From liach at openjdk.org  Thu May  1 00:06:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 00:06:06 GMT
Subject: RFR: 8356022: Migrate descriptor parsing from generics to
 BytecodeDescriptor
Message-ID: <WWJzOE0HrykcWuNdn8uAfgxub1RtpyznSHjBnnzp8T0=.783d3a95-53f2-4a68-a469-1dd1d22dc03f@github.com>

As another step toward the removal of the old generics infrastructure, I propose to remove the usages of generic parsing utilities and use the facilities provided by BytecodeDescriptor, already used by MethodType.fromDescriptorString. This also prevents extra validation cost in use sites to defend against generic types.

In this patch, BytecodeDescriptor and Wrapper see minor updates, mainly for better exception messages - previously, an unparseable char in the descriptor string just reports that char, and now the whole descriptor string is reported.

These behaviors are already covered by the tests added in JDK-8350704 #23788.

Testing: reflect/annotation/Class, running tier 1+2

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

Commit messages:
 - 8356022: Migrate descriptor parsing from generics to BytecodeDescriptor

Changes: https://git.openjdk.org/jdk/pull/24978/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24978&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356022
  Stats: 88 lines in 4 files changed: 39 ins; 30 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24978.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24978/head:pull/24978

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

From jpai at openjdk.org  Thu May  1 01:17:49 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 1 May 2025 01:17:49 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v7]
In-Reply-To: <WXrPCY2jDlc-HuTHhaIFqQR-Sb-COTDvEcztxDV-daQ=.6f81a6d6-8eb5-4528-a7da-d82bfac453f0@github.com>
References: <d-bbTH1lsG4Ev7_sNutKMbLBTXXyQ75ZQTbNvgJkqBQ=.06f597ba-1313-4bb4-9947-880e73acd5bf@github.com>
 <7-hlRi4K3O2f8GbvfOy7Znvvgwyr8pP9BRaIIn4yikM=.1abe74c0-ac9c-447a-956e-49c2d5a93c39@github.com>
 <58DGueeNtyr2dvz3mpHtkN-0IwTBob7FTE7qSxf4-Tw=.eaf788a7-ed25-4551-95e9-7bda041a366b@github.com>
 <fnBvJDP0UMABauuTdiMZxyOAjiJQvVADX_yVlrznOSI=.ca0fdb5a-dd64-42be-a57e-f61992990080@github.com>
 <WXrPCY2jDlc-HuTHhaIFqQR-Sb-COTDvEcztxDV-daQ=.6f81a6d6-8eb5-4528-a7da-d82bfac453f0@github.com>
Message-ID: <vcVyJO5UFU_F8cij0Q3L2LQfL7cxP-n5ed1bJuHIOew=.bf1ca81d-cf06-4b70-8613-cda992c7e40a@github.com>

On Wed, 30 Apr 2025 19:18:57 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>  I think throwing the SkippedException is the right way to go long term but I assume this shows as a reported failure in Mach5 and in the case of assumeTrue it does not result in a failure being reported?

That is correct, use of assumeTrue will skip the test (which is what we want) but it will be classified as aborted instead of skipped. Throwing jtreg.SkippedException however fails that test which isn't a good thing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2069736818

From duke at openjdk.org  Thu May  1 02:05:01 2025
From: duke at openjdk.org (ExE Boss)
Date: Thu, 1 May 2025 02:05:01 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v9]
In-Reply-To: <JEdhi8k7pHVXSfhsmBlvXYPqdRmxoA28H0eLkb7D_YI=.cee51156-73ef-4a3e-9861-2e1a7fe62e8b@github.com>
References: <erzmyFJuLAefAPPuNsKCO6WmpXnwtVw2dXf4Uj2eKRA=.3f601894-77f7-4dc1-99ab-ed347ec999b0@github.com>
 <JEdhi8k7pHVXSfhsmBlvXYPqdRmxoA28H0eLkb7D_YI=.cee51156-73ef-4a3e-9861-2e1a7fe62e8b@github.com>
Message-ID: <Q8vImKKcKmxpDO7NLJ6-aoMN-RZ1Xu-f3w_W7hNU-m4=.a4659857-9db9-4e8e-a93c-75497c5333cd@github.com>

On Wed, 30 Apr 2025 17:45:04 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR contains 2 parts
>> 
>> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
>> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
>> 
>> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
>> 
>> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
>> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
>> 
>> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
>> 
>> - If an entry has not yet been collected, we make sure it will never be collected.
>> - If an entry has been collected, we remove it from the table
>> 
>> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
>> 
>> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
>> 
>> In the future, we may relax the implementation to allow for other use cases.
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - @AlanBateman comments
>  - @xmas92 comments

Changes requested by ExE-Boss at github.com (no known OpenJDK username).

src/java.base/share/classes/java/lang/ref/Reference.java line 314:

> 312:     }
> 313: 
> 314:     private static void runtimeSetup() {

The?comment was?added in?the?wrong?spot:
Suggestion:

    static {
        runtimeSetup();
    }

    // Called from JVM when loading an AOT cache
    private static void runtimeSetup() {

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

PR Review: https://git.openjdk.org/jdk/pull/24757#pullrequestreview-2809022545
PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2069766184

From iklam at openjdk.org  Thu May  1 03:48:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 1 May 2025 03:48:57 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v9]
In-Reply-To: <Q8vImKKcKmxpDO7NLJ6-aoMN-RZ1Xu-f3w_W7hNU-m4=.a4659857-9db9-4e8e-a93c-75497c5333cd@github.com>
References: <erzmyFJuLAefAPPuNsKCO6WmpXnwtVw2dXf4Uj2eKRA=.3f601894-77f7-4dc1-99ab-ed347ec999b0@github.com>
 <JEdhi8k7pHVXSfhsmBlvXYPqdRmxoA28H0eLkb7D_YI=.cee51156-73ef-4a3e-9861-2e1a7fe62e8b@github.com>
 <Q8vImKKcKmxpDO7NLJ6-aoMN-RZ1Xu-f3w_W7hNU-m4=.a4659857-9db9-4e8e-a93c-75497c5333cd@github.com>
Message-ID: <h57967cmeuphxmtoLbCKGT05Fma8S845kiANlpq6mEU=.ab6757ab-c083-4699-93e9-a7d1b98da8d4@github.com>

On Thu, 1 May 2025 02:01:36 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - @AlanBateman comments
>>  - @xmas92 comments
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 314:
> 
>> 312:     }
>> 313: 
>> 314:     private static void runtimeSetup() {
> 
> The?comment was?added in?the?wrong?spot:
> Suggestion:
> 
>     static {
>         runtimeSetup();
>     }
> 
>     // Called from JVM when loading an AOT cache
>     private static void runtimeSetup() {

Oops, I will fix in an related PR #24979

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2069812435

From liach at openjdk.org  Thu May  1 04:45:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 04:45:46 GMT
Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner
 classes
In-Reply-To: <Tkjid9eX1wgNRuVxsqcfVxOiOwtqjHacuehQqmaJUwU=.dc298a48-9ec3-4f13-9cf8-ba7b223c3b1a@github.com>
References: <JQCL1DGBobBWQqWeX3Ykuw1nZOis5D8k6kEllWluE0s=.a089b081-da05-436c-b0f7-ec021887ea57@github.com>
 <Tkjid9eX1wgNRuVxsqcfVxOiOwtqjHacuehQqmaJUwU=.dc298a48-9ec3-4f13-9cf8-ba7b223c3b1a@github.com>
Message-ID: <_uZd7RSmdekF9WeP5qXOOl24Lf00VgithwXEtQcQ9dM=.70173f42-a29e-4a5a-a43f-933b94a8506f@github.com>

On Wed, 30 Apr 2025 21:49:12 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This is a general fix for all the "points to a static field that may hold a different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330).
>> 
>> AOT-cached method handles quite often refer to the static fields in `MethodHandleImpl` or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. `CDSHeapVerifier` makes a very conservative check for such static fields, but sometimes gives false positives (as in the above two JBS issues)
>> 
>> In this PR, we AOT-initialize `MethodHandleImpl` and its inner classes. This is a more authentic snapshot of the state of `java.lang.invoke` during the assembly phase. We also avoid the need to add and maintain entries in the `cdsHeapVerifier.cpp` table.
>> 
>> I also added more code in `MethodHandleTest.java` to simulate potential usage patterns of `MethodHandle` by the Java core libraries. Hopefully this will reduce the likelihood for innocent core lib changes breaking the AOT assembly phase.
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1533:
> 
>> 1531:     }
>> 1532: 
>> 1533:     private static void runtimeSetup() {
> 
> Suggestion:
> 
> 
>     // Called from JVM when loading an AOT cache
>     private static void runtimeSetup() {

Same problem in Reference, credit to @exe-boss

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24956#discussion_r2069844711

From vyazici at openjdk.org  Thu May  1 05:38:27 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 1 May 2025 05:38:27 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
Message-ID: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>

Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.

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

Commit messages:
 - Improve `JavaLangAccess` documentation

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

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

From duke at openjdk.org  Thu May  1 07:23:03 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 1 May 2025 07:23:03 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v9]
In-Reply-To: <Rhd-TORE6HZvS461s9RXOkFUGqSziVfSlS-WkJwFIIw=.58a10e7a-0a61-434e-842e-a6fe8f7bd7d9@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <8SHcFyjNMhqcY0TDhwiLkCO-xottmOFa4nqeCDrglTc=.4122346e-5e83-4f40-abcf-415e33d214f0@github.com>
 <p-0-tWXX8JO0IIlnDanTfTLOI7TaOZ7Lw_5h41OWLhw=.49c5c6ae-9db1-46da-8dc3-23259aae8155@github.com>
 <TqGqjZYMhdqUdFGqBF6uWK4LIXv8aKarteWrCn_OSsw=.57182ab2-8687-4f6a-996d-2d0ba26da67a@github.com>
 <nNsFRSvdP6WDjvnmXBQdpMQKoZDxhP_xeECO-fIXDos=.6e7604f0-5f1b-4dbe-888f-394b8f49712f@github.com>
 <Rhd-TORE6HZvS461s9RXOkFUGqSziVfSlS-WkJwFIIw=.58a10e7a-0a61-434e-842e-a6fe8f7bd7d9@github.com>
Message-ID: <PcEqpKu0kUsuSaHpkTQX_mEQCke4M54meqFNh8_Mxdk=.30ab8568-d07b-4e6a-ba94-af2f2b682bc2@github.com>

On Wed, 30 Apr 2025 21:57:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Unfortunately the same happens. ?
>
> The following javadoc for String's getChars method has, I believe, the desired effect:
> 
> 
>     /**
>      * {@inheritDoc CharSequence}
>      * @param srcBegin {@inheritDoc CharSequence}
>      * @param srcEnd   {@inheritDoc CharSequence}
>      * @param dst      {@inheritDoc CharSequence}
>      * @param dstBegin {@inheritDoc CharSequence}
>      * @throws    IndexOutOfBoundsException {@inheritDoc CharSequence}
>      */
> 
> 
> HTH

Thank you, Joe. That actually produces the expected result. IMHO it is just a workaround for a bug in the javadoc processor, hence I would keep it *just here*, but in all locations (in particular in the CSR) I would propose to keep the shorter form.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2069929069

From duke at openjdk.org  Thu May  1 07:23:03 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 1 May 2025 07:23:03 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v10]
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <pZtV7T5QG8V_KQtOoGiLze9ad2QwacZT531m5a4JwKg=.abaae5eb-0126-4b39-8a02-cc758548a08a@github.com>

> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
> 
> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
> 
> To ensure quality...
> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21730/files
  - new: https://git.openjdk.org/jdk/pull/21730/files/99fcefbd..342bc842

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=08-09

  Stats: 5 lines in 1 file changed: 5 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 May  1 07:32:09 2025
From: duke at openjdk.org (erifan)
Date: Thu, 1 May 2025 07:32:09 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v4]
In-Reply-To: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
Message-ID: <J2uce-Koxq3zh8Fw16I10d6xvZAn9OZv0PpX8iI597I=.962dd328-f9fb-4882-8e66-b84a179552df@github.com>

> 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 six additional commits since the last revision:

 - Update the jtreg test
 - Merge branch 'master' into JDK-8354242
 - Addressed some review comments
   
   1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
   2. Improve code comments.
 - Merge branch 'master' into JDK-8354242
 - Merge branch 'master' into JDK-8354242
 - 8354242: VectorAPI: combine vector not operation with compare
   
   This patch optimizes the following patterns:
   For integer types:
   ```
   (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
       => (VectorMaskCmp src1 src2 ncond)
   (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
       => (VectorMaskCmp src1 src2 ncond)
   ```
   cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
   negative comparison of cond.
   
   For float and double types:
   ```
   (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
       => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
   (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
       => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
   ```
   cond can be eq or ne.
   
   Benchmarks on Nvidia Grace machine with 128-bit SVE2:
   With option `-XX:UseSVE=2`:
   ```
   Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
   testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
   testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
   testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
   testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
   testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
   testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
   testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
   testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
   testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
   testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
   testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
   testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
   testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
   testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
   testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
   testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
   testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
   testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
   testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
   testCompareLTMaskNotInt		ops/s	1672180.09	995.238142	2353757.863	853.774734	1.4
   testCompareLTMaskNotLong	ops/s	856502.2695	12276.82851	1177671.815	496.723302	1.37
   testCompareLTMaskNotShort	ops/s	3325798.025	2412.702501	4711554.181	1779.302112	1.41
   testCompareNEMaskNotByte	ops/s	7910002.518	2771.82477	10245315.33	16321.93935	1.29
   testCompareNEMaskNotDouble	ops/s	863754.6022	523.140788	1179133.982	476.572178	1.36
   testCompareNEMaskNotFloat	ops/s	1723321.883	2598.484803	2358492.186	877.1401	1.36
   testCompareNEMaskNotInt		ops/s	1670288.841	751.774826	2354158.125	835.720163	1.4
   testCompareNEMaskNotLong	ops/s	836327.6835	410.525466	1178178.825	308.757932	1.4
   testCompareNEMaskNotShort	ops/s	3327815.841	1511.978763	4711379.136	2336.505531	1.41
   testCompareUGEMaskNotByte	ops/s	7906699.024	3200.936474	10253843.74	15067.59401	1.29
   testCompareUGEMaskNotInt	ops/s	1674003.923	3287.191727	2353340.666	951.381021	1.4
   testCompareUGEMaskNotLong	ops/s	852424.5562	8920.408939	1177943.609	389.6621	1.38
   testCompareUGEMaskNotShort	ops/s	3327255.858	1584.885143	4711622.355	1247.215277	1.41
   testCompareUGTMaskNotByte	ops/s	7909249.189	4435.283667	10245541.34	10993.34739	1.29
   testCompareUGTMaskNotInt	ops/s	1693713.433	20650.00213	2353153.787	1055.343846	1.38
   testCompareUGTMaskNotLong	ops/s	851022.3395	7079.065268	1177910.677	538.604598	1.38
   testCompareUGTMaskNotShort	ops/s	3327236.988	1616.886789	4711209.865	3098.494145	1.41
   testCompareULEMaskNotByte	ops/s	7909350.825	3251.262342	10261449.03	7273.831341	1.29
   testCompareULEMaskNotInt	ops/s	1672350.925	1545.304304	2353231.755	914.231193	1.4
   testCompareULEMaskNotLong	ops/s	853349.4765	9804.906913	1177967.254	435.044367	1.38
   testCompareULEMaskNotShort	ops/s	3325757.891	1555.062257	4712873.187	1650.986905	1.41
   testCompareULTMaskNotByte	ops/s	7912218.621	2633.477744	10242095.98	21921.39902	1.29
   testCompareULTMaskNotInt	ops/s	1673994.849	2672.507666	2353449.22	946.105757	1.4
   testCompareULTMaskNotLong	ops/s	849032.5868	10406.06689	1177586.047	506.541456	1.38
   testCompareULTMaskNotShort	ops/s	3328062.026	1892.991844	4713247.216	1855.983724	1.41
   
   ```
   With option `-XX:UseSVE=0`:
   ```
   Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
   testCompareEQMaskNotByte	ops/s	7895961.919	72712.90804	7746493.731	71481.92938	0.98
   testCompareEQMaskNotDouble	ops/s	789811.0455	384.493088	766473.7994	2216.581793	0.97
   testCompareEQMaskNotFloat	ops/s	1806305.818	638.010451	1819616.613	3295.38958	1
   testCompareEQMaskNotInt		ops/s	1815820.144	1225.336135	1849538.401	766.29902	1.01
   testCompareEQMaskNotLong	ops/s	807336.492	335.451807	792732.9483	277.954432	0.98
   testCompareEQMaskNotShort	ops/s	4818266.38	1927.862665	4668903.001	1922.782715	0.96
   testCompareGEMaskNotByte	ops/s	7818439.678	75374.97739	16498003.98	41440.49653	2.11
   testCompareGEMaskNotInt		ops/s	1815159.05	1090.912209	2372095.779	1664.397112	1.3
   testCompareGEMaskNotLong	ops/s	804324.5575	2301.686878	927919.8507	371.766719	1.15
   testCompareGEMaskNotShort	ops/s	4818966.563	2443.643652	5385561.038	29558.37423	1.11
   testCompareGTMaskNotByte	ops/s	7893406.157	82687.74264	16470663.2	22165.55812	2.08
   testCompareGTMaskNotInt		ops/s	1815316.812	915.894106	2370447.198	655.016338	1.3
   testCompareGTMaskNotLong	ops/s	807019.456	526.525482	928079.0541	330.582693	1.15
   testCompareGTMaskNotShort	ops/s	4820552.881	1684.247747	5355902.93	5893.2915	1.11
   testCompareLEMaskNotByte	ops/s	7816263.323	79560.0015	16473621.19	56688.99585	2.1
   testCompareLEMaskNotInt		ops/s	1814915.724	926.998625	2368790.306	932.594778	1.3
   testCompareLEMaskNotLong	ops/s	806483.9	935.718082	928110.9074	407.096695	1.15
   testCompareLEMaskNotShort	ops/s	4813660.241	6817.870509	5357107.852	10061.47975	1.11
   testCompareLTMaskNotByte	ops/s	7838948.962	69136.4504	16424405.96	24464.75469	2.09
   testCompareLTMaskNotInt		ops/s	1815056.833	1187.6453	2369892.187	1103.819634	1.3
   testCompareLTMaskNotLong	ops/s	806602.1804	287.923365	928346.4118	617.682824	1.15
   testCompareLTMaskNotShort	ops/s	4817940.643	2767.1509	5372537.84	15397.47169	1.11
   testCompareNEMaskNotByte	ops/s	9078493.798	4630.339307	16484348.42	18925.88346	1.81
   testCompareNEMaskNotDouble	ops/s	661769.6272	398.712981	926763.5839	1808.843788	1.4
   testCompareNEMaskNotFloat	ops/s	1570527.252	563.642144	2312425.678	1815.844846	1.47
   testCompareNEMaskNotInt		ops/s	1619146.58	626.793854	2369711.543	942.330478	1.46
   testCompareNEMaskNotLong	ops/s	680201.5381	2252.836482	927808.6147	414.917863	1.36
   testCompareNEMaskNotShort	ops/s	3763508.054	3622.560798	5367808.015	8591.466599	1.42
   testCompareUGEMaskNotByte	ops/s	7886373.129	75917.74675	16480928.93	27524.31005	2.08
   testCompareUGEMaskNotInt	ops/s	1815636.832	750.036241	2369683.015	901.609404	1.3
   testCompareUGEMaskNotLong	ops/s	806862.5826	287.819616	928001.4394	361.063837	1.15
   testCompareUGEMaskNotShort	ops/s	4820581.361	2098.537435	5375854.248	25619.40165	1.11
   testCompareUGTMaskNotByte	ops/s	7891591.465	96614.93542	16410405.93	15012.37096	2.07
   testCompareUGTMaskNotInt	ops/s	1814871.179	662.825588	2371325.903	1170.491164	1.3
   testCompareUGTMaskNotLong	ops/s	804013.7658	2240.534209	928062.2169	531.306897	1.15
   testCompareUGTMaskNotShort	ops/s	4818150.337	3051.717685	5381449.337	21212.34187	1.11
   testCompareULEMaskNotByte	ops/s	7831540.628	81306.67253	16495250.78	38682.19675	2.1
   testCompareULEMaskNotInt	ops/s	1814484.14	687.860656	2369265.075	940.609586	1.3
   testCompareULEMaskNotLong	ops/s	807780.5749	769.876816	927538.0732	1278.267724	1.14
   testCompareULEMaskNotShort	ops/s	4817437.42	5141.336541	5356183.359	7015.608124	1.11
   testCompareULTMaskNotByte	ops/s	7849078.225	56753.59764	16395975.27	34043.67295	2.08
   testCompareULTMaskNotInt	ops/s	1814328.226	2697.219111	2370700.47	1991.841988	1.3
   testCompareULTMaskNotLong	ops/s	807166.8197	253.061506	927926.2803	252.933462	1.14
   testCompareULTMaskNotShort	ops/s	4821098.216	1625.959044	5348980.243	4100.768121	1.1
   ```
   
   Benchmarks on AMD EPYC 9124 16-Core Processor:
   With option `-XX:UseAVX=3`:
   ```
   Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
   testCompareEQMaskNotByte	ops/s	16607323.35	1233692.631	18381557.66	1163201.522	1.1
   testCompareEQMaskNotDouble	ops/s	2114285.245	58782.2534	2959946.353	43016.0445	1.39
   testCompareEQMaskNotFloat	ops/s	4480874.437	89975.29074	6960151.436	64799.143	1.55
   testCompareEQMaskNotInt		ops/s	4370906.91	51784.80889	6856955.043	313858.5504	1.56
   testCompareEQMaskNotLong	ops/s	2080065.895	26762.06732	2939142.143	67179.05314	1.41
   testCompareEQMaskNotShort	ops/s	7968282.563	210437.2781	12701214.56	473152.6407	1.59
   testCompareGEMaskNotByte	ops/s	18419141.89	473408.9451	19880059.68	321638.0397	1.07
   testCompareGEMaskNotInt		ops/s	4419015.62	77352.98633	7037639.227	151066.0383	1.59
   testCompareGEMaskNotLong	ops/s	2147982.48	49227.42782	3000275.928	39298.75344	1.39
   testCompareGEMaskNotShort	ops/s	8469039.613	17833.19707	12288229.49	244317.8812	1.45
   testCompareGTMaskNotByte	ops/s	18728997.5	468328.8358	20544730.05	392264.6466	1.09
   testCompareGTMaskNotInt		ops/s	4510009.705	78812.57357	7364629.942	70970.78473	1.63
   testCompareGTMaskNotLong	ops/s	2124104.969	40917.89257	2953536.279	35199.19687	1.39
   testCompareGTMaskNotShort	ops/s	8690557.621	311534.1159	12344017.51	457931.8741	1.42
   testCompareLEMaskNotByte	ops/s	17758400.53	478383.4945	19209183.26	1143297.241	1.08
   testCompareLEMaskNotInt		ops/s	4363664.862	43443.18063	7054093.064	78141.11476	1.61
   testCompareLEMaskNotLong	ops/s	2068632.213	29844.78023	2954766.412	50667.22502	1.42
   testCompareLEMaskNotShort	ops/s	8637608.548	183538.5511	12719010.27	473568.8825	1.47
   testCompareLTMaskNotByte	ops/s	14406138.95	423105.0163	17292417.96	371386.9689	1.2
   testCompareLTMaskNotInt		ops/s	4546707.266	131977.3144	7040483.394	213590.4657	1.54
   testCompareLTMaskNotLong	ops/s	2123277.356	47243.21499	2848720.442	58896.97045	1.34
   testCompareLTMaskNotShort	ops/s	7570169.363	649873.6295	11945383.75	988276.5955	1.57
   testCompareNEMaskNotByte	ops/s	18274529.55	683396.7384	19081938.8	1118739.778	1.04
   testCompareNEMaskNotDouble	ops/s	2112533.61	43295.50012	2912115.441	78189.51083	1.37
   testCompareNEMaskNotFloat	ops/s	4628683.814	93817.07362	6967208.729	145135.8544	1.5
   testCompareNEMaskNotInt		ops/s	4470900.214	75974.50842	7286913.662	116328.5277	1.62
   testCompareNEMaskNotLong	ops/s	2134091.061	46377.94061	2934667.477	81675.46021	1.37
   testCompareNEMaskNotShort	ops/s	8790384.287	396161.8599	13076858.35	286272.1155	1.48
   testCompareUGEMaskNotByte	ops/s	18009150.9	660803.8886	17551258.33	1667014.843	0.97
   testCompareUGEMaskNotInt	ops/s	4442928.74	83190.81019	6854088.277	329008.8901	1.54
   testCompareUGEMaskNotLong	ops/s	2088357.736	71696.24791	2973202.26	63278.78974	1.42
   testCompareUGEMaskNotShort	ops/s	8348624.02	116562.7876	12832250.78	546869.3006	1.53
   testCompareUGTMaskNotByte	ops/s	17871101.25	800199.6321	19902619.81	214003.3262	1.11
   testCompareUGTMaskNotInt	ops/s	4088304.421	137797.9723	7135454.33	124553.651	1.74
   testCompareUGTMaskNotLong	ops/s	2070610.42	19881.82182	2991536.365	36260.60767	1.44
   testCompareUGTMaskNotShort	ops/s	8637099.341	155822.1608	12756579.77	186068.199	1.47
   testCompareULEMaskNotByte	ops/s	17940901.36	1258029.364	18932484.94	694554.6305	1.05
   testCompareULEMaskNotInt	ops/s	4369177.511	74982.31936	6392773.082	550171.2266	1.46
   testCompareULEMaskNotLong	ops/s	2135905.761	43693.63178	2877579.631	41651.56289	1.34
   testCompareULEMaskNotShort	ops/s	8607710.544	132655.1676	12446370.04	441718.3035	1.44
   testCompareULTMaskNotByte	ops/s	17409912.23	1033204.537	20607479.99	362000.5056	1.18
   testCompareULTMaskNotInt	ops/s	4386455.9	119192.1635	6920123.264	186158.2845	1.57
   testCompareULTMaskNotLong	ops/s	2064995.149	38622.2734	2988343.589	39037.90006	1.44
   testCompareULTMaskNotShort	ops/s	8642182.752	230919.2442	13029582.09	437101.4923	1.5
   ```
   
   The small amount of performance degradation is due to test fluctuations.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24674/files
  - new: https://git.openjdk.org/jdk/pull/24674/files/34eae981..4fbf84e3

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

  Stats: 13350 lines in 388 files changed: 9247 ins; 1843 del; 2260 mod
  Patch: https://git.openjdk.org/jdk/pull/24674.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24674/head:pull/24674

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

From duke at openjdk.org  Thu May  1 07:34:52 2025
From: duke at openjdk.org (erifan)
Date: Thu, 1 May 2025 07:34:52 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v3]
In-Reply-To: <1Qo4pB9I7Ok4ntXSE-KkE0sv-Tp5EVCWriWnjcf2iEE=.a7e28640-85df-436a-9c82-3c067cc88dee@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <d3j_5wtavYCnzkiXe3P1VQeuRRK1MXDpJd4okI3UBUg=.8b9e56ad-bbc3-4b12-8ff0-fcb86ff4f4df@github.com>
 <1Qo4pB9I7Ok4ntXSE-KkE0sv-Tp5EVCWriWnjcf2iEE=.a7e28640-85df-436a-9c82-3c067cc88dee@github.com>
Message-ID: <ukQEp7aEkMwZVRiy0178aHGYakmWrA0wQ-adDDRTPzw=.1bdceaf9-0338-49ec-8ff2-3d6db70360af@github.com>

On Tue, 29 Apr 2025 10:22:22 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Addressed some review comments
>>    
>>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>>    2. Improve code comments.
>>  - Merge branch 'master' into JDK-8354242
>>  - Merge branch 'master' into JDK-8354242
>>  - 8354242: VectorAPI: combine vector not operation with compare
>>    
>>    This patch optimizes the following patterns:
>>    For integer types:
>>    ```
>>    (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    ```
>>    cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>>    negative comparison of cond.
>>    
>>    For float and double types:
>>    ```
>>    (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    ```
>>    cond can be eq or ne.
>>    
>>    Benchmarks on Nvidia Grace machine with 128-bit SVE2:
>>    With option `-XX:UseSVE=2`:
>>    ```
>>    Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>>    testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>>    testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>>    testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>>    testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>>    testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>>    testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>>    testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>>    testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>>    testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
>>    testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
>>    testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
>>    testCompareGTMaskNotInt		ops/s	1673393...
>
> Yes, this discussion is down to `requires` vs `applyIf`. This is my argument for `applyIf`, quoted from above, I have not yet seen an argument against it:
> 
>>  If you use @require, then the person does not realize there is a test AND the test is not run. If you use applyIf, the person does not realize there is a test, but it is run at least for result verifiation - and then the person MIGHT realize if the test catches a wrong result / crash.
> 
> In my understanding, `requires` should only be used if the test really **requires** a certain platform or feature. That can be because some flags are only available under certain platforms for example. But for IR tests, we should try to always use `applyIf`, because it allows testing on other platforms.
> 
> Actually, I filed this RFE a while ago: https://bugs.openjdk.org/browse/JDK-8310891
> We should try to move as many tests from using `requires` to `applyIf`, so that we have an increased test coverage.

@eme64 @jatin-bhateja I have updated the test, thanks for your suggestion.

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

PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-2844256626

From jlahoda at openjdk.org  Thu May  1 07:45:55 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 May 2025 07:45:55 GMT
Subject: Integrated: 8344708: Implement JEP 511: Module Import Declarations
In-Reply-To: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
Message-ID: <gYaNiDs5PL4NDmpOy9etPHh86GsmJWu_Z_QkubL-OXI=.998a58dc-7470-4204-8f89-23bba1191d55@github.com>

On Wed, 26 Feb 2025 13:50:52 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a patch to finalize the module imports feature. Please see:
> https://bugs.openjdk.org/browse/JDK-8344700

This pull request has now been integrated.

Changeset: 0a697f6f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0a697f6ff4c2f8254e95519e04708cf406009dc3
Stats:     484 lines in 32 files changed: 268 ins; 136 del; 80 mod

8344708: Implement JEP 511: Module Import Declarations

Reviewed-by: mcimadamore, vromero, alanb

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

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

From duke at openjdk.org  Thu May  1 08:45:06 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 1 May 2025 08:45:06 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v11]
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <bY6wxELBjJnRQ5co73NgJC5baGtnY5UKezuQXCvYU5E=.82004266-7468-484d-a28c-85852d06f8d9@github.com>

> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
> 
> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
> 
> To ensure quality...
> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted?

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21730/files
  - new: https://git.openjdk.org/jdk/pull/21730/files/342bc842..62a6867b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 May  1 08:45:06 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 1 May 2025 08:45:06 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v8]
In-Reply-To: <4Rrs1AMrJ4M-_7x6li7dDhSVnasUVy8w4I42IjZCU30=.f0c85e6b-3bb8-464e-a006-3a34e77e06c9@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <1s3MwTXb7v_7WWORxAL4WXOlbMOnpCkt8kbjc613-UM=.a81c62cc-4cc5-4714-8d3b-a63f0b9e092d@github.com>
 <4Rrs1AMrJ4M-_7x6li7dDhSVnasUVy8w4I42IjZCU30=.f0c85e6b-3bb8-464e-a006-3a34e77e06c9@github.com>
Message-ID: <nUA-MzB0cvVRyrPxf3UZaI9TG4UBThspsIQAGeJr_mI=.f1cc0bf9-0b6b-440f-81c6-78c2351eb51d@github.com>

On Mon, 28 Apr 2025 13:29:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.'
>
> src/java.base/share/classes/java/lang/StringBuilder.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2003, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> If there's no change to this file the copyright year update could be reverted?

Good catch, Daniel! Fixed. Thank you! ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2069997101

From dfuchs at openjdk.org  Thu May  1 08:47:46 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 1 May 2025 08:47:46 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v4]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <pKoH3nSdX5785wl9WluGHMfUinFx1sRF9EcFMt_7iaE=.5b3fb398-b66d-43c9-88a0-463973bbee74@github.com>

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 412 commits:

 - merge latest changes from master branch
 - merge latest changes from master branch
 - http3: jep review feedback: rename HttpRequest.HttpRequestOption into top-level HttpOption. Http3DiscoveryMode is now an inner class in HttpOption. Improved protocol selection documentation in HttpClient class-level apiNote. Add links from Builder.version methods.
 - merge latest changes from master branch
 - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
 - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
 - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
 - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
 - http3: minor improvement to log message
 - http3: Artur's review - remove commented out code from test
 - ... and 402 more: https://git.openjdk.org/jdk/compare/526951db...9156a51e

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=03
  Stats: 102846 lines in 472 files changed: 100217 ins; 1120 del; 1509 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 mli at openjdk.org  Thu May  1 08:52:45 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 1 May 2025 08:52:45 GMT
Subject: RFR: 8355698: JDK not supporting sleef could cause exception at
 runtime after JDK-8353786
In-Reply-To: <1hfhvGjxKFAYEtj1D_pIdgU659AE2oPWoQEyXl8sRgQ=.3aa62617-142a-49c9-82c4-0f761cb73aff@github.com>
References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
 <t5yCh_uHzYvMEUCimBleAdsx_rHcD5tic0NqclC7z4Q=.96e18401-96e1-4723-98dd-e12b70933df8@github.com>
 <3BMQiQtyRXIj-NFUoFPliNYV4r1nX3KpKgniMvtOMkc=.cdcd240e-ce85-46c7-9bfb-e5be5124aae9@github.com>
 <PfjjyqfVNfWSyegFjmOOzmyafV46dlMp5mewRvoOn1Q=.48092ede-8990-4fcd-8cbf-64db021374b7@github.com>
 <sCvv_ZdnRtPqNXffYKzKMcK5OUTsree7QbfevmAAQuI=.fdd11430-94a0-4849-8ce1-613da7f92311@github.com>
 <1hfhvGjxKFAYEtj1D_pIdgU659AE2oPWoQEyXl8sRgQ=.3aa62617-142a-49c9-82c4-0f761cb73aff@github.com>
Message-ID: <Np9_Py66RkB-RMq1Uri-J3C6xEcgpAeKiqBWNZWC-fk=.ff9f9610-98a8-4e1d-b5b2-191444284e32@github.com>

On Wed, 30 Apr 2025 19:41:52 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Overall, it still looks like a JDK build issue to me. Hiding problems occurred during the build is not good. If some toolchains can't successfully build the library, the library shouldn't be included in JDK.

No, in riscv case (possiblely also on arm?) I don't think it's a build issue, the jdk vendor can choose to support it or not, it's just the way passing the information ( whether it's supported or not) are different.

How about we consider this in another way, we could fix this issue first, as it fails regularly on riscv and x64 in some situations. Then if you still consider the existing behaviour should be changed and could be improved further, it can be done in another pr. After all, it already broke the existing jdk in some scenarios.
How do you think about it?

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

PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2844401476

From mcimadamore at openjdk.org  Thu May  1 09:08:46 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 May 2025 09:08:46 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v6]
In-Reply-To: <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
Message-ID: <O8GFYpiZIN5JhdBqj7tXP9BOrkEKRpNBwOf5qo46vUs=.20384f2d-a6df-46f1-b039-92656d92fce6@github.com>

On Wed, 30 Apr 2025 15:33:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
>> 
>> Re-allocated segments are not zeroed between allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve on comments

src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 81:

> 79:     @Override
> 80:     public int hashCode() {
> 81:         return System.identityHashCode(this);

What's the value in these overloads? Isn't this implementation the same we'd get if there were no overrides?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070015191

From mcimadamore at openjdk.org  Thu May  1 09:08:46 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 May 2025 09:08:46 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v6]
In-Reply-To: <O8GFYpiZIN5JhdBqj7tXP9BOrkEKRpNBwOf5qo46vUs=.20384f2d-a6df-46f1-b039-92656d92fce6@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
 <O8GFYpiZIN5JhdBqj7tXP9BOrkEKRpNBwOf5qo46vUs=.20384f2d-a6df-46f1-b039-92656d92fce6@github.com>
Message-ID: <Lx9AhMwcKnQnfbbiB2wc2bogr5K6JIMfg4a250mwqZ8=.539cdc45-893c-4a76-bd4f-8115ed261c14@github.com>

On Thu, 1 May 2025 09:04:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve on comments
>
> src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 81:
> 
>> 79:     @Override
>> 80:     public int hashCode() {
>> 81:         return System.identityHashCode(this);
> 
> What's the value in these overloads? Isn't this implementation the same we'd get if there were no overrides?

Ugh - it's a record, I see. Which brings up the question -- should it be a record? Should it advertize its `size and `tl` components (they seem rather implementation specific?).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070017489

From mcimadamore at openjdk.org  Thu May  1 09:11:46 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 May 2025 09:11:46 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v6]
In-Reply-To: <Lx9AhMwcKnQnfbbiB2wc2bogr5K6JIMfg4a250mwqZ8=.539cdc45-893c-4a76-bd4f-8115ed261c14@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
 <O8GFYpiZIN5JhdBqj7tXP9BOrkEKRpNBwOf5qo46vUs=.20384f2d-a6df-46f1-b039-92656d92fce6@github.com>
 <Lx9AhMwcKnQnfbbiB2wc2bogr5K6JIMfg4a250mwqZ8=.539cdc45-893c-4a76-bd4f-8115ed261c14@github.com>
Message-ID: <7Cz0Yoz7CNQXNgnCNlUTI96sTtV87FsVc7sRgPAP6gU=.0b79f998-26e2-4567-af60-8bcd75391105@github.com>

On Thu, 1 May 2025 09:05:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 81:
>> 
>>> 79:     @Override
>>> 80:     public int hashCode() {
>>> 81:         return System.identityHashCode(this);
>> 
>> What's the value in these overloads? Isn't this implementation the same we'd get if there were no overrides?
>
> Ugh - it's a record, I see. Which brings up the question -- should it be a record? Should it advertize its `size and `tl` components (they seem rather implementation specific?).

Was this done so that the final field could be trusted? (I believe all final fields are implicitly trusted in jdk/internal/foreign):


      holder->is_in_package("jdk/internal/foreign/layout") || holder->is_in_package("jdk/internal/foreign") ||

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070024350

From mcimadamore at openjdk.org  Thu May  1 09:25:46 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 May 2025 09:25:46 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v6]
In-Reply-To: <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
Message-ID: <LmQ_Iz6vrttjTx8A737pciH9mhZt3xdWZOplr4sLvEY=.d5943d92-1d5f-4f6a-a132-10bb8766f74a@github.com>

On Wed, 30 Apr 2025 15:33:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
>> 
>> Re-allocated segments are not zeroed between allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve on comments

src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 163:

> 161:                     lock.unlock();
> 162:                 }
> 163:                 Reference.reachabilityFence(arena);

I'm not sure this is enough to keep the automatic arena alive. If the client lets the Frame arena go out of scope w/o calling close, then `arena` will become unreachable, but some segments created by the Frame arena might still be reachable. To be more correct, I think `Frame` should add a "close action" to its confined arena which keeps the outer automatic arena alive. This can be done, for instance, by passing a close action to the `reinterpret` call:


frame = new SlicingAllocator(frameSegment.reinterpret(confinedArena, () -> Reference.reachabilityFence(arena)));


The close action is installed in the `MemorySession` object of `confinedArena` -- which is then attached to all segments returned by `Frame` -- thus keeping the automatic arena alive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070063828

From mcimadamore at openjdk.org  Thu May  1 09:35:48 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 May 2025 09:35:48 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v6]
In-Reply-To: <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
Message-ID: <4jpiMz176AvMXMYO5YwjyNrWre6cTxNcVy6O4wmbq7k=.cb6fc8da-2d89-4f75-896a-c253ff9a3e36@github.com>

On Wed, 30 Apr 2025 15:33:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
>> 
>> Re-allocated segments are not zeroed between allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve on comments

src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 139:

> 137:             public MemorySegment allocate(long byteSize, long byteAlignment) {
> 138:                 // Make sure we are on the right thread
> 139:                 if (((MemorySessionImpl) scope()).ownerThread() != Thread.currentThread()) {

This can also be rewritten as:
`MemorySession.toMemorySession(confinedArena).checkValidState()` -- which is what we use elsewhere

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070089765

From duke at openjdk.org  Thu May  1 09:55:49 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Thu, 1 May 2025 09:55:49 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v5]
In-Reply-To: <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <dFfo7XWntOoKDqWbOSksw2xon3geOvm2h7WuLsodIU0=.6480d447-b14b-43ea-a673-f36e7cbed4fa@github.com>
 <R26A-RFOkbja1bnImimPwn63l0Ey3wceWkCsJg1Jox4=.5621fccc-d59e-4a51-88e9-1c28d9ae9b86@github.com>
 <cNouC_Qp5yZHSyxMdZfBkmprp60u0UPlBS8kL9AVhz0=.4d085a45-cb66-4656-8ba2-41944478c989@github.com>
 <GENBQaAlYVOW6PdXkzHSCIgUIEbVMzMj4_s-E7YLD1c=.125d5f41-50bc-4e0c-befc-f2f7da3eb94e@github.com>
 <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
Message-ID: <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>

On Sun, 27 Apr 2025 14:23:50 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> I misunderstood that I have tested `stdin.encoding`.
>> I cannot confirm that `stdin.encoding` is changed in Windows to proper ones because it has not been included in the latest EA build (20) and I cannot build master for Windows. However, it is changed to `US-ASCII` in Ubuntu when I change `LANG`. I will believe its author until the latest EA build is updated.
>
> Anyway you need to merge master first to test `stdin.encoding`.

`stdin.encoding` seems to work as intended in Windows for Japanese. No need to change. (I wish the constructors of `InputStreamReader` and `Scanner` used `stdin.encoding` instead of UTF-8 for `System.in` by defaultI) Sorry to have bothered you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070108439

From zuniquex at protonmail.com  Thu May  1 10:10:10 2025
From: zuniquex at protonmail.com (=?utf-8?Q?Steffen_Nie=C3=9Fing?=)
Date: Thu, 01 May 2025 10:10:10 +0000
Subject: JavaDoc fix in java.util.Date
In-Reply-To: <54dbafaf-5cac-45d3-a5e3-2cac737dba9e@oracle.com>
References: <QeV5mLVvqC5Ij-QUtdCeInISr3wHrIyOt2-PaMJ2JUOQTBltQjYPu2BEeAKcOiiPsf50svkol4b1o8-9108CJ79bNf1BYnPbMSAjIjOt0a8=@protonmail.com>
 <d425a039-c721-4f99-8711-8ffe60edf1eb@oracle.com>
 <SJ2PR10MB76698571DC7CEE5901A73EDAA2832@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <e012e31c-d471-49cd-813f-65110f0f5ef7@oracle.com>
 <SJ2PR10MB7669CEC72B87A1EF3D298607A2832@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <t7b4RpplTLhZsSGpQLyv3LP4ixFUcRzjsbrnlUObHpduwo-ktA7pcgS4h3IItImabE6y8uU-H_jDITbZ0qcb_Q4VmlsdXXy4yRPM9QbjNso=@protonmail.com>
 <54dbafaf-5cac-45d3-a5e3-2cac737dba9e@oracle.com>
Message-ID: <o31BwgG4PNhn_yd3VtGRU2VrphvfNfW-uRqCkVKpwQ7BBtSQg_c54mnoGg5r0yKTc7G8gwwaBloxNJmBtFJBM_1xQmiZ8uVqUIkqv-UajUA=@protonmail.com>

Thanks for all these helpful responses. So I guess there's nothing to do here except we want to integrate the change proposed by Chen to update the expression to use Long.hashCode.

Cheers,
Steffen

-------- Urspr?ngliche Nachricht --------
Am 30.04.25 23:25 schrieb Roger Riggs :

> Hi Steffen,
>
> One other oddity about the shift operators in Java, they only use the lower 5 bits of the shift distance argument.
>
> So,
>
> int x = 1024;
> x >>4 == 64; and
> x >> 36 == 64;
>
> It is unusual to specify the algorithm used for hashcodes, though in some cases backward compatibility has forced them to be specified.
>
> Regards, Roger
>
> On 4/30/25 4:37 PM, Steffen Nie?ing wrote:
>
>> Thanks, haven't seen unsigned right shift before. You're right, it should be fine to use the unsigned one and hence Long.hashCode for that.
>>
>> However, the docs should match the expression used in the implementation when explicitly naming the returned expression. Should we update both to Long.hashCode(this.getTime())?
>>
>> Cheers,
>> Steffen
>>
>> Chen Liang [<chen.l.liang at oracle.com>](mailto:chen.l.liang at oracle.com) schrieb am Mittwoch, 30. April 2025 um 22:27:
>>
>>> Well, the sign has no impact here - the most significant 32 bits duplicated from the original sign bit are immediately discarded in the subsequent int cast truncation to the least significant 32 bits. However, how there is such a difference from before OpenJDK was published is still intriguing.
>>> ---------------------------------------------------------------
>>>
>>> From: core-libs-dev [<core-libs-dev-retn at openjdk.org>](mailto:core-libs-dev-retn at openjdk.org) on behalf of Naoto Sato [<naoto.sato at oracle.com>](mailto:naoto.sato at oracle.com)
>>> Sent: Wednesday, April 30, 2025 3:11 PM
>>> To: core-libs-dev at openjdk.org [<core-libs-dev at openjdk.org>](mailto:core-libs-dev at openjdk.org)
>>> Subject: Re: JavaDoc fix in java.util.Date
>>>
>>> Interestingly, the implementation of Date.hashCode() does use the signed
>>> right shift ">>".
>>>
>>> Naoto
>>>
>>> On 4/30/25 1:06 PM, Chen Liang wrote:
>>>> Indeed, Joe is right. Unsigned right shift does not appear often and is
>>>> equivalent to signed right shift if the sign bit is 0.
>>>>
>>>> However, this piece of quote can get an upgrade - it can become
>>>> `Long.hashCode(this.getTime())`.
>>>>
>>>> *
>>>> Chen
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* core-libs-dev [<core-libs-dev-retn at openjdk.org>](mailto:core-libs-dev-retn at openjdk.org) on behalf of
>>>> Joseph D. Darcy [<joe.darcy at oracle.com>](mailto:joe.darcy at oracle.com)
>>>> *Sent:* Wednesday, April 30, 2025 2:54 PM
>>>> *To:* Steffen Nie?ing [<zuniquex at protonmail.com>](mailto:zuniquex at protonmail.com); core-libs-
>>>> dev at openjdk.org [<core-libs-dev at openjdk.org>](mailto:core-libs-dev at openjdk.org)
>>>> *Subject:* Re: JavaDoc fix in java.util.Date
>>>> Unsigned right shift is non-existent?
>>>>
>>>> "The operators << (left shift), >> (signed right shift), and >>>
>>>> (unsigned right shift) are called the shift operators. The left-hand
>>>> operand of a shift operator is the value to be shifted; the right-hand
>>>> operand specifies the shift distance. "
>>>>
>>>> https://docs.oracle.com/javase/specs/jls/se24/html/jls-15.html#jls-15.19
>>>> <https://docs.oracle.com/javase/specs/jls/se24/html/jls-15.html#jls-15.19>
>>>>
>>>> -Joe
>>>>
>>>> On 4/30/2025 12:46 PM, Steffen Nie?ing wrote:
>>>>> Hello,
>>>>>
>>>>> I'm new to the OpenJDK community and plan to make my first change.
>>>>>
>>>>> I've found a small mistake in the documentation of
>>>>> java.util.Date#hashCode(). The documentation provides a Java
>>>>> expression of the returned value, which uses a non-existent operator
>>>>> '>>>'.
>>>>>
>>>>> Now I'm searching for a sponsor for a JBS issue and the code review.
>>>>> Chen Liang directed me to this mailing list to ask for sponsoring on
>>>>> this topic.
>>>>>
>>>>> Cheers,
>>>>> Steffen
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250501/70a90d34/attachment-0001.htm>

From mcimadamore at openjdk.org  Thu May  1 10:24:47 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 May 2025 10:24:47 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v6]
In-Reply-To: <LmQ_Iz6vrttjTx8A737pciH9mhZt3xdWZOplr4sLvEY=.d5943d92-1d5f-4f6a-a132-10bb8766f74a@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
 <LmQ_Iz6vrttjTx8A737pciH9mhZt3xdWZOplr4sLvEY=.d5943d92-1d5f-4f6a-a132-10bb8766f74a@github.com>
Message-ID: <CyH1T3cFMsCqQwUFNMULG7xhS9UPG7tkuZaNkcdxtsE=.a33b32c4-8652-4897-b545-dfbc10444955@github.com>

On Thu, 1 May 2025 09:22:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve on comments
>
> src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 163:
> 
>> 161:                     lock.unlock();
>> 162:                 }
>> 163:                 Reference.reachabilityFence(arena);
> 
> I'm not sure this is enough to keep the automatic arena alive. If the client lets the Frame arena go out of scope w/o calling close, then `arena` will become unreachable, but some segments created by the Frame arena might still be reachable. To be more correct, I think `Frame` should add a "close action" to its confined arena which keeps the outer automatic arena alive. This can be done, for instance, by passing a close action to the `reinterpret` call:
> 
> 
> frame = new SlicingAllocator(frameSegment.reinterpret(confinedArena, () -> Reference.reachabilityFence(arena)));
> 
> 
> The close action is installed in the `MemorySession` object of `confinedArena` -- which is then attached to all segments returned by `Frame` -- thus keeping the automatic arena alive.

(if you agree with this analysis, perhaps adding an extra stress test, or tweaking one of the existing stress tests to check this could also be useful)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070128504

From mcimadamore at openjdk.org  Thu May  1 10:24:49 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 May 2025 10:24:49 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v6]
In-Reply-To: <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
Message-ID: <p4z0MV5KVRguei1fYbwXJ05jomsugqeIRF4huzsWFmE=.e1ee3fa1-4a26-4492-a585-e9b820b99aa1@github.com>

On Wed, 30 Apr 2025 15:33:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
>> 
>> Re-allocated segments are not zeroed between allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve on comments

test/jdk/java/foreign/TestBufferStack.java line 192:

> 190:                 assertEquals(firstAddress, segment.address());
> 191:                 var segmentTwo = arena.allocate(JAVA_INT);
> 192:                 assertNotEquals(firstAddress, segmentTwo.address());

Should this check be stronger -- e.g. that the address of the second segment should be the address of the first + the size of JAVA_INT?

test/jdk/java/foreign/TestBufferStack.java line 203:

> 201: 
> 202:     @Test
> 203:     void allocationCaptureStateLayout() {

This test is not really testing much re. capture state layout. It feels like the only added thing w.r.t. `allocationSameAsPoolSize` is that it also checks that additional allocation will fail with IOOBE -- maybe these two tests should be merged?

test/jdk/java/foreign/TestBufferStack.java line 241:

> 239:     @Test
> 240:     void closeConfinement() {
> 241:         var pool = BufferStack.of(POOL_SIZE);

Nice confinement tests!

test/jdk/java/foreign/TestBufferStackStress.java line 28:

> 26:  * @modules java.base/jdk.internal.foreign
> 27:  * @build NativeTestHelper TestBufferStackStress
> 28:  * @run junit/othervm --enable-native-access=ALL-UNNAMED TestBufferStackStress

is `--enable-native-access` needed here (and also in the other stress test) ?

test/jdk/java/foreign/TestBufferStackStress2.java line 45:

> 43: import java.util.concurrent.atomic.AtomicBoolean;
> 44: 
> 45: final class TestBufferStackStress2 extends NativeTestHelper {

This also extends `NativeTestHelper` -- does it need to?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070124607
PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070126160
PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070126843
PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070129639
PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070129263

From mcimadamore at openjdk.org  Thu May  1 10:27:48 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 May 2025 10:27:48 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v6]
In-Reply-To: <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
Message-ID: <Kr2wD6ytrcdHAo6sDA-vuBTO3kmytT3IDTzJSHqvOqM=.a7a215f1-d032-47f6-a6ef-34fcda150bb9@github.com>

On Wed, 30 Apr 2025 15:33:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
>> 
>> Re-allocated segments are not zeroed between allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve on comments

test/micro/org/openjdk/bench/java/lang/foreign/CallOverheadByValue.java line 87:

> 85:     public void byValue() throws Throwable {
> 86:         // point = unit();
> 87:         MemorySegment unused = (MemorySegment) MH_UNIT_BY_VALUE.invokeExact(

This benchmark is a bit misleading, because the allocator object will add some noise in the mix. I suggest to have some allocator object ready in a field, and just pass that (avoiding the lambda). That would also be more similar to idiomatic FFM code (which assumes some allocator is already available at the callsite).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070131376

From rriggs at openjdk.org  Thu May  1 12:58:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 1 May 2025 12:58:51 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version [v7]
In-Reply-To: <qLyzxhjRin1N7OIh1kUfAGA7dECwURIxCIpK3FPA6iw=.cdc6fbb1-040a-4086-a3e4-25a832d3ac5e@github.com>
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
 <qLyzxhjRin1N7OIh1kUfAGA7dECwURIxCIpK3FPA6iw=.cdc6fbb1-040a-4086-a3e4-25a832d3ac5e@github.com>
Message-ID: <_lhfHVwnay07O9vLnUFPnJ1mRuj50y5oxO-lq7oR_Cg=.1ae3a9c1-7856-48f7-ac58-718bcc3b30a6@github.com>

On Wed, 30 Apr 2025 22:12:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Take the class file version to reject flags not yet defined, redefined, or obsoleted. This is useful for clients like javap to report the correct undefined flags for different class file versions.
>> 
>> A preparatory patch for javap to pass around the ClassFileFormatVersion to parse flags is available at #24955.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-cffv-parse
>  - review: improve comments about implicit null checks
>  - Merge branch 'fix/javap-cffv-access-flags' into feature/af-cffv-parse
>  - Adapt the location APIs
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/javap-cffv-access-flags
>  - 8355956: Prepare javap for class file format aware access flag parsing
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Explicit imports
>  - Wording updates
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/e36756b2...b1cf4ebb

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24760#pullrequestreview-2809740302

From liach at openjdk.org  Thu May  1 12:59:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 12:59:51 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v11]
In-Reply-To: <bY6wxELBjJnRQ5co73NgJC5baGtnY5UKezuQXCvYU5E=.82004266-7468-484d-a28c-85852d06f8d9@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <bY6wxELBjJnRQ5co73NgJC5baGtnY5UKezuQXCvYU5E=.82004266-7468-484d-a28c-85852d06f8d9@github.com>
Message-ID: <eIAbKE11RsBYYxLFsdl8mbp9K6FEZaJ0GrHxWWNbsEc=.39224a40-5b72-4e3f-b2fd-cb8226dd2f92@github.com>

On Thu, 1 May 2025 08:45:06 GMT, Markus KARG <duke at openjdk.org> 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 proposal by Daniel: If there's no change to this file the copyright year update could be reverted?

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 488:

> 486:     /**
> 487:      * {@inheritDoc CharSequence}
> 488:      */

Suggestion:

     * {@inheritDoc CharSequence}
     * @param srcBegin {@inheritDoc CharSequence}
     * @param srcEnd   {@inheritDoc CharSequence}
     * @param dst      {@inheritDoc CharSequence}
     * @param dstBegin {@inheritDoc CharSequence}
     * @throws IndexOutOfBoundsException {@inheritDoc CharSequence}
     */

Let's aim for text parity for now; can you create a bug for Javadoc for this inheritDoc inconsistency?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2070240781

From lancea at openjdk.org  Thu May  1 12:58:50 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 1 May 2025 12:58:50 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v7]
In-Reply-To: <vcVyJO5UFU_F8cij0Q3L2LQfL7cxP-n5ed1bJuHIOew=.bf1ca81d-cf06-4b70-8613-cda992c7e40a@github.com>
References: <d-bbTH1lsG4Ev7_sNutKMbLBTXXyQ75ZQTbNvgJkqBQ=.06f597ba-1313-4bb4-9947-880e73acd5bf@github.com>
 <7-hlRi4K3O2f8GbvfOy7Znvvgwyr8pP9BRaIIn4yikM=.1abe74c0-ac9c-447a-956e-49c2d5a93c39@github.com>
 <58DGueeNtyr2dvz3mpHtkN-0IwTBob7FTE7qSxf4-Tw=.eaf788a7-ed25-4551-95e9-7bda041a366b@github.com>
 <fnBvJDP0UMABauuTdiMZxyOAjiJQvVADX_yVlrznOSI=.ca0fdb5a-dd64-42be-a57e-f61992990080@github.com>
 <WXrPCY2jDlc-HuTHhaIFqQR-Sb-COTDvEcztxDV-daQ=.6f81a6d6-8eb5-4528-a7da-d82bfac453f0@github.com>
 <vcVyJO5UFU_F8cij0Q3L2LQfL7cxP-n5ed1bJuHIOew=.bf1ca81d-cf06-4b70-8613-cda992c7e40a@github.com>
Message-ID: <MNBVSDV1ka193aJOjOUQQGZPn8qVH48cYpLcNo9Ymgc=.34f4fb06-53ac-4052-a923-0c282218f070@github.com>

On Thu, 1 May 2025 01:15:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > I think throwing the SkippedException is the right way to go long term but I assume this shows as a reported failure in Mach5 and in the case of assumeTrue it does not result in a failure being reported?
> 
> That is correct, use of assumeTrue will skip the test (which is what we want) but it will be classified as aborted instead of skipped. Throwing jtreg.SkippedException however fails that test which isn't a good thing.

So I think it is important that  the reporting is addressed WRT SkippedException, especially in light of some of the discussions raised in previous threads for Mach5.

So in order to keep the Mach5 pipeline happy, I see the options is simply returning or use assumeTrue providing this does not create any additional reporting noise.  

It might be worthwhile creating a follow on bug to address this in the test, linking to the JtREG bug so that it does not get lost/forgotten

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2070240224

From liach at openjdk.org  Thu May  1 13:04:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 13:04:47 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
In-Reply-To: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
Message-ID: <dhJZfbBsKnkyOi4h8J6nOB1AhhAc67pZp82cB_Rr6Jk=.916994a4-0557-4043-b725-8c023272d76f@github.com>

On Thu, 1 May 2025 05:33:29 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 315:

> 313:      * <b>WARNING: The caller of this method shall relinquish and transfer the
> 314:      * ownership of the byte array to the callee</b>, since the later will not
> 315:      * make a copy.

I think we should add a note on why no copy is made - there may be multiple reads to the input array for decoding, so the input array must not be accessible by untrusted code, which can racily modify it. A side effect is that this array is simply reused if it's eligible to be the string content array, which is unfortunately abused in a few places in the JDK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2070244058

From alanb at openjdk.org  Thu May  1 12:43:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 May 2025 12:43:45 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win)
In-Reply-To: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
Message-ID: <MFX6Iut2tgrXA1o46mfds8VTnfQ21R7pX3Emeq1mcM4=.f443b869-a94f-4da2-a66d-1ff0edae83d3@github.com>

On Wed, 30 Apr 2025 23:38:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired.

I've added the "csr" label as we will need to create a CSR for this. It will need a release note too.

src/java.base/windows/classes/java/io/WinNTFileSystem.java line 45:

> 43: 
> 44:     private static final boolean DELETE_READONLY =
> 45:         Boolean.getBoolean("jdk.io.File.deleteReadOnly");

What would you think of allowDeleteReadOnlyFiles rather than deleteReadOnly?

src/java.base/windows/native/libjava/WinNTFileSystem_md.c line 665:

> 663:         BOOL attrSet = FALSE;
> 664:         if (deleteReadOnly && ((a & FILE_ATTRIBUTE_READONLY) != 0))
> 665:             attrSet = SetFileAttributesW(path, a & (~FILE_ATTRIBUTE_READONLY));

A small comment on the name "attrSet". It hints that it will be set to TRUE if the attribute is set whereas the use here is to mean that SetFileAttributesW has succeeded, a bit confusing because it's clearing the READONLY value, not setting it.  If you rename to something that has the word "modified" or "cleared" might be easy for future maintainers.

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

PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2844767305
PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2070223272
PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2070222588

From duke at openjdk.org  Thu May  1 13:06:50 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 1 May 2025 13:06:50 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v11]
In-Reply-To: <eIAbKE11RsBYYxLFsdl8mbp9K6FEZaJ0GrHxWWNbsEc=.39224a40-5b72-4e3f-b2fd-cb8226dd2f92@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <bY6wxELBjJnRQ5co73NgJC5baGtnY5UKezuQXCvYU5E=.82004266-7468-484d-a28c-85852d06f8d9@github.com>
 <eIAbKE11RsBYYxLFsdl8mbp9K6FEZaJ0GrHxWWNbsEc=.39224a40-5b72-4e3f-b2fd-cb8226dd2f92@github.com>
Message-ID: <b_BF-hOVcyul6ERad9IpcJqoqzhd_KvXQjc0duqeyGI=.fa116284-73e8-4695-912e-f5fccbc3da4b@github.com>

On Thu, 1 May 2025 12:56:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted?
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 488:
> 
>> 486:     /**
>> 487:      * {@inheritDoc CharSequence}
>> 488:      */
> 
> Suggestion:
> 
>      * {@inheritDoc CharSequence}
>      * @param srcBegin {@inheritDoc CharSequence}
>      * @param srcEnd   {@inheritDoc CharSequence}
>      * @param dst      {@inheritDoc CharSequence}
>      * @param dstBegin {@inheritDoc CharSequence}
>      * @throws IndexOutOfBoundsException {@inheritDoc CharSequence}
>      */
> 
> Let's aim for text parity for now; can you create a bug for Javadoc for this inheritDoc inconsistency?

I can open a bug report, but I think text parity makes no sense: There are lots of other places in OpenJDK where the short form is used already, so there will not be any benefit of text parity with just one other code location, but it will force use to open another JBS / PR once the bug is fixed to come back to the short form. So it brings just work but we gain nothing IMHO.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2070246526

From rriggs at openjdk.org  Thu May  1 13:41:01 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 1 May 2025 13:41:01 GMT
Subject: RFR: 8354334: Remove @ValueBased from ProcessHandle
Message-ID: <V5jHERjiEnnLdxXcb3XzBtYLRUKOYTWKAqttvWdtcdo=.a9bc8785-149f-465d-8882-59d61008a2d0@github.com>

Remove internal ValueBased annotation from the ProcessHandle interface declaration.
The implementation remains value based as described in the javadoc. 
Remove unnecessary "public" keyword in interfaces and cleanup javadoc.

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

Commit messages:
 - 8354334: Remove @ValueBased from ProcessHandle

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

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

From rriggs at openjdk.org  Thu May  1 13:55:46 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 1 May 2025 13:55:46 GMT
Subject: RFR: 8356021: Use Double::hashCode in java.util.Locale::hashCode
In-Reply-To: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
References: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
Message-ID: <ahZq9FgLjDCY-rUhZEptP6qMgfzQYWUp2SDSybsm8dc=.fc91b02a-340d-4fde-af76-95dc3d1bdc57@github.com>

On Wed, 30 Apr 2025 18:01:08 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to #24959, java.util.Locale.hashCode can also make the same improvement.
> 
> Replace manual bitwise operations in hashCode implementations of java.util.Locale with Double::hashCode.

lgltm

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24971#pullrequestreview-2809829827

From liach at openjdk.org  Thu May  1 14:01:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 14:01:55 GMT
Subject: RFR: 8356021: Use Double::hashCode in java.util.Locale::hashCode
In-Reply-To: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
References: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
Message-ID: <t-F0z47daZdDhKEPS5QkWmUScRwUtzCB0bQk9whzRJc=.961ae188-ed08-49a0-aba4-f77fd92180e9@github.com>

On Wed, 30 Apr 2025 18:01:08 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to #24959, java.util.Locale.hashCode can also make the same improvement.
> 
> Replace manual bitwise operations in hashCode implementations of java.util.Locale with Double::hashCode.

Thanks for this cleanup, indeed equivalent.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24971#pullrequestreview-2809839693

From liach at openjdk.org  Thu May  1 14:02:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 14:02:46 GMT
Subject: RFR: 8354334: Remove @ValueBased from ProcessHandle
In-Reply-To: <V5jHERjiEnnLdxXcb3XzBtYLRUKOYTWKAqttvWdtcdo=.a9bc8785-149f-465d-8882-59d61008a2d0@github.com>
References: <V5jHERjiEnnLdxXcb3XzBtYLRUKOYTWKAqttvWdtcdo=.a9bc8785-149f-465d-8882-59d61008a2d0@github.com>
Message-ID: <sxdZ4dwukVweinrXxBNP6Kdi013JMqkXnoGOzrr-I9s=.d4d83f2f-829c-4195-99d0-101b297902c2@github.com>

On Thu, 1 May 2025 13:36:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove internal ValueBased annotation from the ProcessHandle interface declaration.
> The implementation remains value based as described in the javadoc. 
> Remove unnecessary "public" keyword in interfaces and cleanup javadoc.

Good cleanup, now interfaces are no longer identity or value.

src/java.base/share/classes/java/lang/ProcessHandle.java line 287:

> 285:      * {@link java.util.concurrent.Future#get() wait} for it to terminate.
> 286:      * {@link java.util.concurrent.Future#cancel(boolean) Cancelling}
> 287:      * the {@linkplain CompletableFuture CompletableFuture} does not affect the Process.

Suggestion:

     * the {@linkplain CompletableFuture} does not affect the Process.

is sufficient.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24986#pullrequestreview-2809842025
PR Review Comment: https://git.openjdk.org/jdk/pull/24986#discussion_r2070303153

From duke at openjdk.org  Thu May  1 14:15:48 2025
From: duke at openjdk.org (Hendrik Schick)
Date: Thu, 1 May 2025 14:15:48 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder
In-Reply-To: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
Message-ID: <uvPgmPTcu_5YBB0kZSRiR6lE8wVcwn-HT0wYd6o2eW0=.fbc35751-5873-4d01-b986-06ea211cfce1@github.com>

On Wed, 30 Apr 2025 14:12:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
> Support methods are static, designed to pass all values as arguments and return a value.
> 
> The value byte array is reallocated under 3 conditions:
> - Increasing the capacity with the same encoder
> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
> - Inflation with the same capacity
> 
> Added StressSBTest to exercise public instance methods of StringBuilder.

test/jdk/java/lang/StringBuilder/StringBuilderRepeat.java line 110:

> 108:         String expected = "repeat233333233333-2-3-3-3-3-3\u2461\u2462\u2462\u2462\u2462\u2462\u2461\u2462\u2462\u2462\u2462\u2462-\u2461-\u2462-\u2462-\u2462-\u2462-\u2462abcabcabc" +
> 109:                           "nullnullnullnullnullnullnullnullnullnullnullnull";
> 110:         assertEquals(expected, sb.toString());

copyright year update missing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2070317617

From weijun at openjdk.org  Thu May  1 14:50:31 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 May 2025 14:50:31 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5]
In-Reply-To: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
Message-ID: <To8P9zSROG54ayME3D-98HIN0qqjfORNadZD8GA4R4I=.440e00b9-9f46-4b0a-ac0f-14612be358e2@github.com>

> Finalize the KDF API.

Weijun Wang 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
 - add a positive debug log and update exception message
 - enhancing exception messages and debug outputs
 - update @since tags as required by JEP 12
 - add enum back
 - the change

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

Changes: https://git.openjdk.org/jdk/pull/24520/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=04
  Stats: 206 lines in 17 files changed: 158 ins; 29 del; 19 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 vromero at openjdk.org  Thu May  1 15:06:06 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 1 May 2025 15:06:06 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API
In-Reply-To: <k0YoPCbK1q_hpxN0e023-_Nk5rpvRjywcuthI9uzAPg=.82a77a31-ff44-413c-8596-da9b2da03f19@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <k0YoPCbK1q_hpxN0e023-_Nk5rpvRjywcuthI9uzAPg=.82a77a31-ff44-413c-8596-da9b2da03f19@github.com>
Message-ID: <IolGhIMvxlSQSJ0b75BiQIMhywgGm3StuvVOCYOZMXU=.532de416-445c-4a29-bcb2-b8141f5c1056@github.com>

On Fri, 18 Apr 2025 02:32:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 4253:
> 
>> 4251: 
>> 4252: # lint: identity
>> 4253: compiler.warn.attempt.to.synchronize.on.instance.of.value.based.class2=\
> 
> How is this different from the message with no 2 suffix? Is there a reason why one localization entry is required for one type of lint?

the requirement is for the identity lint warning to be an alias of the synchronization warning

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2053222093

From liach at openjdk.org  Thu May  1 15:06:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 15:06:05 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <k0YoPCbK1q_hpxN0e023-_Nk5rpvRjywcuthI9uzAPg=.82a77a31-ff44-413c-8596-da9b2da03f19@github.com>

On Fri, 18 Apr 2025 00:06:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 1:

> 1: /*

Need to add handling of `RequiresIdentity` in `createAnnotation`

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 4253:

> 4251: 
> 4252: # lint: identity
> 4253: compiler.warn.attempt.to.synchronize.on.instance.of.value.based.class2=\

How is this different from the message with no 2 suffix? Is there a reason why one localization entry is required for one type of lint?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2049917728
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2049921677

From vromero at openjdk.org  Thu May  1 15:06:04 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 1 May 2025 15:06:04 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API
Message-ID: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>

This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.

For more details please refer to the complete description in the corresponding JIRA entry [1]

TIA

[1] https://bugs.openjdk.org/browse/JDK-8354556

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

Commit messages:
 - final adjustments
 - additional refactorings
 - removing unneeded changes
 - more refactorings
 - more refactorings and tests
 - refactoring
 - refactoring
 - covering more cases plus refactoring in order to simplify the code
 - Merge branch 'JDK-8354556' of https://github.com/vicente-romero-oracle/jdk into JDK-8354556
 - additional coverage for other uses of types
 - ... and 11 more: https://git.openjdk.org/jdk/compare/4dd64b49...5e3acc92

Changes: https://git.openjdk.org/jdk/pull/24746/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354556
  Stats: 495 lines in 25 files changed: 469 ins; 6 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

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

From liach at openjdk.org  Thu May  1 15:44:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 15:44:53 GMT
Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe
 [v2]
In-Reply-To: <0aX2lfNajbJtjO0xDd2bia76z8Vmcnbv2rnsIeLsucI=.0d730be1-f035-4ac4-bffb-692f2c89d88c@github.com>
References: <NLQLZm3c6l5ympapbv_5zWH8rNo8zhGchZrvq7hie9k=.e5e8b256-1a9c-42c0-ac58-8b6416937f39@github.com>
 <0aX2lfNajbJtjO0xDd2bia76z8Vmcnbv2rnsIeLsucI=.0d730be1-f035-4ac4-bffb-692f2c89d88c@github.com>
Message-ID: <9waxLSP10cwzA8b5lKJjSfnELxy6TcQg5U7feCkE3X0=.253d4943-09f9-4059-bc3b-cbacbae33a9d@github.com>

On Wed, 30 Apr 2025 23:02:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Add a test case, fails isWrapperInstance on mainline
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/mhp-wrapper-check-async
>  - 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe

Re jai for repeating: do we want this repeat for a single run or all tier1 runs (which I will use junit RepeatedTest)

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

PR Comment: https://git.openjdk.org/jdk/pull/23757#issuecomment-2845095159

From jpai at openjdk.org  Thu May  1 15:37:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 1 May 2025 15:37:52 GMT
Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe
 [v2]
In-Reply-To: <0aX2lfNajbJtjO0xDd2bia76z8Vmcnbv2rnsIeLsucI=.0d730be1-f035-4ac4-bffb-692f2c89d88c@github.com>
References: <NLQLZm3c6l5ympapbv_5zWH8rNo8zhGchZrvq7hie9k=.e5e8b256-1a9c-42c0-ac58-8b6416937f39@github.com>
 <0aX2lfNajbJtjO0xDd2bia76z8Vmcnbv2rnsIeLsucI=.0d730be1-f035-4ac4-bffb-692f2c89d88c@github.com>
Message-ID: <dCxMBzVl40fXyj8tpiL5qIQVOr6F4DaZ5flG2oa77jU=.7dc1ff41-dff8-4fbc-8084-2b503efb466e@github.com>

On Wed, 30 Apr 2025 23:02:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Add a test case, fails isWrapperInstance on mainline
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/mhp-wrapper-check-async
>  - 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe

Thank you Chen for adding the test. The test looks OK to me.

Please add `8350549` to the `@bug` in the test definition.

I think a brief comment on the test method would make it easier to understand what it does. Would you consider adding a comment, something like:


/**
 * The test verifies that MethodHandleProxies.asInterfaceInstance() and
 * MethodHandleProxies.isWrapperInstance() work as expected when invoked concurrently.
 */



Finally, given the nature of this new test, I think it would be good to have it run in our CI with a test repeat of around 50 to be sure that it doesn't fail intermittently.

test/jdk/java/lang/invoke/MethodHandleProxies/BasicTest.java line 275:

> 273:                 .limit(100)
> 274:                 .forEach(inst -> assertTrue(MethodHandleProxies.isWrapperInstance(inst),
> 275:                         () -> Objects.toIdentityString(inst)));

Nit - the failure message (if at all it fails for any reason) could perhaps be:


Objects.toIdentityString(inst) + " was expected to be a wrapper instance, but isn't"

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

PR Review: https://git.openjdk.org/jdk/pull/23757#pullrequestreview-2810048465
PR Review Comment: https://git.openjdk.org/jdk/pull/23757#discussion_r2070418275

From swen at openjdk.org  Thu May  1 15:49:53 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 1 May 2025 15:49:53 GMT
Subject: Integrated: 8356021: Use Double::hashCode in
 java.util.Locale::hashCode
In-Reply-To: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
References: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
Message-ID: <oVLrM8_PSiIa83nY13nrBKPGBM13bVnOmiaIiYKcNt8=.f61becd6-edde-45fb-bd81-486df9aee5c1@github.com>

On Wed, 30 Apr 2025 18:01:08 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to #24959, java.util.Locale.hashCode can also make the same improvement.
> 
> Replace manual bitwise operations in hashCode implementations of java.util.Locale with Double::hashCode.

This pull request has now been integrated.

Changeset: 2ad639f1
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ad639f1b33fcd8e218e8ad549caf32024a36cb2
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8356021: Use Double::hashCode in java.util.Locale::hashCode

Reviewed-by: rriggs, liach

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

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

From bpb at openjdk.org  Thu May  1 15:57:46 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 1 May 2025 15:57:46 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win)
In-Reply-To: <MFX6Iut2tgrXA1o46mfds8VTnfQ21R7pX3Emeq1mcM4=.f443b869-a94f-4da2-a66d-1ff0edae83d3@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <MFX6Iut2tgrXA1o46mfds8VTnfQ21R7pX3Emeq1mcM4=.f443b869-a94f-4da2-a66d-1ff0edae83d3@github.com>
Message-ID: <aGLS3zvwS5l6zGtpj0kDWWWePwRg_U7d__XEJwaMK2M=.bf99ce14-10a0-497a-b1da-e05021da28aa@github.com>

On Thu, 1 May 2025 12:40:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It will need a release note too.

The issue is already so labelled.

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

PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2845119678

From liach at openjdk.org  Thu May  1 14:39:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 14:39:53 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version [v7]
In-Reply-To: <qLyzxhjRin1N7OIh1kUfAGA7dECwURIxCIpK3FPA6iw=.cdc6fbb1-040a-4086-a3e4-25a832d3ac5e@github.com>
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
 <qLyzxhjRin1N7OIh1kUfAGA7dECwURIxCIpK3FPA6iw=.cdc6fbb1-040a-4086-a3e4-25a832d3ac5e@github.com>
Message-ID: <AQUMoVoq2kb0aRQCAF_UJ5sn57oQqFFb-qOQYg2kDR8=.54ba3b25-bf1b-457b-b3e7-2c020040edfb@github.com>

On Wed, 30 Apr 2025 22:12:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Take the class file version to reject flags not yet defined, redefined, or obsoleted. This is useful for clients like javap to report the correct undefined flags for different class file versions.
>> 
>> A preparatory patch for javap to pass around the ClassFileFormatVersion to parse flags is available at #24955.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-cffv-parse
>  - review: improve comments about implicit null checks
>  - Merge branch 'fix/javap-cffv-access-flags' into feature/af-cffv-parse
>  - Adapt the location APIs
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/javap-cffv-access-flags
>  - 8355956: Prepare javap for class file format aware access flag parsing
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Explicit imports
>  - Wording updates
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/e36756b2...b1cf4ebb

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24760#issuecomment-2844964939

From liach at openjdk.org  Thu May  1 14:39:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 14:39:53 GMT
Subject: Integrated: 8297271: AccessFlag.maskToAccessFlags should be specific
 to class file version
In-Reply-To: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
Message-ID: <TIyZgj-5UddPVAXAVua-506zApXajfZ_NQJUiiNijgQ=.8f074c4d-e41e-4b86-b44d-bf289a03a71d@github.com>

On Fri, 18 Apr 2025 20:33:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> Take the class file version to reject flags not yet defined, redefined, or obsoleted. This is useful for clients like javap to report the correct undefined flags for different class file versions.
> 
> A preparatory patch for javap to pass around the ClassFileFormatVersion to parse flags is available at #24955.

This pull request has now been integrated.

Changeset: bee273d6
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bee273d6b4e34692952d4e7474ab72ee5c54e33a
Stats:     159 lines in 10 files changed: 99 ins; 23 del; 37 mod

8297271: AccessFlag.maskToAccessFlags should be specific to class file version

Reviewed-by: rriggs

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

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

From duke at openjdk.org  Thu May  1 15:05:48 2025
From: duke at openjdk.org (Jason Mehrens)
Date: Thu, 1 May 2025 15:05:48 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win)
In-Reply-To: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
Message-ID: <PITQZ9SSNnunrp2IPCE932bcJI9cyJo62HrXVcfht0A=.4499443b-5696-4c04-9eb8-ed91cc2b69fb@github.com>

On Wed, 30 Apr 2025 23:38:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired.

Will the new property will also change behavior of java.io.File.deleteOnExit() and java.nio.file.StandardOpenOption.DELETE_ON_CLOSE? Might want to talk about that in the CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2845018199

From bpb at openjdk.org  Thu May  1 15:57:48 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 1 May 2025 15:57:48 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win)
In-Reply-To: <PITQZ9SSNnunrp2IPCE932bcJI9cyJo62HrXVcfht0A=.4499443b-5696-4c04-9eb8-ed91cc2b69fb@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <PITQZ9SSNnunrp2IPCE932bcJI9cyJo62HrXVcfht0A=.4499443b-5696-4c04-9eb8-ed91cc2b69fb@github.com>
Message-ID: <GBUfa2OtdXyYb7R4VorQ5eiKxgI1jrN68KRGa6ncQZA=.4072e015-5ce2-4e5e-a75c-7a2a200b8ee2@github.com>

On Thu, 1 May 2025 15:03:02 GMT, Jason Mehrens <duke at openjdk.org> wrote:

> Will the new property will also change behavior of java.io.File.deleteOnExit()

Yes, as that calls `File.delete`.

> and java.nio.file.StandardOpenOption.DELETE_ON_CLOSE?

No.

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

PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2845125188

From alanb at openjdk.org  Thu May  1 16:18:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 May 2025 16:18:46 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win)
In-Reply-To: <GBUfa2OtdXyYb7R4VorQ5eiKxgI1jrN68KRGa6ncQZA=.4072e015-5ce2-4e5e-a75c-7a2a200b8ee2@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <PITQZ9SSNnunrp2IPCE932bcJI9cyJo62HrXVcfht0A=.4499443b-5696-4c04-9eb8-ed91cc2b69fb@github.com>
 <GBUfa2OtdXyYb7R4VorQ5eiKxgI1jrN68KRGa6ncQZA=.4072e015-5ce2-4e5e-a75c-7a2a200b8ee2@github.com>
Message-ID: <EviK-VuWwlRTLGntb6A3JEIMol4-jUidJqHaWT1oKHE=.d2169609-2654-4230-9ca2-22b5469ec1a4@github.com>

On Thu, 1 May 2025 15:54:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > Will the new property will also change behavior of java.io.File.deleteOnExit()
> 
> Yes, as that calls `File.delete`.

Jason's message is a reminder that we will need to find everything that might be accidentally depending on the behavior.

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

PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2845169530

From darcy at openjdk.org  Thu May  1 16:25:53 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 May 2025 16:25:53 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v11]
In-Reply-To: <b_BF-hOVcyul6ERad9IpcJqoqzhd_KvXQjc0duqeyGI=.fa116284-73e8-4695-912e-f5fccbc3da4b@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <bY6wxELBjJnRQ5co73NgJC5baGtnY5UKezuQXCvYU5E=.82004266-7468-484d-a28c-85852d06f8d9@github.com>
 <eIAbKE11RsBYYxLFsdl8mbp9K6FEZaJ0GrHxWWNbsEc=.39224a40-5b72-4e3f-b2fd-cb8226dd2f92@github.com>
 <b_BF-hOVcyul6ERad9IpcJqoqzhd_KvXQjc0duqeyGI=.fa116284-73e8-4695-912e-f5fccbc3da4b@github.com>
Message-ID: <2jc5ZuZmlzsOBJOD9VwObHfox_2VX8Dmy6AhasVXp3w=.4cabab81-4d24-453d-ab46-eb272f6e7c27@github.com>

On Thu, 1 May 2025 13:03:47 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 488:
>> 
>>> 486:     /**
>>> 487:      * {@inheritDoc CharSequence}
>>> 488:      */
>> 
>> Suggestion:
>> 
>>      * {@inheritDoc CharSequence}
>>      * @param srcBegin {@inheritDoc CharSequence}
>>      * @param srcEnd   {@inheritDoc CharSequence}
>>      * @param dst      {@inheritDoc CharSequence}
>>      * @param dstBegin {@inheritDoc CharSequence}
>>      * @throws IndexOutOfBoundsException {@inheritDoc CharSequence}
>>      */
>> 
>> Let's aim for text parity for now; can you create a bug for Javadoc for this inheritDoc inconsistency?
>
> I can open a bug report, but I think text parity makes no sense: There are lots of other places in OpenJDK where the short form is used already, so there will not be any benefit of text parity with just one other code location, but it will force us to open another JBS / PR once the bug is fixed to come back to the short form. So it brings just work but we gain nothing IMHO.

There are subtleties and perhaps surprises in `@inheritDoc`, but that doesn't necessarily imply the current behavior is buggy.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2070475122

From smarks at openjdk.org  Thu May  1 16:57:53 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 1 May 2025 16:57:53 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v5]
In-Reply-To: <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <dFfo7XWntOoKDqWbOSksw2xon3geOvm2h7WuLsodIU0=.6480d447-b14b-43ea-a673-f36e7cbed4fa@github.com>
 <R26A-RFOkbja1bnImimPwn63l0Ey3wceWkCsJg1Jox4=.5621fccc-d59e-4a51-88e9-1c28d9ae9b86@github.com>
 <cNouC_Qp5yZHSyxMdZfBkmprp60u0UPlBS8kL9AVhz0=.4d085a45-cb66-4656-8ba2-41944478c989@github.com>
 <GENBQaAlYVOW6PdXkzHSCIgUIEbVMzMj4_s-E7YLD1c=.125d5f41-50bc-4e0c-befc-f2f7da3eb94e@github.com>
 <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
 <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>
Message-ID: <k_WmWojaK6sUQYgs_a_wfnU1hBnTJb23k4avXhPI8pg=.ecc7d452-0ba0-420a-8c11-443d60c76df3@github.com>

On Thu, 1 May 2025 09:51:41 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Anyway you need to merge master first to test `stdin.encoding`.
>
> `stdin.encoding` seems to work as intended in Windows for Japanese. (I managed to get the Windows binary of my PR) No need to change. (I wish the constructors of `InputStreamReader` and `Scanner` used `stdin.encoding` instead of UTF-8 for `System.in` by defaultI) Sorry to have bothered you.

Hello @tats-u , there is no bother, I appreciate you looking at this.

The addition of `stdin.encoding` in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703) (#24738) happened very quickly. I worked with @naotoj and @AlanBateman on it and we think it does the right thing, but there are many Windows configurations that we don't have the opportunity to test, so more feedback is helpful.

Initially it would be good to understand if `stdin.encoding` is specified and implemented correctly, and whether it provides the right behavior for `java.lang.IO` in JEP 512.

In the future we can consider additional uses of `stdin.encoding` in other parts of the JDK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070508985

From bpb at openjdk.org  Thu May  1 17:07:45 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 1 May 2025 17:07:45 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win)
In-Reply-To: <EviK-VuWwlRTLGntb6A3JEIMol4-jUidJqHaWT1oKHE=.d2169609-2654-4230-9ca2-22b5469ec1a4@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <PITQZ9SSNnunrp2IPCE932bcJI9cyJo62HrXVcfht0A=.4499443b-5696-4c04-9eb8-ed91cc2b69fb@github.com>
 <GBUfa2OtdXyYb7R4VorQ5eiKxgI1jrN68KRGa6ncQZA=.4072e015-5ce2-4e5e-a75c-7a2a200b8ee2@github.com>
 <EviK-VuWwlRTLGntb6A3JEIMol4-jUidJqHaWT1oKHE=.d2169609-2654-4230-9ca2-22b5469ec1a4@github.com>
Message-ID: <xpuXWiOWzgPfsjc91BM4s_JlqLw24s_04s-LWeAemcw=.e9db92bb-525d-403b-8ca4-976b229164a8@github.com>

On Thu, 1 May 2025 16:16:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> [...] we will need to find everything that might be accidentally depending on the behavior.

So far I found only `SetAccess` but there is more testing to do, as well as code scanning.

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

PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2845262183

From jvernee at openjdk.org  Thu May  1 16:58:47 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 May 2025 16:58:47 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v6]
In-Reply-To: <CyH1T3cFMsCqQwUFNMULG7xhS9UPG7tkuZaNkcdxtsE=.a33b32c4-8652-4897-b545-dfbc10444955@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
 <LmQ_Iz6vrttjTx8A737pciH9mhZt3xdWZOplr4sLvEY=.d5943d92-1d5f-4f6a-a132-10bb8766f74a@github.com>
 <CyH1T3cFMsCqQwUFNMULG7xhS9UPG7tkuZaNkcdxtsE=.a33b32c4-8652-4897-b545-dfbc10444955@github.com>
Message-ID: <XX-NZMP7xmvmyexTYvVqzG19m2CfxpilELcW9P-qZOI=.49b739cf-e6f7-4c6b-af67-ea6d5e24ed69@github.com>

On Thu, 1 May 2025 10:20:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 163:
>> 
>>> 161:                     lock.unlock();
>>> 162:                 }
>>> 163:                 Reference.reachabilityFence(arena);
>> 
>> I'm not sure this is enough to keep the automatic arena alive. If the client lets the Frame arena go out of scope w/o calling close, then `arena` will become unreachable, but some segments created by the Frame arena might still be reachable. To be more correct, I think `Frame` should add a "close action" to its confined arena which keeps the outer automatic arena alive. This can be done, for instance, by passing a close action to the `reinterpret` call:
>> 
>> 
>> frame = new SlicingAllocator(frameSegment.reinterpret(confinedArena, () -> Reference.reachabilityFence(arena)));
>> 
>> 
>> The close action is installed in the `MemorySession` object of `confinedArena` -- which is then attached to all segments returned by `Frame` -- thus keeping the automatic arena alive.
>
> (if you agree with this analysis, perhaps adding an extra stress test, or tweaking one of the existing stress tests to check this could also be useful)

I've thought about it a bit, and I think adding a cleanup action to the reinterpret call is indeed the only fool proof way to add a link back to the parent segment. MemorySegment is what gives a user access to the memory (almost like an access token), so the memory needs to be kept alive through the MS. MS has a reference to its scope, which can then reference the original scope through a cleanup action.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2070510278

From joehw at openjdk.org  Thu May  1 17:07:56 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 1 May 2025 17:07:56 GMT
Subject: Integrated: 8354084: Streamline XPath API's extension function control
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: <PR5Xaosw4B9eKcFzCJYeCXmLSZPENo7Z-MD2fJiwqs4=.2c5b73cd-935f-4b42-9adc-470d13e41c55@github.com>

On Fri, 11 Apr 2025 23:05:51 GMT, Joe Wang <joehw at openjdk.org> 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).

This pull request has now been integrated.

Changeset: cf0db963
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf0db96314863376254bacbff4eefd13e3527707
Stats:     464 lines in 9 files changed: 211 ins; 241 del; 12 mod

8354084: Streamline XPath API's extension function control

Reviewed-by: rriggs, naoto

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

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

From duke at openjdk.org  Thu May  1 17:20:49 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 1 May 2025 17:20:49 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v11]
In-Reply-To: <2jc5ZuZmlzsOBJOD9VwObHfox_2VX8Dmy6AhasVXp3w=.4cabab81-4d24-453d-ab46-eb272f6e7c27@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <bY6wxELBjJnRQ5co73NgJC5baGtnY5UKezuQXCvYU5E=.82004266-7468-484d-a28c-85852d06f8d9@github.com>
 <eIAbKE11RsBYYxLFsdl8mbp9K6FEZaJ0GrHxWWNbsEc=.39224a40-5b72-4e3f-b2fd-cb8226dd2f92@github.com>
 <b_BF-hOVcyul6ERad9IpcJqoqzhd_KvXQjc0duqeyGI=.fa116284-73e8-4695-912e-f5fccbc3da4b@github.com>
 <2jc5ZuZmlzsOBJOD9VwObHfox_2VX8Dmy6AhasVXp3w=.4cabab81-4d24-453d-ab46-eb272f6e7c27@github.com>
Message-ID: <LSOrFyZ6177AukhxK4GbbP3dNm2ekhGo6gfjhQEct3o=.ac3069f9-1905-4c9e-8b4a-3e725ed57476@github.com>

On Thu, 1 May 2025 16:23:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> I can open a bug report, but I think text parity makes no sense: There are lots of other places in OpenJDK where the short form is used already, so there will not be any benefit of text parity with just one other code location, but it will force us to open another JBS / PR once the bug is fixed to come back to the short form. So it brings just work but we gain nothing IMHO.
>
> There are subtleties and perhaps surprises in `@inheritDoc`, but that doesn't necessarily imply the current behavior is buggy.

So it is actually *wanted* behavior that in one situation the text *is* inherited, but at `String.java` no text is inherited at all? ? Could not find any hint about that in the JavaDoc manual.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2070545048

From jvernee at openjdk.org  Thu May  1 17:21:45 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 May 2025 17:21:45 GMT
Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe
 [v3]
In-Reply-To: <hDsroOi-rhG1YVFGLduWu26mihsGFEn8TCqLwVg4y-c=.a18ff573-4af6-428c-b37d-6a24900c22c0@github.com>
References: <NLQLZm3c6l5ympapbv_5zWH8rNo8zhGchZrvq7hie9k=.e5e8b256-1a9c-42c0-ac58-8b6416937f39@github.com>
 <hDsroOi-rhG1YVFGLduWu26mihsGFEn8TCqLwVg4y-c=.a18ff573-4af6-428c-b37d-6a24900c22c0@github.com>
Message-ID: <AIdCvSDjkAECBYGSK1feaL84q0K-uFkaliT8luWlqC0=.dbb3bf7a-bed2-4018-bbf7-3780bcee1693@github.com>

On Thu, 1 May 2025 16:34:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions

Changes look good. Thanks!

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23757#pullrequestreview-2810276387

From darcy at openjdk.org  Thu May  1 17:29:54 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 May 2025 17:29:54 GMT
Subject: RFR: 8354424: java/util/logging/LoggingDeadlock5.java fails
 intermittently in tier6 [v2]
In-Reply-To: <yBLKmHWh1HQhifpDB4SvF6Usl2DgbBl4jWhAcdv9-r8=.9098b4ba-805d-4809-8e24-7dd6ca15e481@github.com>
References: <JmPlcF2wXA7NfNRuwkPGlQ5RxM0H6DfUkK45goy_WOk=.27d2ca0b-664f-4b40-bdd5-b1f8be2b520b@github.com>
 <i_2BsViKtsMr0DoOPdnGoySooe7tVX2u_BC2uW8WD-c=.76dff61f-3ff3-4ef8-ad2c-728ce3006d0d@github.com>
 <p74WIehgsYcB441BtpTl4mhPnDiqbhKG5kWX1aHiDls=.e71a3fe4-bdcb-452b-aead-03d7add663fe@github.com>
 <RtT6X_x52Mf31f9mAZgCzNHdFTVF3AbHQy-OmDBrD5k=.483b54c4-25e2-423f-9f1c-f08eb1f7660d@github.com>
 <yBLKmHWh1HQhifpDB4SvF6Usl2DgbBl4jWhAcdv9-r8=.9098b4ba-805d-4809-8e24-7dd6ca15e481@github.com>
Message-ID: <yuK7gKagEHHz_56Q3jFl3ekDRjd6QTxZZqfMhhAhfWI=.7013e541-f1b6-4129-9c47-dbfc198a6192@github.com>

On Thu, 24 Apr 2025 16:24:53 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Hi Joe, yes `adjustTimeout` will scale based on the jtreg timeout factor. I believe the behaviour is to multiply whatever hardcoded timeout is passed by the timeout factor.
>> On lower tiers, in our CI, I beleive it means the test will have to wait for 8s before it can assert that a deadlock is detected. That should be way off the default jtreg timeout - which IIRC is 480s on lower tiers.
>
> Note, the timeout factor also adjusts the jtreg timeout for the entire test. The adjustTimeout() method allows internal test timeouts to scale along with the jtreg timeout.

> Hi Joe, yes `adjustTimeout` will scale based on the jtreg timeout factor. I believe the behaviour is to multiply whatever hardcoded timeout is passed by the timeout factor. On lower tiers, in our CI, I beleive it means the test will have to wait for 8s before it can assert that a deadlock is detected. That should be way off the default jtreg timeout - which IIRC is 480s on lower tiers.

Catching up on PR comments, to make my concerns more explicit: it is best is we don't pessimize the common case of increasing the _minimum_ run time of the test in order to make the test more robust in highly-contended situations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24687#discussion_r2070554333

From naoto at openjdk.org  Thu May  1 16:29:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 May 2025 16:29:50 GMT
Subject: RFR: 8356021: Use Double::hashCode in java.util.Locale::hashCode
In-Reply-To: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
References: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
Message-ID: <Axi4jX3mW1MR-2PyX-XIkWaxBZukzivV_aXtvkwrGok=.c75649a5-b82e-4e7d-a2d1-1317b5232705@github.com>

On Wed, 30 Apr 2025 18:01:08 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to #24959, java.util.Locale.hashCode can also make the same improvement.
> 
> Replace manual bitwise operations in hashCode implementations of java.util.Locale with Double::hashCode.

Thanks for the fix. Even though the fix is trivial and small, please keep the PR open at least for 24 hours so that every region of the globe can see the fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/24971#issuecomment-2845189930

From liach at openjdk.org  Thu May  1 16:34:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 16:34:14 GMT
Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe
 [v3]
In-Reply-To: <NLQLZm3c6l5ympapbv_5zWH8rNo8zhGchZrvq7hie9k=.e5e8b256-1a9c-42c0-ac58-8b6416937f39@github.com>
References: <NLQLZm3c6l5ympapbv_5zWH8rNo8zhGchZrvq7hie9k=.e5e8b256-1a9c-42c0-ac58-8b6416937f39@github.com>
Message-ID: <hDsroOi-rhG1YVFGLduWu26mihsGFEn8TCqLwVg4y-c=.a18ff573-4af6-428c-b37d-6a24900c22c0@github.com>

> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Review suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23757/files
  - new: https://git.openjdk.org/jdk/pull/23757/files/60404635..eb405dd9

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

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

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

From smarks at openjdk.org  Thu May  1 17:54:47 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 1 May 2025 17:54:47 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
Message-ID: <DXQ8sulRSIa5sQJaZU9UM7NF8AHkRsViO6D9b0rI2Vg=.32fa69ad-94bf-4453-97e8-22a6802c8b08@github.com>

On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter <bpb at openjdk.org> 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: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test

src/java.base/share/classes/java/io/Reader.java line 408:

> 406:      * <p> This method works as if invoking it were equivalent to evaluating
> 407:      * the expression:
> 408:      * <blockquote>{@linkplain #readAllChars()}.lines().toList()</blockquote>

I think this is actually too specific, as it could imply the returned List is the exact implementation that is returned by Stream.toList(). It is in this implementation, but I could easily imagine another implementation that constructs the list a different way. It might be better to be descriptive here and say that the entire input is read and is split into lines (where "line" is defined as above) which are returned in an unmodifiable list. And then have "unmodifiable list" be a link to the Unmodifiable Lists section, something like "java/util/List.html#unmodifiable".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2070581767

From liach at openjdk.org  Thu May  1 17:38:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 17:38:43 GMT
Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe
 [v3]
In-Reply-To: <hDsroOi-rhG1YVFGLduWu26mihsGFEn8TCqLwVg4y-c=.a18ff573-4af6-428c-b37d-6a24900c22c0@github.com>
References: <NLQLZm3c6l5ympapbv_5zWH8rNo8zhGchZrvq7hie9k=.e5e8b256-1a9c-42c0-ac58-8b6416937f39@github.com>
 <hDsroOi-rhG1YVFGLduWu26mihsGFEn8TCqLwVg4y-c=.a18ff573-4af6-428c-b37d-6a24900c22c0@github.com>
Message-ID: <9j4Q0K-DT0X_lM2ysFJ-u17cbdHSmmsmCGWZu36CYJ0=.db78f2e1-d9a6-46c3-b9ce-294cdb301d56@github.com>

On Thu, 1 May 2025 16:34:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions

Thanks for the reviews. On baseline this new test has a 50% failure rate so we should be likely to trigger when running on all platforms. Missed the bug id in last push; pushed again, and please review again.

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

PR Comment: https://git.openjdk.org/jdk/pull/23757#issuecomment-2845325170

From jlahoda at openjdk.org  Thu May  1 17:44:47 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 May 2025 17:44:47 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v7]
In-Reply-To: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
Message-ID: <79mjbgCz8a1HC6r0_an5GwcY6lWssji50XWSoV1lrlM=.5fea494d-0bad-4e73-a482-090f47663302@github.com>

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:

 - Merge branch 'master' into finalize-concise-source-files
 - Merge branch 'master' into finalize-concise-source-files
 - Merge remote-tracking branch 'origin/finalize-concise-source-files' into finalize-concise-source-files
 - Add clause about handling of malformed/unmappable bytes.
 - Rewrite bits about charset decoding, removing mention of "internal objects."
 - Use local variable for System.out in print().
 - Reverting test commit.
   
   This reverts commit 7047cf007cc7de937aa21e96125083ee92932692.
 - Fixing tests.
 - Updating copyright year.
 - Adding bug number to tests.
 - ... and 28 more: https://git.openjdk.org/jdk/compare/6b553acb...3868019e

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

Changes: https://git.openjdk.org/jdk/pull/24438/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=06
  Stats: 1060 lines in 59 files changed: 336 ins; 585 del; 139 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 May  1 17:46:52 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 1 May 2025 17:46:52 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
Message-ID: <qk3aV4KUpOBhhCvEXdIJiHbo4xnd5mSKIViow1OYQUI=.c82e0c1f-eb78-45c4-bf05-aa7258e01ddf@github.com>

On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter <bpb at openjdk.org> 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: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test

src/java.base/share/classes/java/io/Reader.java line 405:

> 403:      * a carriage return followed immediately by a line feed, or by reaching the
> 404:      * end-of-file (EOF).
> 405:      *

I think the definition here should be copied from String.lines(), or it should refer to it. The main difference is that spec is explicit about a line being zero-or-more chars followed by a line terminator or one-or-more chars followed by EOF. This implies there is no blank line between a trailing line terminator and EOF.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2070573057

From jlahoda at openjdk.org  Thu May  1 17:48:22 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 May 2025 17:48:22 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v8]
In-Reply-To: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
Message-ID: <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>

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

  Updating copyright year.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24438/files
  - new: https://git.openjdk.org/jdk/pull/24438/files/3868019e..5d0a867f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=06-07

  Stats: 1 line in 1 file changed: 0 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 duke at openjdk.org  Thu May  1 18:17:50 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Thu, 1 May 2025 18:17:50 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java
In-Reply-To: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
Message-ID: <JGXmFCRE427w8BoiKYeD_YBb9vUp1Gy_JIxyTcMMpeQ=.d7dfb409-0041-4158-97e5-6a4157c7acb9@github.com>

On Thu, 6 Mar 2025 13:34:07 GMT, Oleksii Sylichenko <duke at openjdk.org> 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-2845409656

From bpb at openjdk.org  Thu May  1 18:31:37 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 1 May 2025 18:31:37 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v2]
In-Reply-To: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
Message-ID: <EKrY9T5mNrtBL1tJiinGY3RhsxWGKViiVibrXoe2CdA=.a0e546cb-bb4a-4ae1-9351-0e641114e1b7@github.com>

> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8355954: Address comments on naming in the PR

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24977/files
  - new: https://git.openjdk.org/jdk/pull/24977/files/84905743..efca3cf4

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

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

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

From naoto at openjdk.org  Thu May  1 17:44:48 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 May 2025 17:44:48 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v5]
In-Reply-To: <k_WmWojaK6sUQYgs_a_wfnU1hBnTJb23k4avXhPI8pg=.ecc7d452-0ba0-420a-8c11-443d60c76df3@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <dFfo7XWntOoKDqWbOSksw2xon3geOvm2h7WuLsodIU0=.6480d447-b14b-43ea-a673-f36e7cbed4fa@github.com>
 <R26A-RFOkbja1bnImimPwn63l0Ey3wceWkCsJg1Jox4=.5621fccc-d59e-4a51-88e9-1c28d9ae9b86@github.com>
 <cNouC_Qp5yZHSyxMdZfBkmprp60u0UPlBS8kL9AVhz0=.4d085a45-cb66-4656-8ba2-41944478c989@github.com>
 <GENBQaAlYVOW6PdXkzHSCIgUIEbVMzMj4_s-E7YLD1c=.125d5f41-50bc-4e0c-befc-f2f7da3eb94e@github.com>
 <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
 <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>
 <k_WmWojaK6sUQYgs_a_wfnU1hBnTJb23k4avXhPI8pg=.ecc7d452-0ba0-420a-8c11-443d60c76df3@github.com>
Message-ID: <Rvch_7UMKRSFCsJqbkDZEHYkHwhu9kvNqFb24QVVXBQ=.16c48f94-807e-4b42-9952-e341e24c28c4@github.com>

On Thu, 1 May 2025 16:55:06 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> `stdin.encoding` seems to work as intended in Windows for Japanese. (I managed to get the Windows binary of my PR) No need to change. (I wish the constructors of `InputStreamReader` and `Scanner` used `stdin.encoding` instead of UTF-8 for `System.in` by defaultI) Sorry to have bothered you.
>
> Hello @tats-u , there is no bother, I appreciate you looking at this.
> 
> The addition of `stdin.encoding` in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703) (#24738) happened very quickly. I worked with @naotoj and @AlanBateman on it and we think it does the right thing, but there are many Windows configurations that we don't have the opportunity to test, so more feedback is helpful.
> 
> Initially it would be good to understand if `stdin.encoding` is specified and implemented correctly, and whether it provides the right behavior for `java.lang.IO` in JEP 512.
> 
> In the future we can consider additional uses of `stdin.encoding` in other parts of the JDK.

`InputStreamReader` and `Scanner` taking `stdin.encoding` is an interesting idea, but would introduce compatiblity concerns. It would have been simpler if we had `stdin/out/err.encoding` system properties prior to JEP 400. 
As to testing on Windows, I would like to know how the Windows `UILanguage` affects these, afaik we only have tested on English Windows. Say how it works on Japanese Windows with English system locale. However, since we have not changed any existing behavior (from the code wise), I don't think we would see any issues.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070569424

From smarks at openjdk.org  Thu May  1 18:03:51 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 1 May 2025 18:03:51 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
Message-ID: <BB0nBKB-FnwqpRejR4nWVmFrLCcyH0S3-D0p1vJCEeM=.1ce0e0ad-8f0e-412b-b0b2-2f814a1a0fa5@github.com>

On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter <bpb at openjdk.org> 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: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test

src/java.base/share/classes/java/io/BufferedReader.java line 413:

> 411:      * <p> This method works as if invoking it were equivalent to evaluating
> 412:      * the expression:
> 413:      * <blockquote>{@linkplain #lines()}.toList()</blockquote>

I'd suggest avoiding being too specific here, as this implies that this method will invoke the `lines()` method which can be overridden by a subclass. One could have an argument about whether this indeed is implied by the "as if" wording but I think it would be preferable to avoid this. I also think we don't want to have this method depend on possible overridden methods, so that we can provide a future optimized implementation without breaking something. Thus I think most of this doc comment can be inherited form Reader, even though the implementation might be overridden.

src/java.base/share/classes/java/io/BufferedReader.java line 433:

> 431:     public List<String> readAllLines() throws IOException {
> 432:         try {
> 433:             return lines().toList();

I'd suggest not having this method's implementation depend on an overridable method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2070590867
PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2070591288

From vromero at openjdk.org  Thu May  1 18:32:00 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 1 May 2025 18:32:00 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v8]
In-Reply-To: <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>
Message-ID: <m4Ee1G4zMqDSM8ftPnlnPGTAr4_iDT7jOQgGF8F1S34=.789aa973-ef26-41a8-8d3b-d2597f2b874c@github.com>

On Thu, 1 May 2025 17:48:22 GMT, Jan Lahoda <jlahoda at openjdk.org> 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:
> 
>   Updating copyright year.

last changes lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24438#pullrequestreview-2810409833

From adinn at openjdk.org  Thu May  1 18:54:50 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 1 May 2025 18:54:50 GMT
Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner
 classes
In-Reply-To: <JQCL1DGBobBWQqWeX3Ykuw1nZOis5D8k6kEllWluE0s=.a089b081-da05-436c-b0f7-ec021887ea57@github.com>
References: <JQCL1DGBobBWQqWeX3Ykuw1nZOis5D8k6kEllWluE0s=.a089b081-da05-436c-b0f7-ec021887ea57@github.com>
Message-ID: <5vOdChaItphSz0dAvDqdniRjHRAAzeUBu2e7rxMkS54=.05079043-e02a-4853-891e-c7d34919af8d@github.com>

On Tue, 29 Apr 2025 22:59:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is a general fix for all the "points to a static field that may hold a different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330).
> 
> AOT-cached method handles quite often refer to the static fields in `MethodHandleImpl` or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. `CDSHeapVerifier` makes a very conservative check for such static fields, but sometimes gives false positives (as in the above two JBS issues)
> 
> In this PR, we AOT-initialize `MethodHandleImpl` and its inner classes. This is a more authentic snapshot of the state of `java.lang.invoke` during the assembly phase. We also avoid the need to add and maintain entries in the `cdsHeapVerifier.cpp` table.
> 
> I also added more code in `MethodHandleTest.java` to simulate potential usage patterns of `MethodHandle` by the Java core libraries. Hopefully this will reduce the likelihood for innocent core lib changes breaking the AOT assembly phase.

@iklam We have seen this problem with Red Hat deployments in jdk24 as well as jdk25-ea.

I'm saying that mostly for information. However, I do have to ask: If this is fixed for jdk25 is there any question of also fixing it in jdk24? I would be content to receive a no answer -- a similar issue with patch that could be backported from jdk26 -> jdk25 might be something to think about a bit more?

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

PR Comment: https://git.openjdk.org/jdk/pull/24956#issuecomment-2845492119

From bpb at openjdk.org  Thu May  1 18:31:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 1 May 2025 18:31:38 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v2]
In-Reply-To: <MFX6Iut2tgrXA1o46mfds8VTnfQ21R7pX3Emeq1mcM4=.f443b869-a94f-4da2-a66d-1ff0edae83d3@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <MFX6Iut2tgrXA1o46mfds8VTnfQ21R7pX3Emeq1mcM4=.f443b869-a94f-4da2-a66d-1ff0edae83d3@github.com>
Message-ID: <_5k1CPtAMmKlN2ZjGxsP7j6V_GQ77RziAbkh1avwSWE=.ba639ea9-ba14-482a-9bcd-97211c3c0b8c@github.com>

On Thu, 1 May 2025 12:40:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8355954: Address comments on naming in the PR
>
> src/java.base/windows/classes/java/io/WinNTFileSystem.java line 45:
> 
>> 43: 
>> 44:     private static final boolean DELETE_READONLY =
>> 45:         Boolean.getBoolean("jdk.io.File.deleteReadOnly");
> 
> What would you think of allowDeleteReadOnlyFiles rather than deleteReadOnly?

Sounds better. So changed in efca3cf.

> src/java.base/windows/native/libjava/WinNTFileSystem_md.c line 665:
> 
>> 663:         BOOL attrSet = FALSE;
>> 664:         if (deleteReadOnly && ((a & FILE_ATTRIBUTE_READONLY) != 0))
>> 665:             attrSet = SetFileAttributesW(path, a & (~FILE_ATTRIBUTE_READONLY));
> 
> A small comment on the name "attrSet". It hints that it will be set to TRUE if the attribute is set whereas the use here is to mean that SetFileAttributesW has succeeded, a bit confusing because it's clearing the READONLY value, not setting it.  If you rename to something that has the word "modified" or "cleared" might be easy for future maintainers.

Name updated in efca3cf.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2070627406
PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2070627002

From kbarrett at openjdk.org  Thu May  1 19:20:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 1 May 2025 19:20:48 GMT
Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed
 with "RuntimeException: MyObject is not found in test output" [v7]
In-Reply-To: <F-y8fi3UkBMMXJuu-VD-snbtfqLfjDDJz6PjbZcN08w=.3f4d4e34-557b-4b9f-9750-15739dde9256@github.com>
References: <Jcra20HpK4hJAr6O1VySmMukJHFGYEieEpvDVrlbxuI=.03ee416c-3568-4a66-be60-f6c17fed2188@github.com>
 <WQxKoz9WZ1LqIA-vfh-0Vn9n666F70jJf-1tfrmMrvg=.7a74b7b0-01ef-4add-8b99-b2dbc449342b@github.com>
 <1tGRJ4ejgEBN_prDxdLQajmtGU4whVg5OAH8ziKR3pQ=.9b4a8e19-0fec-43a3-a357-4f63d6f7078c@github.com>
 <F-y8fi3UkBMMXJuu-VD-snbtfqLfjDDJz6PjbZcN08w=.3f4d4e34-557b-4b9f-9750-15739dde9256@github.com>
Message-ID: <n3K5hWRf9dc1c9Uire0MXD5gXHhJY1ynp3RQnDIFY0M=.4cba3103-a8dc-40d1-9cbb-593cfe2ad59a@github.com>

On Wed, 30 Apr 2025 20:23:13 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> It spins until at least one `MyObject` has entered `finalize()` before proceeding to fetch the histogram.

My eyes must be going.  Somehow I read that as a `-1`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2070687204

From kbarrett at openjdk.org  Thu May  1 19:33:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 1 May 2025 19:33:48 GMT
Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed
 with "RuntimeException: MyObject is not found in test output" [v7]
In-Reply-To: <n3K5hWRf9dc1c9Uire0MXD5gXHhJY1ynp3RQnDIFY0M=.4cba3103-a8dc-40d1-9cbb-593cfe2ad59a@github.com>
References: <Jcra20HpK4hJAr6O1VySmMukJHFGYEieEpvDVrlbxuI=.03ee416c-3568-4a66-be60-f6c17fed2188@github.com>
 <WQxKoz9WZ1LqIA-vfh-0Vn9n666F70jJf-1tfrmMrvg=.7a74b7b0-01ef-4add-8b99-b2dbc449342b@github.com>
 <1tGRJ4ejgEBN_prDxdLQajmtGU4whVg5OAH8ziKR3pQ=.9b4a8e19-0fec-43a3-a357-4f63d6f7078c@github.com>
 <F-y8fi3UkBMMXJuu-VD-snbtfqLfjDDJz6PjbZcN08w=.3f4d4e34-557b-4b9f-9750-15739dde9256@github.com>
 <n3K5hWRf9dc1c9Uire0MXD5gXHhJY1ynp3RQnDIFY0M=.4cba3103-a8dc-40d1-9cbb-593cfe2ad59a@github.com>
Message-ID: <Ze2E351LQTEjcKfzj2JNAMbV8_4WyD-3M0imyAqFzhM=.66e28c3e-59ce-43f6-b9c5-0f180dbc6f81@github.com>

On Thu, 1 May 2025 19:17:42 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> It spins until at least one `MyObject` has entered `finalize()` before proceeding to fetch the histogram.
>
>> It spins until at least one `MyObject` has entered `finalize()` before proceeding to fetch the histogram.
> 
> My eyes must be going.  Somehow I read that as a `-1`.

I still think this loop isn't actually needed.  What the test is interested in is having final references in the
finalizer queue.  Waiting for reference processing does that.  Waiting for trappedCount to be non-zero
(really, waiting for 1, with more than one indicating a problem with the locking and possible failure to
keep the objects in the finalizer queue), isn't necessary for the remainder of the test to work.  I think
trappedCount isn't needed at all in the current version, and should either be removed or made useful in
some fashion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2070702444

From rriggs at openjdk.org  Thu May  1 19:22:48 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 1 May 2025 19:22:48 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v11]
In-Reply-To: <9LPHVgu_b1TQtHqykVY6XMl--dTbLSIZmdqim4hv-70=.8da0476c-c647-459a-b00c-520c42071457@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <ZVHyBZm88I2cLr48jaKClQSMCrbArdSDLXg21SAwqsw=.254e31ec-0f69-49fe-adce-7ea065a6d1d2@github.com>
 <9LPHVgu_b1TQtHqykVY6XMl--dTbLSIZmdqim4hv-70=.8da0476c-c647-459a-b00c-520c42071457@github.com>
Message-ID: <33QRkIdttGlAkEQOo1lBKm2j-2fgofs1OuaC9qk_-sU=.dd89a944-affc-4ac0-aa29-adadb5d030e1@github.com>

On Tue, 22 Apr 2025 16:51:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354724: Add Reader.readAllLines; test not yet updated
>
> src/java.base/share/classes/java/io/Reader.java line 403:
> 
>> 401:      * by any one of a line feed ('\n'), a carriage return ('\r'), a carriage
>> 402:      * return followed immediately by a line feed, or by reaching the
>> 403:      * end-of-file (EOF).
> 
> Reader is for reading characters so I think the starting line will say that is reads all remaining characters as lines of text.
> 
> In any case, I think you've enough here to help decide if a method should be added to Reader. I think the main observation is that it doesn't require Reader to be buffering.

The description of the method should be the same in Reader and BufferedReader with respect to the behavior, line break handling, etc. It should be possible to use {@inheritDoc} to re-use it in BufferedReader.
Except for the description of the implementation, that can be in an {@impSpec} paragraph.
The method is consuming characters from the stream, assembling lines and returning list.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2070687773

From vlivanov at openjdk.org  Thu May  1 18:29:50 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 1 May 2025 18:29:50 GMT
Subject: RFR: 8355698: JDK not supporting sleef could cause exception at
 runtime after JDK-8353786
In-Reply-To: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
Message-ID: <t3-LblM11MfXbtELuHBEddLiMvzJvXn1XRAgzTogEEg=.86147be4-7f53-429f-ab63-5bf35f100b3e@github.com>

On Mon, 28 Apr 2025 10:34:49 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> 
> Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a released jdk not supportting sleef (for any reason, e.g. low gcc version, intrinsic not supported, rvv not supported, and so on) runs on machine support vector operation (e.g. on riscv, it supports rvv), it can not call into sleef, but will not fail either, it falls back to java scalar version implementation.
> But after [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), it will cause an exception thrown at runtime.
> 
> This change the behaviour of existing jdk, and it should not throw exception anyway.
> 
> @iwanowww @RealFYang 
> 
> Thanks!

I want to understand the issue with missing entries in vector math native libraries first before making a decision how to proceed. 

> I don't think it's a build issue, the jdk vendor can choose to support it or not, it's just the way passing the information ( whether it's supported or not) are different.

Sorry, I don't get it. How does it affect the contents of the native library? JDK vendors do have an option to bundle the library or drop it from their distribution. But when SLEEF-based and SVML math libraries are built by JDK there's no distinction between entries being included in the library. If a vendor modifies make files or native library code, it's up to them to adjust JDK accordingly. Upstream JDK doesn't have to take such scenarios into account.

I looked through SVML and SLEEF-based vector math code and noticed there are some capability check [1] [2] [3] guarding library code. It means that if some library entry is missing, then the whole library is empty. Can you confirm it's the case you see?

[1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/linux/native/libjsvml/globals_vectorApiSupport_linux.S.inc#L35
[2] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/windows/native/libjsvml/globals_vectorApiSupport_windows.S.inc#L28
[3] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/unix/native/libsleef/lib/vector_math_rvv.c#L36

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

PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2845433084

From rriggs at openjdk.org  Thu May  1 19:26:47 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 1 May 2025 19:26:47 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java
In-Reply-To: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
Message-ID: <sS3HZ2aZsOqrm__NxCUeKvdCgwgnYXEP-4LxP7oN0fA=.69034e9c-a0ef-4842-a739-f95124523a0f@github.com>

On Thu, 6 Mar 2025 13:34:07 GMT, Oleksii Sylichenko <duke at openjdk.org> 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 ...

test/jdk/java/lang/ProcessBuilder/Basic.java line 1843:

> 1841:         //----------------------------------------------------------------
> 1842:         try {
> 1843:             String[] cmdp = Windows.is() ? new String[]{"cmd", "/c", "echo."} : new String[]{"echo"};

Why the extra "." in the echo string?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2070694582

From dfuchs at openjdk.org  Thu May  1 17:36:49 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 1 May 2025 17:36:49 GMT
Subject: RFR: 8354424: java/util/logging/LoggingDeadlock5.java fails
 intermittently in tier6 [v2]
In-Reply-To: <yuK7gKagEHHz_56Q3jFl3ekDRjd6QTxZZqfMhhAhfWI=.7013e541-f1b6-4129-9c47-dbfc198a6192@github.com>
References: <JmPlcF2wXA7NfNRuwkPGlQ5RxM0H6DfUkK45goy_WOk=.27d2ca0b-664f-4b40-bdd5-b1f8be2b520b@github.com>
 <i_2BsViKtsMr0DoOPdnGoySooe7tVX2u_BC2uW8WD-c=.76dff61f-3ff3-4ef8-ad2c-728ce3006d0d@github.com>
 <p74WIehgsYcB441BtpTl4mhPnDiqbhKG5kWX1aHiDls=.e71a3fe4-bdcb-452b-aead-03d7add663fe@github.com>
 <RtT6X_x52Mf31f9mAZgCzNHdFTVF3AbHQy-OmDBrD5k=.483b54c4-25e2-423f-9f1c-f08eb1f7660d@github.com>
 <yBLKmHWh1HQhifpDB4SvF6Usl2DgbBl4jWhAcdv9-r8=.9098b4ba-805d-4809-8e24-7dd6ca15e481@github.com>
 <yuK7gKagEHHz_56Q3jFl3ekDRjd6QTxZZqfMhhAhfWI=.7013e541-f1b6-4129-9c47-dbfc198a6192@github.com>
Message-ID: <ieBB3b4lH4YnHLKuGkDTv7v2j05w0bJCvFJLs2jArQY=.1d9f2a1f-1986-4744-a6b7-62b76b33f9a3@github.com>

On Thu, 1 May 2025 17:26:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Note, the timeout factor also adjusts the jtreg timeout for the entire test. The adjustTimeout() method allows internal test timeouts to scale along with the jtreg timeout.
>
>> Hi Joe, yes `adjustTimeout` will scale based on the jtreg timeout factor. I believe the behaviour is to multiply whatever hardcoded timeout is passed by the timeout factor. On lower tiers, in our CI, I beleive it means the test will have to wait for 8s before it can assert that a deadlock is detected. That should be way off the default jtreg timeout - which IIRC is 480s on lower tiers.
> 
> Catching up on PR comments, to make my concerns more explicit: it is best is we don't pessimize the common case of increasing the _minimum_ run time of the test in order to make the test more robust in highly-contended situations.

Right. But it's still way better than hard to diagnose intermittent failures. If this [the 2s x timeout factor minimum time] becomes an issue - I guess we could update the test to only test the case where there should no longer be a deadlock - and remove the self-test that proves that a deadlock would be detected if there was one.
That would need to be carried out in a different PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24687#discussion_r2070562152

From kbarrett at openjdk.org  Thu May  1 19:37:02 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 1 May 2025 19:37:02 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v13]
In-Reply-To: <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>
Message-ID: <_MaD4F7X83A_LevqwBFFnJ7vcXjNhT0k5CPU6dWxq9M=.54ae4358-d6dc-4c51-809e-62667b3330db@github.com>

On Tue, 18 Feb 2025 14:33:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer.
>> 
>> We can migrate DBBs to use `java.lang.ref.Cleaner`.
>> 
>> There are two pecularities during this rewrite.
>> 
>> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it.
>> 
>> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us.
>> 
>> Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. This is why we need another way to check progress that involves checking if cleaner has acted.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `java/nio java/io`
>>  - [x] Linux AArch64 server fastdebug, `java/nio java/io`
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A bit more comments

FYI, I've been working on some more ideas here.  I hope to have more to report in the next couple of days.

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

PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2845588548

From liach at openjdk.org  Thu May  1 18:57:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 18:57:50 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v8]
In-Reply-To: <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>
Message-ID: <i0nrNOxJvTqW1RuRYN6dWWU4-1ArgqLAJ2o9GH7Ks1U=.9e4d7ba6-1126-4621-bd97-23d733261b67@github.com>

On Thu, 1 May 2025 17:48:22 GMT, Jan Lahoda <jlahoda at openjdk.org> 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:
> 
>   Updating copyright year.

src/java.base/share/classes/java/lang/IO.java line 157:

> 155:      * <p>
> 156:      * Writes a prompt as if by calling {@code print}, and then reads a single
> 157:      * line of text as if by calling {@link readln readln()}.

Is this intended to render like `readln` or `readln()`? I always recommend prefixing member references with `#` like `#readln()`.

src/java.base/share/classes/java/lang/IO.java line 179:

> 177:      * the reader() method.
> 178:      */
> 179:     static BufferedReader br;

The comments should indicate all access should be through `reader`, and this field is best made private to indicate direct field access is **not thread safe**.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070645283
PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070647143

From duke at openjdk.org  Thu May  1 20:29:46 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Thu, 1 May 2025 20:29:46 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java
In-Reply-To: <sS3HZ2aZsOqrm__NxCUeKvdCgwgnYXEP-4LxP7oN0fA=.69034e9c-a0ef-4842-a739-f95124523a0f@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
 <sS3HZ2aZsOqrm__NxCUeKvdCgwgnYXEP-4LxP7oN0fA=.69034e9c-a0ef-4842-a739-f95124523a0f@github.com>
Message-ID: <tvPY07xY8QPSk2Bop7Dm4U4wLLc2LdWAc1UCWm9oFL8=.7609fb9d-3362-45ac-a0a2-dd44b7570d41@github.com>

On Thu, 1 May 2025 19:24:13 GMT, Roger Riggs <rriggs at openjdk.org> 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:\\WIN...
>
> test/jdk/java/lang/ProcessBuilder/Basic.java line 1843:
> 
>> 1841:         //----------------------------------------------------------------
>> 1842:         try {
>> 1843:             String[] cmdp = Windows.is() ? new String[]{"cmd", "/c", "echo."} : new String[]{"echo"};
> 
> Why the extra "." in the echo string?

In Windows CMD, the `echo` command, when called without arguments, displays the current state of the command echoing mode ? either enabled (`ON`) or disabled (`OFF`). For the case when this test is run from IntelliJ IDEA.

And the `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line.

And to ensure that the `echo.` command is supported in Cygwin, we need to invoke it via `cmd /c echo.`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2070763745

From rriggs at openjdk.org  Thu May  1 21:08:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 1 May 2025 21:08:29 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v2]
In-Reply-To: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
Message-ID: <X7sRg2P-LJuaj4e_S4r3O2sk3WnBjH51969nKbZtM_4=.f7d0e65e-96d0-4ea6-89b2-917832e17469@github.com>

> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
> Support methods are static, designed to pass all values as arguments and return a value.
> 
> The value byte array is reallocated under 3 conditions:
> - Increasing the capacity with the same encoder
> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
> - Inflation with the same capacity
> 
> Added StressSBTest to exercise public instance methods of StringBuilder.

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

  Added missing bugid to tests
  Applied review suggestions.
  Added convenience methods to StringLatin1 for 4 and 5 character literals to leverage optimizations for merged stores.
  Updated missing copyright years.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24967/files
  - new: https://git.openjdk.org/jdk/pull/24967/files/b59a2e9a..f5003244

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

  Stats: 55 lines in 6 files changed: 16 ins; 14 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/24967.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24967/head:pull/24967

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

From swen at openjdk.org  Thu May  1 18:16:50 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 1 May 2025 18:16:50 GMT
Subject: RFR: 8356021: Use Double::hashCode in java.util.Locale::hashCode
In-Reply-To: <Axi4jX3mW1MR-2PyX-XIkWaxBZukzivV_aXtvkwrGok=.c75649a5-b82e-4e7d-a2d1-1317b5232705@github.com>
References: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
 <Axi4jX3mW1MR-2PyX-XIkWaxBZukzivV_aXtvkwrGok=.c75649a5-b82e-4e7d-a2d1-1317b5232705@github.com>
Message-ID: <9DKNGgorVgpZOig2AsE3iVx3ZsexlX9r7WDTbBsY6lA=.8b79a8b2-4a61-4d66-99ab-a254adb09fb0@github.com>

On Thu, 1 May 2025 16:27:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Similar to #24959, java.util.Locale.hashCode can also make the same improvement.
>> 
>> Replace manual bitwise operations in hashCode implementations of java.util.Locale with Double::hashCode.
>
> Thanks for the fix. Even though the fix is trivial and small, please keep the PR open at least for 24 hours so that every region of the globe can see the fix.

@naotoj Thank you for your reminder. There is a problem with GitHub's prompt. It shows yesterday in less than 24 hours. I will avoid this problem next time.

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

PR Comment: https://git.openjdk.org/jdk/pull/24971#issuecomment-2845399910

From myankelevich at openjdk.org  Thu May  1 21:27:48 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 1 May 2025 21:27:48 GMT
Subject: RFR: 8352480: Don't follow symlinks in additional content for app
 images
In-Reply-To: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
References: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
Message-ID: <SyYlXefnwweD6M6Lue0qAIZPm4jbNAEwOe2sVwb3Ihw=.284bb456-22a3-4e69-9957-7ab1e165814c@github.com>

On Wed, 30 Apr 2025 20:17:57 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Symbolic links will not be followed for `--app-content` on all platforms.
> - Added test to cover this case.
> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links.

test/jdk/tools/jpackage/share/AppContentTest.java line 57:

> 55:  */
> 56: public class AppContentTest {
> 57: 

Nitpick: do you think it might be worth it to add a bug id to the `@test`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2070827582

From bchristi at openjdk.org  Thu May  1 21:47:01 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 1 May 2025 21:47:01 GMT
Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed
 with "RuntimeException: MyObject is not found in test output" [v9]
In-Reply-To: <Jcra20HpK4hJAr6O1VySmMukJHFGYEieEpvDVrlbxuI=.03ee416c-3568-4a66-be60-f6c17fed2188@github.com>
References: <Jcra20HpK4hJAr6O1VySmMukJHFGYEieEpvDVrlbxuI=.03ee416c-3568-4a66-be60-f6c17fed2188@github.com>
Message-ID: <lETJgNjO8kCy1DtUVEvh8dm-Tupl8r35SdGo8qgg-sY=.777fd32c-7ae4-4bff-8006-8394606b1d78@github.com>

> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear up the intermittent failures:
> 
> * run with `othervm`: this test blocks the (global) finalizer thread, and also requires the (global) finalizer thread to enter the test's `finalize()` method
> * The test uses `volatile` ints, but sets them based on their current value, which is not reliable; convert to `AtomicInteger`
> * use `PhantomReference`s to ensure that at least two `MyObject`s have become unreachable. If one is stuck in `finalize()`, at least one is still waiting to be finalized and should show up in the histogram.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  remove unneeded 'trappedCount'

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24143/files
  - new: https://git.openjdk.org/jdk/pull/24143/files/0468fe73..88b26871

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24143&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24143&range=07-08

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

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

From rriggs at openjdk.org  Thu May  1 21:32:47 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 1 May 2025 21:32:47 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java
In-Reply-To: <tvPY07xY8QPSk2Bop7Dm4U4wLLc2LdWAc1UCWm9oFL8=.7609fb9d-3362-45ac-a0a2-dd44b7570d41@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
 <sS3HZ2aZsOqrm__NxCUeKvdCgwgnYXEP-4LxP7oN0fA=.69034e9c-a0ef-4842-a739-f95124523a0f@github.com>
 <tvPY07xY8QPSk2Bop7Dm4U4wLLc2LdWAc1UCWm9oFL8=.7609fb9d-3362-45ac-a0a2-dd44b7570d41@github.com>
Message-ID: <6CRYc09LAUqqqP9cJbNow9BkHS_bJcY1nTIpJJVxA5o=.4aea935a-8c8d-45b5-a74e-5a18d02dfd8d@github.com>

On Thu, 1 May 2025 20:27:01 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> test/jdk/java/lang/ProcessBuilder/Basic.java line 1843:
>> 
>>> 1841:         //----------------------------------------------------------------
>>> 1842:         try {
>>> 1843:             String[] cmdp = Windows.is() ? new String[]{"cmd", "/c", "echo."} : new String[]{"echo"};
>> 
>> Why the extra "." in the echo string?
>
> In Windows CMD, the `echo` command, when called without arguments, displays the current state of the command echoing mode ? either enabled (`ON`) or disabled (`OFF`). For the case when this test is run from IntelliJ IDEA.
> 
> And the `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line.
> 
> And to ensure that the `echo.` command is supported in Cygwin, we need to invoke it via `cmd /c echo.`.

Is `echo.` shorthand for `echo.exe`; if so, please change to the long form to make it clearer the echo program is being run.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2070834029

From duke at openjdk.org  Thu May  1 22:01:07 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Thu, 1 May 2025 22:01:07 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java
In-Reply-To: <6CRYc09LAUqqqP9cJbNow9BkHS_bJcY1nTIpJJVxA5o=.4aea935a-8c8d-45b5-a74e-5a18d02dfd8d@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
 <sS3HZ2aZsOqrm__NxCUeKvdCgwgnYXEP-4LxP7oN0fA=.69034e9c-a0ef-4842-a739-f95124523a0f@github.com>
 <tvPY07xY8QPSk2Bop7Dm4U4wLLc2LdWAc1UCWm9oFL8=.7609fb9d-3362-45ac-a0a2-dd44b7570d41@github.com>
 <6CRYc09LAUqqqP9cJbNow9BkHS_bJcY1nTIpJJVxA5o=.4aea935a-8c8d-45b5-a74e-5a18d02dfd8d@github.com>
Message-ID: <Dt3uWlr2qxiuWJrU5N4feOrIwpNEj28v9xpEaQJ974M=.2999cc9d-a782-4ac2-a92d-9fbaca7c0574@github.com>

On Thu, 1 May 2025 21:30:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> In Windows CMD, the `echo` command, when called without arguments, displays the current state of the command echoing mode ? either enabled (`ON`) or disabled (`OFF`). For the case when this test is run from IntelliJ IDEA.
>> 
>> And the `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line.
>> 
>> And to ensure that the `echo.` command is supported in Cygwin, we need to invoke it via `cmd /c echo.`.
>
> Is `echo.` shorthand for `echo.exe`; if so, please change to the long form to make it clearer the echo program is being run.

No, `echo.` is not an executable, this is a command of the Windows Command Processor.

See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2070858894

From rriggs at openjdk.org  Thu May  1 19:22:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 1 May 2025 19:22:50 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <DXQ8sulRSIa5sQJaZU9UM7NF8AHkRsViO6D9b0rI2Vg=.32fa69ad-94bf-4453-97e8-22a6802c8b08@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
 <DXQ8sulRSIa5sQJaZU9UM7NF8AHkRsViO6D9b0rI2Vg=.32fa69ad-94bf-4453-97e8-22a6802c8b08@github.com>
Message-ID: <F2QI8fLrAJ2ZB6nPfxenoaxVTP6_i1tMt3-9OLiXh0U=.3df00047-29b5-42e2-8518-2b7f63cc26ae@github.com>

On Thu, 1 May 2025 17:51:53 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test
>
> src/java.base/share/classes/java/io/Reader.java line 408:
> 
>> 406:      * <p> This method works as if invoking it were equivalent to evaluating
>> 407:      * the expression:
>> 408:      * <blockquote>{@linkplain #readAllChars()}.lines().toList()</blockquote>
> 
> I think this is actually too specific, as it could imply the returned List is the exact implementation that is returned by Stream.toList(). It is in this implementation, but I could easily imagine another implementation that constructs the list a different way. It might be better to be descriptive here and say that the entire input is read and is split into lines (where "line" is defined as above) which are returned in an unmodifiable list. And then have "unmodifiable list" be a link to the Unmodifiable Lists section, something like "java/util/List.html#unmodifiable".

The word 'equivalent' mitigates the exactness of the code to describe the expected result.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2070689232

From liach at openjdk.org  Thu May  1 17:38:42 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 17:38:42 GMT
Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe
 [v4]
In-Reply-To: <NLQLZm3c6l5ympapbv_5zWH8rNo8zhGchZrvq7hie9k=.e5e8b256-1a9c-42c0-ac58-8b6416937f39@github.com>
References: <NLQLZm3c6l5ympapbv_5zWH8rNo8zhGchZrvq7hie9k=.e5e8b256-1a9c-42c0-ac58-8b6416937f39@github.com>
Message-ID: <XRCcdxfmkq6n57e9X5m_rla8xDbCHg0uNjMDyP9-srk=.3290056d-b42e-4493-9ee7-1039cc820533@github.com>

> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Missed bug id

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23757/files
  - new: https://git.openjdk.org/jdk/pull/23757/files/eb405dd9..66066be7

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

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

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

From duke at openjdk.org  Thu May  1 23:40:49 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Thu, 1 May 2025 23:40:49 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v5]
In-Reply-To: <Rvch_7UMKRSFCsJqbkDZEHYkHwhu9kvNqFb24QVVXBQ=.16c48f94-807e-4b42-9952-e341e24c28c4@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <dFfo7XWntOoKDqWbOSksw2xon3geOvm2h7WuLsodIU0=.6480d447-b14b-43ea-a673-f36e7cbed4fa@github.com>
 <R26A-RFOkbja1bnImimPwn63l0Ey3wceWkCsJg1Jox4=.5621fccc-d59e-4a51-88e9-1c28d9ae9b86@github.com>
 <cNouC_Qp5yZHSyxMdZfBkmprp60u0UPlBS8kL9AVhz0=.4d085a45-cb66-4656-8ba2-41944478c989@github.com>
 <GENBQaAlYVOW6PdXkzHSCIgUIEbVMzMj4_s-E7YLD1c=.125d5f41-50bc-4e0c-befc-f2f7da3eb94e@github.com>
 <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
 <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>
 <k_WmWojaK6sUQYgs_a_wfnU1hBnTJb23k4avXhPI8pg=.ecc7d452-0ba0-420a-8c11-443d60c76df3@github.com>
 <Rvch_7UMKRSFCsJqbkDZEHYkHwhu9kvNqFb24QVVXBQ=.16c48f94-807e-4b42-9952-e341e24c28c4@github.com>
Message-ID: <Kjd6TXMbXvhKTTbmK9LHVMTNuy87YxB_alqV4IBww9E=.e550c9ca-8cec-4177-ae57-df45f0d17f0f@github.com>

On Thu, 1 May 2025 17:40:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello @tats-u , there is no bother, I appreciate you looking at this.
>> 
>> The addition of `stdin.encoding` in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703) (#24738) happened very quickly. I worked with @naotoj and @AlanBateman on it and we think it does the right thing, but there are many Windows configurations that we don't have the opportunity to test, so more feedback is helpful.
>> 
>> Initially it would be good to understand if `stdin.encoding` is specified and implemented correctly, and whether it provides the right behavior for `java.lang.IO` in JEP 512.
>> 
>> In the future we can consider additional uses of `stdin.encoding` in other parts of the JDK.
>
> `InputStreamReader` and `Scanner` taking `stdin.encoding` is an interesting idea, but would introduce compatiblity concerns. It would have been simpler if we had `stdin/out/err.encoding` system properties prior to JEP 400. 
> As to testing on Windows, I would like to know how the Windows `UILanguage` affects these, afaik we only have tested on English Windows. Say how it works on Japanese Windows with English system locale. However, since we have not changed any existing behavior (from the code wise), I don't think we would see any issues.

In Java 17 or prior, non-advanced Windows users especially whose language has a common encodings for ANSI/OEM code page (e.g. Windows-31J for Japanese) had been satisfied the behavior at that time. 
JEP 400 broke everything in stdin in Windows. Currently we need to check both stdin.encoding and (sun.)stdout.encoding in every constructor caller to support older Java versions. 

One idea to fix is to check whether the parameter InpuReader is System.in or not in the constructor of InputStreamReader.

https://github.com/tats-u/jdk/commit/3cbc7be971234ed3c52899ef2b16c040dc120418

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070927346

From duke at openjdk.org  Fri May  2 00:00:59 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Fri, 2 May 2025 00:00:59 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v5]
In-Reply-To: <Kjd6TXMbXvhKTTbmK9LHVMTNuy87YxB_alqV4IBww9E=.e550c9ca-8cec-4177-ae57-df45f0d17f0f@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <dFfo7XWntOoKDqWbOSksw2xon3geOvm2h7WuLsodIU0=.6480d447-b14b-43ea-a673-f36e7cbed4fa@github.com>
 <R26A-RFOkbja1bnImimPwn63l0Ey3wceWkCsJg1Jox4=.5621fccc-d59e-4a51-88e9-1c28d9ae9b86@github.com>
 <cNouC_Qp5yZHSyxMdZfBkmprp60u0UPlBS8kL9AVhz0=.4d085a45-cb66-4656-8ba2-41944478c989@github.com>
 <GENBQaAlYVOW6PdXkzHSCIgUIEbVMzMj4_s-E7YLD1c=.125d5f41-50bc-4e0c-befc-f2f7da3eb94e@github.com>
 <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
 <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>
 <k_WmWojaK6sUQYgs_a_wfnU1hBnTJb23k4avXhPI8pg=.ecc7d452-0ba0-420a-8c11-443d60c76df3@github.com>
 <Rvch_7UMKRSFCsJqbkDZEHYkHwhu9kvNqFb24QVVXBQ=.16c48f94-807e-4b42-9952-e341e24c28c4@github.com>
 <Kjd6TXMbXvhKTTbmK9LHVMTNuy87YxB_alqV4IBww9E=.e550c9ca-8cec-4177-ae57-df45f0d17f0f@github.com>
Message-ID: <dpz22BvUdBRhm09g40hJF6ErZ6YkGsVhe5onequrAE8=.1b58e1c7-342d-4694-99a6-fff46bdda61b@github.com>

On Thu, 1 May 2025 23:33:00 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> `InputStreamReader` and `Scanner` taking `stdin.encoding` is an interesting idea, but would introduce compatiblity concerns. It would have been simpler if we had `stdin/out/err.encoding` system properties prior to JEP 400. 
>> As to testing on Windows, I would like to know how the Windows `UILanguage` affects these, afaik we only have tested on English Windows. Say how it works on Japanese Windows with English system locale. However, since we have not changed any existing behavior (from the code wise), I don't think we would see any issues.
>
> In Java 17 or prior, non-advanced Windows users especially whose language has a common encodings for ANSI/OEM code page (e.g. Windows-31J for Japanese) had been satisfied the behavior at that time. 
> JEP 400 broke everything in stdin in Windows. Currently we need to check both stdin.encoding and (sun.)stdout.encoding in every constructor caller to support older Java versions. 
> 
> One idea to fix is to check whether the parameter InpuReader is System.in or not in the constructor of InputStreamReader.
> 
> https://github.com/tats-u/jdk/commit/3cbc7be971234ed3c52899ef2b16c040dc120418

I think we have only to change console encodings by e.g. `chcp 932` (CMD) or `[Console]::InputEncoding = [Console]::OutputEncoding = [System.Text.Encoding]::Get Encoding(932)` (PowerShell) in Windows. They correspond to `GetConsoleCP` and `GetConsoleOutputCP`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070940588

From huizhe.wang at oracle.com  Fri May  2 00:24:43 2025
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 1 May 2025 17:24:43 -0700
Subject: Namespace Prefix Issue in XML to XSL Transformation
In-Reply-To: <SJ4PPF6D7B23F3FEA3AEBBD32A4999EB9FA9DBA2@SJ4PPF6D7B23F3F.namprd15.prod.outlook.com>
References: <SJ4PPF6D7B23F3FEA3AEBBD32A4999EB9FA9DBA2@SJ4PPF6D7B23F3F.namprd15.prod.outlook.com>
Message-ID: <054f569e-cf8a-4241-ac3d-ca248ac1d65b@oracle.com>

Hi Hempushpa,


You may want to talk to Christoph on JDK-8168664, he might have temped a 
fix at the time. Otherwise, feel free to create a new bug and PR, and we 
can start from there.


Thanks,

Joe

On 4/23/25 7:03 AM, Hempushpa Sahu wrote:
>
> Problem Description :
>
> XSLT transformation creating unique namespace prefixes.
>
> Analysis & Observation :
>
> The XSLT transformation is generating a new namespace prefix for every 
> XML element, even when the namespace value matches that of the parent 
> element. This leads to large XML file transformations exceeding the 
> file size and memory limits on our systems.
>
> The behaviour in OpenJDK has remained consistent since JDK 8; however, 
> the namespace prefix issue is not something we find optimum.
>
> During our investigation of the OpenJDK codebase, we identified defect 
> https://bugs.openjdk.org/browse/JDK-8167179, which was intended to 
> resolve the namespace prefix issue in the OpenJDK 8 release. However, 
> our testing confirms that the issue persists across multiple versions, 
> including OpenJDK 8, 11, 17, and 22. Additionally, we found an open 
> bug report https://bugs.openjdk.org/browse/JDK-8168664 in the OpenJDK 
> issue tracker referencing a similar problem. Notably, there has been 
> no recent activity on this bug for several years
>
> Suggested Solution:
>
> Introduced a hashmap, and storing the unique namespace-url from root 
> node and checking if new url namespace-url encountered then we will 
> store it in the hashmap and increment the namespace prefix, else we 
> will not increment the prefix.
>
> Implemented in existing function startXslElement() of 
> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java
>
> ????????????? else {
>
> ??????? // Need to generate a prefix?
>
> ??????? if (namespace != null && namespace.length() > 0) {
>
> ??????????? prefix = generatePrefix();
>
> ??????????? qname = prefix + ':' + qname;
>
> ??????????? handler.startElement(namespace, qname, qname);
>
> handler.namespaceAfterStartElement(prefix, namespace);
>
> ??????? }
>
> The above code is changed to
>
> ????????????? else {
>
> ??????? // Need to generate a prefix?
>
> ???????????????????????????? if (namespace != null && 
> namespace.length() > 0) {
>
> //Check if prefix needs to be incremented.
>
> if (!namespaceMap.containsKey(namespace))
>
> {
>
> namespaceMap.put(namespace, 
> threadLocalPrefixIndex.get().getAndIncrement());
>
> prefix = "ns"+namespaceMap.get(namespace);
>
> qname = prefix + ':' + qname;
>
> handler.startElement(namespace, qname, qname);
>
> ????????????? handler.namespaceAfterStartElement(prefix, namespace);
>
> }
>
> else
>
> {
>
> //Namespace URI already exist in map.
>
> prefix = "ns"+namespaceMap.get(namespace);
>
> qname = prefix + ':' + qname;
>
> handler.startElement(namespace, qname, qname);
>
> ????????????? handler.namespaceAfterStartElement(prefix, namespace);
>
> }
>
> ???????????????????????????? }
>
> Releases:
>
> OpenJDK 8, 11, 17 & 22 the issue is seen.
>
> Note:
>
> Proceeding with this approach, we will need to update the test files. 
> For instance, we have identified one test case that validates the 
> namespace prefix in the result - 
> test/jaxp/javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java
>
> Next steps:
>
> We want to take the above-mentioned fix to OpenJDK.
>
> Please review and suggest if the above understanding is right and we 
> shall take the fix to OpenJDK.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250501/9deb3a00/attachment-0001.htm>

From jlahoda at openjdk.org  Fri May  2 00:57:27 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 2 May 2025 00:57:27 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v9]
In-Reply-To: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
Message-ID: <EBU-QaOtBooxLw8S407r5r9pkYdpdbqqBomY2P0HSQg=.e1a20ecf-c59f-4e3f-8bdf-b5abb3cf7179@github.com>

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

  Make br field private; tweaks to javadoc.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24438/files
  - new: https://git.openjdk.org/jdk/pull/24438/files/5d0a867f..9c095792

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=07-08

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 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 liach at openjdk.org  Fri May  2 00:57:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 00:57:27 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v9]
In-Reply-To: <EBU-QaOtBooxLw8S407r5r9pkYdpdbqqBomY2P0HSQg=.e1a20ecf-c59f-4e3f-8bdf-b5abb3cf7179@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <EBU-QaOtBooxLw8S407r5r9pkYdpdbqqBomY2P0HSQg=.e1a20ecf-c59f-4e3f-8bdf-b5abb3cf7179@github.com>
Message-ID: <MmlwdH84URKZQSJ58wgMC8x2oa0K0dk-9fL2UVpd0Wg=.2816b649-b2bb-4755-a9e2-ca4d01079017@github.com>

On Fri, 2 May 2025 00:54:24 GMT, Jan Lahoda <jlahoda at openjdk.org> 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:
> 
>   Make br field private; tweaks to javadoc.

Thanks for the update Stuart. Looks all good to me.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24438#pullrequestreview-2810991411

From smarks at openjdk.org  Fri May  2 00:57:28 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 2 May 2025 00:57:28 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v8]
In-Reply-To: <i0nrNOxJvTqW1RuRYN6dWWU4-1ArgqLAJ2o9GH7Ks1U=.9e4d7ba6-1126-4621-bd97-23d733261b67@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>
 <i0nrNOxJvTqW1RuRYN6dWWU4-1ArgqLAJ2o9GH7Ks1U=.9e4d7ba6-1126-4621-bd97-23d733261b67@github.com>
Message-ID: <DwFCtgnc0mjxhkH-11NwxxcgJWF7oa4US8167hX8Lv4=.b2af64ee-55c2-43b1-b8a7-37ad05d2a67c@github.com>

On Thu, 1 May 2025 18:43:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating copyright year.
>
> src/java.base/share/classes/java/lang/IO.java line 157:
> 
>> 155:      * <p>
>> 156:      * Writes a prompt as if by calling {@code print}, and then reads a single
>> 157:      * line of text as if by calling {@link readln readln()}.
> 
> Is this intended to render like `readln` or `readln()`? I always recommend prefixing member references with `#` like `#readln()`.

I added `#` prefixes. I had intended `readln()` to indicate that this referred to the no-arg overload of `readln()` but I think that's too subtle so I removed the parens. But one has to look at the link to determine that it refers to the no-arg readln and not the one-arg readln (which is this method). I also changed the `print` to a link as well.

> src/java.base/share/classes/java/lang/IO.java line 179:
> 
>> 177:      * the reader() method.
>> 178:      */
>> 179:     static BufferedReader br;
> 
> The comments should indicate all access should be through `reader`, and this field is best made private to indicate direct field access is **not thread safe**.

Added a comment. Making it `private` doesn't really help, but I made it private anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070971289
PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070970447

From jpai at openjdk.org  Fri May  2 01:33:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 2 May 2025 01:33:59 GMT
Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe
 [v4]
In-Reply-To: <XRCcdxfmkq6n57e9X5m_rla8xDbCHg0uNjMDyP9-srk=.3290056d-b42e-4493-9ee7-1039cc820533@github.com>
References: <NLQLZm3c6l5ympapbv_5zWH8rNo8zhGchZrvq7hie9k=.e5e8b256-1a9c-42c0-ac58-8b6416937f39@github.com>
 <XRCcdxfmkq6n57e9X5m_rla8xDbCHg0uNjMDyP9-srk=.3290056d-b42e-4493-9ee7-1039cc820533@github.com>
Message-ID: <JHejf9ZabPbmD4UX-JhR9Sa3krotA0G3EBqv_xiP30Y=.d94bc7d4-6fcf-431d-b1cd-dc86cc056342@github.com>

On Thu, 1 May 2025 17:38:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed bug id

Thank you for the updates. Changes look good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23757#pullrequestreview-2811019544

From liach at openjdk.org  Fri May  2 01:33:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 01:33:59 GMT
Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe
 [v4]
In-Reply-To: <XRCcdxfmkq6n57e9X5m_rla8xDbCHg0uNjMDyP9-srk=.3290056d-b42e-4493-9ee7-1039cc820533@github.com>
References: <NLQLZm3c6l5ympapbv_5zWH8rNo8zhGchZrvq7hie9k=.e5e8b256-1a9c-42c0-ac58-8b6416937f39@github.com>
 <XRCcdxfmkq6n57e9X5m_rla8xDbCHg0uNjMDyP9-srk=.3290056d-b42e-4493-9ee7-1039cc820533@github.com>
Message-ID: <ZR7wAS97pvTUPHbF_hmRGzl_yWEp632mh5w2ThV7Nbw=.32592649-3f05-4285-b8de-03f7e9af64ad@github.com>

On Thu, 1 May 2025 17:38:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed bug id

Thanks for the refreshed review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23757#issuecomment-2846110001

From liach at openjdk.org  Fri May  2 01:33:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 01:33:59 GMT
Subject: Integrated: 8350549: MethodHandleProxies.WRAPPER_TYPES is not
 thread-safe
In-Reply-To: <NLQLZm3c6l5ympapbv_5zWH8rNo8zhGchZrvq7hie9k=.e5e8b256-1a9c-42c0-ac58-8b6416937f39@github.com>
References: <NLQLZm3c6l5ympapbv_5zWH8rNo8zhGchZrvq7hie9k=.e5e8b256-1a9c-42c0-ac58-8b6416937f39@github.com>
Message-ID: <gL36YvHgbHCNy6NuiHmfxuW33JNHdXA7PkMFwlFS7Vw=.34f6dabd-0694-4956-8154-d1ec00126add@github.com>

On Mon, 24 Feb 2025 23:47:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set.

This pull request has now been integrated.

Changeset: bd7c7789
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd7c77898a75dece0586bef24d4e18d540f08288
Stats:     34 lines in 2 files changed: 29 ins; 2 del; 3 mod

8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe

Reviewed-by: jpai, jvernee

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

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

From jiangli at openjdk.org  Fri May  2 02:15:32 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 2 May 2025 02:15:32 GMT
Subject: RFR: 8356050: Problemlist jdk & langtools tier1 tests requiring
 runtime usages of <jdk>/bin/tools for static-jdk
Message-ID: <lYyYzYPIR2XTf9BvhyjjXqDouhTtIXEobg8d8yrQDD4=.2e61aa4e-d4b8-4f3e-ab58-f5ef3c1465f4@github.com>

Please review this PR to problemlist jdk & langtools tier1 tests requiring runtime usages of <jdk>/bin/tools, for testing on static-jdk. The affected tests using following tools at runtime:

- javac
- javadoc
- jar
- jarsigner
- jimage
- jps

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

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8356050
 - Problem jdk & langtools tier1 tests requiring runtime usages of <jdk>/bin/tools for static-jdk.

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

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

From swen at openjdk.org  Fri May  2 03:04:02 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 03:04:02 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v12]
In-Reply-To: <YTFbGJ9rzuSvAmlYT_t4e0A62CmWMMOJhwBLsujuNo4=.4a14d041-b2f3-4928-86eb-8e94ab50473e@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <YTFbGJ9rzuSvAmlYT_t4e0A62CmWMMOJhwBLsujuNo4=.4a14d041-b2f3-4928-86eb-8e94ab50473e@github.com>
Message-ID: <d6IFYzuVrVW8Hq0Y-9_BsdxCY2sEbZD2doI93xyo_S8=.d3d51692-589c-4b7d-a29f-277b159170b6@github.com>

On Thu, 7 Sep 2023 19:27:14 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information.  If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO`
>> can be used instead and such stack walker will save the overhead of extracting the method information
>> and the memory used for the stack walking.
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can create a stack walker instance with `DROP_METHOD_INFO` option:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(Predicate.not(implClasses::contains))
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Javadoc & specdiff
>> 
>> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
>> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would have to
>> modify calls to the `walk` method to `walkClass` and the function body.
>> 
>> ### Implementation Details
>> 
>> A `StackWalker` configured with `DROP_METHOD_INFO` ...
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix @Param due to the rename from default to class+method

The value of flags can only be 0 or 0x08000000, so flags & MEMBER_INFO_FLAGS in isHidden and isCallerSensitive methods are always false


    ClassFrameInfo(StackWalker walker) {
        this.flags = walker.retainClassRef ? RETAIN_CLASS_REF_BIT : 0;
    }

    private static final int MEMBER_INFO_FLAGS    = 0x00FFFFFF;
    private static final int RETAIN_CLASS_REF_BIT = 0x08000000; // retainClassRef


The flags field is only assigned in the ClassFrameInfo constructor, so flags can be set to final, and the value here will only be 0 or RETAIN_CLASS_REF_BIT (0x08000000).

So `flags & MEMBER_INFO_FLAGS` in the following code is always false

    boolean isCallerSensitive() {
        return JLIA.isCallerSensitive(flags & MEMBER_INFO_FLAGS);
    }

    boolean isHidden() {
        return JLIA.isHiddenMember(flags & MEMBER_INFO_FLAGS);
    }

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

PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-2846210254

From swen at openjdk.org  Fri May  2 03:36:06 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 03:36:06 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v12]
In-Reply-To: <YTFbGJ9rzuSvAmlYT_t4e0A62CmWMMOJhwBLsujuNo4=.4a14d041-b2f3-4928-86eb-8e94ab50473e@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <YTFbGJ9rzuSvAmlYT_t4e0A62CmWMMOJhwBLsujuNo4=.4a14d041-b2f3-4928-86eb-8e94ab50473e@github.com>
Message-ID: <Ibsj81D6_v1t850KBTvbz-AVcOBBorggBwEhaoz7zDw=.f18e9038-06d4-46d2-ad9b-9b5273208981@github.com>

On Thu, 7 Sep 2023 19:27:14 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information.  If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO`
>> can be used instead and such stack walker will save the overhead of extracting the method information
>> and the memory used for the stack walking.
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can create a stack walker instance with `DROP_METHOD_INFO` option:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(Predicate.not(implClasses::contains))
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Javadoc & specdiff
>> 
>> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
>> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would have to
>> modify calls to the `walk` method to `walkClass` and the function body.
>> 
>> ### Implementation Details
>> 
>> A `StackWalker` configured with `DROP_METHOD_INFO` ...
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix @Param due to the rename from default to class+method

Sorry, I misread it. There is a comment in flags: `updated by VM to set hidden and caller-sensitive bits`

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

PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-2846236653

From swen at openjdk.org  Fri May  2 03:49:39 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 03:49:39 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 UTF16::compress & Unsafe::copyMemory [v4]
In-Reply-To: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
Message-ID: <V8ZrRweDmVS9HD5kY8TM6xIVWBfiZy8StMHs6LPO78o=.59017549-3ec8-4627-b206-a9e897045081@github.com>

> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.
> 
> For these scenarios, we can use the intrinsic method StringUTF16.compress and Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/AbstractStringBuilder.java
 - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/StringUTF16.java
 - putCharsUnchecked
 - copyright
 - Using StringUTF16.compress to speed up LATIN1 StringBuilder append(char[])
 - Using Unsafe.copyMemory to speed up UTF16 StringBuilder append(char[])
 - add append(char[]) benchmark

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

Changes: https://git.openjdk.org/jdk/pull/24773/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24773&range=03
  Stats: 46 lines in 3 files changed: 40 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24773/head:pull/24773

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

From swen at openjdk.org  Fri May  2 03:53:23 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 03:53:23 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v21]
In-Reply-To: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
Message-ID: <1aM0ee4KZZMdJ-P_D4fyHctD5SI-0MSYmqnQ61Bv3p0=.909cc730-2bb7-4a1c-b4f8-4f18734d7b63@github.com>

> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes:
> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3.
> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1.
> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses.

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - Merge remote-tracking branch 'upstream/master' into optim_parse_int_long_202501
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/Integer.java
   #	src/java.base/share/classes/java/lang/Long.java
 - Merge remote-tracking branch 'upstream/master' into optim_parse_int_long_202501
 - remove ForceInline
 - fix comments
 - fix comments
 - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
   
   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
 - copyright
 - fix JdbExprTest
 - Update src/java.base/share/classes/java/lang/Long.java
   
   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
 - Update src/java.base/share/classes/java/lang/Integer.java
   
   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
 - ... and 29 more: https://git.openjdk.org/jdk/compare/bd7c7789...047e1709

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

Changes: https://git.openjdk.org/jdk/pull/22919/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=20
  Stats: 179 lines in 6 files changed: 101 ins; 26 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/22919.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919

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

From swen at openjdk.org  Fri May  2 03:55:24 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 03:55:24 GMT
Subject: RFR: 8349176: Speed up Integer/Long.toString via
 StringConcatHelper::newArray [v3]
In-Reply-To: <u9INrX9ZnlI8Hs0gC1hnE-oYiHLrnL93Q5hF1yzmJgM=.8b5bb878-27f0-4c21-a1bb-82ce65634b81@github.com>
References: <u9INrX9ZnlI8Hs0gC1hnE-oYiHLrnL93Q5hF1yzmJgM=.8b5bb878-27f0-4c21-a1bb-82ce65634b81@github.com>
Message-ID: <kc28TuEhKYFGcG66xECqIMUbvWJhJfJ8FtfwQwBiz8g=.6fd2d4a9-7a8d-4616-b87b-80f52d48f6b3@github.com>

> 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 with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge remote-tracking branch 'upstream/master' into allocate_un_init_202501
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/Integer.java
   #	src/java.base/share/classes/java/lang/Long.java
 - use StringConcatHelper.newArray
 - simplify
 - use Unsafe.allocateUninitializedArray
 - revert StringConcatHelper newArray change
 - copyright
 - remove duplicate check
 - allocateUninitializedArray

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

Changes: https://git.openjdk.org/jdk/pull/23353/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23353&range=02
  Stats: 6 lines in 2 files changed: 2 ins; 0 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  Fri May  2 04:59:45 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 04:59:45 GMT
Subject: RFR: 8356022: Migrate descriptor parsing from generics to
 BytecodeDescriptor
In-Reply-To: <WWJzOE0HrykcWuNdn8uAfgxub1RtpyznSHjBnnzp8T0=.783d3a95-53f2-4a68-a469-1dd1d22dc03f@github.com>
References: <WWJzOE0HrykcWuNdn8uAfgxub1RtpyznSHjBnnzp8T0=.783d3a95-53f2-4a68-a469-1dd1d22dc03f@github.com>
Message-ID: <aT74jPRF2VVCBpvGhe8TJ0a2Gaakmx1U62bDcnKkr3E=.5733fb7e-c904-4061-86c0-426c48ae20fb@github.com>

On Thu, 1 May 2025 00:01:08 GMT, Chen Liang <liach at openjdk.org> wrote:

> As another step toward the removal of the old generics infrastructure, I propose to remove the usages of generic parsing utilities and use the facilities provided by BytecodeDescriptor, already used by MethodType.fromDescriptorString. This also prevents extra validation cost in use sites to defend against generic types.
> 
> In this patch, BytecodeDescriptor and Wrapper see minor updates, mainly for better exception messages - previously, an unparseable char in the descriptor string just reports that char, and now the whole descriptor string is reported.
> 
> These behaviors are already covered by the tests added in JDK-8350704 #23788.
> 
> Testing: reflect/annotation/Class, running tier 1+2

src/java.base/share/classes/java/lang/Class.java line 1565:

> 1563:             Class<?>[] parameterClasses = types.toArray(EMPTY_CLASS_ARRAY);
> 1564: 
> 1565:             final Class<?> enclosingCandidate = enclosingInfo.getEnclosingClass();

Suggestion:

            Constructor<?>[] candidates = enclosingInfo.getEnclosingClass()
                                                       .privateGetDeclaredConstructors(false);

Here the local variable `enclosingInfo` is only used once, the above code may be simpler

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24978#discussion_r2071095785

From duke at openjdk.org  Fri May  2 05:08:52 2025
From: duke at openjdk.org (duke)
Date: Fri, 2 May 2025 05:08:52 GMT
Subject: Withdrawn: 8351344: Avoid explicit Objects.requireNonNull in
 String.join
In-Reply-To: <odmV2OztUnLRYP6djJDZvddEmG0i3Nm8Rw3HVV0YUes=.499ba05e-8ca1-4ed1-a53e-eb5ebf265f63@github.com>
References: <odmV2OztUnLRYP6djJDZvddEmG0i3Nm8Rw3HVV0YUes=.499ba05e-8ca1-4ed1-a53e-eb5ebf265f63@github.com>
Message-ID: <ukHZvu_n-Psp1dijWP7IC6RrhajNqMlIiHDYPXwXgaI=.ec20f2d2-9d5f-40de-8860-ee20ec8278c7@github.com>

On Thu, 20 Feb 2025 09:30:02 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> We have helpful NPE messages now - they are more user-friendly.
> And shorter methods are more likely to be inlined.

This pull request has been closed without being integrated.

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

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

From liach at openjdk.org  Fri May  2 05:14:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 05:14:49 GMT
Subject: RFR: 8356022: Migrate descriptor parsing from generics to
 BytecodeDescriptor
In-Reply-To: <aT74jPRF2VVCBpvGhe8TJ0a2Gaakmx1U62bDcnKkr3E=.5733fb7e-c904-4061-86c0-426c48ae20fb@github.com>
References: <WWJzOE0HrykcWuNdn8uAfgxub1RtpyznSHjBnnzp8T0=.783d3a95-53f2-4a68-a469-1dd1d22dc03f@github.com>
 <aT74jPRF2VVCBpvGhe8TJ0a2Gaakmx1U62bDcnKkr3E=.5733fb7e-c904-4061-86c0-426c48ae20fb@github.com>
Message-ID: <Q91pdD9C9xGHdKZDaS_T3udFNPW8o4ZUcdOCk1cxLA8=.d0b2b20f-4185-41bc-be2e-79bb496e3d93@github.com>

On Fri, 2 May 2025 04:56:51 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> As another step toward the removal of the old generics infrastructure, I propose to remove the usages of generic parsing utilities and use the facilities provided by BytecodeDescriptor, already used by MethodType.fromDescriptorString. This also prevents extra validation cost in use sites to defend against generic types.
>> 
>> In this patch, BytecodeDescriptor and Wrapper see minor updates, mainly for better exception messages - previously, an unparseable char in the descriptor string just reports that char, and now the whole descriptor string is reported.
>> 
>> These behaviors are already covered by the tests added in JDK-8350704 #23788.
>> 
>> Testing: reflect/annotation/Class, running tier 1+2
>
> src/java.base/share/classes/java/lang/Class.java line 1565:
> 
>> 1563:             Class<?>[] parameterClasses = types.toArray(EMPTY_CLASS_ARRAY);
>> 1564: 
>> 1565:             final Class<?> enclosingCandidate = enclosingInfo.getEnclosingClass();
> 
> Suggestion:
> 
>             Constructor<?>[] candidates = enclosingInfo.getEnclosingClass()
>                                                        .privateGetDeclaredConstructors(false);
> 
> Here the local variable `enclosingInfo` is only used once, the above code may be simpler

This patch intentionally did not change this part - and this part can get much more in-depth optimization; for example, arrayContentsEq can be shared for all `Class` arrays, copy of reflective objects can be simplified, etc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24978#discussion_r2071104255

From swen at openjdk.org  Fri May  2 05:19:52 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 05:19:52 GMT
Subject: RFR: 8356022: Migrate descriptor parsing from generics to
 BytecodeDescriptor
In-Reply-To: <WWJzOE0HrykcWuNdn8uAfgxub1RtpyznSHjBnnzp8T0=.783d3a95-53f2-4a68-a469-1dd1d22dc03f@github.com>
References: <WWJzOE0HrykcWuNdn8uAfgxub1RtpyznSHjBnnzp8T0=.783d3a95-53f2-4a68-a469-1dd1d22dc03f@github.com>
Message-ID: <734JhRuV4oIyVO7f9czHorMNCKqoucxHTA5wVdAxtS8=.480541f0-854b-43ab-96c0-378054af4350@github.com>

On Thu, 1 May 2025 00:01:08 GMT, Chen Liang <liach at openjdk.org> wrote:

> As another step toward the removal of the old generics infrastructure, I propose to remove the usages of generic parsing utilities and use the facilities provided by BytecodeDescriptor, already used by MethodType.fromDescriptorString. This also prevents extra validation cost in use sites to defend against generic types.
> 
> In this patch, BytecodeDescriptor and Wrapper see minor updates, mainly for better exception messages - previously, an unparseable char in the descriptor string just reports that char, and now the whole descriptor string is reported.
> 
> These behaviors are already covered by the tests added in JDK-8350704 #23788.
> 
> Testing: reflect/annotation/Class, running tier 1+2

src/java.base/share/classes/java/lang/Class.java line 1563:

> 1561:             List<Class<?>> types = BytecodeDescriptor.parseMethod(enclosingInfo.getDescriptor(), getClassLoader());
> 1562:             types.removeLast();
> 1563:             Class<?>[] parameterClasses = types.toArray(EMPTY_CLASS_ARRAY);

Suggestion:

            var parameterClasses = types.toArray(EMPTY_CLASS_ARRAY);

Here the type of parameterClasses is very clear, or you can use var

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24978#discussion_r2071107230

From swen at openjdk.org  Fri May  2 05:23:45 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 05:23:45 GMT
Subject: RFR: 8356022: Migrate descriptor parsing from generics to
 BytecodeDescriptor
In-Reply-To: <WWJzOE0HrykcWuNdn8uAfgxub1RtpyznSHjBnnzp8T0=.783d3a95-53f2-4a68-a469-1dd1d22dc03f@github.com>
References: <WWJzOE0HrykcWuNdn8uAfgxub1RtpyznSHjBnnzp8T0=.783d3a95-53f2-4a68-a469-1dd1d22dc03f@github.com>
Message-ID: <L6gzRmR5iiCkHWcN6TKXnLhgn-4zyFgCY7k6u7UYUo4=.bcfdc37b-707a-4a41-aad7-53a06ee8f760@github.com>

On Thu, 1 May 2025 00:01:08 GMT, Chen Liang <liach at openjdk.org> wrote:

> As another step toward the removal of the old generics infrastructure, I propose to remove the usages of generic parsing utilities and use the facilities provided by BytecodeDescriptor, already used by MethodType.fromDescriptorString. This also prevents extra validation cost in use sites to defend against generic types.
> 
> In this patch, BytecodeDescriptor and Wrapper see minor updates, mainly for better exception messages - previously, an unparseable char in the descriptor string just reports that char, and now the whole descriptor string is reported.
> 
> These behaviors are already covered by the tests added in JDK-8350704 #23788.
> 
> Testing: reflect/annotation/Class, running tier 1+2

src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java line 48:

> 46:         int[] i = {0};
> 47:         var ret = parseSig(descriptor, i, descriptor.length(), loader);
> 48:         if (i[0] != descriptor.length() || ret == null) {

var ret = parseSig(descriptor, new int[] {0}, descriptor.length(), loader);
        if (descriptor.length() != 0 || ret == null) {

Can it be rewritten like this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24978#discussion_r2071109091

From liach at openjdk.org  Fri May  2 05:23:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 05:23:45 GMT
Subject: RFR: 8356022: Migrate descriptor parsing from generics to
 BytecodeDescriptor
In-Reply-To: <L6gzRmR5iiCkHWcN6TKXnLhgn-4zyFgCY7k6u7UYUo4=.bcfdc37b-707a-4a41-aad7-53a06ee8f760@github.com>
References: <WWJzOE0HrykcWuNdn8uAfgxub1RtpyznSHjBnnzp8T0=.783d3a95-53f2-4a68-a469-1dd1d22dc03f@github.com>
 <L6gzRmR5iiCkHWcN6TKXnLhgn-4zyFgCY7k6u7UYUo4=.bcfdc37b-707a-4a41-aad7-53a06ee8f760@github.com>
Message-ID: <p4e4OSWJwxzpMdxXkjhFNv8dM2DNchyCVVgQmrPLr5c=.f2f176dd-f7ad-4e4a-a35b-99bed2fd6020@github.com>

On Fri, 2 May 2025 05:19:57 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> As another step toward the removal of the old generics infrastructure, I propose to remove the usages of generic parsing utilities and use the facilities provided by BytecodeDescriptor, already used by MethodType.fromDescriptorString. This also prevents extra validation cost in use sites to defend against generic types.
>> 
>> In this patch, BytecodeDescriptor and Wrapper see minor updates, mainly for better exception messages - previously, an unparseable char in the descriptor string just reports that char, and now the whole descriptor string is reported.
>> 
>> These behaviors are already covered by the tests added in JDK-8350704 #23788.
>> 
>> Testing: reflect/annotation/Class, running tier 1+2
>
> src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java line 48:
> 
>> 46:         int[] i = {0};
>> 47:         var ret = parseSig(descriptor, i, descriptor.length(), loader);
>> 48:         if (i[0] != descriptor.length() || ret == null) {
> 
> var ret = parseSig(descriptor, new int[] {0}, descriptor.length(), loader);
>         if (descriptor.length() != 0 || ret == null) {
> 
> Can it be rewritten like this?

i[0] is modified by parseSig

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24978#discussion_r2071109980

From swen at openjdk.org  Fri May  2 06:01:57 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 06:01:57 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v2]
In-Reply-To: <X7sRg2P-LJuaj4e_S4r3O2sk3WnBjH51969nKbZtM_4=.f7d0e65e-96d0-4ea6-89b2-917832e17469@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <X7sRg2P-LJuaj4e_S4r3O2sk3WnBjH51969nKbZtM_4=.f7d0e65e-96d0-4ea6-89b2-917832e17469@github.com>
Message-ID: <xWTb6tzn7JWfmDfuC0uBbTL3XZu-Jv0NCoMHf2yR5kA=.e144bcb5-2949-43a5-8d83-93aab7b45c93@github.com>

On Thu, 1 May 2025 21:08:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing bugid to tests
>   Applied review suggestions.
>   Added convenience methods to StringLatin1 for 4 and 5 character literals to leverage optimizations for merged stores.
>   Updated missing copyright years.

The test code in java/lang/Helper.java needs to be changed to fix the build error


// test/hotspot/jtreg/compiler/patches/java.base/java/lang/Helper.java
package java.lang;

class Helper {
    public static int putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
        int end = i + 4;
        StringUTF16.checkBoundsBeginEnd(i, end, value);
        StringUTF16.putCharsAt(value, i, c1, c2, c3, c4);
        return end;
    }

    public static int putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4, char c5) {
        int end = i + 5;
        StringUTF16.checkBoundsBeginEnd(i, end, value);
        StringUTF16.putCharsAt(value, i, c1, c2, c3, c4, c5);
        return end;
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/24967#issuecomment-2846432424

From swen at openjdk.org  Fri May  2 06:07:47 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 06:07:47 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v2]
In-Reply-To: <X7sRg2P-LJuaj4e_S4r3O2sk3WnBjH51969nKbZtM_4=.f7d0e65e-96d0-4ea6-89b2-917832e17469@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <X7sRg2P-LJuaj4e_S4r3O2sk3WnBjH51969nKbZtM_4=.f7d0e65e-96d0-4ea6-89b2-917832e17469@github.com>
Message-ID: <gsg-wZtFGNPlVSoA9drfcNn-NR6ZNDJD7kWb3ChPGUw=.fc188e30-c0e7-495a-ba6b-902aa08af489@github.com>

On Thu, 1 May 2025 21:08:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing bugid to tests
>   Applied review suggestions.
>   Added convenience methods to StringLatin1 for 4 and 5 character literals to leverage optimizations for merged stores.
>   Updated missing copyright years.

src/java.base/share/classes/java/lang/StringUTF16.java line 1538:

> 1536:         putChar(value, i++, c3);
> 1537:         putChar(value, i++, c4);
> 1538:         assert(i == end);

Suggestion:

        checkBoundsBeginEnd(i, end, value);
        putChar(value, i    , c1);
        putChar(value, i + 1, c2);
        putChar(value, i + 2, c3);
        putChar(value, i + 3, c4);


StringUTF16 can also use `+1 +2 +3` to replace `++`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2071140535

From jlahoda at openjdk.org  Fri May  2 06:13:57 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 2 May 2025 06:13:57 GMT
Subject: Integrated: 8344706: Implement JEP 512: Compact Source Files and
 Instance Main Methods
In-Reply-To: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
Message-ID: <7qJ1POdMGcRYtfcq6u1v6pcCu3MCfOFXoAZIyOf9IVA=.aeb8b7db-e8bf-4db9-9dcc-fd7f55549c39@github.com>

On Fri, 4 Apr 2025 07:20:23 GMT, Jan Lahoda <jlahoda at openjdk.org> 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`)

This pull request has now been integrated.

Changeset: d29700cc
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d29700cc80003d6baddb419f2974ab226478bacc
Stats:     1061 lines in 59 files changed: 336 ins; 585 del; 140 mod

8344706: Implement JEP 512: Compact Source Files and Instance Main Methods

Co-authored-by: Stuart Marks <smarks at openjdk.org>
Reviewed-by: liach, cstein, vromero, naoto

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

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

From duke at openjdk.org  Fri May  2 06:18:46 2025
From: duke at openjdk.org (Markus KARG)
Date: Fri, 2 May 2025 06:18:46 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 UTF16::compress & Unsafe::copyMemory
In-Reply-To: <2zlSFcT1XiOm_I2AsEmRYsi3hPVec_7BEIhxFI5wyro=.5f31ddfe-29b4-4794-906f-8865d7e57121@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <2zlSFcT1XiOm_I2AsEmRYsi3hPVec_7BEIhxFI5wyro=.5f31ddfe-29b4-4794-906f-8865d7e57121@github.com>
Message-ID: <7X7GuAy6-NuAZ1aAqm2M7B6HGm-j7WZ_kmTCbdJRxdk=.5978203c-2997-4bfa-8f2e-fb7d4e3c3d07@github.com>

On Mon, 21 Apr 2025 15:19:40 GMT, Chen Liang <liach at openjdk.org> wrote:

> This might be helpful combined with #21730.

That implies creating a copy of the chars:


private final void appendChars(CharSequence s, int off, int end) {
    if (isLatin1()) {
        byte[] val = this.value;

        // ----- Begin of Experimental Section -----
        char[] ca = new char[end - off];
        s.getChars(off, end, ca, 0);
        int compressed = StringUTF16.compress(ca, 0, val, count, end - off);
        count += compressed;
        off += compressed;
        // ----- End of Experimental Section -----

        for (int i = off, j = count; i < end; i++) {
            char c = s.charAt(i);
            if (StringLatin1.canEncode(c)) {
                val[j++] = (byte)c;
            } else {
                count = j;
                inflate();
                // Store c to make sure sb has a UTF16 char
                StringUTF16.putCharSB(this.value, j++, c);
                count = j;
                i++;
                StringUTF16.putCharsSB(this.value, j, s, i, end);
                count += end - i;
                return;
            }
        }
    } else {
        StringUTF16.putCharsSB(this.value, count, s, off, end);
    }
    count += end - off;
}


While I do *assume* that it should faster to let machine code perform the copy and compression over letting Java code perform a char-by-char approach, to be sure there should be another benchmark to actually proof this claim.

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

PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-2846452819

From swen at openjdk.org  Fri May  2 06:18:47 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 06:18:47 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v2]
In-Reply-To: <X7sRg2P-LJuaj4e_S4r3O2sk3WnBjH51969nKbZtM_4=.f7d0e65e-96d0-4ea6-89b2-917832e17469@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <X7sRg2P-LJuaj4e_S4r3O2sk3WnBjH51969nKbZtM_4=.f7d0e65e-96d0-4ea6-89b2-917832e17469@github.com>
Message-ID: <Zp0KfZ2dxOAT7bO97c7VewmeqUxIyKJ7Ndt_cGqqem0=.e2a9743e-3c1c-48b9-9e71-f1ae90d13640@github.com>

On Thu, 1 May 2025 21:08:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing bugid to tests
>   Applied review suggestions.
>   Added convenience methods to StringLatin1 for 4 and 5 character literals to leverage optimizations for merged stores.
>   Updated missing copyright years.

src/java.base/share/classes/java/lang/StringUTF16.java line 1549:

> 1547:         putChar(value, i++, c4);
> 1548:         putChar(value, i++, c5);
> 1549:         assert(i == end);

We can also use `+1 +2 +3 +4` to replace `++`

        checkBoundsBeginEnd(i, end, value);
        putChar(value, i    , c1);
        putChar(value, i + 1, c2);
        putChar(value, i + 2, c3);
        putChar(value, i + 3, c4);
        putChar(value, i + 4, c5);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2071148628

From epeter at openjdk.org  Fri May  2 06:31:51 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 2 May 2025 06:31:51 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v4]
In-Reply-To: <NETYBagyHXjwUHDzO8Lko4pgtjXm105d9COgS0-Ja7M=.55a9d4bf-9a61-45bd-9848-693ab7cb444b@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <J2uce-Koxq3zh8Fw16I10d6xvZAn9OZv0PpX8iI597I=.962dd328-f9fb-4882-8e66-b84a179552df@github.com>
 <NETYBagyHXjwUHDzO8Lko4pgtjXm105d9COgS0-Ja7M=.55a9d4bf-9a61-45bd-9848-693ab7cb444b@github.com>
Message-ID: <o40v1IOifQIXNQH1HPBfHR6xyBfZJF2pFh4dw9GdKLQ=.0e117807-a2af-4814-858b-33133c912a7f@github.com>

On Fri, 2 May 2025 06:14:19 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Update the jtreg test
>>  - Merge branch 'master' into JDK-8354242
>>  - Addressed some review comments
>>    
>>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>>    2. Improve code comments.
>>  - Merge branch 'master' into JDK-8354242
>>  - Merge branch 'master' into JDK-8354242
>>  - 8354242: VectorAPI: combine vector not operation with compare
>>    
>>    This patch optimizes the following patterns:
>>    For integer types:
>>    ```
>>    (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    ```
>>    cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>>    negative comparison of cond.
>>    
>>    For float and double types:
>>    ```
>>    (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    ```
>>    cond can be eq or ne.
>>    
>>    Benchmarks on Nvidia Grace machine with 128-bit SVE2:
>>    With option `-XX:UseSVE=2`:
>>    ```
>>    Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>>    testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>>    testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>>    testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>>    testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>>    testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>>    testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>>    testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>>    testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>>    testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
>>    testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
>>    testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	1...
>
> src/hotspot/share/opto/vectornode.cpp line 2216:
> 
>> 2214:       in2->is_predicated_vector()) {
>> 2215:     with_predicated = true;
>> 2216:   }
> 
> Suggestion:
> 
>   bool with_predicated = is_predicated_vector() ||
>                          in1->is_predicated_vector() ||
>                          in2->is_predicated_vector();

Would that not be easier to read?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2071147181

From swen at openjdk.org  Fri May  2 06:43:47 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 06:43:47 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 UTF16::compress & Unsafe::copyMemory [v4]
In-Reply-To: <V8ZrRweDmVS9HD5kY8TM6xIVWBfiZy8StMHs6LPO78o=.59017549-3ec8-4627-b206-a9e897045081@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <V8ZrRweDmVS9HD5kY8TM6xIVWBfiZy8StMHs6LPO78o=.59017549-3ec8-4627-b206-a9e897045081@github.com>
Message-ID: <WDrHW-5pKW76jwaOIxfkxjVWggYtUysQ1oc7z-f3rnc=.ef37922c-9596-4d0b-ae21-d7a06ffc5e75@github.com>

On Fri, 2 May 2025 03:49:39 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.
>> 
>> For these scenarios, we can use the intrinsic method StringUTF16.compress and Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/AbstractStringBuilder.java
>  - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/StringUTF16.java
>  - putCharsUnchecked
>  - copyright
>  - Using StringUTF16.compress to speed up LATIN1 StringBuilder append(char[])
>  - Using Unsafe.copyMemory to speed up UTF16 StringBuilder append(char[])
>  - add append(char[]) benchmark

> > This might be helpful combined with #21730.
> 
> That implies creating a copy of the chars:
> 
> ```java
> private final void appendChars(CharSequence s, int off, int end) {
>     if (isLatin1()) {
>         byte[] val = this.value;
> 
>         // ----- Begin of Experimental Section -----
>         char[] ca = new char[end - off];
>         s.getChars(off, end, ca, 0);
>         int compressed = StringUTF16.compress(ca, 0, val, count, end - off);
>         count += compressed;
>         off += compressed;
>         // ----- End of Experimental Section -----
> 
>         for (int i = off, j = count; i < end; i++) {
>             char c = s.charAt(i);
>             if (StringLatin1.canEncode(c)) {
>                 val[j++] = (byte)c;
>             } else {
>                 count = j;
>                 inflate();
>                 // Store c to make sure sb has a UTF16 char
>                 StringUTF16.putCharSB(this.value, j++, c);
>                 count = j;
>                 i++;
>                 StringUTF16.putCharsSB(this.value, j, s, i, end);
>                 count += end - i;
>                 return;
>             }
>         }
>     } else {
>         StringUTF16.putCharsSB(this.value, count, s, off, end);
>     }
>     count += end - off;
> }
> ```
> 
> While I do _assume_ that it should faster to let machine code perform the copy and compression over letting Java code perform a char-by-char approach, to be sure there should be another benchmark to actually proof this claim.


>         char[] ca = new char[end - off];

Your code here has a memory allocation, which may cause slowdown

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

PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-2846483320

From duke at openjdk.org  Fri May  2 06:43:48 2025
From: duke at openjdk.org (Markus KARG)
Date: Fri, 2 May 2025 06:43:48 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 UTF16::compress & Unsafe::copyMemory [v4]
In-Reply-To: <V8ZrRweDmVS9HD5kY8TM6xIVWBfiZy8StMHs6LPO78o=.59017549-3ec8-4627-b206-a9e897045081@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <V8ZrRweDmVS9HD5kY8TM6xIVWBfiZy8StMHs6LPO78o=.59017549-3ec8-4627-b206-a9e897045081@github.com>
Message-ID: <fmTENnnls6QlNngwvE7zC-zZWbJPYb2Qo9hhLUgV9lM=.017ce3f7-d529-40ca-8290-f8567d7f1933@github.com>

On Fri, 2 May 2025 03:49:39 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.
>> 
>> For these scenarios, we can use the intrinsic method StringUTF16.compress and Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/AbstractStringBuilder.java
>  - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/StringUTF16.java
>  - putCharsUnchecked
>  - copyright
>  - Using StringUTF16.compress to speed up LATIN1 StringBuilder append(char[])
>  - Using Unsafe.copyMemory to speed up UTF16 StringBuilder append(char[])
>  - add append(char[]) benchmark

> ```java
> >         char[] ca = new char[end - off];
> ```
> 
> Your code here has a memory allocation, which may cause slowdown

This is exactly what I wanted to express with my posting.

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

PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-2846485487

From swen at openjdk.org  Fri May  2 07:15:45 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 07:15:45 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 UTF16::compress & Unsafe::copyMemory [v4]
In-Reply-To: <fmTENnnls6QlNngwvE7zC-zZWbJPYb2Qo9hhLUgV9lM=.017ce3f7-d529-40ca-8290-f8567d7f1933@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <V8ZrRweDmVS9HD5kY8TM6xIVWBfiZy8StMHs6LPO78o=.59017549-3ec8-4627-b206-a9e897045081@github.com>
 <fmTENnnls6QlNngwvE7zC-zZWbJPYb2Qo9hhLUgV9lM=.017ce3f7-d529-40ca-8290-f8567d7f1933@github.com>
Message-ID: <Rjmq4n-QIKTcuPhiU29BsSdBWZLA2YG5S5U5mySYVMA=.6e92fd18-298e-4ce1-b78b-5e7166beaac4@github.com>

On Fri, 2 May 2025 06:41:14 GMT, Markus KARG <duke at openjdk.org> wrote:

> > ```java
> > >         char[] ca = new char[end - off];
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Your code here has a memory allocation, which may cause slowdown
> 
> This is exactly what I wanted to express with my posting.

I agree with you that this PR can improve the performance of Reader's method ` int read(char[] cbuf, int off, int len)`, but may not help the performance of Reader::getChars.

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

PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-2846530206

From mdoerr at openjdk.org  Fri May  2 08:01:52 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 2 May 2025 08:01:52 GMT
Subject: RFR: 8355979: ATTRIBUTE_NO_UBSAN needs to be extended to handle
 float divisions by zero on AIX
In-Reply-To: <CbiD1gny6_AnRa8wj35UTQrEax7JsnPJ2vOrikOWTB8=.ac4b7cee-59e8-4af9-bf46-dafc834b8c4d@github.com>
References: <CbiD1gny6_AnRa8wj35UTQrEax7JsnPJ2vOrikOWTB8=.ac4b7cee-59e8-4af9-bf46-dafc834b8c4d@github.com>
Message-ID: <XEsOFWuGuxlHBAFtAjTT-ZZ8ok3gvfNDd1y_9KhKkXo=.e2a8e1d1-720f-469f-86f7-f3c962084303@github.com>

On Wed, 30 Apr 2025 13:04:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Seems the currently used ATTRIBUTE_NO_UBSAN does not handle the exclusion of float divisions by zero.
> At least this is the case on AIX.
> 
> (seen in the jtreg test java/lang/Math/PowTests.java )

src/hotspot/share/sanitizers/ub.hpp line 39:

> 37: #define ATTRIBUTE_NO_UBSAN __attribute__((no_sanitize("undefined","float-divide-by-zero")))
> 38: #endif
> 39: #if defined(__GNUC__) && !defined(__clang__)

Maybe use `#elif`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24963#discussion_r2071246318

From pminborg at openjdk.org  Fri May  2 08:04:48 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 2 May 2025 08:04:48 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v6]
In-Reply-To: <7Cz0Yoz7CNQXNgnCNlUTI96sTtV87FsVc7sRgPAP6gU=.0b79f998-26e2-4567-af60-8bcd75391105@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
 <O8GFYpiZIN5JhdBqj7tXP9BOrkEKRpNBwOf5qo46vUs=.20384f2d-a6df-46f1-b039-92656d92fce6@github.com>
 <Lx9AhMwcKnQnfbbiB2wc2bogr5K6JIMfg4a250mwqZ8=.539cdc45-893c-4a76-bd4f-8115ed261c14@github.com>
 <7Cz0Yoz7CNQXNgnCNlUTI96sTtV87FsVc7sRgPAP6gU=.0b79f998-26e2-4567-af60-8bcd75391105@github.com>
Message-ID: <epGl738pjJF33giEsR3juqs50wzb6cEKgRhArqaYALY=.d6c3a8fe-5bb5-497d-bf10-838fd529a7b1@github.com>

On Thu, 1 May 2025 09:09:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Ugh - it's a record, I see. Which brings up the question -- should it be a record? Should it advertize its `size and `tl` components (they seem rather implementation specific?).
>
> Was this done so that the final field could be trusted? (I believe all final fields are implicitly trusted in jdk/internal/foreign):
> 
> 
>       holder->is_in_package("jdk/internal/foreign/layout") || holder->is_in_package("jdk/internal/foreign") ||

Yes. We should revert to a normal class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071249389

From pminborg at openjdk.org  Fri May  2 08:04:50 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 2 May 2025 08:04:50 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v6]
In-Reply-To: <8zAGokzs5CTDvvlNRh8YRaMDChm9Qi4RCWI2SBihE3w=.ade66b03-422a-4cd2-9d1d-085d8a3cae0b@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
 <8zAGokzs5CTDvvlNRh8YRaMDChm9Qi4RCWI2SBihE3w=.ade66b03-422a-4cd2-9d1d-085d8a3cae0b@github.com>
Message-ID: <9wYUZVaWE0sWHHMNJ7hK2uKyTSFaAuCddS32S4PINTE=.9ae90209-ec8b-4d5f-a302-6c3c9566bcb6@github.com>

On Wed, 30 Apr 2025 17:59:31 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve on comments
>
> test/jdk/java/foreign/TestBufferStackStress2.java line 98:
> 
>> 96:                         System.gc();
>> 97:                     }
>> 98:                     segment.get(ValueLayout.JAVA_BYTE, i);
> 
> Won't this read out of bounds? `SMALL_ALLOC_SIZE` is only 8.

Good catch! I will fix that and also add a check that the VT is completed as expected to avoid such issues in the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071248812

From mbaesken at openjdk.org  Fri May  2 08:13:44 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 2 May 2025 08:13:44 GMT
Subject: RFR: 8355979: ATTRIBUTE_NO_UBSAN needs to be extended to handle
 float divisions by zero on AIX
In-Reply-To: <XEsOFWuGuxlHBAFtAjTT-ZZ8ok3gvfNDd1y_9KhKkXo=.e2a8e1d1-720f-469f-86f7-f3c962084303@github.com>
References: <CbiD1gny6_AnRa8wj35UTQrEax7JsnPJ2vOrikOWTB8=.ac4b7cee-59e8-4af9-bf46-dafc834b8c4d@github.com>
 <XEsOFWuGuxlHBAFtAjTT-ZZ8ok3gvfNDd1y_9KhKkXo=.e2a8e1d1-720f-469f-86f7-f3c962084303@github.com>
Message-ID: <fIRGoyEr45waI-PDp0Uynnl9ViFl-oAz4u8XS_4D-ho=.16002a72-decd-4422-b038-6ed90bcedac6@github.com>

On Fri, 2 May 2025 07:59:12 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Seems the currently used ATTRIBUTE_NO_UBSAN does not handle the exclusion of float divisions by zero.
>> At least this is the case on AIX.
>> 
>> (seen in the jtreg test java/lang/Math/PowTests.java )
>
> src/hotspot/share/sanitizers/ub.hpp line 39:
> 
>> 37: #define ATTRIBUTE_NO_UBSAN __attribute__((no_sanitize("undefined","float-divide-by-zero")))
>> 38: #endif
>> 39: #if defined(__GNUC__) && !defined(__clang__)
> 
> Maybe use `#elif`?

Or should I try to set it for BOTH clang and gcc so that the added checks are not needed any more?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24963#discussion_r2071258909

From swen at openjdk.org  Fri May  2 08:14:50 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 08:14:50 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v6]
In-Reply-To: <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <m7hVIJQ8z71NuuKtdlzwPxNwsOdiZ6SBdAkD80m3z2U=.152c926d-3949-4069-b085-d7ac2de99180@github.com>
Message-ID: <0L6OqV-kWUKj74gabM-sbchxjWPPVuOv7ZsnXDX5D4k=.576321e2-146e-440a-b28e-38a37f491c8c@github.com>

On Wed, 30 Apr 2025 15:33:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
>> 
>> Re-allocated segments are not zeroed between allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve on comments

src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 108:

> 106:             final Arena arena = Arena.ofAuto();
> 107:             final SlicingAllocator stack = new SlicingAllocator(arena.allocate(size));
> 108:             return new PerThread(new ReentrantLock(), stack, arena);

Suggestion:

            final Arena arena = Arena.ofAuto();
            return new PerThread(new ReentrantLock(), 
                                 new SlicingAllocator(arena.allocate(size)), arena);
        }

The local variable stack is only used once, is it okay not to use it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071260412

From duke at openjdk.org  Fri May  2 09:01:57 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 2 May 2025 09:01:57 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v49]
In-Reply-To: <xpyRj89EdLeIFsZU8G6VQBoMBQFL6De4oudg3VZYykw=.03af0543-59be-4a57-878a-14e7ec328895@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <xpyRj89EdLeIFsZU8G6VQBoMBQFL6De4oudg3VZYykw=.03af0543-59be-4a57-878a-14e7ec328895@github.com>
Message-ID: <dBN1LlCpOR8fI8WrGc6DLgyrpjHLkUEG5-SsFWh2yTI=.3ec9eb2b-4d11-4e8f-9983-ecdac932beb3@github.com>

On Wed, 30 Apr 2025 15:59:05 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify long power computing

> Is there a reason this cannot simply be the traditional "repeated square" method? Why this complexity?

@rgiulietti By the way, could make sense recycling this algorithm scheme to speed up the computing of powers of `int`s that don't fit into a `long`, using `unsignedLongPow(long, int)` instead of `Math.pow()`?

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

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2846711109

From mli at openjdk.org  Fri May  2 09:11:47 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 2 May 2025 09:11:47 GMT
Subject: RFR: 8355698: JDK not supporting sleef could cause exception at
 runtime after JDK-8353786
In-Reply-To: <t3-LblM11MfXbtELuHBEddLiMvzJvXn1XRAgzTogEEg=.86147be4-7f53-429f-ab63-5bf35f100b3e@github.com>
References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
 <t3-LblM11MfXbtELuHBEddLiMvzJvXn1XRAgzTogEEg=.86147be4-7f53-429f-ab63-5bf35f100b3e@github.com>
Message-ID: <Ig_1_-WcP2v4JV3cJb9EqwQaaJBKqW4CBrfyufd0X4c=.68769185-c574-4084-b94a-908311fde4d7@github.com>

On Thu, 1 May 2025 18:27:24 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> I want to understand the issue with missing entries in vector math native libraries first before making a decision how to proceed.
> 
> > I don't think it's a build issue, the jdk vendor can choose to support it or not, it's just the way passing the information ( whether it's supported or not) are different.
> 
> Sorry, I don't get it. How does it affect the contents of the native library? JDK vendors do have an option to bundle the library or drop it from their distribution. But when SLEEF-based and SVML math libraries are built by JDK there's no distinction between entries being included in the library. If a vendor modifies make files or native library code, it's up to them to adjust JDK accordingly. Upstream JDK doesn't have to take such scenarios into account.

Sorry for confusing you. No, what I mean is vendors can choose their build environment (e.g. with/without support of compiler, I discuss this a bit below), and different environment will lead to whether sleef is supported or not (i.e. whether there are entries in the libsleef.so).

> 
> I looked through SVML and SLEEF-based vector math code and noticed there are some capability check [1] [2] [3] guarding library code. It means that if some library entry is missing, then the whole library is empty. Can you confirm it's the case you see?
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/linux/native/libjsvml/globals_vectorApiSupport_linux.S.inc#L35 [2] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/windows/native/libjsvml/globals_vectorApiSupport_windows.S.inc#L28 [3] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/unix/native/libsleef/lib/vector_math_rvv.c#L36

In riscv sleef case, yes, it checks native compiler version and a flat, this is required because only these versions (or higher) support vector intrinsics which are used in sleef header files. ( I think arm is the same case, but in a bit simpler way only with a flag).

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

PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2846731509

From swen at openjdk.org  Fri May  2 09:19:50 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 09:19:50 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v5]
In-Reply-To: <pFqJMH_PewqEAzplGKZ-lKBkLvpPbveqtDQM4IBEeaw=.e45e3672-30aa-48cb-8595-74425c197abb@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
 <pFqJMH_PewqEAzplGKZ-lKBkLvpPbveqtDQM4IBEeaw=.e45e3672-30aa-48cb-8595-74425c197abb@github.com>
Message-ID: <CqKcYzzFwzgV8opOczzO693TGt1OZgwGZo4JZj4DkYw=.efb51187-e82c-4053-8bd0-59f2ff7cf4b6@github.com>

On Thu, 9 Jan 2025 10:55:16 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> See the JBS bug for some details.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into 8343829
>  - Redacted comments.
>  - Merge branch 'master' into 8343829
>  - Minors in comments.
>  - Removed repeated comment.
>  - Refactoring some code and comments.
>  - 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal

static final int BIG_DECIMAL_EXPONENT = 324;

The BIG_DECIMAL_EXPONENT in line 50 is no longer used and can be removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2846746380

From duke at openjdk.org  Fri May  2 10:00:07 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Fri, 2 May 2025 10:00:07 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v3]
In-Reply-To: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
Message-ID: <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>

> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails

PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:

  Refactor container runtime version code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24948/files
  - new: https://git.openjdk.org/jdk/pull/24948/files/223a5d1b..3b18431d

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

  Stats: 246 lines in 3 files changed: 111 ins; 133 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24948.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24948/head:pull/24948

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

From duke at openjdk.org  Fri May  2 10:00:07 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Fri, 2 May 2025 10:00:07 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v3]
In-Reply-To: <sfs4XqjhfAI3QClqD5Py5_GCb5j7IsUjYz3F-sef0vk=.57fc740a-5005-4847-a131-6c8096cce22b@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <gEphzrXGgqwTdEt_h7V2O0QnbsxyKNFGP-lBeTS1c8w=.adcb76ed-5812-4b6e-a678-442b17ab7e71@github.com>
 <sfs4XqjhfAI3QClqD5Py5_GCb5j7IsUjYz3F-sef0vk=.57fc740a-5005-4847-a131-6c8096cce22b@github.com>
Message-ID: <_D4nqTI9xJUe43WrWHRaozFfHG5HQSv-jzFSNnrggmo=.fc3318d8-a776-48a3-b564-2d8e376bc299@github.com>

On Tue, 29 Apr 2025 20:18:17 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor container runtime version code
>
> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 74:
> 
>> 72:             return;
>> 73:         }
>> 74:         if (IS_DOCKER && TestDockerMemoryMetricsSubgroup.DockerVersion.VERSION_20_10_0.compareTo(getDockerVersion()) > 0) {
> 
> Should this change also cover Podman, in which the minimum version that supports `--cgroupns` is 3.0 ?

updated for podman
In podman cgroupns support was added in 1.5.0
https://github.com/containers/podman/releases?page=18

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2071383984

From duke at openjdk.org  Fri May  2 10:00:08 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Fri, 2 May 2025 10:00:08 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v2]
In-Reply-To: <sfs4XqjhfAI3QClqD5Py5_GCb5j7IsUjYz3F-sef0vk=.57fc740a-5005-4847-a131-6c8096cce22b@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <gEphzrXGgqwTdEt_h7V2O0QnbsxyKNFGP-lBeTS1c8w=.adcb76ed-5812-4b6e-a678-442b17ab7e71@github.com>
 <sfs4XqjhfAI3QClqD5Py5_GCb5j7IsUjYz3F-sef0vk=.57fc740a-5005-4847-a131-6c8096cce22b@github.com>
Message-ID: <u6kJNmpRYPZSpoMT-87HNpk4orqhAqXeFySOu1SnY7Y=.e530c9cc-1ee2-4135-a8c5-281f36dcbb14@github.com>

On Tue, 29 Apr 2025 20:28:36 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update reference of DockerVersion
>
> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 149:
> 
>> 147:     }
>> 148: 
>> 149:     private static class DockerVersion implements Comparable<TestDockerMemoryMetricsSubgroup.DockerVersion> {
> 
> The same code is added to multiple tests.

Created a util file for common code

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2071384406

From pminborg at openjdk.org  Fri May  2 10:40:04 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 2 May 2025 10:40:04 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v7]
In-Reply-To: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
Message-ID: <ePNPHPWO8a-gQ_jVczzNV8E_Qi37E1wVi_4WHNVYkXk=.c03ab70f-8401-44e8-ac72-4f9e86287542@github.com>

> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
> 
> Re-allocated segments are not zeroed between allocations.

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

  Address comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24829/files
  - new: https://git.openjdk.org/jdk/pull/24829/files/22c384f9..dcce2e94

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

  Stats: 165 lines in 6 files changed: 71 ins; 43 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/24829.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24829/head:pull/24829

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

From pminborg at openjdk.org  Fri May  2 10:43:46 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 2 May 2025 10:43:46 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v7]
In-Reply-To: <ePNPHPWO8a-gQ_jVczzNV8E_Qi37E1wVi_4WHNVYkXk=.c03ab70f-8401-44e8-ac72-4f9e86287542@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <ePNPHPWO8a-gQ_jVczzNV8E_Qi37E1wVi_4WHNVYkXk=.c03ab70f-8401-44e8-ac72-4f9e86287542@github.com>
Message-ID: <N7NsUmQu0BcYHHO2YWEoKzsugsJop30V6mYTRL3H3Xc=.8c9a6fa3-b39a-4aca-bf98-dade9489bb12@github.com>

On Fri, 2 May 2025 10:40:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
>> 
>> Re-allocated segments are not zeroed between allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

Updated benchmarks:


Benchmark                            (ELEM_SIZE)  Mode  Cnt   Score   Error  Units
BufferStackBench.OfVirtual.buffer              8  avgt   15  12.695 ? 0.205  ns/op
BufferStackBench.OfVirtual.buffer             16  avgt   15  12.622 ? 0.078  ns/op
BufferStackBench.OfVirtual.buffer             32  avgt   15  12.523 ? 0.022  ns/op
BufferStackBench.OfVirtual.confined            8  avgt   15  22.902 ? 0.407  ns/op
BufferStackBench.OfVirtual.confined           16  avgt   15  23.858 ? 0.652  ns/op
BufferStackBench.OfVirtual.confined           32  avgt   15  25.544 ? 0.458  ns/op
BufferStackBench.buffer                        8  avgt   15   4.923 ? 0.029  ns/op
BufferStackBench.buffer                       16  avgt   15   4.971 ? 0.095  ns/op
BufferStackBench.buffer                       32  avgt   15   4.980 ? 0.105  ns/op
BufferStackBench.confined                      8  avgt   15  22.713 ? 0.289  ns/op
BufferStackBench.confined                     16  avgt   15  23.576 ? 0.348  ns/op
BufferStackBench.confined                     32  avgt   15  25.272 ? 0.530  ns/op


and


vBenchmark                              Mode  Cnt   Score   Error  Units
CallOverheadByValue.OfVirtual.byPtr    avgt   15   4.159 ? 0.097  ns/op
CallOverheadByValue.OfVirtual.byValue  avgt   15  16.535 ? 0.433  ns/op
CallOverheadByValue.byPtr              avgt   15   4.119 ? 0.031  ns/op
CallOverheadByValue.byValue            avgt   15  11.404 ? 0.240  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2846906803

From mli at openjdk.org  Fri May  2 10:48:50 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 2 May 2025 10:48:50 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v4]
In-Reply-To: <sNCddHgt1VcN3PisyrKHnZeDP3Mz8j9sgZCY0cIyG6c=.e0a5ccd3-c432-4557-9c7a-804896590854@github.com>
References: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
 <sNCddHgt1VcN3PisyrKHnZeDP3Mz8j9sgZCY0cIyG6c=.e0a5ccd3-c432-4557-9c7a-804896590854@github.com>
Message-ID: <-bAHBy4AmqSglDpT2t94FrSQ7n1oFPkBDuxfcd2C0A8=.802dff01-b8da-439e-8b80-aa5dddc4031c@github.com>

On Wed, 30 Apr 2025 12:00:45 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, for you to consider.
>> 
>> These tests constantly fails in qemu-user.
>> Either the require host to be same arch explicit or implicit (sysroot).
>> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests.
>> 
>> From bug:
>>> qemu-user/rv64 sets uarch to "qemu" in /proc/cpuinfo (qemu-system do not do that).
>>> We add this uarch to CPU feature string.
>>> This means we can use jtreg 'require' with cpu string to filter out tests in qemu-user.
>> 
>> Relevant qemu code:
>> https://github.com/qemu/qemu/blob/170825d14d88a1ce7fae98d5a928480f2f329b22/linux-user/riscv/target_proc.h#L29
>> 
>> Relevant hotspot code:
>> https://github.com/openjdk/jdk/blob/fa0b18bfde38ee2ffbab33a9eaac547fe8aa3c7c/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L250
>> 
>> Tested that the require only filters out tests in qemu+riscv64.
>> 
>> Thanks!
>> 
>> /Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into qemu-user-issues
>  - Merge branch 'master' into qemu-user-issues
>  - Revert
>  - Merge branch 'master' into qemu-user-issues
>  - Merge branch 'master' into qemu-user-issues
>  - more
>  - more
>  - native or very long

Looks good, thanks for fixing this and discussing!

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

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24229#pullrequestreview-2811707177

From pminborg at openjdk.org  Fri May  2 11:13:27 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 2 May 2025 11:13:27 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v8]
In-Reply-To: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
Message-ID: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>

> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
> 
> Re-allocated segments are not zeroed between allocations.

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

  Cleanup and only create CleanupAction once per thread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24829/files
  - new: https://git.openjdk.org/jdk/pull/24829/files/dcce2e94..c819553c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24829&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24829&range=06-07

  Stats: 33 lines in 2 files changed: 15 ins; 8 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24829.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24829/head:pull/24829

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

From swen at openjdk.org  Fri May  2 11:24:50 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 11:24:50 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v7]
In-Reply-To: <ePNPHPWO8a-gQ_jVczzNV8E_Qi37E1wVi_4WHNVYkXk=.c03ab70f-8401-44e8-ac72-4f9e86287542@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <ePNPHPWO8a-gQ_jVczzNV8E_Qi37E1wVi_4WHNVYkXk=.c03ab70f-8401-44e8-ac72-4f9e86287542@github.com>
Message-ID: <YI2FARstQribZckt1fd5GJmQflSGNo3WtaR4x6ZAFXg=.b8d69e65-758c-430d-888b-293888c7f6a9@github.com>

On Fri, 2 May 2025 10:40:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
>> 
>> Re-allocated segments are not zeroed between allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 186:

> 184:             }
> 185:         }
> 186:     }

Suggestion:

    private record PerThread(ReentrantLock lock, Arena arena, SlicingAllocator stack) {

        @ForceInline
        @SuppressWarnings("restricted")
        public Arena pushFrame(long size, long byteAlignment) {
            boolean needsLock = Thread.currentThread().isVirtual() && !lock.isHeldByCurrentThread();
            if (needsLock && !lock.tryLock()) {
                // Rare: another virtual thread on the same carrier competed for acquisition.
                return Arena.ofConfined();
            }
            if (!stack.canAllocate(size, byteAlignment)) {
                if (needsLock) lock.unlock();
                return Arena.ofConfined();
            }

            Arena confinedArena = Arena.ofConfined();
            long parentOffset = stack.currentOffset();
            MemorySegment frameSegment = stack.allocate(size, byteAlignment);
            long topOfStack = stack.currentOffset();
            // The cleanup action will keep the original automatic `arena` (from which
            // the reusable segment is first allocated) alive even if this Frame
            // becomes unreachable but there are reachable segments still alive.
            SegmentAllocator frame = new SlicingAllocator(frameSegment.reinterpret(confinedArena, new Frame.CleanupAction(arena)));

            return new Frame(this, needsLock, parentOffset, topOfStack, confinedArena, frame);
        }

        static PerThread of(long byteSize, long byteAlignment) {
            final Arena arena = Arena.ofAuto();
            return new PerThread(new ReentrantLock(),
                    arena,
                    new SlicingAllocator(arena.allocate(byteSize, byteAlignment)));
        }
    }

    private record Frame(PerThread thread, boolean locked, long parentOffset, long topOfStack, Arena confinedArena, SegmentAllocator frame) implements Arena {
        record CleanupAction(Arena arena) implements Consumer<MemorySegment> {
            @Override
            public void accept(MemorySegment memorySegment) {
                Reference.reachabilityFence(arena);
            }
        }

        @ForceInline
        private void assertOrder() {
            if (topOfStack != thread.stack.currentOffset())
                throw new IllegalStateException("Out of order access: frame not top-of-stack");
        }

        @ForceInline
        @Override
        @SuppressWarnings("restricted")
        public MemorySegment allocate(long byteSize, long byteAlignment) {
            // Make sure we are on the right thread and not closed
            MemorySessionImpl.toMemorySession(confinedArena).checkValidState();
            return frame.allocate(byteSize, byteAlignment);
        }

        @ForceInline
        @Override
        public MemorySegment.Scope scope() {
            return confinedArena.scope();
        }

        @ForceInline
        @Override
        public void close() {
            assertOrder();
            // the Arena::close method is called "early" as it checks thread
            // confinement and crucially before any mutation of the internal
            // state takes place.
            confinedArena.close();
            thread.stack.resetTo(parentOffset);
            if (locked) {
                thread.lock.unlock();
            }
        }
    }

I find it a bit strange to nest a class inside a record. What do you think if I change it to two records?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071471740

From swen at openjdk.org  Fri May  2 11:33:48 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 11:33:48 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v8]
In-Reply-To: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
Message-ID: <IXD9PqL5gFuYIq-xYjNHDdNICOMnKOn2Cb6mRxn9TCs=.d5d08dcd-f7d4-4302-b4bb-45a0b8cbad6a@github.com>

On Fri, 2 May 2025 11:13:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
>> 
>> Re-allocated segments are not zeroed between allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup and only create CleanupAction once per thread

src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 194:

> 192:             }
> 193:         }
> 194:     }

Suggestion:

    private record PerThread(ReentrantLock lock,
                             Arena arena,
                             SlicingAllocator stack,
                             CleanupAction cleanupAction) {

        @SuppressWarnings("restricted")
        @ForceInline
        public Arena pushFrame(long size, long byteAlignment) {
            boolean needsLock = Thread.currentThread().isVirtual() && !lock.isHeldByCurrentThread();
            if (needsLock && !lock.tryLock()) {
                // Rare: another virtual thread on the same carrier competed for acquisition.
                return Arena.ofConfined();
            }
            if (!stack.canAllocate(size, byteAlignment)) {
                if (needsLock) lock.unlock();
                return Arena.ofConfined();
            }

            long parentOffset = stack.currentOffset();
            final MemorySegment frameSegment = stack.allocate(size, byteAlignment);
            long topOfStack = stack.currentOffset();
            Arena confinedArena = Arena.ofConfined();
            // return new Frame(needsLock, size, byte
            // The cleanup action will keep the original automatic `arena` (from which
            // the reusable segment is first allocated) alive even if this Frame
            // becomes unreachable but there are reachable segments still alive.
            return new Frame(this, needsLock, parentOffset, topOfStack, confinedArena, new SlicingAllocator(frameSegment.reinterpret(confinedArena, cleanupAction)));
        }

        static PerThread of(long byteSize, long byteAlignment) {
            final Arena arena = Arena.ofAuto();
            return new PerThread(new ReentrantLock(),
                    arena,
                    new SlicingAllocator(arena.allocate(byteSize, byteAlignment)),
                    new CleanupAction(arena));
        }

        private record CleanupAction(Arena arena) implements Consumer<MemorySegment> {
            @Override
            public void accept(MemorySegment memorySegment) {
                Reference.reachabilityFence(arena);
            }
        }
    }

    private record Frame(PerThread thead, boolean locked, long parentOffset, long topOfStack, Arena confinedArena, SegmentAllocator frame) implements Arena {

        @ForceInline
        private void assertOrder() {
            if (topOfStack != thead.stack.currentOffset())
                throw new IllegalStateException("Out of order access: frame not top-of-stack");
        }

        @ForceInline
        @Override
        @SuppressWarnings("restricted")
        public MemorySegment allocate(long byteSize, long byteAlignment) {
            // Make sure we are on the right thread and not closed
            MemorySessionImpl.toMemorySession(confinedArena).checkValidState();
            return frame.allocate(byteSize, byteAlignment);
        }

        @ForceInline
        @Override
        public MemorySegment.Scope scope() {
            return confinedArena.scope();
        }

        @ForceInline
        @Override
        public void close() {
            assertOrder();
            // the Arena::close method is called "early" as it checks thread
            // confinement and crucially before any mutation of the internal
            // state takes place.
            confinedArena.close();
            thead.stack.resetTo(parentOffset);
            if (locked) {
                thead.lock.unlock();
            }
        }
    }


Same as the suggestion above, you changed the code. I updated and remade the suggestion and changed it to two records. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071481137

From mcimadamore at openjdk.org  Fri May  2 11:39:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 May 2025 11:39:53 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v8]
In-Reply-To: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
Message-ID: <9wPukxFBvu0fk_O1fNfNZ4DPfEE_Z-fJi7ubiGwq-Ds=.3435ebd8-bab8-4a70-9926-4586df035ce6@github.com>

On Fri, 2 May 2025 11:13:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
>> 
>> Re-allocated segments are not zeroed between allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup and only create CleanupAction once per thread

src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 127:

> 125:                     arena,
> 126:                     new SlicingAllocator(arena.allocate(byteSize, byteAlignment)),
> 127:                     new CleanupAction(arena));

any reason why you didn't use a lambda here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071487667

From aph-open at littlepinkcloud.com  Fri May  2 11:43:37 2025
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Fri, 2 May 2025 12:43:37 +0100
Subject: RFR: 8355698: JDK not supporting sleef could cause exception at
 runtime after JDK-8353786
In-Reply-To: <Ig_1_-WcP2v4JV3cJb9EqwQaaJBKqW4CBrfyufd0X4c=.68769185-c574-4084-b94a-908311fde4d7@github.com>
References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
 <t3-LblM11MfXbtELuHBEddLiMvzJvXn1XRAgzTogEEg=.86147be4-7f53-429f-ab63-5bf35f100b3e@github.com>
 <Ig_1_-WcP2v4JV3cJb9EqwQaaJBKqW4CBrfyufd0X4c=.68769185-c574-4084-b94a-908311fde4d7@github.com>
Message-ID: <d463bf5c-3a9f-4523-b457-ff43bd5261b4@littlepinkcloud.com>

On 5/2/25 10:11, Hamlin Li wrote:
> what I mean is vendors can choose their build environment (e.g. with/without support of compiler, I discuss this a bit below), and different environment will lead to whether sleef is supported or not (i.e. whether there are entries in the libsleef.so).

Again, this is an unhelpful thing to do. If the environment doesn't 
support building the full JDK, kick it out.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at openjdk.org  Fri May  2 11:43:47 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 2 May 2025 11:43:47 GMT
Subject: RFR: 8355698: JDK not supporting sleef could cause exception at
 runtime after JDK-8353786
In-Reply-To: <Np9_Py66RkB-RMq1Uri-J3C6xEcgpAeKiqBWNZWC-fk=.ff9f9610-98a8-4e1d-b5b2-191444284e32@github.com>
References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
 <t5yCh_uHzYvMEUCimBleAdsx_rHcD5tic0NqclC7z4Q=.96e18401-96e1-4723-98dd-e12b70933df8@github.com>
 <3BMQiQtyRXIj-NFUoFPliNYV4r1nX3KpKgniMvtOMkc=.cdcd240e-ce85-46c7-9bfb-e5be5124aae9@github.com>
 <PfjjyqfVNfWSyegFjmOOzmyafV46dlMp5mewRvoOn1Q=.48092ede-8990-4fcd-8cbf-64db021374b7@github.com>
 <sCvv_ZdnRtPqNXffYKzKMcK5OUTsree7QbfevmAAQuI=.fdd11430-94a0-4849-8ce1-613da7f92311@github.com>
 <1hfhvGjxKFAYEtj1D_pIdgU659AE2oPWoQEyXl8sRgQ=.3aa62617-142a-49c9-82c4-0f761cb73aff@github.com>
 <Np9_Py66RkB-RMq1Uri-J3C6xEcgpAeKiqBWNZWC-fk=.ff9f9610-98a8-4e1d-b5b2-191444284e32@github.com>
Message-ID: <_Zjv0l0jFcm3LyXV8aU8IdBDIiXTGatgRfV5BEv6_Fc=.1b5646f8-f905-45e8-9d7f-aec437edfb84@github.com>

On Thu, 1 May 2025 08:50:27 GMT, Hamlin Li <mli at openjdk.org> wrote:

> > Overall, it still looks like a JDK build issue to me. Hiding problems occurred during the build is not good. If some toolchains can't successfully build the library, the library shouldn't be included in JDK.
> 
> No, in riscv case (possiblely also on arm?) I don't think it's a build issue, the jdk vendor can choose to support it or not, it's just the way passing the information ( whether it's supported or not) are different.

I am not convinced that supporting such a divergence between builds of the JDK is something we should support. Sure, we can choose at runtime whether to link with SLEEF or not, but having some builds of (say) risc OpenJDK with SLEEF and some without is a Bad Thing. It is a build issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2847012173

From mcimadamore at openjdk.org  Fri May  2 11:44:48 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 May 2025 11:44:48 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v7]
In-Reply-To: <N7NsUmQu0BcYHHO2YWEoKzsugsJop30V6mYTRL3H3Xc=.8c9a6fa3-b39a-4aca-bf98-dade9489bb12@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <ePNPHPWO8a-gQ_jVczzNV8E_Qi37E1wVi_4WHNVYkXk=.c03ab70f-8401-44e8-ac72-4f9e86287542@github.com>
 <N7NsUmQu0BcYHHO2YWEoKzsugsJop30V6mYTRL3H3Xc=.8c9a6fa3-b39a-4aca-bf98-dade9489bb12@github.com>
Message-ID: <UQwKa0GLRp7EAi9beqMDJfYegt9MkvE8YBANHEEtack=.6b79e776-d9b9-4dea-82af-ae7c935d99bd@github.com>

On Fri, 2 May 2025 10:41:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Updated benchmarks:
> 
> ```
> Benchmark                            (ELEM_SIZE)  Mode  Cnt   Score   Error  Units
> BufferStackBench.OfVirtual.buffer              8  avgt   15  12.695 ? 0.205  ns/op
> BufferStackBench.OfVirtual.buffer             16  avgt   15  12.622 ? 0.078  ns/op
> BufferStackBench.OfVirtual.buffer             32  avgt   15  12.523 ? 0.022  ns/op
> BufferStackBench.OfVirtual.confined            8  avgt   15  22.902 ? 0.407  ns/op
> BufferStackBench.OfVirtual.confined           16  avgt   15  23.858 ? 0.652  ns/op
> BufferStackBench.OfVirtual.confined           32  avgt   15  25.544 ? 0.458  ns/op
> BufferStackBench.buffer                        8  avgt   15   4.923 ? 0.029  ns/op
> BufferStackBench.buffer                       16  avgt   15   4.971 ? 0.095  ns/op
> BufferStackBench.buffer                       32  avgt   15   4.980 ? 0.105  ns/op
> BufferStackBench.confined                      8  avgt   15  22.713 ? 0.289  ns/op
> BufferStackBench.confined                     16  avgt   15  23.576 ? 0.348  ns/op
> BufferStackBench.confined                     32  avgt   15  25.272 ? 0.530  ns/op
> ```
> 
> and
> 
> ```
> Benchmark                              Mode  Cnt   Score   Error  Units
> CallOverheadByValue.OfVirtual.byPtr    avgt   15   4.159 ? 0.097  ns/op
> CallOverheadByValue.OfVirtual.byValue  avgt   15  16.535 ? 0.433  ns/op
> CallOverheadByValue.byPtr              avgt   15   4.119 ? 0.031  ns/op
> CallOverheadByValue.byValue            avgt   15  11.404 ? 0.240  ns/op
> ```

What was the result before this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2847012659

From rgiulietti at openjdk.org  Fri May  2 11:51:55 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 May 2025 11:51:55 GMT
Subject: RFR: 8355992: Add some useful "exact" methods to Math and StrictMath
Message-ID: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>

Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments.
Further, add `unsignedMultiplyExact` methods as well.

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

Commit messages:
 - 8355992: Add some useful "exact" methods to Math and StrictMath

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

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

From rgiulietti at openjdk.org  Fri May  2 11:51:56 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 May 2025 11:51:56 GMT
Subject: RFR: 8355992: Add some useful "exact" methods to Math and
 StrictMath
In-Reply-To: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
Message-ID: <8-F9aOP-sX2MrXtcHsR1vZbA9tv5YW-v3_CrkZP8Co8=.7bdee1c0-b42a-4516-93e4-8ae49af76922@github.com>

On Fri, 2 May 2025 11:47:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments.
> Further, add `unsignedMultiplyExact` methods as well.

Tests will be added once the CSR has been approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/25003#issuecomment-2847026026

From mcimadamore at openjdk.org  Fri May  2 11:52:49 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 May 2025 11:52:49 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v8]
In-Reply-To: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
Message-ID: <hwHKAnKWDW3QpfSmTMBnL02tkfzsxAKNRcZqg-ovB0M=.b3df8983-e3a8-40f4-8173-0e222d63ac94@github.com>

On Fri, 2 May 2025 11:13:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
>> 
>> Re-allocated segments are not zeroed between allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup and only create CleanupAction once per thread

Looks good - I left some stylistic comments on the use of records

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24829#pullrequestreview-2811821102

From mcimadamore at openjdk.org  Fri May  2 11:52:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 May 2025 11:52:51 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v8]
In-Reply-To: <9wPukxFBvu0fk_O1fNfNZ4DPfEE_Z-fJi7ubiGwq-Ds=.3435ebd8-bab8-4a70-9926-4586df035ce6@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
 <9wPukxFBvu0fk_O1fNfNZ4DPfEE_Z-fJi7ubiGwq-Ds=.3435ebd8-bab8-4a70-9926-4586df035ce6@github.com>
Message-ID: <JJBajx3RrQQf1rKZBeGsw-XRl5tA2cyW8hHMNHRISZA=.ad091672-f5c0-4b02-b094-e48970500c0d@github.com>

On Fri, 2 May 2025 11:36:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup and only create CleanupAction once per thread
>
> src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 127:
> 
>> 125:                     arena,
>> 126:                     new SlicingAllocator(arena.allocate(byteSize, byteAlignment)),
>> 127:                     new CleanupAction(arena));
> 
> any reason why you didn't use a lambda here?

Also, not a big fan of records here -- it seems that many implementation details such as cleanup action, lock and slicing allocator are "leaked out" to the caller, that is now responsible to set things up correctly. I think a `PerThread` class with a constructor taking arena, size, alignment would make the code less coupled and more readable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071496742

From jvernee at openjdk.org  Fri May  2 11:52:50 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 May 2025 11:52:50 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v8]
In-Reply-To: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
Message-ID: <mh4m30IhzKJHX89Nbggn9cvys1nZehCtEcDiH8VgKMc=.ebefc677-fdb9-4e30-83a7-ec24a3e20171@github.com>

On Fri, 2 May 2025 11:13:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
>> 
>> Re-allocated segments are not zeroed between allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup and only create CleanupAction once per thread

Latest version looks good to me as well.

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24829#pullrequestreview-2811825794

From mcimadamore at openjdk.org  Fri May  2 11:52:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 May 2025 11:52:51 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v8]
In-Reply-To: <JJBajx3RrQQf1rKZBeGsw-XRl5tA2cyW8hHMNHRISZA=.ad091672-f5c0-4b02-b094-e48970500c0d@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
 <9wPukxFBvu0fk_O1fNfNZ4DPfEE_Z-fJi7ubiGwq-Ds=.3435ebd8-bab8-4a70-9926-4586df035ce6@github.com>
 <JJBajx3RrQQf1rKZBeGsw-XRl5tA2cyW8hHMNHRISZA=.ad091672-f5c0-4b02-b094-e48970500c0d@github.com>
Message-ID: <0En4rtg8rommV5EHy5Jsfhuc2yOBokRo_NLOtN5ODJU=.f24966c7-23b8-40e4-bba0-ffc98dbec77e@github.com>

On Fri, 2 May 2025 11:45:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 127:
>> 
>>> 125:                     arena,
>>> 126:                     new SlicingAllocator(arena.allocate(byteSize, byteAlignment)),
>>> 127:                     new CleanupAction(arena));
>> 
>> any reason why you didn't use a lambda here?
>
> Also, not a big fan of records here -- it seems that many implementation details such as cleanup action, lock and slicing allocator are "leaked out" to the caller, that is now responsible to set things up correctly. I think a `PerThread` class with a constructor taking arena, size, alignment would make the code less coupled and more readable.

And, if you do that, you then don't need the `of` factory -- clients can just use `new`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071498324

From swen at openjdk.org  Fri May  2 11:58:50 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 11:58:50 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v8]
In-Reply-To: <0En4rtg8rommV5EHy5Jsfhuc2yOBokRo_NLOtN5ODJU=.f24966c7-23b8-40e4-bba0-ffc98dbec77e@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
 <9wPukxFBvu0fk_O1fNfNZ4DPfEE_Z-fJi7ubiGwq-Ds=.3435ebd8-bab8-4a70-9926-4586df035ce6@github.com>
 <JJBajx3RrQQf1rKZBeGsw-XRl5tA2cyW8hHMNHRISZA=.ad091672-f5c0-4b02-b094-e48970500c0d@github.com>
 <0En4rtg8rommV5EHy5Jsfhuc2yOBokRo_NLOtN5ODJU=.f24966c7-23b8-40e4-bba0-ffc98dbec77e@github.com>
Message-ID: <-bZOgYK72qj6upg_jsJ5iss0nyvYEeTYcF5Mc2Yb6Wc=.8b46ef04-48e9-421f-a035-190d455fefe7@github.com>

On Fri, 2 May 2025 11:47:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Also, not a big fan of records here -- it seems that many implementation details such as cleanup action, lock and slicing allocator are "leaked out" to the caller, that is now responsible to set things up correctly. I think a `PerThread` class with a constructor taking arena, size, alignment would make the code less coupled and more readable.
>
> And, if you do that, you then don't need the `of` factory -- clients can just use `new`

> any reason why you didn't use a lambda here?

I also think that CleanupAction should be changed to lambda

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071508856

From rgiulietti at openjdk.org  Fri May  2 12:00:13 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 May 2025 12:00:13 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v6]
In-Reply-To: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
Message-ID: <kmbi8sN1CiNsomx8-BbjpgdDiogQU0MyUXJogHChH6s=.78fd103a-9f37-475d-8108-75e851193c4f@github.com>

> See the JBS bug for some details.

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - Remove unused BIG_DECIMAL_EXPONENT
 - Merge branch 'master' into 8343829
 - Merge branch 'master' into 8343829
 - Redacted comments.
 - Merge branch 'master' into 8343829
 - Minors in comments.
 - Removed repeated comment.
 - Refactoring some code and comments.
 - 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22737/files
  - new: https://git.openjdk.org/jdk/pull/22737/files/092755b4..49ed9aac

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

  Stats: 672210 lines in 9937 files changed: 267712 ins; 352817 del; 51681 mod
  Patch: https://git.openjdk.org/jdk/pull/22737.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22737/head:pull/22737

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

From duke at openjdk.org  Fri May  2 12:06:49 2025
From: duke at openjdk.org (ExE Boss)
Date: Fri, 2 May 2025 12:06:49 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v3]
In-Reply-To: <VkBzyrZMCwgRSotwkP2RdSV3x6B83eJgZF4mU830098=.b0d247e3-966a-441c-b7a1-974613eed3b3@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <VkBzyrZMCwgRSotwkP2RdSV3x6B83eJgZF4mU830098=.b0d247e3-966a-441c-b7a1-974613eed3b3@github.com>
Message-ID: <hGvb-Sf4tz5ECqxEdvi4jAqx4RqKzeOHqZzzZwvf0M0=.4aa3eda2-7589-4aff-b7f5-502a58b53024@github.com>

On Tue, 29 Apr 2025 07:54:23 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Since when?

src/java.base/share/classes/java/lang/ScopedValue.java line 1:

> 1: /*

It?occurred to?me that?`ScopedValue.NEW_THREAD_BINDINGS` can?be?made package?private and?used in?`Thread`, removing?duplication in?`Thread.NEW_THREAD_BINDINGS`.

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

This?was?done this?way back?when `ScopedValue` lived?under the?`jdk.incubator.*` package?tree.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24923#discussion_r2071516117

From swen at openjdk.org  Fri May  2 12:10:51 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 12:10:51 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v6]
In-Reply-To: <kmbi8sN1CiNsomx8-BbjpgdDiogQU0MyUXJogHChH6s=.78fd103a-9f37-475d-8108-75e851193c4f@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
 <kmbi8sN1CiNsomx8-BbjpgdDiogQU0MyUXJogHChH6s=.78fd103a-9f37-475d-8108-75e851193c4f@github.com>
Message-ID: <nLxz2p6q6dW3G4BYkSHoDARiqNT-SDuXWrJJhgcPQJ4=.eb81e7e7-357f-47d5-b07d-441ef1444eda@github.com>

On Fri, 2 May 2025 12:00:13 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> See the JBS bug for some details.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Remove unused BIG_DECIMAL_EXPONENT
>  - Merge branch 'master' into 8343829
>  - Merge branch 'master' into 8343829
>  - Redacted comments.
>  - Merge branch 'master' into 8343829
>  - Minors in comments.
>  - Removed repeated comment.
>  - Refactoring some code and comments.
>  - 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 2352:

> 2350: 
> 2351:     /* The precision of the format. */
> 2352:     private static final int[] P = {

private static final int[] P
private static final int[] EP_MIN
private static final int[] EP_MAX
private static final int[] W
private static final int[] E_MAX
private static final int[] E_MIN
private static final int[] Q_MIN
private static final int[] HEX_COUNT


These should all be added with @Stable

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2071520733

From rehn at openjdk.org  Fri May  2 12:14:50 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 2 May 2025 12:14:50 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v2]
In-Reply-To: <p3aEXv6eKuMcwQPv5ks-Xp4r9FahaZebQqihAanYBuQ=.9183e101-6cc8-4b75-9e01-5c64b757cc2d@github.com>
References: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
 <Qv4mQCfYY-wxBg1sQjGbftfU68YwBBLGSjUwtpVrNAM=.a60d5570-342f-4be6-88cb-877b2b8198b1@github.com>
 <p3aEXv6eKuMcwQPv5ks-Xp4r9FahaZebQqihAanYBuQ=.9183e101-6cc8-4b75-9e01-5c64b757cc2d@github.com>
Message-ID: <Wo9l034gJIi6J6qCHg-BfWnbC0K-7Kom0fFkD3JMnNY=.8965162f-7071-49c8-a87f-90667e97bbf8@github.com>

On Thu, 27 Mar 2025 17:57:37 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> 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 four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into qemu-user-issues
>>  - more
>>  - more
>>  - native or very long
>
> I also feel annoying to see some tests fail interminently.
> 
> Not sure if I understand the goal of this pr, seems it might not be the best solution to simply disable these tests when running with qemu. My concerns are: qemu is still one of main methods to quickly verify the functionality changes, but when we just disable the failed tests, and maybe in the future disable more and more tests, then qemu is no longer able to play the role it was supposed to play.

Thanks @Hamlin-Li and @RealFYang.

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

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2847064204

From swen at openjdk.org  Fri May  2 12:26:54 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 12:26:54 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v6]
In-Reply-To: <kmbi8sN1CiNsomx8-BbjpgdDiogQU0MyUXJogHChH6s=.78fd103a-9f37-475d-8108-75e851193c4f@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
 <kmbi8sN1CiNsomx8-BbjpgdDiogQU0MyUXJogHChH6s=.78fd103a-9f37-475d-8108-75e851193c4f@github.com>
Message-ID: <iq-q7njKC0mgO9jXY6SQoTnmaDdNXUR584LM3UGJYr0=.d0a0d557-1adb-45e1-b4b7-82542aa3b836@github.com>

On Fri, 2 May 2025 12:00:13 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> See the JBS bug for some details.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Remove unused BIG_DECIMAL_EXPONENT
>  - Merge branch 'master' into 8343829
>  - Merge branch 'master' into 8343829
>  - Redacted comments.
>  - Merge branch 'master' into 8343829
>  - Minors in comments.
>  - Removed repeated comment.
>  - Refactoring some code and comments.
>  - 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal

We can do some cleanup before this PR, such as #24999

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

PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2847085253

From alanb at openjdk.org  Fri May  2 12:37:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 May 2025 12:37:48 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v3]
In-Reply-To: <hGvb-Sf4tz5ECqxEdvi4jAqx4RqKzeOHqZzzZwvf0M0=.4aa3eda2-7589-4aff-b7f5-502a58b53024@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <VkBzyrZMCwgRSotwkP2RdSV3x6B83eJgZF4mU830098=.b0d247e3-966a-441c-b7a1-974613eed3b3@github.com>
 <hGvb-Sf4tz5ECqxEdvi4jAqx4RqKzeOHqZzzZwvf0M0=.4aa3eda2-7589-4aff-b7f5-502a58b53024@github.com>
Message-ID: <k2fLo6iAq4FK9NZC1PjIGn_f2nUGIfbKYj7tcMOnWDw=.e9c6acae-c23d-4bd7-bc74-861406f5f131@github.com>

On Fri, 2 May 2025 12:03:35 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Since when?
>
> src/java.base/share/classes/java/lang/ScopedValue.java line 1:
> 
>> 1: /*
> 
> It?occurred to?me that?`ScopedValue.NEW_THREAD_BINDINGS` can?be?made package?private and?used in?`Thread`, removing?duplication in?`Thread.NEW_THREAD_BINDINGS`.
> 
> --------------------------------------------------------------------------------
> 
> This?was?done this?way back?when `ScopedValue` lived?under the?`jdk.incubator.*` package?tree.

I think it would be better not change that in this PR, as this PR is about making the feature permanent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24923#discussion_r2071550253

From rgiulietti at openjdk.org  Fri May  2 12:40:52 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 May 2025 12:40:52 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v6]
In-Reply-To: <kmbi8sN1CiNsomx8-BbjpgdDiogQU0MyUXJogHChH6s=.78fd103a-9f37-475d-8108-75e851193c4f@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
 <kmbi8sN1CiNsomx8-BbjpgdDiogQU0MyUXJogHChH6s=.78fd103a-9f37-475d-8108-75e851193c4f@github.com>
Message-ID: <0hh5fiC97LYCIv7GQburF28XZt25Z1UFHYvkO2_MH50=.d6c0e09b-19b4-44b0-9039-430bdc38bd10@github.com>

On Fri, 2 May 2025 12:00:13 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> See the JBS bug for some details.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Remove unused BIG_DECIMAL_EXPONENT
>  - Merge branch 'master' into 8343829
>  - Merge branch 'master' into 8343829
>  - Redacted comments.
>  - Merge branch 'master' into 8343829
>  - Minors in comments.
>  - Removed repeated comment.
>  - Refactoring some code and comments.
>  - 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal

This is just the first step of a planned overhaul of conversions from decimal strings to floating-point values. There are more steps to come.
So I'm not sure that #24999 turns out to be useful at this stage.

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

PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2847108653

From rgiulietti at openjdk.org  Fri May  2 12:45:55 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 May 2025 12:45:55 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v46]
In-Reply-To: <Rrp-YpS5_sB_c2I36ZmWN3e08vjy4JL25m9vIC0ZP3s=.6d6f7153-41d7-485e-ab0f-5fcfb54aeec6@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <3O57UNZ3SXn29fLVtLJ2hm43d798Vt40EIjcvqbcMus=.e8a5dc7a-bb21-44ec-ad66-c11e0a23456f@github.com>
 <Rrp-YpS5_sB_c2I36ZmWN3e08vjy4JL25m9vIC0ZP3s=.6d6f7153-41d7-485e-ab0f-5fcfb54aeec6@github.com>
Message-ID: <XLgWv5_P5CVA4h45WxFbleO_gAZ0mSxFY-7FhYSJEtc=.5e604609-c915-451d-a321-f8d9b0ec0bf0@github.com>

On Tue, 29 Apr 2025 19:11:32 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Adjust the type of operand
>>  - Use a more loose formula to do range check
>>    
>>    Use a more loose formula to do range check, in order not to exclude a priori values that may be inside the supported range
>
> A thought for a future PR  - computing long powers could be useful as a public method as well.

@j3graham 
> A thought for a future PR - computing long powers could be useful as a public method as well.

FYI, I just submitted #25003.

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

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2847118072

From swen at openjdk.org  Fri May  2 12:47:52 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 12:47:52 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v11]
In-Reply-To: <yTWcKmF0WcP69BQAY4TAPav0jLvMpaYCzGVhvMsD_9w=.0ab7cc90-fbd7-45fa-969d-70c5bf16993c@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
 <yTWcKmF0WcP69BQAY4TAPav0jLvMpaYCzGVhvMsD_9w=.0ab7cc90-fbd7-45fa-969d-70c5bf16993c@github.com>
Message-ID: <7jVupzlyU-2eLnFy6h8c_zmY-hh_zpRXn6gVMbknZTc=.a60050c3-ed30-456c-80d3-3e4df1da9e0f@github.com>

On Wed, 30 Apr 2025 20:26:33 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - Reviews from viktor
>  - Rewrite impl to follow the new simplified spec
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - Try to simplify the model - use the finish of computeValue
>    
>  - Test updates - remove repetition, test case for no stale installation
>  - Fix incorrect promise removal when unnecessary and add regression test
>  - Cannot test for recursion eagerly - add test case
>  - More spec, eager exception, finish with existing, thanks John
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/b679d9c3...2292212b

src/java.base/share/classes/java/lang/ClassValue.java line 371:

> 369:             Version<T> v = version();
> 370:             if (v == null)  return false;
> 371:             if (v.isLive())  return true;

Suggestion:

            if (v == null)  return false;
            if (v.isLive()) return true;

Remove a space to align the code

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2071561616

From mullan at openjdk.org  Fri May  2 12:56:50 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 2 May 2025 12:56:50 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5]
In-Reply-To: <To8P9zSROG54ayME3D-98HIN0qqjfORNadZD8GA4R4I=.440e00b9-9f46-4b0a-ac0f-14612be358e2@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <To8P9zSROG54ayME3D-98HIN0qqjfORNadZD8GA4R4I=.440e00b9-9f46-4b0a-ac0f-14612be358e2@github.com>
Message-ID: <DP4G9gxUfBGeHKkeWaT3q8nCyBdvc-oWh6SoENgFNM4=.8a0c9e82-b3b9-47c8-96d4-853918c410ae@github.com>

On Thu, 1 May 2025 14:50:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Finalize the KDF API.
>
> Weijun Wang 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
>  - add a positive debug log and update exception message
>  - enhancing exception messages and debug outputs
>  - update @since tags as required by JEP 12
>  - add enum back
>  - the change

src/java.base/share/classes/javax/crypto/KDF.java line 481:

> 479: 
> 480:     // Rethrows the IAPE thrown by an implementation, adding an explanation
> 481:     // on in which situation it fails.

suggest rewording as "for the situation in which it fails."

src/java.base/share/classes/javax/crypto/KDF.java line 491:

> 489:                     + "using the supplied derivation "
> 490:                     + "inputs, using the " + source + " "
> 491:                     + theOne.provider().getName()

Suggest rewording as: "inputs with the " + source + " " + theOne.provider().getName() + " provider."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2071561925
PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2071567362

From jpai at openjdk.org  Fri May  2 12:59:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 2 May 2025 12:59:46 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v6]
In-Reply-To: <J5zeFL07BWdLYcEYEh4RCIFjlQjFKOfD0V90FhrLKIE=.eeb3690a-0881-4470-a57a-580f1daff906@github.com>
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 <J5zeFL07BWdLYcEYEh4RCIFjlQjFKOfD0V90FhrLKIE=.eeb3690a-0881-4470-a57a-580f1daff906@github.com>
Message-ID: <4EvORA4ZZNr4eJtxhFiKREV5bFXqLj1zVW8hCVY9muM=.824f677f-820e-47d5-8362-c824ee4a03fa@github.com>

On Wed, 30 Apr 2025 17:06:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355444: Remove requires tag from ManyFiles

Hello Brian, I went back and checked the history of this ManyFiles test. The original test did not have the check to skip running on Linux. I do see which commit introduced that check but it doesn't have any additional details other than the brief code comment which said "Linux does not yet allow opening this many files". That was back in 2003. 

So I think the removal of this check and `@requires` is fine. 

> I ran 30 repeats on each of the two Linux architectures in the CI 

I would suggest doing a similar run without specifying a specific test platform. That way it will get run on all relevant platforms. I don't expect it to fail, but it would be good to have that tested before this is integrated.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24860#pullrequestreview-2811947219

From dl at openjdk.org  Fri May  2 13:21:45 2025
From: dl at openjdk.org (Doug Lea)
Date: Fri, 2 May 2025 13:21:45 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
Message-ID: <b-p4Yt3OKJx88ua6qxoI2eRoIvMOf4mYJ-i2RZdu1so=.c9eed405-2f55-4cd2-9e13-bce56b53c6d6@github.com>

On Mon, 28 Apr 2025 15:23:18 GMT, kabutz <duke at openjdk.org> wrote:

> We logged several bugs on the LinkedBlockingDeque. This aggregates them into a single bug report and PR.
> 
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in put/take
> 
> The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down.
> 
> 2. LinkedBlockingDeque.clear() should preserve weakly-consistent iterators
> 
> LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work.
> 
> The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator thus all support self-linking.
> 
> This can be fixed very easily by linking both f.prev and f.next back to f.
> 
> 3. LinkedBlockingDeque offer() creates nodes even if capacity has been reached
> 
> In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking.
> 
> In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field.
> 
> 4. LinkedBlockingDeque allows us to overflow size with addAll()
> 
> In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst holding the lock, we check that we haven't exceed...

I agree that these changes make behavior more consistent with LinkedBlockingQueue, which is worth doing. Thanks for finding straightforward ways to do these that don't impact anything else. 
Changing count field to volatile and sometimes read outside of lock introduces more potential non-sequential-consistency (for example checking size while adding) but doesn't impact  observable guarantees. It may have small performance impact in either direction that could vary across platforms, but I have not detected any.
There are possible (not likely, and still legal according to spec) observable consequences of using lockInterruptibly, but better to have them now not surprisingly different than other blocking queues.

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

Marked as reviewed by dl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24925#pullrequestreview-2811993260

From rgiulietti at openjdk.org  Fri May  2 13:34:02 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 May 2025 13:34:02 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v7]
In-Reply-To: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
Message-ID: <bI8EA_l6SeFqopOMe9mls8148Vn0xnkVoi2Pt2L2eSY=.8faceb89-2e49-4124-bdff-ee0509b82346@github.com>

> See the JBS bug for some details.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Make some static arrays @Stable.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22737/files
  - new: https://git.openjdk.org/jdk/pull/22737/files/49ed9aac..41d070ec

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

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

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

From swen at openjdk.org  Fri May  2 13:42:48 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 13:42:48 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v7]
In-Reply-To: <bI8EA_l6SeFqopOMe9mls8148Vn0xnkVoi2Pt2L2eSY=.8faceb89-2e49-4124-bdff-ee0509b82346@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
 <bI8EA_l6SeFqopOMe9mls8148Vn0xnkVoi2Pt2L2eSY=.8faceb89-2e49-4124-bdff-ee0509b82346@github.com>
Message-ID: <do_vkIX2xc7lJSqlvVbm1N0MU8I5jAZo4rVn92g5iyg=.9b0902c4-a7ae-4b1a-8581-e2b7c1857e56@github.com>

On Fri, 2 May 2025 13:34:02 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> See the JBS bug for some details.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make some static arrays @Stable.

Q_MIN -> E_MIN -> E_MAX -> W -> P Five layers of Stable, I don't know if C2 can work correctly, maybe need to confirm

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

PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2847240211

From swen at openjdk.org  Fri May  2 13:44:47 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 13:44:47 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v7]
In-Reply-To: <N7NsUmQu0BcYHHO2YWEoKzsugsJop30V6mYTRL3H3Xc=.8c9a6fa3-b39a-4aca-bf98-dade9489bb12@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <ePNPHPWO8a-gQ_jVczzNV8E_Qi37E1wVi_4WHNVYkXk=.c03ab70f-8401-44e8-ac72-4f9e86287542@github.com>
 <N7NsUmQu0BcYHHO2YWEoKzsugsJop30V6mYTRL3H3Xc=.8c9a6fa3-b39a-4aca-bf98-dade9489bb12@github.com>
Message-ID: <C5DFY_TnmKmvSFSNEJuvGaRCD4WOxXzb9omEX9VztLc=.88f9479c-3d47-4a7c-abe8-2a6ff04331b7@github.com>

On Fri, 2 May 2025 10:41:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments
>
> Updated benchmarks:
> 
> 
> Benchmark                            (ELEM_SIZE)  Mode  Cnt   Score   Error  Units
> BufferStackBench.OfVirtual.buffer              8  avgt   15  12.695 ? 0.205  ns/op
> BufferStackBench.OfVirtual.buffer             16  avgt   15  12.622 ? 0.078  ns/op
> BufferStackBench.OfVirtual.buffer             32  avgt   15  12.523 ? 0.022  ns/op
> BufferStackBench.OfVirtual.confined            8  avgt   15  22.902 ? 0.407  ns/op
> BufferStackBench.OfVirtual.confined           16  avgt   15  23.858 ? 0.652  ns/op
> BufferStackBench.OfVirtual.confined           32  avgt   15  25.544 ? 0.458  ns/op
> BufferStackBench.buffer                        8  avgt   15   4.923 ? 0.029  ns/op
> BufferStackBench.buffer                       16  avgt   15   4.971 ? 0.095  ns/op
> BufferStackBench.buffer                       32  avgt   15   4.980 ? 0.105  ns/op
> BufferStackBench.confined                      8  avgt   15  22.713 ? 0.289  ns/op
> BufferStackBench.confined                     16  avgt   15  23.576 ? 0.348  ns/op
> BufferStackBench.confined                     32  avgt   15  25.272 ? 0.530  ns/op
> 
> 
> and
> 
> 
> Benchmark                              Mode  Cnt   Score   Error  Units
> CallOverheadByValue.OfVirtual.byPtr    avgt   15   4.159 ? 0.097  ns/op
> CallOverheadByValue.OfVirtual.byValue  avgt   15  16.535 ? 0.433  ns/op
> CallOverheadByValue.byPtr              avgt   15   4.119 ? 0.031  ns/op
> CallOverheadByValue.byValue            avgt   15  11.404 ? 0.240  ns/op

https://github.com/minborg/jdk/pull/7 @minborg I submitted a PR to you, please see if it is useful to you

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

PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2847244523

From rgiulietti at openjdk.org  Fri May  2 13:48:47 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 May 2025 13:48:47 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v7]
In-Reply-To: <do_vkIX2xc7lJSqlvVbm1N0MU8I5jAZo4rVn92g5iyg=.9b0902c4-a7ae-4b1a-8581-e2b7c1857e56@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
 <bI8EA_l6SeFqopOMe9mls8148Vn0xnkVoi2Pt2L2eSY=.8faceb89-2e49-4124-bdff-ee0509b82346@github.com>
 <do_vkIX2xc7lJSqlvVbm1N0MU8I5jAZo4rVn92g5iyg=.9b0902c4-a7ae-4b1a-8581-e2b7c1857e56@github.com>
Message-ID: <qhRTlOmQvj8zTEJkpDxTUpDz2OVm_XeYqrr4I8xVPkM=.8498c49d-0174-40d1-b55c-520461640739@github.com>

On Fri, 2 May 2025 13:40:14 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make some static arrays @Stable.
>
> Q_MIN -> E_MIN -> E_MAX -> W -> P Five layers of Stable, I don't know if C2 can work correctly, maybe need to confirm

@wenshao Do you mean that C2 might generate erroneous code (bad situation!), or that it might not take advantage of `@Stable` in optimized code?

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

PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2847252667

From swen at openjdk.org  Fri May  2 14:04:49 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 14:04:49 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v6]
In-Reply-To: <VLMTeth8BlsUkI2QlekrFz-MIVdp5KbYw2p6kZFQf14=.ae897519-3b5c-4d72-b58e-e5c86655d78a@github.com>
References: <QHEUF-Wlk-NBSpBXX6BEbXy1vN_HNlYkvY0lqzoN6ww=.848bb36e-c272-4926-aa37-f66c68e9135f@github.com>
 <VLMTeth8BlsUkI2QlekrFz-MIVdp5KbYw2p6kZFQf14=.ae897519-3b5c-4d72-b58e-e5c86655d78a@github.com>
Message-ID: <O0MPZN73Lvh82iGDRl1YoztavRH4ZKdf92CGSkBe5LM=.a63a89ef-6186-4397-989a-b7192024fb89@github.com>

On Tue, 29 Apr 2025 12:33:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>> 
>> 
>> Here are some benchmarks that ran on a platform thread and virtual threads respectively (M1 Mac):
>> 
>> 
>> Benchmark                                                  Mode  Cnt   Score   Error  Units
>> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.330 ? 0.820  ns/op
>> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.257 ? 0.117  ns/op
>> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  41.415 ? 1.013  ns/op
>> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.720 ? 0.463  ns/op
>> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.636 ? 0.182  ns/op
>> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.234 ? 0.156  ns/op
>> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.918 ? 0.487  ns/op
>> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   4.946 ? 0.089  ns/op
>> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.280 ? 1.128  ns/op
>> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  21.809 ? 0.413  ns/op
>> CaptureStateUtilBench.tlAllocationFail                     avgt   30  24.422 ? 0.673  ns/op
>> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   5.182 ? 0.152  ns/op
>> 
>> 
>> Adapted system call:
>> 
>>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
>> ```        
>> Explicit allocation:
>> 
>>         try (var arena = Arena.ofConfined()) {
>>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>>         }
>> ```        
>> Thread Local allocation:
>> 
>>         try (var arena = POOLS.take()) {
>>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>>         }
>> ```        
>> The adapted system call exhibits a ~4x performance improvement ove...
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add hashCode/equals to record to improve startup time

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 726:

> 724:         return this instanceof NoInitSegmentAllocator noInit ?
> 725:                 noInit.allocateNoInit(byteSize, 1) :
> 726:                 allocate(byteSize);

Suggestion:

        return this instanceof NoInitSegmentAllocator noInit
                ? noInit.allocateNoInit(byteSize, 1) 
                : allocate(byteSize);

How about a different coding style?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23765#discussion_r2071659669

From swen at openjdk.org  Fri May  2 14:07:46 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 14:07:46 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v7]
In-Reply-To: <do_vkIX2xc7lJSqlvVbm1N0MU8I5jAZo4rVn92g5iyg=.9b0902c4-a7ae-4b1a-8581-e2b7c1857e56@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
 <bI8EA_l6SeFqopOMe9mls8148Vn0xnkVoi2Pt2L2eSY=.8faceb89-2e49-4124-bdff-ee0509b82346@github.com>
 <do_vkIX2xc7lJSqlvVbm1N0MU8I5jAZo4rVn92g5iyg=.9b0902c4-a7ae-4b1a-8581-e2b7c1857e56@github.com>
Message-ID: <wNpgEJ-UBAPHH2ywsTtTGEnXiZX0-qPqAl-TwsICC00=.3bfad498-436a-4a73-916a-e6fd79e5c7a1@github.com>

On Fri, 2 May 2025 13:40:14 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make some static arrays @Stable.
>
> Q_MIN -> E_MIN -> E_MAX -> W -> P Five layers of Stable, I don't know if C2 can work correctly, maybe need to confirm

> @wenshao Do you mean that C2 might generate erroneous code (bad situation!), or that it might not take advantage of `@Stable` in optimized code?

I am worried that too many layers will cause C2 to not be optimized, but I am not sure, and I also hope to learn how to know that `@Stable` works

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

PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2847290855

From pminborg at openjdk.org  Fri May  2 14:08:46 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 2 May 2025 14:08:46 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath
In-Reply-To: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
Message-ID: <O54LfakQQHXhOanriYckqolPX9QAba4fzxsfyKQO0SU=.cbaf4e4a-de60-49b1-a9a8-72f404f1c92d@github.com>

On Fri, 2 May 2025 11:47:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments.
> Further, add `unsignedMultiplyExact` methods as well.

Maybe it is too late, but shouldn't there be a better way to structure all these methods and variants in Math and MathExact? x(), xExact() and all the different parameter types create a rather big Cartesian product.

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

PR Comment: https://git.openjdk.org/jdk/pull/25003#issuecomment-2847293324

From rgiulietti at openjdk.org  Fri May  2 14:12:46 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 May 2025 14:12:46 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v7]
In-Reply-To: <bI8EA_l6SeFqopOMe9mls8148Vn0xnkVoi2Pt2L2eSY=.8faceb89-2e49-4124-bdff-ee0509b82346@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
 <bI8EA_l6SeFqopOMe9mls8148Vn0xnkVoi2Pt2L2eSY=.8faceb89-2e49-4124-bdff-ee0509b82346@github.com>
Message-ID: <-V6dZL-N-yUiRPE0Dj661ygG4XB_6CKLzK3AaVtxmno=.fc380bc5-d43d-41a0-b69a-96fd55aa868a@github.com>

On Fri, 2 May 2025 13:34:02 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> See the JBS bug for some details.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make some static arrays @Stable.

I'm not worried if C2 cannot optimize too many levels of `@Stable` here. The values are used in an unusually long method, so I don't think there are measurable benefits anyway.
In contrast, I would be _much_ concerned if there are real risks of erroneous code being generated.

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

PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2847304061

From rgiulietti at openjdk.org  Fri May  2 14:17:45 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 May 2025 14:17:45 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath
In-Reply-To: <O54LfakQQHXhOanriYckqolPX9QAba4fzxsfyKQO0SU=.cbaf4e4a-de60-49b1-a9a8-72f404f1c92d@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <O54LfakQQHXhOanriYckqolPX9QAba4fzxsfyKQO0SU=.cbaf4e4a-de60-49b1-a9a8-72f404f1c92d@github.com>
Message-ID: <coDsBC5XhvX2nXWDi8dLA_gfaOA8xrN-6rC-KwlNQ-c=.4ec18026-ac13-4ae3-aa56-7541dbaeb7b0@github.com>

On Fri, 2 May 2025 14:06:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments.
>> Further, add `unsignedMultiplyExact` methods as well.
>
> Maybe it is too late, but shouldn't there be a better way to structure all these methods and variants in Math and MathExact? x(), xExact() and all the different parameter types create a rather big Cartesian product.

@minborg I'm open to suggestions for the `pow` methods.
But for the `unsignedMultiplyExact` methods, as their signed counterparts are already in `[Strict]Math` since a long time, I think they should land there as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/25003#issuecomment-2847316992

From pminborg at openjdk.org  Fri May  2 14:17:58 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 2 May 2025 14:17:58 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v8]
In-Reply-To: <-bZOgYK72qj6upg_jsJ5iss0nyvYEeTYcF5Mc2Yb6Wc=.8b46ef04-48e9-421f-a035-190d455fefe7@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
 <9wPukxFBvu0fk_O1fNfNZ4DPfEE_Z-fJi7ubiGwq-Ds=.3435ebd8-bab8-4a70-9926-4586df035ce6@github.com>
 <JJBajx3RrQQf1rKZBeGsw-XRl5tA2cyW8hHMNHRISZA=.ad091672-f5c0-4b02-b094-e48970500c0d@github.com>
 <0En4rtg8rommV5EHy5Jsfhuc2yOBokRo_NLOtN5ODJU=.f24966c7-23b8-40e4-bba0-ffc98dbec77e@github.com>
 <-bZOgYK72qj6upg_jsJ5iss0nyvYEeTYcF5Mc2Yb6Wc=.8b46ef04-48e9-421f-a035-190d455fefe7@github.com>
Message-ID: <V8DNKo1JMqrHd2ESGO9eBn5kl2ujRTtctKSVzVV0mVY=.efd5bfcd-d9c3-431a-b9da-4eaa0618ea7a@github.com>

On Fri, 2 May 2025 11:56:31 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> And, if you do that, you then don't need the `of` factory -- clients can just use `new`
>
>> any reason why you didn't use a lambda here?
> 
> I also think that CleanupAction should be changed to lambda

Using an anonymous class for the cleanup action had very adverse effects on performance. I didn't want to use a lambda for startup performance reasons.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071674052

From pminborg at openjdk.org  Fri May  2 14:17:57 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 2 May 2025 14:17:57 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v8]
In-Reply-To: <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
Message-ID: <4OR68YXIZ0pTSWMdn9Csl-kulCXobpPNc6_G1eWC2qE=.0909310c-717f-4d7e-8db2-f736a6505733@github.com>

On Fri, 2 May 2025 11:13:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
>> 
>> Re-allocated segments are not zeroed between allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup and only create CleanupAction once per thread

The performance before this PR can be seen in the "confined" benchmarks above. In those benchmarks, a regular `Arena.ofConfined` is created upon every invocation.

I will integrate this PR now @wenshao . Can you summarize your proposed changes below as It was a bit unclear to me what you meant. I can create a separate PR with those changes later.

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

PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2847309534
PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2847314767

From pminborg at openjdk.org  Fri May  2 14:18:01 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 2 May 2025 14:18:01 GMT
Subject: Integrated: 8349146: [REDO] Implement a better allocator for downcalls
In-Reply-To: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
Message-ID: <PbVuK4GLFSA0xpbjbR80nPgNcuHoqnToCbwBVmI_1V4=.911e6663-b0f5-4def-b97f-21203ac15b24@github.com>

On Wed, 23 Apr 2025 14:05:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
> 
> Re-allocated segments are not zeroed between allocations.

This pull request has now been integrated.

Changeset: 9f9e73d5
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f9e73d5f9fcb5e926a2674c54cbbc92012b75f6
Stats:     1004 lines in 11 files changed: 983 ins; 15 del; 6 mod

8349146: [REDO] Implement a better allocator for downcalls

Reviewed-by: mcimadamore, jvernee, liach

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

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

From jpai at openjdk.org  Fri May  2 14:24:47 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 2 May 2025 14:24:47 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v7]
In-Reply-To: <bI8EA_l6SeFqopOMe9mls8148Vn0xnkVoi2Pt2L2eSY=.8faceb89-2e49-4124-bdff-ee0509b82346@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
 <bI8EA_l6SeFqopOMe9mls8148Vn0xnkVoi2Pt2L2eSY=.8faceb89-2e49-4124-bdff-ee0509b82346@github.com>
Message-ID: <OXoOThY3wDYFLn7vmiBogUhcKTLR3xL_s-RGv40R5gU=.76d08e2e-a35f-48b8-820b-068c9a054ec8@github.com>

On Fri, 2 May 2025 13:34:02 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> See the JBS bug for some details.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make some static arrays @Stable.

If I understand correctly, we are talking about several (primitive) array type fields having a `@Stable` annotation, in a single class, right? So we aren't really talking about levels?
If so, given what `@Stable` is documented to do, I don't think the number of fields annotated as `@Stable` plays any role in the C2 compiler generating the resultant code.

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

PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2847334140

From rriggs at openjdk.org  Fri May  2 14:42:46 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 2 May 2025 14:42:46 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
In-Reply-To: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
Message-ID: <vn_pxxNKegLNvZ6QZXLLDws2ytOlYCTxAsvzW0a1rWs=.06ac1d03-dfa4-4d08-b2f5-e5c44dff0c71@github.com>

On Thu, 1 May 2025 05:33:29 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 314:

> 312:      * <p>
> 313:      * <b>WARNING: The caller of this method shall relinquish and transfer the
> 314:      * ownership of the byte array to the callee</b>, since the later will not

Typo:  "later" -> "latter". (pre-existing)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2071714828

From swen at openjdk.org  Fri May  2 14:46:54 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 14:46:54 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v8]
In-Reply-To: <4OR68YXIZ0pTSWMdn9Csl-kulCXobpPNc6_G1eWC2qE=.0909310c-717f-4d7e-8db2-f736a6505733@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
 <4OR68YXIZ0pTSWMdn9Csl-kulCXobpPNc6_G1eWC2qE=.0909310c-717f-4d7e-8db2-f736a6505733@github.com>
Message-ID: <mh8mA2grCrIljWrrXRKn52kOFRIIWrsnucj75VVq5iE=.47a61bdd-4a3e-4408-ac34-da33db245dff@github.com>

On Fri, 2 May 2025 14:14:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Can you summarize your proposed changes below as It was a bit unclear to me what you meant. I can create a separate PR with those changes later.

My suggestion is to use two records (both PerThread and Frame) to replace the original inner class Frame. This would also eliminate one use of @ForceInline. This might just be my personal coding style preference ? feel free to adopt it if you like. Just a suggestion!

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

PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2847381560

From nbenalla at openjdk.org  Fri May  2 14:57:52 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 2 May 2025 14:57:52 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
Message-ID: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>

Get JDK 26 underway.

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

Commit messages:
 - Update copyright years
 - Update --release 25 symbol information for JDK 24 build 20
 - initial commit start-of-JDK-26

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355746
  Stats: 1193 lines in 54 files changed: 1100 ins; 16 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/25008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008

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

From nbenalla at openjdk.org  Fri May  2 15:05:44 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 2 May 2025 15:05:44 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
In-Reply-To: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
Message-ID: <yIUI0Q8Jj344JMFsnDM3poyk7UQZCSKS75SA5YFk6mU=.3e167b09-0df3-4ec9-bf45-6b10f73e0d35@github.com>

On Fri, 2 May 2025 14:48:01 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Get JDK 26 underway.

This initial commit of the PR intentionally excludes the creation of the new symbol files so that the fundamental code aspects of the update are easier to see.

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

PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2847422764

From rgiulietti at openjdk.org  Fri May  2 15:12:01 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 May 2025 15:12:01 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v2]
In-Reply-To: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
Message-ID: <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>

> Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments.
> Further, add `unsignedMultiplyExact` methods as well.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Clearer and more complete spec of the *pow* methods.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25003/files
  - new: https://git.openjdk.org/jdk/pull/25003/files/9ab1add2..2d3405f2

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

  Stats: 24 lines in 2 files changed: 8 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25003/head:pull/25003

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

From liach at openjdk.org  Fri May  2 15:17:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 15:17:25 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v12]
In-Reply-To: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
Message-ID: <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com>

> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
> 
> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
> 
> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
> 
> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/ClassValue.java
  
  Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24043/files
  - new: https://git.openjdk.org/jdk/pull/24043/files/2292212b..3d68f09a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=10-11

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

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

From duke at openjdk.org  Fri May  2 15:24:45 2025
From: duke at openjdk.org (kabutz)
Date: Fri, 2 May 2025 15:24:45 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <b-p4Yt3OKJx88ua6qxoI2eRoIvMOf4mYJ-i2RZdu1so=.c9eed405-2f55-4cd2-9e13-bce56b53c6d6@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <b-p4Yt3OKJx88ua6qxoI2eRoIvMOf4mYJ-i2RZdu1so=.c9eed405-2f55-4cd2-9e13-bce56b53c6d6@github.com>
Message-ID: <pNhvtlmpd-FL6LN2bm525uyhYQnTUF2kZ0hswiJsrw4=.96725eda-ac0a-452e-b274-b03bde0fb400@github.com>

On Fri, 2 May 2025 13:19:13 GMT, Doug Lea <dl at openjdk.org> wrote:

>> We logged several bugs on the LinkedBlockingDeque. This aggregates them into a single bug report and PR.
>> 
>> 1. LinkedBlockingDeque does not immediately throw InterruptedException in put/take
>> 
>> The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down.
>> 
>> 2. LinkedBlockingDeque.clear() should preserve weakly-consistent iterators
>> 
>> LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work.
>> 
>> The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator thus all support self-linking.
>> 
>> This can be fixed very easily by linking both f.prev and f.next back to f.
>> 
>> 3. LinkedBlockingDeque offer() creates nodes even if capacity has been reached
>> 
>> In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking.
>> 
>> In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field.
>> 
>> 4. LinkedBlockingDeque allows us to overflow size with addAll()
>> 
>> In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst hol...
>
> I agree that these changes make behavior more consistent with LinkedBlockingQueue, which is worth doing. Thanks for finding straightforward ways to do these that don't impact anything else. 
> Changing count field to volatile and sometimes read outside of lock introduces more potential non-sequential-consistency (for example checking size while adding) but doesn't impact  observable guarantees. It may have small performance impact in either direction that could vary across platforms, but I have not detected any.
> There are possible (not likely, and still legal according to spec) observable consequences of using lockInterruptibly, but better to have them now not surprisingly different than other blocking queues.

Thanks @DougLea !

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

PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2847463059

From rgiulietti at openjdk.org  Fri May  2 15:31:49 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 May 2025 15:31:49 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v7]
In-Reply-To: <OXoOThY3wDYFLn7vmiBogUhcKTLR3xL_s-RGv40R5gU=.76d08e2e-a35f-48b8-820b-068c9a054ec8@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
 <bI8EA_l6SeFqopOMe9mls8148Vn0xnkVoi2Pt2L2eSY=.8faceb89-2e49-4124-bdff-ee0509b82346@github.com>
 <OXoOThY3wDYFLn7vmiBogUhcKTLR3xL_s-RGv40R5gU=.76d08e2e-a35f-48b8-820b-068c9a054ec8@github.com>
Message-ID: <aaICVEnXfyU4M46SkWhcWCosTmNK_vHQHy-dDT28GIE=.d33c3284-7a43-4ca8-970a-86d6d1f6c63a@github.com>

On Fri, 2 May 2025 14:21:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make some static arrays @Stable.
>
> If I understand correctly, we are talking about several (primitive) array type fields having a `@Stable` annotation, in a single class, right? So we aren't really talking about levels?
> If so, given what `@Stable` is documented to do, I don't think the number of fields annotated as `@Stable` plays any role in the C2 compiler generating the resultant code.

@jaikiran "Levels" in the sense that Q_MIN depends on E_MIN, which depends on E_MAX, which depends on W, which depends on P.
If `@Stable` helps, which I think it does, great. If it doesn't, it shouldn't matter in practice.

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

PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2847498217

From duke at openjdk.org  Fri May  2 15:43:47 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 2 May 2025 15:43:47 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v2]
In-Reply-To: <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
Message-ID: <5Kbr6WiyE1kEPtuX2j-jJ0O05jWkoYIFwuR4FUes7ig=.c02a5248-b8f5-4edb-a464-fe256fae40aa@github.com>

On Fri, 2 May 2025 15:12:01 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments.
>> Further, add `unsignedMultiplyExact` methods as well.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clearer and more complete spec of the *pow* methods.

Some easy optimizations for special cases.

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

Changes requested by fabioromano1 at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/25003#pullrequestreview-2812333652

From liach at openjdk.org  Fri May  2 15:49:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 15:49:52 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5]
In-Reply-To: <To8P9zSROG54ayME3D-98HIN0qqjfORNadZD8GA4R4I=.440e00b9-9f46-4b0a-ac0f-14612be358e2@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <To8P9zSROG54ayME3D-98HIN0qqjfORNadZD8GA4R4I=.440e00b9-9f46-4b0a-ac0f-14612be358e2@github.com>
Message-ID: <lqGuJD-sYxmMHpTuUTNegv_4FbWi11XYAhiH2Sv7zko=.93f8a437-f633-47bc-9f6b-24009d6fd234@github.com>

On Thu, 1 May 2025 14:50:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Finalize the KDF API.
>
> Weijun Wang 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
>  - add a positive debug log and update exception message
>  - enhancing exception messages and debug outputs
>  - update @since tags as required by JEP 12
>  - add enum back
>  - the change

The changes to finalize this preview feature look good. I did not review the extra security-specific changes in KDF.java and KDFDelayedProviderException.java.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24520#pullrequestreview-2812347049

From bpb at openjdk.org  Fri May  2 15:51:46 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 May 2025 15:51:46 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v6]
In-Reply-To: <4EvORA4ZZNr4eJtxhFiKREV5bFXqLj1zVW8hCVY9muM=.824f677f-820e-47d5-8362-c824ee4a03fa@github.com>
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 <J5zeFL07BWdLYcEYEh4RCIFjlQjFKOfD0V90FhrLKIE=.eeb3690a-0881-4470-a57a-580f1daff906@github.com>
 <4EvORA4ZZNr4eJtxhFiKREV5bFXqLj1zVW8hCVY9muM=.824f677f-820e-47d5-8362-c824ee4a03fa@github.com>
Message-ID: <71VXdPis_VBu-CuKJD1UyxjB-spGSIQpemzbCXqumJQ=.00cea23a-cca0-415a-bc12-aa5928210e8a@github.com>

On Fri, 2 May 2025 12:56:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I would suggest doing a similar run without specifying a specific test platform. That way it will get run on all relevant platforms. I don't expect it to fail, but it would be good to have that tested before this is integrated.

I ran 30 repeats on all five platforms and there were no failures.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/24860#issuecomment-2847557213

From jlu at openjdk.org  Fri May  2 15:53:22 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 2 May 2025 15:53:22 GMT
Subject: RFR: 8356040: java/util/PluggableLocale/LocaleNameProviderTest.java
 timed out
Message-ID: <ZlNw-uu8c-LYrPGPOzC2ab4YHelGWdKD0mo12m3CFT0=.d43f7119-3594-48aa-90ed-d92c502ee3a5@github.com>

Please review this PR which reduces the amount of combinations tested by `LocaleNameProviderTest`.

This test was exhaustively testing over 1000x1000 `Locale` combinations which was expensive and caused a timeout in tier 5. Narrowing down the tested locales to Japanese language ones can reduce our tested input to 9x9 and provides most of the same value the test previously did. (Since our SPI provider has defined preferred Japanese Locale name values.) This change also refactors the test to use JUnit. The test now runs around ~20 times faster.

Most of the diff is attributed to separating the method source from the test itself. But notice the filtering of `Locale`s done on `availloc` and `jreImplLoc`.

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

Commit messages:
 - init

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

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

From liach at openjdk.org  Fri May  2 15:56:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 15:56:47 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
In-Reply-To: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
Message-ID: <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>

On Fri, 2 May 2025 14:48:01 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Get JDK 26 underway.

Changes requested by liach (Reviewer).

make/conf/version-numbers.conf line 36:

> 34: DEFAULT_VERSION_EXTRA2=0
> 35: DEFAULT_VERSION_EXTRA3=0
> 36: DEFAULT_VERSION_DATE=2026-03-16

Is this accurate?

src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 58:

> 56:  */
> 57: @SupportedAnnotationTypes("*")
> 58: @SupportedSourceVersion(SourceVersion.RELEASE_26)

This processor should emulate `com.sun.tools.jdeprscan.TraverseProc` and override `getSupportedSourceVersion`.

test/hotspot/jtreg/testlibrary/asm/org/objectweb/asm/ClassReader.java line 229:

> 227:         // Check the class' major_version. This field is after the magic and minor_version fields, which
> 228:         // use 4 and 2 bytes respectively.
> 229:         if (checkClassVersion && readShort(classFileOffset + 6) > Opcodes.V26) {

Please do not change ASM - if a test uses ASM to generate or parse later class files, they must migrate to the ClassFile API.  Open a JBS issue and identify the hotspot tests failing without this change.

test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50:

> 48: public class HelpOutputColumnWidthTest extends TestRunner {
> 49: 
> 50:     public static final int MAX_COLUMNS = 84;

What is this for?

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

PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2812349246
PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071811476
PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071815767
PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071819374
PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071817584

From bpb at openjdk.org  Fri May  2 16:05:05 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 May 2025 16:05:05 GMT
Subject: RFR: 8355443: [java.io] Use @requires tag instead of exiting based
 on File.separatorChar value [v2]
In-Reply-To: <VcXi45y3rrd0tA_yjpSce65QVUzQkKNW4kRptFKykZ0=.3eb1523f-cb6b-48a9-a033-2f8f08127eec@github.com>
References: <VcXi45y3rrd0tA_yjpSce65QVUzQkKNW4kRptFKykZ0=.3eb1523f-cb6b-48a9-a033-2f8f08127eec@github.com>
Message-ID: <3sk11HrnNbniie2o0JSpDgfN7XuZiezp0FX7PBUjgoA=.ede9ebbe-b077-40a0-8e9f-3374dac217b7@github.com>

> For tests of the `java.io` package, instead of doing this
> 
>     public static void main(String[] args) throws Exception {
>         if (File.separatorChar != '\') {
>             /* This test is only valid on win32 systems */
>             return;
>         }
> 
> do this
> 
>    @requires (os.family == "windows")

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge
 - 8355443: [java.io] Use @requires tag instead of exiting based on File.separatorChar value

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

Changes: https://git.openjdk.org/jdk/pull/24838/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24838&range=01
  Stats: 61 lines in 10 files changed: 10 ins; 35 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24838.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24838/head:pull/24838

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

From bpb at openjdk.org  Fri May  2 16:05:06 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 May 2025 16:05:06 GMT
Subject: RFR: 8355443: [java.io] Use @requires tag instead of exiting based
 on File.separatorChar value
In-Reply-To: <VcXi45y3rrd0tA_yjpSce65QVUzQkKNW4kRptFKykZ0=.3eb1523f-cb6b-48a9-a033-2f8f08127eec@github.com>
References: <VcXi45y3rrd0tA_yjpSce65QVUzQkKNW4kRptFKykZ0=.3eb1523f-cb6b-48a9-a033-2f8f08127eec@github.com>
Message-ID: <tN8n4N5o2hb2vcHjD0l-qZP1Ske6sM8hmjgvlN9sCLk=.e40e4779-abb3-43f5-94e5-f3cecd4346ae@github.com>

On Thu, 24 Apr 2025 00:33:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> For tests of the `java.io` package, instead of doing this
> 
>     public static void main(String[] args) throws Exception {
>         if (File.separatorChar != '\') {
>             /* This test is only valid on win32 systems */
>             return;
>         }
> 
> do this
> 
>    @requires (os.family == "windows")

df687c0 resolves a conflict with SJIS.java test.

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

PR Comment: https://git.openjdk.org/jdk/pull/24838#issuecomment-2847582924

From duke at openjdk.org  Fri May  2 16:10:51 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 2 May 2025 16:10:51 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v2]
In-Reply-To: <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
Message-ID: <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>

On Fri, 2 May 2025 15:12:01 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments.
>> Further, add `unsignedMultiplyExact` methods as well.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clearer and more complete spec of the *pow* methods.

Some easy optimizations for special cases.

src/java.base/share/classes/java/lang/Math.java line 3494:

> 3492:             return 1;
> 3493:         }
> 3494:         if (x == 0 || x == 1) {

Suggestion:

        if (x == 0 || x == 1 || n == 1) {

src/java.base/share/classes/java/lang/Math.java line 3500:

> 3498:             return (n & 0b1) == 0 ? 1 : -1;
> 3499:         }
> 3500: 

Suggestion:


        if (x == 2) {
            if (n >= Integer.SIZE - 1)
                throw new ArithmeticException("integer overflow");
            return 1 << n;
        }
        if (x == -2) {
            if (n >= Integer.SIZE)
                throw new ArithmeticException("integer overflow");
            // if n == Integer.SIZE - 1, result is correct
            return (n & 0b1) == 0 ? 1 << n : -(1 << n);
        }

       if ((java.math.BigInteger.bitLengthForInt(Math.abs(x)) - 1L) * n + 1L > Integer.SIZE) {
           throw new ArithmeticException("integer overflow");
       }

With also a check for the condition `java.math.BigInteger.bitLengthForInt(Math.abs(x)) * n < Integer.SIZE`, when it is true the path could be led to a loop that skips the checks.

src/java.base/share/classes/java/lang/Math.java line 3532:

> 3530:             return 1;
> 3531:         }
> 3532:         if (x == 0 || x == 1) {

Suggestion:

        if (x == 0 || x == 1 || n == 1) {

src/java.base/share/classes/java/lang/Math.java line 3535:

> 3533:             return x;
> 3534:         }
> 3535: 

Suggestion:


        if (x == 2) {
            if (n >= Integer.SIZE)
                throw new ArithmeticException("unsigned integer overflow");
            return 1 << n;
        }

       if ((java.math.BigInteger.bitLengthForInt(x) - 1L) * n + 1L > Integer.SIZE) {
           throw new ArithmeticException("unsigned integer overflow");
       }

With also a check for the condition `java.math.BigInteger.bitLengthForInt(x) * n <= Integer.SIZE`, when it is true the path could be led to a loop that skips the checks.

src/java.base/share/classes/java/lang/Math.java line 3567:

> 3565:             return 1;
> 3566:         }
> 3567:         if (x == 0 || x == 1) {

Suggestion:

        if (x == 0 || x == 1 || n == 1) {

src/java.base/share/classes/java/lang/Math.java line 3573:

> 3571:             return (n & 0b1) != 0 ? -1 : 1;
> 3572:         }
> 3573: 

Suggestion:


        if (x == 2) {
            if (n >= Long.SIZE - 1)
                throw new ArithmeticException("long overflow");
            return 1L << n;
        }
        if (x == -2) {
            if (n >= Long.SIZE)
                throw new ArithmeticException("long overflow");
            // if n == Long.SIZE - 1, result is correct
            return (n & 0b1) == 0 ? 1L << n : -(1L << n);
        }

       if ((java.math.BigInteger.bitLengthForLong(Math.abs(x)) - 1L) * n + 1L > Long.SIZE) {
           throw new ArithmeticException("long overflow");
       }

With also a check for the condition `java.math.BigInteger.bitLengthForLong(Math.abs(x)) * n < Long.SIZE`, when it is true the path could be led to a loop that skips the checks.

src/java.base/share/classes/java/lang/Math.java line 3610:

> 3608:          * very small when |x| > 1, but not necessarily when |x| <= 1.
> 3609:          */
> 3610:         if (x == 0 || x == 1) {

Suggestion:

        if (x == 0 || x == 1 || n == 1) {

src/java.base/share/classes/java/lang/Math.java line 3613:

> 3611:             return x;
> 3612:         }
> 3613: 

Suggestion:


        if (x == 2) {
            if (n >= Long.SIZE)
                throw new ArithmeticException("unsigned long overflow");
            return 1L << n;
        }

       if ((java.math.BigInteger.bitLengthForLong(x) - 1L) * n + 1L > Long.SIZE) {
           throw new ArithmeticException("unsigned long overflow");
       }

With also a check for the condition `java.math.BigInteger.bitLengthForLong(x) * n <= Long.SIZE`, when it is true the path could be led to a loop that skips the checks.

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

PR Review: https://git.openjdk.org/jdk/pull/25003#pullrequestreview-2812357251
PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071832231
PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071832373
PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071833435
PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071833501
PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071838381
PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071833854
PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071816617
PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071837334

From swen at openjdk.org  Fri May  2 16:10:56 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 16:10:56 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v8]
In-Reply-To: <V8DNKo1JMqrHd2ESGO9eBn5kl2ujRTtctKSVzVV0mVY=.efd5bfcd-d9c3-431a-b9da-4eaa0618ea7a@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
 <9wPukxFBvu0fk_O1fNfNZ4DPfEE_Z-fJi7ubiGwq-Ds=.3435ebd8-bab8-4a70-9926-4586df035ce6@github.com>
 <JJBajx3RrQQf1rKZBeGsw-XRl5tA2cyW8hHMNHRISZA=.ad091672-f5c0-4b02-b094-e48970500c0d@github.com>
 <0En4rtg8rommV5EHy5Jsfhuc2yOBokRo_NLOtN5ODJU=.f24966c7-23b8-40e4-bba0-ffc98dbec77e@github.com>
 <-bZOgYK72qj6upg_jsJ5iss0nyvYEeTYcF5Mc2Yb6Wc=.8b46ef04-48e9-421f-a035-190d455fefe7@github.com>
 <V8DNKo1JMqrHd2ESGO9eBn5kl2ujRTtctKSVzVV0mVY=.efd5bfcd-d9c3-431a-b9da-4eaa0618ea7a@github.com>
Message-ID: <Y2NfbNx153Wcn3uElp5My8F0l8n47Gb0KQa5fdu4ums=.a2348e51-af2d-42bb-b85b-5b6ccc0adb07@github.com>

On Fri, 2 May 2025 14:11:19 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>>> any reason why you didn't use a lambda here?
>> 
>> I also think that CleanupAction should be changed to lambda
>
> Using an anonymous class for the cleanup action had very adverse effects on performance. I didn't want to use a lambda for startup performance reasons.

If using lambda affects performance, how about using anonymous classes?

            return new PerThread(new ReentrantLock(),
                    arena,
                    new SlicingAllocator(arena.allocate(byteSize, byteAlignment)),
                    new Consumer<MemorySegment>() {
                        @Override
                        public void accept(MemorySegment memorySegment) {
                            Reference.reachabilityFence(arena);
                        }});

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071839071

From rgiulietti at openjdk.org  Fri May  2 16:25:46 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 May 2025 16:25:46 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v2]
In-Reply-To: <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
 <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>
Message-ID: <Vzp1-2EuHMiew6z7hPwbTFUeIKDstOmgouf0k3mZAQk=.b410e965-7cb3-49f7-8e84-7b2c00b5471f@github.com>

On Fri, 2 May 2025 16:07:31 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clearer and more complete spec of the *pow* methods.
>
> src/java.base/share/classes/java/lang/Math.java line 3567:
> 
>> 3565:             return 1;
>> 3566:         }
>> 3567:         if (x == 0 || x == 1) {
> 
> Suggestion:
> 
>         if (x == 0 || x == 1 || n == 1) {

@fabioromano1 Unless there's evidence that these cases are _very very_ common, there's no point in adding fast paths.
See this comment in `unsignedPowExact(long,int)`


        /*
         * To keep the code as simple as possible, there are intentionally
         * no fast paths, except for |x| <= 1.
         * The reason is that the number of loop iterations below can be kept
         * very small when |x| > 1, but not necessarily when |x| <= 1.
         */

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071857047

From duke at openjdk.org  Fri May  2 16:29:46 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 2 May 2025 16:29:46 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v2]
In-Reply-To: <Vzp1-2EuHMiew6z7hPwbTFUeIKDstOmgouf0k3mZAQk=.b410e965-7cb3-49f7-8e84-7b2c00b5471f@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
 <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>
 <Vzp1-2EuHMiew6z7hPwbTFUeIKDstOmgouf0k3mZAQk=.b410e965-7cb3-49f7-8e84-7b2c00b5471f@github.com>
Message-ID: <B3J8EvoOg0aj_k8_ATiImnmhM_EkA8yuLLOIt3bNjmc=.75adabc8-8afb-4b48-96a4-22c57857a6d7@github.com>

On Fri, 2 May 2025 16:23:24 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Math.java line 3567:
>> 
>>> 3565:             return 1;
>>> 3566:         }
>>> 3567:         if (x == 0 || x == 1) {
>> 
>> Suggestion:
>> 
>>         if (x == 0 || x == 1 || n == 1) {
>
> @fabioromano1 Unless there's evidence that these cases are _very very_ common, there's no point in adding fast paths.
> See this comment in `unsignedPowExact(long,int)`
> 
> 
>         /*
>          * To keep the code as simple as possible, there are intentionally
>          * no fast paths, except for |x| <= 1.
>          * The reason is that the number of loop iterations below can be kept
>          * very small when |x| > 1, but not necessarily when |x| <= 1.
>          */

@rgiulietti I would keep at least `n == 1` and `(bitLength(x) - 1L) * n + 1L > SIZE` cases

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071860872

From naoto at openjdk.org  Fri May  2 16:43:46 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 May 2025 16:43:46 GMT
Subject: RFR: 8355443: [java.io] Use @requires tag instead of exiting based
 on File.separatorChar value [v2]
In-Reply-To: <3sk11HrnNbniie2o0JSpDgfN7XuZiezp0FX7PBUjgoA=.ede9ebbe-b077-40a0-8e9f-3374dac217b7@github.com>
References: <VcXi45y3rrd0tA_yjpSce65QVUzQkKNW4kRptFKykZ0=.3eb1523f-cb6b-48a9-a033-2f8f08127eec@github.com>
 <3sk11HrnNbniie2o0JSpDgfN7XuZiezp0FX7PBUjgoA=.ede9ebbe-b077-40a0-8e9f-3374dac217b7@github.com>
Message-ID: <R3kpxG3nhokTd6CWAXZ7jRSv7O28uD_VVJtK7pEUoEE=.a31b4a37-dc2e-48db-b0d0-89cc09a13708@github.com>

On Fri, 2 May 2025 16:05:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For tests of the `java.io` package, instead of doing this
>> 
>>     public static void main(String[] args) throws Exception {
>>         if (File.separatorChar != '\') {
>>             /* This test is only valid on win32 systems */
>>             return;
>>         }
>> 
>> do this
>> 
>>    @requires (os.family == "windows")
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge
>  - 8355443: [java.io] Use @requires tag instead of exiting based on File.separatorChar value

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24838#pullrequestreview-2812461982

From liach at openjdk.org  Fri May  2 16:44:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 16:44:53 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v8]
In-Reply-To: <Y2NfbNx153Wcn3uElp5My8F0l8n47Gb0KQa5fdu4ums=.a2348e51-af2d-42bb-b85b-5b6ccc0adb07@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
 <9wPukxFBvu0fk_O1fNfNZ4DPfEE_Z-fJi7ubiGwq-Ds=.3435ebd8-bab8-4a70-9926-4586df035ce6@github.com>
 <JJBajx3RrQQf1rKZBeGsw-XRl5tA2cyW8hHMNHRISZA=.ad091672-f5c0-4b02-b094-e48970500c0d@github.com>
 <0En4rtg8rommV5EHy5Jsfhuc2yOBokRo_NLOtN5ODJU=.f24966c7-23b8-40e4-bba0-ffc98dbec77e@github.com>
 <-bZOgYK72qj6upg_jsJ5iss0nyvYEeTYcF5Mc2Yb6Wc=.8b46ef04-48e9-421f-a035-190d455fefe7@github.com>
 <V8DNKo1JMqrHd2ESGO9eBn5kl2ujRTtctKSVzVV0mVY=.efd5bfcd-d9c3-431a-b9da-4eaa0618ea7a@github.com>
 <Y2NfbNx153Wcn3uElp5My8F0l8n47Gb0KQa5fdu4ums=.a2348e51-af2d-42bb-b85b-5b6ccc0adb07@github.com>
Message-ID: <iTzK7K8n-MEZ3NctAhfIumY_WNENU8l4JTmTFf6L31Q=.6e3c937b-c7ca-4e45-933e-8cbe44aa0627@github.com>

On Fri, 2 May 2025 16:08:09 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Using an anonymous class for the cleanup action had very adverse effects on performance. I didn't want to use a lambda for startup performance reasons.
>
> If using lambda affects performance, how about using anonymous classes?
> 
>             return new PerThread(new ReentrantLock(),
>                     arena,
>                     new SlicingAllocator(arena.allocate(byteSize, byteAlignment)),
>                     new Consumer<MemorySegment>() {
>                         @Override
>                         public void accept(MemorySegment memorySegment) {
>                             Reference.reachabilityFence(arena);
>                         }});

Anonymous classes also captures outer variables and break cleaner/GC. The only safe measures are local enums or records, which never capture outer variables (anonymous classes cannot be enum or records)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2071880222

From rgiulietti at openjdk.org  Fri May  2 16:47:47 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 May 2025 16:47:47 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v2]
In-Reply-To: <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
 <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>
Message-ID: <oCuccSFQzcCuO5J5vCKn6bRJQ9fXCRdmW-Kd38ga9q0=.73bf1790-3464-48b7-9b3a-44445bba4c9b@github.com>

On Fri, 2 May 2025 16:06:42 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clearer and more complete spec of the *pow* methods.
>
> src/java.base/share/classes/java/lang/Math.java line 3613:
> 
>> 3611:             return x;
>> 3612:         }
>> 3613: 
> 
> Suggestion:
> 
> 
>         if (x == 2) {
>             if (n >= Long.SIZE)
>                 throw new ArithmeticException("unsigned long overflow");
>             return 1L << n;
>         }
> 
>        if ((java.math.BigInteger.bitLengthForLong(x) - 1L) * n + 1L > Long.SIZE) {
>            throw new ArithmeticException("unsigned long overflow");
>        }
> 
> With also a check for the condition `java.math.BigInteger.bitLengthForLong(x) * n <= Long.SIZE`, when it is true the path could be led to a loop that skips the checks.

I don't think there's a quick, _precise_ pre-check that would ensure that the loop can just use simple, unchecked `*` multiplications.

Consider `unsignedPowExact(3L, 40)`, which does not overflow, versus `unsignedPowExact(3L, 41)`, which does.
How would you pre-check these two cases using integer arithmetic?

IMO, you still need checked multiplications in the loop.

(Besides, the product in your checks can overflow, so you would have to add a guard.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071884269

From darcy at openjdk.org  Fri May  2 16:47:48 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 May 2025 16:47:48 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
In-Reply-To: <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
Message-ID: <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>

On Fri, 2 May 2025 15:47:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> make/conf/version-numbers.conf line 36:
> 
>> 34: DEFAULT_VERSION_EXTRA2=0
>> 35: DEFAULT_VERSION_EXTRA3=0
>> 36: DEFAULT_VERSION_DATE=2026-03-16
> 
> Is this accurate?

One day off; should be 2026-03-17.

I should have double-checked that in the initial authoring of the change.

> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 58:
> 
>> 56:  */
>> 57: @SupportedAnnotationTypes("*")
>> 58: @SupportedSourceVersion(SourceVersion.RELEASE_26)
> 
> This processor should emulate `com.sun.tools.jdeprscan.TraverseProc` and override `getSupportedSourceVersion`.

The implementation of getSupportedSourceVersion inherited from AbstractProcessor uses the value of this annotation.

> test/hotspot/jtreg/testlibrary/asm/org/objectweb/asm/ClassReader.java line 229:
> 
>> 227:         // Check the class' major_version. This field is after the magic and minor_version fields, which
>> 228:         // use 4 and 2 bytes respectively.
>> 229:         if (checkClassVersion && readShort(classFileOffset + 6) > Opcodes.V26) {
> 
> Please do not change ASM - if a test uses ASM to generate or parse later class files, they must migrate to the ClassFile API.  Open a JBS issue and identify the hotspot tests failing without this change.

There are various HotSpot tests that use ASM and they all fail under JDK 26 without this change.

> test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50:
> 
>> 48: public class HelpOutputColumnWidthTest extends TestRunner {
>> 49: 
>> 50:     public static final int MAX_COLUMNS = 84;
> 
> What is this for?

It is to accommodate the now longer list of --release values in the javac help output,the addition of ", 26".

Splitting the list of releases over two lines would be a better solution, but I didn't take that one when initially preparing the patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071878858
PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071883440
PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071881672
PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071880549

From alanb at openjdk.org  Fri May  2 16:47:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 May 2025 16:47:49 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
In-Reply-To: <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
 <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
Message-ID: <J8LYjKyW-DOppkSZxTWcRYllmQ_WzAwgTxLTdkh9Z4g=.e0d18849-bb60-45ab-851b-d034a26fe6bd@github.com>

On Fri, 2 May 2025 16:43:02 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> test/hotspot/jtreg/testlibrary/asm/org/objectweb/asm/ClassReader.java line 229:
>> 
>>> 227:         // Check the class' major_version. This field is after the magic and minor_version fields, which
>>> 228:         // use 4 and 2 bytes respectively.
>>> 229:         if (checkClassVersion && readShort(classFileOffset + 6) > Opcodes.V26) {
>> 
>> Please do not change ASM - if a test uses ASM to generate or parse later class files, they must migrate to the ClassFile API.  Open a JBS issue and identify the hotspot tests failing without this change.
>
> There are various HotSpot tests that use ASM and they all fail under JDK 26 without this change.

Hopefully new tests will use the ClassFile API and that over time that some of the existing tests that use ASM can be migrated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071884496

From rgiulietti at openjdk.org  Fri May  2 16:56:46 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 May 2025 16:56:46 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v2]
In-Reply-To: <B3J8EvoOg0aj_k8_ATiImnmhM_EkA8yuLLOIt3bNjmc=.75adabc8-8afb-4b48-96a4-22c57857a6d7@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
 <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>
 <Vzp1-2EuHMiew6z7hPwbTFUeIKDstOmgouf0k3mZAQk=.b410e965-7cb3-49f7-8e84-7b2c00b5471f@github.com>
 <B3J8EvoOg0aj_k8_ATiImnmhM_EkA8yuLLOIt3bNjmc=.75adabc8-8afb-4b48-96a4-22c57857a6d7@github.com>
Message-ID: <5wQQJ5le6CtE87hya7Kq6A4g8wdu2O35bifSTumwY04=.fd00d8ba-d951-4fca-b9dd-bec50a676e7a@github.com>

On Fri, 2 May 2025 16:26:48 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> @fabioromano1 Unless there's evidence that these cases are _very very_ common, there's no point in adding fast paths.
>> See this comment in `unsignedPowExact(long,int)`
>> 
>> 
>>         /*
>>          * To keep the code as simple as possible, there are intentionally
>>          * no fast paths, except for |x| <= 1.
>>          * The reason is that the number of loop iterations below can be kept
>>          * very small when |x| > 1, but not necessarily when |x| <= 1.
>>          */
>
> @rgiulietti I would keep at least `n == 1` and `(bitLength(x) - 1L) * n + 1L > SIZE` cases

Again, I don't think that `n == 1` is a frequent case which would make any practical difference.

As for the `bitLength` check, the product might overflow.
Further, `bitLength` might not be that cheap.
Finally, the test would just help to _fail_ faster at the expense of making the successful runs slightly slower.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071894199

From liach at openjdk.org  Fri May  2 16:58:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 16:58:50 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
In-Reply-To: <J8LYjKyW-DOppkSZxTWcRYllmQ_WzAwgTxLTdkh9Z4g=.e0d18849-bb60-45ab-851b-d034a26fe6bd@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
 <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
 <J8LYjKyW-DOppkSZxTWcRYllmQ_WzAwgTxLTdkh9Z4g=.e0d18849-bb60-45ab-851b-d034a26fe6bd@github.com>
Message-ID: <cc8J6tnifhUTh3SCu7VWsvJHc1afHMZeFQpNgqFF7Ew=.09f294a6-f5ac-4905-9868-17c4a174a123@github.com>

On Fri, 2 May 2025 16:45:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> There are various HotSpot tests that use ASM and they all fail under JDK 26 without this change.
>
> Hopefully new tests will use the ClassFile API and that over time that some of the existing tests that use ASM can be migrated.

I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release <N>` argument or migrate class file parsing to ClassFile API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071895599

From liach at openjdk.org  Fri May  2 16:58:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 16:58:49 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
In-Reply-To: <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
 <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
Message-ID: <9h_A8ZO25cAxj_Sex6ez9Lan6hjyoTc0_7PNqaCwfnI=.c8a68611-607c-4d6c-b0c9-23e8909a7376@github.com>

On Fri, 2 May 2025 16:44:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 58:
>> 
>>> 56:  */
>>> 57: @SupportedAnnotationTypes("*")
>>> 58: @SupportedSourceVersion(SourceVersion.RELEASE_26)
>> 
>> This processor should emulate `com.sun.tools.jdeprscan.TraverseProc` and override `getSupportedSourceVersion`.
>
> The implementation of getSupportedSourceVersion inherited from AbstractProcessor uses the value of this annotation.

May I prepare a quick patch to bring this in line with `TraverseProc` so we can skip this site for future start of release updates?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071896732

From swen at openjdk.org  Fri May  2 17:01:14 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 17:01:14 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v2]
In-Reply-To: <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
 <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>
Message-ID: <9ACW3UJDsgcJh02OftWGSeFNa5dbZVtG5NRVSuk5QnQ=.5119a855-507e-4d8a-a069-6b927a9a049e@github.com>

On Fri, 2 May 2025 16:04:18 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clearer and more complete spec of the *pow* methods.
>
> src/java.base/share/classes/java/lang/Math.java line 3500:
> 
>> 3498:             return (n & 0b1) == 0 ? 1 : -1;
>> 3499:         }
>> 3500: 
> 
> Suggestion:
> 
> 
>         if (x == 2) {
>             if (n >= Integer.SIZE - 1)
>                 throw new ArithmeticException("integer overflow");
>             return 1 << n;
>         }
>         if (x == -2) {
>             if (n >= Integer.SIZE)
>                 throw new ArithmeticException("integer overflow");
>             // if n == Integer.SIZE - 1, result is correct
>             return (n & 0b1) == 0 ? 1 << n : -(1 << n);
>         }
> 
>        if ((java.math.BigInteger.bitLengthForInt(Math.abs(x)) - 1L) * n + 1L > Integer.SIZE) {
>            throw new ArithmeticException("integer overflow");
>        }
> 
> With also a check for the condition `java.math.BigInteger.bitLengthForInt(Math.abs(x)) * n < Integer.SIZE`, when it is true the path could be led to a loop that skips the checks.

return (n & 0b1) == 0 ? 1 << n : -(1 << n);


Equivalent to 



return ((1 << n) ^ -(n & 1)) + (n & 1);


Without branches it should be faster

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071898882

From bpb at openjdk.org  Fri May  2 17:02:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 May 2025 17:02:53 GMT
Subject: Integrated: 8355443: [java.io] Use @requires tag instead of exiting
 based on File.separatorChar value
In-Reply-To: <VcXi45y3rrd0tA_yjpSce65QVUzQkKNW4kRptFKykZ0=.3eb1523f-cb6b-48a9-a033-2f8f08127eec@github.com>
References: <VcXi45y3rrd0tA_yjpSce65QVUzQkKNW4kRptFKykZ0=.3eb1523f-cb6b-48a9-a033-2f8f08127eec@github.com>
Message-ID: <3dtOWqD2k007_CZB3GDr45ASiJzFnA0b1pylZIwga-U=.3558a43c-491d-4a3e-8567-9860b7d316bb@github.com>

On Thu, 24 Apr 2025 00:33:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> For tests of the `java.io` package, instead of doing this
> 
>     public static void main(String[] args) throws Exception {
>         if (File.separatorChar != '\') {
>             /* This test is only valid on win32 systems */
>             return;
>         }
> 
> do this
> 
>    @requires (os.family == "windows")

This pull request has now been integrated.

Changeset: 4826a91e
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4826a91e7a729999343f450ab7ec4621cc418550
Stats:     61 lines in 10 files changed: 10 ins; 35 del; 16 mod

8355443: [java.io] Use @requires tag instead of exiting based on File.separatorChar value

Reviewed-by: naoto, vyazici

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

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

From bpb at openjdk.org  Fri May  2 17:03:00 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 May 2025 17:03:00 GMT
Subject: Integrated: 8355444: [java.io] Use @requires tag instead of exiting
 based on "os.name" property value
In-Reply-To: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
Message-ID: <adeBZTlDWnoXzSNvbbk3nMBaA-BX_ZgfymL_WR37dOw=.0d7f00c8-b7f3-46b4-88e7-034279d76e6b@github.com>

On Thu, 24 Apr 2025 20:46:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.

This pull request has now been integrated.

Changeset: 5faa5590
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5faa55902211e5ad8edc51282022ed9db3684b25
Stats:     46 lines in 6 files changed: 13 ins; 25 del; 8 mod

8355444: [java.io] Use @requires tag instead of exiting based on "os.name" property value

Reviewed-by: jpai, lancea

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

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

From aph at openjdk.org  Fri May  2 17:04:05 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 2 May 2025 17:04:05 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v4]
In-Reply-To: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
Message-ID: <TxwU7dUbzzrLHiyTMBFC9u5KH8bbx_uayhggLPm5sck=.7e3d511b-c118-42ab-80be-5798cce4cc72@github.com>

> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a null argument.

Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:

 - Remove unnecessary @since 25
 - Remove unnecessary @enablePreview in some tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24923/files
  - new: https://git.openjdk.org/jdk/pull/24923/files/d3f2ff1f..8f626617

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

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

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

From duke at openjdk.org  Fri May  2 17:09:47 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 2 May 2025 17:09:47 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v2]
In-Reply-To: <oCuccSFQzcCuO5J5vCKn6bRJQ9fXCRdmW-Kd38ga9q0=.73bf1790-3464-48b7-9b3a-44445bba4c9b@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
 <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>
 <oCuccSFQzcCuO5J5vCKn6bRJQ9fXCRdmW-Kd38ga9q0=.73bf1790-3464-48b7-9b3a-44445bba4c9b@github.com>
Message-ID: <HzDhy333paUhxamAWEvC_OdlrvSdF9rlncXbRJKz0x0=.008b1a01-b9f6-4dce-bf56-bdbe3239fb61@github.com>

On Fri, 2 May 2025 16:45:28 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> I don't think there's a quick, _precise_ pre-check that would ensure that the loop can just use simple, unchecked `*` multiplications.
> 
> Consider `unsignedPowExact(3L, 40)`, which does not overflow, versus `unsignedPowExact(3L, 41)`, which does. How would you pre-check these two cases using integer arithmetic?
> 
> IMO, you still need checked multiplications in the loop.
> 
> (Besides, the product in your checks can overflow, so you would have to add a guard.)

@rgiulietti

1. `BigInteger.bitLengthForLong(x) * n <= Long.SIZE` is a sufficient condition to ensure no overflow;

2. `(BigInteger.bitLengthForLong(x) - 1L) * n + 1L > Long.SIZE` is a sufficient condition to ensure the overflow.


Thus, there remain only the cases when ` Long.SIZE < BigInteger.bitLengthForLong(x) * n && (BigInteger.bitLengthForLong(x) - 1L) * n + 1L <= Long.SIZE`, in this cases checked multiplications in the loop are needed.
 
Moreover, `BigInteger.bitLengthForLong(x) - 1L` is a `long`, so the product does not overflow, so the condition at point 1 never overflows if it is evaluated only if the condition at point 2 is false.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071904898

From naoto at openjdk.org  Fri May  2 17:18:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 May 2025 17:18:51 GMT
Subject: RFR: 8356040:
 java/util/PluggableLocale/LocaleNameProviderTest.java timed out
In-Reply-To: <ZlNw-uu8c-LYrPGPOzC2ab4YHelGWdKD0mo12m3CFT0=.d43f7119-3594-48aa-90ed-d92c502ee3a5@github.com>
References: <ZlNw-uu8c-LYrPGPOzC2ab4YHelGWdKD0mo12m3CFT0=.d43f7119-3594-48aa-90ed-d92c502ee3a5@github.com>
Message-ID: <Iomf-tx3GsG0uRH8wf9_LWEYYkABjleMzZB8s4fnHlE=.271f762d-407a-425a-87f0-be18f705cd54@github.com>

On Fri, 2 May 2025 15:49:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which reduces the amount of combinations tested by `LocaleNameProviderTest`.
> 
> This test was exhaustively testing over 1000x1000 `Locale` combinations which was expensive and caused a timeout in tier 5. Narrowing down the tested locales to Japanese language ones can reduce our tested input to 9x9 and provides most of the same value the test previously did. (Since our SPI provider has defined preferred Japanese Locale name values.) This change also refactors the test to use JUnit. The test now runs around ~20 times faster.
> 
> Most of the diff is attributed to separating the method source from the test itself. But notice the filtering of `Locale`s done on `availloc` and `jreImplLoc`.

Looks good.

test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 61:

> 59:      * This is not an exhaustive test. Such a test would require iterating (1000x1000)+
> 60:      * inputs. Instead, we check against Japanese lang locales which guarantees
> 61:      * we will run into cases where the CLDR is not preferred and the SPI has defined

It would be helpful to mention why CLDR is not the preferred provider (as the SPI impl has variants of the Japanese locale)

test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 92:

> 90:         String jresctry = null;
> 91:         String jresvrnt = null;
> 92:         if (!lang.equals("")) {

Can be replaced with `isEmpty()`

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

PR Review: https://git.openjdk.org/jdk/pull/25009#pullrequestreview-2812517069
PR Review Comment: https://git.openjdk.org/jdk/pull/25009#discussion_r2071912893
PR Review Comment: https://git.openjdk.org/jdk/pull/25009#discussion_r2071918059

From duke at openjdk.org  Fri May  2 17:19:57 2025
From: duke at openjdk.org (Christoph)
Date: Fri, 2 May 2025 17:19:57 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
Message-ID: <d6tsmSF6s_7h6QvvgnWO1S-awAN5HH3yE-8SqUR8pl0=.ad6f7b2e-4452-44a9-b725-5340d14385b2@github.com>

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
> - This change is for macOS only.
> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

Followed the stepa and  built an unsigned image first and then signed the jpackage build and created the pkg/dmg files. However, notarization fails as it says it's not signed at all:

e.g.: 
>       "path": "JabRef-6.0_arm64.dmg/JabRef.app/Contents/MacOS/JabRef",
      "message": "The binary is not signed with a valid Developer ID certificate.", 
 
[ notarylog.log](https://github.com/user-attachments/files/20016162/notarylog.log)

Testing now with a presigned image.

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2847722058

From rgiulietti at openjdk.org  Fri May  2 17:20:46 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 May 2025 17:20:46 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v2]
In-Reply-To: <HzDhy333paUhxamAWEvC_OdlrvSdF9rlncXbRJKz0x0=.008b1a01-b9f6-4dce-bf56-bdbe3239fb61@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
 <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>
 <oCuccSFQzcCuO5J5vCKn6bRJQ9fXCRdmW-Kd38ga9q0=.73bf1790-3464-48b7-9b3a-44445bba4c9b@github.com>
 <HzDhy333paUhxamAWEvC_OdlrvSdF9rlncXbRJKz0x0=.008b1a01-b9f6-4dce-bf56-bdbe3239fb61@github.com>
Message-ID: <RhRURJNlPE4JJ_8hmILU3CUjY4SAf23CGaI3q0busAg=.2efdc9cd-5d7f-4ce0-b512-7b447afc356c@github.com>

On Fri, 2 May 2025 17:03:30 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> I don't think there's a quick, _precise_ pre-check that would ensure that the loop can just use simple, unchecked `*` multiplications.
>> 
>> Consider `unsignedPowExact(3L, 40)`, which does not overflow, versus `unsignedPowExact(3L, 41)`, which does.
>> How would you pre-check these two cases using integer arithmetic?
>> 
>> IMO, you still need checked multiplications in the loop.
>> 
>> (Besides, the product in your checks can overflow, so you would have to add a guard.)
>
>> I don't think there's a quick, _precise_ pre-check that would ensure that the loop can just use simple, unchecked `*` multiplications.
>> 
>> Consider `unsignedPowExact(3L, 40)`, which does not overflow, versus `unsignedPowExact(3L, 41)`, which does. How would you pre-check these two cases using integer arithmetic?
>> 
>> IMO, you still need checked multiplications in the loop.
>> 
>> (Besides, the product in your checks can overflow, so you would have to add a guard.)
> 
> @rgiulietti
> 
> 1. `BigInteger.bitLengthForLong(x) * n <= Long.SIZE` is a sufficient condition to ensure no overflow;
> 
> 2. `(BigInteger.bitLengthForLong(x) - 1L) * n + 1L > Long.SIZE` is a sufficient condition to ensure the overflow.
> 
> 
> Thus, there remain only the cases when ` Long.SIZE < BigInteger.bitLengthForLong(x) * n && (BigInteger.bitLengthForLong(x) - 1L) * n + 1L <= Long.SIZE`, in this cases checked multiplications in the loop are needed.
>  
> Moreover, `BigInteger.bitLengthForLong(x) - 1L` is a `long`, so the product does not overflow, so the condition at point 1 never overflows if it is evaluated only if the condition at point 2 is false.

@fabioromano1 Well, there are two checks. In one the product can overflow, you'd need to convert one of the operands to `long`.

Anyway, since the pre-checks are not precise, that would lead to an implementation with a loop with checked, and another one with unchecked multiplications. I don't think this buys you anything.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071920476

From darcy at openjdk.org  Fri May  2 17:21:50 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 May 2025 17:21:50 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
In-Reply-To: <cc8J6tnifhUTh3SCu7VWsvJHc1afHMZeFQpNgqFF7Ew=.09f294a6-f5ac-4905-9868-17c4a174a123@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
 <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
 <J8LYjKyW-DOppkSZxTWcRYllmQ_WzAwgTxLTdkh9Z4g=.e0d18849-bb60-45ab-851b-d034a26fe6bd@github.com>
 <cc8J6tnifhUTh3SCu7VWsvJHc1afHMZeFQpNgqFF7Ew=.09f294a6-f5ac-4905-9868-17c4a174a123@github.com>
Message-ID: <h0NG79gUPcH1_prs_0-BfqFkNnXGmlyJR6M79uUnJhU=.efdcbe80-3565-4be8-8fe3-b88c9791effb@github.com>

On Fri, 2 May 2025 16:54:59 GMT, Chen Liang <liach at openjdk.org> wrote:

> I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release <N>` argument or migrate class file parsing to ClassFile API.

Sounds good. I think prepping such a change is outside the scope of what @nizarbenalla or myself should do as part of the start of JDK 26 patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071921145

From rriggs at openjdk.org  Fri May  2 17:24:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 2 May 2025 17:24:06 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v3]
In-Reply-To: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
Message-ID: <QpnbZKc7ef8pJuC17i0V5VOJWcdHrBFzJfFxFmx-7P0=.689ad7c0-fbde-499c-b06d-907a8a98b36a@github.com>

> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
> Support methods are static, designed to pass all values as arguments and return a value.
> 
> The value byte array is reallocated under 3 conditions:
> - Increasing the capacity with the same encoder
> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
> - Inflation with the same capacity
> 
> Added StressSBTest to exercise public instance methods of StringBuilder.

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

  Optimize StringUTF16.putCharsAt a bit.
  Fixup hotspot Helper of putCharsAt to remove return value to match StringUTF16.putCharsAt.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24967/files
  - new: https://git.openjdk.org/jdk/pull/24967/files/f5003244..d2261cd6

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

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

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

From duke at openjdk.org  Fri May  2 17:30:48 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 2 May 2025 17:30:48 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v2]
In-Reply-To: <RhRURJNlPE4JJ_8hmILU3CUjY4SAf23CGaI3q0busAg=.2efdc9cd-5d7f-4ce0-b512-7b447afc356c@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
 <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>
 <oCuccSFQzcCuO5J5vCKn6bRJQ9fXCRdmW-Kd38ga9q0=.73bf1790-3464-48b7-9b3a-44445bba4c9b@github.com>
 <HzDhy333paUhxamAWEvC_OdlrvSdF9rlncXbRJKz0x0=.008b1a01-b9f6-4dce-bf56-bdbe3239fb61@github.com>
 <RhRURJNlPE4JJ_8hmILU3CUjY4SAf23CGaI3q0busAg=.2efdc9cd-5d7f-4ce0-b512-7b447afc356c@github.com>
Message-ID: <ZXUNv4ru5p_1rmgx0IaHXiL4pFZmbRqZnTZwl04ywB8=.9c0017f0-81cc-4df3-b250-3b71220463e2@github.com>

On Fri, 2 May 2025 17:18:36 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Anyway, since the pre-checks are not precise, that would lead to an implementation with a loop with checked, and another one with unchecked multiplications. I don't think this buys you anything.

It serves to skip the checks in the loop if in the common cases the length of the results are way more little with respect to `Long.SIZE` and to fail fast if in the common cases the length of the results are way more bigger than `Long.SIZE`.

> @fabioromano1 Well, there are two checks. In one the product can overflow, you'd need to convert one of the operands to `long`.

If the condition at point 1 is evaluated only if the condition at point 2 is false, then it can never overflow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071929231

From duke at openjdk.org  Fri May  2 17:33:50 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 2 May 2025 17:33:50 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v2]
In-Reply-To: <5wQQJ5le6CtE87hya7Kq6A4g8wdu2O35bifSTumwY04=.fd00d8ba-d951-4fca-b9dd-bec50a676e7a@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
 <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>
 <Vzp1-2EuHMiew6z7hPwbTFUeIKDstOmgouf0k3mZAQk=.b410e965-7cb3-49f7-8e84-7b2c00b5471f@github.com>
 <B3J8EvoOg0aj_k8_ATiImnmhM_EkA8yuLLOIt3bNjmc=.75adabc8-8afb-4b48-96a4-22c57857a6d7@github.com>
 <5wQQJ5le6CtE87hya7Kq6A4g8wdu2O35bifSTumwY04=.fd00d8ba-d951-4fca-b9dd-bec50a676e7a@github.com>
Message-ID: <I-JxMqSM__Ww1SBfZawoLfv3ZMQwKh5DTcckg_DIXPA=.c29bb83d-4aa0-4e8c-9f6a-fc70ff33fa3e@github.com>

On Fri, 2 May 2025 16:53:39 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> As for the `bitLength` check, the product might overflow. Further, `bitLength` might not be that cheap.

The current implementations of `bitLength()` calls `numberOfLeadingZeros`, which are:

public static int numberOfLeadingZeros(long i) {
        int x = (int)(i >>> 32);
        return x == 0 ? 32 + Integer.numberOfLeadingZeros((int)i)
                : Integer.numberOfLeadingZeros(x);
    }

public static int numberOfLeadingZeros(int i) {
        // HD, Count leading 0's
        if (i <= 0)
            return i == 0 ? 32 : 0;
        int n = 31;
        if (i >= 1 << 16) { n -= 16; i >>>= 16; }
        if (i >= 1 <<  8) { n -=  8; i >>>=  8; }
        if (i >= 1 <<  4) { n -=  4; i >>>=  4; }
        if (i >= 1 <<  2) { n -=  2; i >>>=  2; }
        return n - (i >>> 1);
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071934498

From rriggs at openjdk.org  Fri May  2 17:35:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 2 May 2025 17:35:53 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 UTF16::compress & Unsafe::copyMemory [v4]
In-Reply-To: <V8ZrRweDmVS9HD5kY8TM6xIVWBfiZy8StMHs6LPO78o=.59017549-3ec8-4627-b206-a9e897045081@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <V8ZrRweDmVS9HD5kY8TM6xIVWBfiZy8StMHs6LPO78o=.59017549-3ec8-4627-b206-a9e897045081@github.com>
Message-ID: <Wxyg9SVuqu7LVRudUKXl7K7kSw8_iA9ArJ18oBHb-rY=.02811a97-01ad-4185-9e61-474090ed2f89@github.com>

On Fri, 2 May 2025 03:49:39 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.
>> 
>> For these scenarios, we can use the intrinsic method StringUTF16.compress and Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/AbstractStringBuilder.java
>  - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/StringUTF16.java
>  - putCharsUnchecked
>  - copyright
>  - Using StringUTF16.compress to speed up LATIN1 StringBuilder append(char[])
>  - Using Unsafe.copyMemory to speed up UTF16 StringBuilder append(char[])
>  - add append(char[]) benchmark

Changes requested by rriggs (Reviewer).

src/java.base/share/classes/java/lang/StringUTF16.java line 1322:

> 1320:                 val,
> 1321:                 Unsafe.ARRAY_BYTE_BASE_OFFSET + ((long) index << 1),
> 1322:                 ((long) (end - off)) << 1);

This use of Unsafe is not warranted. If it can't be done with arrayCopy, leave the original code as is.

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

PR Review: https://git.openjdk.org/jdk/pull/24773#pullrequestreview-2812557629
PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2071937012

From mcimadamore at openjdk.org  Fri May  2 17:36:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 May 2025 17:36:57 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v8]
In-Reply-To: <4OR68YXIZ0pTSWMdn9Csl-kulCXobpPNc6_G1eWC2qE=.0909310c-717f-4d7e-8db2-f736a6505733@github.com>
References: <WNzFDYktILPy7RAKXc5pAKaT8tA-vtsMIXscoUltaWg=.4c676184-51ec-44d1-8af7-173766021ef1@github.com>
 <_1w-qtbtC-Vds4jIYWDaVJUZTfnsTVL26x23meTbRqY=.33e67efd-c962-4f7b-bed8-0653ca73d8b7@github.com>
 <4OR68YXIZ0pTSWMdn9Csl-kulCXobpPNc6_G1eWC2qE=.0909310c-717f-4d7e-8db2-f736a6505733@github.com>
Message-ID: <JPV_x6ZUzDWQTJP89y4qbV-xVMMfLUP6NcLQTOiakyk=.f11dd623-626c-46e7-be91-ad86bff3a768@github.com>

On Fri, 2 May 2025 14:12:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> The performance before this PR can be seen in the "confined" benchmarks above. In those benchmarks, a regular `Arena.ofConfined` is created upon every invocation.

Yes - but I was referring to the performance of the native call -- not that of the allocation per se (e.g. `CallOverheadByValue`). If I'm not mistaken the numbers of that benchmark all refer to new code (well, except when we pass by pointer, in which case there's no allocation -- both before and after this PR).

E.g. it would be useful to also see how the by-value call has improved before/after this PR, in addition to looking at the difference between byValue/byRef in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2847747932

From rriggs at openjdk.org  Fri May  2 17:37:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 2 May 2025 17:37:54 GMT
Subject: RFR: 8349176: Speed up Integer/Long.toString via
 StringConcatHelper::newArray [v3]
In-Reply-To: <kc28TuEhKYFGcG66xECqIMUbvWJhJfJ8FtfwQwBiz8g=.6fd2d4a9-7a8d-4616-b87b-80f52d48f6b3@github.com>
References: <u9INrX9ZnlI8Hs0gC1hnE-oYiHLrnL93Q5hF1yzmJgM=.8b5bb878-27f0-4c21-a1bb-82ce65634b81@github.com>
 <kc28TuEhKYFGcG66xECqIMUbvWJhJfJ8FtfwQwBiz8g=.6fd2d4a9-7a8d-4616-b87b-80f52d48f6b3@github.com>
Message-ID: <uKq8ZO0wJ0vqChHNI1Pgl7XZr2ejVB91YH4izJEz5wU=.05486a6c-c460-49a7-a037-65d3baca1f14@github.com>

On Fri, 2 May 2025 03:55:24 GMT, Shaojin Wen <swen at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into allocate_un_init_202501
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/Integer.java
>    #	src/java.base/share/classes/java/lang/Long.java
>  - use StringConcatHelper.newArray
>  - simplify
>  - use Unsafe.allocateUninitializedArray
>  - revert StringConcatHelper newArray change
>  - copyright
>  - remove duplicate check
>  - allocateUninitializedArray

The StringConcatHelper methods should not be used outside of StringConcat.

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

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23353#pullrequestreview-2812563398

From jlu at openjdk.org  Fri May  2 17:39:08 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 2 May 2025 17:39:08 GMT
Subject: RFR: 8356040:
 java/util/PluggableLocale/LocaleNameProviderTest.java timed out [v2]
In-Reply-To: <ZlNw-uu8c-LYrPGPOzC2ab4YHelGWdKD0mo12m3CFT0=.d43f7119-3594-48aa-90ed-d92c502ee3a5@github.com>
References: <ZlNw-uu8c-LYrPGPOzC2ab4YHelGWdKD0mo12m3CFT0=.d43f7119-3594-48aa-90ed-d92c502ee3a5@github.com>
Message-ID: <ny4l-50hJsEa69IOxJkcdtPOr1l8uv-3gmG9kAXRvSE=.4fbd4581-580c-41ca-9af2-777b1b0f05b4@github.com>

> Please review this PR which reduces the amount of combinations tested by `LocaleNameProviderTest`.
> 
> This test was exhaustively testing over 1000x1000 `Locale` combinations which was expensive and caused a timeout in tier 5. Narrowing down the tested locales to Japanese language ones can reduce our tested input to 9x9 and provides most of the same value the test previously did. (Since our SPI provider has defined preferred Japanese Locale name values.) This change also refactors the test to use JUnit. The test now runs around ~20 times faster.
> 
> Most of the diff is attributed to separating the method source from the test itself. But notice the filtering of `Locale`s done on `availloc` and `jreImplLoc`.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Naoto review - update comment, isEmpty()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25009/files
  - new: https://git.openjdk.org/jdk/pull/25009/files/c3e77cde..579c1ebe

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

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

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

From duke at openjdk.org  Fri May  2 17:41:57 2025
From: duke at openjdk.org (Christoph)
Date: Fri, 2 May 2025 17:41:57 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
Message-ID: <A6U0fFOF5_HykVcUA1icZqPwEjYdZ7zLHRMgArruTG4=.a5c571b6-ca1d-48ea-977b-0f551fc6ce81@github.com>

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
> - This change is for macOS only.
> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

When supplying mac sign to building the image, it does not work either and then applying.
The current branch is here in this PR https://github.com/JabRef/jabref/pull/13032/

And now I remember that probably this was the initial reason for using the original approach mentioned earlier with specifcying the app content 


  "severity": "error",
      "code": null,
      "path": "JabRef-6.0_arm64.dmg/JabRef.app/Contents/MacOS/JabRef",
      "message": "The signature of the binary is invalid.",
      "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087735",
      "architecture": "arm64"
    }

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2847757982

From jiangli at openjdk.org  Fri May  2 17:43:37 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 2 May 2025 17:43:37 GMT
Subject: RFR: 8356050: Problemlist jdk,
 langtools & lib-test tier1 tests requiring runtime usages of <jdk>/bin/tools
 for static-jdk [v2]
In-Reply-To: <lYyYzYPIR2XTf9BvhyjjXqDouhTtIXEobg8d8yrQDD4=.2e61aa4e-d4b8-4f3e-ab58-f5ef3c1465f4@github.com>
References: <lYyYzYPIR2XTf9BvhyjjXqDouhTtIXEobg8d8yrQDD4=.2e61aa4e-d4b8-4f3e-ab58-f5ef3c1465f4@github.com>
Message-ID: <yQbxpPosPX10H2Z1MKSqghOpjQGA8KOa5ig9JEtaIZE=.6311a6af-e786-4309-b72e-d7304f71bd1c@github.com>

> Please review this PR to problemlist jdk & langtools tier1 tests requiring runtime usages of <jdk>/bin/tools, for testing on static-jdk. The affected tests using following tools at runtime:
> 
> - javac
> - javadoc
> - jar
> - jarsigner
> - jcmd
> - jimage
> - jps
> 
> The latest teir1 testing results on static-jdk: https://github.com/jianglizhou/jdk/actions/runs/14781658116/job/41503569932.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Problemlist jdk/test/lib/hprof/HprofTest.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24995/files
  - new: https://git.openjdk.org/jdk/pull/24995/files/8954219a..982a6cfc

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

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

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

From rriggs at openjdk.org  Fri May  2 17:45:46 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 2 May 2025 17:45:46 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java
In-Reply-To: <Dt3uWlr2qxiuWJrU5N4feOrIwpNEj28v9xpEaQJ974M=.2999cc9d-a782-4ac2-a92d-9fbaca7c0574@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
 <sS3HZ2aZsOqrm__NxCUeKvdCgwgnYXEP-4LxP7oN0fA=.69034e9c-a0ef-4842-a739-f95124523a0f@github.com>
 <tvPY07xY8QPSk2Bop7Dm4U4wLLc2LdWAc1UCWm9oFL8=.7609fb9d-3362-45ac-a0a2-dd44b7570d41@github.com>
 <6CRYc09LAUqqqP9cJbNow9BkHS_bJcY1nTIpJJVxA5o=.4aea935a-8c8d-45b5-a74e-5a18d02dfd8d@github.com>
 <Dt3uWlr2qxiuWJrU5N4feOrIwpNEj28v9xpEaQJ974M=.2999cc9d-a782-4ac2-a92d-9fbaca7c0574@github.com>
Message-ID: <ZkcLZZ8VyKHLib1iV60Rrl2j57MFPBJSeJoJO-hcuHs=.80f10646-a11d-4800-99f5-75c47e7a3c6a@github.com>

On Thu, 1 May 2025 21:58:18 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Is `echo.` shorthand for `echo.exe`; if so, please change to the long form to make it clearer the echo program is being run.
>
> No, `echo.` is not an executable, this is a command of the Windows Command Processor.
> 
> See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo

That sounds brittle. The "echo." usage is not specified, only shown as an example.
Under what command parsing rule does it run exactly the "echo" builtin?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2071947579

From asemenyuk at openjdk.org  Fri May  2 17:46:53 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 2 May 2025 17:46:53 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <A6U0fFOF5_HykVcUA1icZqPwEjYdZ7zLHRMgArruTG4=.a5c571b6-ca1d-48ea-977b-0f551fc6ce81@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
 <A6U0fFOF5_HykVcUA1icZqPwEjYdZ7zLHRMgArruTG4=.a5c571b6-ca1d-48ea-977b-0f551fc6ce81@github.com>
Message-ID: <1ziGVo3kRSjV25DaqA9w4wPyFJYndFyxzxRhtguOhFE=.45e09cd7-7645-4a76-91a5-cc9e7f5a1c15@github.com>

On Fri, 2 May 2025 17:39:16 GMT, Christoph <duke at openjdk.org> wrote:

> And now I remember that probably this was the initial reason for using the original approach mentioned earlier with specifcying the app content

This means the two-stage packaging with signing is completely broken in jpackage. Not good. Can you share jpackage logs?

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2847767094

From darcy at openjdk.org  Fri May  2 17:46:58 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 May 2025 17:46:58 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
In-Reply-To: <9h_A8ZO25cAxj_Sex6ez9Lan6hjyoTc0_7PNqaCwfnI=.c8a68611-607c-4d6c-b0c9-23e8909a7376@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
 <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
 <9h_A8ZO25cAxj_Sex6ez9Lan6hjyoTc0_7PNqaCwfnI=.c8a68611-607c-4d6c-b0c9-23e8909a7376@github.com>
Message-ID: <Cnl_A-g8Rn37q28wvO9iSEhh_U8oEB6fy_o0ujJen4w=.d9ac811f-413e-4922-b402-792122673299@github.com>

On Fri, 2 May 2025 16:55:49 GMT, Chen Liang <liach at openjdk.org> wrote:

> May I prepare a quick patch to bring this in line with `TraverseProc` so we can skip this site for future start of release updates?

I know it is possible to write getSupportedSourceVersion to return the latest version, but I don't think it is appropriate for this annotation processor to use that idiom since it might actually need to be meaningfully updated with code changes to support the new source level. Explicitly needing to change this annotation is a backstop reminder to do that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071949205

From swen at openjdk.org  Fri May  2 17:51:49 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 17:51:49 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v3]
In-Reply-To: <QpnbZKc7ef8pJuC17i0V5VOJWcdHrBFzJfFxFmx-7P0=.689ad7c0-fbde-499c-b06d-907a8a98b36a@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <QpnbZKc7ef8pJuC17i0V5VOJWcdHrBFzJfFxFmx-7P0=.689ad7c0-fbde-499c-b06d-907a8a98b36a@github.com>
Message-ID: <yzIStBhU9mAjPrC_GoQZZMhygrKGz01pzGv5Hy7QhWU=.663c98e2-4e2a-42a5-b713-5aee495a4519@github.com>

On Fri, 2 May 2025 17:24:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize StringUTF16.putCharsAt a bit.
>   Fixup hotspot Helper of putCharsAt to remove return value to match StringUTF16.putCharsAt.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1970:

> 1968:     private static byte[] appendChars(byte[] value, byte coder, int count, char[] s, int off, int end) {
> 1969:         if (isLatin1(coder)) {
> 1970:             for (int i = off, j = count; i < end; i++) {

Suggestion:

            int compressed = StringUTF16.compress(s, off, value, count, end - off);
            for (int i = compressed + off, j = count + compressed; i < end; i++) {

Refer to PR #24773, adding StringUTF16.compress preprocessing here will improve the performance of java.io.BufferedReader::readLine method.

Should it be done at once or separately for PR #24773 to make changes?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2071954862

From rgiulietti at openjdk.org  Fri May  2 17:52:44 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 May 2025 17:52:44 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v2]
In-Reply-To: <I-JxMqSM__Ww1SBfZawoLfv3ZMQwKh5DTcckg_DIXPA=.c29bb83d-4aa0-4e8c-9f6a-fc70ff33fa3e@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
 <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>
 <Vzp1-2EuHMiew6z7hPwbTFUeIKDstOmgouf0k3mZAQk=.b410e965-7cb3-49f7-8e84-7b2c00b5471f@github.com>
 <B3J8EvoOg0aj_k8_ATiImnmhM_EkA8yuLLOIt3bNjmc=.75adabc8-8afb-4b48-96a4-22c57857a6d7@github.com>
 <5wQQJ5le6CtE87hya7Kq6A4g8wdu2O35bifSTumwY04=.fd00d8ba-d951-4fca-b9dd-bec50a676e7a@github.com>
 <I-JxMqSM__Ww1SBfZawoLfv3ZMQwKh5DTcckg_DIXPA=.c29bb83d-4aa0-4e8c-9f6a-fc70ff33fa3e@github.com>
Message-ID: <Yq6-D4R6nlbAO0o2JRoY6bumZzFOF-qPXydXEQXCZW0=.d203192d-b0a6-45fa-a0ee-fe5c696f75e0@github.com>

On Fri, 2 May 2025 17:30:55 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Again, I don't think that `n == 1` is a frequent case which would make any practical difference.
>> 
>> As for the `bitLength` check, the product might overflow.
>> Further, `bitLength` might not be that cheap.
>> Finally, the test would just help to _fail_ faster at the expense of making the successful runs slightly slower.
>
>> As for the `bitLength` check, the product might overflow. Further, `bitLength` might not be that cheap.
> 
> The current implementations of `bitLength()` call `numberOfLeadingZeros()`, which are:
> 
> public static int numberOfLeadingZeros(long i) {
>         int x = (int)(i >>> 32);
>         return x == 0 ? 32 + Integer.numberOfLeadingZeros((int)i)
>                 : Integer.numberOfLeadingZeros(x);
>     }
> 
> public static int numberOfLeadingZeros(int i) {
>         // HD, Count leading 0's
>         if (i <= 0)
>             return i == 0 ? 32 : 0;
>         int n = 31;
>         if (i >= 1 << 16) { n -= 16; i >>>= 16; }
>         if (i >= 1 <<  8) { n -=  8; i >>>=  8; }
>         if (i >= 1 <<  4) { n -=  4; i >>>=  4; }
>         if (i >= 1 <<  2) { n -=  2; i >>>=  2; }
>         return n - (i >>> 1);
>     }

Yes, I'm familiar with both this Java code and the intrinsic code.

Compare this with the much simpler proposed code.
The checked multiplication `unsignedMultiplyExact` apparently performs two 64x64->64 multiplications, but on some architectures it might end up in a single 64x64->128 multiplication and one check.
So the proposed code performs 6 such multiplications if the method returns + 5 ordinary multiplications in the worst case.

As a general rule, the simpler the code, the better the outcome of the optimizing compiler.

Again, to me there's no point in failing fast at the expense of the successful case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071955574

From rgiulietti at openjdk.org  Fri May  2 17:57:48 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 May 2025 17:57:48 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v2]
In-Reply-To: <ZXUNv4ru5p_1rmgx0IaHXiL4pFZmbRqZnTZwl04ywB8=.9c0017f0-81cc-4df3-b250-3b71220463e2@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
 <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>
 <oCuccSFQzcCuO5J5vCKn6bRJQ9fXCRdmW-Kd38ga9q0=.73bf1790-3464-48b7-9b3a-44445bba4c9b@github.com>
 <HzDhy333paUhxamAWEvC_OdlrvSdF9rlncXbRJKz0x0=.008b1a01-b9f6-4dce-bf56-bdbe3239fb61@github.com>
 <RhRURJNlPE4JJ_8hmILU3CUjY4SAf23CGaI3q0busAg=.2efdc9cd-5d7f-4ce0-b512-7b447afc356c@github.com>
 <ZXUNv4ru5p_1rmgx0IaHXiL4pFZmbRqZnTZwl04ywB8=.9c0017f0-81cc-4df3-b250-3b71220463e2@github.com>
Message-ID: <viuNB6jdXw8J3Cn6b4U6Y9UMsQkkxG8EcZNYSpNrJSw=.0b9c3f8f-98ca-4083-8d1b-1a350e60ca63@github.com>

On Fri, 2 May 2025 17:26:21 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> @fabioromano1 Well, there are two checks. In one the product can overflow, you'd need to convert one of the operands to `long`.
>> 
>> Anyway, since the pre-checks are not precise, that would lead to an implementation with a loop with checked, and another one with unchecked multiplications. I don't think this buys you anything.
>
>> Anyway, since the pre-checks are not precise, that would lead to an implementation with a loop with checked, and another one with unchecked multiplications. I don't think this buys you anything.
> 
> It serves to skip the checks in the loop if in the common cases the length of the results are way more little with respect to `Long.SIZE` and to fail fast if in the common cases the length of the results are way bigger than `Long.SIZE`.
> 
>> @fabioromano1 Well, there are two checks. In one the product can overflow, you'd need to convert one of the operands to `long`.
> 
> If the condition at point 1 is evaluated only if the condition at point 2 is false, then it can never overflow.

If that check would be a couple of instructions or so, then I could agree.

True, there are no overflows in the checks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071959063

From duke at openjdk.org  Fri May  2 17:57:47 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 2 May 2025 17:57:47 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v2]
In-Reply-To: <9ACW3UJDsgcJh02OftWGSeFNa5dbZVtG5NRVSuk5QnQ=.5119a855-507e-4d8a-a069-6b927a9a049e@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
 <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>
 <9ACW3UJDsgcJh02OftWGSeFNa5dbZVtG5NRVSuk5QnQ=.5119a855-507e-4d8a-a069-6b927a9a049e@github.com>
Message-ID: <mYyGH7yq1-u7lz1XHxweHF1AK62baAj178GmFQUxDVo=.fb746b58-3e38-4e3b-8607-b3d34e5494b4@github.com>

On Fri, 2 May 2025 16:57:43 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Math.java line 3500:
>> 
>>> 3498:             return (n & 0b1) == 0 ? 1 : -1;
>>> 3499:         }
>>> 3500: 
>> 
>> Suggestion:
>> 
>> 
>>         if (x == 2) {
>>             if (n >= Integer.SIZE - 1)
>>                 throw new ArithmeticException("integer overflow");
>>             return 1 << n;
>>         }
>>         if (x == -2) {
>>             if (n >= Integer.SIZE)
>>                 throw new ArithmeticException("integer overflow");
>>             // if n == Integer.SIZE - 1, result is correct
>>             return (n & 0b1) == 0 ? 1 << n : -(1 << n);
>>         }
>> 
>>        if ((java.math.BigInteger.bitLengthForInt(Math.abs(x)) - 1L) * n + 1L > Integer.SIZE) {
>>            throw new ArithmeticException("integer overflow");
>>        }
>> 
>> With also a check for the condition `java.math.BigInteger.bitLengthForInt(Math.abs(x)) * n < Integer.SIZE`, when it is true the path could be led to a loop that skips the checks.
>
> return (n & 0b1) == 0 ? 1 << n : -(1 << n);
> 
> 
> Equivalent to 
> 
> 
> 
> return ((1 << n) ^ -(n & 1)) + (n & 1);
> 
> 
> Without branches it should be faster

> ```java
> return ((1 << n) ^ -(n & 1)) + (n & 1);
> ```

It should have a comment that explains that this does the two's complement if `n` is odd, and it does nothing otherwise. Anyway, probably the optimization for `x == -2` will not be included.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071960548

From swen at openjdk.org  Fri May  2 17:58:48 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 17:58:48 GMT
Subject: RFR: 8349176: Speed up Integer/Long.toString via
 StringConcatHelper::newArray [v3]
In-Reply-To: <uKq8ZO0wJ0vqChHNI1Pgl7XZr2ejVB91YH4izJEz5wU=.05486a6c-c460-49a7-a037-65d3baca1f14@github.com>
References: <u9INrX9ZnlI8Hs0gC1hnE-oYiHLrnL93Q5hF1yzmJgM=.8b5bb878-27f0-4c21-a1bb-82ce65634b81@github.com>
 <kc28TuEhKYFGcG66xECqIMUbvWJhJfJ8FtfwQwBiz8g=.6fd2d4a9-7a8d-4616-b87b-80f52d48f6b3@github.com>
 <uKq8ZO0wJ0vqChHNI1Pgl7XZr2ejVB91YH4izJEz5wU=.05486a6c-c460-49a7-a037-65d3baca1f14@github.com>
Message-ID: <E2I6ZhuWou_vUtf7ZL4kGLrL5AlYRCmVv8FNlAF5M54=.6f09b1a8-1f32-41e9-8d79-8e59c9754525@github.com>

On Fri, 2 May 2025 17:35:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The StringConcatHelper methods should not be used outside of StringConcat.

I had a version that used UNSAFE.allocateUninitializedArray , but @liach suggested using StringConcatHelper.newArray

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

PR Comment: https://git.openjdk.org/jdk/pull/23353#issuecomment-2847787404

From duke at openjdk.org  Fri May  2 18:04:55 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 2 May 2025 18:04:55 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v2]
In-Reply-To: <viuNB6jdXw8J3Cn6b4U6Y9UMsQkkxG8EcZNYSpNrJSw=.0b9c3f8f-98ca-4083-8d1b-1a350e60ca63@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
 <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>
 <oCuccSFQzcCuO5J5vCKn6bRJQ9fXCRdmW-Kd38ga9q0=.73bf1790-3464-48b7-9b3a-44445bba4c9b@github.com>
 <HzDhy333paUhxamAWEvC_OdlrvSdF9rlncXbRJKz0x0=.008b1a01-b9f6-4dce-bf56-bdbe3239fb61@github.com>
 <RhRURJNlPE4JJ_8hmILU3CUjY4SAf23CGaI3q0busAg=.2efdc9cd-5d7f-4ce0-b512-7b447afc356c@github.com>
 <ZXUNv4ru5p_1rmgx0IaHXiL4pFZmbRqZnTZwl04ywB8=.9c0017f0-81cc-4df3-b250-3b71220463e2@github.com>
 <viuNB6jdXw8J3Cn6b4U6Y9UMsQkkxG8EcZNYSpNrJSw=.0b9c3f8f-98ca-4083-8d1b-1a350e60ca63@github.com>
Message-ID: <w1JPrUIXNseCejG19OPNLXopNn_f3zqSJfC8wSIf0xU=.b7c791a9-0663-4e16-98b9-a6941e01e419@github.com>

On Fri, 2 May 2025 17:53:12 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>>> Anyway, since the pre-checks are not precise, that would lead to an implementation with a loop with checked, and another one with unchecked multiplications. I don't think this buys you anything.
>> 
>> It serves to skip the checks in the loop if in the common cases the length of the results are way more little with respect to `Long.SIZE` and to fail fast if in the common cases the length of the results are way bigger than `Long.SIZE`.
>> 
>>> @fabioromano1 Well, there are two checks. In one the product can overflow, you'd need to convert one of the operands to `long`.
>> 
>> If the condition at point 1 is evaluated only if the condition at point 2 is false, then it can never overflow.
>
> If that check would be a couple of instructions or so, then I could agree.
> 
> True, there are no overflows in the checks.

@rgiulietti If you think that this checks might be useful, the choice is yours.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2071969275

From liach at openjdk.org  Fri May  2 18:05:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 18:05:52 GMT
Subject: RFR: 8349176: Speed up Integer/Long.toString via
 StringConcatHelper::newArray [v3]
In-Reply-To: <kc28TuEhKYFGcG66xECqIMUbvWJhJfJ8FtfwQwBiz8g=.6fd2d4a9-7a8d-4616-b87b-80f52d48f6b3@github.com>
References: <u9INrX9ZnlI8Hs0gC1hnE-oYiHLrnL93Q5hF1yzmJgM=.8b5bb878-27f0-4c21-a1bb-82ce65634b81@github.com>
 <kc28TuEhKYFGcG66xECqIMUbvWJhJfJ8FtfwQwBiz8g=.6fd2d4a9-7a8d-4616-b87b-80f52d48f6b3@github.com>
Message-ID: <iZdPdU_26B0cEswrNF5YChYxndl5mrx-yvB4p-bvrww=.9cdc8ad1-fc24-42b3-83b7-203c020c4d2a@github.com>

On Fri, 2 May 2025 03:55:24 GMT, Shaojin Wen <swen at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into allocate_un_init_202501
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/Integer.java
>    #	src/java.base/share/classes/java/lang/Long.java
>  - use StringConcatHelper.newArray
>  - simplify
>  - use Unsafe.allocateUninitializedArray
>  - revert StringConcatHelper newArray change
>  - copyright
>  - remove duplicate check
>  - allocateUninitializedArray

src/java.base/share/classes/java/lang/Integer.java line 439:

> 437:             return new String(buf, LATIN1);
> 438:         } else {
> 439:             byte[] buf = StringConcatHelper.newArray(size << 1);

@RogerRiggs I recommended StringConcatHelper because that was used in StringLatin1.

For StringUTF16, it has its own newBytesFor:
Suggestion:

            byte[] buf = StringUTF16.newBytesFor(size);

Or we can factor out a `StringLatin1.newBytesFor` too and encapsulate `newArray` usage.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23353#discussion_r2071969862

From duke at openjdk.org  Fri May  2 18:09:58 2025
From: duke at openjdk.org (Christoph)
Date: Fri, 2 May 2025 18:09:58 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
Message-ID: <FlbSG1pt1OV6Px57k7limNCMhipvP5KCz_JxMwCI61I=.fa2917db-2182-4393-9db8-6fe22d526331@github.com>

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
> - This change is for macOS only.
> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

>From the GitHub actions run with double signing:  (mac os 14 runner) 
jpackage Log starts at `Creating app package: JabRef.app`

[signed_image_signed_dmg_macOS (ARM64) installer and portable version.txt](https://github.com/user-attachments/files/20016626/signed_image_signed_dmg_macOS.ARM64.installer.and.portable.version.txt)

Run with only signing the pkg/dmg: 
[only signing dmg_macOS (ARM64) installer and portable version.txt](https://github.com/user-attachments/files/20016647/only.signing.dmg_macOS.ARM64.installer.and.portable.version.txt)

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2847804315

From swen at openjdk.org  Fri May  2 18:14:45 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 18:14:45 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 UTF16::compress & Unsafe::copyMemory [v4]
In-Reply-To: <Wxyg9SVuqu7LVRudUKXl7K7kSw8_iA9ArJ18oBHb-rY=.02811a97-01ad-4185-9e61-474090ed2f89@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <V8ZrRweDmVS9HD5kY8TM6xIVWBfiZy8StMHs6LPO78o=.59017549-3ec8-4627-b206-a9e897045081@github.com>
 <Wxyg9SVuqu7LVRudUKXl7K7kSw8_iA9ArJ18oBHb-rY=.02811a97-01ad-4185-9e61-474090ed2f89@github.com>
Message-ID: <KOHIfa0AS_WepowGrmopq0fgWM-P7aI22AXONSWH1Xc=.867948c7-6ecc-49bb-b0f1-6301d6deca44@github.com>

On Fri, 2 May 2025 17:32:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> This use of Unsafe is not warranted. If it can't be done with arrayCopy, leave the original code as is.

The core library also uses Unsafe.copyMemory in many places. Can it be used in this scenario? Or can we find other ways to copy char[] to byte[]?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2071979599

From swen at openjdk.org  Fri May  2 18:17:51 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 18:17:51 GMT
Subject: RFR: 8349176: Speed up Integer/Long.toString via
 StringConcatHelper::newArray [v3]
In-Reply-To: <iZdPdU_26B0cEswrNF5YChYxndl5mrx-yvB4p-bvrww=.9cdc8ad1-fc24-42b3-83b7-203c020c4d2a@github.com>
References: <u9INrX9ZnlI8Hs0gC1hnE-oYiHLrnL93Q5hF1yzmJgM=.8b5bb878-27f0-4c21-a1bb-82ce65634b81@github.com>
 <kc28TuEhKYFGcG66xECqIMUbvWJhJfJ8FtfwQwBiz8g=.6fd2d4a9-7a8d-4616-b87b-80f52d48f6b3@github.com>
 <iZdPdU_26B0cEswrNF5YChYxndl5mrx-yvB4p-bvrww=.9cdc8ad1-fc24-42b3-83b7-203c020c4d2a@github.com>
Message-ID: <YtiElTVt_9jTMu8OmvhEeo2ylqUf7mB5hxaB5lyEi-w=.3718a151-1c41-43ed-8f8c-354399eefaa7@github.com>

On Fri, 2 May 2025 18:02:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into allocate_un_init_202501
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/lang/Integer.java
>>    #	src/java.base/share/classes/java/lang/Long.java
>>  - use StringConcatHelper.newArray
>>  - simplify
>>  - use Unsafe.allocateUninitializedArray
>>  - revert StringConcatHelper newArray change
>>  - copyright
>>  - remove duplicate check
>>  - allocateUninitializedArray
>
> src/java.base/share/classes/java/lang/Integer.java line 439:
> 
>> 437:             return new String(buf, LATIN1);
>> 438:         } else {
>> 439:             byte[] buf = StringConcatHelper.newArray(size << 1);
> 
> @RogerRiggs I recommended StringConcatHelper because that was used in StringLatin1.
> 
> For StringUTF16, it has its own newBytesFor:
> Suggestion:
> 
>             byte[] buf = StringUTF16.newBytesFor(size);
> 
> Or we can factor out a `StringLatin1.newBytesFor` too and encapsulate `newArray` usage.

public static byte[] newBytesFor(int len) {
        return new byte[newBytesLength(len)];
    }

StringUTF16.newBytesFor uses new byte[], which is not the purpose of this PR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23353#discussion_r2071982990

From bpb at openjdk.org  Fri May  2 18:19:35 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 May 2025 18:19:35 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v3]
In-Reply-To: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
Message-ID: <V_z1LM8NiXvm2IaCKIJHcr-WrAVCc7KVB7eYUjGSszU=.dd1c921c-a20b-471b-8e5f-be63360be0d8@github.com>

> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24977/files
  - new: https://git.openjdk.org/jdk/pull/24977/files/efca3cf4..0fef4782

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

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

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

From smarks at openjdk.org  Fri May  2 18:31:31 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 2 May 2025 18:31:31 GMT
Subject: RFR: 8351230: Collections.synchronizedList returns a list that is not
 thread-safe
Message-ID: <HtBkFlpJ7N3BjMiDZcA2LgM0YOEkd4L1_6XKIPJwwew=.6325e6ba-153e-43c6-9de6-ab00c1e972ed@github.com>

Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper:

- overrides and adds locking to SequencedCollection methods;
- performs instance management of reversed synchronized views;
- adds test for race conditions and functional tests of synchronized wrappers.

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

Commit messages:
 - moar comments
 - Various tweaks.
 - fix for synch list
 - fix copyright line
 - tests for synch list

Changes: https://git.openjdk.org/jdk/pull/24990/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24990&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351230
  Stats: 227 lines in 3 files changed: 214 ins; 9 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24990.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24990/head:pull/24990

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

From weijun at openjdk.org  Fri May  2 18:31:52 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 May 2025 18:31:52 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5]
In-Reply-To: <DP4G9gxUfBGeHKkeWaT3q8nCyBdvc-oWh6SoENgFNM4=.8a0c9e82-b3b9-47c8-96d4-853918c410ae@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <To8P9zSROG54ayME3D-98HIN0qqjfORNadZD8GA4R4I=.440e00b9-9f46-4b0a-ac0f-14612be358e2@github.com>
 <DP4G9gxUfBGeHKkeWaT3q8nCyBdvc-oWh6SoENgFNM4=.8a0c9e82-b3b9-47c8-96d4-853918c410ae@github.com>
Message-ID: <gU8Het2pCRd7EcHGYwNW4laXpCAb1mbgPxrA-_HegwM=.7da4ac42-3343-4599-961f-a14024daf034@github.com>

On Fri, 2 May 2025 12:50:41 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang 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
>>  - add a positive debug log and update exception message
>>  - enhancing exception messages and debug outputs
>>  - update @since tags as required by JEP 12
>>  - add enum back
>>  - the change
>
> src/java.base/share/classes/javax/crypto/KDF.java line 491:
> 
>> 489:                     + "using the supplied derivation "
>> 490:                     + "inputs, using the " + source + " "
>> 491:                     + theOne.provider().getName()
> 
> Suggest rewording as: "inputs with the " + source + " " + theOne.provider().getName() + " provider."

The exception message following uses `"The " + source + " provider " + theOne.provider.getName()`. Shall I also switch to `"The " + source + " " + theOne.provider.getName() + " provider"`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2071997676

From mullan at openjdk.org  Fri May  2 18:39:47 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 2 May 2025 18:39:47 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5]
In-Reply-To: <gU8Het2pCRd7EcHGYwNW4laXpCAb1mbgPxrA-_HegwM=.7da4ac42-3343-4599-961f-a14024daf034@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <To8P9zSROG54ayME3D-98HIN0qqjfORNadZD8GA4R4I=.440e00b9-9f46-4b0a-ac0f-14612be358e2@github.com>
 <DP4G9gxUfBGeHKkeWaT3q8nCyBdvc-oWh6SoENgFNM4=.8a0c9e82-b3b9-47c8-96d4-853918c410ae@github.com>
 <gU8Het2pCRd7EcHGYwNW4laXpCAb1mbgPxrA-_HegwM=.7da4ac42-3343-4599-961f-a14024daf034@github.com>
Message-ID: <kDBE92WygZKrDPnp3eTuuFXzrw_PWt4M_qe1kZhhTuk=.aa69bfd7-eeb7-4b78-b1db-25080b0efb61@github.com>

On Fri, 2 May 2025 18:29:14 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/KDF.java line 491:
>> 
>>> 489:                     + "using the supplied derivation "
>>> 490:                     + "inputs, using the " + source + " "
>>> 491:                     + theOne.provider().getName()
>> 
>> Suggest rewording as: "inputs with the " + source + " " + theOne.provider().getName() + " provider."
>
> The exception message following uses `"The " + source + " provider " + theOne.provider.getName()`. Shall I also switch to `"The " + source + " " + theOne.provider.getName() + " provider"`?

Yes, good to make it consistent. I think it reads slightly better if the name of the provider comes before "provider".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2072005947

From naoto at openjdk.org  Fri May  2 18:42:45 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 May 2025 18:42:45 GMT
Subject: RFR: 8356040:
 java/util/PluggableLocale/LocaleNameProviderTest.java timed out [v2]
In-Reply-To: <ny4l-50hJsEa69IOxJkcdtPOr1l8uv-3gmG9kAXRvSE=.4fbd4581-580c-41ca-9af2-777b1b0f05b4@github.com>
References: <ZlNw-uu8c-LYrPGPOzC2ab4YHelGWdKD0mo12m3CFT0=.d43f7119-3594-48aa-90ed-d92c502ee3a5@github.com>
 <ny4l-50hJsEa69IOxJkcdtPOr1l8uv-3gmG9kAXRvSE=.4fbd4581-580c-41ca-9af2-777b1b0f05b4@github.com>
Message-ID: <vg2atXbtnYPHwgpDqZLmnK05laqPQFY630_MKr1pYoc=.9f040ee0-a28d-4259-8c7c-2ad93229c422@github.com>

On Fri, 2 May 2025 17:39:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which reduces the amount of combinations tested by `LocaleNameProviderTest`.
>> 
>> This test was exhaustively testing over 1000x1000 `Locale` combinations which was expensive and caused a timeout in tier 5. Narrowing down the tested locales to Japanese language ones can reduce our tested input to 9x9 and provides most of the same value the test previously did. (Since our SPI provider has defined preferred Japanese Locale name values.) This change also refactors the test to use JUnit. The test now runs around ~20 times faster.
>> 
>> Most of the diff is attributed to separating the method source from the test itself. But notice the filtering of `Locale`s done on `availloc` and `jreImplLoc`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto review - update comment, isEmpty()

LGTM. Thanks for simplifying the test

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25009#pullrequestreview-2812676717

From weijun at openjdk.org  Fri May  2 18:49:34 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 May 2025 18:49:34 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6]
In-Reply-To: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
Message-ID: <IGzpehDXDsv_5MZ1ZOO1MnrqLPp1bYNS4anT8Z-8f88=.577c3298-d6d9-48bc-86cf-21c83bfb910b@github.com>

> Finalize the KDF API.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  fine tuning debug log and exception message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24520/files
  - new: https://git.openjdk.org/jdk/pull/24520/files/323b046b..f44dc9bd

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

  Stats: 8 lines in 2 files changed: 1 ins; 0 del; 7 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 smarks at openjdk.org  Fri May  2 19:03:53 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 2 May 2025 19:03:53 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <F2QI8fLrAJ2ZB6nPfxenoaxVTP6_i1tMt3-9OLiXh0U=.3df00047-29b5-42e2-8518-2b7f63cc26ae@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
 <DXQ8sulRSIa5sQJaZU9UM7NF8AHkRsViO6D9b0rI2Vg=.32fa69ad-94bf-4453-97e8-22a6802c8b08@github.com>
 <F2QI8fLrAJ2ZB6nPfxenoaxVTP6_i1tMt3-9OLiXh0U=.3df00047-29b5-42e2-8518-2b7f63cc26ae@github.com>
Message-ID: <FN2uTRQa7F53we_mGNLJEHkmvIv8JqsoPF_4D5ufzH8=.0ea526a4-1a6a-42e2-829c-12a9cfd95c05@github.com>

On Thu, 1 May 2025 19:19:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 408:
>> 
>>> 406:      * <p> This method works as if invoking it were equivalent to evaluating
>>> 407:      * the expression:
>>> 408:      * <blockquote>{@linkplain #readAllChars()}.lines().toList()</blockquote>
>> 
>> I think this is actually too specific, as it could imply the returned List is the exact implementation that is returned by Stream.toList(). It is in this implementation, but I could easily imagine another implementation that constructs the list a different way. It might be better to be descriptive here and say that the entire input is read and is split into lines (where "line" is defined as above) which are returned in an unmodifiable list. And then have "unmodifiable list" be a link to the Unmodifiable Lists section, something like "java/util/List.html#unmodifiable".
>
> The word 'equivalent' mitigates the exactness of the code to describe the expected result.

I think it's still ambiguous. There was a back-and-forth a while ago -- I think @bplb was involved -- where there was similar wording about something being "equivalent to" or "as if" foo() was called, and the person was insistent that this meant that foo() should actually be called (and it was a bug that foo() was not called).

A possible rewording that might tip the balance is to change "works as if" (which implies implementation) to "the result is as if" (which emphasizes the result and less how it was arrived at). But I'd still recommend avoiding using code as a specification, especially if the code involves a publicly overridable method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2072031354

From swen at openjdk.org  Fri May  2 19:09:48 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 2 May 2025 19:09:48 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v8]
In-Reply-To: <fHBCE8kw7jUn9gc4R0o8v0PQbsCYWTvxkNJpGji7744=.a77cb139-35b4-492f-83a2-bb5a28eac32d@github.com>
References: <d-bbTH1lsG4Ev7_sNutKMbLBTXXyQ75ZQTbNvgJkqBQ=.06f597ba-1313-4bb4-9947-880e73acd5bf@github.com>
 <fHBCE8kw7jUn9gc4R0o8v0PQbsCYWTvxkNJpGji7744=.a77cb139-35b4-492f-83a2-bb5a28eac32d@github.com>
Message-ID: <-ljVhLq1eqiX7jZaQ_k4IBTLAu1iDbrTLljF8_wdq2Y=.300f3c0d-58a1-40af-9e21-e31afa1ade12@github.com>

On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
>> 
>> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
>> 
>> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
>> 
>> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's review - update code comment in the test

src/java.base/share/classes/java/util/zip/ZipFile.java line 1240:

> 1238:                 entries[index] = hash;
> 1239:                 entries[index + 1] = next;
> 1240:                 entries[index + 2] = pos;

Suggestion:

                entries[index    ] = hash;
                entries[index + 1] = next;
                entries[index + 2] = pos;

Aligned code is more readable

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2072037453

From liach at openjdk.org  Fri May  2 19:19:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 19:19:55 GMT
Subject: RFR: 8355962: RISCV64 cross build fails after 8354996
Message-ID: <hJEbc5cnWRjumd2pszFuLBAWOODmKiMoTrwITbMPmPU=.518aa754-0919-49d8-9746-039bf476b9c8@github.com>

Roll back the HelloClasslist downcall generation that caused cross build failures for riscv64 and aarch64 from x86-64.

Testing: riscv64 cross build

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

Commit messages:
 - 8355962: RISCV64 cross build fails after 8354996

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

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

From archie.cobbs at gmail.com  Fri May  2 19:23:25 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 2 May 2025 14:23:25 -0500
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <FN2uTRQa7F53we_mGNLJEHkmvIv8JqsoPF_4D5ufzH8=.0ea526a4-1a6a-42e2-829c-12a9cfd95c05@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
 <DXQ8sulRSIa5sQJaZU9UM7NF8AHkRsViO6D9b0rI2Vg=.32fa69ad-94bf-4453-97e8-22a6802c8b08@github.com>
 <F2QI8fLrAJ2ZB6nPfxenoaxVTP6_i1tMt3-9OLiXh0U=.3df00047-29b5-42e2-8518-2b7f63cc26ae@github.com>
 <FN2uTRQa7F53we_mGNLJEHkmvIv8JqsoPF_4D5ufzH8=.0ea526a4-1a6a-42e2-829c-12a9cfd95c05@github.com>
Message-ID: <CANSoFxsFdRS-aAVvjWEVGUw+NsT4YNCo1OHNtGC_RafVnwSavw@mail.gmail.com>

On Fri, May 2, 2025 at 2:04?PM Stuart Marks <smarks at openjdk.org> wrote:

> There was a back-and-forth a while ago -- I think @bplb was involved --
> where there was similar wording about something being "equivalent to" or
> "as if" foo() was called, and the person was insistent that this meant that
> foo() should actually be called (and it was a bug that foo() was not
> called).
>

For those who enjoy rehashing the past, here it is :)
https://bugs.openjdk.org/browse/JDK-8307863

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250502/1c262e1b/attachment.htm>

From asemenyuk at openjdk.org  Fri May  2 19:31:54 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 2 May 2025 19:31:54 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
Message-ID: <f7W9-clt1wWEOZLlsrU_DwHmHIOw0WbSKzl1xUTM_z0=.f3de2a04-5462-4fe6-ba30-7a3fcb946a8f@github.com>

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
> - This change is for macOS only.
> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

It looks like jpackage sign bundles in a way that they can not be notarized.

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2847948330

From vromero at openjdk.org  Fri May  2 19:32:32 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 May 2025 19:32:32 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v2]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <frPmWVlOlA4zMR8-VM118Mi39bODtoyzr4tu4Oglv0o=.5f1a2a9c-e98d-4672-9a21-2a3f7cb8deed@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  updating test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/5e3acc92..1134ffee

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

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

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

From asemenyuk at openjdk.org  Fri May  2 19:34:59 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 2 May 2025 19:34:59 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <r0QOricU38-_MnFoJjakdbjkci6hpSlwbuyNRLOWCxo=.a604e360-bd01-4933-9258-891bf7ed1eee@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
 <r0QOricU38-_MnFoJjakdbjkci6hpSlwbuyNRLOWCxo=.a604e360-bd01-4933-9258-891bf7ed1eee@github.com>
Message-ID: <Y4B4LUlRs-AWppoIngR5ZRI2AfiH8PvImGaeUMdIAfc=.c0d8e33c-7ebf-417d-b1e9-f3121b48f19d@github.com>

On Mon, 28 Oct 2024 22:30:06 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
>> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
>> - This change is for macOS only.
>> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.
>
> Closing this PR. This issue will be fixed under new PR https://github.com/openjdk/jdk/pull/21741.

@sashamatveev can you comment?

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2847954657

From forax at openjdk.org  Fri May  2 19:40:49 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 2 May 2025 19:40:49 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
Message-ID: <5e91fwQ-fvxomq2pltkLuT0EeVaJPH_L4ibc4u6O91c=.03f7a833-0dd2-4427-ab88-b1b88daa4d2a@github.com>

On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter <bpb at openjdk.org> 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: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test

test/jdk/java/io/BufferedReader/ReadAll.java line 82:

> 80:     @AfterAll
> 81:     public static void cleanup() throws IOException {
> 82:         file.delete();

If the call to createTempFile() above fails with an exception, file will be null

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2072068586

From vromero at openjdk.org  Fri May  2 19:41:34 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 May 2025 19:41:34 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v3]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <LTnhc1b0-PaFRZdk_1zLQYG_HaGOQVUE9aP_dCigMQE=.6a31e7b5-180f-48ad-989c-ac7f6db8885f@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'master' into JDK-8354556
 - updating test
 - final adjustments
 - additional refactorings
 - removing unneeded changes
 - more refactorings
 - more refactorings and tests
 - refactoring
 - refactoring
 - covering more cases plus refactoring in order to simplify the code
 - ... and 13 more: https://git.openjdk.org/jdk/compare/60ba81d7...151908a2

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

Changes: https://git.openjdk.org/jdk/pull/24746/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=02
  Stats: 494 lines in 25 files changed: 468 ins; 6 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

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

From vromero at openjdk.org  Fri May  2 19:44:31 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 May 2025 19:44:31 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v4]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <QxFySn5mkqhFHBY2Px5kmxuMX2l1DNR6vgBaqSBbzH0=.d94d9b13-54af-41d3-a668-fc0c3795b99d@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  changes to test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/151908a2..60f1f53b

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

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

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

From erikj at openjdk.org  Fri May  2 19:54:44 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 2 May 2025 19:54:44 GMT
Subject: RFR: 8355962: RISCV64 cross build fails after 8354996
In-Reply-To: <hJEbc5cnWRjumd2pszFuLBAWOODmKiMoTrwITbMPmPU=.518aa754-0919-49d8-9746-039bf476b9c8@github.com>
References: <hJEbc5cnWRjumd2pszFuLBAWOODmKiMoTrwITbMPmPU=.518aa754-0919-49d8-9746-039bf476b9c8@github.com>
Message-ID: <reCbRglNtOgEbE2L5JMF4wDLokSMK9Bwkn4jIPU7CFE=.4fc55719-509c-4636-8977-a7ea1d4b6ba6@github.com>

On Fri, 2 May 2025 19:14:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> Roll back the HelloClasslist downcall generation that caused cross build failures for riscv64 and aarch64 from x86-64.
> 
> Testing: riscv64 cross build

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25013#pullrequestreview-2812795358

From bpb at openjdk.org  Fri May  2 20:39:45 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 May 2025 20:39:45 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v3]
In-Reply-To: <V_z1LM8NiXvm2IaCKIJHcr-WrAVCc7KVB7eYUjGSszU=.dd1c921c-a20b-471b-8e5f-be63360be0d8@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <V_z1LM8NiXvm2IaCKIJHcr-WrAVCc7KVB7eYUjGSszU=.dd1c921c-a20b-471b-8e5f-be63360be0d8@github.com>
Message-ID: <1grEUdKcCxBPboSWy5obCUJJrdyJVX7diRJEEOMQqsk=.cce7b09c-336f-445b-abbc-694d46392d04@github.com>

On Fri, 2 May 2025 18:19:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set

I ran all tests in `open/test/jdk` and `HashedPasswordFileTest` was the only failure which did not appear to be spurious (there were four apparently spurious failures in `java/awt/print`). `HashedPasswordFileTest` was modified in 0fef478 and now passes.

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

PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2848075890

From jlu at openjdk.org  Fri May  2 20:55:54 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 2 May 2025 20:55:54 GMT
Subject: RFR: 8356096: ISO 4217 Amendment 179 Update
Message-ID: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>

Please review this PR which implements ISO 4217 update 179.

The _Arab Accounting Dinar_ currency is added under an _agency_, (not _country_) entity. As a result it is not added as an entry in the country to currency mapping in `currencyData.properties`. It has a numeric code of 396, and minor units of 2 (so it is not added to any of the `minorX` entries in `currencyData.properties`).

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

Commit messages:
 - init

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

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

From rriggs at openjdk.org  Fri May  2 21:11:47 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 2 May 2025 21:11:47 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java
In-Reply-To: <ZkcLZZ8VyKHLib1iV60Rrl2j57MFPBJSeJoJO-hcuHs=.80f10646-a11d-4800-99f5-75c47e7a3c6a@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
 <sS3HZ2aZsOqrm__NxCUeKvdCgwgnYXEP-4LxP7oN0fA=.69034e9c-a0ef-4842-a739-f95124523a0f@github.com>
 <tvPY07xY8QPSk2Bop7Dm4U4wLLc2LdWAc1UCWm9oFL8=.7609fb9d-3362-45ac-a0a2-dd44b7570d41@github.com>
 <6CRYc09LAUqqqP9cJbNow9BkHS_bJcY1nTIpJJVxA5o=.4aea935a-8c8d-45b5-a74e-5a18d02dfd8d@github.com>
 <Dt3uWlr2qxiuWJrU5N4feOrIwpNEj28v9xpEaQJ974M=.2999cc9d-a782-4ac2-a92d-9fbaca7c0574@github.com>
 <ZkcLZZ8VyKHLib1iV60Rrl2j57MFPBJSeJoJO-hcuHs=.80f10646-a11d-4800-99f5-75c47e7a3c6a@github.com>
Message-ID: <sjRVRFRcog3II0sgTGsmxv-ggDHMq7FDQfgrIzW_dnc=.0826aebf-bcc2-4d38-9ed6-624e17f0a785@github.com>

On Fri, 2 May 2025 17:42:40 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> No, `echo.` is not an executable, this is a command of the Windows Command Processor.
>> 
>> See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo
>
> That sounds brittle. The "echo." usage is not specified, only shown as an example.
> Under what command parsing rule does it run exactly the "echo" builtin?

A bit more investigation and some trial and error.
It appears that with `echo.`, cmd.com is searching for a file named "echo" and when it does not find it it reverts to the builtin.  But it has already wasted time searching the %Path% for a non-existent file.
A couple comments searching the internet suggested using either "/" or ":". Both are not part of file paths and are parsed differently.
In my trial and error on Windows 10, I consistently get an error from `cmd /c echo.`, 
`'echo.' is not recognized as an internal or external command...`

I'd propose to use `echo/` instead, the `/` will terminate the parsing of the command name and won't be interpreted as part of a file name and as an empty command option will be ignored.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2072151928

From liach at openjdk.org  Fri May  2 21:34:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 21:34:46 GMT
Subject: RFR: 8355962: RISCV64 cross build fails after 8354996
In-Reply-To: <hJEbc5cnWRjumd2pszFuLBAWOODmKiMoTrwITbMPmPU=.518aa754-0919-49d8-9746-039bf476b9c8@github.com>
References: <hJEbc5cnWRjumd2pszFuLBAWOODmKiMoTrwITbMPmPU=.518aa754-0919-49d8-9746-039bf476b9c8@github.com>
Message-ID: <4Yq5q-QjlgK9ln9ICrwaQmH-_kwsbgz39_vi2eqP0pI=.85e4f24d-832f-4c90-af1f-28d90c805fa1@github.com>

On Fri, 2 May 2025 19:14:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> Roll back the HelloClasslist downcall generation that caused cross build failures for riscv64 and aarch64 from x86-64.
> 
> Testing: riscv64 cross build

If someone can verify this patch works - @caoman since you have tried to raise attention on this issue, can you test this patch for x86 to arm cross builds?

Delegating integration as this seems in need.

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

PR Comment: https://git.openjdk.org/jdk/pull/25013#issuecomment-2848154785

From duke at openjdk.org  Fri May  2 21:55:46 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Fri, 2 May 2025 21:55:46 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java
In-Reply-To: <sjRVRFRcog3II0sgTGsmxv-ggDHMq7FDQfgrIzW_dnc=.0826aebf-bcc2-4d38-9ed6-624e17f0a785@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
 <sS3HZ2aZsOqrm__NxCUeKvdCgwgnYXEP-4LxP7oN0fA=.69034e9c-a0ef-4842-a739-f95124523a0f@github.com>
 <tvPY07xY8QPSk2Bop7Dm4U4wLLc2LdWAc1UCWm9oFL8=.7609fb9d-3362-45ac-a0a2-dd44b7570d41@github.com>
 <6CRYc09LAUqqqP9cJbNow9BkHS_bJcY1nTIpJJVxA5o=.4aea935a-8c8d-45b5-a74e-5a18d02dfd8d@github.com>
 <Dt3uWlr2qxiuWJrU5N4feOrIwpNEj28v9xpEaQJ974M=.2999cc9d-a782-4ac2-a92d-9fbaca7c0574@github.com>
 <ZkcLZZ8VyKHLib1iV60Rrl2j57MFPBJSeJoJO-hcuHs=.80f10646-a11d-4800-99f5-75c47e7a3c6a@github.com>
 <sjRVRFRcog3II0sgTGsmxv-ggDHMq7FDQfgrIzW_dnc=.0826aebf-bcc2-4d38-9ed6-624e17f0a785@github.com>
Message-ID: <t5Tmi9sbohNhpPzCXy19bydokIKvtkKxZnuCbRtEDxk=.b831cdc4-42c0-4490-8e93-cb9236c4cf93@github.com>

On Fri, 2 May 2025 21:08:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> That sounds brittle. The "echo." usage is not specified, only shown as an example.
>> Under what command parsing rule does it run exactly the "echo" builtin?
>
> A bit more investigation and some trial and error.
> It appears that with `echo.`, cmd.com is searching for a file named "echo" and when it does not find it it reverts to the builtin.  But it has already wasted time searching the %Path% for a non-existent file.
> A couple comments searching the internet suggested using either "/" or ":". Both are not part of file paths and are parsed differently.
> In my trial and error on Windows 10, I consistently get an error from `cmd /c echo.`, 
> `'echo.' is not recognized as an internal or external command...`
> 
> I'd propose to use `echo/` instead, the `/` will terminate the parsing of the command name and won't be interpreted as part of a file name and as an empty command option will be ignored.

On the other hand, the test can be modified as follows: on Windows, pass an empty string as an argument to `echo` and expect two double quotes followed by a newline character as the valid result:


String[] cmdp = Windows.is() ? new String[]{"cmd.exe", "/c", "echo", ""} : new String[]{"echo"};
String[] envp = {"Hello", "World"}; // Yuck!
Process p = Runtime.getRuntime().exec(cmdp, envp);
String expected = Windows.is() ? """\n" : "\n";
equal(commandOutput(p), expected);


What do you prefer: the "echo/" variant or the "double quotes" variant?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2072184014

From rriggs at openjdk.org  Fri May  2 22:06:46 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 2 May 2025 22:06:46 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java
In-Reply-To: <t5Tmi9sbohNhpPzCXy19bydokIKvtkKxZnuCbRtEDxk=.b831cdc4-42c0-4490-8e93-cb9236c4cf93@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
 <sS3HZ2aZsOqrm__NxCUeKvdCgwgnYXEP-4LxP7oN0fA=.69034e9c-a0ef-4842-a739-f95124523a0f@github.com>
 <tvPY07xY8QPSk2Bop7Dm4U4wLLc2LdWAc1UCWm9oFL8=.7609fb9d-3362-45ac-a0a2-dd44b7570d41@github.com>
 <6CRYc09LAUqqqP9cJbNow9BkHS_bJcY1nTIpJJVxA5o=.4aea935a-8c8d-45b5-a74e-5a18d02dfd8d@github.com>
 <Dt3uWlr2qxiuWJrU5N4feOrIwpNEj28v9xpEaQJ974M=.2999cc9d-a782-4ac2-a92d-9fbaca7c0574@github.com>
 <ZkcLZZ8VyKHLib1iV60Rrl2j57MFPBJSeJoJO-hcuHs=.80f10646-a11d-4800-99f5-75c47e7a3c6a@github.com>
 <sjRVRFRcog3II0sgTGsmxv-ggDHMq7FDQfgrIzW_dnc=.0826aebf-bcc2-4d38-9ed6-624e17f0a785@github.com>
 <t5Tmi9sbohNhpPzCXy19bydokIKvtkKxZnuCbRtEDxk=.b831cdc4-42c0-4490-8e93-cb9236c4cf93@github.com>
Message-ID: <YuOi5qXpwwbzAHn-Jn1NwLW4V3E3asLX98Nt9lZAYyA=.645fc352-0de3-4e02-ba34-812f90e66bb8@github.com>

On Fri, 2 May 2025 21:52:46 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> A bit more investigation and some trial and error.
>> It appears that with `echo.`, cmd.com is searching for a file named "echo" and when it does not find it it reverts to the builtin.  But it has already wasted time searching the %Path% for a non-existent file.
>> A couple comments searching the internet suggested using either "/" or ":". Both are not part of file paths and are parsed differently.
>> In my trial and error on Windows 10, I consistently get an error from `cmd /c echo.`, 
>> `'echo.' is not recognized as an internal or external command...`
>> 
>> I'd propose to use `echo/` instead, the `/` will terminate the parsing of the command name and won't be interpreted as part of a file name and as an empty command option will be ignored.
>
> On the other hand, the test can be modified as follows: on Windows, pass an empty string as an argument to `echo` and expect two double quotes followed by a newline character as the valid result:
> 
> 
> String[] cmdp = Windows.is() ? new String[]{"cmd.exe", "/c", "echo", ""} : new String[]{"echo"};
> String[] envp = {"Hello", "World"}; // Yuck!
> Process p = Runtime.getRuntime().exec(cmdp, envp);
> String expected = Windows.is() ? """\n" : "\n";
> equal(commandOutput(p), expected);
> 
> 
> What do you prefer: the "echo/" variant or the "double quotes" variant?

I'd use the 'echo/' version to keep the test simpler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2072193051

From almatvee at openjdk.org  Fri May  2 22:14:53 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 2 May 2025 22:14:53 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
Message-ID: <3Jw2RM0K-cylehvQaV1iD5U9Aw5B9UKtLFIeqyfKhA8=.93b6bb9a-83fd-48ae-9c2a-aca7b6cc2fbe@github.com>

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
> - This change is for macOS only.
> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

Not sure what is going on. I tried generating app-image with signing modifying it and then generating DMG with --mac-sign and application image is signed correctly. I did not tried to notarize it.

When DMG is mounted what is output of `codesign --display -vvvv /Volumes/JabRef-6.0_arm64.dmg/JabRef.app`?

Also from provided logs:

2025-05-02T17:19:25.6911920Z     /usr/bin/codesign -s Developer ID Application: JabRef e.V. (6792V39SK3) -vvvv --timestamp --options runtime --prefix org.*** --entitlements buildres/mac/***.entitlements --force build/distribution/JabRef.app/Contents/runtime

`buildres/mac/***.entitlements` -> "***" does not look right.

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848202529

From duke at openjdk.org  Fri May  2 22:31:00 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Fri, 2 May 2025 22:31:00 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v2]
In-Reply-To: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
Message-ID: <kP52md4jtegpdRjEhoCH39icyT6550HpKOiZb47lAlM=.cabb7671-3343-4dfd-aa0f-9143a2714c0e@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm.
> 
> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b15](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B15) as the baseline version.
> 
> For performance data collected with the built in **cbrt** micro-benchmark, see the table below. Each result is the mean of 8 individual runs. Overall, the intrinsic provides a performance uplift of 41%.
> 
> | Benchmark        | Throughput with baseline (op/s) | Throughput with intrinsic (op/s) | Speedup |
> | :----------------: | :----------------------------------: | :----------------------------------: | :---------: |
> | MathBench.cbrt | 148242                                        | 209122                                        | 1.41x       |
> 
> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.

Mohamed Issa 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 'openjdk:master' into user/missa-prime/cbrt
 - Change coeff_table alignment from 4 bytes to 16 bytes to conform with movapd instruction
 - Merge branch 'master' into user/missa-prime/cbrt
 - x86_64 intrinsic for cbrt using libm

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

Changes: https://git.openjdk.org/jdk/pull/24470/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24470&range=01
  Stats: 466 lines in 26 files changed: 453 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/24470.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24470/head:pull/24470

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

From asemenyuk at openjdk.org  Fri May  2 22:34:54 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 2 May 2025 22:34:54 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <3Jw2RM0K-cylehvQaV1iD5U9Aw5B9UKtLFIeqyfKhA8=.93b6bb9a-83fd-48ae-9c2a-aca7b6cc2fbe@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
 <3Jw2RM0K-cylehvQaV1iD5U9Aw5B9UKtLFIeqyfKhA8=.93b6bb9a-83fd-48ae-9c2a-aca7b6cc2fbe@github.com>
Message-ID: <Mb6xeZFHOA2-ZMbQ7EJcEUuU3X2nvMhl8VY1L8_K_mk=.c9708d84-5d4e-45d8-b940-9d632882f2be@github.com>

On Fri, 2 May 2025 22:12:18 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> "***" does not look right.

This is just a mask to hide the real value.

> I did not tried to notarize it.

Well, the problem is with notarization. Signing in jpackage passed. But looks like it produces a bundle that can not be notarized.

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848222502

From manc at openjdk.org  Fri May  2 22:36:49 2025
From: manc at openjdk.org (Man Cao)
Date: Fri, 2 May 2025 22:36:49 GMT
Subject: RFR: 8355962: RISCV64 cross build fails after 8354996
In-Reply-To: <hJEbc5cnWRjumd2pszFuLBAWOODmKiMoTrwITbMPmPU=.518aa754-0919-49d8-9746-039bf476b9c8@github.com>
References: <hJEbc5cnWRjumd2pszFuLBAWOODmKiMoTrwITbMPmPU=.518aa754-0919-49d8-9746-039bf476b9c8@github.com>
Message-ID: <tTumAXZCvyo2VswwsBAa7oxbm_9kJZhD4k_rlIZG1iA=.eba4b2a9-807a-40bc-960a-aa313085a19e@github.com>

On Fri, 2 May 2025 19:14:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> Roll back the HelloClasslist downcall generation that caused cross build failures for riscv64 and aarch64 from x86-64.
> 
> Testing: riscv64 cross build

Marked as reviewed by manc (Committer).

Yes, I tested that this change fixes the failure for cross-compiling aarch64.

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

PR Review: https://git.openjdk.org/jdk/pull/25013#pullrequestreview-2813005097
PR Comment: https://git.openjdk.org/jdk/pull/25013#issuecomment-2848222583

From liach at openjdk.org  Fri May  2 22:36:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 22:36:50 GMT
Subject: Integrated: 8355962: RISCV64 cross build fails after 8354996
In-Reply-To: <hJEbc5cnWRjumd2pszFuLBAWOODmKiMoTrwITbMPmPU=.518aa754-0919-49d8-9746-039bf476b9c8@github.com>
References: <hJEbc5cnWRjumd2pszFuLBAWOODmKiMoTrwITbMPmPU=.518aa754-0919-49d8-9746-039bf476b9c8@github.com>
Message-ID: <IMdb5kE0bFnfhHH2UDmwpiFFApbMZa169xWESBHEfGU=.2479d7b0-89b0-42cc-8356-c6ad7ed5b060@github.com>

On Fri, 2 May 2025 19:14:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> Roll back the HelloClasslist downcall generation that caused cross build failures for riscv64 and aarch64 from x86-64.
> 
> Testing: riscv64 cross build

This pull request has now been integrated.

Changeset: 4d2d1298
Author:    Chen Liang <liach at openjdk.org>
Committer: Man Cao <manc at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4d2d12987f8c1be64719a7d01276a789af245ee2
Stats:     7 lines in 2 files changed: 0 ins; 6 del; 1 mod

8355962: RISCV64 cross build fails after 8354996

Reviewed-by: erikj, manc

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

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

From mik3hall at gmail.com  Fri May  2 22:52:00 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 2 May 2025 17:52:00 -0500
Subject: RFR: 8342576: [macos] AppContentTest still fails after
 JDK-8341443 for same reason on older macOS versions
In-Reply-To: <Mb6xeZFHOA2-ZMbQ7EJcEUuU3X2nvMhl8VY1L8_K_mk=.c9708d84-5d4e-45d8-b940-9d632882f2be@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
 <3Jw2RM0K-cylehvQaV1iD5U9Aw5B9UKtLFIeqyfKhA8=.93b6bb9a-83fd-48ae-9c2a-aca7b6cc2fbe@github.com>
 <Mb6xeZFHOA2-ZMbQ7EJcEUuU3X2nvMhl8VY1L8_K_mk=.c9708d84-5d4e-45d8-b940-9d632882f2be@github.com>
Message-ID: <977460AD-488D-4455-9B0E-2ABBD2E2579A@gmail.com>



> On May 2, 2025, at 5:34?PM, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:
> 
> On Fri, 2 May 2025 22:12:18 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:
> 
>> "***" does not look right.
> 
> This is just a mask to hide the real value.
> 
>> I did not tried to notarize it.
> 
> Well, the problem is with notarization. Signing in jpackage passed. But looks like it produces a bundle that can not be notarized.
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848222502

I had successfully notarized a jpackage app sometime back. As I remember it was a rather involved process where you had to be online to an Apple server?
I still have it in the build for one application but offline it does always fail.

This might be from when I did that
https://developer.apple.com/forums/thread/124614
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250502/3dfd4081/attachment.htm>

From almatvee at openjdk.org  Fri May  2 22:56:52 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 2 May 2025 22:56:52 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
Message-ID: <fsgwVkhoZDK5-6EGrmKd3ghHIKqjvtLO2G0JRn8bSrI=.2ef29ba2-1103-40b1-8e96-d12279074a2f@github.com>

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
> - This change is for macOS only.
> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

It might be possible that "codesign --display -vvvv" does not check signature well enough as notarization. If I am reading issue correctly signed app-image is being generated, then it will be post-process and then it is used to generate DMG. See https://github.com/JabRef/jabref/pull/13032. In this case we will package app-image as is since we will assume it is signed. See [JDK-8293462](https://bugs.openjdk.org/browse/JDK-8293462). My suggestion is to generate unsigned image if post-processing is required or sign application image separately after it was modified. See [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850).

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848240659

From kbarrett at openjdk.org  Sat May  3 00:38:47 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 3 May 2025 00:38:47 GMT
Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed
 with "RuntimeException: MyObject is not found in test output" [v9]
In-Reply-To: <lETJgNjO8kCy1DtUVEvh8dm-Tupl8r35SdGo8qgg-sY=.777fd32c-7ae4-4bff-8006-8394606b1d78@github.com>
References: <Jcra20HpK4hJAr6O1VySmMukJHFGYEieEpvDVrlbxuI=.03ee416c-3568-4a66-be60-f6c17fed2188@github.com>
 <lETJgNjO8kCy1DtUVEvh8dm-Tupl8r35SdGo8qgg-sY=.777fd32c-7ae4-4bff-8006-8394606b1d78@github.com>
Message-ID: <QWRVkqE5InLXOIV2aN_iujhFQBSjldCJcglPMfmRsCE=.03d2fa42-cb11-46c3-ad57-94f3ad1c54ef@github.com>

On Thu, 1 May 2025 21:47:01 GMT, Brent Christian <bchristi at openjdk.org> 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:
> 
>   remove unneeded 'trappedCount'

test/jdk/java/lang/ref/FinalizerHistogramTest.java line 78:

> 76:                 refProResult = wb.waitForReferenceProcessing();
> 77:                 System.out.println("waitForReferenceProcessing returned: " + refProResult);
> 78:             } while (refProResult);

Why the spammy output?  Why not just

while (wb.waitForReferenceProcessing()) {}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2072259958

From smarks at openjdk.org  Sat May  3 01:02:19 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 3 May 2025 01:02:19 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
Message-ID: <Yc2MCOL0H_V7ERnSicKO-seKFkG2VnOTAZQ4wIkXVfE=.23e64425-6677-470b-b016-80caef1a5c39@github.com>

On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter <bpb at openjdk.org> 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: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test

Archie Cobbs wrote:
> For those who enjoy rehashing the past, here it is :) [JDK-8307863](https://bugs.openjdk.org/browse/JDK-8307863)

Thanks for the pointer. I don't want to rehash the past, but looking at the previous discussion was informative. Holy cow that was two years ago already; I thought it was just a couple months ago.

In any case, the effect I'm trying for here is to have the specification be able to use code or pseudo-code, which is sometimes the most intuitive way to specify something. Sometimes this _description_ involves another method (or methods) on the same class, but it doesn't want to _specify_ that the other method is actually called. The reason this is significant is that, if the other method is overridable by a subclass, the self-call is observable by the subclass and the subclass implementation can affect the behavior of this method.

More concretely, suppose we have a method specification for the `foo()` method that is like this. (Intentionally vague wording).

> This method behaves like `bar().length()`.

... where the `bar()` method on this class is overridable by a subclass. A reasonable person might think, ok, if I override `bar()` and change its behavior, then `foo()` will also be affected.

Two questions are relevant here:

1. Do we want self-calls, or do we want to avoid self-calls?
2. What specification wording should be used to require self-calls or lack of self-calls?

Note that I've omitted another option for 2 which is to leave it unspecified. Astute readers will note that leaving it unspecified eventually leads to the [fragile base class problem](https://en.wikipedia.org/wiki/Fragile_base_class). Java has suffered from this a fair amount over the years, and the way to avoid it is to be explicit in the specification about what self-calls are or are not made. That's a primary role of the `@implSpec` javadoc tag.

(Sorry for lecturing here, but I want to make sure all readers are on the same page.)

Here are my proposed answers to the questions.

1. In this case `Reader` is an abstract class, and therefore it relies on a subclass to provide _some_ implementation; so some self-calls are required. I observe that the only abstract methods on `Reader` are `close()` and `read(char[], int, int)`, and further that all the concrete methods are implemented in terms of this three-arg `read` method. Based on this, the new methods here should be implemented in terms of that three-arg `read` method, and also they should be specified to do so in an `@implSpec` clause.

(In principle, the other concrete methods of `Reader` should also have `@implSpec` clauses that say they use the three-arg `read` method, but that can probably be handled separately.)

2. Since there will be specific self-calls, there needs to be an `@implSpec` that specifies that. I'd recommend something like this for `readAllChars()`:


    @implSpec
    The implementation in this class reads all the characters from the input by
    repeatedly calling the read(char[], int, int) method with a positive len argument
    until a call returns -1.


There is still the matter of the wording to use for the non-self-call case, although that isn't operative here. Continuing the above example, I'd suggest something like "the result is as if `bar().length()` had been called." The use of the subjunctive mood hints reasonably strongly that `bar()` isn't _really_ called, though it is somewhat subtle. The JDK has used similar wording, sometimes "the effect is as if" but even "effect" is somewhat ambiguous, which is why I'm suggesting "result" here.

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

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2848332415

From liach at openjdk.org  Sat May  3 01:08:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 3 May 2025 01:08:17 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v2]
In-Reply-To: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@github.com>

> Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Don't need to update latestSupported later
   
 - Merge branch 'pr/25015' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Add advanced testing for different latestSupported
   
 - 8355536: Create version constants to model preview language and vm features

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

Changes: https://git.openjdk.org/jdk/pull/25017/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=01
  Stats: 1266 lines in 6 files changed: 1124 ins; 83 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/25017.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25017/head:pull/25017

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

From almatvee at openjdk.org  Sat May  3 03:37:46 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 3 May 2025 03:37:46 GMT
Subject: RFR: 8352480: Don't follow symlinks in additional content for app
 images
In-Reply-To: <SyYlXefnwweD6M6Lue0qAIZPm4jbNAEwOe2sVwb3Ihw=.284bb456-22a3-4e69-9957-7ab1e165814c@github.com>
References: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
 <SyYlXefnwweD6M6Lue0qAIZPm4jbNAEwOe2sVwb3Ihw=.284bb456-22a3-4e69-9957-7ab1e165814c@github.com>
Message-ID: <9lyJyHh_vUdTzUYNO4KVO-UHlEacl9B_8F76j8oCvMg=.4b7e9a1c-6bd3-49a6-915a-f8a19b510251@github.com>

On Thu, 1 May 2025 21:23:38 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> - Symbolic links will not be followed for `--app-content` on all platforms.
>> - Added test to cover this case.
>> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links.
>
> test/jdk/tools/jpackage/share/AppContentTest.java line 57:
> 
>> 55:  */
>> 56: public class AppContentTest {
>> 57: 
> 
> Nitpick: do you think it might be worth it to add a bug id to the `@test`?

No. I do not see a need. This is a generic test and not something specific to particular JBS issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2072305435

From swen at openjdk.org  Sat May  3 05:03:36 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 3 May 2025 05:03:36 GMT
Subject: RFR: 8349176: Speed up Integer/Long.toString via
 StringConcatHelper::newArray [v4]
In-Reply-To: <u9INrX9ZnlI8Hs0gC1hnE-oYiHLrnL93Q5hF1yzmJgM=.8b5bb878-27f0-4c21-a1bb-82ce65634b81@github.com>
References: <u9INrX9ZnlI8Hs0gC1hnE-oYiHLrnL93Q5hF1yzmJgM=.8b5bb878-27f0-4c21-a1bb-82ce65634b81@github.com>
Message-ID: <tI9blpanPahfQWwugS4LEaIOaKLdTKNoPNByt2CkLjM=.6c2666f6-4a84-4148-83b8-f4a8692a07a5@github.com>

> 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 Unsafe::allocateUninitializedArray

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23353/files
  - new: https://git.openjdk.org/jdk/pull/23353/files/d6942080..549ff0f8

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

  Stats: 6 lines in 2 files changed: 2 ins; 0 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 duke at openjdk.org  Sat May  3 07:27:49 2025
From: duke at openjdk.org (Markus KARG)
Date: Sat, 3 May 2025 07:27:49 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
Message-ID: <6lD4tGZLf54gX50KgP-YGFAGTQhh0A7kh07p-XdOX-Y=.c30197c4-2ffa-4a7a-b5cb-98901427eaa7@github.com>

On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter <bpb at openjdk.org> 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: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test

src/java.base/share/classes/java/io/Reader.java line 213:

> 211:             public String readAllChars() throws IOException {
> 212:                 ensureOpen();
> 213:                 return cs.toString().substring(next);

Your change implies creating a full-length string *first* (including cyoping and compression), just to strip it down to a smaller one *later*. It would be more efficient to *first* strip it down, and compression into a `String` *afterwards*. Imagine a huge `cs` with `next` being near to `length()`, and you see the difference in efficiency! ? 

`cs.subSequence(next, cs.length() - next).toString()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2072340583

From duke at openjdk.org  Sat May  3 08:34:53 2025
From: duke at openjdk.org (Christoph)
Date: Sat, 3 May 2025 08:34:53 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
Message-ID: <n9D80jZ-y3nkXn5YsKaVEe_4v-0DZEi0Sntlvuyrlt0=.49b906f1-bcb1-49d9-9ad7-c240587b20c9@github.com>

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
> - This change is for macOS only.
> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

I managed to get it working now. 
1. Build a signed app image with --mac-sign
2. Add the addtional content 
3. re-sign the content manually with 

          # Sign the final artifact
          codesign --force --deep --sign "Developer ID Application: JabRef e.V. (6792V39SK3)" \
            --entitlements buildres/mac/jabref.entitlements \
            --options runtime --timestamp build/distribution/JabRef.app

4. build a signed dmg/pkg
5. Notarization works now :)

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848520498

From duke at openjdk.org  Sat May  3 09:17:49 2025
From: duke at openjdk.org (Markus KARG)
Date: Sat, 3 May 2025 09:17:49 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
Message-ID: <-wkmG1NP_OsBAU-a4HAJOLRM9KK8ccUxH02rlogXI8o=.3f30e760-fbc2-47c3-9e96-2de14781152c@github.com>

On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter <bpb at openjdk.org> 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: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test

src/java.base/share/classes/java/io/Reader.java line 211:

> 209:             }
> 210: 
> 211:             public String readAllChars() throws IOException {

The addition of this method effectively resolves [JDK-8309726](https://bugs.openjdk.org/browse/JDK-8309726), so I hope you don't mind me setting you as the assignee there, just to ensure we don't forget to close JDK-8309726 in turn once JDK-8354724 is closed? ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2072357390

From duke at openjdk.org  Sat May  3 09:32:51 2025
From: duke at openjdk.org (Markus KARG)
Date: Sat, 3 May 2025 09:32:51 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <6lD4tGZLf54gX50KgP-YGFAGTQhh0A7kh07p-XdOX-Y=.c30197c4-2ffa-4a7a-b5cb-98901427eaa7@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
 <6lD4tGZLf54gX50KgP-YGFAGTQhh0A7kh07p-XdOX-Y=.c30197c4-2ffa-4a7a-b5cb-98901427eaa7@github.com>
Message-ID: <_gsm1O3oGkFRt64kDD7WKL2HG69RpOhvbwRTjhTMBWI=.0c7c0bfb-1783-4162-be25-90e3ebe6dc56@github.com>

On Sat, 3 May 2025 07:25:09 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test
>
> src/java.base/share/classes/java/io/Reader.java line 213:
> 
>> 211:             public String readAllChars() throws IOException {
>> 212:                 ensureOpen();
>> 213:                 return cs.toString().substring(next);
> 
> Your change implies creating a full-length string *first* (including cyoping and compression), just to strip it down to a smaller one *later*. It would be more efficient to *first* strip it down, and compression into a `String` *afterwards*. Imagine a huge `cs` with `next` being near to `length()`, and you see the difference in efficiency! ? 
> 
> `cs.subSequence(next, cs.length() - next).toString()`

Oh, and we should set `next` afterwards, so the `Reader` knows that the end of the sequence is reached:


public String readAllChars() throws IOException {
    ensureOpen();
    var remainder = cs.subSequence(next, cs.length() - next);
    next = length();
    return remainder.toString();
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2072359744

From duke at openjdk.org  Sat May  3 09:37:48 2025
From: duke at openjdk.org (Markus KARG)
Date: Sat, 3 May 2025 09:37:48 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
Message-ID: <bvglmgD10RGrTwhZUSZlpwOWnHef4W7xpFE-5Pm608E=.8b40cbf8-343a-426f-8a3b-18a6b86d5036@github.com>

On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter <bpb at openjdk.org> 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: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test

src/java.base/share/classes/java/io/Reader.java line 211:

> 209:             }
> 210: 
> 211:             public String readAllChars() throws IOException {

Now that the method got renamed from `readString()` to `readAllChars()` I'd like to suggest that the return type should not be `String` anymore but `CharSequence`. This would open potential for more efficient implementations. For example, we can omit the final `.toString()` after `.subSequence()`, effectively preventing the *double* copy implied (the first copy already was created by `subSequence()`). *Iff* a caller essentially needs a `String` (for whatever reason), he can add a `.toString()` *in the calling code* easily. But unless that is the case, we should not *enforce* `String` for efficiency reasons.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2072360280

From duke at openjdk.org  Sat May  3 11:46:03 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Sat, 3 May 2025 11:46:03 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java [v2]
In-Reply-To: <YuOi5qXpwwbzAHn-Jn1NwLW4V3E3asLX98Nt9lZAYyA=.645fc352-0de3-4e02-ba34-812f90e66bb8@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
 <sS3HZ2aZsOqrm__NxCUeKvdCgwgnYXEP-4LxP7oN0fA=.69034e9c-a0ef-4842-a739-f95124523a0f@github.com>
 <tvPY07xY8QPSk2Bop7Dm4U4wLLc2LdWAc1UCWm9oFL8=.7609fb9d-3362-45ac-a0a2-dd44b7570d41@github.com>
 <6CRYc09LAUqqqP9cJbNow9BkHS_bJcY1nTIpJJVxA5o=.4aea935a-8c8d-45b5-a74e-5a18d02dfd8d@github.com>
 <Dt3uWlr2qxiuWJrU5N4feOrIwpNEj28v9xpEaQJ974M=.2999cc9d-a782-4ac2-a92d-9fbaca7c0574@github.com>
 <ZkcLZZ8VyKHLib1iV60Rrl2j57MFPBJSeJoJO-hcuHs=.80f10646-a11d-4800-99f5-75c47e7a3c6a@github.com>
 <sjRVRFRcog3II0sgTGsmxv-ggDHMq7FDQfgrIzW_dnc=.0826aebf-bcc2-4d38-9ed6-624e17f0a785@github.com>
 <t5Tmi9sbohNhpPzCXy19bydokIKvtkKxZnuCbRtEDxk=.b831cdc4-42c0-4490-8e93-cb9236c4cf93@github.com>
 <YuOi5qXpwwbzAHn-Jn1NwLW4V3E3asLX98Nt9lZAYyA=.645fc352-0de3-4e02-ba34-812f90e66bb8@github.com>
Message-ID: <Ojg1bCOdeeryjdbq7K_TJIJywNfIkwhpF8b_oBHLjTo=.f1db3d7d-d7e0-491d-81b3-d743da109a98@github.com>

On Fri, 2 May 2025 22:04:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> On the other hand, the test can be modified as follows: on Windows, pass an empty string as an argument to `echo` and expect two double quotes followed by a newline character as the valid result:
>> 
>> 
>> String[] cmdp = Windows.is() ? new String[]{"cmd.exe", "/c", "echo", ""} : new String[]{"echo"};
>> String[] envp = {"Hello", "World"}; // Yuck!
>> Process p = Runtime.getRuntime().exec(cmdp, envp);
>> String expected = Windows.is() ? """\n" : "\n";
>> equal(commandOutput(p), expected);
>> 
>> 
>> What do you prefer: the "echo/" variant or the "double quotes" variant?
>
> I'd use the 'echo/' version to keep the test simpler.

done: 61ab85f2cff6d35ba53f7538dcbca95e46d541cd

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2072379429

From duke at openjdk.org  Sat May  3 11:46:03 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Sat, 3 May 2025 11:46:03 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java [v2]
In-Reply-To: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
Message-ID: <2UGWZcTuz7Hn6uuu9VgI7m0GofAXr8lSK-oi3h0hb8Q=.48543198-fc6f-4483-82d5-28dedfb7cd08@github.com>

> 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
> 
> 
> If we try to run `echo` as a process in Windows, for example from IntelliJ IDEA, we get the error above, because Windows does not have such an executable, but instead this is a command of the Command Processor (CMD).
> 
> The `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line.
> 
> See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo
> 
> To ensure that the `echo.` command is supported in Cygwin, we need to invoke it via `cmd /c`, because Cygwin has its own executable `echo`.
> 
> ## cmd.exe /c set
>  The following test fails in a Windows environment under specific conditi...

Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:

  8353489: replace `echo.` with `echo/`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23933/files
  - new: https://git.openjdk.org/jdk/pull/23933/files/17109340..61ab85f2

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 eirbjo at openjdk.org  Sat May  3 12:22:45 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 3 May 2025 12:22:45 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java [v2]
In-Reply-To: <2UGWZcTuz7Hn6uuu9VgI7m0GofAXr8lSK-oi3h0hb8Q=.48543198-fc6f-4483-82d5-28dedfb7cd08@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
 <2UGWZcTuz7Hn6uuu9VgI7m0GofAXr8lSK-oi3h0hb8Q=.48543198-fc6f-4483-82d5-28dedfb7cd08@github.com>
Message-ID: <kwUAYYMDtXCrrES2Pue5o2wD6S41vVdBM4NXjLLhvzo=.bf347ddc-76cf-416a-8b7c-5686b59ae000@github.com>

On Sat, 3 May 2025 11:46:03 GMT, Oleksii Sylichenko <duke at openjdk.org> 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
>> 
>> 
>> If we try to run `echo` as a process in Windows, for example from IntelliJ IDEA, we get the error above, because Windows does not have such an executable, but instead this is a command of the Command Processor (CMD).
>> 
>> The `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line. Was implemented using the analogous `echo/` command to avoid compatibility issues.
>> 
>> See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo
>> 
>> To ensure that the `echo/` command is supported in Cygwin, we n...
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8353489: replace `echo.` with `echo/`

test/jdk/java/lang/ProcessBuilder/Basic.java line 1843:

> 1841:         //----------------------------------------------------------------
> 1842:         try {
> 1843:             String[] cmdp = Windows.is() ? new String[]{"cmd", "/c", "echo/"} : new String[]{"echo"};

A future maintainer without intimate familiarity with Windows commands and syntax would probably appreciate a short comment explaining the command chosen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2072384373

From duke at openjdk.org  Sat May  3 12:46:46 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Sat, 3 May 2025 12:46:46 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java [v2]
In-Reply-To: <kwUAYYMDtXCrrES2Pue5o2wD6S41vVdBM4NXjLLhvzo=.bf347ddc-76cf-416a-8b7c-5686b59ae000@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
 <2UGWZcTuz7Hn6uuu9VgI7m0GofAXr8lSK-oi3h0hb8Q=.48543198-fc6f-4483-82d5-28dedfb7cd08@github.com>
 <kwUAYYMDtXCrrES2Pue5o2wD6S41vVdBM4NXjLLhvzo=.bf347ddc-76cf-416a-8b7c-5686b59ae000@github.com>
Message-ID: <w1Pind55pdwrtfaZdM1wKMQyM3MiDSmNRmBzeFkWmIA=.3f6075a8-e438-4ee1-b767-255e3c3cb4c9@github.com>

On Sat, 3 May 2025 12:19:54 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8353489: replace `echo.` with `echo/`
>
> test/jdk/java/lang/ProcessBuilder/Basic.java line 1843:
> 
>> 1841:         //----------------------------------------------------------------
>> 1842:         try {
>> 1843:             String[] cmdp = Windows.is() ? new String[]{"cmd", "/c", "echo/"} : new String[]{"echo"};
> 
> A future maintainer without intimate familiarity with Windows commands and syntax would probably appreciate a short comment explaining the command chosen.

Would a comment with the following text be sufficient:

In Windows CMD (`cmd.exe`), `echo/` outputs a newline (i.e., an empty line).
Wrapping it with `cmd.exe /c` ensures compatibility in both native Windows and Cygwin environments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2072388153

From eirbjo at openjdk.org  Sat May  3 12:49:44 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 3 May 2025 12:49:44 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java [v2]
In-Reply-To: <w1Pind55pdwrtfaZdM1wKMQyM3MiDSmNRmBzeFkWmIA=.3f6075a8-e438-4ee1-b767-255e3c3cb4c9@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
 <2UGWZcTuz7Hn6uuu9VgI7m0GofAXr8lSK-oi3h0hb8Q=.48543198-fc6f-4483-82d5-28dedfb7cd08@github.com>
 <kwUAYYMDtXCrrES2Pue5o2wD6S41vVdBM4NXjLLhvzo=.bf347ddc-76cf-416a-8b7c-5686b59ae000@github.com>
 <w1Pind55pdwrtfaZdM1wKMQyM3MiDSmNRmBzeFkWmIA=.3f6075a8-e438-4ee1-b767-255e3c3cb4c9@github.com>
Message-ID: <05a4twZcz4u4KMieiir8xUxI60Q3zzysPvoZW1uk_H0=.622fa46b-84ff-41aa-b8d6-1b76898801ce@github.com>

On Sat, 3 May 2025 12:44:08 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> test/jdk/java/lang/ProcessBuilder/Basic.java line 1843:
>> 
>>> 1841:         //----------------------------------------------------------------
>>> 1842:         try {
>>> 1843:             String[] cmdp = Windows.is() ? new String[]{"cmd", "/c", "echo/"} : new String[]{"echo"};
>> 
>> A future maintainer without intimate familiarity with Windows commands and syntax would probably appreciate a short comment explaining the command chosen.
>
> Would a comment with the following text be sufficient:
> 
> In Windows CMD (`cmd.exe`), `echo/` outputs a newline (i.e., an empty line).
> Wrapping it with `cmd.exe /c` ensures compatibility in both native Windows and Cygwin environments.

Thanks, sounds fine to me! (Although I?m not an expert in the field, which is also why I thought a comment would be a nice addition here)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2072388535

From duke at openjdk.org  Sat May  3 13:02:34 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Sat, 3 May 2025 13:02:34 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java [v3]
In-Reply-To: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
Message-ID: <uV1w-VU-IkHDd7JQbtj8biW9-aQyUjZ24AJM8mnZV4w=.894c0b38-42b7-4eaa-b64d-7d06bc049d7c@github.com>

> 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
> 
> 
> If we try to run `echo` as a process in Windows, for example from IntelliJ IDEA, we get the error above, because Windows does not have such an executable, but instead this is a command of the Command Processor (CMD).
> 
> The `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line. Was implemented using the analogous `echo/` command to avoid compatibility issues.
> 
> See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo
> 
> To ensure that the `echo/` command is supported in Cygwin, we need to invoke it via `cmd /c`, because Cygwin has its own executable "echo".
> 
> ## cmd.e...

Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:

  8353489: add comment about `echo/`; `cmd` -> `cmd.exe`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23933/files
  - new: https://git.openjdk.org/jdk/pull/23933/files/61ab85f2..90752f18

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

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 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 duke at openjdk.org  Sat May  3 13:02:34 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Sat, 3 May 2025 13:02:34 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java [v2]
In-Reply-To: <05a4twZcz4u4KMieiir8xUxI60Q3zzysPvoZW1uk_H0=.622fa46b-84ff-41aa-b8d6-1b76898801ce@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
 <2UGWZcTuz7Hn6uuu9VgI7m0GofAXr8lSK-oi3h0hb8Q=.48543198-fc6f-4483-82d5-28dedfb7cd08@github.com>
 <kwUAYYMDtXCrrES2Pue5o2wD6S41vVdBM4NXjLLhvzo=.bf347ddc-76cf-416a-8b7c-5686b59ae000@github.com>
 <w1Pind55pdwrtfaZdM1wKMQyM3MiDSmNRmBzeFkWmIA=.3f6075a8-e438-4ee1-b767-255e3c3cb4c9@github.com>
 <05a4twZcz4u4KMieiir8xUxI60Q3zzysPvoZW1uk_H0=.622fa46b-84ff-41aa-b8d6-1b76898801ce@github.com>
Message-ID: <2pTS3qae2y9KNS7zbpXkR8mmdbY7EMiAck5-tc4phA4=.64d21d4f-cab0-488c-a8f6-2728b8479ec0@github.com>

On Sat, 3 May 2025 12:46:55 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Would a comment with the following text be sufficient:
>> 
>> In Windows CMD (`cmd.exe`), `echo/` outputs a newline (i.e., an empty line).
>> Wrapping it with `cmd.exe /c` ensures compatibility in both native Windows and Cygwin environments.
>
> Thanks, sounds fine to me! (Although I?m not an expert in the field, which is also why I thought a comment would be a nice addition here)

done: 90752f181b1d8326c854bc06e2108a3751fa225e

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23933#discussion_r2072390824

From mik3hall at gmail.com  Sat May  3 15:10:46 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 3 May 2025 10:10:46 -0500
Subject: RFR: 8342576: [macos] AppContentTest still fails after
 JDK-8341443 for same reason on older macOS versions
In-Reply-To: <n9D80jZ-y3nkXn5YsKaVEe_4v-0DZEi0Sntlvuyrlt0=.49b906f1-bcb1-49d9-9ad7-c240587b20c9@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
 <n9D80jZ-y3nkXn5YsKaVEe_4v-0DZEi0Sntlvuyrlt0=.49b906f1-bcb1-49d9-9ad7-c240587b20c9@github.com>
Message-ID: <90FE32DF-9C77-466C-A95C-5C96DE44083C@gmail.com>


> 3. re-sign the content manually with 
> 
>          # Sign the final artifact
>          codesign --force --deep --sign "Developer ID Application: JabRef e.V. (6792V39SK3)" \
>            --entitlements buildres/mac/jabref.entitlements \
>            --options runtime --timestamp build/distribution/JabRef.app
> 

Possibly I missed something if this was the fix.

I don?t remember any issues with the existing signing when I tried notarization.

I do see?

--deep  (DEPRECATED for signing as of macOS 13.0)

When I man codesign.

I?m also a little curious how you came up with the ?options runtime. I?m not familiar and even after looking at the man I?m not quite sure what it's purpose is. Make the requirements extra strict exempted by entitlements maybe?

Also why you decided to use ?timestamp?

I looked to see if jpackage uses any options like this but verbose output only shows codesign being invoked, many times, and not with what parameters.

If this is sufficient, or required, for a valid, notarizable application, maybe jpackage could be simplified to  just do an invocation like yours at the end rather than the numerous invocations it appears to do.


From duke at openjdk.org  Sat May  3 15:33:52 2025
From: duke at openjdk.org (Christoph)
Date: Sat, 3 May 2025 15:33:52 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
Message-ID: <hJdD4wGL_u_bPTB_s2fFFEcoQX1unQBalIKM9n0X6EA=.6a6109ae-0469-4b24-afdf-deae2b9caa48@github.com>

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
> - This change is for macOS only.
> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

Jpackage does include the options as well from the logs:

2025-05-02T17:19:25.6907840Z [17:19:12.379] Preparing Info.plist: /Users/runner/work/***/***/jabgui/build/distribution/JabRef.app/Contents/Info.plist.
2025-05-02T17:19:25.6908750Z [17:19:12.383] Using custom package resource [Application Info.plist] (loaded from Info.plist).
2025-05-02T17:19:25.6909590Z [17:19:12.388] Using custom package resource [Java Runtime Info.plist] (loaded from Runtime-Info.plist).
2025-05-02T17:19:25.6910240Z [17:19:23.350] Running /usr/bin/codesign
2025-05-02T17:19:25.6910740Z [17:19:24.530] Command [PID: 6752]:
2025-05-02T17:19:25.6911920Z     /usr/bin/codesign -s Developer ID Application: JabRef e.V. (6792V39SK3) -vvvv --timestamp --options runtime --prefix org.*** --entitlements buildres/mac/***.entitlements --force build/distribution/JabRef.app/Contents/runtime
2025-05-02T17:19:25.6912950Z [17:19:24.530] Output:
2025-05-02T17:19:25.6914200Z     build/distribution/JabRef.app/Contents/runtime: replacing existing signature
2025-05-02T17:19:25.6915140Z     build/distribution/JabRef.app/Contents/runtime: signed bundle with Mach-O thin (arm64) [com.oracle.java.JabRef]
2025-05-02T17:19:25.6915990Z [17:19:24.530] Returned: 0
2025-05-02T17:19:25.6916510Z [17:19:24.530] Running /usr/bin/codesign
2025-05-02T17:19:25.6917100Z [17:19:25.655] Command [PID: 6759]:
2025-05-02T17:19:25.6918000Z     /usr/bin/codesign -s Developer ID Application: JabRef e.V. (6792V39SK3) -vvvv --timestamp --options runtime --prefix org.*** --entitlements buildres/mac/***.entitlements --force build/distribution/JabRef.app
2025-05-02T17:19:25.6918880Z [17:19:25.656] Output:
2025-05-02T17:19:25.6919430Z     build/distribution/JabRef.app: replacing existing signature
2025-05-02T17:19:25.6920230Z     build/distribution/JabRef.app: signed app bundle with Mach-O thin (arm64) [org.***JabRef]
2025-05-02T17:19:25.6920880Z [17:19:25.656] Returned: 0
2025-05-02T17:19:25.6921160Z 
2025-05-02T17:19:25.6921510Z [17:19:25.656] Succeeded in building Mac Application Image package
2025-05-02T17:19:36.0557030Z Warning: Support for per-user configuration of the installed application will not be supported due to missing "build/distribution/JabRef.app/Contents/app/.package" in predefined signed application image.


After creating the app image we put additional content in it under Resources. That probably affects the integrity? of the whole stuff


**Runtime** options is for Hardened Runtime https://developer.apple.com/documentation/security/hardened-runtime 
which allows specifying exclusions like jit in the entitlements 

**Timestamp** is also required https://developer.apple.com/documentation/security/resolving-common-notarization-issues#Include-a-secure-timestamp 

Otherwise, notarization fails with no timestamp or invalid timestamp. 

**Deep** is like going recursively through the files. But should be avoided. I will try without as well 

To upload a macOS app to be notarized, you must enable the Hardened Runtime capability. For more information about notarization, see [Notarizing macOS software before distribution](https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution).

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848675876

From mik3hall at gmail.com  Sat May  3 15:49:58 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 3 May 2025 10:49:58 -0500
Subject: RFR: 8342576: [macos] AppContentTest still fails after
 JDK-8341443 for same reason on older macOS versions
In-Reply-To: <hJdD4wGL_u_bPTB_s2fFFEcoQX1unQBalIKM9n0X6EA=.6a6109ae-0469-4b24-afdf-deae2b9caa48@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
 <hJdD4wGL_u_bPTB_s2fFFEcoQX1unQBalIKM9n0X6EA=.6a6109ae-0469-4b24-afdf-deae2b9caa48@github.com>
Message-ID: <C0B30885-8E67-4BF7-A612-CFBEEC4F8141@gmail.com>



> On May 3, 2025, at 10:33?AM, Christoph <duke at openjdk.org> wrote:
> 
> On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:
> 
>> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
>> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
>> - This change is for macOS only.
>> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.
> 
> Jpackage does include the options as well from the logs:

Not for me with 

${PACKAGER} \
	--verbose \
	--jlink-options '--strip-debug --no-man-pages --no-header-files' \
	--input input \
	--icon GenericApp.icns \
	--resource-dir resources \
	--name HalfPipe \
	--type "dmg" \
	--main-jar halfpipe.jar \
	--main-class us.hall.hp.common.LoaderLaunchStub \
	--module-path '/Users/mjh/Documents/javafx-jmods-21.0.1:mods' \
 	--add-modules javafx.swing,javafx.graphics,javafx.controls,us.hall.eio,org.openjdk.nashorn,java.compiler,java.desktop,java.logging,java.management,jdk.management.agent,java.prefs,java.se,java.rmi,java.scripting,java.sql,java.xml,jdk.attach,jdk.jshell,jdk.crypto.ec,jdk.jdeps,jdk.jcmd,jdk.zipfs,jdk.jfr \
	--java-options '-Xmx1024m -XX:+UnlockDiagnosticVMOptions --add-opens java.desktop/javax.swing.text=ALL-UNNAMED --enable-preview -Djdk.attach.allowAttachSelf=true -XX:+UseG1GC -XX:MaxGCPauseMillis=50 --enable-native-access=ALL-UNNAMED -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider --add-opens=java.base/java.lang=ALL-UNNAMED --add-exports java.base/java.lang=ALL-UNNAMED --add-exports org.openjdk.nashorn/org.openjdk.nashorn.tools=ALL-UNNAMED -Dapp.path=$APPDIR -Djava.security.policy=$APPDIR/all.policy -Dapple.laf.useScreenMenuBar=true -Dapple.awt.application.name=HalfPipe -Dconsole=pane' \
	--mac-package-identifier "us.hall.HalfPipe" \
	--mac-sign \
	--mac-signing-key-user-name "$SIGNING_CERT" \
	--mac-entitlements "entitlements.xml" \
	--mac-dmg-content additional/src.zip,additional/Half-Pipe.pdf

All I see are the 

[10:05:03.044] Running /usr/bin/codesign


> 
> 
> After creating the app image we put additional content in it under Resources. That probably affects the integrity? of the whole stuff
> 
> 
> **Runtime** options is for Hardened Runtime https://developer.apple.com/documentation/security/hardened-runtime 
> which allows specifying exclusions like jit in the entitlements 
> 
> **Timestamp** is also required https://developer.apple.com/documentation/security/resolving-common-notarization-issues#Include-a-secure-timestamp 
> 
> Otherwise, notarization fails with no timestamp or invalid timestamp. 
> 
> **Deep** is like going recursively through the files. But should be avoided. I will try without as well 
> 
> To upload a macOS app to be notarized, you must enable the Hardened Runtime capability. For more information about notarization, see [Notarizing macOS software before distribution](https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution).

Hardened runtime sounds sort of familiar, it?s been a while. Other requirements might of changed.


From mik3hall at gmail.com  Sat May  3 15:53:10 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 3 May 2025 10:53:10 -0500
Subject: RFR: 8342576: [macos] AppContentTest still fails after
 JDK-8341443 for same reason on older macOS versions
In-Reply-To: <C0B30885-8E67-4BF7-A612-CFBEEC4F8141@gmail.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
 <hJdD4wGL_u_bPTB_s2fFFEcoQX1unQBalIKM9n0X6EA=.6a6109ae-0469-4b24-afdf-deae2b9caa48@github.com>
 <C0B30885-8E67-4BF7-A612-CFBEEC4F8141@gmail.com>
Message-ID: <7832C240-075F-4051-819E-2981E4AFE3B2@gmail.com>



> On May 3, 2025, at 10:49?AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On May 3, 2025, at 10:33?AM, Christoph <duke at openjdk.org> wrote:
>> 
>> On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:
>> 
>>> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
>>> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
>>> - This change is for macOS only.
>>> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.
>> 
>> Jpackage does include the options as well from the logs:
> 
> Not for me with 
> 

Sorry missed it.

/usr/bin/codesign -s Developer ID Application: Michael Hall (5X6BXQB3Q7) -vvvv --timestamp --options runtime --prefix us.hall.hp.common. --entitlements entitlements.xml --force /var/folders/mp/64527rf1501726r7t53qpx0w0000gn/T/jdk.jpackage8582845157994500039/images/image-17727033358038913514/HalfPipe.app

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250503/c021f2fe/attachment.htm>

From duke at openjdk.org  Sat May  3 16:09:45 2025
From: duke at openjdk.org (Markus KARG)
Date: Sat, 3 May 2025 16:09:45 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 UTF16::compress & Unsafe::copyMemory [v4]
In-Reply-To: <Rjmq4n-QIKTcuPhiU29BsSdBWZLA2YG5S5U5mySYVMA=.6e92fd18-298e-4ce1-b78b-5e7166beaac4@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <V8ZrRweDmVS9HD5kY8TM6xIVWBfiZy8StMHs6LPO78o=.59017549-3ec8-4627-b206-a9e897045081@github.com>
 <fmTENnnls6QlNngwvE7zC-zZWbJPYb2Qo9hhLUgV9lM=.017ce3f7-d529-40ca-8290-f8567d7f1933@github.com>
 <Rjmq4n-QIKTcuPhiU29BsSdBWZLA2YG5S5U5mySYVMA=.6e92fd18-298e-4ce1-b78b-5e7166beaac4@github.com>
Message-ID: <gDOq_GfRbg2GUui-M2U-ubqvgckBewo1DLJjD0QoRCk=.64c57c06-1a49-46dc-b26d-e652f5018ff7@github.com>

On Fri, 2 May 2025 07:13:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> > > ```java
> > > >         char[] ca = new char[end - off];
> > > ```
> > > Your code here has a memory allocation, which may cause slowdown
> > 
> > This is exactly what I wanted to express with my posting.
> 
> I agree with you that this PR can improve the performance of Reader's method ` int read(char[] cbuf, int off, int len)`, but may not help the performance of Reader::getChars.

I have performed a JMH Benchmark to compare the code with and without the optimization, and the result is surprising:


Benchmark | (SIZE) | Mode | Cnt | Score | ? | Error | Units
25 (modified) | 2 | thrpt | 25 | 71277668 | ? | 5549555 | ops/s
25 (modified) | 128 | thrpt | 25 | 33916527 | ? | 2631800 | ops/s
25 (modified) | 1024 | thrpt | 25 | 4291498 | ? | 401636 | ops/s
25 (modified) | 8192 | thrpt | 25 | 419871 | ? | 63557 | ops/s
 ?
Benchmark | (SIZE) | Mode | Cnt | Score | ? | Error | Units
25 (original) | 2 | thrpt | 25 | 159882761 | ? | 2900397 | ops/s
25 (original) | 128 | thrpt | 25 | 24093787 | ? | 1706259 | ops/s
25 (original) | 1024 | thrpt | 25 | 3794393 | ? | 28097 | ops/s
25 (original) | 8192 | thrpt | 25 | 491340 | ? | 5569 | ops/s


Actually for appended lengths of 128...1024 characters, the modified case is faster. This means, the benefit of `StringUTF16::compress` in fact outperforms the penalty implied by `new char[]`! While for size 1024 chars the benefit is rather small, for size 128 it is huge: More than 40% gain in throughput! ? 

I will repeat the benchmark with more steps in the range 2...1024 to see where the break-even-point is, so we effectively can enable the optimization in a performance-wise "safe" range. Stay tuned! ?

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

PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-2848689948

From mik3hall at gmail.com  Sat May  3 16:19:54 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 3 May 2025 11:19:54 -0500
Subject: RFR: 8342576: [macos] AppContentTest still fails after
 JDK-8341443 for same reason on older macOS versions
In-Reply-To: <C0B30885-8E67-4BF7-A612-CFBEEC4F8141@gmail.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
 <hJdD4wGL_u_bPTB_s2fFFEcoQX1unQBalIKM9n0X6EA=.6a6109ae-0469-4b24-afdf-deae2b9caa48@github.com>
 <C0B30885-8E67-4BF7-A612-CFBEEC4F8141@gmail.com>
Message-ID: <8FBCA716-7B12-43A5-A631-CA541AD3B1AF@gmail.com>



> On May 3, 2025, at 10:49?AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> **Deep** is like going recursively through the files. But should be avoided. I will try without as well

There was something in the man about behavior when using deep in combination with force. I?m not sure what eliminating one will do.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250503/036eb9d2/attachment.htm>

From swen at openjdk.org  Sat May  3 18:33:48 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 3 May 2025 18:33:48 GMT
Subject: RFR: 8349176: Speed up Integer/Long.toString via
 StringConcatHelper::newArray [v4]
In-Reply-To: <tI9blpanPahfQWwugS4LEaIOaKLdTKNoPNByt2CkLjM=.6c2666f6-4a84-4148-83b8-f4a8692a07a5@github.com>
References: <u9INrX9ZnlI8Hs0gC1hnE-oYiHLrnL93Q5hF1yzmJgM=.8b5bb878-27f0-4c21-a1bb-82ce65634b81@github.com>
 <tI9blpanPahfQWwugS4LEaIOaKLdTKNoPNByt2CkLjM=.6c2666f6-4a84-4148-83b8-f4a8692a07a5@github.com>
Message-ID: <JB1OIiZCwBdZ_ov_1g0IGvqEaNX3mZG9dTP9q9GzC1Y=.74231b8d-819a-4031-9a5f-61e1f6907ac8@github.com>

On Sat, 3 May 2025 05:03:36 GMT, Shaojin Wen <swen at openjdk.org> 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 Unsafe::allocateUninitializedArray

public static String toString(int i) {
        int size = DecimalDigits.stringSize(i);
        byte coder = COMPACT_STRINGS ? LATIN1 : UTF16;
        byte[] buf = (byte[]) Unsafe.getUnsafe().allocateUninitializedArray(byte.class, size << coder);
        if (coder == LATIN1) {
            DecimalDigits.getCharsLatin1(i, size, buf);
        } else {
            DecimalDigits.getCharsUTF16(i, size, buf);
        }
        return new String(buf, coder);
    }

This implementation has a smaller code size and the same performance, but it changes the code structure, so I did not use it.

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

PR Comment: https://git.openjdk.org/jdk/pull/23353#issuecomment-2848749465

From zuniquex at protonmail.com  Sat May  3 20:07:22 2025
From: zuniquex at protonmail.com (=?utf-8?Q?Steffen_Nie=C3=9Fing?=)
Date: Sat, 03 May 2025 20:07:22 +0000
Subject: Documentation fix in MethodHandles.Lookup
Message-ID: <R0ejpwN4ZFSC8il9bE3c1HwS8Cq9PDDmWdMZgKQeAdnm-4Gib6j_YyNRgBDsGRnKILBg30KNC4wA4Bt2dkPqVHwuZoLld9tdDtwUPvY3ooM=@protonmail.com>

Hello,

I've found a small documentation inconvenience in the MethodHandles.Lookup class documentation. In the Lookup Factory Methods table the field types of the member and bytecode definitions for lookup.findGetter diverge: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/MethodHandles.java#L503-L504.

I'd propose to change the bytecode entry to (FT) this.f;. I'm a new contributor and don't have access to the JBS yet. I'd be grateful, if anyone would like to sponsor me here.

Cheers,
Steffen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250503/6c81bd5c/attachment.htm>

From asemenyuk at openjdk.org  Sat May  3 20:37:54 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 3 May 2025 20:37:54 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <C0B30885-8E67-4BF7-A612-CFBEEC4F8141@gmail.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
 <C0B30885-8E67-4BF7-A612-CFBEEC4F8141@gmail.com>
Message-ID: <BB1jdx5GvLb1n5vd3K9RDt6MC73skLKsvguw3XHtLx0=.d4114723-f6a1-4589-a64e-e13f7592c31b@github.com>

On Sat, 3 May 2025 15:51:39 GMT, Michael Hall <mik3hall at gmail.com> wrote:

> After creating the app image we put additional content in it under Resources. That probably affects the integrity? of the whole stuff

Right, if you modify the app image, you need to resign it. I'm glad you figured out a workaround. But ideally, you should be able to pass additional content to jpackage with `--app-content`, and it should produce a notarizable signed app image without extra steps on the user's side. Unfortunately, it doesn't.

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848798298

From asemenyuk at openjdk.org  Sat May  3 20:58:50 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 3 May 2025 20:58:50 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
Message-ID: <RTtFbulcfSK2FuLBJ4T2DHm6mjRVsv4e7GC1erOBadE=.0aafd0a3-08b1-4bf7-a1be-d87f658b065d@github.com>

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
> - This change is for macOS only.
> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

So the takeaway from this fruitful discussion is:
 - jpackage doesn't produce helpful verbose signing output. Filed [JDK-8356116](https://bugs.openjdk.org/browse/JDK-8356116)
 - jpackage doesn't produce a notarizable app image if `--app-content` is used. Filed [JDK-8356117](https://bugs.openjdk.org/browse/JDK-8356117)

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848805427

From mik3hall at gmail.com  Sat May  3 21:14:45 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 3 May 2025 16:14:45 -0500
Subject: RFR: 8342576: [macos] AppContentTest still fails after
 JDK-8341443 for same reason on older macOS versions
In-Reply-To: <RTtFbulcfSK2FuLBJ4T2DHm6mjRVsv4e7GC1erOBadE=.0aafd0a3-08b1-4bf7-a1be-d87f658b065d@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
 <RTtFbulcfSK2FuLBJ4T2DHm6mjRVsv4e7GC1erOBadE=.0aafd0a3-08b1-4bf7-a1be-d87f658b065d@github.com>
Message-ID: <54576F35-E74D-4D8B-80F4-D1BCEF2F913E@gmail.com>



> On May 3, 2025, at 3:58?PM, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:
> 
> On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:
> 
>> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
>> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
>> - This change is for macOS only.
>> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.
> 
> So the takeaway from this fruitful discussion is:
> - jpackage doesn't produce helpful verbose signing output. Filed [JDK-8356116](https://bugs.openjdk.org/browse/JDK-8356116)

I was mistaken on this. The codesign parameters appear to be shown once. Then there are many messages indicating just that codesign is being run.
If the same parameters are always used indicating the parameters for each message probably isn?t needed.

> - jpackage doesn't produce a notarizable app image if `--app-content` is used. Filed [JDK-8356117](https://bugs.openjdk.org/browse/JDK-8356117)
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848805427

I may of missed this as well. I thought the original poster indicated that changing the signing parameters somehow gave them a fix.
If so, and doing it only once works, all the additional codesign?s that jpackage seems to do might not be necessary?
Although if his fix depended on using ?deep that currently shows as deprecated in the man page.

I would think that only executable content would need signing? ?app-content I don?t think adds anything for that.
If it doesn?t break signing, and I see there is a SigningOptionsTest that appears to include it, I wouldn?t think it would break notarization either.

But I don?t know. Other than testing some time back I don?t notarize.


From duke at openjdk.org  Sat May  3 21:14:57 2025
From: duke at openjdk.org (Christoph)
Date: Sat, 3 May 2025 21:14:57 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <RTtFbulcfSK2FuLBJ4T2DHm6mjRVsv4e7GC1erOBadE=.0aafd0a3-08b1-4bf7-a1be-d87f658b065d@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
 <RTtFbulcfSK2FuLBJ4T2DHm6mjRVsv4e7GC1erOBadE=.0aafd0a3-08b1-4bf7-a1be-d87f658b065d@github.com>
Message-ID: <fPPlTcikAYFyKY7QS9Ma74b12UEvT8-dYgZbWCURI0E=.74f2f73c-94fc-4fc6-a748-b45fd33b34b3@github.com>

On Sat, 3 May 2025 20:56:00 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> jpackage doesn't produce a notarizable app image if --app-content is used. Filed [JDK-8356117](https://bugs.openjdk.org/browse/JDK-8356117)

Actually, this is a regression as it worked in JDK23 where we just used it recently 
https://github.com/JabRef/jabref/blob/6d0d78716893cc09577a957d111d62ba2dfbefd0/.github/workflows/deployment-arm64.yml#L115-L126 

Just changing from 23 to 24 led to this error as reported by @koppor  earlier in this thread 
https://github.com/openjdk/jdk/pull/21698#issuecomment-2838481133 

The binaries of the release were successfully notarized both on macOS13 and macOS14 (About dialog of JabRef shows the jdk version used as well, 23.0.1) 
 https://github.com/JabRef/jabref/releases/tag/v6.0-alpha2

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2848810724

From bchristi at openjdk.org  Sun May  4 03:52:50 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Sun, 4 May 2025 03:52:50 GMT
Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed
 with "RuntimeException: MyObject is not found in test output" [v9]
In-Reply-To: <QWRVkqE5InLXOIV2aN_iujhFQBSjldCJcglPMfmRsCE=.03d2fa42-cb11-46c3-ad57-94f3ad1c54ef@github.com>
References: <Jcra20HpK4hJAr6O1VySmMukJHFGYEieEpvDVrlbxuI=.03ee416c-3568-4a66-be60-f6c17fed2188@github.com>
 <lETJgNjO8kCy1DtUVEvh8dm-Tupl8r35SdGo8qgg-sY=.777fd32c-7ae4-4bff-8006-8394606b1d78@github.com>
 <QWRVkqE5InLXOIV2aN_iujhFQBSjldCJcglPMfmRsCE=.03d2fa42-cb11-46c3-ad57-94f3ad1c54ef@github.com>
Message-ID: <jT5Hv-1o6XUXUwSoHfq1N4DhKQLhtrAis0w92MPXpBw=.92c8fb10-b615-4713-841d-72f1338a0904@github.com>

On Sat, 3 May 2025 00:35:44 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unneeded 'trappedCount'
>
> test/jdk/java/lang/ref/FinalizerHistogramTest.java line 78:
> 
>> 76:                 refProResult = wb.waitForReferenceProcessing();
>> 77:                 System.out.println("waitForReferenceProcessing returned: " + refProResult);
>> 78:             } while (refProResult);
> 
> Why the spammy output?  Why not just
> 
> while (wb.waitForReferenceProcessing()) {}

Right now, the test just it prints a single line:
`waitForReferenceProcessing returned: false`
and I expect this to continue to be true.

For intermittently failing tests, I'm inclined to add a little extra output as long as I'm fiddling with it anyway. That way, if the test ever starts failing again, we have some (hopefully useful) clues about what happened.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2072512987

From kbarrett at openjdk.org  Sun May  4 04:07:59 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 4 May 2025 04:07:59 GMT
Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed
 with "RuntimeException: MyObject is not found in test output" [v9]
In-Reply-To: <lETJgNjO8kCy1DtUVEvh8dm-Tupl8r35SdGo8qgg-sY=.777fd32c-7ae4-4bff-8006-8394606b1d78@github.com>
References: <Jcra20HpK4hJAr6O1VySmMukJHFGYEieEpvDVrlbxuI=.03ee416c-3568-4a66-be60-f6c17fed2188@github.com>
 <lETJgNjO8kCy1DtUVEvh8dm-Tupl8r35SdGo8qgg-sY=.777fd32c-7ae4-4bff-8006-8394606b1d78@github.com>
Message-ID: <ZXuB1RoofnCQmKRffsgkJhcLABi02eYbKNH2LNx2oxc=.8159f6dc-5895-47a4-95c1-835e282682d7@github.com>

On Thu, 1 May 2025 21:47:01 GMT, Brent Christian <bchristi at openjdk.org> 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:
> 
>   remove unneeded 'trappedCount'

Marked as reviewed by kbarrett (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24143#pullrequestreview-2813356236

From kbarrett at openjdk.org  Sun May  4 04:07:59 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 4 May 2025 04:07:59 GMT
Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed
 with "RuntimeException: MyObject is not found in test output" [v9]
In-Reply-To: <jT5Hv-1o6XUXUwSoHfq1N4DhKQLhtrAis0w92MPXpBw=.92c8fb10-b615-4713-841d-72f1338a0904@github.com>
References: <Jcra20HpK4hJAr6O1VySmMukJHFGYEieEpvDVrlbxuI=.03ee416c-3568-4a66-be60-f6c17fed2188@github.com>
 <lETJgNjO8kCy1DtUVEvh8dm-Tupl8r35SdGo8qgg-sY=.777fd32c-7ae4-4bff-8006-8394606b1d78@github.com>
 <QWRVkqE5InLXOIV2aN_iujhFQBSjldCJcglPMfmRsCE=.03d2fa42-cb11-46c3-ad57-94f3ad1c54ef@github.com>
 <jT5Hv-1o6XUXUwSoHfq1N4DhKQLhtrAis0w92MPXpBw=.92c8fb10-b615-4713-841d-72f1338a0904@github.com>
Message-ID: <cDCXOdx_qfzWzwW8Up9HnsT8G3k9ekDcG3Qu2_v56_I=.3790124e-02e8-4d4b-b88d-fee825799d31@github.com>

On Sun, 4 May 2025 03:49:44 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Right now, the test just it prints a single line: `waitForReferenceProcessing returned: false` and I expect this to continue to be true.

If reference processing is being slow because of load, that will be different.

> For intermittently failing tests, I'm inclined to add a little extra output as long as I'm fiddling with it anyway. That way, if the test ever starts failing again, we have some (hopefully useful) clues about what happened.

OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2072514833

From chen.l.liang at oracle.com  Sun May  4 04:33:58 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sun, 4 May 2025 04:33:58 +0000
Subject: Documentation fix in MethodHandles.Lookup
In-Reply-To: <R0ejpwN4ZFSC8il9bE3c1HwS8Cq9PDDmWdMZgKQeAdnm-4Gib6j_YyNRgBDsGRnKILBg30KNC4wA4Bt2dkPqVHwuZoLld9tdDtwUPvY3ooM=@protonmail.com>
References: <R0ejpwN4ZFSC8il9bE3c1HwS8Cq9PDDmWdMZgKQeAdnm-4Gib6j_YyNRgBDsGRnKILBg30KNC4wA4Bt2dkPqVHwuZoLld9tdDtwUPvY3ooM=@protonmail.com>
Message-ID: <SJ2PR10MB766969C1C04A188A785B52DAA28F2@SJ2PR10MB7669.namprd10.prod.outlook.com>

I have created https://bugs.openjdk.org/browse/JDK-8356119 for you. You can proceed to create a patch.
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Steffen Nie?ing <zuniquex at protonmail.com>
Sent: Saturday, May 3, 2025 3:07 PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Documentation fix in MethodHandles.Lookup

Hello,

I've found a small documentation inconvenience in the MethodHandles.Lookup class documentation. In the Lookup Factory Methods table the field types of the member and bytecode definitions for lookup.findGetter diverge: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/MethodHandles.java#L503-L504.

I'd propose to change the bytecode entry to (FT) this.f;. I'm a new contributor and don't have access to the JBS yet. I'd be grateful, if anyone would like to sponsor me here.

Cheers,
Steffen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250504/ed538667/attachment-0001.htm>

From alanb at openjdk.org  Sun May  4 05:12:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 4 May 2025 05:12:00 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <_gsm1O3oGkFRt64kDD7WKL2HG69RpOhvbwRTjhTMBWI=.0c7c0bfb-1783-4162-be25-90e3ebe6dc56@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
 <6lD4tGZLf54gX50KgP-YGFAGTQhh0A7kh07p-XdOX-Y=.c30197c4-2ffa-4a7a-b5cb-98901427eaa7@github.com>
 <_gsm1O3oGkFRt64kDD7WKL2HG69RpOhvbwRTjhTMBWI=.0c7c0bfb-1783-4162-be25-90e3ebe6dc56@github.com>
Message-ID: <jd9LQJ0WWD1vKVsk1hr8aXdkGHGVnzLDibQeX79boGY=.65119ae7-1f98-4d4f-bf66-7af04a475fce@github.com>

On Sat, 3 May 2025 09:30:17 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 213:
>> 
>>> 211:             public String readAllChars() throws IOException {
>>> 212:                 ensureOpen();
>>> 213:                 return cs.toString().substring(next);
>> 
>> Your change implies creating a full-length string *first* (including cyoping and compression), just to strip it down to a smaller one *later*. It would be more efficient to *first* strip it down, and compression into a `String` *afterwards*. Imagine a huge `cs` with `next` being near to `length()`, and you see the difference in efficiency! ? 
>> 
>> `cs.subSequence(next, cs.length()).toString()`
>> 
>> (Edited my proposal to be more correct.)
>
> Oh, and we should set `next` afterwards, so the `Reader` knows that the end of the sequence is reached:
> 
> 
> public String readAllChars() throws IOException {
>     ensureOpen();
>     var len = cs.length();
>     var remainder = cs.subSequence(next, len);
>     next = len;
>     return remainder.toString();
> }
> 
> 
> (Edited my proposal to be a bit more concurrency-friendly and correct.)

Probably best to ignore the implementation details as the discussions on what methods to expose, and where, is still going on. It was probably a bit premature to create the PR without getting agreement on the API first.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2072521725

From lucy at openjdk.org  Sun May  4 12:30:45 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Sun, 4 May 2025 12:30:45 GMT
Subject: RFR: 8355979: ATTRIBUTE_NO_UBSAN needs to be extended to handle
 float divisions by zero on AIX
In-Reply-To: <CbiD1gny6_AnRa8wj35UTQrEax7JsnPJ2vOrikOWTB8=.ac4b7cee-59e8-4af9-bf46-dafc834b8c4d@github.com>
References: <CbiD1gny6_AnRa8wj35UTQrEax7JsnPJ2vOrikOWTB8=.ac4b7cee-59e8-4af9-bf46-dafc834b8c4d@github.com>
Message-ID: <Sr-bVxmFH1Ev7ZujENT9EaxssYj07wH-e1Xdr1I-K_Q=.a8d892f4-9261-4c66-b1d9-8f8fef894e8c@github.com>

On Wed, 30 Apr 2025 13:04:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Seems the currently used ATTRIBUTE_NO_UBSAN does not handle the exclusion of float divisions by zero.
> At least this is the case on AIX.
> 
> (seen in the jtreg test java/lang/Math/PowTests.java )

LGTM.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24963#pullrequestreview-2813453676

From lucy at openjdk.org  Sun May  4 12:30:46 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Sun, 4 May 2025 12:30:46 GMT
Subject: RFR: 8355979: ATTRIBUTE_NO_UBSAN needs to be extended to handle
 float divisions by zero on AIX
In-Reply-To: <fIRGoyEr45waI-PDp0Uynnl9ViFl-oAz4u8XS_4D-ho=.16002a72-decd-4422-b038-6ed90bcedac6@github.com>
References: <CbiD1gny6_AnRa8wj35UTQrEax7JsnPJ2vOrikOWTB8=.ac4b7cee-59e8-4af9-bf46-dafc834b8c4d@github.com>
 <XEsOFWuGuxlHBAFtAjTT-ZZ8ok3gvfNDd1y_9KhKkXo=.e2a8e1d1-720f-469f-86f7-f3c962084303@github.com>
 <fIRGoyEr45waI-PDp0Uynnl9ViFl-oAz4u8XS_4D-ho=.16002a72-decd-4422-b038-6ed90bcedac6@github.com>
Message-ID: <pr7ilkBGHBg2L-XFqrcWb1bM5W8gl3IAXt165nn-yhg=.eed198d1-31f4-440c-b6bc-65fb465f63d4@github.com>

On Fri, 2 May 2025 08:11:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/hotspot/share/sanitizers/ub.hpp line 39:
>> 
>>> 37: #define ATTRIBUTE_NO_UBSAN __attribute__((no_sanitize("undefined","float-divide-by-zero")))
>>> 38: #endif
>>> 39: #if defined(__GNUC__) && !defined(__clang__)
>> 
>> Maybe use `#elif`?
>
> Or should I try to set it for BOTH clang and gcc so that the added checks are not needed any more?

If you change it to #elif, then please do it in both files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24963#discussion_r2072605220

From duke at openjdk.org  Sun May  4 14:02:45 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 4 May 2025 14:02:45 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: <NieYRAJ5CS6tleYzkyUp4EfP4D488yDkKU0xej9Uf8Q=.054270ec-4395-4a01-95f5-5f5bd5a7c618@github.com>

On Sat, 5 Apr 2025 17:36:29 GMT, Markus KARG <duke at openjdk.org> 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`.

@liach How to proceed?

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

PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2849236880

From liach at openjdk.org  Sun May  4 14:51:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 May 2025 14:51:44 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: <BWwvzrcR8h5Qr55B5f7UrBTf0ni8gzOhv4ri8X8I188=.35544c6f-d72f-45bd-9cd3-5ae60dcbbdc9@github.com>

On Sat, 5 Apr 2025 17:36:29 GMT, Markus KARG <duke at openjdk.org> 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`.

I will raise attention to this to other Oracle's JDK core library reviewers. Meanwhile you can start drafting a CSR like that for `getChars` for `CharSequence`.

One concern is that (See `HashMap.newHashMap` vs `HashMap.of`) `XxxWriter.of(StringBuilder)` now returns a basic `Writer` instead of `XxxWriter`, but since we already have that for `Reader.of` and the argument type is specific, I think this is not an issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2849260129

From liach at openjdk.org  Sun May  4 14:57:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 May 2025 14:57:51 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: <CgZEZxnANDgYo254cqD_HIoefqSBO74Dzm3kkBw50WI=.195d4c9c-de4d-4422-b995-b45b2de91e32@github.com>

On Sat, 5 Apr 2025 17:36:29 GMT, Markus KARG <duke at openjdk.org> 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`.

src/java.base/share/classes/java/nio/X-Buffer.java.template line 2:

> 1: /*
> 2:  * Copyright (c) 2000, 2025, Oracle and/or its affiliates. All rights reserved.

Redundant change.

test/jdk/java/io/Writer/Of.java line 45:

> 43:         @Override
> 44:         public String toString() {
> 45:             return id; // allows to identify config when test case fails

I used the same strategy in junit tests; the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24469#discussion_r2072637744
PR Review Comment: https://git.openjdk.org/jdk/pull/24469#discussion_r2072638134

From duke at openjdk.org  Sun May  4 16:21:41 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 4 May 2025 16:21:41 GMT
Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2]
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: <OQFS9tEyTK4cXqq9upD-EH8-B3H_LB0nfBAHkW-daXk=.fd5763c2-a86d-4b0b-9857-c8a70542ad31@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`.

Markus KARG has updated the pull request incrementally with two additional commits since the last revision:

 - Undone copyright update of otherwise unchanged file.
 - Update Of.java
   
   Applied changnes proposed by @liach: "the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise."

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24469/files
  - new: https://git.openjdk.org/jdk/pull/24469/files/75efb7fd..ea435ed1

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

  Stats: 7 lines in 2 files changed: 0 ins; 5 del; 2 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 duke at openjdk.org  Sun May  4 16:21:42 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 4 May 2025 16:21:42 GMT
Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2]
In-Reply-To: <CgZEZxnANDgYo254cqD_HIoefqSBO74Dzm3kkBw50WI=.195d4c9c-de4d-4422-b995-b45b2de91e32@github.com>
References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
 <CgZEZxnANDgYo254cqD_HIoefqSBO74Dzm3kkBw50WI=.195d4c9c-de4d-4422-b995-b45b2de91e32@github.com>
Message-ID: <Cmh8zPpIUDFWCQERlCxOwwUMvX_h3oU8odyYbwurVlM=.634cbb54-032f-4966-b06f-37cbaced12ec@github.com>

On Sun, 4 May 2025 14:52:39 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Undone copyright update of otherwise unchanged file.
>>  - Update Of.java
>>    
>>    Applied changnes proposed by @liach: "the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise."
>
> src/java.base/share/classes/java/nio/X-Buffer.java.template line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2000, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Redundant change.

Good catch! Undone copyright update in https://github.com/openjdk/jdk/pull/24469/commits/ea435ed1090d8f028262f5900baf0a00472726d9.

> test/jdk/java/io/Writer/Of.java line 45:
> 
>> 43:         @Override
>> 44:         public String toString() {
>> 45:             return id; // allows to identify config when test case fails
> 
> I used the same strategy in junit tests; the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise.

Understood. Removed override in https://github.com/openjdk/jdk/pull/24469/commits/f48b99995723b6c4dd73014015f50b1047ff28cd.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24469#discussion_r2072655279
PR Review Comment: https://git.openjdk.org/jdk/pull/24469#discussion_r2072654985

From duke at openjdk.org  Sun May  4 16:49:21 2025
From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=)
Date: Sun, 4 May 2025 16:49:21 GMT
Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter
Message-ID: <NQUre5r4T9T4zOi4Jcw180gWzhzcnrLRrUBwR72y-AY=.9232e31f-2f1f-418a-8bf3-6f98dfef649a@github.com>

This PR fixes a typo in the bytecode cast for Lookup.findGetter.

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

Commit messages:
 - 8356119: Correct field type for bytecode cast

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

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

From duke at openjdk.org  Sun May  4 17:03:48 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 4 May 2025 17:03:48 GMT
Subject: RFR: 8353795: Add Writer.of(StringBuilder)
In-Reply-To: <BWwvzrcR8h5Qr55B5f7UrBTf0ni8gzOhv4ri8X8I188=.35544c6f-d72f-45bd-9cd3-5ae60dcbbdc9@github.com>
References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
 <BWwvzrcR8h5Qr55B5f7UrBTf0ni8gzOhv4ri8X8I188=.35544c6f-d72f-45bd-9cd3-5ae60dcbbdc9@github.com>
Message-ID: <NLXF5MeN-nyQhx-abdUSw_oKuBNr2ONiwtDZ3J5Xxxk=.9d02c6ff-9376-4d38-b324-ddec74ecc588@github.com>

On Sun, 4 May 2025 14:49:35 GMT, Chen Liang <liach at openjdk.org> wrote:

> ...you can start drafting a CSR like that for `getChars` for `CharSequence`.

Done. Kindly asking your review for the CSR: https://bugs.openjdk.org/browse/JDK-8356123.

> One concern is that (See `HashMap.newHashMap` vs `HashMap.of`) `XxxWriter.of(StringBuilder)` now returns a basic `Writer` instead of `XxxWriter`, but since we already have that for `Reader.of` and the argument type is specific, I think this is not an issue.

The CSR indicates that `Writer.of()` is the *symmetric* API to `Reader.of()`, so I think it is understood why we have chosen that name.

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

PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2849314924

From liach at openjdk.org  Sun May  4 17:04:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 May 2025 17:04:53 GMT
Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter
In-Reply-To: <NQUre5r4T9T4zOi4Jcw180gWzhzcnrLRrUBwR72y-AY=.9232e31f-2f1f-418a-8bf3-6f98dfef649a@github.com>
References: <NQUre5r4T9T4zOi4Jcw180gWzhzcnrLRrUBwR72y-AY=.9232e31f-2f1f-418a-8bf3-6f98dfef649a@github.com>
Message-ID: <IcrG4g62NrLAIU4JRqXT7x1s9jtd5Cqt26uw2SHhQvQ=.f4d51550-af0c-4916-baa6-20172cbae9a9@github.com>

On Sun, 4 May 2025 16:45:11 GMT, Steffen Nie?ing <duke at openjdk.org> wrote:

> This PR fixes a typo in the bytecode cast for Lookup.findGetter.

Thanks for the mailing list communication and reply.

Check out https://openjdk.org/guide/ for more steps. For example, a patch should usually wait 24 hours for sufficient reviews.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25024#pullrequestreview-2813514938

From eirbjo at openjdk.org  Sun May  4 17:22:47 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 4 May 2025 17:22:47 GMT
Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter
In-Reply-To: <NQUre5r4T9T4zOi4Jcw180gWzhzcnrLRrUBwR72y-AY=.9232e31f-2f1f-418a-8bf3-6f98dfef649a@github.com>
References: <NQUre5r4T9T4zOi4Jcw180gWzhzcnrLRrUBwR72y-AY=.9232e31f-2f1f-418a-8bf3-6f98dfef649a@github.com>
Message-ID: <k_7K0gS17MsurSz1qwrHEGkOcjdMDbZuBZIr-ujQZZ0=.5c4a1bf0-e12b-4341-8efc-b193090e8d25@github.com>

On Sun, 4 May 2025 16:45:11 GMT, Steffen Nie?ing <duke at openjdk.org> wrote:

> This PR fixes a typo in the bytecode cast for Lookup.findGetter.

Nit: Would be nice if the PR title/description made it clear for the casual reader that this is a documentation/Javadoc typo, as opposed to a code issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/25024#issuecomment-2849324307

From eirbjo at openjdk.org  Sun May  4 17:28:45 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 4 May 2025 17:28:45 GMT
Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter
In-Reply-To: <NQUre5r4T9T4zOi4Jcw180gWzhzcnrLRrUBwR72y-AY=.9232e31f-2f1f-418a-8bf3-6f98dfef649a@github.com>
References: <NQUre5r4T9T4zOi4Jcw180gWzhzcnrLRrUBwR72y-AY=.9232e31f-2f1f-418a-8bf3-6f98dfef649a@github.com>
Message-ID: <KzQ77ImuRTMpQvrQL6OYNslBpj6lZW7x1Tom2MsOrUE=.9fc8a59e-cc8a-4138-a213-fad1518d356b@github.com>

On Sun, 4 May 2025 16:45:11 GMT, Steffen Nie?ing <duke at openjdk.org> wrote:

> This PR fixes a typo in the bytecode cast for Lookup.findGetter.

Just a tip for a newcomer: (Welcome!)

It may be useful to flag this PR as ?trivial? and ?documentation-only? by saying something like ?Please review this trivial, documentation-only PR which..?

This gives reviewers some feeling of the size/complexity of the PR without actually digging into the code.

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

PR Comment: https://git.openjdk.org/jdk/pull/25024#issuecomment-2849327311

From asemenyuk at openjdk.org  Sun May  4 17:32:55 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sun, 4 May 2025 17:32:55 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <wdt9ESRa6CUdwCtoYKoGB3_Bf0vMVWM8QIET3Ufrn5M=.f1274c92-3b9c-4ecd-8936-b7bf3e5542fe@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
 <wdt9ESRa6CUdwCtoYKoGB3_Bf0vMVWM8QIET3Ufrn5M=.f1274c92-3b9c-4ecd-8936-b7bf3e5542fe@github.com>
Message-ID: <xSHVUzKcDG4UirH39LyvGyp_QRO3vbTrVRp6dFcNy6Y=.66bc59ec-a45a-41d1-91e1-cc6b76758a27@github.com>

On Tue, 29 Apr 2025 11:35:29 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
>> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
>> - This change is for macOS only.
>> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.
>
> Google directed me here. We updated from JDK23 to JDK24
> 
> We have
> 
>     --app-content buildres/mac/jabrefHost.py
> 
> JDK23: Without any issue
> 
> JDK24: 
> 
> 
> "codesign" failed and additional application content was supplied via the "--app-content" parameter. Probably the additional content broke the integrity of the application bundle and caused the failure. Ensure content supplied via the "--app-content" parameter does not break the integrity of the application bundle, or add it in the post-processing step.
> [10:08:52.963] Running /usr/bin/xcrun
> [10:08:52.973] Command [PID: 9939]:
>     /usr/bin/xcrun --help
> [10:08:52.973] Output:
>     Usage: xcrun [options] <tool name> ... arguments ...
>     
>     Find and execute the named command line tool from the active developer
>     directory.
>     
>     The active developer directory can be set using `xcode-select`, or via the
>     DEVELOPER_DIR environment variable. See the xcrun and xcode-select manual
>     pages for more information.
>     
>     Options:
>       -h, --help                  show this help message and exit
>       --version                   show the xcrun version
>       -v, --verbose               show verbose logging output
>       --sdk <sdk name>            find the tool for the given SDK name
>       --toolchain <name>          find the tool for the given toolchain
>       -l, --log                   show commands to be executed (with --run)
>       -f, --find                  only find and print the tool path
>       -r, --run                   find and execute the tool (the default behavior)
>       -n, --no-cache              do not use the lookup cache
>       -k, --kill-cache            invalidate all existing cache entries
>       --show-sdk-path             show selected SDK install path
>       --show-sdk-version          show selected SDK version
>       --show-sdk-build-version    show selected SDK build version
>       --show-sdk-platform-path    show selected SDK platform path
>       --show-sdk-platform-version show selected SDK platform version
> [10:08:52.974] Returned: 0
> 
> Error: "codesign" failed with following output:
> /var/folders/gn/rldh9pd93qg48089gvgb1gb80000gn/T/jdk.jpackage3854937683320166432/images/image-16322408788641963111/JabRef.app: replacing existing signature
> /var/folders/gn/rldh9pd93qg48089gvgb1gb80000gn/T/jdk.jpackage3854937683320166432/images/image-16322408788641963111/JabRef.app: code object is not signed at all
> In subcomponent: /private/var/folders/gn/rldh9pd93qg48089gvgb1gb80000gn/T/jdk.jpackage3854937683320166...

> Just changing from 23 to 24 led to this error as reported by @koppor earlier in this thread
https://github.com/openjdk/jdk/pull/21698#issuecomment-2838481133

This looks like a regression, but it is not. You use `--app-content buildres/mac/jabrefHost.py`, which will add the "jabrefHost.py" file to the "Contents" directory of the app image. "jabrefHost.py" file should not be at this location, regardless of the version of jpackage. Explanation - https://github.com/openjdk/jdk/pull/21698#issuecomment-2838942773. It should be in the "Contents/Resources" directory instead, so the app content arguments should be `--app-content buildres/mac/Resources/jabrefHost.py`. Can you please try it?

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2849329249

From asemenyuk at openjdk.org  Sun May  4 17:35:57 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sun, 4 May 2025 17:35:57 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <54576F35-E74D-4D8B-80F4-D1BCEF2F913E@gmail.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
 <54576F35-E74D-4D8B-80F4-D1BCEF2F913E@gmail.com>
Message-ID: <IGkfRwzOsav5gLpq8HhRvSCym9ZHMzK2GHyO9QAoLh0=.bbb222f3-960d-4d4c-9cd7-ab3f935b33e5@github.com>

On Sat, 3 May 2025 21:16:39 GMT, Michael Hall <mik3hall at gmail.com> wrote:

> If the same parameters are always used indicating the parameters for each message probably isn?t needed.

The same parameters don't need to be logged, but having the complete list of files signed by jpackage in the log would be good. We don't have it now.

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2849330544

From duke at openjdk.org  Sun May  4 17:55:46 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Sun, 4 May 2025 17:55:46 GMT
Subject: RFR: 8351230: Collections.synchronizedList returns a list that is
 not thread-safe
In-Reply-To: <HtBkFlpJ7N3BjMiDZcA2LgM0YOEkd4L1_6XKIPJwwew=.6325e6ba-153e-43c6-9de6-ab00c1e972ed@github.com>
References: <HtBkFlpJ7N3BjMiDZcA2LgM0YOEkd4L1_6XKIPJwwew=.6325e6ba-153e-43c6-9de6-ab00c1e972ed@github.com>
Message-ID: <h3b0gIkbHz5efvlh3NPhzBZPhQ8DUDa4Ao-rGnVJXO4=.414b236b-4638-41de-91ec-80bf827999c1@github.com>

On Thu, 1 May 2025 19:05:50 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper:
> 
> - overrides and adds locking to SequencedCollection methods;
> - performs instance management of reversed synchronized views;
> - adds test for race conditions and functional tests of synchronized wrappers.

src/java.base/share/classes/java/util/Collections.java line 2837:

> 2835:                 return reversedView;
> 2836:             }
> 2837:         }

`SynchronizedRandomAccessList` overrides `subList`, should it also override `reversed`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24990#discussion_r2072672563

From duke at openjdk.org  Sun May  4 18:12:57 2025
From: duke at openjdk.org (Christoph)
Date: Sun, 4 May 2025 18:12:57 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
Message-ID: <BZwJXikpqut1BsR8Rz43GI1RZjTBvYstzh2jgIlGX8o=.adfc9a79-6610-49a2-9bba-7dbaac5c7bd2@github.com>

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
> - This change is for macOS only.
> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

Just tried it with putting the additional files into the Resources folder.  Same error as originally reported.

Run: https://github.com/JabRef/jabref/actions/runs/14823769155/job/41614205909 

Changes from PR: https://github.com/JabRef/jabref/pull/13032/files#diff-5a17873aec4eae6b52b00959d8f9e17672912858f63181d39de8c3a713e90018R135-R144 


"codesign" failed and additional application content was supplied via the "--app-content" parameter. Probably the additional content broke the integrity of the application bundle and caused the failure. Ensure content supplied via the "--app-content" parameter does not break the integrity of the application bundle, or add it in the post-processing step.


Error: "codesign" failed with following output:
/var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app: replacing existing signature
/var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app: code object is not signed at all
In subcomponent: /private/var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app/Contents/***Host.py
[17:58:51.622] java.io.IOException: Command [/usr/bin/codesign, -s, Developer ID Application: JabRef e.V. (6792V39SK3), -vvvv, --timestamp, --options, runtime, --prefix, org.***, --entitlements, buildres/mac/***.entitlements, --force, /var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app] exited with 1 code
	at jdk.jpackage/jdk.jpackage.internal.Executor.executeExpectSuccess(Executor.java:90)
	at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:125)
	at jdk.jpackage/jdk.jpackage.internal.MacAppImageBuilder.runCodesign(MacAppImageBuilder.java:740)
	at jdk.jpackage/jdk.jpackage.internal.MacAppImageBuilder.signAppBundle(MacAppImageBuilder.java:907)
	at jdk.jpackage/jdk.jpackage.internal.MacAppImageBuilder.doSigning(MacAppImageBuilder.java:414)
	at jdk.jpackage/jdk.jpackage.internal.MacAppImageBuilder.prepareApplicationFiles(MacAppImageBuilder.java:365)
	at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.createAppBundle(AppImageBundler.java:189)
	at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.execute(AppImageBundler.java:93)
	at jdk.jpackage/jdk.jpackage.internal.MacBaseInstallerBundler.prepareAppBundle(MacBaseInstallerBundler.java:201)
	at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:83)
	at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:579)
	at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:707)
	at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:554)
	at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:92)
	at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53)

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2849343813

From alanb at openjdk.org  Sun May  4 18:41:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 4 May 2025 18:41:46 GMT
Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2]
In-Reply-To: <OQFS9tEyTK4cXqq9upD-EH8-B3H_LB0nfBAHkW-daXk=.fd5763c2-a86d-4b0b-9857-c8a70542ad31@github.com>
References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
 <OQFS9tEyTK4cXqq9upD-EH8-B3H_LB0nfBAHkW-daXk=.fd5763c2-a86d-4b0b-9857-c8a70542ad31@github.com>
Message-ID: <cjIKFJmq6HfpJOcjXtnnb1Ap47mgWY6RgX-NeyGuGRw=.6a1fec61-eafd-450f-9359-a1d50093367f@github.com>

On Sun, 4 May 2025 16:21:41 GMT, Markus KARG <duke at openjdk.org> 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`.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Undone copyright update of otherwise unchanged file.
>  - Update Of.java
>    
>    Applied changnes proposed by @liach: "the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise."

Way too early to create a PR and CSR for this. I think close the PR for now, instead start a discussion on core-libs-dev to get input.

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

PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2849357907

From duke at openjdk.org  Sun May  4 19:00:52 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Sun, 4 May 2025 19:00:52 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v2]
In-Reply-To: <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
 <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@github.com>
Message-ID: <EH2EXKLz60ICZwd65amhBCbjwnzkhBNVxo_mPAAClCU=.7f0d6946-1a90-48be-be78-89ad74891e0f@github.com>

On Sat, 3 May 2025 01:08:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Don't need to update latestSupported later
>    
>  - Merge branch 'pr/25015' of https://github.com/openjdk/jdk into feature/preview-cffv
>  - Add advanced testing for different latestSupported
>    
>  - 8355536: Create version constants to model preview language and vm features

src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 413:

> 411:      * ensure the program is compatible with future Java SE releases.
> 412:      * <p>
> 413:      * This is a reflective preview API to allows tools running in Java runtime

Suggestion:

     * This is a reflective preview API that allows tools running in Java runtime

src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 419:

> 417:      * @see <a href="https://openjdk.org/jeps/456">
> 418:      * JEP 456: Unnamed Variables &amp; Patterns</a>
> 419: 

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2072682604
PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2072683561

From duke at openjdk.org  Sun May  4 19:41:55 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Sun, 4 May 2025 19:41:55 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v3]
In-Reply-To: <M7s6_JHhw3uJ8iaPL_eIy9p5BsXpuxx5Rm26pExRh60=.7209bb72-6272-449d-8e8f-3ddb319daf5f@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 <M7s6_JHhw3uJ8iaPL_eIy9p5BsXpuxx5Rm26pExRh60=.7209bb72-6272-449d-8e8f-3ddb319daf5f@github.com>
Message-ID: <Ug_KckdxUN2BEaAfZY1-qQWK2KBadM-WQCbo8RVBe-U=.8e1bb2de-c562-4c0a-b508-1103bf9792c5@github.com>

On Mon, 28 Apr 2025 14:36:33 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>> 
>> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>> 
>> Also see #24705.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Use more simple function descriptor
>  - Simplify FFM linker warmup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Wip work trying to speed up FFM

src/java.base/share/classes/java/lang/foreign/Linker.java line 866:

> 864:                     .map(CapturableState::forName)
> 865:                     .mapToInt(state -> 1 << state.ordinal())
> 866:                     .sum();

Using `sum` means the result will be incorrect if `capturedState` contains a valid name multiple times:

var option = (LinkerOptions.CaptureCallState)Linker.Option.captureCallState("WSAGetLastError", "WSAGetLastError");

// will print [ERRNO] on Windows
System.out.println(option.saved());


option = (LinkerOptions.CaptureCallState)Linker.Option.captureCallState("errno", "errno");

// will throw IndexOutOfBoundsException on all platforms
option.saved();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2072694511

From duke at openjdk.org  Sun May  4 19:41:55 2025
From: duke at openjdk.org (duke)
Date: Sun, 4 May 2025 19:41:55 GMT
Subject: Withdrawn: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long)
In-Reply-To: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
Message-ID: <Stw33Fnbhag_T6j9Jur7qyHF9lXApNyMCWtNI1k9j08=.c499a732-b571-4aec-a69e-adbe74e365c4@github.com>

On Mon, 3 Feb 2025 18:51:20 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The following code can reproduce the problem, writing out of bounds causes JVM Crash
> 
> 
>          StringBuilder buf = new StringBuilder();
>         buf.append('?');
> 
>         Thread[] threads = new Thread[40];
>         final CountDownLatch latch = new CountDownLatch(threads.length);
>         Runnable r = () -> {
>             for (int i = 0; i < 1000000; i++) {
>                 buf.setLength(0);
>                 buf.trimToSize();
>                 buf.append(123456789123456789L);
>             }
>             latch.countDown();
>         };
> 
>         for (int i = 0; i < threads.length; i++) {
>             threads[i] = new Thread(r);
>         }
>         for (Thread t : threads) {
>             t.start();
>         }
>         latch.await();
> 
> 
> This problem can be avoided by using the value of ensureCapacityInternal directly.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Sun May  4 19:45:56 2025
From: duke at openjdk.org (duke)
Date: Sun, 4 May 2025 19:45:56 GMT
Subject: Withdrawn: 8349189: Speed up DateTime parse & format via Class File
 API
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <nrEdd0NZNzebZAyRF8vBaZdl46PnU1pLhyqFbA-ujEE=.c17aa894-9538-424f-ac71-6cca2a509b8f@github.com>

On Fri, 31 Jan 2025 10:29:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Sun May  4 19:47:53 2025
From: duke at openjdk.org (duke)
Date: Sun, 4 May 2025 19:47:53 GMT
Subject: Withdrawn: 8315585: Optimization for decimal to string
In-Reply-To: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com>
References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com>
Message-ID: <sdtLFBifPr9BKtb6rT7WLFoCX3pRGKO7rMg6S-Hh3LE=.792ee168-ce53-4e5d-bed8-290344e8d1a4@github.com>

On Sat, 25 Jan 2025 07:25:40 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code

This pull request has been closed without being integrated.

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

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

From liach at openjdk.org  Sun May  4 20:27:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 May 2025 20:27:52 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v3]
In-Reply-To: <Ug_KckdxUN2BEaAfZY1-qQWK2KBadM-WQCbo8RVBe-U=.8e1bb2de-c562-4c0a-b508-1103bf9792c5@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 <M7s6_JHhw3uJ8iaPL_eIy9p5BsXpuxx5Rm26pExRh60=.7209bb72-6272-449d-8e8f-3ddb319daf5f@github.com>
 <Ug_KckdxUN2BEaAfZY1-qQWK2KBadM-WQCbo8RVBe-U=.8e1bb2de-c562-4c0a-b508-1103bf9792c5@github.com>
Message-ID: <K5fXIJuw_duSHqxL6HniHzWcroKetTpnC60G6tzFGaM=.191ae8b1-43b2-4904-b6a1-fba800782179@github.com>

On Sun, 4 May 2025 19:35:15 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>>  - Use more simple function descriptor
>>  - Simplify FFM linker warmup
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>>  - Wip work trying to speed up FFM
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 866:
> 
>> 864:                     .map(CapturableState::forName)
>> 865:                     .mapToInt(state -> 1 << state.ordinal())
>> 866:                     .sum();
> 
> Using `sum` means the result will be incorrect if `capturedState` contains a valid name multiple times:
> 
> var option = (LinkerOptions.CaptureCallState)Linker.Option.captureCallState("WSAGetLastError", "WSAGetLastError");
> 
> // will print [ERRNO] on Windows
> System.out.println(option.saved());
> 
> 
> option = (LinkerOptions.CaptureCallState)Linker.Option.captureCallState("errno", "errno");
> 
> // will throw IndexOutOfBoundsException on all platforms
> option.saved();

Hmm, I intentionally checked `toSet` does not reject duplicates but forgot about this part. Anyways this stream code is problematic; will fix this in a patch that removes this stream code wholesale.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2072703688

From liach at openjdk.org  Sun May  4 20:29:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 May 2025 20:29:02 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v3]
In-Reply-To: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <9iHgapUiP3vcKCr2JX3m0ZI0PjYe6OKnJvtL4ujo3oI=.97814213-5bd1-486b-bafc-743c2d5666d2@github.com>

> Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
  
  Co-authored-by: Luca Kellermann <lukellmann at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25017/files
  - new: https://git.openjdk.org/jdk/pull/25017/files/d0ff022f..0a3f3896

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

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

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

From liach at openjdk.org  Sun May  4 20:31:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 May 2025 20:31:45 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v2]
In-Reply-To: <EH2EXKLz60ICZwd65amhBCbjwnzkhBNVxo_mPAAClCU=.7f0d6946-1a90-48be-be78-89ad74891e0f@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
 <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@github.com>
 <EH2EXKLz60ICZwd65amhBCbjwnzkhBNVxo_mPAAClCU=.7f0d6946-1a90-48be-be78-89ad74891e0f@github.com>
Message-ID: <h8FFsOzJ32CxA2f6glePn42O1RGuFIb63tDVH5ZWNbI=.3cd7fea4-ad31-420e-89a3-ffe126aa3652@github.com>

On Sun, 4 May 2025 18:46:02 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Don't need to update latestSupported later
>>    
>>  - Merge branch 'pr/25015' of https://github.com/openjdk/jdk into feature/preview-cffv
>>  - Add advanced testing for different latestSupported
>>    
>>  - 8355536: Create version constants to model preview language and vm features
>
> src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 413:
> 
>> 411:      * ensure the program is compatible with future Java SE releases.
>> 412:      * <p>
>> 413:      * This is a reflective preview API to allows tools running in Java runtime
> 
> Suggestion:
> 
>      * This is a reflective preview API that allows tools running in Java runtime

Don't know why you recommend this, but this aims to explain why this API is reflective preview API instead of an essential preview API (that does not have `reflective = true`). Particular tools wish to perform this specific check, like `javap`; otherwise, I would have marked this as non-reflective, and tools must resort to a third-party knowledge pool to parse preview features related to the current release.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2072704486

From duke at openjdk.org  Sun May  4 20:35:53 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Sun, 4 May 2025 20:35:53 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v2]
In-Reply-To: <h8FFsOzJ32CxA2f6glePn42O1RGuFIb63tDVH5ZWNbI=.3cd7fea4-ad31-420e-89a3-ffe126aa3652@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
 <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@github.com>
 <EH2EXKLz60ICZwd65amhBCbjwnzkhBNVxo_mPAAClCU=.7f0d6946-1a90-48be-be78-89ad74891e0f@github.com>
 <h8FFsOzJ32CxA2f6glePn42O1RGuFIb63tDVH5ZWNbI=.3cd7fea4-ad31-420e-89a3-ffe126aa3652@github.com>
Message-ID: <tMCXLFcvKrTglfRiJtmhS6mgqaQRi2K73S_5Z91R1eY=.23328ae5-0ddb-41d6-9835-7db41585eb6e@github.com>

On Sun, 4 May 2025 20:29:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 413:
>> 
>>> 411:      * ensure the program is compatible with future Java SE releases.
>>> 412:      * <p>
>>> 413:      * This is a reflective preview API to allows tools running in Java runtime
>> 
>> Suggestion:
>> 
>>      * This is a reflective preview API that allows tools running in Java runtime
>
> Don't know why you recommend this, but this aims to explain why this API is reflective preview API instead of an essential preview API (that does not have `reflective = true`). Particular tools wish to perform this specific check, like `javap`; otherwise, I would have marked this as non-reflective, and tools must resort to a third-party knowledge pool to parse preview features related to the current release.

It sounded wrong, maybe "to allow" (without 's') would be better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2072705126

From liach at openjdk.org  Sun May  4 20:38:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 May 2025 20:38:47 GMT
Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2]
In-Reply-To: <cjIKFJmq6HfpJOcjXtnnb1Ap47mgWY6RgX-NeyGuGRw=.6a1fec61-eafd-450f-9359-a1d50093367f@github.com>
References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
 <OQFS9tEyTK4cXqq9upD-EH8-B3H_LB0nfBAHkW-daXk=.fd5763c2-a86d-4b0b-9857-c8a70542ad31@github.com>
 <cjIKFJmq6HfpJOcjXtnnb1Ap47mgWY6RgX-NeyGuGRw=.6a1fec61-eafd-450f-9359-a1d50093367f@github.com>
Message-ID: <5mpZGPWGnNshcE30YOHry52vhvYWzdz3sOpsxOIu_nU=.2efc76c8-72c6-4938-91be-b68af5c90223@github.com>

On Sun, 4 May 2025 18:39:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> start a discussion on core-libs-dev

Threads about this topic have been started multiple times but failed to attract any attention on this topic, not even a rejection:
- https://mail.openjdk.org/pipermail/core-libs-dev/2024-December/thread.html#137807
- https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/thread.html#141272

In this situation, how can we ensure a renewed discussion will actually attract attention? I think our guide should suggest a solution to this, like "prmopting a thread after 2 weeks of no reply"?

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

PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2849406747

From liach at openjdk.org  Sun May  4 21:37:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 May 2025 21:37:26 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v4]
In-Reply-To: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <_MkrZWV7SnFd_3CgOvpa_gER0ie2syWXAEhvS47jHLs=.29f9f5a1-ab2f-4be3-8b5d-bb3184ab77ab@github.com>

> Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25017/files
  - new: https://git.openjdk.org/jdk/pull/25017/files/0a3f3896..c1a175ef

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

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

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

From liach at openjdk.org  Sun May  4 21:37:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 May 2025 21:37:26 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v2]
In-Reply-To: <tMCXLFcvKrTglfRiJtmhS6mgqaQRi2K73S_5Z91R1eY=.23328ae5-0ddb-41d6-9835-7db41585eb6e@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
 <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@github.com>
 <EH2EXKLz60ICZwd65amhBCbjwnzkhBNVxo_mPAAClCU=.7f0d6946-1a90-48be-be78-89ad74891e0f@github.com>
 <h8FFsOzJ32CxA2f6glePn42O1RGuFIb63tDVH5ZWNbI=.3cd7fea4-ad31-420e-89a3-ffe126aa3652@github.com>
 <tMCXLFcvKrTglfRiJtmhS6mgqaQRi2K73S_5Z91R1eY=.23328ae5-0ddb-41d6-9835-7db41585eb6e@github.com>
Message-ID: <ZHj0sC-CZ_W-3Q1yD_XXU39B09fzje9uvcyc1UiTtWE=.d4e7ebc2-2a13-4de1-8cab-9c3528e4de7a@github.com>

On Sun, 4 May 2025 20:33:36 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> Don't know why you recommend this, but this aims to explain why this API is reflective preview API instead of an essential preview API (that does not have `reflective = true`). Particular tools wish to perform this specific check, like `javap`; otherwise, I would have marked this as non-reflective, and tools must resort to a third-party knowledge pool to parse preview features related to the current release.
>
> It sounded wrong, maybe "to allow" (without 's') would be better.

Suggestion:

     * This is a reflective preview API to allow tools running in Java runtime

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2072719721

From liach at openjdk.org  Sun May  4 21:46:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 May 2025 21:46:50 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v3]
In-Reply-To: <K5fXIJuw_duSHqxL6HniHzWcroKetTpnC60G6tzFGaM=.191ae8b1-43b2-4904-b6a1-fba800782179@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 <M7s6_JHhw3uJ8iaPL_eIy9p5BsXpuxx5Rm26pExRh60=.7209bb72-6272-449d-8e8f-3ddb319daf5f@github.com>
 <Ug_KckdxUN2BEaAfZY1-qQWK2KBadM-WQCbo8RVBe-U=.8e1bb2de-c562-4c0a-b508-1103bf9792c5@github.com>
 <K5fXIJuw_duSHqxL6HniHzWcroKetTpnC60G6tzFGaM=.191ae8b1-43b2-4904-b6a1-fba800782179@github.com>
Message-ID: <F2d6UTaa4xVtC42_8HK8tOpHu1sBWTXSvNtmWXkpCks=.9d047498-4acf-46e7-86c8-c8ba59e9aac5@github.com>

On Sun, 4 May 2025 20:25:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 866:
>> 
>>> 864:                     .map(CapturableState::forName)
>>> 865:                     .mapToInt(state -> 1 << state.ordinal())
>>> 866:                     .sum();
>> 
>> Using `sum` means the result will be incorrect if `capturedState` contains a valid name multiple times:
>> 
>> var option = (LinkerOptions.CaptureCallState)Linker.Option.captureCallState("WSAGetLastError", "WSAGetLastError");
>> 
>> // will print [ERRNO] on Windows
>> System.out.println(option.saved());
>> 
>> 
>> option = (LinkerOptions.CaptureCallState)Linker.Option.captureCallState("errno", "errno");
>> 
>> // will throw IndexOutOfBoundsException on all platforms
>> option.saved();
>
> Hmm, I intentionally checked `toSet` does not reject duplicates but forgot about this part. Anyways this stream code is problematic; will fix this in a patch that removes this stream code wholesale.

I created an issue to revisit CapturableState https://bugs.openjdk.org/browse/JDK-8356126 and will fix these problem with new unit test ensuring the toString message and nonexistent/duplicate behaviors, also removing redundant stream usage.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2072721337

From liach at openjdk.org  Sun May  4 22:40:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 May 2025 22:40:52 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v3]
In-Reply-To: <F2d6UTaa4xVtC42_8HK8tOpHu1sBWTXSvNtmWXkpCks=.9d047498-4acf-46e7-86c8-c8ba59e9aac5@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 <M7s6_JHhw3uJ8iaPL_eIy9p5BsXpuxx5Rm26pExRh60=.7209bb72-6272-449d-8e8f-3ddb319daf5f@github.com>
 <Ug_KckdxUN2BEaAfZY1-qQWK2KBadM-WQCbo8RVBe-U=.8e1bb2de-c562-4c0a-b508-1103bf9792c5@github.com>
 <K5fXIJuw_duSHqxL6HniHzWcroKetTpnC60G6tzFGaM=.191ae8b1-43b2-4904-b6a1-fba800782179@github.com>
 <F2d6UTaa4xVtC42_8HK8tOpHu1sBWTXSvNtmWXkpCks=.9d047498-4acf-46e7-86c8-c8ba59e9aac5@github.com>
Message-ID: <PA2tbbe4H8hhFkoMkODMMan_BmAPxCIFdz_Adxyx8J0=.909ba90e-c479-4b2f-a6c2-d271184c6c80@github.com>

On Sun, 4 May 2025 21:43:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hmm, I intentionally checked `toSet` does not reject duplicates but forgot about this part. Anyways this stream code is problematic; will fix this in a patch that removes this stream code wholesale.
>
> I created an issue to revisit CapturableState https://bugs.openjdk.org/browse/JDK-8356126 and will fix these problem with new unit test ensuring the toString message and nonexistent/duplicate behaviors, also removing redundant stream usage.

See #25025, which includes a regression test that should prevent such duplicate arg mishandling or toString message missing user-friendly names.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2072730363

From liach at openjdk.org  Sun May  4 22:41:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 May 2025 22:41:54 GMT
Subject: RFR: 8356126: Revisit CaptureCallState
Message-ID: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>

Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.

Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.

Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)

Testing: jdk/lang/foreign, tier 1-3 in progress.

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

Commit messages:
 - Bugid
 - 8356126: Revisit CaptureCallState

Changes: https://git.openjdk.org/jdk/pull/25025/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356126
  Stats: 129 lines in 7 files changed: 48 ins; 42 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/25025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25025/head:pull/25025

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

From mik3hall at gmail.com  Sun May  4 22:54:25 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 4 May 2025 17:54:25 -0500
Subject: RFR: 8342576: [macos] AppContentTest still fails after
 JDK-8341443 for same reason on older macOS versions
In-Reply-To: <BZwJXikpqut1BsR8Rz43GI1RZjTBvYstzh2jgIlGX8o=.adfc9a79-6610-49a2-9bba-7dbaac5c7bd2@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
 <BZwJXikpqut1BsR8Rz43GI1RZjTBvYstzh2jgIlGX8o=.adfc9a79-6610-49a2-9bba-7dbaac5c7bd2@github.com>
Message-ID: <9A5706EA-EC7A-41BE-8518-4C7BF68868A9@gmail.com>



> On May 4, 2025, at 1:12?PM, Christoph <duke at openjdk.org> wrote:
> 
> In subcomponent: /private/var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app/Contents/***Host.py

If this is the current error log the file ***Host.py (? Strange file name.) doesn?t seem to be in the resource directory but the Contents directory still?

But I?ve been off on this a couple times already.

Still curious do all the codesign running messages in verbose output indicate multiple invocations or are they the status for a single running process?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250504/0fb54e02/attachment.htm>

From duke at openjdk.org  Sun May  4 23:13:49 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Sun, 4 May 2025 23:13:49 GMT
Subject: RFR: 8356126: Revisit CaptureCallState
In-Reply-To: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
Message-ID: <vL0XapJ1TnZOgHFvgll0YWDySSFmWHjg50iwJhi3RL8=.8fd716f3-6686-48a3-aa6e-fecef57bb2bb@github.com>

On Sun, 4 May 2025 22:37:21 GMT, Chen Liang <liach at openjdk.org> wrote:

> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
> 
> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
> 
> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
> 
> Testing: jdk/lang/foreign, tier 1-3 in progress.

src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 63:

> 61:             stateLayouts[i++] = supported.layout;
> 62:         }
> 63:         LAYOUT = MemoryLayout.structLayout(stateLayouts);

Does it matter that the order is not deterministic here? This question can also be asked for the exception in `forName` and result of `displayString`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2072732592

From asemenyuk at openjdk.org  Sun May  4 23:18:53 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sun, 4 May 2025 23:18:53 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
Message-ID: <zCn4wK2jiaSYpAgwFMK22e_8S7kAgjDTz97sbGcGaJ0=.e73d1322-13b5-4a3f-a96f-d37771c577bc@github.com>

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
> - This change is for macOS only.
> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

In the log:


In subcomponent: /private/var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app/Contents/***Host.py


The command line:

jpackage \
  ...
  --app-content buildres/mac/Resources/***Host.py \
  --app-content buildres/mac/Resources/native-messaging-host \


`--app-content` values are wrong. My bad, I gave you incorrect instructions. It should be a single "--app-content buildres/mac" option. This way, jpackage will copy both the "jabrefHost.py" file and the "native-messaging-host" directory into the "Contents/Resources" directory in the app bundle. This should make codesign work.

You can have multiple `--app-content` on the jpackage command line, but on macOS, the value should be a directory with the "Resources" subdirectory (or any other directory that is valid in the "Contents" directory of the app bundle). Otherwise, codesign will keep failing.

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2849491184

From liach at openjdk.org  Sun May  4 23:32:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 May 2025 23:32:43 GMT
Subject: RFR: 8356126: Revisit CaptureCallState
In-Reply-To: <vL0XapJ1TnZOgHFvgll0YWDySSFmWHjg50iwJhi3RL8=.8fd716f3-6686-48a3-aa6e-fecef57bb2bb@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <vL0XapJ1TnZOgHFvgll0YWDySSFmWHjg50iwJhi3RL8=.8fd716f3-6686-48a3-aa6e-fecef57bb2bb@github.com>
Message-ID: <NbBjc_wp4BKpibK06IAe-TfAneHzDjVirTWTK6JVP3M=.f4d8fd37-f6f1-461f-b7d7-6defb8fe334f@github.com>

On Sun, 4 May 2025 22:51:21 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
>> 
>> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
>> 
>> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
>> 
>> Testing: jdk/lang/foreign, tier 1-3 in progress.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 63:
> 
>> 61:             stateLayouts[i++] = supported.layout;
>> 62:         }
>> 63:         LAYOUT = MemoryLayout.structLayout(stateLayouts);
> 
> Does it matter that the order is not deterministic here? This question can also be asked for the exception in `forName` and result of `displayString`.

After all, this should not be an enum when the entries differ by platform. We need to convert this to records.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2072740841

From iklam at openjdk.org  Mon May  5 00:29:19 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 5 May 2025 00:29:19 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics
Message-ID: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>

This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)

- Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
- Added processing of the `AOT_TOOL_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
- Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options

Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.

Examples:


# Create an AOT cache with a single command:
$ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
Hello World
Temporary AOTConfiguration recorded: foo.aot.config
Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
AOTCache creation is complete: foo.aot 10240000 bytes

# Create logging file for the AOT cache assembly phase
$ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
$ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld


Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).

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

Commit messages:
 - Remove %t restriction
 - Added %p substitution; clean up
 - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
 - fixed typo
 - added comment that was removed in previous commit
 - Refactored code to enfore the order of argument parsing
 - 8355798: Implement JEP-JDK-8350022: Ahead-of-time Command Line Ergonomics

Changes: https://git.openjdk.org/jdk/pull/24942/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355798
  Stats: 1776 lines in 17 files changed: 1298 ins; 439 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/24942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942

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

From kvn at openjdk.org  Mon May  5 00:29:20 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 5 May 2025 00:29:20 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics
In-Reply-To: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
Message-ID: <yteO0kGOL66F-9axU05cABX63exn87r8Z7tbFM-MYbU=.e006c808-4fff-449a-aa8b-9c42f7ef7705@github.com>

On Tue, 29 Apr 2025 04:50:42 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
> 
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
> - Added processing of the `AOT_TOOL_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
> 
> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
> 
> Examples:
> 
> 
> # Create an AOT cache with a single command:
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> Hello World
> Temporary AOTConfiguration recorded: foo.aot.config
> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
> AOTCache creation is complete: foo.aot 10240000 bytes
> 
> # Create logging file for the AOT cache assembly phase
> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> 
> 
> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).

Few comments.

JEP and CSR call env var :`JAVA_AOT_OPTIONS`. This description and changes call it `AOT_TOOL_OPTIONS`. Please, fix.

src/hotspot/share/cds/metaspaceShared.cpp line 1068:

> 1066:   }
> 1067: 
> 1068:   // Pass all arguments. These include those from JAVA_TOOL_OPTIONS and _JAVA_OPTIONS.

`_JAVA_OPTIONS`. Do you mean `JAVA_AOT_OPTIONS`?

src/hotspot/share/cds/metaspaceShared.cpp line 1071:

> 1069:   for (int i = 0; i < Arguments::num_jvm_args(); i++) {
> 1070:     const char* arg = Arguments::jvm_args_array()[i];
> 1071:     if (strncmp("-XX:AOTMode", arg, 11) == 0) {

In arguments.cpp you do `strncmp("-XX:AOTMode=", arg, 12) == 0`. I think you need to be consistent.

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

> 508: 
> 509:             Map<String, String> env = pb.environment();
> 510:             env.put("JAVA_TOOL_OPTIONS", sb.toString());

What about `JAVA_AOT_OPTIONS`?

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

PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2804218715
PR Comment: https://git.openjdk.org/jdk/pull/24942#issuecomment-2839405664
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2066881980
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2066888741
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2066892210

From iklam at openjdk.org  Mon May  5 00:38:13 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 5 May 2025 00:38:13 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v2]
In-Reply-To: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
Message-ID: <DA_fpI4S7yXKOwmVZ7ZFEu1QQQdIzbx6uwK2KDbWrhg=.6faee4e0-5071-43ca-a0fc-b7f057dc3b84@github.com>

> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
> 
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
> 
> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
> 
> Examples:
> 
> 
> # Create an AOT cache with a single command:
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> Hello World
> Temporary AOTConfiguration recorded: foo.aot.config
> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
> AOTCache creation is complete: foo.aot 10240000 bytes
> 
> # Create logging file for the AOT cache assembly phase
> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> 
> 
> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24942/files
  - new: https://git.openjdk.org/jdk/pull/24942/files/acba394e..5e51e8fe

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

  Stats: 305 lines in 5 files changed: 142 ins; 140 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/24942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942

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

From iklam at openjdk.org  Mon May  5 01:00:31 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 5 May 2025 01:00:31 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v3]
In-Reply-To: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
Message-ID: <ZqN7me24ilvFxqQs47wNdM6lhli5RuQXWKP4fwRI4No=.4fae3be6-ceb5-4de2-b129-1fde746c0760@github.com>

> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
> 
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
> 
> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
> 
> Examples:
> 
> 
> # Create an AOT cache with a single command:
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> Hello World
> Temporary AOTConfiguration recorded: foo.aot.config
> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
> AOTCache creation is complete: foo.aot 10240000 bytes
> 
> # Create logging file for the AOT cache assembly phase
> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> 
> 
> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @vnkozlov comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24942/files
  - new: https://git.openjdk.org/jdk/pull/24942/files/5e51e8fe..0eb8b545

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

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

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

From iklam at openjdk.org  Mon May  5 01:00:31 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 5 May 2025 01:00:31 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics
In-Reply-To: <yteO0kGOL66F-9axU05cABX63exn87r8Z7tbFM-MYbU=.e006c808-4fff-449a-aa8b-9c42f7ef7705@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <yteO0kGOL66F-9axU05cABX63exn87r8Z7tbFM-MYbU=.e006c808-4fff-449a-aa8b-9c42f7ef7705@github.com>
Message-ID: <Kv61EAlT6QrF0qFmcMTDYWXUcQEQVBhsYmkVrjrDboE=.3894456a-5a90-4a27-b2d7-966583bfd8a1@github.com>

On Tue, 29 Apr 2025 15:48:12 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> JEP and CSR call env var :`JAVA_AOT_OPTIONS`. This description and changes call it `AOT_TOOL_OPTIONS`. Please, fix.

Fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/24942#issuecomment-2849668130

From iklam at openjdk.org  Mon May  5 01:00:31 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 5 May 2025 01:00:31 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v3]
In-Reply-To: <yteO0kGOL66F-9axU05cABX63exn87r8Z7tbFM-MYbU=.e006c808-4fff-449a-aa8b-9c42f7ef7705@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <yteO0kGOL66F-9axU05cABX63exn87r8Z7tbFM-MYbU=.e006c808-4fff-449a-aa8b-9c42f7ef7705@github.com>
Message-ID: <WEPMm8rf7zRrMXmT4fh0NL2-DwT7WitVn-eHKEcZku8=.45124202-99b3-432a-a106-7f7c34a25104@github.com>

On Tue, 29 Apr 2025 15:56:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @vnkozlov comments
>
> src/hotspot/share/cds/metaspaceShared.cpp line 1068:
> 
>> 1066:   }
>> 1067: 
>> 1068:   // Pass all arguments. These include those from JAVA_TOOL_OPTIONS and _JAVA_OPTIONS.
> 
> `_JAVA_OPTIONS`. Do you mean `JAVA_AOT_OPTIONS`?

`JAVA_AOT_OPTIONS` is not parsed here. I added comments.

> src/hotspot/share/cds/metaspaceShared.cpp line 1071:
> 
>> 1069:   for (int i = 0; i < Arguments::num_jvm_args(); i++) {
>> 1070:     const char* arg = Arguments::jvm_args_array()[i];
>> 1071:     if (strncmp("-XX:AOTMode", arg, 11) == 0) {
> 
> In arguments.cpp you do `strncmp("-XX:AOTMode=", arg, 12) == 0`. I think you need to be consistent.

Fixed.

> src/java.base/share/classes/jdk/internal/misc/CDS.java line 510:
> 
>> 508: 
>> 509:             Map<String, String> env = pb.environment();
>> 510:             env.put("JAVA_TOOL_OPTIONS", sb.toString());
> 
> What about `JAVA_AOT_OPTIONS`?

This method doesn't not touch `JAVA_AOT_OPTIONS`, which will be inherited by the child process.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2072761734
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2072761745
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2072761767

From liach at openjdk.org  Mon May  5 03:13:35 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 May 2025 03:13:35 GMT
Subject: RFR: 8356126: Revisit CaptureCallState [v2]
In-Reply-To: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
Message-ID: <W9LObaoDuOznXc9CdliKV9-LIAIQSqwisdF-EHlxTWY=.516ac7ac-84e8-4467-bc3b-1c059ddd98af@github.com>

> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
> 
> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
> 
> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
> 
> Testing: jdk/lang/foreign, tier 1-3 in progress.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Further revamp, remove unnecessary instances on irrelevant platforms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25025/files
  - new: https://git.openjdk.org/jdk/pull/25025/files/94fca4b4..106ad252

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

  Stats: 30 lines in 1 file changed: 12 ins; 4 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25025/head:pull/25025

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

From liach at openjdk.org  Mon May  5 03:32:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 May 2025 03:32:45 GMT
Subject: RFR: 8356126: Revisit CaptureCallState [v3]
In-Reply-To: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
Message-ID: <B2NQulzuPH1yJjPITiJ6nSkzLG1LOr-VRVYXm_0kjmw=.99260e88-3fbd-4824-a187-b32a0b1534cf@github.com>

> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
> 
> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
> 
> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
> 
> Testing: jdk/lang/foreign, tier 1-3 in progress.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Unchecked

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25025/files
  - new: https://git.openjdk.org/jdk/pull/25025/files/106ad252..fc3e7a80

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

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

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

From liach at openjdk.org  Mon May  5 04:50:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 May 2025 04:50:30 GMT
Subject: RFR: 8356126: Revisit CaptureCallState [v4]
In-Reply-To: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
Message-ID: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com>

> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
> 
> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
> 
> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
> 
> Testing: jdk/lang/foreign, tier 1-3 in progress.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  No env to test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25025/files
  - new: https://git.openjdk.org/jdk/pull/25025/files/fc3e7a80..806d307b

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

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

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

From duke at openjdk.org  Mon May  5 05:40:47 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 5 May 2025 05:40:47 GMT
Subject: RFR: 8356126: Revisit CaptureCallState [v4]
In-Reply-To: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com>
Message-ID: <Upg_aXZZ8a79L02cDTx2l_HP4PGRDm9fMyzJDxpq7t4=.b9a4c763-d10d-47d9-b8b4-8ab25776c018@github.com>

On Mon, 5 May 2025 04:50:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
>> 
>> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
>> 
>> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
>> 
>> Testing: jdk/lang/foreign, tier 1-3 in progress.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No env to test

Note?that the?use of?the?unsequenced `Map.of(?)` results?in the?return value of?`CapturableState?.displayString(?)` to?no?longer be?ordered by?the?mask?bits.

To?fix?this, simply?add a?`private?static List<CapturableState>`[^1] for?storing the?supported?values:

[^1]: And/or?introduce and?use unmodifiable `SequencedMap.of(?)` and?`SequencedSet.of(?)` factory?methods.

src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 55:

> 53:         } else {
> 54:             supported = List.of(new CapturableState("errno", JAVA_INT, 1 << 2));
> 55:         }

Suggestion:

    private static final List<CapturableState> SUPPORTED;

    static {
        final List<CapturableState> supported;

        if (OperatingSystem.isWindows()) {
            supported = List.of(
                    new CapturableState("GetLastError",    JAVA_INT, 1 << 0),
                    new CapturableState("WSAGetLastError", JAVA_INT, 1 << 1),
                    new CapturableState("errno",           JAVA_INT, 1 << 2)
            );
        } else {
            supported = List.of(new CapturableState("errno", JAVA_INT, 1 << 2));
        }

        SUPPORTED = supported;

src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 96:

> 94:     public static String displayString(int mask) {
> 95:         var displayList = new ArrayList<>();
> 96:         for (var e : LOOKUP.values()) {

Suggestion:

        for (var e : SUPPORTED) {

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

PR Review: https://git.openjdk.org/jdk/pull/25025#pullrequestreview-2813828585
PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2072860691
PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2072860830

From alanb at openjdk.org  Mon May  5 06:35:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 May 2025 06:35:46 GMT
Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2]
In-Reply-To: <5mpZGPWGnNshcE30YOHry52vhvYWzdz3sOpsxOIu_nU=.2efc76c8-72c6-4938-91be-b68af5c90223@github.com>
References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
 <OQFS9tEyTK4cXqq9upD-EH8-B3H_LB0nfBAHkW-daXk=.fd5763c2-a86d-4b0b-9857-c8a70542ad31@github.com>
 <cjIKFJmq6HfpJOcjXtnnb1Ap47mgWY6RgX-NeyGuGRw=.6a1fec61-eafd-450f-9359-a1d50093367f@github.com>
 <5mpZGPWGnNshcE30YOHry52vhvYWzdz3sOpsxOIu_nU=.2efc76c8-72c6-4938-91be-b68af5c90223@github.com>
Message-ID: <eeRDuECOJFPJUsTfuLfJmp_Q58iGge4HMvB_8ezOwM4=.68aed1bd-16a3-4a9e-a56e-9966fbefa299@github.com>

On Sun, 4 May 2025 20:36:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> In this situation, how can we ensure a renewed discussion will actually attract attention? I think our guide should suggest a solution to this, like "prmopting a thread after 2 weeks of no reply"?

The mailing list is the right place to get agreement on what the problem is and what the solution/API might be if it progresses to that. Lack of engagement should not be interpreted as supporting the proposal. The lack of engagement might be better interpreted as people are busy or maybe that the problem isn't compelling or high priority enough to spend time on right now.  The dev guide should not put a deadline on getting responses.

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

PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2850034687

From turbanoff at gmail.com  Mon May  5 07:54:04 2025
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Mon, 5 May 2025 10:54:04 +0300
Subject: StringIndexOutOfBoundsException is thrown from String.concat
Message-ID: <CAF+DQ5e-NTjqZnpZ2_Kn_6EYmn4svjAKfntMKpuYn0VACP3szw@mail.gmail.com>

Hello.
I noticed that String.concat can throw StringIndexOutOfBoundsException:

String r1 = "-".repeat(Integer.MAX_VALUE - 10);
String r2 = "?".repeat((Integer.MAX_VALUE - 10)  / 2);
System.out.println(r1.concat(r2));

On JDK 24 it gives:
Exception in thread "main" java.lang.StringIndexOutOfBoundsException:
Range [0, 0 + 2147483637) out of bounds for length 1073741807
    at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:55)
    at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:52)
    at java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:213)
    at java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:210)
    at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:98)
    at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckFromIndexSize(Preconditions.java:118)
    at java.base/jdk.internal.util.Preconditions.checkFromIndexSize(Preconditions.java:397)
    at java.base/java.lang.String.checkBoundsOffCount(String.java:4938)
    at java.base/java.lang.StringUTF16.checkBoundsOffCount(StringUTF16.java:1789)
    at java.base/java.lang.StringUTF16.inflate(StringUTF16.java:1616)
    at java.base/java.lang.StringLatin1.inflate(StringLatin1.java:875)
    at java.base/java.lang.String.getBytes(String.java:4812)
    at java.base/java.lang.StringConcatHelper.doConcat(StringConcatHelper.java:434)
    at java.base/java.lang.String.concat(String.java:2977)

On JDK 23 it results in expected OOM:

Exception in thread "main" java.lang.OutOfMemoryError: Overflow:
String length out of range
    at java.base/java.lang.StringConcatHelper.checkOverflow(StringConcatHelper.java:66)
    at java.base/java.lang.StringConcatHelper.mix(StringConcatHelper.java:125)
    at java.base/java.lang.StringConcatHelper.simpleConcat(StringConcatHelper.java:374)
    at java.base/java.lang.String.concat(String.java:2990)

Andrey Turbanov

From aturbanov at openjdk.org  Mon May  5 07:58:56 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 May 2025 07:58:56 GMT
Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v7]
In-Reply-To: <7jJhv5Eb-VWcsm64nN3e07zHp92QaVE5MHv6W1KqScc=.53abce8f-2301-4dfd-b52d-bec0eea264dd@github.com>
References: <vnijupgoATashEN6yRTJkGj6bgsz30fuM2Kgy3UNgeU=.1a7fea78-f74a-4578-b7de-c4e5b7165dad@github.com>
 <7jJhv5Eb-VWcsm64nN3e07zHp92QaVE5MHv6W1KqScc=.53abce8f-2301-4dfd-b52d-bec0eea264dd@github.com>
Message-ID: <MMbblSL2xDVQioPzxN9XFJAtBt75hzXUxZTLreniCZE=.461c3a81-49bf-42a9-ab0b-3eac91bc9de5@github.com>

On Tue, 23 Jul 2024 12:56:07 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduce change

Looks like this changes regressed behavior on long Strings:

        String r1 = "-".repeat(Integer.MAX_VALUE - 10);
        String r2 = "?".repeat((Integer.MAX_VALUE - 10)  / 2);
        System.out.println(r1.concat(r2));

This code now throws `StringIndexOutOfBoundsException` instead of `OutOfMemoryError`

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

PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2850196722

From alan.bateman at oracle.com  Mon May  5 08:06:34 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Mon, 5 May 2025 09:06:34 +0100
Subject: StringIndexOutOfBoundsException is thrown from String.concat
In-Reply-To: <CAF+DQ5e-NTjqZnpZ2_Kn_6EYmn4svjAKfntMKpuYn0VACP3szw@mail.gmail.com>
References: <CAF+DQ5e-NTjqZnpZ2_Kn_6EYmn4svjAKfntMKpuYn0VACP3szw@mail.gmail.com>
Message-ID: <796f797f-238a-42fb-a498-2c62e4525e82@oracle.com>

Can you create a bug in JBS to track this?

-Alan

On 05/05/2025 08:54, Andrey Turbanov wrote:
> Hello.
> I noticed that String.concat can throw StringIndexOutOfBoundsException:
>
> String r1 = "-".repeat(Integer.MAX_VALUE - 10);
> String r2 = "?".repeat((Integer.MAX_VALUE - 10)  / 2);
> System.out.println(r1.concat(r2));
>
> On JDK 24 it gives:
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException:
> Range [0, 0 + 2147483637) out of bounds for length 1073741807
>      at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:55)
>      at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:52)
>      at java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:213)
>      at java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:210)
>      at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:98)
>      at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckFromIndexSize(Preconditions.java:118)
>      at java.base/jdk.internal.util.Preconditions.checkFromIndexSize(Preconditions.java:397)
>      at java.base/java.lang.String.checkBoundsOffCount(String.java:4938)
>      at java.base/java.lang.StringUTF16.checkBoundsOffCount(StringUTF16.java:1789)
>      at java.base/java.lang.StringUTF16.inflate(StringUTF16.java:1616)
>      at java.base/java.lang.StringLatin1.inflate(StringLatin1.java:875)
>      at java.base/java.lang.String.getBytes(String.java:4812)
>      at java.base/java.lang.StringConcatHelper.doConcat(StringConcatHelper.java:434)
>      at java.base/java.lang.String.concat(String.java:2977)
>
> On JDK 23 it results in expected OOM:
>
> Exception in thread "main" java.lang.OutOfMemoryError: Overflow:
> String length out of range
>      at java.base/java.lang.StringConcatHelper.checkOverflow(StringConcatHelper.java:66)
>      at java.base/java.lang.StringConcatHelper.mix(StringConcatHelper.java:125)
>      at java.base/java.lang.StringConcatHelper.simpleConcat(StringConcatHelper.java:374)
>      at java.base/java.lang.String.concat(String.java:2990)
>
> Andrey Turbanov


From jpai at openjdk.org  Mon May  5 08:18:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 May 2025 08:18:46 GMT
Subject: RFR: 8356126: Revisit CaptureCallState [v4]
In-Reply-To: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com>
Message-ID: <uLQ9stJ_vYOCsQv0-aUg0lNyaEaBbql5Wjd8ueTtAmI=.c19e3ba5-4e93-4ab5-8c76-54dedbdfd756@github.com>

On Mon, 5 May 2025 04:50:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
>> 
>> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
>> 
>> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
>> 
>> Testing: jdk/lang/foreign, tier 1-3 in progress.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No env to test

src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 139:

> 137:      */
> 138:     private static OperatingSystem initOS() {
> 139:         // Called lazily, valueOf has overhead

Hello Chen, in context of this bug fix, what kind of overhead does `valueOf()` have?
The (pre-existing) comment on this `initOS()` method sets an expectation that it will be called from the static initializer of this `OperatingSystem` class and thus it expects an `ExceptionInInitializerError` to be thrown by the static initiliazer, if the operating system name isn't recognized. Any access to `OperatingSystem` class would then have resulted in a `NoClassDefFoundError`. With this proposed change, the callers of `OperatingSystem.current()` would now start seeing an `IllegalArgumentException` if for any reason the operating system name isn't recognized.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2073026614

From jpai at openjdk.org  Mon May  5 08:22:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 May 2025 08:22:48 GMT
Subject: RFR: 8356126: Revisit CaptureCallState [v4]
In-Reply-To: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com>
Message-ID: <Ep5iVF0ydvJjaKJriVKOlYKE5NrF7Hf5zEhwzrRRP1o=.2dcc185a-631d-4783-a4cd-78d7fca93260@github.com>

On Mon, 5 May 2025 04:50:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
>> 
>> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
>> 
>> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
>> 
>> Testing: jdk/lang/foreign, tier 1-3 in progress.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No env to test

On a general note, I think the title of the JBS issue needs to better state what this change is about. From what I understand, this is a bug fix which addresses an issue in `jdk.internal.foreign.abi.LinkerOptions.capturedCallState()` method where it could have returned an incorrect value. I think the issue type also should be changed to Bug instead of Sub-task.

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

PR Comment: https://git.openjdk.org/jdk/pull/25025#issuecomment-2850249386

From duke at openjdk.org  Mon May  5 08:25:29 2025
From: duke at openjdk.org (Stefan Lobbenmeier)
Date: Mon, 5 May 2025 08:25:29 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps
Message-ID: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>

The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space

You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372

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

Commit messages:
 - Use the same syntax as for --mac-dmg-content
 - Correct documentation for --linux-package-deps

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

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

From duke at openjdk.org  Mon May  5 08:25:29 2025
From: duke at openjdk.org (Stefan Lobbenmeier)
Date: Mon, 5 May 2025 08:25:29 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps
In-Reply-To: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
Message-ID: <c8qdmIxTkfLz5Z78qQJ4yeGa_YOL628EeHQD4Li1jWs=.752cf5af-26e3-4cf6-bbf1-6cdc5f326e1b@github.com>

On Fri, 14 Feb 2025 15:01:35 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space
> 
> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372

See also https://github.com/JetBrains/compose-multiplatform/pull/5227 for a discussion if this option has an argument

Just gonna try /signed again, but I didn?t get any more information from oracle

a new comment
I guess the action also suggests that i should first create a Jira issue

Cannot do that, but I could create a but to oracle jdk so I used that review id

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

PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2659596573
PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2725595104
PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2844799049
PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2844822926

From duke at openjdk.org  Mon May  5 08:28:56 2025
From: duke at openjdk.org (Christoph)
Date: Mon, 5 May 2025 08:28:56 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
Message-ID: <DW7nB7Q5xwdMhha3XBrtbh6QLJmx4QVJGfXVxzI_7OY=.6010dd2f-a761-4bc0-b6f0-b79d63e30a96@github.com>

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
> - This change is for macOS only.
> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

Thanks all for your support, with a single app-content parameter and the resource directory this worked with codesign and  even notarization worked on both macOS13 and macOS14 (arm) 
It would be great if you document this in the manual/help

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2850262585

From jwaters at openjdk.org  Mon May  5 09:20:45 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 May 2025 09:20:45 GMT
Subject: RFR: 8355573: Remove kludge_c++11.h from jpackage code
In-Reply-To: <ABRXOAFnthURb4yuEcE4Ex-2Vz28YrnyXp6a3iFX0os=.96006b49-051d-4eda-9c29-7e3b34f0e3cb@github.com>
References: <ABRXOAFnthURb4yuEcE4Ex-2Vz28YrnyXp6a3iFX0os=.96006b49-051d-4eda-9c29-7e3b34f0e3cb@github.com>
Message-ID: <cuRlMfxyRi2mcHkyb9c-ADDkum91hcX7cRkFe7ED_b4=.90678c98-9c5c-4b35-a6e8-e1f891c467ad@github.com>

On Fri, 25 Apr 2025 06:14:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> kludge_c++11.h was introduced to work around older C++ versions not having access to C++ utilities like std::unique_ptr. Since we are already on C++14 (And hopefully will get C++17 soon) this workaround can be removed from jpackage code.

Ping

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

PR Comment: https://git.openjdk.org/jdk/pull/24868#issuecomment-2850392890

From yzheng at openjdk.org  Mon May  5 09:42:47 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Mon, 5 May 2025 09:42:47 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v4]
In-Reply-To: <QxFySn5mkqhFHBY2Px5kmxuMX2l1DNR6vgBaqSBbzH0=.d94d9b13-54af-41d3-a668-fc0c3795b99d@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <QxFySn5mkqhFHBY2Px5kmxuMX2l1DNR6vgBaqSBbzH0=.d94d9b13-54af-41d3-a668-fc0c3795b99d@github.com>
Message-ID: <nFPBY8CGBTjDDuaRzSFXA1daX0DWp3dF7QXSZuOfSnE=.91545dc2-fec4-4a01-8d34-52e3e0efec98@github.com>

On Fri, 2 May 2025 19:44:31 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes to test

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 669:

> 667: 
> 668:     public boolean isValueBased() {
> 669:         return (tsym.flags_field & VALUE_BASED) != 0;

We have encountered a NPE in javac:

  java.lang.NullPointerException: Cannot read field "flags_field" because "this.tsym" is null
  	at jdk.compiler/com.sun.tools.javac.code.Type.isValueBased(Type.java:669)
  	at jdk.compiler/com.sun.tools.javac.comp.Check.checkRequiresIdentity(Check.java:5739)
  	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitNewClass(Attr.java:2918)
  	at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1915)
...

It looks like `tsym` can be null https://github.com/openjdk/jdk/blob/60f1f53b18d065f110936e71b7430d7e365881d4/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java#L517-L519

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2073144717

From jpai at openjdk.org  Mon May  5 10:34:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 May 2025 10:34:48 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v8]
In-Reply-To: <-ljVhLq1eqiX7jZaQ_k4IBTLAu1iDbrTLljF8_wdq2Y=.300f3c0d-58a1-40af-9e21-e31afa1ade12@github.com>
References: <d-bbTH1lsG4Ev7_sNutKMbLBTXXyQ75ZQTbNvgJkqBQ=.06f597ba-1313-4bb4-9947-880e73acd5bf@github.com>
 <fHBCE8kw7jUn9gc4R0o8v0PQbsCYWTvxkNJpGji7744=.a77cb139-35b4-492f-83a2-bb5a28eac32d@github.com>
 <-ljVhLq1eqiX7jZaQ_k4IBTLAu1iDbrTLljF8_wdq2Y=.300f3c0d-58a1-40af-9e21-e31afa1ade12@github.com>
Message-ID: <vfv95ucHtdRjIXlIVtGzzQO3LAH9Fl49BWXBVxfiEEg=.711ff1f5-87e8-4330-ac7d-b5f0cd9ce8c8@github.com>

On Fri, 2 May 2025 19:06:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Lance's review - update code comment in the test
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1240:
> 
>> 1238:                 entries[index] = hash;
>> 1239:                 entries[index + 1] = next;
>> 1240:                 entries[index + 2] = pos;
> 
> Suggestion:
> 
>                 entries[index    ] = hash;
>                 entries[index + 1] = next;
>                 entries[index + 2] = pos;
> 
> Aligned code is more readable

Hello Shaojin, leaving one or more spaces before a closing `]` bracket of array access contradicts the style that I've seen used often in the code. At least it's not a common style used in this area of the code in the JDK.

I think it's fine in the current form and changing it to align with subsequent lines isn't necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2073207272

From eirbjo at openjdk.org  Mon May  5 10:51:48 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 5 May 2025 10:51:48 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v8]
In-Reply-To: <fHBCE8kw7jUn9gc4R0o8v0PQbsCYWTvxkNJpGji7744=.a77cb139-35b4-492f-83a2-bb5a28eac32d@github.com>
References: <d-bbTH1lsG4Ev7_sNutKMbLBTXXyQ75ZQTbNvgJkqBQ=.06f597ba-1313-4bb4-9947-880e73acd5bf@github.com>
 <fHBCE8kw7jUn9gc4R0o8v0PQbsCYWTvxkNJpGji7744=.a77cb139-35b4-492f-83a2-bb5a28eac32d@github.com>
Message-ID: <nsbRogKURNsbGW9qaxv0Cc6DoRCM70diVvRq4u_VL0s=.990b2b90-c1bd-44eb-ad4b-4108dd1973d8@github.com>

On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
>> 
>> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
>> 
>> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
>> 
>> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's review - update code comment in the test

Great work, I have no further input.

Reviewing this part of ZipFile reminds me that this codes begs for some refactoring. Neither the RandomAccessFile nor the CEN bytes change between different charsets so I believe there may be potential for some untangling and simplification here.

 But that?s for another PR :)

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

Marked as reviewed by eirbjo (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23986#pullrequestreview-2814432670

From lancea at openjdk.org  Mon May  5 11:05:49 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 5 May 2025 11:05:49 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v8]
In-Reply-To: <fHBCE8kw7jUn9gc4R0o8v0PQbsCYWTvxkNJpGji7744=.a77cb139-35b4-492f-83a2-bb5a28eac32d@github.com>
References: <d-bbTH1lsG4Ev7_sNutKMbLBTXXyQ75ZQTbNvgJkqBQ=.06f597ba-1313-4bb4-9947-880e73acd5bf@github.com>
 <fHBCE8kw7jUn9gc4R0o8v0PQbsCYWTvxkNJpGji7744=.a77cb139-35b4-492f-83a2-bb5a28eac32d@github.com>
Message-ID: <Iona280KOiHUcI1g_Q7G1_N3MrY5R9BXoO4jiRFAJcM=.8f307290-51fb-4992-afec-dbc7f87c864c@github.com>

On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
>> 
>> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
>> 
>> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
>> 
>> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's review - update code comment in the test

Thank you for the efforts on this Jai.

The changes look good

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23986#pullrequestreview-2814459946

From rehn at openjdk.org  Mon May  5 11:46:55 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 5 May 2025 11:46:55 GMT
Subject: Integrated: 8352730: RISC-V: Disable tests in qemu-user
In-Reply-To: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
References: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
Message-ID: <csvX_w1hA9B3MIjrHyD57vRuUuQpv2RUz0zw9gs3xNM=.3a9cfd13-641e-4679-82da-f473093e5bca@github.com>

On Tue, 25 Mar 2025 14:19:55 GMT, Robbin Ehn <rehn at openjdk.org> 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

This pull request has now been integrated.

Changeset: 02647976
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/026479767c011227b63e7fdb8a38f61977782249
Stats:     71 lines in 64 files changed: 71 ins; 0 del; 0 mod

8352730: RISC-V: Disable tests in qemu-user

Reviewed-by: fyang, mli

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

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

From rgiulietti at openjdk.org  Mon May  5 13:13:39 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 5 May 2025 13:13:39 GMT
Subject: RFR: 8356152: String.concat can throw StringIndexOutOfBoundsException
Message-ID: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>

A fix to throw `OutOfMemoryError`, as done in releases ? 23.

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

Commit messages:
 - 8356152: String.concat can throw StringIndexOutOfBoundsException

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

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

From rgiulietti at openjdk.org  Mon May  5 13:36:05 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 5 May 2025 13:36:05 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v2]
In-Reply-To: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
Message-ID: <xhplqB8y9DcWjx369b8jE8qIuFMqLmosoFQvVPCITFk=.0948f104-6c11-4c84-ae4c-3b11ac61964f@github.com>

> A fix to throw `OutOfMemoryError`, as done in releases ? 23.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Simplified test slightly.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25038/files
  - new: https://git.openjdk.org/jdk/pull/25038/files/a70ccd20..900a0b8d

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

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

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

From liach at openjdk.org  Mon May  5 13:41:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 May 2025 13:41:47 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v2]
In-Reply-To: <xhplqB8y9DcWjx369b8jE8qIuFMqLmosoFQvVPCITFk=.0948f104-6c11-4c84-ae4c-3b11ac61964f@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
 <xhplqB8y9DcWjx369b8jE8qIuFMqLmosoFQvVPCITFk=.0948f104-6c11-4c84-ae4c-3b11ac61964f@github.com>
Message-ID: <YzYOxuFOI7xKUH3sDSpmXDOU5q3V21OFWiv3gJQuubY=.9f1471c4-79eb-4845-ae66-e941dfdc2659@github.com>

On Mon, 5 May 2025 13:36:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> A fix to throw `OutOfMemoryError`, as done in releases ? 23.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified test slightly.

Looks good. So the problem was when `s1.length() + s2.length()` overflows to be negative, `<< coder` can make it positive and bypass the check in `newLength` - a weird scenario indeed.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25038#pullrequestreview-2814854242

From jpai at openjdk.org  Mon May  5 13:53:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 May 2025 13:53:48 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v2]
In-Reply-To: <xhplqB8y9DcWjx369b8jE8qIuFMqLmosoFQvVPCITFk=.0948f104-6c11-4c84-ae4c-3b11ac61964f@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
 <xhplqB8y9DcWjx369b8jE8qIuFMqLmosoFQvVPCITFk=.0948f104-6c11-4c84-ae4c-3b11ac61964f@github.com>
Message-ID: <ytDNjDRCMZSs9WMLok0HE19C7jioBYi0nm-jiCZXOcM=.e01b9cf6-ba09-4d0a-92a4-f1cf4e8a82a9@github.com>

On Mon, 5 May 2025 13:36:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> A fix to throw `OutOfMemoryError`, as done in releases ? 23.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified test slightly.

test/jdk/java/lang/String/concat/HugeConcatTest.java line 29:

> 27:  * @summary Check that huge concatenations throw OutOfMemoryError
> 28:  * @run junit/othervm -Xmx6G -XX:+CompactStrings -Dcompact=true HugeConcatTest
> 29:  * @run junit/othervm -Xmx6G -XX:-CompactStrings -Dcompact=false HugeConcatTest

Hello Raffaello, some other tests that require such large heap sizes use a: 

`@requires os.maxMemory > 6G` 

to prevent failure to launch `java`. I think we should add it here too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2073491401

From asemenyuk at openjdk.org  Mon May  5 14:01:57 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 5 May 2025 14:01:57 GMT
Subject: RFR: 8355573: Remove kludge_c++11.h from jpackage code
In-Reply-To: <ABRXOAFnthURb4yuEcE4Ex-2Vz28YrnyXp6a3iFX0os=.96006b49-051d-4eda-9c29-7e3b34f0e3cb@github.com>
References: <ABRXOAFnthURb4yuEcE4Ex-2Vz28YrnyXp6a3iFX0os=.96006b49-051d-4eda-9c29-7e3b34f0e3cb@github.com>
Message-ID: <309qivCCj1axCGqcU_y57X27CX4KNZj71CYYjwuAsxo=.b0833f4f-1f29-43c7-a536-a952f45b3022@github.com>

On Fri, 25 Apr 2025 06:14:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> kludge_c++11.h was introduced to work around older C++ versions not having access to C++ utilities like std::unique_ptr. Since we are already on C++14 (And hopefully will get C++17 soon) this workaround can be removed from jpackage code.

Marked as reviewed by asemenyuk (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24868#pullrequestreview-2814913682

From rgiulietti at openjdk.org  Mon May  5 14:06:27 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 5 May 2025 14:06:27 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v3]
In-Reply-To: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
Message-ID: <hz3LKiJgfk4YlXZB-hfjfXryO4vlSUlYu3g20a6w8l8=.8e71971d-7a99-4bb6-a86f-6e92159d6f61@github.com>

> A fix to throw `OutOfMemoryError`, as done in releases ? 23.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Added '@requires' to test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25038/files
  - new: https://git.openjdk.org/jdk/pull/25038/files/900a0b8d..1207556c

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

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

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

From rgiulietti at openjdk.org  Mon May  5 14:06:27 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 5 May 2025 14:06:27 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v2]
In-Reply-To: <ytDNjDRCMZSs9WMLok0HE19C7jioBYi0nm-jiCZXOcM=.e01b9cf6-ba09-4d0a-92a4-f1cf4e8a82a9@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
 <xhplqB8y9DcWjx369b8jE8qIuFMqLmosoFQvVPCITFk=.0948f104-6c11-4c84-ae4c-3b11ac61964f@github.com>
 <ytDNjDRCMZSs9WMLok0HE19C7jioBYi0nm-jiCZXOcM=.e01b9cf6-ba09-4d0a-92a4-f1cf4e8a82a9@github.com>
Message-ID: <gZ18ktYBz54QpJFV6uNzi0ETECpn56GmRff8KtUv83Y=.e09d20be-7d20-41f3-ac0b-9216309b4210@github.com>

On Mon, 5 May 2025 13:51:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplified test slightly.
>
> test/jdk/java/lang/String/concat/HugeConcatTest.java line 29:
> 
>> 27:  * @summary Check that huge concatenations throw OutOfMemoryError
>> 28:  * @run junit/othervm -Xmx6G -XX:+CompactStrings -Dcompact=true HugeConcatTest
>> 29:  * @run junit/othervm -Xmx6G -XX:-CompactStrings -Dcompact=false HugeConcatTest
> 
> Hello Raffaello, some other tests that require such large heap sizes use a: 
> 
> `@requires os.maxMemory > 6G` 
> 
> to prevent failure to launch `java`. I think we should add it here too.

Thanks Jai

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2073512927

From aturbanov at openjdk.org  Mon May  5 14:25:46 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 May 2025 14:25:46 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v3]
In-Reply-To: <hz3LKiJgfk4YlXZB-hfjfXryO4vlSUlYu3g20a6w8l8=.8e71971d-7a99-4bb6-a86f-6e92159d6f61@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
 <hz3LKiJgfk4YlXZB-hfjfXryO4vlSUlYu3g20a6w8l8=.8e71971d-7a99-4bb6-a86f-6e92159d6f61@github.com>
Message-ID: <m36EHrzT599elFMCSOBAtEB0Ccc_IzPK_mmxkczl1I4=.99099d9d-cc5f-4240-a8ef-f77b118f4055@github.com>

On Mon, 5 May 2025 14:06:27 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> A fix to throw `OutOfMemoryError`, as done in releases ? 23.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added '@requires' to test.

test/jdk/java/lang/String/concat/HugeConcatTest.java line 38:

> 36: import static org.junit.Assert.assertThrows;
> 37: 
> 38: public class HugeConcatTest {

The same issue is reproduced with simple `+` concatenation.

        String r1 = "-".repeat(Integer.MAX_VALUE - 10);
        String r2 = "?".repeat((Integer.MAX_VALUE - 10)  / 2);
        System.out.println(r1 + r2);

I think it makes sense to add related test for it too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2073551759

From rgiulietti at openjdk.org  Mon May  5 14:38:05 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 5 May 2025 14:38:05 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v4]
In-Reply-To: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
Message-ID: <YlGNjEj8PXyiI3uAMm0blRZISm_-l1X-1j0dIS5_Da4=.ef4d17bc-d04d-494e-bb2e-f1917a2c6a35@github.com>

> A fix to throw `OutOfMemoryError`, as done in releases ? 23.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Added language concat + to test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25038/files
  - new: https://git.openjdk.org/jdk/pull/25038/files/1207556c..f0c75b95

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

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

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

From rgiulietti at openjdk.org  Mon May  5 14:38:06 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 5 May 2025 14:38:06 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v3]
In-Reply-To: <m36EHrzT599elFMCSOBAtEB0Ccc_IzPK_mmxkczl1I4=.99099d9d-cc5f-4240-a8ef-f77b118f4055@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
 <hz3LKiJgfk4YlXZB-hfjfXryO4vlSUlYu3g20a6w8l8=.8e71971d-7a99-4bb6-a86f-6e92159d6f61@github.com>
 <m36EHrzT599elFMCSOBAtEB0Ccc_IzPK_mmxkczl1I4=.99099d9d-cc5f-4240-a8ef-f77b118f4055@github.com>
Message-ID: <bC82we8BssvEakwczxh2ykg7gEZNUmbkKs1YZClQNnc=.a085b336-cdc2-44b7-831f-5eb5adff02b5@github.com>

On Mon, 5 May 2025 14:23:11 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added '@requires' to test.
>
> test/jdk/java/lang/String/concat/HugeConcatTest.java line 38:
> 
>> 36: import static org.junit.Assert.assertThrows;
>> 37: 
>> 38: public class HugeConcatTest {
> 
> The same issue is reproduced with simple `+` concatenation.
> 
>         String r1 = "-".repeat(Integer.MAX_VALUE - 10);
>         String r2 = "?".repeat((Integer.MAX_VALUE - 10)  / 2);
>         System.out.println(r1 + r2);
> 
> I think it makes sense to add related test for it too.

@turbanoff I addressed your note.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2073576074

From vromero at openjdk.org  Mon May  5 14:46:48 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 5 May 2025 14:46:48 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v4]
In-Reply-To: <nFPBY8CGBTjDDuaRzSFXA1daX0DWp3dF7QXSZuOfSnE=.91545dc2-fec4-4a01-8d34-52e3e0efec98@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <QxFySn5mkqhFHBY2Px5kmxuMX2l1DNR6vgBaqSBbzH0=.d94d9b13-54af-41d3-a668-fc0c3795b99d@github.com>
 <nFPBY8CGBTjDDuaRzSFXA1daX0DWp3dF7QXSZuOfSnE=.91545dc2-fec4-4a01-8d34-52e3e0efec98@github.com>
Message-ID: <K31uA3N1-P6fLQbarJUBGqc7kPuH5SH7tnRGv--DQB0=.f6b3ff09-5efe-447a-a06f-2ff8a829a8a4@github.com>

On Mon, 5 May 2025 09:40:16 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changes to test
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 669:
> 
>> 667: 
>> 668:     public boolean isValueBased() {
>> 669:         return (tsym.flags_field & VALUE_BASED) != 0;
> 
> We have encountered a NPE in javac:
> 
>   java.lang.NullPointerException: Cannot read field "flags_field" because "this.tsym" is null
>   	at jdk.compiler/com.sun.tools.javac.code.Type.isValueBased(Type.java:669)
>   	at jdk.compiler/com.sun.tools.javac.comp.Check.checkRequiresIdentity(Check.java:5739)
>   	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitNewClass(Attr.java:2918)
>   	at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1915)
> ...
> 
> It looks like `tsym` can be null https://github.com/openjdk/jdk/blob/60f1f53b18d065f110936e71b7430d7e365881d4/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java#L517-L519

thanks for the report I will update the PR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2073595845

From liach at openjdk.org  Mon May  5 15:05:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 May 2025 15:05:48 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v3]
In-Reply-To: <QpnbZKc7ef8pJuC17i0V5VOJWcdHrBFzJfFxFmx-7P0=.689ad7c0-fbde-499c-b06d-907a8a98b36a@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <QpnbZKc7ef8pJuC17i0V5VOJWcdHrBFzJfFxFmx-7P0=.689ad7c0-fbde-499c-b06d-907a8a98b36a@github.com>
Message-ID: <ganNVCbMRb4xiIenGJnPtWxoe-pbqSbrWfpXhfZn13E=.f6df06a6-cd02-4606-acf2-5a56214e8fa8@github.com>

On Fri, 2 May 2025 17:24:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize StringUTF16.putCharsAt a bit.
>   Fixup hotspot Helper of putCharsAt to remove return value to match StringUTF16.putCharsAt.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1856:

> 1854: 
> 1855:     // Package access for String and StringBuffer.
> 1856:     final boolean isLatin1() {

I recommend inlining the Stirng usage of this method too like for all other sites in ASB. Then this is only used by serialization of StringBuffer/Builder, and arguably those can move to use the plain version too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2073607977

From ihse at openjdk.org  Mon May  5 15:08:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 May 2025 15:08:52 GMT
Subject: RFR: 8355249: Remove the use of WMIC from the entire source code
 [v2]
In-Reply-To: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
References: <blL6FOj7XD1T3u_ODIwYPIPDXEowzSR0w5j92nC9gCo=.8a2428d9-1795-4dd0-91fd-8b604c7cc100@github.com>
 <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
Message-ID: <7unkKqs4wV5Iy9XF-iKuz0PU9VNXMyWS740Gn93H8B0=.d0c238fc-8ca3-42ad-a7a8-b43af17f1cb2@github.com>

On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata <duke at openjdk.org> wrote:

>> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI.
>> 
>> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency.
>> 
>> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file.
>> Note: In my environment, it worked correctly even without these options.
>> 
>> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in:
>> 
>> - `environment.html`: `windows/system/os` section
>> - `process.html`: `[Process ID]/windows/native/info` section
>> 
>> **Testing:**
>> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes.
>
> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   run jcheck

Build changes look good.

@ alexeysemenyukoracle Can you review the jpackage test change?

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24791#pullrequestreview-2815147219

From liach at openjdk.org  Mon May  5 15:55:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 May 2025 15:55:51 GMT
Subject: RFR: 8356126: Revisit CaptureCallState [v4]
In-Reply-To: <Upg_aXZZ8a79L02cDTx2l_HP4PGRDm9fMyzJDxpq7t4=.b9a4c763-d10d-47d9-b8b4-8ab25776c018@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com>
 <Upg_aXZZ8a79L02cDTx2l_HP4PGRDm9fMyzJDxpq7t4=.b9a4c763-d10d-47d9-b8b4-8ab25776c018@github.com>
Message-ID: <UzgHIFB9GA36elx53Sv7ovzofitACng5vgNARVRv3cc=.8c9f0d7a-e82e-46cd-b0f9-6375cb6384d0@github.com>

On Mon, 5 May 2025 05:31:33 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   No env to test
>
> src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 96:
> 
>> 94:     public static String displayString(int mask) {
>> 95:         var displayList = new ArrayList<>();
>> 96:         for (var e : LOOKUP.values()) {
> 
> Suggestion:
> 
>         for (var e : SUPPORTED) {

Good point, however this is display only. To fix this I should add a comment to displayList.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2073708594

From liach at openjdk.org  Mon May  5 15:55:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 May 2025 15:55:52 GMT
Subject: RFR: 8356126: Revisit CaptureCallState [v4]
In-Reply-To: <uLQ9stJ_vYOCsQv0-aUg0lNyaEaBbql5Wjd8ueTtAmI=.c19e3ba5-4e93-4ab5-8c76-54dedbdfd756@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com>
 <uLQ9stJ_vYOCsQv0-aUg0lNyaEaBbql5Wjd8ueTtAmI=.c19e3ba5-4e93-4ab5-8c76-54dedbdfd756@github.com>
Message-ID: <R0Z0V9chwQzLGtDUS72ouLffcUSv4dRBzk04ykFJT_8=.de0158e4-9892-4d47-abc0-f2c3540e927c@github.com>

On Mon, 5 May 2025 08:16:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   No env to test
>
> src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 139:
> 
>> 137:      */
>> 138:     private static OperatingSystem initOS() {
>> 139:         // Called lazily, valueOf has overhead
> 
> Hello Chen, in context of this bug fix, what kind of overhead does `valueOf()` have?
> The (pre-existing) comment on this `initOS()` method sets an expectation that it will be called from the static initializer of this `OperatingSystem` class and thus it expects an `ExceptionInInitializerError` to be thrown by the static initiliazer, if the operating system name isn't recognized. Any access to `OperatingSystem` class would then have resulted in a `NoClassDefFoundError`. With this proposed change, the callers of `OperatingSystem.current()` would now start seeing an `IllegalArgumentException` if for any reason the operating system name isn't recognized.

Enum.valueOf -> Class.enumConstantDirectory -> Class.getEnumConstantsShared -> Method.invoke -> MethodHandleAccessorFactory.makeSpecializedTarget(isStatic = true) -> MethodHandles.dropArguments -> LambdaForm.editor -> bytecode generation and loading because this currently cannot be pregenerated by CDS archive.

If this class is broken, this would probably already surface at build time because this is used by jlink; otherwise it would have surfaced in Process tests. I don't think ensuring EIIE vs IAE is worth a test here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2073707472

From liach at openjdk.org  Mon May  5 16:11:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 May 2025 16:11:23 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v5]
In-Reply-To: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <_YoWvD7qNQzOVYH7nGma3s_D1k8Blh3D-AyUOqY7DxQ=.d7012548-d463-45aa-be82-5de8d89b2cb1@github.com>

> Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version.

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/preview-cffv
 - Update src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java
 - Update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
   
   Co-authored-by: Luca Kellermann <lukellmann at gmail.com>
 - Don't need to update latestSupported later
   
 - Merge branch 'pr/25015' of https://github.com/openjdk/jdk into feature/preview-cffv
 - JDK-8356108: Update SourceVersion.RELEASE_25 description for JEPs 511 and 512
 - Add advanced testing for different latestSupported
   
 - 8355536: Create version constants to model preview language and vm features

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

Changes: https://git.openjdk.org/jdk/pull/25017/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=04
  Stats: 1265 lines in 6 files changed: 1123 ins; 83 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/25017.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25017/head:pull/25017

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

From kvn at openjdk.org  Mon May  5 16:21:46 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 5 May 2025 16:21:46 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v3]
In-Reply-To: <ZqN7me24ilvFxqQs47wNdM6lhli5RuQXWKP4fwRI4No=.4fae3be6-ceb5-4de2-b129-1fde746c0760@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <ZqN7me24ilvFxqQs47wNdM6lhli5RuQXWKP4fwRI4No=.4fae3be6-ceb5-4de2-b129-1fde746c0760@github.com>
Message-ID: <7xQPMF73IAIbB7vGPS8ipjIiaimA6O4Jmm8XqqMgN4I=.f6084b06-65d6-453e-a8c6-f455ccc7a15a@github.com>

On Mon, 5 May 2025 01:00:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>> 
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
>> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
>> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
>> 
>> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
>> 
>> Examples:
>> 
>> 
>> # Create an AOT cache with a single command:
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> Hello World
>> Temporary AOTConfiguration recorded: foo.aot.config
>> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
>> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
>> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
>> AOTCache creation is complete: foo.aot 10240000 bytes
>> 
>> # Create logging file for the AOT cache assembly phase
>> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> 
>> 
>> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @vnkozlov comments

src/hotspot/share/cds/metaspaceShared.cpp line 1018:

> 1016:     CDSConfig::disable_dumping_aot_code();
> 1017:   }
> 1018: 

Is this from merge form mainline?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2073756831

From kvn at openjdk.org  Mon May  5 16:24:48 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 5 May 2025 16:24:48 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v3]
In-Reply-To: <ZqN7me24ilvFxqQs47wNdM6lhli5RuQXWKP4fwRI4No=.4fae3be6-ceb5-4de2-b129-1fde746c0760@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <ZqN7me24ilvFxqQs47wNdM6lhli5RuQXWKP4fwRI4No=.4fae3be6-ceb5-4de2-b129-1fde746c0760@github.com>
Message-ID: <ZuUJNLAVEybgdSqtFNnd109unHgX6jnx0Cht8Ta1pME=.99006b9f-e401-4afe-962a-e0d0778d9bb3@github.com>

On Mon, 5 May 2025 01:00:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>> 
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
>> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
>> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
>> 
>> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
>> 
>> Examples:
>> 
>> 
>> # Create an AOT cache with a single command:
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> Hello World
>> Temporary AOTConfiguration recorded: foo.aot.config
>> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
>> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
>> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
>> AOTCache creation is complete: foo.aot 10240000 bytes
>> 
>> # Create logging file for the AOT cache assembly phase
>> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> 
>> 
>> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @vnkozlov comments

src/hotspot/share/cds/cdsConfig.cpp line 412:

> 410:     log_debug(aot,codecache,init)("AOTCache is not specified - AOTAdapterCaching is ignored");
> 411:   }
> 412: 

Also from merge?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2073760775

From vromero at openjdk.org  Mon May  5 16:30:27 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 5 May 2025 16:30:27 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v5]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <hlQ_wxPVmRXC8jrCMazw0CCVRT2WcED6XzcXe3A2shc=.0633f497-b8fa-4372-9536-acff1794a322@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/60f1f53b..ad7f617d

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

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

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

From liach at openjdk.org  Mon May  5 16:44:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 May 2025 16:44:02 GMT
Subject: RFR: 8356126: Duplicaton handling and optimization of
 CaptureCallState [v5]
In-Reply-To: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
Message-ID: <jdZkdPn3QI3c-QklFui6Aj7hXcn0pPrV7kMQ0w4tEQ0=.37ea8bef-fa3f-440f-875c-6450539517a0@github.com>

> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
> 
> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
> 
> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
> 
> Testing: jdk/lang/foreign, tier 1-3 in progress.

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/25025/files
  - new: https://git.openjdk.org/jdk/pull/25025/files/806d307b..d1598afa

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

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

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

From liach at openjdk.org  Mon May  5 16:44:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 May 2025 16:44:02 GMT
Subject: RFR: 8356126: Duplicaton handling and optimization of
 CaptureCallState [v4]
In-Reply-To: <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com>
Message-ID: <Aoz-xHABFwzdwec4XTbqRdHrFkUhNwGMyuZ62QJjUk4=.9265689d-1eed-471a-b1f0-ba1c01817713@github.com>

On Mon, 5 May 2025 04:50:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
>> 
>> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
>> 
>> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
>> 
>> Testing: jdk/lang/foreign, tier 1-3 in progress.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No env to test

Thanks for the remarks. I have addressed them; feel free to review again.

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

PR Comment: https://git.openjdk.org/jdk/pull/25025#issuecomment-2851601489

From jlu at openjdk.org  Mon May  5 16:45:51 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 5 May 2025 16:45:51 GMT
Subject: Integrated: 8356040:
 java/util/PluggableLocale/LocaleNameProviderTest.java timed out
In-Reply-To: <ZlNw-uu8c-LYrPGPOzC2ab4YHelGWdKD0mo12m3CFT0=.d43f7119-3594-48aa-90ed-d92c502ee3a5@github.com>
References: <ZlNw-uu8c-LYrPGPOzC2ab4YHelGWdKD0mo12m3CFT0=.d43f7119-3594-48aa-90ed-d92c502ee3a5@github.com>
Message-ID: <k1wJgWgFmKlsGQeZACp3_PbV-u1MA4p55eph99f0xeA=.4ac45fb8-9056-44df-982f-16bbb8a74c3b@github.com>

On Fri, 2 May 2025 15:49:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which reduces the amount of combinations tested by `LocaleNameProviderTest`.
> 
> This test was exhaustively testing over 1000x1000 `Locale` combinations which was expensive and caused a timeout in tier 5. Narrowing down the tested locales to Japanese language ones can reduce our tested input to 9x9 and provides most of the same value the test previously did. (Since our SPI provider has defined preferred Japanese Locale name values.) This change also refactors the test to use JUnit. The test now runs around ~20 times faster.
> 
> Most of the diff is attributed to separating the method source from the test itself. But notice the filtering of `Locale`s done on `availloc` and `jreImplLoc`.

This pull request has now been integrated.

Changeset: 32f67a3e
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/32f67a3e38be807164435ea0841c01d2b7c73652
Stats:     133 lines in 1 file changed: 64 ins; 48 del; 21 mod

8356040: java/util/PluggableLocale/LocaleNameProviderTest.java timed out

Reviewed-by: naoto

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

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

From pminborg at openjdk.org  Mon May  5 16:53:56 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 5 May 2025 16:53:56 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v6]
In-Reply-To: <VLMTeth8BlsUkI2QlekrFz-MIVdp5KbYw2p6kZFQf14=.ae897519-3b5c-4d72-b58e-e5c86655d78a@github.com>
References: <QHEUF-Wlk-NBSpBXX6BEbXy1vN_HNlYkvY0lqzoN6ww=.848bb36e-c272-4926-aa37-f66c68e9135f@github.com>
 <VLMTeth8BlsUkI2QlekrFz-MIVdp5KbYw2p6kZFQf14=.ae897519-3b5c-4d72-b58e-e5c86655d78a@github.com>
Message-ID: <CM-dR6SUOzIwNwGRl4kk7Hc3hYaRGBo4B7ajzLn0JIM=.31d6c3f3-dd6f-41e2-8fb8-a3d1d414b5e4@github.com>

On Tue, 29 Apr 2025 12:33:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>> 
>> 
>> Here are some benchmarks that ran on a platform thread and virtual threads respectively (M1 Mac):
>> 
>> 
>> Benchmark                                                  Mode  Cnt   Score   Error  Units
>> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.330 ? 0.820  ns/op
>> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.257 ? 0.117  ns/op
>> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  41.415 ? 1.013  ns/op
>> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.720 ? 0.463  ns/op
>> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.636 ? 0.182  ns/op
>> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.234 ? 0.156  ns/op
>> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.918 ? 0.487  ns/op
>> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   4.946 ? 0.089  ns/op
>> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.280 ? 1.128  ns/op
>> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  21.809 ? 0.413  ns/op
>> CaptureStateUtilBench.tlAllocationFail                     avgt   30  24.422 ? 0.673  ns/op
>> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   5.182 ? 0.152  ns/op
>> 
>> 
>> Adapted system call:
>> 
>>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
>> ```        
>> Explicit allocation:
>> 
>>         try (var arena = Arena.ofConfined()) {
>>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>>         }
>> ```        
>> Thread Local allocation:
>> 
>>         try (var arena = POOLS.take()) {
>>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>>         }
>> ```        
>> The adapted system call exhibits a ~4x performance improvement ove...
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add hashCode/equals to record to improve startup time

I will close this PR and create a new one against the bug report using the newly integrated `BufferStack` and Stable Values.

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

PR Comment: https://git.openjdk.org/jdk/pull/23765#issuecomment-2851629378

From pminborg at openjdk.org  Mon May  5 16:59:02 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 5 May 2025 16:59:02 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno
Message-ID: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>

As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.

Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.

It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.

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

Commit messages:
 - Use stable values
 - Merge branch 'master' into errno-util3b
 - Add hashCode/equals to record to improve startup time
 - Revert change to ArenaImpl
 - Merge master
 - Merge master
 - Add test for woven allocation
 - Merge branch 'master' into errno-util3
 - Use lazy initialization of method handles
 - Clean up visibility
 - ... and 29 more: https://git.openjdk.org/jdk/compare/1501a5e4...04dc6d3e

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

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

From pminborg at openjdk.org  Mon May  5 17:09:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 5 May 2025 17:09:03 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v2]
In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
Message-ID: <3SdR6_UBmgwF4FYVHVc0NVWtcJP109kPfKCd9m1u6Dk=.a18f4c75-757c-44d5-b0a4-a2078d88c828@github.com>

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Reformat more
 - Reformat

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25043/files
  - new: https://git.openjdk.org/jdk/pull/25043/files/04dc6d3e..29441123

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

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

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

From pminborg at openjdk.org  Mon May  5 17:09:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 5 May 2025 17:09:03 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno
In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
Message-ID: <2XpgMtckMkT6IA6hNlOajEN56B0v8pxSL6pAHRof-pQ=.d76066ce-881d-4fef-b2f4-76a0f19f9c43@github.com>

On Mon, 5 May 2025 16:53:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.

The current benchmarks (M1 macOS):


~/Applications/brr --build --build-microbenchmarks -w CaptureStateUtilBench

Benchmark                                                  Mode  Cnt   Score   Error  Units
CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  34.372 ? 0.221  ns/op
CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30  12.694 ? 0.251  ns/op
CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  40.470 ? 0.529  ns/op
CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.680 ? 0.339  ns/op
CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  31.054 ? 0.575  ns/op
CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   5.029 ? 0.088  ns/op
CaptureStateUtilBench.explicitAllocationFail               avgt   30  40.338 ? 0.586  ns/op
CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  21.769 ? 0.552  ns/op



Passes `tier1` on multiple platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/25043#issuecomment-2851658924

From pminborg at openjdk.org  Mon May  5 17:13:02 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 5 May 2025 17:13:02 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v3]
In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
Message-ID: <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com>

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.

Per Minborg has updated the pull request incrementally with three additional commits since the last revision:

 - Fix empty line at the end of a third file
 - Fix empty line at the end of another file
 - Fix empty line at the end of a file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25043/files
  - new: https://git.openjdk.org/jdk/pull/25043/files/29441123..07a39db9

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

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

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

From aturbanov at openjdk.org  Mon May  5 17:14:47 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 May 2025 17:14:47 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v4]
In-Reply-To: <YlGNjEj8PXyiI3uAMm0blRZISm_-l1X-1j0dIS5_Da4=.ef4d17bc-d04d-494e-bb2e-f1917a2c6a35@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
 <YlGNjEj8PXyiI3uAMm0blRZISm_-l1X-1j0dIS5_Da4=.ef4d17bc-d04d-494e-bb2e-f1917a2c6a35@github.com>
Message-ID: <excMxzdNWB2snNe7Z1cNAoT0wxxVcsX4ozDaTzpWeX4=.c222fe7e-7807-4b8c-90e5-1583ffb8fb82@github.com>

On Mon, 5 May 2025 14:38:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> A fix to throw `OutOfMemoryError`, as done in releases ? 23.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added language concat + to test.

test/jdk/java/lang/String/concat/HugeConcatTest.java line 38:

> 36: import static org.junit.Assert.assertThrows;
> 37: 
> 38: public class HugeConcatTest {

I've tried to execute the test with reverting changes in `StringConcatHelper` - it doesn't fail.
Added logging and actually OOM happened due to heap size:

Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range
Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range
Reall got OOM: java.lang.OutOfMemoryError: Java heap space
Reall got OOM: java.lang.OutOfMemoryError: Java heap space
Reall got OOM: java.lang.OutOfMemoryError: Java heap space
Reall got OOM: java.lang.OutOfMemoryError: Java heap space
Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range
Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range
----------System.err:(13/854)----------
STARTED    HugeConcatTest::testConcat_UTF16_UTF16 'testConcat_UTF16_UTF16()'
SUCCESSFUL HugeConcatTest::testConcat_UTF16_UTF16 'testConcat_UTF16_UTF16()' [9ms]
STARTED    HugeConcatTest::testConcat_Latin1_UTF16 'testConcat_Latin1_UTF16()'
SUCCESSFUL HugeConcatTest::testConcat_Latin1_UTF16 'testConcat_Latin1_UTF16()' [657ms]
STARTED    HugeConcatTest::testConcat_UTF16_Latin1 'testConcat_UTF16_Latin1()'
SUCCESSFUL HugeConcatTest::testConcat_UTF16_Latin1 'testConcat_UTF16_Latin1()' [52ms]
STARTED    HugeConcatTest::testConcat_Latin1_Latin1 'testConcat_Latin1_Latin1()'
SUCCESSFUL HugeConcatTest::testConcat_Latin1_Latin1 'testConcat_Latin1_Latin1()' [1ms]


I think we should validate error message too. Not only fact that it was thrown.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2073833500

From aturbanov at openjdk.org  Mon May  5 17:14:47 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 May 2025 17:14:47 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v4]
In-Reply-To: <excMxzdNWB2snNe7Z1cNAoT0wxxVcsX4ozDaTzpWeX4=.c222fe7e-7807-4b8c-90e5-1583ffb8fb82@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
 <YlGNjEj8PXyiI3uAMm0blRZISm_-l1X-1j0dIS5_Da4=.ef4d17bc-d04d-494e-bb2e-f1917a2c6a35@github.com>
 <excMxzdNWB2snNe7Z1cNAoT0wxxVcsX4ozDaTzpWeX4=.c222fe7e-7807-4b8c-90e5-1583ffb8fb82@github.com>
Message-ID: <w75FLw8GmCXgUOjDNLR6vTbp-rPWxzBLWCrtBgqiodM=.b1355c69-c8c0-423c-b108-67a2b6386eee@github.com>

On Mon, 5 May 2025 17:09:37 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added language concat + to test.
>
> test/jdk/java/lang/String/concat/HugeConcatTest.java line 38:
> 
>> 36: import static org.junit.Assert.assertThrows;
>> 37: 
>> 38: public class HugeConcatTest {
> 
> I've tried to execute the test with reverting changes in `StringConcatHelper` - it doesn't fail.
> Added logging and actually OOM happened due to heap size:
> 
> Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range
> Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range
> Reall got OOM: java.lang.OutOfMemoryError: Java heap space
> Reall got OOM: java.lang.OutOfMemoryError: Java heap space
> Reall got OOM: java.lang.OutOfMemoryError: Java heap space
> Reall got OOM: java.lang.OutOfMemoryError: Java heap space
> Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range
> Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range
> ----------System.err:(13/854)----------
> STARTED    HugeConcatTest::testConcat_UTF16_UTF16 'testConcat_UTF16_UTF16()'
> SUCCESSFUL HugeConcatTest::testConcat_UTF16_UTF16 'testConcat_UTF16_UTF16()' [9ms]
> STARTED    HugeConcatTest::testConcat_Latin1_UTF16 'testConcat_Latin1_UTF16()'
> SUCCESSFUL HugeConcatTest::testConcat_Latin1_UTF16 'testConcat_Latin1_UTF16()' [657ms]
> STARTED    HugeConcatTest::testConcat_UTF16_Latin1 'testConcat_UTF16_Latin1()'
> SUCCESSFUL HugeConcatTest::testConcat_UTF16_Latin1 'testConcat_UTF16_Latin1()' [52ms]
> STARTED    HugeConcatTest::testConcat_Latin1_Latin1 'testConcat_Latin1_Latin1()'
> SUCCESSFUL HugeConcatTest::testConcat_Latin1_Latin1 'testConcat_Latin1_Latin1()' [1ms]
> 
> 
> I think we should validate error message too. Not only fact that it was thrown.

_Really_ fails with Xmx7G

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2073836326

From rriggs at openjdk.org  Mon May  5 17:18:33 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 5 May 2025 17:18:33 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v4]
In-Reply-To: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
Message-ID: <IM8UrwI1zmpxjWKMWJtoah9mWeSvRPQ5F_LTRpwIE9o=.0433b4ee-4cb5-45f9-9d27-cd9647016570@github.com>

> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
> Support methods are static, designed to pass all values as arguments and return a value.
> 
> The value byte array is reallocated under 3 conditions:
> - Increasing the capacity with the same encoder
> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
> - Inflation with the same capacity
> 
> Added StressSBTest to exercise public instance methods of StringBuilder.

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

  Applied suggestion to use StringUTF16.compress in append() for copying char[].
  Added similar improvement to putCharsAt.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24967/files
  - new: https://git.openjdk.org/jdk/pull/24967/files/d2261cd6..ff3d841f

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

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

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

From naoto at openjdk.org  Mon May  5 17:22:45 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 May 2025 17:22:45 GMT
Subject: RFR: 8356096: ISO 4217 Amendment 179 Update
In-Reply-To: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>
References: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>
Message-ID: <TMoKyst2Q91UwdgX-DfV0lLk5cB6RTsQKsjk_PEbM4g=.904b3259-8b16-4a24-b014-cbbe2796162f@github.com>

On Fri, 2 May 2025 20:51:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which implements ISO 4217 update 179.
> 
> The _Arab Accounting Dinar_ currency is added under an _agency_, (not _country_) entity. As a result it is not added as an entry in the country to currency mapping in `currencyData.properties`. It has a numeric code of 396, and minor units of 2 (so it is not added to any of the `minorX` entries in `currencyData.properties`).

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25014#pullrequestreview-2815515425

From rgiulietti at openjdk.org  Mon May  5 17:29:33 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 5 May 2025 17:29:33 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v5]
In-Reply-To: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
Message-ID: <bF_OnxOCbrFO-atOiCBXIJp_JxT2__hFunyZV-aTPs0=.2da5ecfe-81e1-4723-9bab-65aec9c808e2@github.com>

> A fix to throw `OutOfMemoryError`, as done in releases ? 23.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Increased min heap size to 8G.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25038/files
  - new: https://git.openjdk.org/jdk/pull/25038/files/f0c75b95..0ca5b653

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

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

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

From iris at openjdk.org  Mon May  5 17:31:45 2025
From: iris at openjdk.org (Iris Clark)
Date: Mon, 5 May 2025 17:31:45 GMT
Subject: RFR: 8356096: ISO 4217 Amendment 179 Update
In-Reply-To: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>
References: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>
Message-ID: <Ry5_4qxqnprIddsFyz33W34DvHwJ9Q8eCt0JpxdBAps=.10370f86-0a5d-4d46-931b-cb52491d0b8f@github.com>

On Fri, 2 May 2025 20:51:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which implements ISO 4217 update 179.
> 
> The _Arab Accounting Dinar_ currency is added under an _agency_, (not _country_) entity. As a result it is not added as an entry in the country to currency mapping in `currencyData.properties`. It has a numeric code of 396, and minor units of 2 (so it is not added to any of the `minorX` entries in `currencyData.properties`).

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25014#pullrequestreview-2815543817

From rriggs at openjdk.org  Mon May  5 17:32:19 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 5 May 2025 17:32:19 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
Message-ID: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>

> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
> Support methods are static, designed to pass all values as arguments and return a value.
> 
> The value byte array is reallocated under 3 conditions:
> - Increasing the capacity with the same encoder
> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
> - Inflation with the same capacity
> 
> Added StressSBTest to exercise public instance methods of StringBuilder.

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

  Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24967/files
  - new: https://git.openjdk.org/jdk/pull/24967/files/ff3d841f..80992a20

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

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

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

From jpai at openjdk.org  Mon May  5 17:37:47 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 May 2025 17:37:47 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
Message-ID: <HN-weWcqOwwjNEtcpGjn8unVaEgWWGiP7pekQPtHRk0=.16142675-583c-4770-9447-37cb450c2d92@github.com>

On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder.

src/java.base/share/classes/java/lang/StringUTF16.java line 1531:

> 1529:     }
> 1530: 
> 1531:     public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {

Hello Roger, can this (pre-existing) method and the other `putCharsAt` that we are changing here, be changed to package private instead of `public`? As far as I can see, these 2 are only accessed from `java.lang.AbstractStringBuilder` which resides in the same package as this class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2073878460

From liach at openjdk.org  Mon May  5 17:41:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 May 2025 17:41:48 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <HN-weWcqOwwjNEtcpGjn8unVaEgWWGiP7pekQPtHRk0=.16142675-583c-4770-9447-37cb450c2d92@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
 <HN-weWcqOwwjNEtcpGjn8unVaEgWWGiP7pekQPtHRk0=.16142675-583c-4770-9447-37cb450c2d92@github.com>
Message-ID: <bYwTWncj-zjfq0zL59J1d2XfX1uXGq2IYmMow_1RdbM=.d9b273cd-903e-4fe2-98b2-38eb8fc5d4dc@github.com>

On Mon, 5 May 2025 17:34:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder.
>
> src/java.base/share/classes/java/lang/StringUTF16.java line 1531:
> 
>> 1529:     }
>> 1530: 
>> 1531:     public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
> 
> Hello Roger, can this (pre-existing) method and the other `putCharsAt` that we are changing here, be changed to package private instead of `public`? As far as I can see, these 2 are only accessed from `java.lang.AbstractStringBuilder` which resides in the same package as this class.

In fact, `StringUTF16` and `StringLatin1` are both package-private, so technically all their method access modifiers should either be package-private or private.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2073887894

From rgiulietti at openjdk.org  Mon May  5 17:49:47 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 5 May 2025 17:49:47 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v4]
In-Reply-To: <w75FLw8GmCXgUOjDNLR6vTbp-rPWxzBLWCrtBgqiodM=.b1355c69-c8c0-423c-b108-67a2b6386eee@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
 <YlGNjEj8PXyiI3uAMm0blRZISm_-l1X-1j0dIS5_Da4=.ef4d17bc-d04d-494e-bb2e-f1917a2c6a35@github.com>
 <excMxzdNWB2snNe7Z1cNAoT0wxxVcsX4ozDaTzpWeX4=.c222fe7e-7807-4b8c-90e5-1583ffb8fb82@github.com>
 <w75FLw8GmCXgUOjDNLR6vTbp-rPWxzBLWCrtBgqiodM=.b1355c69-c8c0-423c-b108-67a2b6386eee@github.com>
Message-ID: <6vv_RfftsMHItY1Fd1m4WFUraAwfYiNui815ORAQL7k=.4e685520-cfc2-49ac-9808-7ed197941fb7@github.com>

On Mon, 5 May 2025 17:11:46 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> test/jdk/java/lang/String/concat/HugeConcatTest.java line 38:
>> 
>>> 36: import static org.junit.Assert.assertThrows;
>>> 37: 
>>> 38: public class HugeConcatTest {
>> 
>> I've tried to execute the test with reverting changes in `StringConcatHelper` - it doesn't fail.
>> Added logging and actually OOM happened due to heap size:
>> 
>> Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range
>> Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range
>> Reall got OOM: java.lang.OutOfMemoryError: Java heap space
>> Reall got OOM: java.lang.OutOfMemoryError: Java heap space
>> Reall got OOM: java.lang.OutOfMemoryError: Java heap space
>> Reall got OOM: java.lang.OutOfMemoryError: Java heap space
>> Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range
>> Reall got OOM: java.lang.OutOfMemoryError: Overflow: String length out of range
>> ----------System.err:(13/854)----------
>> STARTED    HugeConcatTest::testConcat_UTF16_UTF16 'testConcat_UTF16_UTF16()'
>> SUCCESSFUL HugeConcatTest::testConcat_UTF16_UTF16 'testConcat_UTF16_UTF16()' [9ms]
>> STARTED    HugeConcatTest::testConcat_Latin1_UTF16 'testConcat_Latin1_UTF16()'
>> SUCCESSFUL HugeConcatTest::testConcat_Latin1_UTF16 'testConcat_Latin1_UTF16()' [657ms]
>> STARTED    HugeConcatTest::testConcat_UTF16_Latin1 'testConcat_UTF16_Latin1()'
>> SUCCESSFUL HugeConcatTest::testConcat_UTF16_Latin1 'testConcat_UTF16_Latin1()' [52ms]
>> STARTED    HugeConcatTest::testConcat_Latin1_Latin1 'testConcat_Latin1_Latin1()'
>> SUCCESSFUL HugeConcatTest::testConcat_Latin1_Latin1 'testConcat_Latin1_Latin1()' [1ms]
>> 
>> 
>> I think we should validate error message too. Not only fact that it was thrown.
>
> _Really_ fails with Xmx7G

Yes, the required heap size was not enough for the reverted variant to throw a non-OOME exception/error.

Just out of curiosity, is JDK-8356152 a real-world issue you stumbled upon, or did you encounter it during some testing of yours?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2073899613

From rriggs at openjdk.org  Mon May  5 18:02:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 5 May 2025 18:02:50 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <bYwTWncj-zjfq0zL59J1d2XfX1uXGq2IYmMow_1RdbM=.d9b273cd-903e-4fe2-98b2-38eb8fc5d4dc@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
 <HN-weWcqOwwjNEtcpGjn8unVaEgWWGiP7pekQPtHRk0=.16142675-583c-4770-9447-37cb450c2d92@github.com>
 <bYwTWncj-zjfq0zL59J1d2XfX1uXGq2IYmMow_1RdbM=.d9b273cd-903e-4fe2-98b2-38eb8fc5d4dc@github.com>
Message-ID: <QjRIAsQHBio75Hxj1wMA9_7ZxQDFEunq9JOJylSBncc=.8a37330f-5d68-43d2-8136-2e6d6d0b5960@github.com>

On Mon, 5 May 2025 17:38:55 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringUTF16.java line 1531:
>> 
>>> 1529:     }
>>> 1530: 
>>> 1531:     public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
>> 
>> Hello Roger, can this (pre-existing) method and the other `putCharsAt` that we are changing here, be changed to package private instead of `public`? As far as I can see, these 2 are only accessed from `java.lang.AbstractStringBuilder` which resides in the same package as this class.
>
> In fact, `StringUTF16` and `StringLatin1` are both package-private, so technically all their method access modifiers should either be package-private or private.

How about in another PR.  None of the `public static ` methods in StringUTF16 or StringLatin1 need to be public. But it will make this PR very noisy for the wrong reasons.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2073917061

From jpai at openjdk.org  Mon May  5 18:02:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 May 2025 18:02:51 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <QjRIAsQHBio75Hxj1wMA9_7ZxQDFEunq9JOJylSBncc=.8a37330f-5d68-43d2-8136-2e6d6d0b5960@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
 <HN-weWcqOwwjNEtcpGjn8unVaEgWWGiP7pekQPtHRk0=.16142675-583c-4770-9447-37cb450c2d92@github.com>
 <bYwTWncj-zjfq0zL59J1d2XfX1uXGq2IYmMow_1RdbM=.d9b273cd-903e-4fe2-98b2-38eb8fc5d4dc@github.com>
 <QjRIAsQHBio75Hxj1wMA9_7ZxQDFEunq9JOJylSBncc=.8a37330f-5d68-43d2-8136-2e6d6d0b5960@github.com>
Message-ID: <UNyu3-5TUmbjh-tAWux24DJcaUcYPUX3p0n9C1kPD10=.3b9e56ff-fd3a-4abf-a743-92e45c3041ee@github.com>

On Mon, 5 May 2025 17:58:09 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> In fact, `StringUTF16` and `StringLatin1` are both package-private, so technically all their method access modifiers should either be package-private or private.
>
> How about in another PR.  None of the `public static ` methods in StringUTF16 or StringLatin1 need to be public. But it will make this PR very noisy for the wrong reasons.

Doing that in a separate issue/PR sounds good to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2073921127

From cushon at openjdk.org  Mon May  5 18:04:51 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 5 May 2025 18:04:51 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v10]
In-Reply-To: <PKReG4Cxbw4EFGvv8hUNd-QCyfyeHma2iAK6dO106JA=.ffde0cbd-9677-47b6-9f89-ea59dde01a5c@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
 <95_0h5qpY-WYbzFlfMqyETLmw3YkiBqh-MltS5-bpMU=.c7020e2e-e322-4b3e-b5d5-919304234e25@github.com>
 <PKReG4Cxbw4EFGvv8hUNd-QCyfyeHma2iAK6dO106JA=.ffde0cbd-9677-47b6-9f89-ea59dde01a5c@github.com>
Message-ID: <-WZAftWUFTVZDfqq2bhaMr48JBHkMXy9FWwLNuZBGng=.92e3258e-e8b9-41b9-bc88-54b0d5f29bf8@github.com>

On Sat, 26 Apr 2025 04:09:03 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think our next steps are: In early 26, if a corpus search proved no definitive incompatibility, integrate this change and post a message to quality-discuss. Same for #15614. If any incompatibility surfaces, we have sufficient time to rollback. What do you think?

That sounds OK to me.

I have applied this change to Google's build of OpenJDK and it has been released, we have continued to see no impact to real-world code.

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

PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2851883053

From rriggs at openjdk.org  Mon May  5 18:22:47 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 5 May 2025 18:22:47 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v3]
In-Reply-To: <yzIStBhU9mAjPrC_GoQZZMhygrKGz01pzGv5Hy7QhWU=.663c98e2-4e2a-42a5-b713-5aee495a4519@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <QpnbZKc7ef8pJuC17i0V5VOJWcdHrBFzJfFxFmx-7P0=.689ad7c0-fbde-499c-b06d-907a8a98b36a@github.com>
 <yzIStBhU9mAjPrC_GoQZZMhygrKGz01pzGv5Hy7QhWU=.663c98e2-4e2a-42a5-b713-5aee495a4519@github.com>
Message-ID: <sVUP7zhSO0T26H7-MCrcaCCckJSRgypHb-fbb4Aa4Ks=.1db92b07-cef8-4565-bfba-0a0d9e714fb0@github.com>

On Fri, 2 May 2025 17:49:20 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Optimize StringUTF16.putCharsAt a bit.
>>   Fixup hotspot Helper of putCharsAt to remove return value to match StringUTF16.putCharsAt.
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1970:
> 
>> 1968:     private static byte[] appendChars(byte[] value, byte coder, int count, char[] s, int off, int end) {
>> 1969:         if (isLatin1(coder)) {
>> 1970:             for (int i = off, j = count; i < end; i++) {
> 
> Suggestion:
> 
>             int compressed = StringUTF16.compress(s, off, value, count, end - off);
>             for (int i = compressed + off, j = count + compressed; i < end; i++) {
> 
> Refer to PR #24773, adding StringUTF16.compress preprocessing here will improve the performance of java.io.BufferedReader::readLine method.
> 
> Should it be done at once or separately for PR #24773 to make changes?

I rolled this suggestion into ff3d841; and fixed a second occurence.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2073947019

From duke at openjdk.org  Mon May  5 18:28:47 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 5 May 2025 18:28:47 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v3]
In-Reply-To: <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com>
Message-ID: <cLknpFFaLQim0ofef4kmHQroCXy_DZcuP93rFB2I9bo=.79a42667-d328-421f-b836-909b953658c1@github.com>

On Mon, 5 May 2025 17:13:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix empty line at the end of a third file
>  - Fix empty line at the end of another file
>  - Fix empty line at the end of a file

src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 176:

> 174:             @ForceInline
> 175:             @Override
> 176:             public NativeMemorySegmentImpl allocateNoInit(long byteSize, long byteAlignment) {

This?probably also?needs `@SuppressWarnings("restricted")`:
Suggestion:

            @ForceInline
            @Override
            @SuppressWarnings("restricted")
            public NativeMemorySegmentImpl allocateNoInit(long byteSize, long byteAlignment) {

src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 85:

> 83:     // specific "basic handle" in the `BASIC_HANDLE_CACHE`.
> 84:     //   returnType in {int.class | long.class}
> 85:     //   stateName can be anything non-null but should be in {"GetLastError" | "WSAGetLastError"} | "errno")}

Suggestion:

    //   stateName can be anything non-null but should be in {"GetLastError" | "WSAGetLastError" | "errno"}

src/java.base/share/classes/jdk/internal/invoke/MhUtil.java line 88:

> 86:     public static MethodHandle findStatic(MethodHandles.Lookup lookup,
> 87:                                            String name,
> 88:                                            MethodType type) {

Suggestion:

                                          String name,
                                          MethodType type) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2073948786
PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2073955345
PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2073949485

From rriggs at openjdk.org  Mon May  5 18:38:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 5 May 2025 18:38:54 GMT
Subject: Integrated: 8354334: Remove @ValueBased from ProcessHandle
In-Reply-To: <V5jHERjiEnnLdxXcb3XzBtYLRUKOYTWKAqttvWdtcdo=.a9bc8785-149f-465d-8882-59d61008a2d0@github.com>
References: <V5jHERjiEnnLdxXcb3XzBtYLRUKOYTWKAqttvWdtcdo=.a9bc8785-149f-465d-8882-59d61008a2d0@github.com>
Message-ID: <9vPLNeBORaD8SOejGUr-cSqD6qf0n6edbgToOSm5YuQ=.06c2e977-ca92-4ae4-96b0-861c49639c18@github.com>

On Thu, 1 May 2025 13:36:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove internal ValueBased annotation from the ProcessHandle interface declaration.
> The implementation remains value based as described in the javadoc. 
> Remove unnecessary "public" keyword in interfaces and cleanup javadoc.

This pull request has now been integrated.

Changeset: 65f188f2
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/65f188f29f1e9fe0f73d730a4c6029a7742c6d15
Stats:     16 lines in 1 file changed: 0 ins; 3 del; 13 mod

8354334: Remove @ValueBased from ProcessHandle

Reviewed-by: liach

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

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

From rriggs at openjdk.org  Mon May  5 18:39:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 5 May 2025 18:39:51 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java [v3]
In-Reply-To: <uV1w-VU-IkHDd7JQbtj8biW9-aQyUjZ24AJM8mnZV4w=.894c0b38-42b7-4eaa-b64d-7d06bc049d7c@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
 <uV1w-VU-IkHDd7JQbtj8biW9-aQyUjZ24AJM8mnZV4w=.894c0b38-42b7-4eaa-b64d-7d06bc049d7c@github.com>
Message-ID: <OoyLhITPZ7MFl4OzWDUHqErqWIXXRAUGOCBo0Zlx9XM=.c1953c1c-191a-4e71-b76f-c9afd04c43f2@github.com>

On Sat, 3 May 2025 13:02:34 GMT, Oleksii Sylichenko <duke at openjdk.org> 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
>> 
>> 
>> If we try to run `echo` as a process in Windows, for example from IntelliJ IDEA, we get the error above, because Windows does not have such an executable, but instead this is a command of the Command Processor (CMD).
>> 
>> The `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line. Was implemented using the analogous `echo/` command to avoid compatibility issues.
>> 
>> See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo
>> 
>> To ensure that the `echo/` command is supported in Cygwin, we n...
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8353489: add comment about `echo/`; `cmd` -> `cmd.exe`

Looks good, thanks for the update.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23933#pullrequestreview-2815730121

From aturbanov at openjdk.org  Mon May  5 18:42:45 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 May 2025 18:42:45 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v4]
In-Reply-To: <6vv_RfftsMHItY1Fd1m4WFUraAwfYiNui815ORAQL7k=.4e685520-cfc2-49ac-9808-7ed197941fb7@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
 <YlGNjEj8PXyiI3uAMm0blRZISm_-l1X-1j0dIS5_Da4=.ef4d17bc-d04d-494e-bb2e-f1917a2c6a35@github.com>
 <excMxzdNWB2snNe7Z1cNAoT0wxxVcsX4ozDaTzpWeX4=.c222fe7e-7807-4b8c-90e5-1583ffb8fb82@github.com>
 <w75FLw8GmCXgUOjDNLR6vTbp-rPWxzBLWCrtBgqiodM=.b1355c69-c8c0-423c-b108-67a2b6386eee@github.com>
 <6vv_RfftsMHItY1Fd1m4WFUraAwfYiNui815ORAQL7k=.4e685520-cfc2-49ac-9808-7ed197941fb7@github.com>
Message-ID: <TA6VeIbQPD2XOx1o5kVDa68CnXHZM_9o7Li7oa336hM=.f097d77f-e69f-473d-b188-b1b3bbed1dcf@github.com>

On Mon, 5 May 2025 17:47:02 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> _Really_ fails with Xmx7G
>
> Yes, the required heap size was not enough for the reverted variant to throw a non-OOME exception/error.
> 
> Just out of curiosity, is JDK-8356152 a real-world issue you stumbled upon, or did you encounter it during some testing of yours?

I just stumbled at the code, while reviewing other patches. Not a real-world issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2073977237

From duke at openjdk.org  Mon May  5 18:52:49 2025
From: duke at openjdk.org (duke)
Date: Mon, 5 May 2025 18:52:49 GMT
Subject: RFR: 8353489: Increase timeout and improve Windows compatibility
 in test/jdk/java/lang/ProcessBuilder/Basic.java [v3]
In-Reply-To: <uV1w-VU-IkHDd7JQbtj8biW9-aQyUjZ24AJM8mnZV4w=.894c0b38-42b7-4eaa-b64d-7d06bc049d7c@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
 <uV1w-VU-IkHDd7JQbtj8biW9-aQyUjZ24AJM8mnZV4w=.894c0b38-42b7-4eaa-b64d-7d06bc049d7c@github.com>
Message-ID: <JUp0MU8JTYGu5GseVsyESBT_V-p9PqIc4Nps-fht-kE=.afe22873-1e42-4a41-aeb3-339d0571f4ca@github.com>

On Sat, 3 May 2025 13:02:34 GMT, Oleksii Sylichenko <duke at openjdk.org> 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
>> 
>> 
>> If we try to run `echo` as a process in Windows, for example from IntelliJ IDEA, we get the error above, because Windows does not have such an executable, but instead this is a command of the Command Processor (CMD).
>> 
>> The `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line. Was implemented using the analogous `echo/` command to avoid compatibility issues.
>> 
>> See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo
>> 
>> To ensure that the `echo/` command is supported in Cygwin, we n...
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8353489: add comment about `echo/`; `cmd` -> `cmd.exe`

@asilichenko 
Your change (at version 90752f181b1d8326c854bc06e2108a3751fa225e) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23933#issuecomment-2852006051

From duke at openjdk.org  Mon May  5 18:59:29 2025
From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=)
Date: Mon, 5 May 2025 18:59:29 GMT
Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter [v2]
In-Reply-To: <NQUre5r4T9T4zOi4Jcw180gWzhzcnrLRrUBwR72y-AY=.9232e31f-2f1f-418a-8bf3-6f98dfef649a@github.com>
References: <NQUre5r4T9T4zOi4Jcw180gWzhzcnrLRrUBwR72y-AY=.9232e31f-2f1f-418a-8bf3-6f98dfef649a@github.com>
Message-ID: <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com>

> JavaDoc only: This PR fixes a typo in the `bytecode behavior` table entry for Lookup.findGetter.

Steffen Nie?ing has updated the pull request with a new target base 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-8356119
 - 8356119: Correct field type for bytecode cast

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25024/files
  - new: https://git.openjdk.org/jdk/pull/25024/files/14148dd1..020b062f

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

  Stats: 1336 lines in 105 files changed: 1096 ins; 102 del; 138 mod
  Patch: https://git.openjdk.org/jdk/pull/25024.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25024/head:pull/25024

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

From duke at openjdk.org  Mon May  5 18:59:29 2025
From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=)
Date: Mon, 5 May 2025 18:59:29 GMT
Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter
In-Reply-To: <k_7K0gS17MsurSz1qwrHEGkOcjdMDbZuBZIr-ujQZZ0=.5c4a1bf0-e12b-4341-8efc-b193090e8d25@github.com>
References: <NQUre5r4T9T4zOi4Jcw180gWzhzcnrLRrUBwR72y-AY=.9232e31f-2f1f-418a-8bf3-6f98dfef649a@github.com>
 <k_7K0gS17MsurSz1qwrHEGkOcjdMDbZuBZIr-ujQZZ0=.5c4a1bf0-e12b-4341-8efc-b193090e8d25@github.com>
Message-ID: <SxED6jvJQxK3lk29B3AdVU4JowIH7b6vBCBtrJwBkUo=.3ee230de-29bb-4035-9d52-9dcd8c5cce00@github.com>

On Sun, 4 May 2025 17:20:29 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Nit: Would be nice if the PR title/description made it clear for the casual reader that this is a documentation/Javadoc typo, as opposed to a code issue.

Thanks for the hint. I've updated the PR accordingly. 

> This gives reviewers some feeling of the size/complexity of the PR without actually digging into the code.

I've tried to make that clear now. Thanks for the feedback and the nice welcome here.

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

PR Comment: https://git.openjdk.org/jdk/pull/25024#issuecomment-2852013683

From duke at openjdk.org  Mon May  5 18:59:50 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Mon, 5 May 2025 18:59:50 GMT
Subject: Integrated: 8353489: Increase timeout and improve Windows
 compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java
In-Reply-To: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
References: <cPeL33cLuHq9hLdrukI7LJK02aqEr06V36340VE9qwc=.421ee719-d188-4e58-915d-dd9acebe3795@github.com>
Message-ID: <Ey_O4XS98P6wEAd6ZRdNVPMtY7hwC2B5KV1iqU-ApP0=.c2745bf3-a922-453b-b702-96376ccbb00c@github.com>

On Thu, 6 Mar 2025 13:34:07 GMT, Oleksii Sylichenko <duke at openjdk.org> 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
> 
> 
> If we try to run `echo` as a process in Windows, for example from IntelliJ IDEA, we get the error above, because Windows does not have such an executable, but instead this is a command of the Command Processor (CMD).
> 
> The `echo.` command with the `.` works the same way as calling `echo` without parameters in Unix ? it outputs an empty line. Was implemented using the analogous `echo/` command to avoid compatibility issues.
> 
> See: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo
> 
> To ensure that the `echo/` command is supported in Cygwin, we need to invoke it via `cmd /c`, because Cygwin has its own executable "echo".
> 
> ## cmd.e...

This pull request has now been integrated.

Changeset: 6bcbc3b0
Author:    Oleksii Sylichenko <a.silichenko at gmail.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6bcbc3b0a21687504b07a0a405d824a448aea872
Stats:     8 lines in 1 file changed: 2 ins; 1 del; 5 mod

8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java

Reviewed-by: rriggs

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

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

From duke at openjdk.org  Mon May  5 19:39:44 2025
From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=)
Date: Mon, 5 May 2025 19:39:44 GMT
Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter [v2]
In-Reply-To: <IcrG4g62NrLAIU4JRqXT7x1s9jtd5Cqt26uw2SHhQvQ=.f4d51550-af0c-4916-baa6-20172cbae9a9@github.com>
References: <NQUre5r4T9T4zOi4Jcw180gWzhzcnrLRrUBwR72y-AY=.9232e31f-2f1f-418a-8bf3-6f98dfef649a@github.com>
 <IcrG4g62NrLAIU4JRqXT7x1s9jtd5Cqt26uw2SHhQvQ=.f4d51550-af0c-4916-baa6-20172cbae9a9@github.com>
Message-ID: <_WKhVsp3ndefx8j0ngh02e0yvLC9VkN2HPAQTG6tz3I=.64317be2-0b98-4278-9280-25d65c7aaf8c@github.com>

On Sun, 4 May 2025 17:01:54 GMT, Chen Liang <liach at openjdk.org> wrote:

> Thanks for the mailing list communication and reply.
>
> Check out https://openjdk.org/guide/ for more steps. For example, a patch should usually wait 24 hours for sufficient reviews.

@liach Thanks for the fast review and the creation of the backing JBS issue. I've updated the PR and checked the tests. As this change is fairly trivial, I think the 24 hours should be enough review time for this one. If you're fine with it, I'd appreciate your sponsor approval.

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

PR Comment: https://git.openjdk.org/jdk/pull/25024#issuecomment-2852132095

From zuniquex at protonmail.com  Mon May  5 20:05:06 2025
From: zuniquex at protonmail.com (=?utf-8?Q?Steffen_Nie=C3=9Fing?=)
Date: Mon, 05 May 2025 20:05:06 +0000
Subject: JavaDoc: NPE in java.net.http.HttpHeaders
Message-ID: <Osz5cwLv8dCufch8gyhKOQf-jqglf72M1rNOEiLPtWbFrQwwUNo6ump8KA3rCi5ZaTGtWiIFQgII55g50WurfP6rvKumwWyfIgGZGVwckCo=@protonmail.com>

Hello,

recently I've discovered that the JavaDoc of the instance methods of java.net.http.HttpHeaders lacks the throws declarations for NullPointerExceptions. The static creator method `of` contains such a declaration. So the snippet `HttpHeaders.of(null, null)` is documented to throw an NPE, while the snippet `HttpHeaders.of(Map.of(), (k, v) -> true).firstValue(null)` currently isn't.

I'd propose to add the missing JavaDoc throws declarations to the #allValues(String), #firstValueAsLong(String) and #firstValue(String) methods as they all can throw an NPE through `requireNonNull(name);` in the allValues method.

If there's interest in this change, I'd appreciate if anyone would like to sponsor me on this one.

Cheers,
Steffen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250505/afc56b5b/attachment-0001.htm>

From valeriep at openjdk.org  Mon May  5 20:07:52 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 5 May 2025 20:07:52 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6]
In-Reply-To: <IGzpehDXDsv_5MZ1ZOO1MnrqLPp1bYNS4anT8Z-8f88=.577c3298-d6d9-48bc-86cf-21c83bfb910b@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <IGzpehDXDsv_5MZ1ZOO1MnrqLPp1bYNS4anT8Z-8f88=.577c3298-d6d9-48bc-86cf-21c83bfb910b@github.com>
Message-ID: <ozCQCz3li3hlrxImPLyXO51QYRs13xcOHoxixP0XUJc=.a49fa122-bec8-4b62-8fbf-a65ebf91c737@github.com>

On Fri, 2 May 2025 18:49:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Finalize the KDF API.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fine tuning debug log and exception message

test/jdk/com/sun/crypto/provider/KDF/HKDFSaltIKMTest.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8331008

Should we add 8353888 to all the tests?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2074112296

From bpb at openjdk.org  Mon May  5 20:13:47 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 5 May 2025 20:13:47 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <FN2uTRQa7F53we_mGNLJEHkmvIv8JqsoPF_4D5ufzH8=.0ea526a4-1a6a-42e2-829c-12a9cfd95c05@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
 <DXQ8sulRSIa5sQJaZU9UM7NF8AHkRsViO6D9b0rI2Vg=.32fa69ad-94bf-4453-97e8-22a6802c8b08@github.com>
 <F2QI8fLrAJ2ZB6nPfxenoaxVTP6_i1tMt3-9OLiXh0U=.3df00047-29b5-42e2-8518-2b7f63cc26ae@github.com>
 <FN2uTRQa7F53we_mGNLJEHkmvIv8JqsoPF_4D5ufzH8=.0ea526a4-1a6a-42e2-829c-12a9cfd95c05@github.com>
Message-ID: <_2ekooJ1JCePIMHLkbFsQRNCkKXXKvAS3dRvOpcLfnA=.6795990f-8a75-4763-902c-8c9f0250ceb0@github.com>

On Fri, 2 May 2025 19:00:42 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> I think it's still ambiguous. [...]

Without addressing the specific comments, I would simply like to point out that "as if" and "equivalent" is common phrasing in this area, e.g.,

- [File.toPath](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#toPath())
- [Files.newBufferedReader](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Files.html#newBufferedReader(java.nio.file.Path))
- etc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2074120906

From liach at openjdk.org  Mon May  5 20:39:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 May 2025 20:39:46 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v5]
In-Reply-To: <bF_OnxOCbrFO-atOiCBXIJp_JxT2__hFunyZV-aTPs0=.2da5ecfe-81e1-4723-9bab-65aec9c808e2@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
 <bF_OnxOCbrFO-atOiCBXIJp_JxT2__hFunyZV-aTPs0=.2da5ecfe-81e1-4723-9bab-65aec9c808e2@github.com>
Message-ID: <C3Aku9aL_DGMmvFkOuYV67PZ2l48FIShYn6LZEiVVcI=.069bce1b-85f8-4ea4-8622-0726f3cee044@github.com>

On Mon, 5 May 2025 17:29:33 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> A fix to throw `OutOfMemoryError`, as done in releases ? 23.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Increased min heap size to 8G.

Test updates look helpful.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25038#pullrequestreview-2816032703

From liach at openjdk.org  Mon May  5 20:39:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 May 2025 20:39:46 GMT
Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter [v2]
In-Reply-To: <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com>
References: <NQUre5r4T9T4zOi4Jcw180gWzhzcnrLRrUBwR72y-AY=.9232e31f-2f1f-418a-8bf3-6f98dfef649a@github.com>
 <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com>
Message-ID: <i24P67d4eWz2pytdBxYUgTmIrzkdA-YhPNwOiA03PiE=.768a083a-5944-45e6-9d63-2501ba26172d@github.com>

On Mon, 5 May 2025 18:59:29 GMT, Steffen Nie?ing <duke at openjdk.org> wrote:

>> JavaDoc only: This PR fixes a typo in the `bytecode behavior` table entry for Lookup.findGetter.
>
> Steffen Nie?ing has updated the pull request with a new target base 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-8356119
>  - 8356119: Correct field type for bytecode cast

FYI to integrate, you need to type the `/integrate` command.

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

PR Comment: https://git.openjdk.org/jdk/pull/25024#issuecomment-2852273712

From bpb at openjdk.org  Mon May  5 20:45:50 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 5 May 2025 20:45:50 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <BB0nBKB-FnwqpRejR4nWVmFrLCcyH0S3-D0p1vJCEeM=.1ce0e0ad-8f0e-412b-b0b2-2f814a1a0fa5@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
 <BB0nBKB-FnwqpRejR4nWVmFrLCcyH0S3-D0p1vJCEeM=.1ce0e0ad-8f0e-412b-b0b2-2f814a1a0fa5@github.com>
Message-ID: <7-F1vCVNup1tOkC8CLcuVB9f5aYydrRJMw0fNWFjriE=.60ffa2e0-0aec-4e76-b4a0-6e18506a0333@github.com>

On Thu, 1 May 2025 18:00:54 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> I'd suggest not having this method's implementation depend on an overridable method.

I'm jumping the gun here by referring to an implementation detail, but the overridable method problem could be circumvented using an approach taken in other classes in `java.io`:

        if (getClass() == BufferedReader.class) {
            try {
                return lines().toList();
            } catch (UncheckedIOException ue) {
                // the cause cannot be null
                throw ue.getCause();
            }
        } else {
            return super.readAllLines();
        }

This would not need to be mentioned in the specification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2074159396

From duke at openjdk.org  Mon May  5 20:46:46 2025
From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=)
Date: Mon, 5 May 2025 20:46:46 GMT
Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter [v2]
In-Reply-To: <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com>
References: <NQUre5r4T9T4zOi4Jcw180gWzhzcnrLRrUBwR72y-AY=.9232e31f-2f1f-418a-8bf3-6f98dfef649a@github.com>
 <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com>
Message-ID: <bcWPz8AbLr3CYtpTlFo_SpSZcFIMCIEuJMPv7V7xNs4=.9e2cbbc9-bd53-4e28-b0fc-b769e98702ac@github.com>

On Mon, 5 May 2025 18:59:29 GMT, Steffen Nie?ing <duke at openjdk.org> wrote:

>> JavaDoc only: This PR fixes a typo in the `bytecode behavior` table entry for Lookup.findGetter.
>
> Steffen Nie?ing has updated the pull request with a new target base 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-8356119
>  - 8356119: Correct field type for bytecode cast

Okay, thanks. From the guide I thought you'd have to enter the `/sponsor` command first before I can `/integrate`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25024#issuecomment-2852289475

From duke at openjdk.org  Mon May  5 20:49:49 2025
From: duke at openjdk.org (duke)
Date: Mon, 5 May 2025 20:49:49 GMT
Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter [v2]
In-Reply-To: <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com>
References: <NQUre5r4T9T4zOi4Jcw180gWzhzcnrLRrUBwR72y-AY=.9232e31f-2f1f-418a-8bf3-6f98dfef649a@github.com>
 <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com>
Message-ID: <ox4x5zkcYo5bA3mbx8X5deG2qo32__iUNhb3bsyW_ak=.493ee5f7-b49c-4fab-908a-60a14a77cc97@github.com>

On Mon, 5 May 2025 18:59:29 GMT, Steffen Nie?ing <duke at openjdk.org> wrote:

>> JavaDoc only: This PR fixes a typo in the `bytecode behavior` table entry for Lookup.findGetter.
>
> Steffen Nie?ing has updated the pull request with a new target base 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-8356119
>  - 8356119: Correct field type for bytecode cast

@zUniQueX 
Your change (at version 020b062fe8fa544eb5ac37163e82d0aa1db50dfe) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25024#issuecomment-2852295782

From duke at openjdk.org  Mon May  5 20:54:56 2025
From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=)
Date: Mon, 5 May 2025 20:54:56 GMT
Subject: Integrated: 8356119: Typo in bytecode behavior for Lookup.findGetter
In-Reply-To: <NQUre5r4T9T4zOi4Jcw180gWzhzcnrLRrUBwR72y-AY=.9232e31f-2f1f-418a-8bf3-6f98dfef649a@github.com>
References: <NQUre5r4T9T4zOi4Jcw180gWzhzcnrLRrUBwR72y-AY=.9232e31f-2f1f-418a-8bf3-6f98dfef649a@github.com>
Message-ID: <rL88cF56hH6e1uoXSVMmhf1oWwMU_tr1yQU3SUKXPSk=.940e5e2e-e514-4684-b2b1-0c0d2f9336d0@github.com>

On Sun, 4 May 2025 16:45:11 GMT, Steffen Nie?ing <duke at openjdk.org> wrote:

> JavaDoc only: This PR fixes a typo in the `bytecode behavior` table entry for Lookup.findGetter.

This pull request has now been integrated.

Changeset: 2a4f37cc
Author:    Steffen Nie?ing <zuniquex at protonmail.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a4f37cc169e0e876b0b463261f84594af4e7569
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8356119: Typo in bytecode behavior for Lookup.findGetter

Reviewed-by: liach

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

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

From liach at openjdk.org  Mon May  5 20:54:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 May 2025 20:54:56 GMT
Subject: RFR: 8356119: Typo in bytecode behavior for Lookup.findGetter [v2]
In-Reply-To: <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com>
References: <NQUre5r4T9T4zOi4Jcw180gWzhzcnrLRrUBwR72y-AY=.9232e31f-2f1f-418a-8bf3-6f98dfef649a@github.com>
 <7ynJO1dLW4hq5J3vxM1dvh_P-zM6u41P7hm5aeKRKc8=.2adfbbcc-5165-4c6b-af04-711715d08c3d@github.com>
Message-ID: <wplK-AEL8Hrzam78nFizPUAEX0UWLsKivSJHxKU_d4I=.dbeae4cc-b9f6-49a6-9e5f-4c66ca12f806@github.com>

On Mon, 5 May 2025 18:59:29 GMT, Steffen Nie?ing <duke at openjdk.org> wrote:

>> JavaDoc only: This PR fixes a typo in the `bytecode behavior` table entry for Lookup.findGetter.
>
> Steffen Nie?ing has updated the pull request with a new target base 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-8356119
>  - 8356119: Correct field type for bytecode cast

Thanks for this fix!

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

PR Comment: https://git.openjdk.org/jdk/pull/25024#issuecomment-2852305117

From bpb at openjdk.org  Mon May  5 21:00:12 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 5 May 2025 21:00:12 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v15]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: <4rFHYWIzukqYmTr6jvev9uUpbL1iLUg4OE-JI3oThM0=.22ba7232-9c4f-4399-a6a8-39410bb2d89b@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: Fix potential NPE in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/dc84bd1b..db338317

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=13-14

  Stats: 2 lines in 1 file changed: 1 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 bpb at openjdk.org  Mon May  5 21:00:12 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 5 May 2025 21:00:12 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <5e91fwQ-fvxomq2pltkLuT0EeVaJPH_L4ibc4u6O91c=.03f7a833-0dd2-4427-ab88-b1b88daa4d2a@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
 <5e91fwQ-fvxomq2pltkLuT0EeVaJPH_L4ibc4u6O91c=.03f7a833-0dd2-4427-ab88-b1b88daa4d2a@github.com>
Message-ID: <Ul43SxCD2fJx2fVcBb6t03ce3iIwb4JWJB01qCvpzx8=.7308bf9f-8b30-4cca-bcc2-a049b5620af3@github.com>

On Fri, 2 May 2025 19:38:11 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test
>
> test/jdk/java/io/BufferedReader/ReadAll.java line 82:
> 
>> 80:     @AfterAll
>> 81:     public static void cleanup() throws IOException {
>> 82:         file.delete();
> 
> If the call to createTempFile() above fails with an exception, file will be null

Thanks. Fixed in [db33831](https://github.com/openjdk/jdk/pull/24728/commits/db338317439703e106f06f963eb67f06bf150d28).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2074192348

From aturbanov at openjdk.org  Mon May  5 21:01:59 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 May 2025 21:01:59 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v5]
In-Reply-To: <bF_OnxOCbrFO-atOiCBXIJp_JxT2__hFunyZV-aTPs0=.2da5ecfe-81e1-4723-9bab-65aec9c808e2@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
 <bF_OnxOCbrFO-atOiCBXIJp_JxT2__hFunyZV-aTPs0=.2da5ecfe-81e1-4723-9bab-65aec9c808e2@github.com>
Message-ID: <o-BR9svkpt8A0mFekAaDGCb9yWtSLU_UuXN4OL4wUYY=.259d8e92-8157-438d-ba2f-0e1631b1f68c@github.com>

On Mon, 5 May 2025 17:29:33 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> A fix to throw `OutOfMemoryError`, as done in releases ? 23.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Increased min heap size to 8G.

Marked as reviewed by aturbanov (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25038#pullrequestreview-2816095371

From weijun at openjdk.org  Mon May  5 21:03:48 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 May 2025 21:03:48 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6]
In-Reply-To: <ozCQCz3li3hlrxImPLyXO51QYRs13xcOHoxixP0XUJc=.a49fa122-bec8-4b62-8fbf-a65ebf91c737@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <IGzpehDXDsv_5MZ1ZOO1MnrqLPp1bYNS4anT8Z-8f88=.577c3298-d6d9-48bc-86cf-21c83bfb910b@github.com>
 <ozCQCz3li3hlrxImPLyXO51QYRs13xcOHoxixP0XUJc=.a49fa122-bec8-4b62-8fbf-a65ebf91c737@github.com>
Message-ID: <Cwl0AITUcvjG9XLxPBddevu4s7XkRCXLzaCvVbCxX_c=.b9664acd-2d83-4e1e-b0dc-f1aef2fd4558@github.com>

On Mon, 5 May 2025 20:04:46 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fine tuning debug log and exception message
>
> test/jdk/com/sun/crypto/provider/KDF/HKDFSaltIKMTest.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 8331008
> 
> Should we add 8353888 to all the tests?

The Virtual Threads JEP didn't. https://github.com/openjdk/jdk/commit/2586f36120317cd206464b1e79d3906f711487cb#diff-35150e3bfd3304405ec403aa29cbea7aaa05c7bab3e28ac92e8162683114746a. I assume we don't either. Bug ids should match changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2074195043

From asemenyuk at openjdk.org  Mon May  5 21:14:01 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 5 May 2025 21:14:01 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
Message-ID: <pii3KOvk3M9jFKdvesz3TPAfV8EqsdSYFAJZirR0adc=.2760d046-5c73-466e-97ed-6d548d0a3d16@github.com>

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
> - This change is for macOS only.
> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

Filed [JDK-8356218](https://bugs.openjdk.org/browse/JDK-8356218) to follow up with the documentation

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

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2852348515

From bchristi at openjdk.org  Mon May  5 21:37:48 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 5 May 2025 21:37:48 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
Message-ID: <nLpdJCObVvW7a6Z5eITjtxqONaiETN1yNaQvroaBvsg=.2bf673b4-5179-41c5-8653-df6fabf5a226@github.com>

On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 335:

> 333:      *
> 334:      * @param  minCapacity the desired minimum capacity
> 335:      * @throws OutOfMemoryError if minCapacity is less than zero or

new `@params` for added arguments?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2074232727

From chen.l.liang at oracle.com  Mon May  5 21:46:13 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Mon, 5 May 2025 21:46:13 +0000
Subject: JavaDoc: NPE in java.net.http.HttpHeaders
In-Reply-To: <Osz5cwLv8dCufch8gyhKOQf-jqglf72M1rNOEiLPtWbFrQwwUNo6ump8KA3rCi5ZaTGtWiIFQgII55g50WurfP6rvKumwWyfIgGZGVwckCo=@protonmail.com>
References: <Osz5cwLv8dCufch8gyhKOQf-jqglf72M1rNOEiLPtWbFrQwwUNo6ump8KA3rCi5ZaTGtWiIFQgII55g50WurfP6rvKumwWyfIgGZGVwckCo=@protonmail.com>
Message-ID: <SJ2PR10MB7669E27D67B9932A13272B09A28E2@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hello Steffen,
I think this is fine. In the package summary of java.net.http, the last sentence says:

Unless otherwise stated, null parameter values will cause methods of all classes in this package to throw NullPointerException.

The method you mentioned in particular does mention NPE, but that clause aims to cover the edge cases where the headerMap contains null keys, null values, or one of its value List contains null.

I think a potential improvement here is to update the package summary to indicate NPE for any nested collection; this is what Class-File API does for java.lang.classfile and the subpackages.

Regards,
Chen Liang

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Steffen Nie?ing <zuniquex at protonmail.com>
Sent: Monday, May 5, 2025 3:05 PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: JavaDoc: NPE in java.net.http.HttpHeaders

Hello,

recently I've discovered that the JavaDoc of the instance methods of java.net.http.HttpHeaders lacks the throws declarations for NullPointerExceptions. The static creator method `of` contains such a declaration. So the snippet `HttpHeaders.of(null, null)` is documented to throw an NPE, while the snippet `HttpHeaders.of(Map.of(), (k, v) -> true).firstValue(null)` currently isn't.

I'd propose to add the missing JavaDoc throws declarations to the #allValues(String), #firstValueAsLong(String) and #firstValue(String) methods as they all can throw an NPE through `requireNonNull(name);` in the allValues method.

If there's interest in this change, I'd appreciate if anyone would like to sponsor me on this one.

Cheers,
Steffen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250505/f95789ab/attachment-0001.htm>

From almatvee at openjdk.org  Mon May  5 22:31:48 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 5 May 2025 22:31:48 GMT
Subject: RFR: 8355573: Remove kludge_c++11.h from jpackage code
In-Reply-To: <ABRXOAFnthURb4yuEcE4Ex-2Vz28YrnyXp6a3iFX0os=.96006b49-051d-4eda-9c29-7e3b34f0e3cb@github.com>
References: <ABRXOAFnthURb4yuEcE4Ex-2Vz28YrnyXp6a3iFX0os=.96006b49-051d-4eda-9c29-7e3b34f0e3cb@github.com>
Message-ID: <n0hxEGtixYaAjJrWVZ_segrizstoD7cFucoTpFBxQyk=.1a3ac19a-6935-4411-9457-c6b902559ea7@github.com>

On Fri, 25 Apr 2025 06:14:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> kludge_c++11.h was introduced to work around older C++ versions not having access to C++ utilities like std::unique_ptr. Since we are already on C++14 (And hopefully will get C++17 soon) this workaround can be removed from jpackage code.

src/jdk.jpackage/windows/native/common/MsiUtils.h line 35:

> 33: #include <new>
> 34: #include <map>
> 35: #include <memory>

Why this include was added?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24868#discussion_r2074290056

From valeriep at openjdk.org  Mon May  5 23:10:21 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 5 May 2025 23:10:21 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6]
In-Reply-To: <IGzpehDXDsv_5MZ1ZOO1MnrqLPp1bYNS4anT8Z-8f88=.577c3298-d6d9-48bc-86cf-21c83bfb910b@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <IGzpehDXDsv_5MZ1ZOO1MnrqLPp1bYNS4anT8Z-8f88=.577c3298-d6d9-48bc-86cf-21c83bfb910b@github.com>
Message-ID: <HbFASiE30jlau5uYQd8IfunzRxrDsWjjg1K2he6aig8=.c62665fb-5ecb-40be-9be8-25ccb501e531@github.com>

On Fri, 2 May 2025 18:49:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Finalize the KDF API.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fine tuning debug log and exception message

Looks good.

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24520#pullrequestreview-2816353093

From smarks at openjdk.org  Mon May  5 23:36:35 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 5 May 2025 23:36:35 GMT
Subject: RFR: 8351230: Collections.synchronizedList returns a list that is
 not thread-safe [v2]
In-Reply-To: <HtBkFlpJ7N3BjMiDZcA2LgM0YOEkd4L1_6XKIPJwwew=.6325e6ba-153e-43c6-9de6-ab00c1e972ed@github.com>
References: <HtBkFlpJ7N3BjMiDZcA2LgM0YOEkd4L1_6XKIPJwwew=.6325e6ba-153e-43c6-9de6-ab00c1e972ed@github.com>
Message-ID: <DRxCjR218Sb5Px9jomhYtD8HV-g71CqeJ0Pei-xYsBk=.def444b8-bf73-44f4-85d0-3750774b9be6@github.com>

> Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper:
> 
> - overrides and adds locking to SequencedCollection methods;
> - performs instance management of reversed synchronized views;
> - adds test for race conditions and functional tests of synchronized wrappers.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Reversed view of SynchronizedRandomAccessList should also be RandomAccess.
  Add tests to ensure RandomAccess is preserved when reversing.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24990/files
  - new: https://git.openjdk.org/jdk/pull/24990/files/fe351510..1750bb20

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

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

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

From smarks at openjdk.org  Mon May  5 23:36:36 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 5 May 2025 23:36:36 GMT
Subject: RFR: 8351230: Collections.synchronizedList returns a list that is
 not thread-safe [v2]
In-Reply-To: <h3b0gIkbHz5efvlh3NPhzBZPhQ8DUDa4Ao-rGnVJXO4=.414b236b-4638-41de-91ec-80bf827999c1@github.com>
References: <HtBkFlpJ7N3BjMiDZcA2LgM0YOEkd4L1_6XKIPJwwew=.6325e6ba-153e-43c6-9de6-ab00c1e972ed@github.com>
 <h3b0gIkbHz5efvlh3NPhzBZPhQ8DUDa4Ao-rGnVJXO4=.414b236b-4638-41de-91ec-80bf827999c1@github.com>
Message-ID: <Zy0MHZm-rIA1JP5kshNT9gBcc_8Alev0AdsynkG_saU=.1a179a2a-0cf4-440b-b071-f524e027dfa7@github.com>

On Sun, 4 May 2025 17:51:48 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reversed view of SynchronizedRandomAccessList should also be RandomAccess.
>>   Add tests to ensure RandomAccess is preserved when reversing.
>
> src/java.base/share/classes/java/util/Collections.java line 2837:
> 
>> 2835:                 return reversedView;
>> 2836:             }
>> 2837:         }
> 
> `SynchronizedRandomAccessList` overrides `subList`, should it also override `reversed`?

Good point, yes it should! At least, it should ensure that the reversed view of a random access synchronized list should also be random access -- which the current code doesn't do. Overriding reversed() in the RA subclass is probably the clearest way to do that. I'll also take the opportunity to expand test coverage, as I don't think the reversed-view-of-RA-is-also-RA is covered anywhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24990#discussion_r2074366852

From iklam at openjdk.org  Mon May  5 23:44:14 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 5 May 2025 23:44:14 GMT
Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner
 classes
In-Reply-To: <5vOdChaItphSz0dAvDqdniRjHRAAzeUBu2e7rxMkS54=.05079043-e02a-4853-891e-c7d34919af8d@github.com>
References: <JQCL1DGBobBWQqWeX3Ykuw1nZOis5D8k6kEllWluE0s=.a089b081-da05-436c-b0f7-ec021887ea57@github.com>
 <5vOdChaItphSz0dAvDqdniRjHRAAzeUBu2e7rxMkS54=.05079043-e02a-4853-891e-c7d34919af8d@github.com>
Message-ID: <QdjJ8G0s90D356pWkIoOmL1lMI8zjomfqbSDeQXFGWc=.eb0d693b-cf30-4e23-befc-0a06490f8ba6@github.com>

On Thu, 1 May 2025 18:52:22 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> @iklam We have seen this problem with Red Hat deployments in jdk24 as well as jdk25-ea.
> 
> I'm saying that mostly for information. However, I do have to ask: If this is fixed for jdk25 is there any question of also fixing it in jdk24? I would be content to receive a no answer -- a similar issue with patch that could be backported from jdk26 -> jdk25 might be something to think about a bit more?

Backporting this to jdk 24 would require a lot of effort. I think it might be easier to update CDSHeapVerifier to add more rules  to filter out the false positives. CDSHeapVerifier is too conservative and reports error for things that are actually OK.

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

PR Comment: https://git.openjdk.org/jdk/pull/24956#issuecomment-2852698208

From iklam at openjdk.org  Mon May  5 23:50:31 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 5 May 2025 23:50:31 GMT
Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner
 classes [v2]
In-Reply-To: <JQCL1DGBobBWQqWeX3Ykuw1nZOis5D8k6kEllWluE0s=.a089b081-da05-436c-b0f7-ec021887ea57@github.com>
References: <JQCL1DGBobBWQqWeX3Ykuw1nZOis5D8k6kEllWluE0s=.a089b081-da05-436c-b0f7-ec021887ea57@github.com>
Message-ID: <Xx7OLj80AjJ_Ay-yUz-Lgd9DRLg2QWyEn97WSrnvnxg=.c639e8e9-ba3c-4844-a0e2-d8bbcec728c1@github.com>

> This is a general fix for all the "points to a static field that may hold a different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330).
> 
> AOT-cached method handles quite often refer to the static fields in `MethodHandleImpl` or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. `CDSHeapVerifier` makes a very conservative check for such static fields, but sometimes gives false positives (as in the above two JBS issues)
> 
> In this PR, we AOT-initialize `MethodHandleImpl` and its inner classes. This is a more authentic snapshot of the state of `java.lang.invoke` during the assembly phase. We also avoid the need to add and maintain entries in the `cdsHeapVerifier.cpp` table.
> 
> I also added more code in `MethodHandleTest.java` to simulate potential usage patterns of `MethodHandle` by the Java core libraries. Hopefully this will reduce the likelihood for innocent core lib changes breaking the AOT assembly phase.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Comments from @liach and @ExE-Boss

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24956/files
  - new: https://git.openjdk.org/jdk/pull/24956/files/0f6a2e0a..a1e3743b

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

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

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

From liach at openjdk.org  Mon May  5 23:53:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 May 2025 23:53:17 GMT
Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner
 classes [v2]
In-Reply-To: <Xx7OLj80AjJ_Ay-yUz-Lgd9DRLg2QWyEn97WSrnvnxg=.c639e8e9-ba3c-4844-a0e2-d8bbcec728c1@github.com>
References: <JQCL1DGBobBWQqWeX3Ykuw1nZOis5D8k6kEllWluE0s=.a089b081-da05-436c-b0f7-ec021887ea57@github.com>
 <Xx7OLj80AjJ_Ay-yUz-Lgd9DRLg2QWyEn97WSrnvnxg=.c639e8e9-ba3c-4844-a0e2-d8bbcec728c1@github.com>
Message-ID: <EbhS0ferM7Z5YfWq09RQzb8ALc0xdE4Gx6e03lnxsA8=.69eb708e-e79d-4af8-a86d-3d47425e2fea@github.com>

On Mon, 5 May 2025 23:50:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is a general fix for all the "points to a static field that may hold a different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330).
>> 
>> AOT-cached method handles quite often refer to the static fields in `MethodHandleImpl` or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. `CDSHeapVerifier` makes a very conservative check for such static fields, but sometimes gives false positives (as in the above two JBS issues)
>> 
>> In this PR, we AOT-initialize `MethodHandleImpl` and its inner classes. This is a more authentic snapshot of the state of `java.lang.invoke` during the assembly phase. We also avoid the need to add and maintain entries in the `cdsHeapVerifier.cpp` table.
>> 
>> I also added more code in `MethodHandleTest.java` to simulate potential usage patterns of `MethodHandle` by the Java core libraries. Hopefully this will reduce the likelihood for innocent core lib changes breaking the AOT assembly phase.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments from @liach and @ExE-Boss

The Java code change and the BSM coverage looks good to me. Requiring another reviewer for hotspot changes.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24956#pullrequestreview-2816431978

From iklam at openjdk.org  Tue May  6 00:00:22 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 6 May 2025 00:00:22 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v3]
In-Reply-To: <ZuUJNLAVEybgdSqtFNnd109unHgX6jnx0Cht8Ta1pME=.99006b9f-e401-4afe-962a-e0d0778d9bb3@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <ZqN7me24ilvFxqQs47wNdM6lhli5RuQXWKP4fwRI4No=.4fae3be6-ceb5-4de2-b129-1fde746c0760@github.com>
 <ZuUJNLAVEybgdSqtFNnd109unHgX6jnx0Cht8Ta1pME=.99006b9f-e401-4afe-962a-e0d0778d9bb3@github.com>
Message-ID: <W1gHeNU9BePsc9JGnvIjl5sqePwJrd0t463YAW0Vd-0=.6d9c3c46-c181-4fff-875b-7bf76535ce4f@github.com>

On Mon, 5 May 2025 16:21:56 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @vnkozlov comments
>
> src/hotspot/share/cds/cdsConfig.cpp line 412:
> 
>> 410:     log_debug(aot,codecache,init)("AOTCache is not specified - AOTAdapterCaching is ignored");
>> 411:   }
>> 412: 
> 
> Also from merge?

That's from the merge. This block doesn't show up when you select "show all commits".

> src/hotspot/share/cds/metaspaceShared.cpp line 1018:
> 
>> 1016:     CDSConfig::disable_dumping_aot_code();
>> 1017:   }
>> 1018: 
> 
> Is this from merge form mainline?

That's from the merge. This block doesn't show up when you select "show all commits".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2074421751
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2074419749

From darcy at openjdk.org  Tue May  6 00:04:19 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 May 2025 00:04:19 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v2]
In-Reply-To: <Yq6-D4R6nlbAO0o2JRoY6bumZzFOF-qPXydXEQXCZW0=.d203192d-b0a6-45fa-a0ee-fe5c696f75e0@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <wJBc1rcduuMCPfc7CI3Tn_A6YhLzYK5ud07-8w9H4nw=.0c0e7cd5-442b-4c61-8fe7-1f47c4faf172@github.com>
 <tEd-3nOOvFsqe0N_g-ZrZd6BajGh__g8xAX_TCMtMqc=.85bce6f9-d2b3-497d-9d13-7c29c11c8db1@github.com>
 <Vzp1-2EuHMiew6z7hPwbTFUeIKDstOmgouf0k3mZAQk=.b410e965-7cb3-49f7-8e84-7b2c00b5471f@github.com>
 <B3J8EvoOg0aj_k8_ATiImnmhM_EkA8yuLLOIt3bNjmc=.75adabc8-8afb-4b48-96a4-22c57857a6d7@github.com>
 <5wQQJ5le6CtE87hya7Kq6A4g8wdu2O35bifSTumwY04=.fd00d8ba-d951-4fca-b9dd-bec50a676e7a@github.com>
 <I-JxMqSM__Ww1SBfZawoLfv3ZMQwKh5DTcckg_DIXPA=.c29bb83d-4aa0-4e8c-9f6a-fc70ff33fa3e@github.com>
 <Yq6-D4R6nlbAO0o2JRoY6bumZzFOF-qPXydXEQXCZW0=.d203192d-b0a6-45fa-a0ee-fe5c696f75e0@github.com>
Message-ID: <8qOP7ec0_eA9d8fV3KdnwM7aTMPis5H_wgr-rc5kxxw=.f6ffced2-54f3-4550-be25-1c2640fe9118@github.com>

On Fri, 2 May 2025 17:49:54 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Yes, I'm familiar with both this Java code and the intrinsic code.
> 
> Compare this with the much simpler proposed code. The checked multiplication `unsignedMultiplyExact` apparently performs two 64x64->64 multiplications, but on some architectures it might end up in a single 64x64->128 multiplication and one check. So the proposed code performs 6 such multiplications if the method returns + 5 ordinary multiplications in the worst case.
> 
> As a general rule, the simpler the code, the better the outcome of the optimizing compiler.
> 
> Again, to me there's no point in failing fast at the expense of the successful case.

Yes; we can always try to make simpler code faster if the need or interest arises.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25003#discussion_r2074441059

From kvn at openjdk.org  Tue May  6 00:06:14 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 6 May 2025 00:06:14 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v3]
In-Reply-To: <ZqN7me24ilvFxqQs47wNdM6lhli5RuQXWKP4fwRI4No=.4fae3be6-ceb5-4de2-b129-1fde746c0760@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <ZqN7me24ilvFxqQs47wNdM6lhli5RuQXWKP4fwRI4No=.4fae3be6-ceb5-4de2-b129-1fde746c0760@github.com>
Message-ID: <yNP11Gb38afqfu6aF2984evfQ4coNKqVuFtm43jIpck=.e8a42c1e-6b4b-47b2-9ee3-633a440461f6@github.com>

On Mon, 5 May 2025 01:00:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>> 
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
>> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
>> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
>> 
>> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
>> 
>> Examples:
>> 
>> 
>> # Create an AOT cache with a single command:
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> Hello World
>> Temporary AOTConfiguration recorded: foo.aot.config
>> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
>> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
>> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
>> AOTCache creation is complete: foo.aot 10240000 bytes
>> 
>> # Create logging file for the AOT cache assembly phase
>> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> 
>> 
>> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @vnkozlov comments

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2816460660

From swen at openjdk.org  Tue May  6 00:47:16 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 6 May 2025 00:47:16 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
Message-ID: <c3DUwjTlWLVBZRO3tRZYcg7vgZcyQPuet6F-CZSmwNs=.b4669794-6978-416c-82d7-a8ec72f54327@github.com>

On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 185:

> 183:         if (coder == another.coder) {
> 184:             return isLatin1(coder) ? StringLatin1.compareTo(val1, val2, count1, count2)
> 185:                               : StringUTF16.compareTo(val1, val2, count1, count2);

Suggestion:

            return isLatin1(coder) ? StringLatin1.compareTo(val1, val2, count1, count2)
                                                  : StringUTF16.compareTo(val1, val2, count1, count2);

As before, align the code

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 188:

> 186:         }
> 187:         return isLatin1(coder) ? StringLatin1.compareToUTF16(val1, val2, count1, count2)
> 188:                           : StringUTF16.compareToLatin1(val1, val2, count1, count2);

Suggestion:

        return isLatin1(coder) ? StringLatin1.compareToUTF16(val1, val2, count1, count2)
                                              : StringUTF16.compareToLatin1(val1, val2, count1, count2);

As before, align the code

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2074477815
PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2074478089

From jwaters at openjdk.org  Tue May  6 00:52:12 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 6 May 2025 00:52:12 GMT
Subject: RFR: 8355573: Remove kludge_c++11.h from jpackage code
In-Reply-To: <n0hxEGtixYaAjJrWVZ_segrizstoD7cFucoTpFBxQyk=.1a3ac19a-6935-4411-9457-c6b902559ea7@github.com>
References: <ABRXOAFnthURb4yuEcE4Ex-2Vz28YrnyXp6a3iFX0os=.96006b49-051d-4eda-9c29-7e3b34f0e3cb@github.com>
 <n0hxEGtixYaAjJrWVZ_segrizstoD7cFucoTpFBxQyk=.1a3ac19a-6935-4411-9457-c6b902559ea7@github.com>
Message-ID: <AAmJDvfSBLyNcUa5luzniM9g5l34gpU2ePtw-h0D1MI=.1f8589da-ae5b-4a21-850c-f7bdec049aab@github.com>

On Mon, 5 May 2025 22:23:04 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> kludge_c++11.h was introduced to work around older C++ versions not having access to C++ utilities like std::unique_ptr. Since we are already on C++14 (And hopefully will get C++17 soon) this workaround can be removed from jpackage code.
>
> src/jdk.jpackage/windows/native/common/MsiUtils.h line 35:
> 
>> 33: #include <new>
>> 34: #include <map>
>> 35: #include <memory>
> 
> Why this include was added?

It seemed to be needed to compile successfully back when I removed the kludge header (I couldn't figure out why). I can try again without the memory include using GitHub Actions to test instead if that is preferred.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24868#discussion_r2074480472

From jpai at openjdk.org  Tue May  6 01:22:13 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 01:22:13 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
Message-ID: <QCYyVKeHMY6KGNjoMIluL8juS-1BoE-nYGWWYURXZL8=.5cbe1262-6e9b-466e-b47b-cd95eea1222f@github.com>

On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 238:

> 236:      * {@return true if the byte array should be replaced due to increased capacity or coder change}
> 237:      * <ul>
> 238:      *     <li>The new coder is the different thn the old coder

Nit - typo, `thn` should have been `than`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2074495916

From jpai at openjdk.org  Tue May  6 01:27:14 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 01:27:14 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
Message-ID: <2fxlcQiP04IDV6Pau09mVCW2D9CVA8VxKPORPIm9zgQ=.c964cb3c-00ec-4316-a71b-6f0e0ac66895@github.com>

On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 240:

> 238:      *     <li>The new coder is the different thn the old coder
> 239:      *     <li>The new length is greater than to the current length
> 240:      *     <li>The new length is non-negative, as it might have overflowed due to an increment

I think this is a typo too and `non-negative` should have been `negative`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2074505941

From asemenyuk at openjdk.org  Tue May  6 01:29:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 6 May 2025 01:29:15 GMT
Subject: RFR: 8356219: jpackage places libapplauncher.so in incorrect location
 in the app image
Message-ID: <Rwar8nIPy6NFKCIAsW6asYMN_rj9s5LRMg3lQPlTFLg=.b763cd3d-9ff2-4f2f-8a33-2458363a7e93@github.com>

- Refactor PathGroup
 - Add test cases to PathGroupTest
 - Update UsrTreeTest to verify "libapplauncher.so" is placed in the correct location in the package
 - Refactor UsrTreeTest to use JPackageCommand assert functions

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

Commit messages:
 - Make JPackageCommand.assertFileInAppImage() public. Test location of the "libapplauncher.so"
 - Fix bug in PathGroup that resulted in copying "libapplauncher.so" in wrong location

Changes: https://git.openjdk.org/jdk/pull/25051/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25051&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356219
  Stats: 814 lines in 6 files changed: 641 ins; 64 del; 109 mod
  Patch: https://git.openjdk.org/jdk/pull/25051.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25051/head:pull/25051

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

From asemenyuk at openjdk.org  Tue May  6 01:29:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 6 May 2025 01:29:15 GMT
Subject: RFR: 8356219: jpackage places libapplauncher.so in incorrect
 location in the app image
In-Reply-To: <Rwar8nIPy6NFKCIAsW6asYMN_rj9s5LRMg3lQPlTFLg=.b763cd3d-9ff2-4f2f-8a33-2458363a7e93@github.com>
References: <Rwar8nIPy6NFKCIAsW6asYMN_rj9s5LRMg3lQPlTFLg=.b763cd3d-9ff2-4f2f-8a33-2458363a7e93@github.com>
Message-ID: <Lcr2FFylUA6hLTEcL7J3Oy4gto7mVmMz9RC1j2BZSck=.cb2d3bb5-6ab4-427b-a5fa-5a3be9aa35bf@github.com>

On Mon, 5 May 2025 21:44:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Refactor PathGroup
>  - Add test cases to PathGroupTest
>  - Update UsrTreeTest to verify "libapplauncher.so" is placed in the correct location in the package
>  - Refactor UsrTreeTest to use JPackageCommand assert functions

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/25051#issuecomment-2852936934

From almatvee at openjdk.org  Tue May  6 01:38:16 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 6 May 2025 01:38:16 GMT
Subject: RFR: 8355573: Remove kludge_c++11.h from jpackage code
In-Reply-To: <AAmJDvfSBLyNcUa5luzniM9g5l34gpU2ePtw-h0D1MI=.1f8589da-ae5b-4a21-850c-f7bdec049aab@github.com>
References: <ABRXOAFnthURb4yuEcE4Ex-2Vz28YrnyXp6a3iFX0os=.96006b49-051d-4eda-9c29-7e3b34f0e3cb@github.com>
 <n0hxEGtixYaAjJrWVZ_segrizstoD7cFucoTpFBxQyk=.1a3ac19a-6935-4411-9457-c6b902559ea7@github.com>
 <AAmJDvfSBLyNcUa5luzniM9g5l34gpU2ePtw-h0D1MI=.1f8589da-ae5b-4a21-850c-f7bdec049aab@github.com>
Message-ID: <qwkzTiWxKK8bc5znZS_Y7umLX1cSbNX1Y_Tc7MUJCSw=.a9002222-6e69-4ea1-bcff-36c8e441d266@github.com>

On Tue, 6 May 2025 00:49:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/jdk.jpackage/windows/native/common/MsiUtils.h line 35:
>> 
>>> 33: #include <new>
>>> 34: #include <map>
>>> 35: #include <memory>
>> 
>> Why this include was added?
>
> It seemed to be needed to compile successfully back when I removed the kludge header (I couldn't figure out why). I can try again without the memory include using GitHub Actions to test instead if that is preferred.

I think it is required for `std::unique_ptr` in this file. Strange that it did compiled before. Maybe it was included indirectly somehow. Looks fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24868#discussion_r2074537642

From almatvee at openjdk.org  Tue May  6 01:38:15 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 6 May 2025 01:38:15 GMT
Subject: RFR: 8355573: Remove kludge_c++11.h from jpackage code
In-Reply-To: <ABRXOAFnthURb4yuEcE4Ex-2Vz28YrnyXp6a3iFX0os=.96006b49-051d-4eda-9c29-7e3b34f0e3cb@github.com>
References: <ABRXOAFnthURb4yuEcE4Ex-2Vz28YrnyXp6a3iFX0os=.96006b49-051d-4eda-9c29-7e3b34f0e3cb@github.com>
Message-ID: <tr907MJ88bcIPBpFlvYspzHza6sp8HAkuAEbYuBEfPs=.bdc0fcf2-abe4-49c6-9335-c834a455bd7c@github.com>

On Fri, 25 Apr 2025 06:14:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> kludge_c++11.h was introduced to work around older C++ versions not having access to C++ utilities like std::unique_ptr. Since we are already on C++14 (And hopefully will get C++17 soon) this workaround can be removed from jpackage code.

Marked as reviewed by almatvee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24868#pullrequestreview-2816572454

From jpai at openjdk.org  Tue May  6 01:41:23 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 01:41:23 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
Message-ID: <Q3mFphXP94IQIDZx-aIjwPi5OChb1NbVneZg9Lc0TiA=.10b1cc44-2039-40b8-ad1e-3a2b4ff48d8b@github.com>

On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 277:

> 275:                 // copy all bytes to new larger buffer
> 276:                 value = Arrays.copyOf(value,
> 277:                         newCapacity(value, newCoder, minimumCapacity) << newCoder);

Would this benefit with an `assert` to verify that the new buffer length being proposed is not lesser than the current buffer's length (thus truncating content). Something like:


// copy all bytes to new larger buffer
int newLen = newCapacity(value, newCoder, minimumCapacity) << newCoder;
assert newLen >= value.length : "bad new length " + newLen + " for buffer's length " + value.length; 
value = Arrays.copyOf(value, newLen);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2074546636

From jpai at openjdk.org  Tue May  6 01:53:14 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 01:53:14 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
Message-ID: <W2CJl9M8mA24tsEVO0Qv9OywpsGWyhrRIuPWdSldxK0=.8cb7a836-01ba-4095-9166-7b3e65b244ef@github.com>

On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 309:

> 307:         if (minimumCapacity - oldCapacity > 0) {
> 308:             value = Arrays.copyOf(value,
> 309:                     newCapacity(value, coder, minimumCapacity) << coder);

Same question about whether we should assert that the new length we determine for the buffer is not lesser than the current buffer length.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2074579962

From jpai at openjdk.org  Tue May  6 02:04:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 02:04:18 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v11]
In-Reply-To: <bY6wxELBjJnRQ5co73NgJC5baGtnY5UKezuQXCvYU5E=.82004266-7468-484d-a28c-85852d06f8d9@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <bY6wxELBjJnRQ5co73NgJC5baGtnY5UKezuQXCvYU5E=.82004266-7468-484d-a28c-85852d06f8d9@github.com>
Message-ID: <PBiSYA5aqDEnMIqV_0e7cvAbmc6YmO78SqKDx168qsU=.2b4c3790-b3c6-4ce3-a916-36a5e4c402a4@github.com>

On Thu, 1 May 2025 08:45:06 GMT, Markus KARG <duke at openjdk.org> 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 proposal by Daniel: If there's no change to this file the copyright year update could be reverted?

Hello Markus, it's been a while since this PR was merged with latest master branch in mainline. Could you update the PR to do that?

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

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

From darcy at openjdk.org  Tue May  6 02:24:17 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 May 2025 02:24:17 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v11]
In-Reply-To: <LSOrFyZ6177AukhxK4GbbP3dNm2ekhGo6gfjhQEct3o=.ac3069f9-1905-4c9e-8b4a-3e725ed57476@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <bY6wxELBjJnRQ5co73NgJC5baGtnY5UKezuQXCvYU5E=.82004266-7468-484d-a28c-85852d06f8d9@github.com>
 <eIAbKE11RsBYYxLFsdl8mbp9K6FEZaJ0GrHxWWNbsEc=.39224a40-5b72-4e3f-b2fd-cb8226dd2f92@github.com>
 <b_BF-hOVcyul6ERad9IpcJqoqzhd_KvXQjc0duqeyGI=.fa116284-73e8-4695-912e-f5fccbc3da4b@github.com>
 <2jc5ZuZmlzsOBJOD9VwObHfox_2VX8Dmy6AhasVXp3w=.4cabab81-4d24-453d-ab46-eb272f6e7c27@github.com>
 <LSOrFyZ6177AukhxK4GbbP3dNm2ekhGo6gfjhQEct3o=.ac3069f9-1905-4c9e-8b4a-3e725ed57476@github.com>
Message-ID: <5FwC5VTxPYBUNMq8nPPyFxYQ4BMZzaiVxbm1CW9Zbi8=.1b4c9d8f-642b-4666-9961-d77841e39f8e@github.com>

On Thu, 1 May 2025 17:18:07 GMT, Markus KARG <duke at openjdk.org> wrote:

>> There are subtleties and perhaps surprises in `@inheritDoc`, but that doesn't necessarily imply the current behavior is buggy.
>
> So it is actually *wanted* behavior that in one situation the text *is* inherited, but at `String.java` no text is inherited at all? ? Could not find any hint about that in the JavaDoc manual.

> So it is actually _wanted_ behavior that in one situation the text _is_ inherited, but at `String.java` no text is inherited at all? ? Could not find any hint about that in the JavaDoc manual.

The inheritDoc functionality of javadoc was reworked relatively recently so I would assume the current behavior is intentional, even if not documented.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2074634715

From almatvee at openjdk.org  Tue May  6 02:48:15 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 6 May 2025 02:48:15 GMT
Subject: RFR: 8356219: jpackage places libapplauncher.so in incorrect
 location in the app image
In-Reply-To: <Rwar8nIPy6NFKCIAsW6asYMN_rj9s5LRMg3lQPlTFLg=.b763cd3d-9ff2-4f2f-8a33-2458363a7e93@github.com>
References: <Rwar8nIPy6NFKCIAsW6asYMN_rj9s5LRMg3lQPlTFLg=.b763cd3d-9ff2-4f2f-8a33-2458363a7e93@github.com>
Message-ID: <Wu7zZAEiOz8CGvyrc9Z8TnZXqlgke9jmLESYZDlwXec=.59bef08a-dbe0-447e-a4d8-78e1c3af5e7f@github.com>

On Mon, 5 May 2025 21:44:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Refactor PathGroup
>  - Add test cases to PathGroupTest
>  - Update UsrTreeTest to verify "libapplauncher.so" is placed in the correct location in the package
>  - Refactor UsrTreeTest to use JPackageCommand assert functions

Looks good with minor comment.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/ApplicationLayout.java line 32:

> 30: public record ApplicationLayout(Path launchersDirectory, Path appDirectory,
> 31:         Path runtimeDirectory, Path runtimeHomeDirectory, Path appModsDirectory,
> 32:         Path destktopIntegrationDirectory, Path contentDirectory, Path libapplauncher) {

`destktop` -> `desktop`

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

PR Review: https://git.openjdk.org/jdk/pull/25051#pullrequestreview-2816721573
PR Review Comment: https://git.openjdk.org/jdk/pull/25051#discussion_r2074650278

From vlivanov at openjdk.org  Tue May  6 02:48:16 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 6 May 2025 02:48:16 GMT
Subject: RFR: 8355698: JDK not supporting sleef could cause exception at
 runtime after JDK-8353786
In-Reply-To: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
Message-ID: <1dojSNtcbxGAxR2KWo_bqJficSV_QsTcWU2xlo3kxE8=.8c9902eb-017b-4aba-a1ae-9b4fb88ba18f@github.com>

On Mon, 28 Apr 2025 10:34:49 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> 
> Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a released jdk not supportting sleef (for any reason, e.g. low gcc version, intrinsic not supported, rvv not supported, and so on) runs on machine support vector operation (e.g. on riscv, it supports rvv), it can not call into sleef, but will not fail either, it falls back to java scalar version implementation.
> But after [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), it will cause an exception thrown at runtime.
> 
> This change the behaviour of existing jdk, and it should not throw exception anyway.
> 
> @iwanowww @RealFYang 
> 
> Thanks!

Thanks, Li. I think I have a better understanding now how it all works across platforms.

I agree with Andrew that it's highly undesireable to have divergence across JDK builds, but I don't have a good understanding how mature toolchain support is when it comes to vector intrinsics SLEEF library relies on.

As of now, producing empty native library is the only way to communicate that a vector math library isn't properly built.

So, 2 problems to address:
  (1) JDK build may produce an empty vector math library (and no build failures);
  (2) vector math library is built unconditionally (there's no way to configure JDK build to skip it).

Speaking of SVML, it requires GCC 4.9+ and MSVC 2017. According to JDK build documentation [1], newer toolchain versions are required for JDK build. So, it should be fine to remove GCC version checks. (JDK-8355656 is reported for a JDK build using Clang. I have no idea whether Clang can build SVML stubs or not.) 

So, the stop-the-gap fix for JDK-8355698 is to disable SLEEF build when toolchain doesn't have proper support. Alternatively, VectorMathLibrary can probe the library to ensure it is not empty [2]. 

[1] https://github.com/openjdk/jdk/blob/master/doc/building.md

[2] 

diff --git a/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java b/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java
index 4729235e2d9..9f0abb9afa1 100644
--- a/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java
+++ b/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java
@@ -189,6 +189,16 @@ public boolean isSupported(Operator op, VectorSpecies<?> vspecies) {
     private static class SLEEF implements Library {
         static {
             VectorSupport.loadNativeLibrary("sleef");
+            ensureValidLibrary();
+        }
+
+        private static void ensureValidLibrary() {
+            // Probe an arbitrary entry point to ensure the library is not empty.
+            // JDK build of SLEEF-based vector math library may produce an empty library when
+            // proper toolchain support is absent. Until it is fixed, ensure the corresponding
+            // native library is not empty.
+            // Throws an exception on lookup failure which triggers a switch to Java-based implementation.
+            LOOKUP.findOrThrow(LIBRARY.symbolName(VectorOperators.SIN, FloatVector.SPECIES_64));
         }
 
         private static String suffix(VectorShape vshape, boolean isShapeAgnostic) {

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

PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2853122819

From asemenyuk at openjdk.org  Tue May  6 03:25:07 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 6 May 2025 03:25:07 GMT
Subject: RFR: 8356219: jpackage places libapplauncher.so in incorrect
 location in the app image [v2]
In-Reply-To: <Rwar8nIPy6NFKCIAsW6asYMN_rj9s5LRMg3lQPlTFLg=.b763cd3d-9ff2-4f2f-8a33-2458363a7e93@github.com>
References: <Rwar8nIPy6NFKCIAsW6asYMN_rj9s5LRMg3lQPlTFLg=.b763cd3d-9ff2-4f2f-8a33-2458363a7e93@github.com>
Message-ID: <2qiByi-Qtb91lGRl1Bv21y6r-kIdsYU3EGMcqRK5qNU=.f138fa2f-e7a1-45cb-8f8e-658df628213c@github.com>

> - Refactor PathGroup
>  - Add test cases to PathGroupTest
>  - Update UsrTreeTest to verify "libapplauncher.so" is placed in the correct location in the package
>  - Refactor UsrTreeTest to use JPackageCommand assert functions

Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright year
 - Fix a typo in ApplicationLayout

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25051/files
  - new: https://git.openjdk.org/jdk/pull/25051/files/fa35bfbc..2ef2f889

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

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

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

From asemenyuk at openjdk.org  Tue May  6 03:25:08 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 6 May 2025 03:25:08 GMT
Subject: RFR: 8356219: jpackage places libapplauncher.so in incorrect
 location in the app image [v2]
In-Reply-To: <Wu7zZAEiOz8CGvyrc9Z8TnZXqlgke9jmLESYZDlwXec=.59bef08a-dbe0-447e-a4d8-78e1c3af5e7f@github.com>
References: <Rwar8nIPy6NFKCIAsW6asYMN_rj9s5LRMg3lQPlTFLg=.b763cd3d-9ff2-4f2f-8a33-2458363a7e93@github.com>
 <Wu7zZAEiOz8CGvyrc9Z8TnZXqlgke9jmLESYZDlwXec=.59bef08a-dbe0-447e-a4d8-78e1c3af5e7f@github.com>
Message-ID: <h-KDHjgh0OhNdzICC6Be9d2-rkKmF15oN1ANQKZ_VE0=.6976b2e1-8252-48e9-85e7-cf038c70f430@github.com>

On Tue, 6 May 2025 02:36:27 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update copyright year
>>  - Fix a typo in ApplicationLayout
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/ApplicationLayout.java line 32:
> 
>> 30: public record ApplicationLayout(Path launchersDirectory, Path appDirectory,
>> 31:         Path runtimeDirectory, Path runtimeHomeDirectory, Path appModsDirectory,
>> 32:         Path destktopIntegrationDirectory, Path contentDirectory, Path libapplauncher) {
> 
> `destktop` -> `desktop`

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25051#discussion_r2074670384

From duke at openjdk.org  Tue May  6 03:49:18 2025
From: duke at openjdk.org (duke)
Date: Tue, 6 May 2025 03:49:18 GMT
Subject: Withdrawn: 8349543: LinkedBlockingDeque does not immediately throw
 InterrruptedException in put/take
In-Reply-To: <Da_VhZrKMVCSNPN6BSYHrYLsU3MnehmJZcI0ZJUzaJ8=.eb25a512-e279-47f4-ae14-11c965f204cd@github.com>
References: <Da_VhZrKMVCSNPN6BSYHrYLsU3MnehmJZcI0ZJUzaJ8=.eb25a512-e279-47f4-ae14-11c965f204cd@github.com>
Message-ID: <8pU2ZhgpJaeMTk5IQWbq9CcTNQc402BXIfAjX5T9CFg=.cbc90bd5-0cf7-4a7b-9d87-dce9ba429051@github.com>

On Wed, 5 Feb 2025 15:36:15 GMT, kabutz <duke at openjdk.org> wrote:

> The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Tue May  6 04:25:26 2025
From: duke at openjdk.org (duke)
Date: Tue, 6 May 2025 04:25:26 GMT
Subject: Withdrawn: 8337143: (fc, fs) Move filesystem-related native objects
 from libnio to libjava
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <DKSRbY-vFfCNA5WktntFIaVut3S3vBgbvBAFoWK-STg=.6706b813-923e-4f1c-b39d-9623ab6888d0@github.com>

On Wed, 24 Jul 2024 19:11:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> 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.

This pull request has been closed without being integrated.

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

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

From alan.bateman at oracle.com  Tue May  6 06:03:48 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 6 May 2025 07:03:48 +0100
Subject: JavaDoc: NPE in java.net.http.HttpHeaders
In-Reply-To: <Osz5cwLv8dCufch8gyhKOQf-jqglf72M1rNOEiLPtWbFrQwwUNo6ump8KA3rCi5ZaTGtWiIFQgII55g50WurfP6rvKumwWyfIgGZGVwckCo=@protonmail.com>
References: <Osz5cwLv8dCufch8gyhKOQf-jqglf72M1rNOEiLPtWbFrQwwUNo6ump8KA3rCi5ZaTGtWiIFQgII55g50WurfP6rvKumwWyfIgGZGVwckCo=@protonmail.com>
Message-ID: <febf46a8-de04-491c-9187-b03a48c7c134@oracle.com>

On 05/05/2025 21:05, Steffen Nie?ing wrote:
> Hello,
>
> recently I've discovered that the JavaDoc of the instance methods of 
> java.net.http.HttpHeaders lacks the throws declarations for 
> NullPointerExceptions. The static creator method `of` contains such a 
> declaration. So the snippet `HttpHeaders.of(null, null)` is documented 
> to throw an NPE, while the snippet `HttpHeaders.of(Map.of(), (k, v) -> 
> true).firstValue(null)` currently isn't.
>
> I'd propose to add the missing JavaDoc throws declarations to the 
> #allValues(String), #firstValueAsLong(String) and #firstValue(String) 
> methods as they all can throw an NPE through `requireNonNull(name);` 
> in the allValues method.
>
> If there's interest in this change, I'd appreciate if anyone would 
> like to sponsor me on this one.
>
Can you bring this to net-dev to discuss? net-dev is where the 
networking API and the HTTP client are maintained.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250506/71768e83/attachment.htm>

From jpai at openjdk.org  Tue May  6 06:39:13 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 06:39:13 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v4]
In-Reply-To: <R0Z0V9chwQzLGtDUS72ouLffcUSv4dRBzk04ykFJT_8=.de0158e4-9892-4d47-abc0-f2c3540e927c@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com>
 <uLQ9stJ_vYOCsQv0-aUg0lNyaEaBbql5Wjd8ueTtAmI=.c19e3ba5-4e93-4ab5-8c76-54dedbdfd756@github.com>
 <R0Z0V9chwQzLGtDUS72ouLffcUSv4dRBzk04ykFJT_8=.de0158e4-9892-4d47-abc0-f2c3540e927c@github.com>
Message-ID: <rasxfoWU6irGim8uQjSSZaQg9_V7zdZ0swlDjBoE8S8=.12d34c7c-92fe-413f-a845-dcfaf1a2b888@github.com>

On Mon, 5 May 2025 15:52:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 139:
>> 
>>> 137:      */
>>> 138:     private static OperatingSystem initOS() {
>>> 139:         // Called lazily, valueOf has overhead
>> 
>> Hello Chen, in context of this bug fix, what kind of overhead does `valueOf()` have?
>> The (pre-existing) comment on this `initOS()` method sets an expectation that it will be called from the static initializer of this `OperatingSystem` class and thus it expects an `ExceptionInInitializerError` to be thrown by the static initiliazer, if the operating system name isn't recognized. Any access to `OperatingSystem` class would then have resulted in a `NoClassDefFoundError`. With this proposed change, the callers of `OperatingSystem.current()` would now start seeing an `IllegalArgumentException` if for any reason the operating system name isn't recognized.
>
> Enum.valueOf -> Class.enumConstantDirectory -> Class.getEnumConstantsShared -> Method.invoke -> MethodHandleAccessorFactory.makeSpecializedTarget(isStatic = true) -> MethodHandles.dropArguments -> LambdaForm.editor -> bytecode generation and loading because this currently cannot be pregenerated by CDS archive.
> 
> If this class is broken, this would probably already surface at build time because this is used by jlink; otherwise it would have surfaced in Process tests. I don't think ensuring EIIE vs IAE is worth a test here.

Thank you Chen for updating the issue type of bug.

> If this class is broken, this would probably already surface at build time because this is used by jlink; otherwise it would have surfaced in Process tests. I don't think ensuring EIIE vs IAE is worth a test here.

The current bug fix I think should just address the incorrect result from `captureCallState()`.

If the change to OperatingSystem class has practical improvements to the startup performance, then I think it's worth proposing. I suggest we do it in a separate and independent PR and the discussion and review for that change would have to take into account the existing comment in that class and see if it is no longer necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2074814448

From redestad at openjdk.org  Tue May  6 07:47:16 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 6 May 2025 07:47:16 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v5]
In-Reply-To: <bF_OnxOCbrFO-atOiCBXIJp_JxT2__hFunyZV-aTPs0=.2da5ecfe-81e1-4723-9bab-65aec9c808e2@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
 <bF_OnxOCbrFO-atOiCBXIJp_JxT2__hFunyZV-aTPs0=.2da5ecfe-81e1-4723-9bab-65aec9c808e2@github.com>
Message-ID: <-h6nC56_HwMWSYMJsNLcMG6CLNaXVU7YaDwZJdVYrjE=.fb97d835-27b2-48ec-b5e2-6133b8feac16@github.com>

On Mon, 5 May 2025 17:29:33 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> A fix to throw `OutOfMemoryError`, as done in releases ? 23.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Increased min heap size to 8G.

LGTM

src/java.base/share/classes/java/lang/StringConcatHelper.java line 435:

> 433:     static String doConcat(String s1, String s2) {
> 434:         byte coder = (byte) (s1.coder() | s2.coder());
> 435:         int newLength = checkOverflow(s1.length() + s2.length()) << coder;

Might be mildly inefficient for this case since `checkOverflow` is designed for the compound length+coder `long`. Since this is only used in the simple path it should be easy for JITs to optimize, though.

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

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25038#pullrequestreview-2817218650
PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2074907577

From cstein at openjdk.org  Tue May  6 08:07:24 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 May 2025 08:07:24 GMT
Subject: RFR: 8354260: Launcher help text is wrong for -Xms
Message-ID: <GNQoFX12jZpR2aUADOyHxNQZLmKb1dvi3-xavm2FcGQ=.fc94ed09-4d39-45f8-bb14-fb9f2041bcc2@github.com>

Please review this update to synchronize the extra help text for `-Xms` with the description given in the manpage.

Copied from the issue:
> The launcher help text for -Xms is wrong and should be updated to match the manpage description. The actual meaning of -Xms is that it sets both the initial and minimum Java heap size, not just the initial Java heap size.
>
> ````
> $ java -X
> ...
> -Xms<size> set initial Java heap size
> ````
>
> From the manpage:
> ````
> `-Xms` *size*
> : Sets the minimum and the initial size (in bytes) of the heap. This value
>     must be a multiple of 1024 and greater than 1 MB. Append the letter `k` or
>     `K` to indicate kilobytes, `m` or `M` to indicate megabytes, or `g` or `G`
>     to indicate gigabytes. The following examples show how to set the size of
>     allocated memory to 6 MB using various units:
> ````

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

Commit messages:
 - 8354260: Launcher help text is wrong for -Xms

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

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

From jwilhelm at openjdk.org  Tue May  6 08:13:21 2025
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 6 May 2025 08:13:21 GMT
Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2]
In-Reply-To: <OQFS9tEyTK4cXqq9upD-EH8-B3H_LB0nfBAHkW-daXk=.fd5763c2-a86d-4b0b-9857-c8a70542ad31@github.com>
References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
 <OQFS9tEyTK4cXqq9upD-EH8-B3H_LB0nfBAHkW-daXk=.fd5763c2-a86d-4b0b-9857-c8a70542ad31@github.com>
Message-ID: <pWonAs5Ni8f4Rqu8PqkUqb7Fmtj_LhceOiuZOI_KQPk=.47fe83c7-d0a6-4e4e-bbc5-101a9b2c083a@github.com>

On Sun, 4 May 2025 16:21:41 GMT, Markus KARG <duke at openjdk.org> 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`.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Undone copyright update of otherwise unchanged file.
>  - Update Of.java
>    
>    Applied changnes proposed by @liach: "the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise."

There is some wording around this topic in the guide already:
_In order to prepare the community for your patch, please socialize your idea on the relevant [mailing lists](https://openjdk.org/guide/#mailing-lists). Almost all changes, and in particular any API changes, must go this route and have a broad agreement in place before there is any point in presenting code._

I've added the suggested text to clarify this paragraph: https://github.com/openjdk/guide/pull/150

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

PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2853649815

From jsikstro at openjdk.org  Tue May  6 08:18:12 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 6 May 2025 08:18:12 GMT
Subject: RFR: 8354260: Launcher help text is wrong for -Xms
In-Reply-To: <GNQoFX12jZpR2aUADOyHxNQZLmKb1dvi3-xavm2FcGQ=.fc94ed09-4d39-45f8-bb14-fb9f2041bcc2@github.com>
References: <GNQoFX12jZpR2aUADOyHxNQZLmKb1dvi3-xavm2FcGQ=.fc94ed09-4d39-45f8-bb14-fb9f2041bcc2@github.com>
Message-ID: <20rwAIBCR6mR5Jta7t9j54b_GBK8vDJt26816MUjOvs=.92d66219-83fa-405d-be90-ab9a187ed769@github.com>

On Tue, 6 May 2025 08:02:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this update to synchronize the extra help text for `-Xms` with the description given in the manpage.
> 
> Copied from the issue:
>> The launcher help text for -Xms is wrong and should be updated to match the manpage description. The actual meaning of -Xms is that it sets both the initial and minimum Java heap size, not just the initial Java heap size.
>>
>> ````
>> $ java -X
>> ...
>> -Xms<size> set initial Java heap size
>> ````
>>
>> From the manpage:
>> ````
>> `-Xms` *size*
>> : Sets the minimum and the initial size (in bytes) of the heap. This value
>>     must be a multiple of 1024 and greater than 1 MB. Append the letter `k` or
>>     `K` to indicate kilobytes, `m` or `M` to indicate megabytes, or `g` or `G`
>>     to indicate gigabytes. The following examples show how to set the size of
>>     allocated memory to 6 MB using various units:
>> ````

Not really my area but I think this is good. Are the localized texts (in `launcher_<lang>.properties`) updated at a later time?

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

Marked as reviewed by jsikstro (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25058#pullrequestreview-2817313879

From swen at openjdk.org  Tue May  6 08:25:19 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 6 May 2025 08:25:19 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v5]
In-Reply-To: <-h6nC56_HwMWSYMJsNLcMG6CLNaXVU7YaDwZJdVYrjE=.fb97d835-27b2-48ec-b5e2-6133b8feac16@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
 <bF_OnxOCbrFO-atOiCBXIJp_JxT2__hFunyZV-aTPs0=.2da5ecfe-81e1-4723-9bab-65aec9c808e2@github.com>
 <-h6nC56_HwMWSYMJsNLcMG6CLNaXVU7YaDwZJdVYrjE=.fb97d835-27b2-48ec-b5e2-6133b8feac16@github.com>
Message-ID: <NyM7mLFCbMU3b4zMZdQ_5RmPpAeUenkhGmq4QmKyamc=.5b297f0b-a91d-4e56-a2cc-13a32d1e2665@github.com>

On Tue, 6 May 2025 07:44:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Increased min heap size to 8G.
>
> src/java.base/share/classes/java/lang/StringConcatHelper.java line 435:
> 
>> 433:     static String doConcat(String s1, String s2) {
>> 434:         byte coder = (byte) (s1.coder() | s2.coder());
>> 435:         int newLength = checkOverflow(s1.length() + s2.length()) << coder;
> 
> Might be mildly inefficient for this case since `checkOverflow` is designed for the compound length+coder `long`. Since this is only used in the simple path it should be easy for JITs to optimize, though.

@ForceInline
    static int checkOverflow(int value) {
        if (value >= 0) {
            return value;
        }
        throw new OutOfMemoryError("Overflow: String length out of range");
    }

    private static long checkOverflow(long lengthCoder) {
        if ((int)lengthCoder >= 0) {
            return lengthCoder;
        }
        throw new OutOfMemoryError("Overflow: String length out of range");
    }

@cl4es There are two checkOverflow methods

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2074971917

From swen at openjdk.org  Tue May  6 08:44:24 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 6 May 2025 08:44:24 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v3]
In-Reply-To: <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com>
Message-ID: <5SoKycpAXGw1Z_svDIsGwNXFM25YTooOvASFZjI38xY=.663b5878-597e-437d-b077-80aed0880cde@github.com>

On Mon, 5 May 2025 17:13:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix empty line at the end of a third file
>  - Fix empty line at the end of another file
>  - Fix empty line at the end of a file

src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 74:

> 72:         // The Cartesian product : (int.class, long.class) x ("errno", ...)
> 73:         // Do not use Streams in order to enable "early" use in the init sequence.
> 74:         for (Class<?> c : List.of(int.class, long.class)) {

Suggestion:

        for (Class<?> c : new Class<?>[] {int.class, long.class}) {

Isn't this safer to use during early initialization?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2075003232

From rgiulietti at openjdk.org  Tue May  6 08:47:14 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 6 May 2025 08:47:14 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v5]
In-Reply-To: <NyM7mLFCbMU3b4zMZdQ_5RmPpAeUenkhGmq4QmKyamc=.5b297f0b-a91d-4e56-a2cc-13a32d1e2665@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
 <bF_OnxOCbrFO-atOiCBXIJp_JxT2__hFunyZV-aTPs0=.2da5ecfe-81e1-4723-9bab-65aec9c808e2@github.com>
 <-h6nC56_HwMWSYMJsNLcMG6CLNaXVU7YaDwZJdVYrjE=.fb97d835-27b2-48ec-b5e2-6133b8feac16@github.com>
 <NyM7mLFCbMU3b4zMZdQ_5RmPpAeUenkhGmq4QmKyamc=.5b297f0b-a91d-4e56-a2cc-13a32d1e2665@github.com>
Message-ID: <ZjPctgxBf_YlOkTF_ij8iUwFop3feVFf9fMUcTt3J-w=.7baf9f98-904d-4dda-867c-6c4ecfb0235a@github.com>

On Tue, 6 May 2025 08:22:51 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringConcatHelper.java line 435:
>> 
>>> 433:     static String doConcat(String s1, String s2) {
>>> 434:         byte coder = (byte) (s1.coder() | s2.coder());
>>> 435:         int newLength = checkOverflow(s1.length() + s2.length()) << coder;
>> 
>> Might be mildly inefficient for this case since `checkOverflow` is designed for the compound length+coder `long`. Since this is only used in the simple path it should be easy for JITs to optimize, though.
>
> @ForceInline
>     static int checkOverflow(int value) {
>         if (value >= 0) {
>             return value;
>         }
>         throw new OutOfMemoryError("Overflow: String length out of range");
>     }
> 
>     private static long checkOverflow(long lengthCoder) {
>         if ((int)lengthCoder >= 0) {
>             return lengthCoder;
>         }
>         throw new OutOfMemoryError("Overflow: String length out of range");
>     }
> 
> @cl4es There are two checkOverflow methods

Exactly. The one used here is the (int) variant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2075011584

From swen at openjdk.org  Tue May  6 08:50:15 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 6 May 2025 08:50:15 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v3]
In-Reply-To: <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com>
Message-ID: <kdQ0cQYPOnJu1nON4BYTube75JfjVWp-2CfsPfz2AU8=.f1fe7acf-a054-4e19-b51f-51e092daef39@github.com>

On Mon, 5 May 2025 17:13:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix empty line at the end of a third file
>  - Fix empty line at the end of another file
>  - Fix empty line at the end of a file

src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 390:

> 388:                 return MhUtil.findVirtual(LOOKUP, Arena.class, "close",
> 389:                         MethodType.methodType(void.class));
> 390:         }

Suggestion:

        return switch (index) {
            case NON_NEGATIVE_INT -> MhUtil.findStatic(LOOKUP, "nonNegative",
                    MethodType.methodType(boolean.class, int.class));
            case SUCCESS_INT -> MhUtil.findStatic(LOOKUP, "success",
                    MethodType.methodType(int.class, int.class, MemorySegment.class));
            case ERROR_INT -> MhUtil.findStatic(LOOKUP, "error",
                    MethodType.methodType(int.class, MethodHandle.class, int.class, MemorySegment.class));
            case NON_NEGATIVE_LONG -> MhUtil.findStatic(LOOKUP, "nonNegative",
                    MethodType.methodType(boolean.class, long.class));
            case SUCCESS_LONG -> MhUtil.findStatic(LOOKUP, "success",
                    MethodType.methodType(long.class, long.class, MemorySegment.class));
            case ERROR_LONG -> MhUtil.findStatic(LOOKUP, "error",
                    MethodType.methodType(long.class, MethodHandle.class, long.class, MemorySegment.class));
            case ACQUIRE_ARENA -> MhUtil.findStatic(LOOKUP, "acquireArena",
                    MethodType.methodType(Arena.class));
            case ALLOCATE -> MhUtil.findStatic(LOOKUP, "allocate",
                    MethodType.methodType(MemorySegment.class, Arena.class));
            case ARENA_CLOSE -> MhUtil.findVirtual(LOOKUP, Arena.class, "close",
                    MethodType.methodType(void.class));
            default -> throw new InternalError("Unknown index: " + index);
        };

Switch statement can be replaced with enhanced 'switch'

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2075016584

From cstein at openjdk.org  Tue May  6 08:59:20 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 May 2025 08:59:20 GMT
Subject: RFR: 8354260: Launcher help text is wrong for -Xms
In-Reply-To: <20rwAIBCR6mR5Jta7t9j54b_GBK8vDJt26816MUjOvs=.92d66219-83fa-405d-be90-ab9a187ed769@github.com>
References: <GNQoFX12jZpR2aUADOyHxNQZLmKb1dvi3-xavm2FcGQ=.fc94ed09-4d39-45f8-bb14-fb9f2041bcc2@github.com>
 <20rwAIBCR6mR5Jta7t9j54b_GBK8vDJt26816MUjOvs=.92d66219-83fa-405d-be90-ab9a187ed769@github.com>
Message-ID: <AO5OPl-oDes6QkDLWIrR6us_ejplTt-DhOAwdeDXLYQ=.df1fbe3d-ce3a-4a86-b206-3b8994e06a02@github.com>

On Tue, 6 May 2025 08:15:16 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Are the localized texts (in launcher_<lang>.properties) updated at a later time?

Yes. We only update the English variant without the `_<lang>` classifier; the rest will be translated and updated in pre-release step. See for example "[8347498: JDK 24 RDP2 L10n resource files update](https://bugs.openjdk.org/browse/JDK-8347498)" and the related commit: https://github.com/openjdk/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea

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

PR Comment: https://git.openjdk.org/jdk/pull/25058#issuecomment-2853775647

From pminborg at openjdk.org  Tue May  6 09:03:32 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 May 2025 09:03:32 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
Message-ID: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>

This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.

Unfortunately, this PR shows the total commit history for stable values.

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

Commit messages:
 - Merge branch 'master' into jep502-followup
 - Update src/java.base/share/classes/java/lang/StableValue.java
 - Simplify furhter
 - Address comments in PR
 - Merge master
 - Remove unused method and add comment
 - Address comments
 - Merge branch 'master' into jep502-followup
 - Update link in docs
 - Remove forgotten line
 - ... and 372 more: https://git.openjdk.org/jdk/compare/1501a5e4...116ce16c

Changes: https://git.openjdk.org/jdk/pull/25004/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25004&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356080
  Stats: 328 lines in 13 files changed: 211 ins; 46 del; 71 mod
  Patch: https://git.openjdk.org/jdk/pull/25004.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25004/head:pull/25004

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

From duke at openjdk.org  Tue May  6 09:03:34 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 6 May 2025 09:03:34 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
In-Reply-To: <bVbOJKli_2diVXN8lu61f6mDhf2nYKqVBIzivkddLMg=.371ec9e9-df3b-4465-9101-e31df6732ee2@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
 <bVbOJKli_2diVXN8lu61f6mDhf2nYKqVBIzivkddLMg=.371ec9e9-df3b-4465-9101-e31df6732ee2@github.com>
Message-ID: <FZtw57hAMVG-5zWNTKC59zgpB6l3sXj2_jlsQpeppKw=.d0a9af11-1789-46e2-acab-c18f90786e48@github.com>

On Fri, 2 May 2025 13:56:19 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
>> 
>> Unfortunately, this PR shows the total commit history for stable values.
>
> src/java.base/share/classes/jdk/internal/lang/stable/StableSupplier.java line 62:
> 
>> 60:     public String toString() {
>> 61:         final Object t = delegate.wrappedContentsAcquire();
>> 62:         return t == this ? "(this StableSupplier)" : StableValueImpl.renderWrapped(t);
> 
> Suggestion:
> 
>         return delegate.wrappedContentsAcquire() == this 
>                ? "(this StableSupplier)" 
>                : StableValueImpl.renderWrapped(t);
> 
> Same as above, simplifying the code by removing local variables that are only used once

The?`t`?variable is?used?again in?the?`else` branch?of the?ternary?operator.

> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 108:
> 
>> 106:         if (t == null) {
>> 107:             throw new NoSuchElementException("No contents set");
>> 108:         }
> 
> Suggestion:
> 
>         if (wrappedContentsAcquire() == null) {
>             throw new NoSuchElementException("No contents set");
>         }
> 
> Same as above, simplifying the code by removing local variables that are only used once

`t`?is?passed to?`unwrap` on?the?next?line: <https://github.com/openjdk/jdk/blob/28bfb5c62e30516dcc5cf476ababaf7a3f1f6705/src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java#L104-L110>

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2071820465
PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2071822154

From liach at openjdk.org  Tue May  6 09:03:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 09:03:33 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
In-Reply-To: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
Message-ID: <7QymLvAbuk2tnG0hkN73Sqmk7RngVqVdbZ4mbeKudQE=.ae0379c8-b362-4a99-92b4-e6049f271c95@github.com>

On Fri, 2 May 2025 12:13:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
> 
> Unfortunately, this PR shows the total commit history for stable values.

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

> 385:  * The method {@link #orElseSet(Supplier)} guarantees that the provided
> 386:  * {@linkplain Supplier} is invoked successfully at most once, even under race.
> 387:  * Invocations of {@link #orElseSet(Supplier)} (Object)} form a total order of zero or

Suggestion:

 * Invocations of {@link #orElseSet(Supplier)} form a total order of zero or

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2072270481

From swen at openjdk.org  Tue May  6 09:03:33 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 6 May 2025 09:03:33 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
In-Reply-To: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
Message-ID: <bVbOJKli_2diVXN8lu61f6mDhf2nYKqVBIzivkddLMg=.371ec9e9-df3b-4465-9101-e31df6732ee2@github.com>

On Fri, 2 May 2025 12:13:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
> 
> Unfortunately, this PR shows the total commit history for stable values.

src/java.base/share/classes/java/util/ImmutableCollections.java line 895:

> 893:             public List<E> subList(int fromIndex, int toIndex) {
> 894:                 int size = size();
> 895:                 subListRangeCheck(fromIndex, toIndex, size);

Suggestion:

                subListRangeCheck(fromIndex, toIndex, size());

size is only used once, can it be simplified like this?

src/java.base/share/classes/java/util/ImmutableCollections.java line 905:

> 903:                 // Todo: Provide a copy free solution
> 904:                 final StableValueImpl<E>[] reversed = Arrays.copyOfRange(delegates, this.offset, this.size - offset);
> 905:                 return StableUtil.renderElements(this, "StableCollection", reversed);

Suggestion:

                return StableUtil.renderElements(this, "StableCollection", 
                                                 Arrays.copyOfRange(deepRoot(root).delegates, this.offset, this.size - offset));

The three local variables `deepRoot/delegates/reversed` are only used once. Can they be simplified like this?

src/java.base/share/classes/java/util/ImmutableCollections.java line 932:

> 930:                 final StableValueImpl<E>[] reversed = ArraysSupport.reverse(
> 931:                         Arrays.copyOf(delegates, delegates.length));
> 932:                 return StableUtil.renderElements(this, "Collection", reversed);

Suggestion:

                final StableValueImpl<E>[] delegates = deepRoot(base).delegates;
                // Todo: Provide a copy free solution
                return StableUtil.renderElements(this, "Collection", ArraysSupport.reverse(Arrays.copyOf(delegates, delegates.length)));


Same as above, simplifying the code by removing local variables that are only used once

src/java.base/share/classes/jdk/internal/lang/stable/StableSupplier.java line 62:

> 60:     public String toString() {
> 61:         final Object t = delegate.wrappedContentsAcquire();
> 62:         return t == this ? "(this StableSupplier)" : StableValueImpl.renderWrapped(t);

Suggestion:

        return delegate.wrappedContentsAcquire() == this 
               ? "(this StableSupplier)" 
               : StableValueImpl.renderWrapped(t);

Same as above, simplifying the code by removing local variables that are only used once

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

> 52:     // Unsafe offsets for direct field access
> 53: 
> 54:     private static final long CONTENT_OFFSET =

It should be CONTENTS_OFFSET, right?

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

> 106:         if (t == null) {
> 107:             throw new NoSuchElementException("No contents set");
> 108:         }

Suggestion:

        if (wrappedContentsAcquire() == null) {
            throw new NoSuchElementException("No contents set");
        }

Same as above, simplifying the code by removing local variables that are only used once

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2071635586
PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2071642599
PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2071648603
PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2071651874
PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2071654313
PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2071656349

From stuefe at openjdk.org  Tue May  6 09:06:24 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 6 May 2025 09:06:24 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v4]
In-Reply-To: <nbR3H0HjDI-2hc34fJ4ZRZNA23i4nA1XNiaX8tWKye8=.b5b51f92-ee1e-42a1-9743-ce76c070a774@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
 <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
 <nbR3H0HjDI-2hc34fJ4ZRZNA23i4nA1XNiaX8tWKye8=.b5b51f92-ee1e-42a1-9743-ce76c070a774@github.com>
Message-ID: <gX1d-jasrxhhQiQ5sYUAAUp0ev6MBIsZYGRvF2OWVJw=.7276992d-ab6b-4ed3-ae0c-bcbe25a9b3d6@github.com>

On Wed, 30 Apr 2025 17:26:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> @tstuefe -- I know you love `jspawnhelper` bugs, want to take a look?

Love is a strong word :-)

I missed this one. I will take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/24149#issuecomment-2853797278

From swen at openjdk.org  Tue May  6 09:24:23 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 6 May 2025 09:24:23 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v3]
In-Reply-To: <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com>
Message-ID: <m9RBNTMgGyX04fA4-fUohjSIZyKAZeh8XRz8P1ftEAo=.83a9e08b-a11c-4857-b83f-692f6e34deaa@github.com>

On Mon, 5 May 2025 17:13:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix empty line at the end of a third file
>  - Fix empty line at the end of another file
>  - Fix empty line at the end of a file

src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 306:

> 304:     @ForceInline
> 305:     private static int success(int value,
> 306:                                MemorySegment segment) {

Suggestion:

    private static long success(long value, MemorySegment segment) {

Newline separation is not necessary here

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2075073938

From swen at openjdk.org  Tue May  6 09:28:13 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 6 May 2025 09:28:13 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v3]
In-Reply-To: <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com>
Message-ID: <lPBPTYm2wiwvp45Zr8pJ8jAv9zhD_64uAChueCaGkE0=.37fb2b82-26a8-4d3b-ba74-de53a5a299d0@github.com>

On Mon, 5 May 2025 17:13:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix empty line at the end of a third file
>  - Fix empty line at the end of another file
>  - Fix empty line at the end of a file

src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 103:

> 101:             }
> 102:             return returnType;
> 103:         }

Suggestion:

        static Class<?> returnType(MethodHandle target) {
            // Implicit null check
            final MethodType type = target.type();
            final Class<?> returnType = type.returnType();

            if (!(returnType.equals(int.class) || returnType.equals(long.class))) {
                throw illegalArgDoesNot(target, "return an int or a long");
            }
            if (type.parameterCount() == 0 || type.parameterType(0) != MemorySegment.class) {
                throw illegalArgDoesNot(target, "have a MemorySegment as the first parameter");
            }
            return returnType;
        }


If returnType uses a local variable, type also uses a local variable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2075081366

From swen at openjdk.org  Tue May  6 09:38:15 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 6 May 2025 09:38:15 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v5]
In-Reply-To: <jdZkdPn3QI3c-QklFui6Aj7hXcn0pPrV7kMQ0w4tEQ0=.37ea8bef-fa3f-440f-875c-6450539517a0@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <jdZkdPn3QI3c-QklFui6Aj7hXcn0pPrV7kMQ0w4tEQ0=.37ea8bef-fa3f-440f-875c-6450539517a0@github.com>
Message-ID: <DPzyChsToCnF_jbXWmIrY-XlU6yVST4THQg4gFlAou8=.93f32778-e9da-436b-a023-c18a5b59b373@github.com>

On Mon, 5 May 2025 16:44:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
>> 
>> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
>> 
>> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
>> 
>> Testing: jdk/lang/foreign, tier 1-3 in progress.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks

src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 59:

> 57:         MemoryLayout[] stateLayouts = new MemoryLayout[supported.size()];
> 58:         @SuppressWarnings({"unchecked", "rawtypes"})
> 59:         Map.Entry<String, CapturableState>[] entries = new Map.Entry[supported.size()];

Suggestion:

        CapturableState[] supported;

        if (OperatingSystem.isWindows()) {
            supported = new CapturableState[] {
                    new CapturableState("GetLastError", JAVA_INT, 1 << 0),
                    new CapturableState("WSAGetLastError", JAVA_INT, 1 << 1),
                    new CapturableState("errno", JAVA_INT, 1 << 2)
            };
        } else {
            supported = new CapturableState[] {new CapturableState("errno", JAVA_INT, 1 << 2)};
        }

        MemoryLayout[] stateLayouts = new MemoryLayout[supported.length];
        @SuppressWarnings({"unchecked", "rawtypes"})
        Map.Entry<String, CapturableState>[] entries = new Map.Entry[supported.length];

Here it might be better to replace List with an array

src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 84:

> 82:         if (ret == null) {
> 83:             throw new IllegalArgumentException(
> 84:                     "Unknown name: " + name +", must be one of: "

Suggestion:

                    "Unknown name: " + name + ", must be one of: "

space

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075096871
PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075097771

From redestad at openjdk.org  Tue May  6 10:09:13 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 6 May 2025 10:09:13 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v5]
In-Reply-To: <ZjPctgxBf_YlOkTF_ij8iUwFop3feVFf9fMUcTt3J-w=.7baf9f98-904d-4dda-867c-6c4ecfb0235a@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
 <bF_OnxOCbrFO-atOiCBXIJp_JxT2__hFunyZV-aTPs0=.2da5ecfe-81e1-4723-9bab-65aec9c808e2@github.com>
 <-h6nC56_HwMWSYMJsNLcMG6CLNaXVU7YaDwZJdVYrjE=.fb97d835-27b2-48ec-b5e2-6133b8feac16@github.com>
 <NyM7mLFCbMU3b4zMZdQ_5RmPpAeUenkhGmq4QmKyamc=.5b297f0b-a91d-4e56-a2cc-13a32d1e2665@github.com>
 <ZjPctgxBf_YlOkTF_ij8iUwFop3feVFf9fMUcTt3J-w=.7baf9f98-904d-4dda-867c-6c4ecfb0235a@github.com>
Message-ID: <HNwn7eucxdQ_6hXKbERBhHRZ5v4JQZPaX-63yTX1yA8=.690a549a-3cda-4be8-ab17-4d6dc31b4b4c@github.com>

On Tue, 6 May 2025 08:44:56 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @ForceInline
>>     static int checkOverflow(int value) {
>>         if (value >= 0) {
>>             return value;
>>         }
>>         throw new OutOfMemoryError("Overflow: String length out of range");
>>     }
>> 
>>     private static long checkOverflow(long lengthCoder) {
>>         if ((int)lengthCoder >= 0) {
>>             return lengthCoder;
>>         }
>>         throw new OutOfMemoryError("Overflow: String length out of range");
>>     }
>> 
>> @cl4es There are two checkOverflow methods
>
> Exactly. The one used here is the (int) variant.

D'oh, missed that it's been added since it's not co-located in the source. Sorry for the noise!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25038#discussion_r2075147358

From vklang at openjdk.org  Tue May  6 10:21:21 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 6 May 2025 10:21:21 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message [v4]
In-Reply-To: <khVURCi6CS9QRXC8Xnb-hEIFFxdpedAwcSf3P6PSu0Y=.87b88edf-100a-4743-be07-dc79a222409d@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <khVURCi6CS9QRXC8Xnb-hEIFFxdpedAwcSf3P6PSu0Y=.87b88edf-100a-4743-be07-dc79a222409d@github.com>
Message-ID: <vouhkobRGmUb3xOBOAsJTl95agm4v1SVUgLBXwEOjDk=.60dd80c0-d493-4d01-abf6-e00e6c36a9fc@github.com>

On Fri, 18 Apr 2025 03:22:28 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

>> 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

src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java line 158:

> 156:     private <T> T doInvokeAny(Collection<? extends Callable<T>> tasks,
> 157:                               boolean timed, long nanos)
> 158:         throws InterruptedException, ExecutionException, TimeoutException, NullPointerException {

NullPointerException is a RuntimeException

Suggestion:

        throws InterruptedException, ExecutionException, TimeoutException {

src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java line 264:

> 262:     @Override
> 263:     public <T> List<Future<T>> invokeAll(Collection<? extends Callable<T>> tasks)
> 264:         throws InterruptedException , NullPointerException {

NullPointerException is a RuntimeException

Suggestion:

        throws InterruptedException {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23050#discussion_r2075163173
PR Review Comment: https://git.openjdk.org/jdk/pull/23050#discussion_r2075163888

From redestad at openjdk.org  Tue May  6 11:06:20 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 6 May 2025 11:06:20 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v8]
In-Reply-To: <fHBCE8kw7jUn9gc4R0o8v0PQbsCYWTvxkNJpGji7744=.a77cb139-35b4-492f-83a2-bb5a28eac32d@github.com>
References: <d-bbTH1lsG4Ev7_sNutKMbLBTXXyQ75ZQTbNvgJkqBQ=.06f597ba-1313-4bb4-9947-880e73acd5bf@github.com>
 <fHBCE8kw7jUn9gc4R0o8v0PQbsCYWTvxkNJpGji7744=.a77cb139-35b4-492f-83a2-bb5a28eac32d@github.com>
Message-ID: <8KfOLnQ42AcdAR0mP0ileW5-4LOnUniljRRdZq3zB7o=.1d7338a6-deb9-4b35-bec5-7bc225611d72@github.com>

On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
>> 
>> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
>> 
>> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
>> 
>> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's review - update code comment in the test

Changes LGTM

While this PR fixes the bug reported in JDK-8355975 I'm not sure how the changes in JDK-8243254 are to blame for that particular bug. This since no aspect of the charset was part of `Key` before. The provided test case fails in an unrelated way (unmappable character) when I try building and testing on JDK 8 and 11, though. It would be good to make sure this is not an issue on older JDKs?

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

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23986#pullrequestreview-2817852104

From jpai at openjdk.org  Tue May  6 11:16:17 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 11:16:17 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v8]
In-Reply-To: <fHBCE8kw7jUn9gc4R0o8v0PQbsCYWTvxkNJpGji7744=.a77cb139-35b4-492f-83a2-bb5a28eac32d@github.com>
References: <d-bbTH1lsG4Ev7_sNutKMbLBTXXyQ75ZQTbNvgJkqBQ=.06f597ba-1313-4bb4-9947-880e73acd5bf@github.com>
 <fHBCE8kw7jUn9gc4R0o8v0PQbsCYWTvxkNJpGji7744=.a77cb139-35b4-492f-83a2-bb5a28eac32d@github.com>
Message-ID: <sTwZ7C7X740Uqawcokv2yWs6qLypDM_L7y4ZfUUiNR8=.cc35089f-5bf0-4b83-a323-a6f95a317bbf@github.com>

On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
>> 
>> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
>> 
>> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
>> 
>> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's review - update code comment in the test

Hello Claes, thank you for the review.

> While this PR fixes the bug reported in JDK-8355975 I'm not sure how the changes in JDK-8243254 are to blame for that particular bug. This since no aspect of the charset was part of Key before. 

You are right and I've updated the JBS issue to correct myself that 8355975 isn't the cause for this and it likely exists even in older versions. I overlooked that even though 8355975 introduced the charset to be part of the `Key`, the underlying issue relates to considering two `ZipFile` instances opened with different `Charset`s as having the same entry names.

> The provided test case fails in an unrelated way (unmappable character) when I try building and testing on JDK 8 and 11, though. It would be good to make sure this is not an issue on older JDKs?

I will take a look at why it fails with that error on those versions and see if the test can be adjusted (outside of this PR) for those releases.

Thank you everyone for the reviews and the inputs. Alan had started reviewing this last week, so I'll wait for his review before integrating this.

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

PR Comment: https://git.openjdk.org/jdk/pull/23986#issuecomment-2854182588

From jpai at openjdk.org  Tue May  6 11:23:20 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 11:23:20 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v8]
In-Reply-To: <fHBCE8kw7jUn9gc4R0o8v0PQbsCYWTvxkNJpGji7744=.a77cb139-35b4-492f-83a2-bb5a28eac32d@github.com>
References: <d-bbTH1lsG4Ev7_sNutKMbLBTXXyQ75ZQTbNvgJkqBQ=.06f597ba-1313-4bb4-9947-880e73acd5bf@github.com>
 <fHBCE8kw7jUn9gc4R0o8v0PQbsCYWTvxkNJpGji7744=.a77cb139-35b4-492f-83a2-bb5a28eac32d@github.com>
Message-ID: <e19Px76I2fGB0BDrAuanKWIIaaHyGdC27eySFaLVSFo=.de5d6b0c-810a-4b94-b1c2-ba6fc73536ea@github.com>

On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
>> 
>> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
>> 
>> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
>> 
>> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's review - update code comment in the test

Hello Eirik,

> Neither the RandomAccessFile nor the CEN bytes change between different charsets so I believe there may be potential for some untangling and simplification here.
...
> But that?s for another PR :)

You are right and I noticed that and a few other related things when working on this change. Given the role this ZIP/JAR parsing code plays in the JDK and various historical iterations it has gone through, doing any refactoring would be better done in independent and  reasonably sized  chunks if possible. I haven't however done a thorough analysis of whether it's feasible.

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

PR Comment: https://git.openjdk.org/jdk/pull/23986#issuecomment-2854200203

From duke at openjdk.org  Tue May  6 11:25:20 2025
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 May 2025 11:25:20 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v11]
In-Reply-To: <5FwC5VTxPYBUNMq8nPPyFxYQ4BMZzaiVxbm1CW9Zbi8=.1b4c9d8f-642b-4666-9961-d77841e39f8e@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <bY6wxELBjJnRQ5co73NgJC5baGtnY5UKezuQXCvYU5E=.82004266-7468-484d-a28c-85852d06f8d9@github.com>
 <eIAbKE11RsBYYxLFsdl8mbp9K6FEZaJ0GrHxWWNbsEc=.39224a40-5b72-4e3f-b2fd-cb8226dd2f92@github.com>
 <b_BF-hOVcyul6ERad9IpcJqoqzhd_KvXQjc0duqeyGI=.fa116284-73e8-4695-912e-f5fccbc3da4b@github.com>
 <2jc5ZuZmlzsOBJOD9VwObHfox_2VX8Dmy6AhasVXp3w=.4cabab81-4d24-453d-ab46-eb272f6e7c27@github.com>
 <LSOrFyZ6177AukhxK4GbbP3dNm2ekhGo6gfjhQEct3o=.ac3069f9-1905-4c9e-8b4a-3e725ed57476@github.com>
 <5FwC5VTxPYBUNMq8nPPyFxYQ4BMZzaiVxbm1CW9Zbi8=.1b4c9d8f-642b-4666-9961-d77841e39f8e@github.com>
Message-ID: <OJm0XWvJISYreH2upTlve4rmSTXEzBbsKjJHhM_QvNM=.af1346fc-a1d2-4aef-a6d0-d088a87e24c3@github.com>

On Tue, 6 May 2025 02:21:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> So it is actually *wanted* behavior that in one situation the text *is* inherited, but at `String.java` no text is inherited at all? ? Could not find any hint about that in the JavaDoc manual.
>
>> So it is actually _wanted_ behavior that in one situation the text _is_ inherited, but at `String.java` no text is inherited at all? ? Could not find any hint about that in the JavaDoc manual.
> 
> The inheritDoc functionality of javadoc was reworked relatively recently so I would assume the current behavior is intentional, even if not documented.

Understood. Thank you for clarifying, Joe! :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2075255586

From duke at openjdk.org  Tue May  6 11:25:19 2025
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 May 2025 11:25:19 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v11]
In-Reply-To: <PBiSYA5aqDEnMIqV_0e7cvAbmc6YmO78SqKDx168qsU=.2b4c3790-b3c6-4ce3-a916-36a5e4c402a4@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <bY6wxELBjJnRQ5co73NgJC5baGtnY5UKezuQXCvYU5E=.82004266-7468-484d-a28c-85852d06f8d9@github.com>
 <PBiSYA5aqDEnMIqV_0e7cvAbmc6YmO78SqKDx168qsU=.2b4c3790-b3c6-4ce3-a916-36a5e4c402a4@github.com>
Message-ID: <ElaSulVLeJ_WM0ZsWa1S2ZlOR9LCc8DYQ3c3gibUlpo=.27648334-e818-4b65-b68d-708b28593f2c@github.com>

On Tue, 6 May 2025 02:01:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Markus, it's been a while since this PR was merged with latest master branch in mainline. Could you update the PR to do that?

As rebasing is not wanted in OpenJDK, do you mean merging `master` branch into *this* branch?

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

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

From jpai at openjdk.org  Tue May  6 11:33:23 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 11:33:23 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v11]
In-Reply-To: <ElaSulVLeJ_WM0ZsWa1S2ZlOR9LCc8DYQ3c3gibUlpo=.27648334-e818-4b65-b68d-708b28593f2c@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <bY6wxELBjJnRQ5co73NgJC5baGtnY5UKezuQXCvYU5E=.82004266-7468-484d-a28c-85852d06f8d9@github.com>
 <PBiSYA5aqDEnMIqV_0e7cvAbmc6YmO78SqKDx168qsU=.2b4c3790-b3c6-4ce3-a916-36a5e4c402a4@github.com>
 <ElaSulVLeJ_WM0ZsWa1S2ZlOR9LCc8DYQ3c3gibUlpo=.27648334-e818-4b65-b68d-708b28593f2c@github.com>
Message-ID: <2Awpgkw3OvX8ZzVWLnn9HKHcDqFF2jFN5-m-knxeWAw=.eb199166-6cc0-4d38-9cbc-138f82577e6f@github.com>

On Tue, 6 May 2025 11:23:01 GMT, Markus KARG <duke at openjdk.org> wrote:

> do you mean merging master branch into this branch?

Yes, that's correct. That should then run the GitHub actions job against this PR against a more relevant state of this PR.

Since things have settled and the CSR approved, I'll also run this PR against our CI to verify nothing fails unexpectedly. I will anyway be doing the merge against master locally before submitting for tier testing, but it's always a good practice to keep the PR updated with latest master changes, when the master branch has seen too many commits since the PR was opened.

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

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

From pminborg at openjdk.org  Tue May  6 11:48:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 May 2025 11:48:13 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy field
 evaluations
Message-ID: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>

This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

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

Commit messages:
 - Address comments
 - Document field alignment assumption
 - Add unhecked call test
 - Move raw factories into inner class Raw
 - Add copyright header and revert unintended change
 - Add examples to doc and fix tests
 - Add @Stable for URI and add benchmark
 - Rename classes
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/25040/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356255
  Stats: 904 lines in 10 files changed: 868 ins; 26 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040

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

From pminborg at openjdk.org  Tue May  6 11:48:15 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 May 2025 11:48:15 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <MJn1nqjbkTUI6g___10iB-FS5guVRVavCr4OR_VHavw=.3641ea1d-35df-4782-a2a6-5a705731adb9@github.com>

On Mon, 5 May 2025 13:41:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

Benchmarks:


Benchmark                        Mode  Cnt  Score   Error  Units
StableUpdatersBenchmark.base     avgt   10  0.715 ? 0.026  ns/op
StableUpdatersBenchmark.updater  avgt   10  0.716 ? 0.079  ns/op


Which shows the updater has the same performance as imperative code which is good.

Updated benchmarks:


Benchmark                              Mode  Cnt  Score   Error  Units
StableUpdatersBenchmark.base           avgt   10  0.838 ? 0.041  ns/op
StableUpdatersBenchmark.baseStatic     avgt   10  0.759 ? 0.088  ns/op
StableUpdatersBenchmark.updater        avgt   10  0.888 ? 0.086  ns/op
StableUpdatersBenchmark.updaterStatic  avgt   10  0.753 ? 0.017  ns/op
StableUpdatersBenchmark.uri            avgt   10  0.781 ? 0.206  ns/op
StableUpdatersBenchmark.uriStatic      avgt   10  0.724 ? 0.048  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/25040#issuecomment-2851073331
PR Comment: https://git.openjdk.org/jdk/pull/25040#issuecomment-2853800652

From liach at openjdk.org  Tue May  6 11:48:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 11:48:14 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <SPkI2lv_w_TCf7Y2dVPbtpUCBH167Y_B1CPvsnli8DQ=.3297c679-4c6c-46ce-96ae-07ce2f2e5c21@github.com>

On Mon, 5 May 2025 13:41:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

Changes requested by liach (Reviewer).

src/java.base/share/classes/java/lang/reflect/Method.java line 101:

> 99: 
> 100:     private static final ToIntFunction<Method> HASH_UPDATER =
> 101:             StableFieldUpdater.ofIntRaw(Method.class, Unsafe.getUnsafe().objectFieldOffset(Method.class, "hash"), new ToIntFunction<Method>() {

If we are using unsafe to get field offsets, why don't we just accept arguments to locate a MethodHandle (like those arguments to MhUtils)?

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

PR Review: https://git.openjdk.org/jdk/pull/25040#pullrequestreview-2815145097
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2073631615

From pminborg at openjdk.org  Tue May  6 11:48:16 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 May 2025 11:48:16 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations
In-Reply-To: <SPkI2lv_w_TCf7Y2dVPbtpUCBH167Y_B1CPvsnli8DQ=.3297c679-4c6c-46ce-96ae-07ce2f2e5c21@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <SPkI2lv_w_TCf7Y2dVPbtpUCBH167Y_B1CPvsnli8DQ=.3297c679-4c6c-46ce-96ae-07ce2f2e5c21@github.com>
Message-ID: <hTAYQU2pKnWPwjOaqfTWo6t6vn_kfO2S9Fb-pkfLof8=.6fd79252-39c9-4a7f-b4f9-b97a1d9b5732@github.com>

On Mon, 5 May 2025 15:04:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> src/java.base/share/classes/java/lang/reflect/Method.java line 101:
> 
>> 99: 
>> 100:     private static final ToIntFunction<Method> HASH_UPDATER =
>> 101:             StableFieldUpdater.ofIntRaw(Method.class, Unsafe.getUnsafe().objectFieldOffset(Method.class, "hash"), new ToIntFunction<Method>() {
> 
> If we are using unsafe to get field offsets, why don't we just accept arguments to locate a MethodHandle (like those arguments to MhUtils)?

Do you mean for interacting with the field or computing the hash?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075052972

From liach at openjdk.org  Tue May  6 11:48:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 11:48:17 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations
In-Reply-To: <hTAYQU2pKnWPwjOaqfTWo6t6vn_kfO2S9Fb-pkfLof8=.6fd79252-39c9-4a7f-b4f9-b97a1d9b5732@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <SPkI2lv_w_TCf7Y2dVPbtpUCBH167Y_B1CPvsnli8DQ=.3297c679-4c6c-46ce-96ae-07ce2f2e5c21@github.com>
 <hTAYQU2pKnWPwjOaqfTWo6t6vn_kfO2S9Fb-pkfLof8=.6fd79252-39c9-4a7f-b4f9-b97a1d9b5732@github.com>
Message-ID: <1zyhyBGMKNBM0S4KAB3q5eqByvPGFbNIOLFrR_KzIjQ=.b27c864f-4026-4b9b-b958-0215a73bc3db@github.com>

On Tue, 6 May 2025 09:09:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/Method.java line 101:
>> 
>>> 99: 
>>> 100:     private static final ToIntFunction<Method> HASH_UPDATER =
>>> 101:             StableFieldUpdater.ofIntRaw(Method.class, Unsafe.getUnsafe().objectFieldOffset(Method.class, "hash"), new ToIntFunction<Method>() {
>> 
>> If we are using unsafe to get field offsets, why don't we just accept arguments to locate a MethodHandle (like those arguments to MhUtils)?
>
> Do you mean for interacting with the field or computing the hash?

Calling the method that computes hash.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075217957

From pminborg at openjdk.org  Tue May  6 11:48:17 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 May 2025 11:48:17 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations
In-Reply-To: <1zyhyBGMKNBM0S4KAB3q5eqByvPGFbNIOLFrR_KzIjQ=.b27c864f-4026-4b9b-b958-0215a73bc3db@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <SPkI2lv_w_TCf7Y2dVPbtpUCBH167Y_B1CPvsnli8DQ=.3297c679-4c6c-46ce-96ae-07ce2f2e5c21@github.com>
 <hTAYQU2pKnWPwjOaqfTWo6t6vn_kfO2S9Fb-pkfLof8=.6fd79252-39c9-4a7f-b4f9-b97a1d9b5732@github.com>
 <1zyhyBGMKNBM0S4KAB3q5eqByvPGFbNIOLFrR_KzIjQ=.b27c864f-4026-4b9b-b958-0215a73bc3db@github.com>
Message-ID: <HXfHhZbkRR1isSZFkBGn-7lLHtTKxItntRpHLRWsqng=.8173537a-f789-43f1-85a4-d2b76f76df97@github.com>

On Tue, 6 May 2025 10:55:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Do you mean for interacting with the field or computing the hash?
>
> Calling the method that computes hash.

This would require another implementation to be written. Maybe we can add that later?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075271947

From swen at openjdk.org  Tue May  6 11:48:19 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 6 May 2025 11:48:19 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <uTpZhE_J5JG9s5UyR21V_BmrjSJVgKBJhEnV2-pOB64=.d40513ae-9fe0-40e5-9123-bbd79252ab37@github.com>

On Mon, 5 May 2025 13:41:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

src/java.base/share/classes/java/lang/reflect/Method.java line 105:

> 103:                 public int applyAsInt(Method method) {
> 104:                     return method.getDeclaringClass().getName().hashCode() ^ method.getName()
> 105:                             .hashCode();

Suggestion:

                    return method.getDeclaringClass().getName().hashCode() 
                                             ^ method.getName().hashCode();

code indentation alignment

src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 330:

> 328:                 throw illegalField("non final fields", field);
> 329:             }
> 330:             sun.reflect.misc.ReflectUtil.ensureMemberAccess(

Why not use import here but use the full path?

src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 350:

> 348:         }
> 349:         final Field[] fields = holderType.getDeclaredFields();
> 350:         for (Field f : fields) {

Suggestion:

        for (Field f : holderType.getDeclaredFields()) {

The local variable fields is only used once and can be simplified

test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 132:

> 130:                     Objects.equals(this.bar, that.bar) &&
> 131:                     Objects.equals(this.baz, that.baz);
> 132:         }

Suggestion:

        public boolean equals(Object o) {
            return o instanceof Foo that
                    && Objects.equals(this.bar, that.bar)
                    && Objects.equals(this.baz, that.baz);
        }

In most cases in JDK code, the operator `&&` is placed in front.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075244737
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075229805
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075234183
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075239678

From pminborg at openjdk.org  Tue May  6 11:58:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 May 2025 11:58:14 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v5]
In-Reply-To: <jdZkdPn3QI3c-QklFui6Aj7hXcn0pPrV7kMQ0w4tEQ0=.37ea8bef-fa3f-440f-875c-6450539517a0@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <jdZkdPn3QI3c-QklFui6Aj7hXcn0pPrV7kMQ0w4tEQ0=.37ea8bef-fa3f-440f-875c-6450539517a0@github.com>
Message-ID: <32ucY7tR1BkXyswk9VFkOzuvvN4f5DecNZNZ_2BtgHE=.1fafacc7-aad9-4c30-a76c-df0b39ed57b6@github.com>

On Mon, 5 May 2025 16:44:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
>> 
>> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
>> 
>> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
>> 
>> Testing: jdk/lang/foreign, tier 1-3 in progress.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks

src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 81:

> 79: 
> 80:     public static CapturableState forName(String name) {
> 81:         var ret = LOOKUP.get(name);

As we usually have just one element (and for Windows three elements) it might be both less memory consuming and faster to just search a `@Stable` array linearly rather than having a Map.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075308234

From pminborg at openjdk.org  Tue May  6 12:02:15 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 May 2025 12:02:15 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v5]
In-Reply-To: <jdZkdPn3QI3c-QklFui6Aj7hXcn0pPrV7kMQ0w4tEQ0=.37ea8bef-fa3f-440f-875c-6450539517a0@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <jdZkdPn3QI3c-QklFui6Aj7hXcn0pPrV7kMQ0w4tEQ0=.37ea8bef-fa3f-440f-875c-6450539517a0@github.com>
Message-ID: <Vq6842ZecVOtjaZ46tz6HoBlOl35HCvoA4_3hCRyTt4=.9f0aa0c5-01ff-48dd-afef-cdde8a40a803@github.com>

On Mon, 5 May 2025 16:44:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
>> 
>> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
>> 
>> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
>> 
>> Testing: jdk/lang/foreign, tier 1-3 in progress.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks

src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 88:

> 86: 
> 87:     // The current OperatingSystem
> 88:     private static @Stable OperatingSystem CURRENT_OS;

Could this be a `StableValue.supplier()`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075313499

From stuefe at openjdk.org  Tue May  6 12:03:26 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 6 May 2025 12:03:26 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v4]
In-Reply-To: <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
 <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
Message-ID: <YoHw-NBBOF6dHnbNX2nlxarBy1jnHdHUhuSEZlcSp_k=.536fcce1-7010-461f-a934-52505f473170@github.com>

On Wed, 30 Apr 2025 16:11:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong.
>> 
>> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. 
>> 
>> I am very open to bike-shedding about the actual message :)
>> 
>> Additional testing:
>>  - [x] Ad-hoc experiments with breaking jspawnhelper
>>  - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Add bug ID
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Pull message into a field
>  - Test cases
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Initial fix
>    
>    Good spawnhelper failure message
>    
>    Trying tests
>    
>    Print helper message on all IOExceptions
>    
>    Final

Makes sense.

I recently looked into this because of signal handling issues. I planned to add logging to jspawnhelper. I had done similar work at SAP, and we found it really useful.

My very pragmatic plan was to define an environment variable that would name the name of a file; the variable's existence would then signal logging=on to jspawnhelper and it would log into this file. Since we can have process trees, every file name would get the pid of the process attached. Of course, care must be taken around exec (close the file before exec as to not inherit it; re-open it for some last logging after exec errors) and when passing around this variable (must be excluded from any environment var cleansing we do).

Bit tricky but no rocket science. I will do it when I find the time. 

Of course, all of that does not help customers who don't contact support; for them, the exception text is the sole info. This would be more of a tool for us than for them.

src/java.base/unix/native/libjava/ProcessImpl_md.c line 346:

> 344:         if (ret != EINVAL)
> 345:             detail = tmpbuf;
> 346:     }

Pre-existing, possibly as follow-up: 

I wonder whether we can do more. I don't like how we either only print out the errno string, or only print out the "Default" detail (I don't like the "default" prefix since it's really useful context information about this errno). 

For a problem on this side, we mostly pass in errno, then swallow the "defaultdetail". E.g. for posix_spawn failure, we'd print e.g. "12:Out of memory\nPossible reasons: ... " (or whatever localized string strerror returns).

For errors that happen inside the jspawnhelper (see line 790ff where we pass 0 for the errno), we print out "0:Bad code from spawn helper\nPossible reasons: ... ", so we swallow the errno we got from the jspawnhelper.

Could we print out instead the default, then the errno string, then the Possible reasons text? E.g.
"posix_spawn failed (12:Out of memory)\nPossible reasons: ..."
or
"Bad code from spawn helper (12:Out of memory)\nPossible reasons: ..." 

There is an issue of errnum values from the far side possibly intersecting with valid errno. Could be solved simply by assigning negative values to ERR_MALLOC, ERR_PIPE and ERR_ARGS. I am not aware of any errno values being negative. The errno printing would need to recognise these three values in addition to errno values. We also could remove the +3 workaround in the test.

The only argument I see against is some vague form of backward compatibility, in case people get confused about the new information, or that existing tools parse this output.

src/java.base/unix/native/libjava/ProcessImpl_md.c line 348:

> 346:     }
> 347:     /* ASCII Decimal representation uses 2.4 times as many bits as binary. */
> 348:     fmtsize = sizeof(IOE_FORMAT) + strlen(internalErrorDetail) + strlen(detail) + 3 * sizeof(errnum);

Suggestion:

    fmtsize = sizeof(IOE_FORMAT) + 3 * sizeof(errnum) + strlen(detail) +  strlen(internalErrorDetail) + 1;

... just to appease my OCD.

src/java.base/unix/native/libjava/ProcessImpl_md.c line 351:

> 349:     errmsg = NEW(char, fmtsize);
> 350:     if (errmsg == NULL)
> 351:         return;

Preexisting: seems to be weird to just quietly swallow the allocation error.

src/java.base/unix/native/libjava/ProcessImpl_md.c line 377:

> 375:       throwIOExceptionImpl(env, errnum, defaultDetail, "");
> 376:   }
> 377: }

Why only for POSIX_SPAWN? We use jspawnhelper also for fork/vfork+exec.

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

PR Review: https://git.openjdk.org/jdk/pull/24149#pullrequestreview-2817819896
PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2075257935
PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2075220275
PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2075224053
PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2075211949

From liach at openjdk.org  Tue May  6 12:10:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 12:10:14 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v5]
In-Reply-To: <Vq6842ZecVOtjaZ46tz6HoBlOl35HCvoA4_3hCRyTt4=.9f0aa0c5-01ff-48dd-afef-cdde8a40a803@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <jdZkdPn3QI3c-QklFui6Aj7hXcn0pPrV7kMQ0w4tEQ0=.37ea8bef-fa3f-440f-875c-6450539517a0@github.com>
 <Vq6842ZecVOtjaZ46tz6HoBlOl35HCvoA4_3hCRyTt4=.9f0aa0c5-01ff-48dd-afef-cdde8a40a803@github.com>
Message-ID: <nKfoXsr1PtS3P_AzHLlACBIeN1cloSADCNymio6HpqM=.655514ad-15da-4987-9ea1-a004779ad757@github.com>

On Tue, 6 May 2025 11:59:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks
>
> src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 88:
> 
>> 86: 
>> 87:     // The current OperatingSystem
>> 88:     private static @Stable OperatingSystem CURRENT_OS;
> 
> Could this be a `StableValue.supplier()`?

I would rather optimize MethodHandleAccessorFactory than defining a new class for this...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075326990

From pminborg at openjdk.org  Tue May  6 12:20:16 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 May 2025 12:20:16 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v3]
In-Reply-To: <cLknpFFaLQim0ofef4kmHQroCXy_DZcuP93rFB2I9bo=.79a42667-d328-421f-b836-909b953658c1@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com>
 <cLknpFFaLQim0ofef4kmHQroCXy_DZcuP93rFB2I9bo=.79a42667-d328-421f-b836-909b953658c1@github.com>
Message-ID: <ht9G_K--ZR3nVjIR8zuuYZFohVvTRkk8BAqbgVZmQFc=.2dfca217-4aac-4fb3-b108-dd3917aec6e9@github.com>

On Mon, 5 May 2025 18:21:44 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fix empty line at the end of a third file
>>  - Fix empty line at the end of another file
>>  - Fix empty line at the end of a file
>
> src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 176:
> 
>> 174:             @ForceInline
>> 175:             @Override
>> 176:             public NativeMemorySegmentImpl allocateNoInit(long byteSize, long byteAlignment) {
> 
> This?probably also?needs `@SuppressWarnings("restricted")`:
> Suggestion:
> 
>             @ForceInline
>             @Override
>             @SuppressWarnings("restricted")
>             public NativeMemorySegmentImpl allocateNoInit(long byteSize, long byteAlignment) {

I can't see why that is needed? Which restricted method is called by this method? What did I miss?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2075344707

From pminborg at openjdk.org  Tue May  6 12:24:17 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 May 2025 12:24:17 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v3]
In-Reply-To: <m9RBNTMgGyX04fA4-fUohjSIZyKAZeh8XRz8P1ftEAo=.83a9e08b-a11c-4857-b83f-692f6e34deaa@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com>
 <m9RBNTMgGyX04fA4-fUohjSIZyKAZeh8XRz8P1ftEAo=.83a9e08b-a11c-4857-b83f-692f6e34deaa@github.com>
Message-ID: <SP9iqRJ8vsnznKUmRgcPA3_OzIsNZiK7y3XaigWFThQ=.be928a07-6154-458a-ac2f-09c889895f39@github.com>

On Tue, 6 May 2025 09:21:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fix empty line at the end of a third file
>>  - Fix empty line at the end of another file
>>  - Fix empty line at the end of a file
>
> src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 306:
> 
>> 304:     @ForceInline
>> 305:     private static int success(int value,
>> 306:                                MemorySegment segment) {
> 
> Suggestion:
> 
>     private static long success(long value, MemorySegment segment) {
> 
> Newline separation is not necessary here

I've taken the approach to always separate parameters in this class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2075353554

From liach at openjdk.org  Tue May  6 12:26:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 12:26:13 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations
In-Reply-To: <HXfHhZbkRR1isSZFkBGn-7lLHtTKxItntRpHLRWsqng=.8173537a-f789-43f1-85a4-d2b76f76df97@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <SPkI2lv_w_TCf7Y2dVPbtpUCBH167Y_B1CPvsnli8DQ=.3297c679-4c6c-46ce-96ae-07ce2f2e5c21@github.com>
 <hTAYQU2pKnWPwjOaqfTWo6t6vn_kfO2S9Fb-pkfLof8=.6fd79252-39c9-4a7f-b4f9-b97a1d9b5732@github.com>
 <1zyhyBGMKNBM0S4KAB3q5eqByvPGFbNIOLFrR_KzIjQ=.b27c864f-4026-4b9b-b958-0215a73bc3db@github.com>
 <HXfHhZbkRR1isSZFkBGn-7lLHtTKxItntRpHLRWsqng=.8173537a-f789-43f1-85a4-d2b76f76df97@github.com>
Message-ID: <CCcYfCqazfZBrch-cZLSBxXG5jn-khRNe7daYwDxGSY=.b301e715-0c55-4b13-9bf6-b8629b3dc835@github.com>

On Tue, 6 May 2025 11:33:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Calling the method that computes hash.
>
> This would require another implementation to be written. Maybe we can add that later?

I feel like declaring a function is declaring redundant classes when we can just reuse a DirectMethodHandle pointing to an actual method. Also the zero alternative should be handled by the provided computing function/method instead of handled by this utility.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075357802

From pminborg at openjdk.org  Tue May  6 12:32:38 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 May 2025 12:32:38 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v4]
In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
Message-ID: <Av9w-CHHrUGeABiUbfvlhVCfJtqKyQELdTIwbsCVNf0=.6dc0ed4b-ab3c-42fd-afdd-9539d8072d23@github.com>

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.

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/25043/files
  - new: https://git.openjdk.org/jdk/pull/25043/files/07a39db9..6b26ef6a

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

  Stats: 17 lines in 3 files changed: 10 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25043/head:pull/25043

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

From pminborg at openjdk.org  Tue May  6 12:32:39 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 May 2025 12:32:39 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v3]
In-Reply-To: <kdQ0cQYPOnJu1nON4BYTube75JfjVWp-2CfsPfz2AU8=.f1fe7acf-a054-4e19-b51f-51e092daef39@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com>
 <kdQ0cQYPOnJu1nON4BYTube75JfjVWp-2CfsPfz2AU8=.f1fe7acf-a054-4e19-b51f-51e092daef39@github.com>
Message-ID: <qGh4TxJ7MIudua-Xk4iMx354D_QLCN1in8u2G0qk4F0=.c6e77625-0a27-4876-99e6-49431ad78798@github.com>

On Tue, 6 May 2025 08:47:54 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fix empty line at the end of a third file
>>  - Fix empty line at the end of another file
>>  - Fix empty line at the end of a file
>
> src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 390:
> 
>> 388:                 return MhUtil.findVirtual(LOOKUP, Arena.class, "close",
>> 389:                         MethodType.methodType(void.class));
>> 390:         }
> 
> Suggestion:
> 
>         return switch (index) {
>             case NON_NEGATIVE_INT -> MhUtil.findStatic(LOOKUP, "nonNegative",
>                     MethodType.methodType(boolean.class, int.class));
>             case SUCCESS_INT -> MhUtil.findStatic(LOOKUP, "success",
>                     MethodType.methodType(int.class, int.class, MemorySegment.class));
>             case ERROR_INT -> MhUtil.findStatic(LOOKUP, "error",
>                     MethodType.methodType(int.class, MethodHandle.class, int.class, MemorySegment.class));
>             case NON_NEGATIVE_LONG -> MhUtil.findStatic(LOOKUP, "nonNegative",
>                     MethodType.methodType(boolean.class, long.class));
>             case SUCCESS_LONG -> MhUtil.findStatic(LOOKUP, "success",
>                     MethodType.methodType(long.class, long.class, MemorySegment.class));
>             case ERROR_LONG -> MhUtil.findStatic(LOOKUP, "error",
>                     MethodType.methodType(long.class, MethodHandle.class, long.class, MemorySegment.class));
>             case ACQUIRE_ARENA -> MhUtil.findStatic(LOOKUP, "acquireArena",
>                     MethodType.methodType(Arena.class));
>             case ALLOCATE -> MhUtil.findStatic(LOOKUP, "allocate",
>                     MethodType.methodType(MemorySegment.class, Arena.class));
>             case ARENA_CLOSE -> MhUtil.findVirtual(LOOKUP, Arena.class, "close",
>                     MethodType.methodType(void.class));
>             default -> throw new InternalError("Unknown index: " + index);
>         };
> 
> Switch statement can be replaced with enhanced 'switch'

I have the old switch format in anticipation of faster startup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2075368639

From jpai at openjdk.org  Tue May  6 13:06:14 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 13:06:14 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
Message-ID: <_RBFenZwdc85lHZTiCz8ir6kYkH4ZegtjBDwKRQYk_M=.b289d795-a36c-481b-9fce-478ba450fbc3@github.com>

On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder.

> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values.

I see that in the proposed changes, we are now using the same names for these local variables and method parameters as the field names. Would using different names for these local variables be better? To avoid shadowing the field names (`value`, `coder` and `count`)? I think that could help prevent future (accidental) refactoring changes that end up unintentionally accessing fields instead of local variables.

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

PR Comment: https://git.openjdk.org/jdk/pull/24967#issuecomment-2854499902

From jpai at openjdk.org  Tue May  6 13:47:15 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 13:47:15 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
Message-ID: <C5LRNvGe5r-I2TCEYYQ_7yyeMyX1cFXksk-B-coS8CY=.0ffd37cb-d245-4638-9c56-3ad0e298b516@github.com>

On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1867:

> 1865:      * {@return Return the buffer containing the composed string and inserted characters}
> 1866:      * If the buffer coder needs to support UTF16 and does not, it is inflated and a different
> 1867:      * buffer is returned. TThe caller is responsible for setting the coder and updating the value ref

Typo - Should have been `The` instead of `TThe`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075514598

From jpai at openjdk.org  Tue May  6 13:58:15 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 13:58:15 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
Message-ID: <5eu74f7XoVq24VDlPHV92U-sEq3R5Wz6SbZ53_tg5TE=.18913c00-cf54-4724-b916-adcb5e40dc04@github.com>

On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder.

test/jdk/java/lang/StringBuilder/StressSBTest.java line 76:

> 74:      *
> 75:      * @param numThreads the number of threads
> 76:      * @param duration   a Duratio, typically a few seconds

Typo - should have been `a Duration, ...`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075538136

From jpai at openjdk.org  Tue May  6 14:03:25 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 14:03:25 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
Message-ID: <gfd4LFvYLcgdcZ6u6eJAqnpET0guLJS8f19tGkMH22Q=.bf56a9c1-f15a-4f61-bfbc-ed4949772b8d@github.com>

On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder.

Some of the files will need a copyright year update.

test/jdk/java/lang/StringBuilder/StressSBTest.java line 72:

> 70:     /**
> 71:      * Stress test using a number of platform threads for a duration.
> 72:      * Success is marked by a lack of exceptions.

If I'm reading the test correctly, then the exceptions that happen in the launched thread are merely logged and thus the test will never throw any exceptions and will never fail?

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

PR Comment: https://git.openjdk.org/jdk/pull/24967#issuecomment-2854691855
PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075546963

From duke at openjdk.org  Tue May  6 14:15:15 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 6 May 2025 14:15:15 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <Iknbm8JxHBTXEwLK4nfHGJto1ZICzXA-vwCGXYXT5Dg=.ab0b6189-682e-4293-88f3-bf4b169ac78e@github.com>

On Mon, 5 May 2025 13:41:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 214:

> 212:             }
> 213:             Objects.requireNonNull(underlying);
> 214:             return new StableLongFieldUpdater<>(holderType, offset, underlying, zeroReplacement);

This?should probably?construct `TearingStableLongFieldUpdater` on?32?bit?platforms:
Suggestion:

            if (Architecture.is64bit()) {
                // We are also relying on the fact that the VM will not place 64-bit
                // instance fields that can cross cache lines.
                return new StableLongFieldUpdater<>(holderType, offset, underlying, zeroReplacement);
            } else {
                return new TearingStableLongFieldUpdater<>(holderType, offset, underlying, zeroReplacement);
            }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075572314

From ihse at openjdk.org  Tue May  6 14:16:32 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 14:16:32 GMT
Subject: RFR: 8354273: Replace even more Unicode characters with ASCII [v3]
In-Reply-To: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
References: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
Message-ID: <Ynl7ATLqF5wm7um0BI3RwZC2IO9VObO1blOBXNny1Sk=.0fedb3c5-dd77-4123-82a8-ecde62b4f01f@github.com>

> 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 with a new target base 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 restore-more-ascii
 - Remove incorrectly copied "?anchor"
 - 8354273: Restore even more pointless unicode characters to ASCII

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24567/files
  - new: https://git.openjdk.org/jdk/pull/24567/files/876708c2..a07ef96d

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

  Stats: 273049 lines in 2453 files changed: 80961 ins; 183018 del; 9070 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 mbaesken at openjdk.org  Tue May  6 14:18:25 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 6 May 2025 14:18:25 GMT
Subject: Integrated: 8355979: ATTRIBUTE_NO_UBSAN needs to be extended to handle
 float divisions by zero on AIX
In-Reply-To: <CbiD1gny6_AnRa8wj35UTQrEax7JsnPJ2vOrikOWTB8=.ac4b7cee-59e8-4af9-bf46-dafc834b8c4d@github.com>
References: <CbiD1gny6_AnRa8wj35UTQrEax7JsnPJ2vOrikOWTB8=.ac4b7cee-59e8-4af9-bf46-dafc834b8c4d@github.com>
Message-ID: <6wqzprQ0jouL5AXs6K7EYvgMQbr_BawkG6fB5oO2kG0=.1720fa45-21a9-4de9-8758-d52bb510e8ac@github.com>

On Wed, 30 Apr 2025 13:04:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Seems the currently used ATTRIBUTE_NO_UBSAN does not handle the exclusion of float divisions by zero.
> At least this is the case on AIX.
> 
> (seen in the jtreg test java/lang/Math/PowTests.java )

This pull request has now been integrated.

Changeset: 088825ed
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/088825ed889551e6067d46bf77fe4d30a3972da1
Stats:     12 lines in 2 files changed: 6 ins; 0 del; 6 mod

8355979: ATTRIBUTE_NO_UBSAN needs to be extended to handle float divisions by zero on AIX

Reviewed-by: jkern, lucy

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

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

From liach at openjdk.org  Tue May  6 14:36:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 14:36:03 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v6]
In-Reply-To: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
Message-ID: <CPKq4Kxrl_u6oiLvEtxEsqUDJqm0xQhO8EmJau80J8M=.9dd92058-4ac2-4de7-a986-a97fee5e0ee9@github.com>

> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
> 
> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
> 
> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
> 
> Testing: jdk/lang/foreign, tier 1-3 in progress.

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 nine additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states
 - rollback OS
 - Review remarks
 - No env to test
   
 - Unchecked
   
 - Further revamp, remove unnecessary instances on irrelevant platforms
   
 - Bugid
 - 8356126: Revisit CaptureCallState

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25025/files
  - new: https://git.openjdk.org/jdk/pull/25025/files/d1598afa..2ead9d6d

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

  Stats: 2943 lines in 162 files changed: 2315 ins; 163 del; 465 mod
  Patch: https://git.openjdk.org/jdk/pull/25025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25025/head:pull/25025

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

From rriggs at openjdk.org  Tue May  6 14:38:21 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 May 2025 14:38:21 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v5]
In-Reply-To: <bF_OnxOCbrFO-atOiCBXIJp_JxT2__hFunyZV-aTPs0=.2da5ecfe-81e1-4723-9bab-65aec9c808e2@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
 <bF_OnxOCbrFO-atOiCBXIJp_JxT2__hFunyZV-aTPs0=.2da5ecfe-81e1-4723-9bab-65aec9c808e2@github.com>
Message-ID: <R2I6V2pGM7EcNG1lGYXrJ4lrpyCPtpvrXNzJKSBFDCA=.ebd80a7a-e6aa-4e94-90c4-b5d2de6cb828@github.com>

On Mon, 5 May 2025 17:29:33 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> A fix to throw `OutOfMemoryError`, as done in releases ? 23.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Increased min heap size to 8G.

Looks good, thanks

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25038#pullrequestreview-2818538058

From pminborg at openjdk.org  Tue May  6 14:40:46 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 May 2025 14:40:46 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v2]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <dPNU_d4_dn_kdgjRtmQIY9kQJai2T5AeRwaxjJEqdEE=.aaf0100b-cbb0-40ff-b321-3a260fccef6b@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

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

  Fix raw long updater under 32-bit mode

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/33e1779c..52e96c52

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

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

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

From rriggs at openjdk.org  Tue May  6 15:00:25 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 May 2025 15:00:25 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <Q3mFphXP94IQIDZx-aIjwPi5OChb1NbVneZg9Lc0TiA=.10b1cc44-2039-40b8-ad1e-3a2b4ff48d8b@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
 <Q3mFphXP94IQIDZx-aIjwPi5OChb1NbVneZg9Lc0TiA=.10b1cc44-2039-40b8-ad1e-3a2b4ff48d8b@github.com>
Message-ID: <mzbNgWPqFD9y_ehCc_CcjOnBvsLQ-CzLW-DyoWceuuE=.dcb33039-61f9-4a70-ab64-70c5bca2909a@github.com>

On Tue, 6 May 2025 01:38:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder.
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 277:
> 
>> 275:                 // copy all bytes to new larger buffer
>> 276:                 value = Arrays.copyOf(value,
>> 277:                         newCapacity(value, newCoder, minimumCapacity) << newCoder);
> 
> Would this benefit with an `assert` to verify that the new buffer length being proposed is not lesser than the current buffer's length (thus truncating content). Something like:
> 
> 
> // copy all bytes to new larger buffer
> int newLen = newCapacity(value, newCoder, minimumCapacity) << newCoder;
> assert newLen >= value.length : "bad new length " + newLen + " for buffer's length " + value.length; 
> value = Arrays.copyOf(value, newLen);

I'd be concerned about bloating the code size for a check that will not be triggered.
`growth` is non-negative and `newCapacity()` uses the same comparison to determine its growth value.
If ArraySupport.newLength can't satisify the request, it will throw.

> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 309:
> 
>> 307:         if (minimumCapacity - oldCapacity > 0) {
>> 308:             value = Arrays.copyOf(value,
>> 309:                     newCapacity(value, coder, minimumCapacity) << coder);
> 
> Same question about whether we should assert that the new length we determine for the buffer is not lesser than the current buffer length.

ditto, will not return a shorter array, it will throw instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075667207
PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075668360

From rriggs at openjdk.org  Tue May  6 15:10:19 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 May 2025 15:10:19 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <_RBFenZwdc85lHZTiCz8ir6kYkH4ZegtjBDwKRQYk_M=.b289d795-a36c-481b-9fce-478ba450fbc3@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
 <_RBFenZwdc85lHZTiCz8ir6kYkH4ZegtjBDwKRQYk_M=.b289d795-a36c-481b-9fce-478ba450fbc3@github.com>
Message-ID: <OByaVIba0yHkHGWUeimSk2-VqegnUdtK8A5gm_5dlw4=.54eb91bb-4bc5-449c-a097-bd0ae9a4b089@github.com>

On Tue, 6 May 2025 13:03:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I see that in the proposed changes, we are now using the same names for these local variables and method parameters as the field names. Would using different names for these local variables be better? To avoid shadowing the field names (`value`, `coder` and `count`)? I think that could help prevent future (accidental) refactoring changes that end up unintentionally accessing fields instead of local variables.

A valid concern. Opinions vary about the value/risk of shadowing.
Here the code is more readable using the familiar field names for all of the computations and
highlighting the use of `this.` to identify the copying out of and into the fields while reviewing and auditing the code.

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

PR Comment: https://git.openjdk.org/jdk/pull/24967#issuecomment-2854917666

From ihse at openjdk.org  Tue May  6 15:12:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 15:12:19 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <TDmCfGJjSU6S6OtslOdj06Mx2-15BuufvsalEcQWt7Q=.df27883d-e6f4-48e5-82ed-9ad2be53340e@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
 <L61KEZBpl0QV70RZVdSL3fo8R_sAE5WFC5BYK7R4_dg=.0d304f25-bc33-4f66-8f2e-85cda92cb8d4@github.com>
 <j0CHZTYVTsJKo4n5PTtDk23ZVbrwiELWAL9qOrX95GE=.fe1d18fe-c312-47c7-82b6-f6d1780024cc@github.com>
 <TDmCfGJjSU6S6OtslOdj06Mx2-15BuufvsalEcQWt7Q=.df27883d-e6f4-48e5-82ed-9ad2be53340e@github.com>
Message-ID: <9Q_tHeUczynfbPen9yg52qG1NY6z_jVXFgIEnPcsh84=.7544bce2-ed3d-47fe-bb00-5c23bad638a8@github.com>

On Thu, 17 Apr 2025 16:26:59 GMT, Naoto Sato <naoto at openjdk.org> 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?
>
>> 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.

@naotoj Unfortunately, I do not have the possibility to test on a Windows machine with Chinese locale.

I'll ping Yi Yang who was behind https://github.com/openjdk/jdk/pull/3107, a suggested solution for [JDK-8263028](https://bugs.openjdk.org/browse/JDK-8263028). That is the best I was able to dig up for any contributor that clearly had run into this kind of problems before. 

@y1yang0 Can you please help us to test this patch so it works properly on Windows computers with Chinese locale?

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2854924350

From rriggs at openjdk.org  Tue May  6 15:23:39 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 May 2025 15:23:39 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v6]
In-Reply-To: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
Message-ID: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com>

> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
> Support methods are static, designed to pass all values as arguments and return a value.
> 
> The value byte array is reallocated under 3 conditions:
> - Increasing the capacity with the same encoder
> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
> - Inflation with the same capacity
> 
> Added StressSBTest to exercise public instance methods of StringBuilder.

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

  Apply reviewer suggestions for typos, javadoc, and copyright dates.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24967/files
  - new: https://git.openjdk.org/jdk/pull/24967/files/80992a20..efd6fed1

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

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

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

From duke at openjdk.org  Tue May  6 15:23:39 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 6 May 2025 15:23:39 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
Message-ID: <6fwx-RiRnE_IhQacZgAPnrF4S5Bd4DG7mw79RxZCea8=.4a62d7e4-d5ef-4301-bc08-c284167782d1@github.com>

On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 2101:

> 2099:     }
> 2100: 
> 2101:     private AbstractStringBuilder repeat(char c, int count) {

How about renaming the `count` parameter here so that it is obviously distinct from the meaning of `count` elsewhere in this class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075710531

From rriggs at openjdk.org  Tue May  6 15:23:39 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 May 2025 15:23:39 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <gfd4LFvYLcgdcZ6u6eJAqnpET0guLJS8f19tGkMH22Q=.bf56a9c1-f15a-4f61-bfbc-ed4949772b8d@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
 <gfd4LFvYLcgdcZ6u6eJAqnpET0guLJS8f19tGkMH22Q=.bf56a9c1-f15a-4f61-bfbc-ed4949772b8d@github.com>
Message-ID: <NsU39L3e4j093vXi_YGsuIOOsvdUJ_O4lYK21bQqXos=.27dc9337-3d41-47b9-8212-519947ccf1dc@github.com>

On Tue, 6 May 2025 13:59:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder.
>
> test/jdk/java/lang/StringBuilder/StressSBTest.java line 72:
> 
>> 70:     /**
>> 71:      * Stress test using a number of platform threads for a duration.
>> 72:      * Success is marked by a lack of exceptions.
> 
> If I'm reading the test correctly, then the exceptions that happen in the launched thread are merely logged and thus the test will never throw any exceptions and will never fail?

Yes, the logging is there to help assess how often racy use results in unpredictable (exception) behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075705736

From ihse at openjdk.org  Tue May  6 15:25:43 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 15:25:43 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v4]
In-Reply-To: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
Message-ID: <j5PlYeoS1GTp8KizABIEWkGmacjxdU1cVbXNFU6Q05Y=.46cca0c8-7e0b-4eab-b59b-b6920fad8557@github.com>

> 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 two additional commits since the last revision:

 - Add informative message  about supported locales.
 - Allow C locale with warning instead of fatal error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24574/files
  - new: https://git.openjdk.org/jdk/pull/24574/files/452f42dc..9ce59e1f

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

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 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 jpai at openjdk.org  Tue May  6 15:29:16 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 15:29:16 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <OByaVIba0yHkHGWUeimSk2-VqegnUdtK8A5gm_5dlw4=.54eb91bb-4bc5-449c-a097-bd0ae9a4b089@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
 <_RBFenZwdc85lHZTiCz8ir6kYkH4ZegtjBDwKRQYk_M=.b289d795-a36c-481b-9fce-478ba450fbc3@github.com>
 <OByaVIba0yHkHGWUeimSk2-VqegnUdtK8A5gm_5dlw4=.54eb91bb-4bc5-449c-a097-bd0ae9a4b089@github.com>
Message-ID: <3PXIAd_Exlyp5GTGdYJgbEhWjHmeXtbhgiHmwVBPo3s=.f7c9f696-ea2e-4222-81c5-5616f65c8bae@github.com>

On Tue, 6 May 2025 15:07:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> > I see that in the proposed changes, we are now using the same names for these local variables and method parameters as the field names. Would using different names for these local variables be better? To avoid shadowing the field names (`value`, `coder` and `count`)? I think that could help prevent future (accidental) refactoring changes that end up unintentionally accessing fields instead of local variables.
> 
> A valid concern. Opinions vary about the value/risk of shadowing. Here the code is more readable using the familiar field names for all of the computations and highlighting the use of `this.` to identify the copying out of and into the fields while reviewing and auditing the code.

Fair enough.

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

PR Comment: https://git.openjdk.org/jdk/pull/24967#issuecomment-2855021639

From rriggs at openjdk.org  Tue May  6 15:29:18 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 May 2025 15:29:18 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v5]
In-Reply-To: <6fwx-RiRnE_IhQacZgAPnrF4S5Bd4DG7mw79RxZCea8=.4a62d7e4-d5ef-4301-bc08-c284167782d1@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <9hPk2f-WQDS7QiNUF635emHkyEy9lVAm1XEpnYxuMsA=.20ac101b-ea91-44f1-8fe4-06b9255ee775@github.com>
 <6fwx-RiRnE_IhQacZgAPnrF4S5Bd4DG7mw79RxZCea8=.4a62d7e4-d5ef-4301-bc08-c284167782d1@github.com>
Message-ID: <mrieTZADr2bqWGiiaLGK022iDifVG7D_7WX5FGXChSk=.f569d23d-9e63-4f15-b718-13bb91ff550c@github.com>

On Tue, 6 May 2025 15:19:09 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor to consistently use `isLatin1(coder)` within AbstractStringBuilder.
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 2101:
> 
>> 2099:     }
>> 2100: 
>> 2101:     private AbstractStringBuilder repeat(char c, int count) {
> 
> How about renaming the `count` parameter here so that it is obviously distinct from the meaning of `count` elsewhere in this class.

Yes, that's a bit unfortunate overloading of the parameter name as defined in the public `repeat` methods.
Maybe that can be considered more fully in a separate PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075727565

From ihse at openjdk.org  Tue May  6 15:29:27 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 15:29:27 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <mv1LIyvIryUorv8s6UP5jSqhSqj14dNOUEF4TIpQC84=.fd0a5b7d-4cf1-42ab-bd17-615c6fc913a9@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
 <mv1LIyvIryUorv8s6UP5jSqhSqj14dNOUEF4TIpQC84=.fd0a5b7d-4cf1-42ab-bd17-615c6fc913a9@github.com>
Message-ID: <0yCHTP7eQgosQh4hZ5khOXUulKb6gRx_uCr7Rl785Zg=.16873d03-5d82-49f0-9ad4-26330b3282d0@github.com>

On Wed, 16 Apr 2025 10:35:02 GMT, Matthias Baesken <mbaesken at openjdk.org> 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)

@MBaesken I added an informative text about supported locales. I also lowered the fatal error of missing an UTF-8 locale into just a warning (for all platforms, not just AIX). Apparently it works with building on AIX for now, even with a undefined character encoding, but I will not guarantee that it will continue to work for all eternity. But a warning is probably be enough, and if it does work the user is free to try. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24574#discussion_r2075728219

From ihse at openjdk.org  Tue May  6 15:39:04 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 15:39:04 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v5]
In-Reply-To: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
Message-ID: <Jb7VOfKdtOj2kvoGjgBsmb-J31uB_FHlkLY_ulG1um4=.7027776d-c936-4ff7-9afc-7e91ca110d21@github.com>

> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Merge branch 'master' into go-full-utf8
 - Add informative message  about supported locales.
 - Allow C locale with warning instead of fatal error
 - Also document UTF-8 requirements (solves JDK-8338973)
 - Let configure only accept utf-8 locales
 - Address review comments from Kim
 - Also tell javadoc that we have utf-8 now
 - Fix flags for Windows
 - Mark java and native source code as utf-8
 - Don't convert properties files to iso-8859-1.
 - ... and 3 more: https://git.openjdk.org/jdk/compare/e43ea2cd...bea19a70

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24574/files
  - new: https://git.openjdk.org/jdk/pull/24574/files/9ce59e1f..bea19a70

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

  Stats: 273063 lines in 2455 files changed: 80969 ins; 183018 del; 9076 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 dfuchs at openjdk.org  Tue May  6 15:39:19 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 6 May 2025 15:39:19 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v2]
In-Reply-To: <dPNU_d4_dn_kdgjRtmQIY9kQJai2T5AeRwaxjJEqdEE=.aaf0100b-cbb0-40ff-b321-3a260fccef6b@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <dPNU_d4_dn_kdgjRtmQIY9kQJai2T5AeRwaxjJEqdEE=.aaf0100b-cbb0-40ff-b321-3a260fccef6b@github.com>
Message-ID: <9CHAvFJuNMdvc-UdKIhL9Bv1vDU3m30YZARCta1LETc=.b4b95bbd-5b70-4a6a-bc7a-196344812610@github.com>

On Tue, 6 May 2025 14:40:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix raw long updater under 32-bit mode

src/java.base/share/classes/java/net/URI.java line 558:

> 556: 
> 557:     // Used reflectively by HASH_UPDATER
> 558:     @Stable

What are the effect of this change on startup time? I remember that @cl4es made a number of changes to URI to improve startup. Maybe this change should be dropped out of this PR for now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2075743220

From ihse at openjdk.org  Tue May  6 15:39:24 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 15:39:24 GMT
Subject: RFR: 8354273: Replace even more Unicode characters with ASCII [v3]
In-Reply-To: <Ynl7ATLqF5wm7um0BI3RwZC2IO9VObO1blOBXNny1Sk=.0fedb3c5-dd77-4123-82a8-ecde62b4f01f@github.com>
References: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
 <Ynl7ATLqF5wm7um0BI3RwZC2IO9VObO1blOBXNny1Sk=.0fedb3c5-dd77-4123-82a8-ecde62b4f01f@github.com>
Message-ID: <NO4E3P79QlBsrC6zcQwwbnA4FgXHvAaMZXAwucxFtps=.7f0248af-a382-4f2d-a5c8-ebb1af37e5bd@github.com>

On Tue, 6 May 2025 14:16:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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 with a new target base 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 restore-more-ascii
>  - Remove incorrectly copied "?anchor"
>  - 8354273: Restore even more pointless unicode characters to ASCII

Ping?

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

PR Comment: https://git.openjdk.org/jdk/pull/24567#issuecomment-2855052189

From bpb at openjdk.org  Tue May  6 15:43:07 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 6 May 2025 15:43:07 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v16]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: <2AyhnZiLia6FKXoJlSzArzhIiWCchzGM_EJ9hWj93_Y=.175dfeff-fc4e-46f8-9c80-413b9e4971e3@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: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/db338317..983aeb50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=14-15

  Stats: 96 lines in 3 files changed: 29 ins; 47 del; 20 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 ihse at openjdk.org  Tue May  6 15:46:03 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 15:46:03 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters [v2]
In-Reply-To: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
Message-ID: <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>

> 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.

Magnus Ihse Bursie has updated the pull request with a new target base 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 unicode-sequence-in-comments
 - 8354968: Replace unicode sequences in comment text with UTF-8 characters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24727/files
  - new: https://git.openjdk.org/jdk/pull/24727/files/ae1166af..694b33dc

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

  Stats: 273063 lines in 2455 files changed: 80969 ins; 183018 del; 9076 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 jpai at openjdk.org  Tue May  6 15:51:17 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 15:51:17 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v6]
In-Reply-To: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com>
Message-ID: <o9yZb6L3QUKvaAHxBf8BZ84NQUm1KvMq-MXF4tKwLk0=.0053af5e-b16d-42d2-99c2-e7bc47b75089@github.com>

On Tue, 6 May 2025 15:23:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply reviewer suggestions for typos, javadoc, and copyright dates.

Thank you for the updates. Overall the changes in this PR look good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24967#pullrequestreview-2818782618

From liach at openjdk.org  Tue May  6 15:51:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 15:51:54 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v7]
In-Reply-To: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
Message-ID: <9dkxuF2Tli8rNGcKcHwuNmzbb0zSwUzWR4KfaXBs0eY=.bbde1f02-98fe-49d6-b27b-057b75a5116e@github.com>

> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
> 
> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
> 
> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
> 
> Testing: jdk/lang/foreign, tier 1-3 in progress.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java
  
  Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25025/files
  - new: https://git.openjdk.org/jdk/pull/25025/files/2ead9d6d..450ea115

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

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

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

From liach at openjdk.org  Tue May  6 15:51:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 15:51:55 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v5]
In-Reply-To: <DPzyChsToCnF_jbXWmIrY-XlU6yVST4THQg4gFlAou8=.93f32778-e9da-436b-a023-c18a5b59b373@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <jdZkdPn3QI3c-QklFui6Aj7hXcn0pPrV7kMQ0w4tEQ0=.37ea8bef-fa3f-440f-875c-6450539517a0@github.com>
 <DPzyChsToCnF_jbXWmIrY-XlU6yVST4THQg4gFlAou8=.93f32778-e9da-436b-a023-c18a5b59b373@github.com>
Message-ID: <1ZRryOd8Xk_Eu6uqiUBWav8Ss5IKpOpyT1U0Xj_27Tg=.dc714b83-1fa1-4389-893a-b5d9e892fc2d@github.com>

On Tue, 6 May 2025 09:35:16 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks
>
> src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 59:
> 
>> 57:         MemoryLayout[] stateLayouts = new MemoryLayout[supported.size()];
>> 58:         @SuppressWarnings({"unchecked", "rawtypes"})
>> 59:         Map.Entry<String, CapturableState>[] entries = new Map.Entry[supported.size()];
> 
> Suggestion:
> 
>         CapturableState[] supported;
> 
>         if (OperatingSystem.isWindows()) {
>             supported = new CapturableState[] {
>                     new CapturableState("GetLastError", JAVA_INT, 1 << 0),
>                     new CapturableState("WSAGetLastError", JAVA_INT, 1 << 1),
>                     new CapturableState("errno", JAVA_INT, 1 << 2)
>             };
>         } else {
>             supported = new CapturableState[] {new CapturableState("errno", JAVA_INT, 1 << 2)};
>         }
> 
>         MemoryLayout[] stateLayouts = new MemoryLayout[supported.length];
>         @SuppressWarnings({"unchecked", "rawtypes"})
>         Map.Entry<String, CapturableState>[] entries = new Map.Entry[supported.length];
> 
> Here it might be better to replace List with an array

I think I might ask @JornVernee for opinion as that is the original author.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075764944

From liach at openjdk.org  Tue May  6 15:51:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 15:51:55 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v5]
In-Reply-To: <32ucY7tR1BkXyswk9VFkOzuvvN4f5DecNZNZ_2BtgHE=.1fafacc7-aad9-4c30-a76c-df0b39ed57b6@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <jdZkdPn3QI3c-QklFui6Aj7hXcn0pPrV7kMQ0w4tEQ0=.37ea8bef-fa3f-440f-875c-6450539517a0@github.com>
 <32ucY7tR1BkXyswk9VFkOzuvvN4f5DecNZNZ_2BtgHE=.1fafacc7-aad9-4c30-a76c-df0b39ed57b6@github.com>
Message-ID: <pUWF1DGOAhsiuqrxN8v9WMumxZ1K6Nr9JYL4IWHPfuk=.1d3c04d5-24de-425f-bf5e-0f7b686d66f8@github.com>

On Tue, 6 May 2025 11:56:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks
>
> src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 81:
> 
>> 79: 
>> 80:     public static CapturableState forName(String name) {
>> 81:         var ret = LOOKUP.get(name);
> 
> As we usually have just one element (and for Windows three elements) it might be both less memory consuming and faster to just search a `@Stable` array linearly rather than having a Map.

`Map.get` still has cleaner code than an array iteration, and there is already a Map1 optimized implementation. I think map is more friendly in the long run.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075767137

From liach at openjdk.org  Tue May  6 15:51:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 15:51:55 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v5]
In-Reply-To: <nKfoXsr1PtS3P_AzHLlACBIeN1cloSADCNymio6HpqM=.655514ad-15da-4987-9ea1-a004779ad757@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <jdZkdPn3QI3c-QklFui6Aj7hXcn0pPrV7kMQ0w4tEQ0=.37ea8bef-fa3f-440f-875c-6450539517a0@github.com>
 <Vq6842ZecVOtjaZ46tz6HoBlOl35HCvoA4_3hCRyTt4=.9f0aa0c5-01ff-48dd-afef-cdde8a40a803@github.com>
 <nKfoXsr1PtS3P_AzHLlACBIeN1cloSADCNymio6HpqM=.655514ad-15da-4987-9ea1-a004779ad757@github.com>
Message-ID: <nOrRF9hb1mLCvoNPGBZSQUEJ_-N3Ez8R9pW7tFTMMa8=.703c180a-15f3-402f-a929-2e05966fee68@github.com>

On Tue, 6 May 2025 12:07:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 88:
>> 
>>> 86: 
>>> 87:     // The current OperatingSystem
>>> 88:     private static @Stable OperatingSystem CURRENT_OS;
>> 
>> Could this be a `StableValue.supplier()`?
>
> I would rather optimize MethodHandleAccessorFactory than defining a new class for this...

Rolled back per @jaikiran.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075767396

From liach at openjdk.org  Tue May  6 15:51:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 15:51:55 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v4]
In-Reply-To: <rasxfoWU6irGim8uQjSSZaQg9_V7zdZ0swlDjBoE8S8=.12d34c7c-92fe-413f-a845-dcfaf1a2b888@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <2BKUaRCSlDt8e_LMe605ppcBsTLixlPE6aHQbcFu6tg=.0ec5e1bf-9e82-43e9-a17d-02ab7b8cb8fc@github.com>
 <uLQ9stJ_vYOCsQv0-aUg0lNyaEaBbql5Wjd8ueTtAmI=.c19e3ba5-4e93-4ab5-8c76-54dedbdfd756@github.com>
 <R0Z0V9chwQzLGtDUS72ouLffcUSv4dRBzk04ykFJT_8=.de0158e4-9892-4d47-abc0-f2c3540e927c@github.com>
 <rasxfoWU6irGim8uQjSSZaQg9_V7zdZ0swlDjBoE8S8=.12d34c7c-92fe-413f-a845-dcfaf1a2b888@github.com>
Message-ID: <6kFeuo8pz_X5YITDlJcc-SYUpJvhSxrW_OsMHXqOrio=.9ef6de4f-16f2-4606-991c-87c91b655e09@github.com>

On Tue, 6 May 2025 06:36:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Enum.valueOf -> Class.enumConstantDirectory -> Class.getEnumConstantsShared -> Method.invoke -> MethodHandleAccessorFactory.makeSpecializedTarget(isStatic = true) -> MethodHandles.dropArguments -> LambdaForm.editor -> bytecode generation and loading because this currently cannot be pregenerated by CDS archive.
>> 
>> If this class is broken, this would probably already surface at build time because this is used by jlink; otherwise it would have surfaced in Process tests. I don't think ensuring EIIE vs IAE is worth a test here.
>
> Thank you Chen for updating the issue type of bug.
> 
>> If this class is broken, this would probably already surface at build time because this is used by jlink; otherwise it would have surfaced in Process tests. I don't think ensuring EIIE vs IAE is worth a test here.
> 
> The current bug fix I think should just address the incorrect result from `captureCallState()`.
> 
> If the change to OperatingSystem class has practical improvements to the startup performance, then I think it's worth proposing. I suggest we do it in a separate and independent PR and the discussion and review for that change would have to take into account the existing comment in that class and see if it is no longer necessary.

Yep, rolled back OS changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075768065

From asemenyuk at openjdk.org  Tue May  6 16:43:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 6 May 2025 16:43:15 GMT
Subject: RFR: 8355249: Remove the use of WMIC from the entire source code
 [v2]
In-Reply-To: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
References: <blL6FOj7XD1T3u_ODIwYPIPDXEowzSR0w5j92nC9gCo=.8a2428d9-1795-4dd0-91fd-8b604c7cc100@github.com>
 <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
Message-ID: <aXrQkdaJSIVjXK34cEBg-1tb91EnSOsgPvQnSE3B50M=.62662f8f-a528-4fa5-b6c5-0c3bb5c7e587@github.com>

On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata <duke at openjdk.org> wrote:

>> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI.
>> 
>> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency.
>> 
>> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file.
>> Note: In my environment, it worked correctly even without these options.
>> 
>> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in:
>> 
>> - `environment.html`: `windows/system/os` section
>> - `process.html`: `[Process ID]/windows/native/info` section
>> 
>> **Testing:**
>> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes.
>
> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   run jcheck

Marked as reviewed by asemenyuk (Reviewer).

Looks good assuming jpackage tests ([test/jdk/tools/jpackage/windows/WinNoRestartTest.java](https://github.com/openjdk/jdk/blob/a6995a3d42955f1f207c14be1634daf225b5ab3f/test/jdk/tools/jpackage/windows/Win8301247Test.java#L24) and [test/jdk/tools/jpackage/windows/Win8301247Test.java](https://github.com/openjdk/jdk/blob/a6995a3d42955f1f207c14be1634daf225b5ab3f/test/jdk/tools/jpackage/windows/Win8301247Test.java#L24)) passed with this change.

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

PR Review: https://git.openjdk.org/jdk/pull/24791#pullrequestreview-2818983754
PR Comment: https://git.openjdk.org/jdk/pull/24791#issuecomment-2855254506

From naoto at openjdk.org  Tue May  6 16:45:26 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 May 2025 16:45:26 GMT
Subject: RFR: 8354273: Replace even more Unicode characters with ASCII [v3]
In-Reply-To: <Ynl7ATLqF5wm7um0BI3RwZC2IO9VObO1blOBXNny1Sk=.0fedb3c5-dd77-4123-82a8-ecde62b4f01f@github.com>
References: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
 <Ynl7ATLqF5wm7um0BI3RwZC2IO9VObO1blOBXNny1Sk=.0fedb3c5-dd77-4123-82a8-ecde62b4f01f@github.com>
Message-ID: <i7yFd48vuJdikLZgeiz-IA4ww7ecKEDHrgLWiE_P7Oo=.fc92ab9b-8fc2-480d-81e5-61be832f6014@github.com>

On Tue, 6 May 2025 14:16:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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 with a new target base 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 restore-more-ascii
>  - Remove incorrectly copied "?anchor"
>  - 8354273: Restore even more pointless unicode characters to ASCII

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24567#pullrequestreview-2818989660

From duke at openjdk.org  Tue May  6 16:56:22 2025
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 May 2025 16:56:22 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v11]
In-Reply-To: <2Awpgkw3OvX8ZzVWLnn9HKHcDqFF2jFN5-m-knxeWAw=.eb199166-6cc0-4d38-9cbc-138f82577e6f@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <bY6wxELBjJnRQ5co73NgJC5baGtnY5UKezuQXCvYU5E=.82004266-7468-484d-a28c-85852d06f8d9@github.com>
 <PBiSYA5aqDEnMIqV_0e7cvAbmc6YmO78SqKDx168qsU=.2b4c3790-b3c6-4ce3-a916-36a5e4c402a4@github.com>
 <ElaSulVLeJ_WM0ZsWa1S2ZlOR9LCc8DYQ3c3gibUlpo=.27648334-e818-4b65-b68d-708b28593f2c@github.com>
 <2Awpgkw3OvX8ZzVWLnn9HKHcDqFF2jFN5-m-knxeWAw=.eb199166-6cc0-4d38-9cbc-138f82577e6f@github.com>
Message-ID: <lThLnLsk8uwE00XkdS0zLsRt0-4aMQIQhYuPVGDQa50=.2a69fa6b-9662-4add-8aa4-16f6c6152069@github.com>

On Tue, 6 May 2025 11:30:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > do you mean merging master branch into this branch?
> 
> Yes, that's correct. That should then run the GitHub actions job against this PR against a more relevant state of this PR.
> 
> Since things have settled and the CSR approved, I'll also run this PR against our CI to verify nothing fails unexpectedly. I will anyway be doing the merge against master locally before submitting for tier testing, but it's always a good practice to keep the PR updated with latest master changes, when the master branch has seen too many commits since the PR was opened.

Yes that is pretty clear. I'm using git since decades but always do rebase in all other project, so my question was only about *how* to perform the update. ?

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

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

From jpai at openjdk.org  Tue May  6 17:05:20 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 May 2025 17:05:20 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v11]
In-Reply-To: <lThLnLsk8uwE00XkdS0zLsRt0-4aMQIQhYuPVGDQa50=.2a69fa6b-9662-4add-8aa4-16f6c6152069@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <bY6wxELBjJnRQ5co73NgJC5baGtnY5UKezuQXCvYU5E=.82004266-7468-484d-a28c-85852d06f8d9@github.com>
 <PBiSYA5aqDEnMIqV_0e7cvAbmc6YmO78SqKDx168qsU=.2b4c3790-b3c6-4ce3-a916-36a5e4c402a4@github.com>
 <ElaSulVLeJ_WM0ZsWa1S2ZlOR9LCc8DYQ3c3gibUlpo=.27648334-e818-4b65-b68d-708b28593f2c@github.com>
 <2Awpgkw3OvX8ZzVWLnn9HKHcDqFF2jFN5-m-knxeWAw=.eb199166-6cc0-4d38-9cbc-138f82577e6f@github.com>
 <lThLnLsk8uwE00XkdS0zLsRt0-4aMQIQhYuPVGDQa50=.2a69fa6b-9662-4add-8aa4-16f6c6152069@github.com>
Message-ID: <6tJ94UzFn2GwHMB9WK3Xeig34edB02mMoWw8_ZjPMzc=.a69e8f1b-edd4-4c89-b34f-8248b11852c4@github.com>

On Tue, 6 May 2025 16:53:07 GMT, Markus KARG <duke at openjdk.org> wrote:

> so my question was only about how to perform the update.

Locally, if your remote repo that points to github.com/openjdk/jdk is named `upstream` and the local branch from which you have created this PR is named `getchars`, then you would do something like the following:


# fetch latest changes in master branch of github.com/openjdk/jdk
git fetch upstream master
# update your local workspace to your local getchars branch (if you aren't already on it)
git switch getchars
# merge the changes from upstream master branch into this local getchars branch
git merge -m "merge latest from master branch" upstream/master

If there are no merge resolution conflicts, then those command should be enough and your local `getchars` branch should now have the upstream master changes.

Once you build and test locally you can then push those changes from `getchars` branch to your forked remote repo's getchars branch (and thus automatically update this PR) using:


# while being on getchars branch locally and your forked remote is named mkarg-remote
git push mkarg-remote getchars

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

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

From jvernee at openjdk.org  Tue May  6 17:16:21 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 6 May 2025 17:16:21 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v5]
In-Reply-To: <1ZRryOd8Xk_Eu6uqiUBWav8Ss5IKpOpyT1U0Xj_27Tg=.dc714b83-1fa1-4389-893a-b5d9e892fc2d@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <jdZkdPn3QI3c-QklFui6Aj7hXcn0pPrV7kMQ0w4tEQ0=.37ea8bef-fa3f-440f-875c-6450539517a0@github.com>
 <DPzyChsToCnF_jbXWmIrY-XlU6yVST4THQg4gFlAou8=.93f32778-e9da-436b-a023-c18a5b59b373@github.com>
 <1ZRryOd8Xk_Eu6uqiUBWav8Ss5IKpOpyT1U0Xj_27Tg=.dc714b83-1fa1-4389-893a-b5d9e892fc2d@github.com>
Message-ID: <sPwRTPrWCuLYGa-HZUjivEnSrVtXK9-YlfHGdjCNf0w=.ca779601-f162-4b0f-89b4-8f79ad4b91ae@github.com>

On Tue, 6 May 2025 15:46:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 59:
>> 
>>> 57:         MemoryLayout[] stateLayouts = new MemoryLayout[supported.size()];
>>> 58:         @SuppressWarnings({"unchecked", "rawtypes"})
>>> 59:         Map.Entry<String, CapturableState>[] entries = new Map.Entry[supported.size()];
>> 
>> Suggestion:
>> 
>>         CapturableState[] supported;
>> 
>>         if (OperatingSystem.isWindows()) {
>>             supported = new CapturableState[] {
>>                     new CapturableState("GetLastError", JAVA_INT, 1 << 0),
>>                     new CapturableState("WSAGetLastError", JAVA_INT, 1 << 1),
>>                     new CapturableState("errno", JAVA_INT, 1 << 2)
>>             };
>>         } else {
>>             supported = new CapturableState[] {new CapturableState("errno", JAVA_INT, 1 << 2)};
>>         }
>> 
>>         MemoryLayout[] stateLayouts = new MemoryLayout[supported.length];
>>         @SuppressWarnings({"unchecked", "rawtypes"})
>>         Map.Entry<String, CapturableState>[] entries = new Map.Entry[supported.length];
>> 
>> Here it might be better to replace List with an array
>
> I think I might ask @JornVernee for opinion as that is the original author.

Either one works I think. Array might be a bit more efficient. Don't think it matters much though

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075931062

From swen at openjdk.org  Tue May  6 17:19:18 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 6 May 2025 17:19:18 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v3]
In-Reply-To: <qGh4TxJ7MIudua-Xk4iMx354D_QLCN1in8u2G0qk4F0=.c6e77625-0a27-4876-99e6-49431ad78798@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com>
 <kdQ0cQYPOnJu1nON4BYTube75JfjVWp-2CfsPfz2AU8=.f1fe7acf-a054-4e19-b51f-51e092daef39@github.com>
 <qGh4TxJ7MIudua-Xk4iMx354D_QLCN1in8u2G0qk4F0=.c6e77625-0a27-4876-99e6-49431ad78798@github.com>
Message-ID: <Rp5KEWwo32Q1xji7MPrEXzdLwOPRwFBqwBfyP4GviuA=.1dc73cc9-550f-4a1b-ac03-34a2fb302af1@github.com>

On Tue, 6 May 2025 12:30:01 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 390:
>> 
>>> 388:                 return MhUtil.findVirtual(LOOKUP, Arena.class, "close",
>>> 389:                         MethodType.methodType(void.class));
>>> 390:         }
>> 
>> Suggestion:
>> 
>>         return switch (index) {
>>             case NON_NEGATIVE_INT -> MhUtil.findStatic(LOOKUP, "nonNegative",
>>                     MethodType.methodType(boolean.class, int.class));
>>             case SUCCESS_INT -> MhUtil.findStatic(LOOKUP, "success",
>>                     MethodType.methodType(int.class, int.class, MemorySegment.class));
>>             case ERROR_INT -> MhUtil.findStatic(LOOKUP, "error",
>>                     MethodType.methodType(int.class, MethodHandle.class, int.class, MemorySegment.class));
>>             case NON_NEGATIVE_LONG -> MhUtil.findStatic(LOOKUP, "nonNegative",
>>                     MethodType.methodType(boolean.class, long.class));
>>             case SUCCESS_LONG -> MhUtil.findStatic(LOOKUP, "success",
>>                     MethodType.methodType(long.class, long.class, MemorySegment.class));
>>             case ERROR_LONG -> MhUtil.findStatic(LOOKUP, "error",
>>                     MethodType.methodType(long.class, MethodHandle.class, long.class, MemorySegment.class));
>>             case ACQUIRE_ARENA -> MhUtil.findStatic(LOOKUP, "acquireArena",
>>                     MethodType.methodType(Arena.class));
>>             case ALLOCATE -> MhUtil.findStatic(LOOKUP, "allocate",
>>                     MethodType.methodType(MemorySegment.class, Arena.class));
>>             case ARENA_CLOSE -> MhUtil.findVirtual(LOOKUP, Arena.class, "close",
>>                     MethodType.methodType(void.class));
>>             default -> throw new InternalError("Unknown index: " + index);
>>         };
>> 
>> Switch statement can be replaced with enhanced 'switch'
>
> I have the old switch format in anticipation of faster startup.

enhanced 'switch' is just syntax sugar and does not affect startup speed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2075935264

From naoto at openjdk.org  Tue May  6 17:21:18 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 May 2025 17:21:18 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters [v2]
In-Reply-To: <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
 <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>
Message-ID: <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>

On Tue, 6 May 2025 15:46:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> 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.
>
> Magnus Ihse Bursie has updated the pull request with a new target base 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 unicode-sequence-in-comments
>  - 8354968: Replace unicode sequences in comment text with UTF-8 characters

src/java.base/share/classes/java/text/Collator.java line 141:

> 139:      * considered significant during comparison. The assignment of strengths
> 140:      * to language features is locale dependent. A common example is for
> 141:      * different accented forms of the same base letter ("a" vs "?") to be

Since this (and the other one in RuleBasedCollator) is in the explanation of text handling, I think keeping the original code point makes sense. So I'd have both UTF-8 string and its Unicode escape notation here.

src/java.base/share/classes/java/text/RuleBasedCollator.java line 594:

> 592:         // a three-digit number, one digit for primary, one for secondary, etc.
> 593:         //
> 594:         // String:              A     a     B   ?

Maybe "? (\u00e9, e-acute)"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2075933987
PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2075935811

From jvernee at openjdk.org  Tue May  6 17:22:17 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 6 May 2025 17:22:17 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v5]
In-Reply-To: <pUWF1DGOAhsiuqrxN8v9WMumxZ1K6Nr9JYL4IWHPfuk=.1d3c04d5-24de-425f-bf5e-0f7b686d66f8@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <jdZkdPn3QI3c-QklFui6Aj7hXcn0pPrV7kMQ0w4tEQ0=.37ea8bef-fa3f-440f-875c-6450539517a0@github.com>
 <32ucY7tR1BkXyswk9VFkOzuvvN4f5DecNZNZ_2BtgHE=.1fafacc7-aad9-4c30-a76c-df0b39ed57b6@github.com>
 <pUWF1DGOAhsiuqrxN8v9WMumxZ1K6Nr9JYL4IWHPfuk=.1d3c04d5-24de-425f-bf5e-0f7b686d66f8@github.com>
Message-ID: <3SAlKbn9bHOENW0w-L3AWBmYjrebfJdQRKuLI7o8Nr8=.0beead30-081e-48ae-9620-eafc68f5b64f@github.com>

On Tue, 6 May 2025 15:47:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 81:
>> 
>>> 79: 
>>> 80:     public static CapturableState forName(String name) {
>>> 81:         var ret = LOOKUP.get(name);
>> 
>> As we usually have just one element (and for Windows three elements) it might be both less memory consuming and faster to just search a `@Stable` array linearly rather than having a Map.
>
> `Map.get` still has cleaner code than an array iteration, and there is already a Map1 optimized implementation. I think map is more friendly in the long run.

Alternatively, you could hard code the names in a `switch` here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075939248

From erikj at openjdk.org  Tue May  6 17:26:23 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 6 May 2025 17:26:23 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v5]
In-Reply-To: <Jb7VOfKdtOj2kvoGjgBsmb-J31uB_FHlkLY_ulG1um4=.7027776d-c936-4ff7-9afc-7e91ca110d21@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Jb7VOfKdtOj2kvoGjgBsmb-J31uB_FHlkLY_ulG1um4=.7027776d-c936-4ff7-9afc-7e91ca110d21@github.com>
Message-ID: <IKLgNAus-pIoBbMxsqdXHglNuc_uwV9gCgqLhddOxbs=.a3c0e925-af6b-4fcb-9520-5f2ed471cf0b@github.com>

On Tue, 6 May 2025 15:39:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into go-full-utf8
>  - Add informative message  about supported locales.
>  - Allow C locale with warning instead of fatal error
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim
>  - Also tell javadoc that we have utf-8 now
>  - Fix flags for Windows
>  - Mark java and native source code as utf-8
>  - Don't convert properties files to iso-8859-1.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/e6fcaea5...bea19a70

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2819093476

From duke at openjdk.org  Tue May  6 17:28:21 2025
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 May 2025 17:28:21 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <jd9LQJ0WWD1vKVsk1hr8aXdkGHGVnzLDibQeX79boGY=.65119ae7-1f98-4d4f-bf66-7af04a475fce@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <GJgmuQCLF4DikEHKInF6J_dZvd3V6SdyKSohOW2eqU0=.93b9933b-cbba-4084-a99e-c9316e710608@github.com>
 <6lD4tGZLf54gX50KgP-YGFAGTQhh0A7kh07p-XdOX-Y=.c30197c4-2ffa-4a7a-b5cb-98901427eaa7@github.com>
 <_gsm1O3oGkFRt64kDD7WKL2HG69RpOhvbwRTjhTMBWI=.0c7c0bfb-1783-4162-be25-90e3ebe6dc56@github.com>
 <jd9LQJ0WWD1vKVsk1hr8aXdkGHGVnzLDibQeX79boGY=.65119ae7-1f98-4d4f-bf66-7af04a475fce@github.com>
Message-ID: <p68N62KIXdVWryKCbu3mmqLwGf2fsDMGdGYqeb_soMM=.bf039f80-ed85-48cf-b693-ba3bab3761d9@github.com>

On Sun, 4 May 2025 05:08:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Oh, and we should set `next` afterwards, so the `Reader` knows that the end of the sequence is reached:
>> 
>> 
>> public String readAllChars() throws IOException {
>>     ensureOpen();
>>     var len = cs.length();
>>     var remainder = cs.subSequence(next, len);
>>     next = len;
>>     return remainder.toString();
>> }
>> 
>> 
>> (Edited my proposal to be a bit more concurrency-friendly and correct.)
>
> Probably best to ignore the implementation details as the discussions on what methods to expose, and where, is still going on. It was probably a bit premature to create the PR without getting agreement on the API first.

So at least it's not just me... ? ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2075948845

From jvernee at openjdk.org  Tue May  6 17:30:15 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 6 May 2025 17:30:15 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v7]
In-Reply-To: <9dkxuF2Tli8rNGcKcHwuNmzbb0zSwUzWR4KfaXBs0eY=.bbde1f02-98fe-49d6-b27b-057b75a5116e@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <9dkxuF2Tli8rNGcKcHwuNmzbb0zSwUzWR4KfaXBs0eY=.bbde1f02-98fe-49d6-b27b-057b75a5116e@github.com>
Message-ID: <0q687IquRkiGrlnoNQkNQUvTuLL_CxtgZ7UAW2WG26c=.5172a34c-aed9-4ad9-a7e1-9a0359236096@github.com>

On Tue, 6 May 2025 15:51:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
>> 
>> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
>> 
>> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
>> 
>> Testing: jdk/lang/foreign, tier 1-3 in progress.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java
>   
>   Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>

Looks good.

src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 55:

> 53:         } else {
> 54:             supported = List.of(new CapturableState("errno", JAVA_INT, 1 << 2));
> 55:         }

Maybe just split the initialization of `LAYOUT` and `LOOKUP` across these 2 branches, instead of collecting everything into intermediate arrays. i.e.

Suggestion:

        if (OperatingSystem.isWindows()) {
            LAYOUT = MemoryLayout.structLayout(
                JAVA_INT, // GetLastError
                JAVA_INT, // WSAGetLastError
                JAVA_INT // errno
            );
            LOOKUP = Map.of(
                "GetLastError", 1 << 0,
                "WSAGetLastError", 1 << 1,
                "errno", 1 << 2
            );
        } else {
            LAYOUT = MemoryLayout.structLayout(
                JAVA_INT // errno
            );
            LOOKUP = Map.of(
                "errno", 1 << 2
            );
        }

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25025#pullrequestreview-2819101227
PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075950579

From duke at openjdk.org  Tue May  6 17:33:20 2025
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 May 2025 17:33:20 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v11]
In-Reply-To: <bY6wxELBjJnRQ5co73NgJC5baGtnY5UKezuQXCvYU5E=.82004266-7468-484d-a28c-85852d06f8d9@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <bY6wxELBjJnRQ5co73NgJC5baGtnY5UKezuQXCvYU5E=.82004266-7468-484d-a28c-85852d06f8d9@github.com>
Message-ID: <3KjNbuZlZwyr7pAf6idOFXuQO7TUNYXya8nUPGvlkII=.ba5d118a-17bb-4b56-a11c-065a59788ca9@github.com>

On Thu, 1 May 2025 08:45:06 GMT, Markus KARG <duke at openjdk.org> 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 proposal by Daniel: If there's no change to this file the copyright year update could be reverted?

I know all that. As I said, I am using git since decades, so I know *lots* of alternative ways to update branches and even proposed the one you want, so I just needed to know *which of those alternatives* (not the exact commands) you *want*. Don't know why posted all that, as the question was already solved by you?! ?

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

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

From rgiulietti at openjdk.org  Tue May  6 17:35:22 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 6 May 2025 17:35:22 GMT
Subject: RFR: 8356152: String.concat can throw
 StringIndexOutOfBoundsException [v5]
In-Reply-To: <o-BR9svkpt8A0mFekAaDGCb9yWtSLU_UuXN4OL4wUYY=.259d8e92-8157-438d-ba2f-0e1631b1f68c@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
 <bF_OnxOCbrFO-atOiCBXIJp_JxT2__hFunyZV-aTPs0=.2da5ecfe-81e1-4723-9bab-65aec9c808e2@github.com>
 <o-BR9svkpt8A0mFekAaDGCb9yWtSLU_UuXN4OL4wUYY=.259d8e92-8157-438d-ba2f-0e1631b1f68c@github.com>
Message-ID: <FBZpb2DSl5M5TWqh6EdCsaImcj1MoHPr-WE2qdWir3s=.4fdb545c-70b1-4822-bd7e-431767ab3d06@github.com>

On Mon, 5 May 2025 20:58:56 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Increased min heap size to 8G.
>
> Marked as reviewed by aturbanov (Committer).

Thanks to the reviewers, and to @turbanoff for reporting.

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

PR Comment: https://git.openjdk.org/jdk/pull/25038#issuecomment-2855390232

From rgiulietti at openjdk.org  Tue May  6 17:35:23 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 6 May 2025 17:35:23 GMT
Subject: Integrated: 8356152: String.concat can throw
 StringIndexOutOfBoundsException
In-Reply-To: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
References: <OsdQg6Cnv6CREWLvQAi41HJrjwYxQN1orNv01o8Amdc=.189ec1b3-10d9-4357-99cf-3e379387184f@github.com>
Message-ID: <iH9UtvlIL0gmpPOUmz3Yc-sqh2fN9fukGjmsOTyIDyE=.c9bd60b8-9e98-4277-8b85-5140b788dead@github.com>

On Mon, 5 May 2025 13:07:45 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> A fix to throw `OutOfMemoryError`, as done in releases ? 23.

This pull request has now been integrated.

Changeset: 052e2522
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/052e2522b661e51b5fd2e0561c4866e97b9d170d
Stats:     79 lines in 2 files changed: 78 ins; 0 del; 1 mod

8356152: String.concat can throw StringIndexOutOfBoundsException

Reviewed-by: liach, aturbanov, redestad, rriggs

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

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

From liach at openjdk.org  Tue May  6 17:43:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 17:43:14 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v7]
In-Reply-To: <0q687IquRkiGrlnoNQkNQUvTuLL_CxtgZ7UAW2WG26c=.5172a34c-aed9-4ad9-a7e1-9a0359236096@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <9dkxuF2Tli8rNGcKcHwuNmzbb0zSwUzWR4KfaXBs0eY=.bbde1f02-98fe-49d6-b27b-057b75a5116e@github.com>
 <0q687IquRkiGrlnoNQkNQUvTuLL_CxtgZ7UAW2WG26c=.5172a34c-aed9-4ad9-a7e1-9a0359236096@github.com>
Message-ID: <zry_bjNCTIwhZwd1V6yKR_z1NNbbNb62ZakWt1pPorA=.0e4900a0-9e2f-47cf-a606-2c11e199b659@github.com>

On Tue, 6 May 2025 17:27:09 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java
>>   
>>   Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>
>
> src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 55:
> 
>> 53:         } else {
>> 54:             supported = List.of(new CapturableState("errno", JAVA_INT, 1 << 2));
>> 55:         }
> 
> Maybe just split the initialization of `LAYOUT` and `LOOKUP` across these 2 branches, instead of collecting everything into intermediate arrays. i.e.
> 
> Suggestion:
> 
>         if (OperatingSystem.isWindows()) {
>             LAYOUT = MemoryLayout.structLayout(
>                 JAVA_INT, // GetLastError
>                 JAVA_INT, // WSAGetLastError
>                 JAVA_INT // errno
>             );
>             LOOKUP = Map.of(
>                 "GetLastError", 1 << 0,
>                 "WSAGetLastError", 1 << 1,
>                 "errno", 1 << 2
>             );
>         } else {
>             LAYOUT = MemoryLayout.structLayout(
>                 JAVA_INT // errno
>             );
>             LOOKUP = Map.of(
>                 "errno", 1 << 2
>             );
>         }

Then we can just make `CapturableState` a utility class. Should we proceed in this direction?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2075969405

From almatvee at openjdk.org  Tue May  6 17:47:19 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 6 May 2025 17:47:19 GMT
Subject: RFR: 8356219: jpackage places libapplauncher.so in incorrect
 location in the app image [v2]
In-Reply-To: <2qiByi-Qtb91lGRl1Bv21y6r-kIdsYU3EGMcqRK5qNU=.f138fa2f-e7a1-45cb-8f8e-658df628213c@github.com>
References: <Rwar8nIPy6NFKCIAsW6asYMN_rj9s5LRMg3lQPlTFLg=.b763cd3d-9ff2-4f2f-8a33-2458363a7e93@github.com>
 <2qiByi-Qtb91lGRl1Bv21y6r-kIdsYU3EGMcqRK5qNU=.f138fa2f-e7a1-45cb-8f8e-658df628213c@github.com>
Message-ID: <uCPznkpB01woFQYFhHeBFUNHtcwY4_iHc3ZqO2-b0fY=.87777944-7094-4a22-8475-6d184ae1d6e9@github.com>

On Tue, 6 May 2025 03:25:07 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Refactor PathGroup
>>  - Add test cases to PathGroupTest
>>  - Update UsrTreeTest to verify "libapplauncher.so" is placed in the correct location in the package
>>  - Refactor UsrTreeTest to use JPackageCommand assert functions
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year
>  - Fix a typo in ApplicationLayout

Marked as reviewed by almatvee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25051#pullrequestreview-2819144121

From ihse at openjdk.org  Tue May  6 17:49:14 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 17:49:14 GMT
Subject: RFR: 8356050: Problemlist jdk,
 langtools & lib-test tier1 tests requiring runtime usages of <jdk>/bin/tools
 for static-jdk [v2]
In-Reply-To: <yQbxpPosPX10H2Z1MKSqghOpjQGA8KOa5ig9JEtaIZE=.6311a6af-e786-4309-b72e-d7304f71bd1c@github.com>
References: <lYyYzYPIR2XTf9BvhyjjXqDouhTtIXEobg8d8yrQDD4=.2e61aa4e-d4b8-4f3e-ab58-f5ef3c1465f4@github.com>
 <yQbxpPosPX10H2Z1MKSqghOpjQGA8KOa5ig9JEtaIZE=.6311a6af-e786-4309-b72e-d7304f71bd1c@github.com>
Message-ID: <kamOwEXxIgb6p7gg2-1aoG6-bP5gnr372T3tb24PaAE=.ba5ecab7-0a1f-4af9-aca5-38e097c39eab@github.com>

On Fri, 2 May 2025 17:43:37 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this PR to problemlist jdk & langtools tier1 tests requiring runtime usages of <jdk>/bin/tools, for testing on static-jdk. The affected tests using following tools at runtime:
>> 
>> - javac
>> - javadoc
>> - jar
>> - jarsigner
>> - jcmd
>> - jimage
>> - jps
>> 
>> The latest teir1 testing results on static-jdk: https://github.com/jianglizhou/jdk/actions/runs/14781658116/job/41503569932.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Problemlist jdk/test/lib/hprof/HprofTest.

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24995#pullrequestreview-2819148902

From jiangli at openjdk.org  Tue May  6 17:58:23 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 6 May 2025 17:58:23 GMT
Subject: RFR: 8356050: Problemlist jdk,
 langtools & lib-test tier1 tests requiring runtime usages of <jdk>/bin/tools
 for static-jdk [v2]
In-Reply-To: <kamOwEXxIgb6p7gg2-1aoG6-bP5gnr372T3tb24PaAE=.ba5ecab7-0a1f-4af9-aca5-38e097c39eab@github.com>
References: <lYyYzYPIR2XTf9BvhyjjXqDouhTtIXEobg8d8yrQDD4=.2e61aa4e-d4b8-4f3e-ab58-f5ef3c1465f4@github.com>
 <yQbxpPosPX10H2Z1MKSqghOpjQGA8KOa5ig9JEtaIZE=.6311a6af-e786-4309-b72e-d7304f71bd1c@github.com>
 <kamOwEXxIgb6p7gg2-1aoG6-bP5gnr372T3tb24PaAE=.ba5ecab7-0a1f-4af9-aca5-38e097c39eab@github.com>
Message-ID: <2cX5g5DljTkiJdCTP5YMjjehXOJah9VYInT3jLOiztQ=.0126c189-e8be-45d8-9c74-b66c7ec1af13@github.com>

On Tue, 6 May 2025 17:47:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Problemlist jdk/test/lib/hprof/HprofTest.
>
> Marked as reviewed by ihse (Reviewer).

Thanks for reviewing, @magicus!

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

PR Comment: https://git.openjdk.org/jdk/pull/24995#issuecomment-2855446867

From jiangli at openjdk.org  Tue May  6 17:58:24 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 6 May 2025 17:58:24 GMT
Subject: Integrated: 8356050: Problemlist jdk,
 langtools & lib-test tier1 tests requiring runtime usages of <jdk>/bin/tools
 for static-jdk
In-Reply-To: <lYyYzYPIR2XTf9BvhyjjXqDouhTtIXEobg8d8yrQDD4=.2e61aa4e-d4b8-4f3e-ab58-f5ef3c1465f4@github.com>
References: <lYyYzYPIR2XTf9BvhyjjXqDouhTtIXEobg8d8yrQDD4=.2e61aa4e-d4b8-4f3e-ab58-f5ef3c1465f4@github.com>
Message-ID: <nDPX-oMmf4nFRPg4vqdI9pBvyVScmu2jC9h77w7rQlc=.8f12fc21-3570-4fad-bb4e-a11f5b838958@github.com>

On Fri, 2 May 2025 01:15:05 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR to problemlist jdk & langtools tier1 tests requiring runtime usages of <jdk>/bin/tools, for testing on static-jdk. The affected tests using following tools at runtime:
> 
> - javac
> - javadoc
> - jar
> - jarsigner
> - jcmd
> - jimage
> - jps
> 
> The latest teir1 testing results on static-jdk: https://github.com/jianglizhou/jdk/actions/runs/14781658116/job/41503569932.

This pull request has now been integrated.

Changeset: 064b036e
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/064b036ebd73407ce036d283dbacce44530dbb38
Stats:     45 lines in 3 files changed: 45 ins; 0 del; 0 mod

8356050: Problemlist jdk, langtools & lib-test tier1 tests requiring runtime usages of <jdk>/bin/tools for static-jdk

Reviewed-by: ihse

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

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

From asemenyuk at openjdk.org  Tue May  6 18:00:24 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 6 May 2025 18:00:24 GMT
Subject: Integrated: 8356219: jpackage places libapplauncher.so in incorrect
 location in the app image
In-Reply-To: <Rwar8nIPy6NFKCIAsW6asYMN_rj9s5LRMg3lQPlTFLg=.b763cd3d-9ff2-4f2f-8a33-2458363a7e93@github.com>
References: <Rwar8nIPy6NFKCIAsW6asYMN_rj9s5LRMg3lQPlTFLg=.b763cd3d-9ff2-4f2f-8a33-2458363a7e93@github.com>
Message-ID: <2fLeNTdovq40wT00G2iZG8Q2Ikte8LeFsCKyYZyRR7k=.8948c2a4-6abc-4a55-b212-51dcc5d48269@github.com>

On Mon, 5 May 2025 21:44:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Refactor PathGroup
>  - Add test cases to PathGroupTest
>  - Update UsrTreeTest to verify "libapplauncher.so" is placed in the correct location in the package
>  - Refactor UsrTreeTest to use JPackageCommand assert functions

This pull request has now been integrated.

Changeset: 9c43871f
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9c43871fd15c6fa89f7ad8803c68db7d7a6c09ca
Stats:     822 lines in 8 files changed: 641 ins; 64 del; 117 mod

8356219: jpackage places libapplauncher.so in incorrect location in the app image

Reviewed-by: almatvee

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

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

From ihse at openjdk.org  Tue May  6 18:02:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 18:02:19 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters [v2]
In-Reply-To: <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
 <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>
 <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>
Message-ID: <05oLqW_SUMUc1lusuWCbsJD_BL9g6or613do3-Dwrug=.bfcb16e9-169d-4a61-8b42-61333cceda66@github.com>

On Tue, 6 May 2025 17:15:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base 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 unicode-sequence-in-comments
>>  - 8354968: Replace unicode sequences in comment text with UTF-8 characters
>
> src/java.base/share/classes/java/text/Collator.java line 141:
> 
>> 139:      * considered significant during comparison. The assignment of strengths
>> 140:      * to language features is locale dependent. A common example is for
>> 141:      * different accented forms of the same base letter ("a" vs "?") to be
> 
> Since this (and the other one in RuleBasedCollator) is in the explanation of text handling, I think keeping the original code point makes sense. So I'd have both UTF-8 string and its Unicode escape notation here.

I'm not sure what you mean by "both" here. Do you mean something along the lines of `? (\u00e9, e-acute)` as you suggested below? An additional complication here is that this is part of a javadoc block. I assumed (but must admit that I have not checked) that the `\u00E4` notation will be replaced with unicode characters by Javadoc in the generated html. If so, there should be no difference in the generated javadoc between the original `"\u00E4"` and my suggested patch `"?"`. (There is a change for someone reading the code directly in Collator.java, though).

If I am right, and if you want the generated Javadoc to contain `\u00E4`, I assume you would need to escape the backslash. 

But then again, perhaps I am not correct and javadoc keeps the `\u00E4` as a literal. I'd have to check that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2075997573

From ihse at openjdk.org  Tue May  6 18:03:22 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 18:03:22 GMT
Subject: Integrated: 8354273: Replace even more Unicode characters with ASCII
In-Reply-To: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
References: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
Message-ID: <ozQlBoLORphUUvXLzjs_gDH9cMgvcJVlVzgbt3b6pR0=.df8da50a-67f9-4ee4-b87f-52b49445cefb@github.com>

On Thu, 10 Apr 2025 10:18:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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.

This pull request has now been integrated.

Changeset: 08dd4a75
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08dd4a75c5b751a66d2e088b0ec9c6d6c443c14a
Stats:     11 lines in 8 files changed: 0 ins; 1 del; 10 mod

8354273: Replace even more Unicode characters with ASCII

Reviewed-by: naoto

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

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

From jvernee at openjdk.org  Tue May  6 18:07:30 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 6 May 2025 18:07:30 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v7]
In-Reply-To: <zry_bjNCTIwhZwd1V6yKR_z1NNbbNb62ZakWt1pPorA=.0e4900a0-9e2f-47cf-a606-2c11e199b659@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <9dkxuF2Tli8rNGcKcHwuNmzbb0zSwUzWR4KfaXBs0eY=.bbde1f02-98fe-49d6-b27b-057b75a5116e@github.com>
 <0q687IquRkiGrlnoNQkNQUvTuLL_CxtgZ7UAW2WG26c=.5172a34c-aed9-4ad9-a7e1-9a0359236096@github.com>
 <zry_bjNCTIwhZwd1V6yKR_z1NNbbNb62ZakWt1pPorA=.0e4900a0-9e2f-47cf-a606-2c11e199b659@github.com>
Message-ID: <CiCOcdUF9emCqus4QOJl8CJTO5JGj52PFzKw_2i5eSc=.5e10728d-afec-4ffb-a891-db26771058c6@github.com>

On Tue, 6 May 2025 17:40:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 55:
>> 
>>> 53:         } else {
>>> 54:             supported = List.of(new CapturableState("errno", JAVA_INT, 1 << 2));
>>> 55:         }
>> 
>> Maybe just split the initialization of `LAYOUT` and `LOOKUP` across these 2 branches, instead of collecting everything into intermediate arrays. i.e.
>> 
>> Suggestion:
>> 
>>         if (OperatingSystem.isWindows()) {
>>             LAYOUT = MemoryLayout.structLayout(
>>                 JAVA_INT, // GetLastError
>>                 JAVA_INT, // WSAGetLastError
>>                 JAVA_INT // errno
>>             );
>>             LOOKUP = Map.of(
>>                 "GetLastError", 1 << 0,
>>                 "WSAGetLastError", 1 << 1,
>>                 "errno", 1 << 2
>>             );
>>         } else {
>>             LAYOUT = MemoryLayout.structLayout(
>>                 JAVA_INT // errno
>>             );
>>             LOOKUP = Map.of(
>>                 "errno", 1 << 2
>>             );
>>         }
>
> Then we can just make `CapturableState` a utility class. Should we proceed in this direction?

Yes, that seems fine to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2076005578

From naoto at openjdk.org  Tue May  6 18:09:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 May 2025 18:09:25 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters [v2]
In-Reply-To: <05oLqW_SUMUc1lusuWCbsJD_BL9g6or613do3-Dwrug=.bfcb16e9-169d-4a61-8b42-61333cceda66@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
 <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>
 <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>
 <05oLqW_SUMUc1lusuWCbsJD_BL9g6or613do3-Dwrug=.bfcb16e9-169d-4a61-8b42-61333cceda66@github.com>
Message-ID: <g1nEEI-RAaG_MRVesbDb13DDKf_oe49wObM9oeXSHzM=.864f4b77-66e6-48e2-a021-8348550d23ec@github.com>

On Tue, 6 May 2025 17:59:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/Collator.java line 141:
>> 
>>> 139:      * considered significant during comparison. The assignment of strengths
>>> 140:      * to language features is locale dependent. A common example is for
>>> 141:      * different accented forms of the same base letter ("a" vs "?") to be
>> 
>> Since this (and the other one in RuleBasedCollator) is in the explanation of text handling, I think keeping the original code point makes sense. So I'd have both UTF-8 string and its Unicode escape notation here.
>
> I'm not sure what you mean by "both" here. Do you mean something along the lines of `? (\u00e9, e-acute)` as you suggested below? An additional complication here is that this is part of a javadoc block. I assumed (but must admit that I have not checked) that the `\u00E4` notation will be replaced with unicode characters by Javadoc in the generated html. If so, there should be no difference in the generated javadoc between the original `"\u00E4"` and my suggested patch `"?"`. (There is a change for someone reading the code directly in Collator.java, though).
> 
> If I am right, and if you want the generated Javadoc to contain `\u00E4`, I assume you would need to escape the backslash. 
> 
> But then again, perhaps I am not correct and javadoc keeps the `\u00E4` as a literal. I'd have to check that.

Yes, I meant literally `\u00e9` or `\u00E4`, but I think it is better described as `U+00E9` emphasizing the code point. So in this case, I'd suggest

"a" vs "?" (U+00E9)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2076008258

From henryjen at openjdk.org  Tue May  6 18:09:45 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 6 May 2025 18:09:45 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v5]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <4WWeeFJ0bxH4U1XfnLXi2wmekdo6rRRPzegDLnePGPc=.813a8ecc-f500-462a-a865-ca5d632e8423@github.com>

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

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Validation entry name, also output the count of duplicates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/e38774af..24d0776d

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

  Stats: 229 lines in 3 files changed: 151 ins; 45 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/24430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430

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

From henryjen at openjdk.org  Tue May  6 18:21:30 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 6 May 2025 18:21:30 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v6]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <Uvb8haTDHaSUlFccwMonvOOpnMogpbjr2KpffroxpmQ=.0e863939-4729-4ab6-9d67-f276570e9084@github.com>

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

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Restore Validator access level

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/24d0776d..e0eff6ef

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

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

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

From jlu at openjdk.org  Tue May  6 18:30:18 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 6 May 2025 18:30:18 GMT
Subject: RFR: 8356096: ISO 4217 Amendment 179 Update
In-Reply-To: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>
References: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>
Message-ID: <GYgygbtYt8IzxZ3zeYidNd8LjZaIv_D08fbesCTlOp0=.3d74dbe3-5e45-4c25-87fb-e6de2f0a5afe@github.com>

On Fri, 2 May 2025 20:51:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which implements ISO 4217 update 179.
> 
> The _Arab Accounting Dinar_ currency is added under an _agency_, (not _country_) entity. As a result it is not added as an entry in the country to currency mapping in `currencyData.properties`. It has a numeric code of 396, and minor units of 2 (so it is not added to any of the `minorX` entries in `currencyData.properties`).

Thanks for reviewing.

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

PR Comment: https://git.openjdk.org/jdk/pull/25014#issuecomment-2855531302

From jlu at openjdk.org  Tue May  6 18:30:19 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 6 May 2025 18:30:19 GMT
Subject: Integrated: 8356096: ISO 4217 Amendment 179 Update
In-Reply-To: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>
References: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>
Message-ID: <iQRC1oOGdik853F2QycpQ2Kdi047Zbd80ley1eds_C4=.df6b00ed-25a5-4ba7-ab01-6e639fb22628@github.com>

On Fri, 2 May 2025 20:51:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which implements ISO 4217 update 179.
> 
> The _Arab Accounting Dinar_ currency is added under an _agency_, (not _country_) entity. As a result it is not added as an entry in the country to currency mapping in `currencyData.properties`. It has a numeric code of 396, and minor units of 2 (so it is not added to any of the `minorX` entries in `currencyData.properties`).

This pull request has now been integrated.

Changeset: 0cb355ee
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0cb355ee921183423c8ffc44491f428c49c62c28
Stats:     11 lines in 4 files changed: 2 ins; 0 del; 9 mod

8356096: ISO 4217 Amendment 179 Update

Reviewed-by: naoto, iris

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

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

From bchristi at openjdk.org  Tue May  6 18:43:19 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 6 May 2025 18:43:19 GMT
Subject: Integrated: 8298783: java/lang/ref/FinalizerHistogramTest.java failed
 with "RuntimeException: MyObject is not found in test output"
In-Reply-To: <Jcra20HpK4hJAr6O1VySmMukJHFGYEieEpvDVrlbxuI=.03ee416c-3568-4a66-be60-f6c17fed2188@github.com>
References: <Jcra20HpK4hJAr6O1VySmMukJHFGYEieEpvDVrlbxuI=.03ee416c-3568-4a66-be60-f6c17fed2188@github.com>
Message-ID: <egPNLxbEJ--ts0-kC8ASuEgxrNQZRQ4TkZ1OSIp31zI=.3f605ae7-0b4f-4bda-b7a2-15e165153742@github.com>

On Thu, 20 Mar 2025 22:35:23 GMT, Brent Christian <bchristi at openjdk.org> 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.

This pull request has now been integrated.

Changeset: fe29cad5
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fe29cad5e0b10cd088fc39967599f5a8dcaa445c
Stats:     28 lines in 1 file changed: 14 ins; 1 del; 13 mod

8298783: java/lang/ref/FinalizerHistogramTest.java failed with "RuntimeException: MyObject is not found in test output"

Reviewed-by: kbarrett, jpai

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

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

From liach at openjdk.org  Tue May  6 20:07:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 20:07:56 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v8]
In-Reply-To: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
Message-ID: <ICaMR5QoL7FQHz7e2hhjA1UTwR9gccq8w3nI9Ixqo1s=.b60d3784-d9b9-474c-b556-e80e213db398@github.com>

> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
> 
> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
> 
> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
> 
> Testing: jdk/lang/foreign, tier 1-3 in progress.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Simplify to utility class
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states
 - Update src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java
   
   Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states
 - rollback OS
 - Review remarks
 - No env to test
   
 - Unchecked
   
 - Further revamp, remove unnecessary instances on irrelevant platforms
   
 - ... and 2 more: https://git.openjdk.org/jdk/compare/83a1ad55...0f495539

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25025/files
  - new: https://git.openjdk.org/jdk/pull/25025/files/450ea115..0f495539

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=06-07

  Stats: 8346 lines in 139 files changed: 4543 ins; 2476 del; 1327 mod
  Patch: https://git.openjdk.org/jdk/pull/25025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25025/head:pull/25025

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

From bpb at openjdk.org  Tue May  6 20:14:05 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 6 May 2025 20:14:05 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v13]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <EY-hJf2eWdC0OKZlwdSbYK3McMx9nH12m8jfGfXGYKc=.5969f5c1-6eca-451f-aa20-4f1065260a9f@github.com>

> 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 13 commits:

 - Merge
 - 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
 - ... and 3 more: https://git.openjdk.org/jdk/compare/9477c422...da21fa69

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

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=12
  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 duke at openjdk.org  Tue May  6 20:32:17 2025
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 May 2025 20:32:17 GMT
Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2]
In-Reply-To: <OQFS9tEyTK4cXqq9upD-EH8-B3H_LB0nfBAHkW-daXk=.fd5763c2-a86d-4b0b-9857-c8a70542ad31@github.com>
References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
 <OQFS9tEyTK4cXqq9upD-EH8-B3H_LB0nfBAHkW-daXk=.fd5763c2-a86d-4b0b-9857-c8a70542ad31@github.com>
Message-ID: <KguwWll6vXUa1kWxR6FE6A9Par1NWtSu21voplUnbQU=.ac51c0a8-3565-4e4c-8d9f-3d266db74567@github.com>

On Sun, 4 May 2025 16:21:41 GMT, Markus KARG <duke at openjdk.org> 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`.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Undone copyright update of otherwise unchanged file.
>  - Update Of.java
>    
>    Applied changnes proposed by @liach: "the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise."

> There is some wording around this topic in the guide already: _In order to prepare the community for your patch, please socialize your idea on the relevant [mailing lists](https://openjdk.org/guide/#mailing-lists). Almost all changes, and in particular any API changes, must go this route and have a broad agreement in place before there is any point in presenting code._
> 
> I've added the suggested text to clarify this paragraph: [openjdk/guide#150](https://github.com/openjdk/guide/pull/150)

Then I can literally stop working on OpenJDK rather immediately, as people never find enough time for **"broad"** agreement. At least they didn't in the past **years**.

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

PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2855892549

From asemenyuk at openjdk.org  Tue May  6 20:38:23 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 6 May 2025 20:38:23 GMT
Subject: RFR: 8356309: Fix issues uncovered after running jpackage tests
 locally with installing test packages
In-Reply-To: <oXb2RJob38i58VDh6ojqb0mxBLgfvY7DTBCf5HF0q8A=.8d7d3de4-bd9d-4891-9d06-ea9be8e24fe6@github.com>
References: <oXb2RJob38i58VDh6ojqb0mxBLgfvY7DTBCf5HF0q8A=.8d7d3de4-bd9d-4891-9d06-ea9be8e24fe6@github.com>
Message-ID: <DAA5gcJttTCQroFgRTxG3Vrt3L1W_tNUq2UzWqiLspQ=.8b62bef1-44dd-42d6-b009-48a61786eac2@github.com>

On Fri, 25 Apr 2025 18:07:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix issues uncovered in the tests after local test runs with the installation of test packages:
>  - LinuxHelper: fix a regression from [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988). Before the [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988) fix, when a process started with Executor didn't write to stdout, `Executor.executeAndGetFirstLineOfOutput()` returned an empty string; after the fix, it throws an exception.
>  - Fix EmptyFolderTest: when an MSI is installed, it can create empty directories. Empty directories are not created only when it is unpacked. We probably never ran EmptyFolderTest in "install test packages" mode; we always executed it in "unpack test packages" mode.
>  -  Fix `PackageTest.Group` to make it work correctly when a test runs jpackage to produce both exe and msi packages, and when they are installed.
>  
> Before the fix, the sequence was:
> 
> for (action in {create, install, uninstall}) {
>   for (test in tests) {
>     for (type in {exe, msi}) {
>       run $action on $test of $type
>     }
>   }
> }
> 
> 
> After the fix, the sequence is:
> 
> for (type in {exe, msi}) {
>   for (action in {create, install, uninstall}) {
>     for (test in tests) {
>       run $action on $test of $type
>     }
>   }
> }
> 
> 
> Additionally:
>  - Add missing `@Test` annotation to PathGroupTest.testNullId() test case;
>  - Fix typo in PListReaderTest: STRING_ARRY -> STRING_ARR**A**Y;
>  - Optimize RuntimeImageTest to not run jlink if external Java runtime is supplied;
>  - Add a test to RuntimeImageTest to verify jpackage strips the "jmod" directory and the "src.zip" file from an external runtime image

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/24884#issuecomment-2855904552

From asemenyuk at openjdk.org  Tue May  6 20:38:23 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 6 May 2025 20:38:23 GMT
Subject: RFR: 8356309: Fix issues uncovered after running jpackage tests
 locally with installing test packages
Message-ID: <oXb2RJob38i58VDh6ojqb0mxBLgfvY7DTBCf5HF0q8A=.8d7d3de4-bd9d-4891-9d06-ea9be8e24fe6@github.com>

Fix issues uncovered in the tests after local test runs with the installation of test packages:
 - LinuxHelper: fix a regression from [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988). Before the [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988) fix, when a process started with Executor didn't write to stdout, `Executor.executeAndGetFirstLineOfOutput()` returned an empty string; after the fix, it throws an exception.
 - Fix EmptyFolderTest: when an MSI is installed, it can create empty directories. Empty directories are not created only when it is unpacked. We probably never ran EmptyFolderTest in "install test packages" mode; we always executed it in "unpack test packages" mode.
 -  Fix `PackageTest.Group` to make it work correctly when a test runs jpackage to produce both exe and msi packages, and when they are installed.
 
Before the fix, the sequence was:

for (action in {create, install, uninstall}) {
  for (test in tests) {
    for (type in {exe, msi}) {
      run $action on $test of $type
    }
  }
}


After the fix, the sequence is:

for (type in {exe, msi}) {
  for (action in {create, install, uninstall}) {
    for (test in tests) {
      run $action on $test of $type
    }
  }
}


Additionally:
 - Add missing `@Test` annotation to PathGroupTest.testNullId() test case;
 - Fix typo in PListReaderTest: STRING_ARRY -> STRING_ARR**A**Y;
 - Optimize RuntimeImageTest to not run jlink if external Java runtime is supplied;
 - Add a test to RuntimeImageTest to verify jpackage strips the "jmod" directory and the "src.zip" file from an external runtime image

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

Commit messages:
 - Merge branch 'master' into local-test-followup
 - Bugfix RuntimePackageTest
 - Bugfix
 - Better test coverage
 - Add RuntimeImageTest.testStrippedFiles() test to verify jmods and src.zip files are stripped from copied runtime
 - Improve RuntimeImageTest
 - Add missing @Test annotation
 - Fix typo
 - EmptyFolderTest: bugfix
 - PackageTest: fix to make it work when exe and msi packagings are both enabled and when PackageTest.Group is used
 - ... and 5 more: https://git.openjdk.org/jdk/compare/0cb355ee...9649c077

Changes: https://git.openjdk.org/jdk/pull/24884/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24884&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356309
  Stats: 107 lines in 7 files changed: 49 ins; 6 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/24884.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24884/head:pull/24884

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

From duke at openjdk.org  Tue May  6 20:52:34 2025
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 May 2025 20:52:34 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v12]
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>

> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
> 
> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
> 
> To ensure quality...
> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - merge latest from master branch
 - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted?
 - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs
 - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since.
 - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.'
 - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars()
 - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()
 - 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)'
 - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted?
 - Applied changes requested by Alan: Copies chars from this sequence into the given destination array
 - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a

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

Changes: https://git.openjdk.org/jdk/pull/21730/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=11
  Stats: 470 lines in 8 files changed: 399 ins; 59 del; 12 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  Tue May  6 20:54:17 2025
From: duke at openjdk.org (Markus KARG)
Date: Tue, 6 May 2025 20:54:17 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v11]
In-Reply-To: <ElaSulVLeJ_WM0ZsWa1S2ZlOR9LCc8DYQ3c3gibUlpo=.27648334-e818-4b65-b68d-708b28593f2c@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <bY6wxELBjJnRQ5co73NgJC5baGtnY5UKezuQXCvYU5E=.82004266-7468-484d-a28c-85852d06f8d9@github.com>
 <PBiSYA5aqDEnMIqV_0e7cvAbmc6YmO78SqKDx168qsU=.2b4c3790-b3c6-4ce3-a916-36a5e4c402a4@github.com>
 <ElaSulVLeJ_WM0ZsWa1S2ZlOR9LCc8DYQ3c3gibUlpo=.27648334-e818-4b65-b68d-708b28593f2c@github.com>
Message-ID: <NE3r07WsiM4gvKfWw39QZkeC-qAhvbhFlEJgco5y4P4=.2a55a2f4-247b-40fd-9b1f-259cd1d6a639@github.com>

On Tue, 6 May 2025 11:23:01 GMT, Markus KARG <duke at openjdk.org> wrote:

> Hello Markus, it's been a while since this PR was merged with latest master branch in mainline. Could you update the PR to do that?

Updated to current `master`. Builds fine locally. Pushed to Github. Github Actions currently are running.

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

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

From duke at openjdk.org  Tue May  6 21:45:34 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Tue, 6 May 2025 21:45:34 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v3]
In-Reply-To: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
Message-ID: <H3vvJxVRsOzXpLIAnz2vc3wU_Umd9IoyI1cgqYT6mq0=.79b289da-60f2-4f62-99bd-227e03e9df2b@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm.
> 
> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version.
> 
> For performance data collected with the built in **cbrt** micro-benchmark, see the table below. Each result is the mean of 8 individual runs. Overall, the intrinsic provides a performance uplift of 37%.
> 
> | Benchmark        | Throughput with baseline (op/s) | Throughput with intrinsic (op/s) | Speedup |
> | :----------------: | :----------------------------------: | :----------------------------------: | :---------: |
> | MathBench.cbrt | 152465                                        | 208537                                        | 1.37x       |
> 
> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.

Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:

  Add new set of cbrt micro-benchmarks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24470/files
  - new: https://git.openjdk.org/jdk/pull/24470/files/3212c669..57412f0d

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

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

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

From jvernee at openjdk.org  Tue May  6 21:49:19 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 6 May 2025 21:49:19 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v8]
In-Reply-To: <ICaMR5QoL7FQHz7e2hhjA1UTwR9gccq8w3nI9Ixqo1s=.b60d3784-d9b9-474c-b556-e80e213db398@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <ICaMR5QoL7FQHz7e2hhjA1UTwR9gccq8w3nI9Ixqo1s=.b60d3784-d9b9-474c-b556-e80e213db398@github.com>
Message-ID: <KJWxe8IQB6_9_xoW7AInjSzq52E0cAvsvjrfzgA0fdc=.e00418c2-2195-4330-92fa-e4ec7a97740e@github.com>

On Tue, 6 May 2025 20:07:56 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
>> 
>> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
>> 
>> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
>> 
>> Testing: jdk/lang/foreign, tier 1-3 in progress.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Simplify to utility class
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states
>  - Update src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java
>    
>    Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states
>  - rollback OS
>  - Review remarks
>  - No env to test
>    
>  - Unchecked
>    
>  - Further revamp, remove unnecessary instances on irrelevant platforms
>    
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/479659a2...0f495539

Changes look good

src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 62:

> 60:                     "errno",           1 << 2
> 61:             );
> 62:         }

Pre-existing, but while you're here, could you add a comment stating that the mask values have to be kept in sync with the value in `DowncallLinker::capture_state` in `src/hotspot/share/prims/downcallLinker.cpp`? (See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/downcallLinker.cpp#L36)

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25025#pullrequestreview-2819760597
PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2076367601

From jwilhelm at openjdk.org  Tue May  6 21:57:15 2025
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 6 May 2025 21:57:15 GMT
Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2]
In-Reply-To: <OQFS9tEyTK4cXqq9upD-EH8-B3H_LB0nfBAHkW-daXk=.fd5763c2-a86d-4b0b-9857-c8a70542ad31@github.com>
References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
 <OQFS9tEyTK4cXqq9upD-EH8-B3H_LB0nfBAHkW-daXk=.fd5763c2-a86d-4b0b-9857-c8a70542ad31@github.com>
Message-ID: <KSLx3-ce2qLb74qQKBquuJqWRxYk0bAW2o3SJxrgvM0=.d96e1a7a-23e5-4d29-8657-1e08084dcb86@github.com>

On Sun, 4 May 2025 16:21:41 GMT, Markus KARG <duke at openjdk.org> 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`.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Undone copyright update of otherwise unchanged file.
>  - Update Of.java
>    
>    Applied changnes proposed by @liach: "the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise."

We must remember that the OpenJDK community is built by individuals with different backgrounds and motivations to engaging. Some people get paid to work on OpenJDK development, others do it in their own time. It would be next to impossible to dictate any kinds of rules to enforce engagement from reviewers as this would require companies and individuals to commit to prioritizing issues that may not be in their interest to spend time on.

Any kind of "if you engage in a discussion you must reply within X weeks" will most likely only result in less people engaging in the first place.

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

PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2856187951

From liach at openjdk.org  Tue May  6 22:11:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 22:11:49 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v9]
In-Reply-To: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
Message-ID: <9gn1nMQxoXSqk7Hpa1luMl8fAQdRJcdqm7s9YpZaGCw=.300a6c90-a049-42d0-95c2-d2279c8dca38@github.com>

> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
> 
> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
> 
> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
> 
> Testing: jdk/lang/foreign, tier 1-3 in progress.

Chen Liang has updated the pull request incrementally with two additional commits since the last revision:

 - Indicate source file
 - Keep in sync comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25025/files
  - new: https://git.openjdk.org/jdk/pull/25025/files/0f495539..5986dbff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25025&range=07-08

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

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

From liach at openjdk.org  Tue May  6 22:11:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 22:11:50 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v8]
In-Reply-To: <KJWxe8IQB6_9_xoW7AInjSzq52E0cAvsvjrfzgA0fdc=.e00418c2-2195-4330-92fa-e4ec7a97740e@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <ICaMR5QoL7FQHz7e2hhjA1UTwR9gccq8w3nI9Ixqo1s=.b60d3784-d9b9-474c-b556-e80e213db398@github.com>
 <KJWxe8IQB6_9_xoW7AInjSzq52E0cAvsvjrfzgA0fdc=.e00418c2-2195-4330-92fa-e4ec7a97740e@github.com>
Message-ID: <4EuA5Ih76U-5w5ifFq9G1nP4VAhGbuB9myNYpXkCFwc=.f275bd06-2625-41f9-aab5-288c75ed1f20@github.com>

On Tue, 6 May 2025 21:45:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - Simplify to utility class
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states
>>  - Update src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java
>>    
>>    Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/ffm-opt-capture-states
>>  - rollback OS
>>  - Review remarks
>>  - No env to test
>>    
>>  - Unchecked
>>    
>>  - Further revamp, remove unnecessary instances on irrelevant platforms
>>    
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/e1e77797...0f495539
>
> src/java.base/share/classes/jdk/internal/foreign/abi/CapturableState.java line 62:
> 
>> 60:                     "errno",           1 << 2
>> 61:             );
>> 62:         }
> 
> Pre-existing, but while you're here, could you add a comment stating that the mask values have to be kept in sync with the value in `DowncallLinker::capture_state` in `src/hotspot/share/prims/downcallLinker.cpp`? (See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/downcallLinker.cpp#L36)

Done. Added in the MASKS field declaration. Also updated the outdated class name reference in downcallLinker.cpp. (Missed c++ file name in first push, c++ file name is not that easy to discover)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2076415819

From jvernee at openjdk.org  Tue May  6 22:21:16 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 6 May 2025 22:21:16 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v9]
In-Reply-To: <9gn1nMQxoXSqk7Hpa1luMl8fAQdRJcdqm7s9YpZaGCw=.300a6c90-a049-42d0-95c2-d2279c8dca38@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <9gn1nMQxoXSqk7Hpa1luMl8fAQdRJcdqm7s9YpZaGCw=.300a6c90-a049-42d0-95c2-d2279c8dca38@github.com>
Message-ID: <607rDUECdLHyT6YOhm3fMX6axgaBt81JF_cjePq0Qbg=.54d73522-7410-4811-9b8d-be78da9b272b@github.com>

On Tue, 6 May 2025 22:11:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
>> 
>> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
>> 
>> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
>> 
>> Testing: jdk/lang/foreign, tier 1-3 in progress.
>
> Chen Liang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Indicate source file
>  - Keep in sync comments

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25025#pullrequestreview-2819834200

From liach at openjdk.org  Tue May  6 22:21:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 22:21:16 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v9]
In-Reply-To: <9gn1nMQxoXSqk7Hpa1luMl8fAQdRJcdqm7s9YpZaGCw=.300a6c90-a049-42d0-95c2-d2279c8dca38@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <9gn1nMQxoXSqk7Hpa1luMl8fAQdRJcdqm7s9YpZaGCw=.300a6c90-a049-42d0-95c2-d2279c8dca38@github.com>
Message-ID: <FY4zI-BbiOtn7Vomeux-b9io_q8xEYE4VFwipmlYCH8=.4d245eec-a9a7-4246-8e18-76cc8e731fe0@github.com>

On Tue, 6 May 2025 22:11:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
>> 
>> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
>> 
>> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
>> 
>> Testing: jdk/lang/foreign, tier 1-3 in progress.
>
> Chen Liang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Indicate source file
>  - Keep in sync comments

Thanks for the review! Tier 1-3 tests all pass. Will wait for people to check out this utility class version.

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

PR Comment: https://git.openjdk.org/jdk/pull/25025#issuecomment-2856250459

From bchristi at openjdk.org  Tue May  6 22:51:16 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 6 May 2025 22:51:16 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v6]
In-Reply-To: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com>
Message-ID: <JdHwmQWclg-ORFOoe04W5Qcm0r59brBd8OsKqclRZWA=.085589a0-846b-48ee-8e1e-eae465952afb@github.com>

On Tue, 6 May 2025 15:23:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply reviewer suggestions for typos, javadoc, and copyright dates.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1972:

> 1970:      * @param s a char array
> 1971:      * @param off the offset of the first character to append
> 1972:      * @param end end last (exclusive) character to append

It might be helpful to somehow clarify that, in the case of appending Latin1 characters to a Latin1 buffer, it is expected/required that `value` is already of sufficient size.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2076467887

From liach at openjdk.org  Tue May  6 22:57:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 22:57:15 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v6]
In-Reply-To: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com>
Message-ID: <pvRO0pa8yXucxsNl9Fo5Tz2MbiK-v3qLqcXQcwGr0dM=.6de1e943-a440-4b73-936b-6346a54478a8@github.com>

On Tue, 6 May 2025 15:23:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply reviewer suggestions for typos, javadoc, and copyright dates.

Some of the new methods in ASB are still unsafe; I need to spend more time to verify each of their use cases.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 270:

> 268:     private static byte[] ensureCapacityNewCoder(byte[] value, byte coder, int count,
> 269:                                                  int minimumCapacity, byte newCoder) {
> 270:         assert coder == newCoder || newCoder == UTF16 : "bad new coder UTF16 -> LATIN1";

I recommend an additional assertion `count <= minimumCapacity`; even though all callers ensure this currently, in case this is accidentally violated, we are sending dangerous arguments to `StringLatin1.inflate`.

Also, the message string of assertion can include the `coder` and `newCoder` values. Same for the other assertions we add.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 321:

> 319:      */
> 320:     private static byte[] inflateToUTF16(byte[] value, int count) {
> 321:         byte[] newValue = StringUTF16.newBytesFor(value.length);

Same value.length vs count assertion recommendation

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

PR Review: https://git.openjdk.org/jdk/pull/24967#pullrequestreview-2818880544
PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075825884
PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2075827576

From bchristi at openjdk.org  Tue May  6 22:57:15 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 6 May 2025 22:57:15 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v6]
In-Reply-To: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com>
Message-ID: <vvDjVYOunV-hx_p07NhaAzi-unUm6461LXWHpaECHXs=.d6d2665d-dce1-4e6b-9adf-3fc100837a5e@github.com>

On Tue, 6 May 2025 15:23:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply reviewer suggestions for typos, javadoc, and copyright dates.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 2006:

> 2004:      * @param s a string
> 2005:      * @param off the offset of the first character to append
> 2006:      * @param end end last (exclusive) character to append

It might be helpful to somehow clarify that, in the case of appending Latin1 characters to a Latin1 buffer, it is expected/required that `value` is already of sufficient size.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2076470416

From bchristi at openjdk.org  Tue May  6 23:00:16 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 6 May 2025 23:00:16 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v6]
In-Reply-To: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com>
Message-ID: <QThgSHrjkAHpEjAyGXUAssciQKn413RjiKFbzp0Czpg=.7a1a0ef0-933a-481b-bb22-3c3afe38c1cc@github.com>

On Tue, 6 May 2025 15:23:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply reviewer suggestions for typos, javadoc, and copyright dates.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 2044:

> 2042:      * @param s a string
> 2043:      * @param off the offset of the first character to append
> 2044:      * @param end end last (exclusive) character to append

It might be helpful to somehow clarify that, in the case of appending Latin1 characters to a Latin1 buffer, it is expected/required that `value` is already of sufficient size.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2076475596

From almatvee at openjdk.org  Tue May  6 23:32:13 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 6 May 2025 23:32:13 GMT
Subject: RFR: 8356309: Fix issues uncovered after running jpackage tests
 locally with installing test packages
In-Reply-To: <oXb2RJob38i58VDh6ojqb0mxBLgfvY7DTBCf5HF0q8A=.8d7d3de4-bd9d-4891-9d06-ea9be8e24fe6@github.com>
References: <oXb2RJob38i58VDh6ojqb0mxBLgfvY7DTBCf5HF0q8A=.8d7d3de4-bd9d-4891-9d06-ea9be8e24fe6@github.com>
Message-ID: <5htRvtHPwxIcBJByLPGox9myjjcoFmcwryVAVgp_C00=.17353db5-8120-4217-843f-5e5195271fdc@github.com>

On Fri, 25 Apr 2025 18:07:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix issues uncovered in the tests after local test runs with the installation of test packages:
>  - LinuxHelper: fix a regression from [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988). Before the [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988) fix, when a process started with Executor didn't write to stdout, `Executor.executeAndGetFirstLineOfOutput()` returned an empty string; after the fix, it throws an exception.
>  - Fix EmptyFolderTest: when an MSI is installed, it can create empty directories. Empty directories are not created only when it is unpacked. We probably never ran EmptyFolderTest in "install test packages" mode; we always executed it in "unpack test packages" mode.
>  -  Fix `PackageTest.Group` to make it work correctly when a test runs jpackage to produce both exe and msi packages, and when they are installed.
>  
> Before the fix, the sequence was:
> 
> for (action in {create, install, uninstall}) {
>   for (test in tests) {
>     for (type in {exe, msi}) {
>       run $action on $test of $type
>     }
>   }
> }
> 
> 
> After the fix, the sequence is:
> 
> for (type in {exe, msi}) {
>   for (action in {create, install, uninstall}) {
>     for (test in tests) {
>       run $action on $test of $type
>     }
>   }
> }
> 
> 
> Additionally:
>  - Add missing `@Test` annotation to PathGroupTest.testNullId() test case;
>  - Fix typo in PListReaderTest: STRING_ARRY -> STRING_ARR**A**Y;
>  - Optimize RuntimeImageTest to not run jlink if external Java runtime is supplied;
>  - Add a test to RuntimeImageTest to verify jpackage strips the "jmod" directory and the "src.zip" file from an external runtime image

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24884#pullrequestreview-2819970329

From asemenyuk at openjdk.org  Tue May  6 23:43:17 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 6 May 2025 23:43:17 GMT
Subject: Integrated: 8356309: Fix issues uncovered after running jpackage tests
 locally with installing test packages
In-Reply-To: <oXb2RJob38i58VDh6ojqb0mxBLgfvY7DTBCf5HF0q8A=.8d7d3de4-bd9d-4891-9d06-ea9be8e24fe6@github.com>
References: <oXb2RJob38i58VDh6ojqb0mxBLgfvY7DTBCf5HF0q8A=.8d7d3de4-bd9d-4891-9d06-ea9be8e24fe6@github.com>
Message-ID: <9l8S-Efdjbhvz43_6Povp0ltYoEeT84TYHBkj0OVE7A=.526b1333-219e-4eab-a702-f3dac98a6f58@github.com>

On Fri, 25 Apr 2025 18:07:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix issues uncovered in the tests after local test runs with the installation of test packages:
>  - LinuxHelper: fix a regression from [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988). Before the [JDK-8354988](https://bugs.openjdk.org/browse/JDK-8354988) fix, when a process started with Executor didn't write to stdout, `Executor.executeAndGetFirstLineOfOutput()` returned an empty string; after the fix, it throws an exception.
>  - Fix EmptyFolderTest: when an MSI is installed, it can create empty directories. Empty directories are not created only when it is unpacked. We probably never ran EmptyFolderTest in "install test packages" mode; we always executed it in "unpack test packages" mode.
>  -  Fix `PackageTest.Group` to make it work correctly when a test runs jpackage to produce both exe and msi packages, and when they are installed.
>  
> Before the fix, the sequence was:
> 
> for (action in {create, install, uninstall}) {
>   for (test in tests) {
>     for (type in {exe, msi}) {
>       run $action on $test of $type
>     }
>   }
> }
> 
> 
> After the fix, the sequence is:
> 
> for (type in {exe, msi}) {
>   for (action in {create, install, uninstall}) {
>     for (test in tests) {
>       run $action on $test of $type
>     }
>   }
> }
> 
> 
> Additionally:
>  - Add missing `@Test` annotation to PathGroupTest.testNullId() test case;
>  - Fix typo in PListReaderTest: STRING_ARRY -> STRING_ARR**A**Y;
>  - Optimize RuntimeImageTest to not run jlink if external Java runtime is supplied;
>  - Add a test to RuntimeImageTest to verify jpackage strips the "jmod" directory and the "src.zip" file from an external runtime image

This pull request has now been integrated.

Changeset: cbbab07d
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cbbab07d232ff7d46f91b2df4e1b0ef4f37bba95
Stats:     107 lines in 7 files changed: 49 ins; 6 del; 52 mod

8356309: Fix issues uncovered after running jpackage tests locally with installing test packages

Reviewed-by: almatvee

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

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

From duke at openjdk.org  Wed May  7 01:14:16 2025
From: duke at openjdk.org (Daishi Tabata)
Date: Wed, 7 May 2025 01:14:16 GMT
Subject: RFR: 8355249: Remove the use of WMIC from the entire source code
 [v2]
In-Reply-To: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
References: <blL6FOj7XD1T3u_ODIwYPIPDXEowzSR0w5j92nC9gCo=.8a2428d9-1795-4dd0-91fd-8b604c7cc100@github.com>
 <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
Message-ID: <_DiRDJt8fWIUVE67JZBz77VD8I1ubbynjOkrjnX7jhU=.b6a7ef16-a1fb-447d-838c-b74b49157561@github.com>

On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata <duke at openjdk.org> wrote:

>> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI.
>> 
>> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency.
>> 
>> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file.
>> Note: In my environment, it worked correctly even without these options.
>> 
>> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in:
>> 
>> - `environment.html`: `windows/system/os` section
>> - `process.html`: `[Process ID]/windows/native/info` section
>> 
>> **Testing:**
>> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes.
>
> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   run jcheck

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24791#issuecomment-2856733631

From duke at openjdk.org  Wed May  7 01:14:17 2025
From: duke at openjdk.org (duke)
Date: Wed, 7 May 2025 01:14:17 GMT
Subject: RFR: 8355249: Remove the use of WMIC from the entire source code
 [v2]
In-Reply-To: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
References: <blL6FOj7XD1T3u_ODIwYPIPDXEowzSR0w5j92nC9gCo=.8a2428d9-1795-4dd0-91fd-8b604c7cc100@github.com>
 <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
Message-ID: <XJT_nntyDb4nK-BtHFjPDrpgFPaZjsa1M5lKn_n2skk=.64ecb990-d5f0-4074-a6ad-20783f56d33d@github.com>

On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata <duke at openjdk.org> wrote:

>> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI.
>> 
>> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency.
>> 
>> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file.
>> Note: In my environment, it worked correctly even without these options.
>> 
>> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in:
>> 
>> - `environment.html`: `windows/system/os` section
>> - `process.html`: `[Process ID]/windows/native/info` section
>> 
>> **Testing:**
>> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes.
>
> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   run jcheck

@tabata-d 
Your change (at version 76a3a7ee1f3f266795c88dd35e03205d7a8234aa) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24791#issuecomment-2856734732

From almatvee at openjdk.org  Wed May  7 01:34:13 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 7 May 2025 01:34:13 GMT
Subject: RFR: 8352480: Don't follow symlinks in additional content for app
 images [v2]
In-Reply-To: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
References: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
Message-ID: <JKSq7zes6_VlV45NkYKKDcvUkExp8w3rg0CZdkRzOHM=.afff8fbd-dde9-4019-88ec-63779ead42fb@github.com>

> - Symbolic links will not be followed for `--app-content` on all platforms.
> - Added test to cover this case.
> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links.

Alexander Matveev has updated the pull request with a new target base 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 remote-tracking branch 'upstream/master' into JDK-8352480
 - 8352480: [macos] Don't follow symlinks in additional content for app images [v4]
 - 8352480: [macos] Don't follow symlinks in additional content for app images [v3]
 - 8352480: [macos] Don't follow symlinks in additional content for app images [v2]
 - 8352480: [macos] Don't follow symlinks in additional content for app images

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24974/files
  - new: https://git.openjdk.org/jdk/pull/24974/files/004304ed..519be97e

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

  Stats: 30202 lines in 804 files changed: 21331 ins; 5103 del; 3768 mod
  Patch: https://git.openjdk.org/jdk/pull/24974.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24974/head:pull/24974

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

From almatvee at openjdk.org  Wed May  7 01:34:13 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 7 May 2025 01:34:13 GMT
Subject: RFR: 8352480: Don't follow symlinks in additional content for app
 images
In-Reply-To: <Eiw-F2s72o7_to0gJ-uTEvLxoWsm6xV_TYKKsvv89ic=.7a29497b-f428-4d0c-a21f-617c87e1acd3@github.com>
References: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
 <Eiw-F2s72o7_to0gJ-uTEvLxoWsm6xV_TYKKsvv89ic=.7a29497b-f428-4d0c-a21f-617c87e1acd3@github.com>
Message-ID: <E--NsnjXhhCOHfCm-v3-wwiWt_VXtN4-L3k97O1r2pE=.e1fd64ec-4a99-486c-a33e-da94abbac7f1@github.com>

On Wed, 30 Apr 2025 20:56:19 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> I don't like the idea of changing behavior on only one platform. It should be consistent across all platforms. Let's not follow symlinks on other platforms, either.

Fix is updated not to follow links on all platforms. Test is updated as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/24974#issuecomment-2856762373

From yyang at openjdk.org  Wed May  7 01:43:18 2025
From: yyang at openjdk.org (Yi Yang)
Date: Wed, 7 May 2025 01:43:18 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <TDmCfGJjSU6S6OtslOdj06Mx2-15BuufvsalEcQWt7Q=.df27883d-e6f4-48e5-82ed-9ad2be53340e@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
 <L61KEZBpl0QV70RZVdSL3fo8R_sAE5WFC5BYK7R4_dg=.0d304f25-bc33-4f66-8f2e-85cda92cb8d4@github.com>
 <j0CHZTYVTsJKo4n5PTtDk23ZVbrwiELWAL9qOrX95GE=.fe1d18fe-c312-47c7-82b6-f6d1780024cc@github.com>
 <TDmCfGJjSU6S6OtslOdj06Mx2-15BuufvsalEcQWt7Q=.df27883d-e6f4-48e5-82ed-9ad2be53340e@github.com>
Message-ID: <iKAMfZmlpXTmnJLgCGhdewo9fZ55a4mZldY0jBNJ-28=.8ba2b92f-9305-4004-8940-f5af4ac79dcb@github.com>

On Thu, 17 Apr 2025 16:26:59 GMT, Naoto Sato <naoto at openjdk.org> 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?
>
>> 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.

> @naotoj Unfortunately, I do not have the possibility to test on a Windows machine with Chinese locale.
> 
> I'll ping Yi Yang who was behind #3107, a suggested solution for [JDK-8263028](https://bugs.openjdk.org/browse/JDK-8263028). That is the best I was able to dig up for any contributor that clearly had run into this kind of problems before.
> 
> @y1yang0 Can you please help us to test this patch so it works properly on Windows computers with Chinese locale?

Sorry, I haven't worked on JDK for a while. Maybe @Glavo?

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2856775920

From swen at openjdk.org  Wed May  7 01:53:20 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 7 May 2025 01:53:20 GMT
Subject: RFR: 8352480: Don't follow symlinks in additional content for app
 images [v2]
In-Reply-To: <JKSq7zes6_VlV45NkYKKDcvUkExp8w3rg0CZdkRzOHM=.afff8fbd-dde9-4019-88ec-63779ead42fb@github.com>
References: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
 <JKSq7zes6_VlV45NkYKKDcvUkExp8w3rg0CZdkRzOHM=.afff8fbd-dde9-4019-88ec-63779ead42fb@github.com>
Message-ID: <0x4NlyUcYHzwYW-IIHRNJTNWIXRvcohZDad0eKVscNI=.bb774920-52df-4b0e-8c84-ee0d70c3d520@github.com>

On Wed, 7 May 2025 01:34:13 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Symbolic links will not be followed for `--app-content` on all platforms.
>> - Added test to cover this case.
>> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links.
>
> Alexander Matveev has updated the pull request with a new target base 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 remote-tracking branch 'upstream/master' into JDK-8352480
>  - 8352480: [macos] Don't follow symlinks in additional content for app images [v4]
>  - 8352480: [macos] Don't follow symlinks in additional content for app images [v3]
>  - 8352480: [macos] Don't follow symlinks in additional content for app images [v2]
>  - 8352480: [macos] Don't follow symlinks in additional content for app images

test/jdk/tools/jpackage/share/AppContentTest.java line 37:

> 35: import java.util.stream.Stream;
> 36: import static jdk.internal.util.OperatingSystem.MACOS;
> 37: import static jdk.internal.util.OperatingSystem.LINUX;

Should the imports here be sorted?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2076636260

From almatvee at openjdk.org  Wed May  7 02:07:03 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 7 May 2025 02:07:03 GMT
Subject: RFR: 8352480: Don't follow symlinks in additional content for app
 images [v3]
In-Reply-To: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
References: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
Message-ID: <nBloeGMFbz5uS_37AONMV0ApSWAtYHzgu-DQyqt0Oyo=.20e9ee1f-81ba-422e-93cf-a38ae4ec4318@github.com>

> - Symbolic links will not be followed for `--app-content` on all platforms.
> - Added test to cover this case.
> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8352480: [macos] Don't follow symlinks in additional content for app images [v5]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24974/files
  - new: https://git.openjdk.org/jdk/pull/24974/files/519be97e..166c3ffa

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

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

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

From almatvee at openjdk.org  Wed May  7 02:07:05 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 7 May 2025 02:07:05 GMT
Subject: RFR: 8352480: Don't follow symlinks in additional content for app
 images [v2]
In-Reply-To: <0x4NlyUcYHzwYW-IIHRNJTNWIXRvcohZDad0eKVscNI=.bb774920-52df-4b0e-8c84-ee0d70c3d520@github.com>
References: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
 <JKSq7zes6_VlV45NkYKKDcvUkExp8w3rg0CZdkRzOHM=.afff8fbd-dde9-4019-88ec-63779ead42fb@github.com>
 <0x4NlyUcYHzwYW-IIHRNJTNWIXRvcohZDad0eKVscNI=.bb774920-52df-4b0e-8c84-ee0d70c3d520@github.com>
Message-ID: <1dns1SyGSQ85llY_Kqo98wTOpfm6WSvROxHacTyD7Ek=.0e491427-18de-4510-beea-09d2c096665a@github.com>

On Wed, 7 May 2025 01:50:31 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request with a new target base 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 remote-tracking branch 'upstream/master' into JDK-8352480
>>  - 8352480: [macos] Don't follow symlinks in additional content for app images [v4]
>>  - 8352480: [macos] Don't follow symlinks in additional content for app images [v3]
>>  - 8352480: [macos] Don't follow symlinks in additional content for app images [v2]
>>  - 8352480: [macos] Don't follow symlinks in additional content for app images
>
> test/jdk/tools/jpackage/share/AppContentTest.java line 37:
> 
>> 35: import java.util.stream.Stream;
>> 36: import static jdk.internal.util.OperatingSystem.MACOS;
>> 37: import static jdk.internal.util.OperatingSystem.LINUX;
> 
> Should the imports here be sorted?

Yes. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2076644634

From duke at openjdk.org  Wed May  7 02:10:56 2025
From: duke at openjdk.org (erifan)
Date: Wed, 7 May 2025 02:10:56 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v5]
In-Reply-To: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
Message-ID: <huhJ3Yq2fj9CJGBAqQFZxd8i0Wjnwad3moNHymXKyy8=.d64a2532-6bd5-4e58-84ee-18f682d7fe20@github.com>

> 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 eight additional commits since the last revision:

 - Refactor code
   
   Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
   optimization, making the code more modular.
 - Merge branch 'master' into JDK-8354242
 - Update the jtreg test
 - Merge branch 'master' into JDK-8354242
 - Addressed some review comments
   
   1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
   2. Improve code comments.
 - Merge branch 'master' into JDK-8354242
 - Merge branch 'master' into JDK-8354242
 - 8354242: VectorAPI: combine vector not operation with compare
   
   This patch optimizes the following patterns:
   For integer types:
   ```
   (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
       => (VectorMaskCmp src1 src2 ncond)
   (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
       => (VectorMaskCmp src1 src2 ncond)
   ```
   cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
   negative comparison of cond.
   
   For float and double types:
   ```
   (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
       => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
   (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
       => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
   ```
   cond can be eq or ne.
   
   Benchmarks on Nvidia Grace machine with 128-bit SVE2:
   With option `-XX:UseSVE=2`:
   ```
   Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
   testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
   testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
   testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
   testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
   testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
   testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
   testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
   testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
   testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
   testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
   testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
   testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
   testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
   testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
   testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
   testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
   testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
   testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
   testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
   testCompareLTMaskNotInt		ops/s	1672180.09	995.238142	2353757.863	853.774734	1.4
   testCompareLTMaskNotLong	ops/s	856502.2695	12276.82851	1177671.815	496.723302	1.37
   testCompareLTMaskNotShort	ops/s	3325798.025	2412.702501	4711554.181	1779.302112	1.41
   testCompareNEMaskNotByte	ops/s	7910002.518	2771.82477	10245315.33	16321.93935	1.29
   testCompareNEMaskNotDouble	ops/s	863754.6022	523.140788	1179133.982	476.572178	1.36
   testCompareNEMaskNotFloat	ops/s	1723321.883	2598.484803	2358492.186	877.1401	1.36
   testCompareNEMaskNotInt		ops/s	1670288.841	751.774826	2354158.125	835.720163	1.4
   testCompareNEMaskNotLong	ops/s	836327.6835	410.525466	1178178.825	308.757932	1.4
   testCompareNEMaskNotShort	ops/s	3327815.841	1511.978763	4711379.136	2336.505531	1.41
   testCompareUGEMaskNotByte	ops/s	7906699.024	3200.936474	10253843.74	15067.59401	1.29
   testCompareUGEMaskNotInt	ops/s	1674003.923	3287.191727	2353340.666	951.381021	1.4
   testCompareUGEMaskNotLong	ops/s	852424.5562	8920.408939	1177943.609	389.6621	1.38
   testCompareUGEMaskNotShort	ops/s	3327255.858	1584.885143	4711622.355	1247.215277	1.41
   testCompareUGTMaskNotByte	ops/s	7909249.189	4435.283667	10245541.34	10993.34739	1.29
   testCompareUGTMaskNotInt	ops/s	1693713.433	20650.00213	2353153.787	1055.343846	1.38
   testCompareUGTMaskNotLong	ops/s	851022.3395	7079.065268	1177910.677	538.604598	1.38
   testCompareUGTMaskNotShort	ops/s	3327236.988	1616.886789	4711209.865	3098.494145	1.41
   testCompareULEMaskNotByte	ops/s	7909350.825	3251.262342	10261449.03	7273.831341	1.29
   testCompareULEMaskNotInt	ops/s	1672350.925	1545.304304	2353231.755	914.231193	1.4
   testCompareULEMaskNotLong	ops/s	853349.4765	9804.906913	1177967.254	435.044367	1.38
   testCompareULEMaskNotShort	ops/s	3325757.891	1555.062257	4712873.187	1650.986905	1.41
   testCompareULTMaskNotByte	ops/s	7912218.621	2633.477744	10242095.98	21921.39902	1.29
   testCompareULTMaskNotInt	ops/s	1673994.849	2672.507666	2353449.22	946.105757	1.4
   testCompareULTMaskNotLong	ops/s	849032.5868	10406.06689	1177586.047	506.541456	1.38
   testCompareULTMaskNotShort	ops/s	3328062.026	1892.991844	4713247.216	1855.983724	1.41
   
   ```
   With option `-XX:UseSVE=0`:
   ```
   Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
   testCompareEQMaskNotByte	ops/s	7895961.919	72712.90804	7746493.731	71481.92938	0.98
   testCompareEQMaskNotDouble	ops/s	789811.0455	384.493088	766473.7994	2216.581793	0.97
   testCompareEQMaskNotFloat	ops/s	1806305.818	638.010451	1819616.613	3295.38958	1
   testCompareEQMaskNotInt		ops/s	1815820.144	1225.336135	1849538.401	766.29902	1.01
   testCompareEQMaskNotLong	ops/s	807336.492	335.451807	792732.9483	277.954432	0.98
   testCompareEQMaskNotShort	ops/s	4818266.38	1927.862665	4668903.001	1922.782715	0.96
   testCompareGEMaskNotByte	ops/s	7818439.678	75374.97739	16498003.98	41440.49653	2.11
   testCompareGEMaskNotInt		ops/s	1815159.05	1090.912209	2372095.779	1664.397112	1.3
   testCompareGEMaskNotLong	ops/s	804324.5575	2301.686878	927919.8507	371.766719	1.15
   testCompareGEMaskNotShort	ops/s	4818966.563	2443.643652	5385561.038	29558.37423	1.11
   testCompareGTMaskNotByte	ops/s	7893406.157	82687.74264	16470663.2	22165.55812	2.08
   testCompareGTMaskNotInt		ops/s	1815316.812	915.894106	2370447.198	655.016338	1.3
   testCompareGTMaskNotLong	ops/s	807019.456	526.525482	928079.0541	330.582693	1.15
   testCompareGTMaskNotShort	ops/s	4820552.881	1684.247747	5355902.93	5893.2915	1.11
   testCompareLEMaskNotByte	ops/s	7816263.323	79560.0015	16473621.19	56688.99585	2.1
   testCompareLEMaskNotInt		ops/s	1814915.724	926.998625	2368790.306	932.594778	1.3
   testCompareLEMaskNotLong	ops/s	806483.9	935.718082	928110.9074	407.096695	1.15
   testCompareLEMaskNotShort	ops/s	4813660.241	6817.870509	5357107.852	10061.47975	1.11
   testCompareLTMaskNotByte	ops/s	7838948.962	69136.4504	16424405.96	24464.75469	2.09
   testCompareLTMaskNotInt		ops/s	1815056.833	1187.6453	2369892.187	1103.819634	1.3
   testCompareLTMaskNotLong	ops/s	806602.1804	287.923365	928346.4118	617.682824	1.15
   testCompareLTMaskNotShort	ops/s	4817940.643	2767.1509	5372537.84	15397.47169	1.11
   testCompareNEMaskNotByte	ops/s	9078493.798	4630.339307	16484348.42	18925.88346	1.81
   testCompareNEMaskNotDouble	ops/s	661769.6272	398.712981	926763.5839	1808.843788	1.4
   testCompareNEMaskNotFloat	ops/s	1570527.252	563.642144	2312425.678	1815.844846	1.47
   testCompareNEMaskNotInt		ops/s	1619146.58	626.793854	2369711.543	942.330478	1.46
   testCompareNEMaskNotLong	ops/s	680201.5381	2252.836482	927808.6147	414.917863	1.36
   testCompareNEMaskNotShort	ops/s	3763508.054	3622.560798	5367808.015	8591.466599	1.42
   testCompareUGEMaskNotByte	ops/s	7886373.129	75917.74675	16480928.93	27524.31005	2.08
   testCompareUGEMaskNotInt	ops/s	1815636.832	750.036241	2369683.015	901.609404	1.3
   testCompareUGEMaskNotLong	ops/s	806862.5826	287.819616	928001.4394	361.063837	1.15
   testCompareUGEMaskNotShort	ops/s	4820581.361	2098.537435	5375854.248	25619.40165	1.11
   testCompareUGTMaskNotByte	ops/s	7891591.465	96614.93542	16410405.93	15012.37096	2.07
   testCompareUGTMaskNotInt	ops/s	1814871.179	662.825588	2371325.903	1170.491164	1.3
   testCompareUGTMaskNotLong	ops/s	804013.7658	2240.534209	928062.2169	531.306897	1.15
   testCompareUGTMaskNotShort	ops/s	4818150.337	3051.717685	5381449.337	21212.34187	1.11
   testCompareULEMaskNotByte	ops/s	7831540.628	81306.67253	16495250.78	38682.19675	2.1
   testCompareULEMaskNotInt	ops/s	1814484.14	687.860656	2369265.075	940.609586	1.3
   testCompareULEMaskNotLong	ops/s	807780.5749	769.876816	927538.0732	1278.267724	1.14
   testCompareULEMaskNotShort	ops/s	4817437.42	5141.336541	5356183.359	7015.608124	1.11
   testCompareULTMaskNotByte	ops/s	7849078.225	56753.59764	16395975.27	34043.67295	2.08
   testCompareULTMaskNotInt	ops/s	1814328.226	2697.219111	2370700.47	1991.841988	1.3
   testCompareULTMaskNotLong	ops/s	807166.8197	253.061506	927926.2803	252.933462	1.14
   testCompareULTMaskNotShort	ops/s	4821098.216	1625.959044	5348980.243	4100.768121	1.1
   ```
   
   Benchmarks on AMD EPYC 9124 16-Core Processor:
   With option `-XX:UseAVX=3`:
   ```
   Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
   testCompareEQMaskNotByte	ops/s	16607323.35	1233692.631	18381557.66	1163201.522	1.1
   testCompareEQMaskNotDouble	ops/s	2114285.245	58782.2534	2959946.353	43016.0445	1.39
   testCompareEQMaskNotFloat	ops/s	4480874.437	89975.29074	6960151.436	64799.143	1.55
   testCompareEQMaskNotInt		ops/s	4370906.91	51784.80889	6856955.043	313858.5504	1.56
   testCompareEQMaskNotLong	ops/s	2080065.895	26762.06732	2939142.143	67179.05314	1.41
   testCompareEQMaskNotShort	ops/s	7968282.563	210437.2781	12701214.56	473152.6407	1.59
   testCompareGEMaskNotByte	ops/s	18419141.89	473408.9451	19880059.68	321638.0397	1.07
   testCompareGEMaskNotInt		ops/s	4419015.62	77352.98633	7037639.227	151066.0383	1.59
   testCompareGEMaskNotLong	ops/s	2147982.48	49227.42782	3000275.928	39298.75344	1.39
   testCompareGEMaskNotShort	ops/s	8469039.613	17833.19707	12288229.49	244317.8812	1.45
   testCompareGTMaskNotByte	ops/s	18728997.5	468328.8358	20544730.05	392264.6466	1.09
   testCompareGTMaskNotInt		ops/s	4510009.705	78812.57357	7364629.942	70970.78473	1.63
   testCompareGTMaskNotLong	ops/s	2124104.969	40917.89257	2953536.279	35199.19687	1.39
   testCompareGTMaskNotShort	ops/s	8690557.621	311534.1159	12344017.51	457931.8741	1.42
   testCompareLEMaskNotByte	ops/s	17758400.53	478383.4945	19209183.26	1143297.241	1.08
   testCompareLEMaskNotInt		ops/s	4363664.862	43443.18063	7054093.064	78141.11476	1.61
   testCompareLEMaskNotLong	ops/s	2068632.213	29844.78023	2954766.412	50667.22502	1.42
   testCompareLEMaskNotShort	ops/s	8637608.548	183538.5511	12719010.27	473568.8825	1.47
   testCompareLTMaskNotByte	ops/s	14406138.95	423105.0163	17292417.96	371386.9689	1.2
   testCompareLTMaskNotInt		ops/s	4546707.266	131977.3144	7040483.394	213590.4657	1.54
   testCompareLTMaskNotLong	ops/s	2123277.356	47243.21499	2848720.442	58896.97045	1.34
   testCompareLTMaskNotShort	ops/s	7570169.363	649873.6295	11945383.75	988276.5955	1.57
   testCompareNEMaskNotByte	ops/s	18274529.55	683396.7384	19081938.8	1118739.778	1.04
   testCompareNEMaskNotDouble	ops/s	2112533.61	43295.50012	2912115.441	78189.51083	1.37
   testCompareNEMaskNotFloat	ops/s	4628683.814	93817.07362	6967208.729	145135.8544	1.5
   testCompareNEMaskNotInt		ops/s	4470900.214	75974.50842	7286913.662	116328.5277	1.62
   testCompareNEMaskNotLong	ops/s	2134091.061	46377.94061	2934667.477	81675.46021	1.37
   testCompareNEMaskNotShort	ops/s	8790384.287	396161.8599	13076858.35	286272.1155	1.48
   testCompareUGEMaskNotByte	ops/s	18009150.9	660803.8886	17551258.33	1667014.843	0.97
   testCompareUGEMaskNotInt	ops/s	4442928.74	83190.81019	6854088.277	329008.8901	1.54
   testCompareUGEMaskNotLong	ops/s	2088357.736	71696.24791	2973202.26	63278.78974	1.42
   testCompareUGEMaskNotShort	ops/s	8348624.02	116562.7876	12832250.78	546869.3006	1.53
   testCompareUGTMaskNotByte	ops/s	17871101.25	800199.6321	19902619.81	214003.3262	1.11
   testCompareUGTMaskNotInt	ops/s	4088304.421	137797.9723	7135454.33	124553.651	1.74
   testCompareUGTMaskNotLong	ops/s	2070610.42	19881.82182	2991536.365	36260.60767	1.44
   testCompareUGTMaskNotShort	ops/s	8637099.341	155822.1608	12756579.77	186068.199	1.47
   testCompareULEMaskNotByte	ops/s	17940901.36	1258029.364	18932484.94	694554.6305	1.05
   testCompareULEMaskNotInt	ops/s	4369177.511	74982.31936	6392773.082	550171.2266	1.46
   testCompareULEMaskNotLong	ops/s	2135905.761	43693.63178	2877579.631	41651.56289	1.34
   testCompareULEMaskNotShort	ops/s	8607710.544	132655.1676	12446370.04	441718.3035	1.44
   testCompareULTMaskNotByte	ops/s	17409912.23	1033204.537	20607479.99	362000.5056	1.18
   testCompareULTMaskNotInt	ops/s	4386455.9	119192.1635	6920123.264	186158.2845	1.57
   testCompareULTMaskNotLong	ops/s	2064995.149	38622.2734	2988343.589	39037.90006	1.44
   testCompareULTMaskNotShort	ops/s	8642182.752	230919.2442	13029582.09	437101.4923	1.5
   ```
   
   The small amount of performance degradation is due to test fluctuations.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24674/files
  - new: https://git.openjdk.org/jdk/pull/24674/files/4fbf84e3..001fac0f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=03-04

  Stats: 27362 lines in 755 files changed: 19223 ins; 4813 del; 3326 mod
  Patch: https://git.openjdk.org/jdk/pull/24674.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24674/head:pull/24674

PR: https://git.openjdk.org/jdk/pull/24674

From duke at openjdk.org  Wed May  7 02:10:56 2025
From: duke at openjdk.org (erifan)
Date: Wed, 7 May 2025 02:10:56 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v3]
In-Reply-To: <ukQEp7aEkMwZVRiy0178aHGYakmWrA0wQ-adDDRTPzw=.1bdceaf9-0338-49ec-8ff2-3d6db70360af@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <d3j_5wtavYCnzkiXe3P1VQeuRRK1MXDpJd4okI3UBUg=.8b9e56ad-bbc3-4b12-8ff0-fcb86ff4f4df@github.com>
 <1Qo4pB9I7Ok4ntXSE-KkE0sv-Tp5EVCWriWnjcf2iEE=.a7e28640-85df-436a-9c82-3c067cc88dee@github.com>
 <ukQEp7aEkMwZVRiy0178aHGYakmWrA0wQ-adDDRTPzw=.1bdceaf9-0338-49ec-8ff2-3d6db70360af@github.com>
Message-ID: <d-2LlN6uvKpRI5Y6IPySaAR-CKfpxAMReg3Iidb2CmA=.476570ee-57b0-4e95-b0d0-151e8ff6683e@github.com>

On Thu, 1 May 2025 07:32:22 GMT, erifan <duke at openjdk.org> wrote:

>> Yes, this discussion is down to `requires` vs `applyIf`. This is my argument for `applyIf`, quoted from above, I have not yet seen an argument against it:
>> 
>>>  If you use @require, then the person does not realize there is a test AND the test is not run. If you use applyIf, the person does not realize there is a test, but it is run at least for result verifiation - and then the person MIGHT realize if the test catches a wrong result / crash.
>> 
>> In my understanding, `requires` should only be used if the test really **requires** a certain platform or feature. That can be because some flags are only available under certain platforms for example. But for IR tests, we should try to always use `applyIf`, because it allows testing on other platforms.
>> 
>> Actually, I filed this RFE a while ago: https://bugs.openjdk.org/browse/JDK-8310891
>> We should try to move as many tests from using `requires` to `applyIf`, so that we have an increased test coverage.
>
> @eme64 @jatin-bhateja I have updated the test, thanks for your suggestion.

> @erifan thanks for updating the tests!
> 
> Now I had a quick look at the VM code.
> 
> My biggest observation is this:
> 
> Wrapping `VectorNode::Ideal` somewhere in the middle of your new optimization is going to make future optimizations here much harder. How would they check their conditions next to yours? That would be quite a mess.
> 
> I suggest you do this:
> 
> * `XorVNode::Ideal` does
>   
>   * checks `in1 == in2` case
>   * calls a method called `XorVNode::Ideal_XorV_VectorMaskCmp`. Check if it succeeded, i.e. returns `nullptr`.
>   * ... future optimizations could go here ...
>   * Finally, i.e. none of the optimizations above worked: call `VectorNode::Ideal`
> 
> Then you pack all your new logic here into `XorVNode::Ideal_XorV_VectorMaskCmp`. You can also find a better name, it is just what I came up with just now.
> 
> This gives us a much more **modular** design, and it is easier to add another new optimization to `XorVNode::Ideal`. It is easy to change the precedence of the optimizations by just changing the order, etc.
> 
> Examples of this "modular" design:
> 
> * `CMoveNode::Ideal` -> calls `TypeNode::Ideal` and `Ideal_minmax`.
> * `StoreBNode::Ideal` -> calls `StoreNode::Ideal_masked_input` and `StoreNode::Ideal_sign_extended_input`
>   These are really nice, because you can quickly see what optimizations we already have, and in which order they are checked.

Yes, this is a good idea, I have changed it like this, thanks for your suggestion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-2856811448

From duke at openjdk.org  Wed May  7 02:10:56 2025
From: duke at openjdk.org (erifan)
Date: Wed, 7 May 2025 02:10:56 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v4]
In-Reply-To: <o40v1IOifQIXNQH1HPBfHR6xyBfZJF2pFh4dw9GdKLQ=.0e117807-a2af-4814-858b-33133c912a7f@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <J2uce-Koxq3zh8Fw16I10d6xvZAn9OZv0PpX8iI597I=.962dd328-f9fb-4882-8e66-b84a179552df@github.com>
 <NETYBagyHXjwUHDzO8Lko4pgtjXm105d9COgS0-Ja7M=.55a9d4bf-9a61-45bd-9848-693ab7cb444b@github.com>
 <o40v1IOifQIXNQH1HPBfHR6xyBfZJF2pFh4dw9GdKLQ=.0e117807-a2af-4814-858b-33133c912a7f@github.com>
Message-ID: <aJmywqoZGKVL9-KwxnhuJ4ieU2Y9oZch5tS1qu42NSQ=.e9442200-e309-4a94-ba1f-0670390c0556@github.com>

On Fri, 2 May 2025 06:14:33 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/share/opto/vectornode.cpp line 2216:
>> 
>>> 2214:       in2->is_predicated_vector()) {
>>> 2215:     with_predicated = true;
>>> 2216:   }
>> 
>> Suggestion:
>> 
>>   bool with_predicated = is_predicated_vector() ||
>>                          in1->is_predicated_vector() ||
>>                          in2->is_predicated_vector();
>
> Would that not be easier to read?

Yes, done, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2076645802

From duke at openjdk.org  Wed May  7 02:10:58 2025
From: duke at openjdk.org (erifan)
Date: Wed, 7 May 2025 02:10:58 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v4]
In-Reply-To: <NETYBagyHXjwUHDzO8Lko4pgtjXm105d9COgS0-Ja7M=.55a9d4bf-9a61-45bd-9848-693ab7cb444b@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <J2uce-Koxq3zh8Fw16I10d6xvZAn9OZv0PpX8iI597I=.962dd328-f9fb-4882-8e66-b84a179552df@github.com>
 <NETYBagyHXjwUHDzO8Lko4pgtjXm105d9COgS0-Ja7M=.55a9d4bf-9a61-45bd-9848-693ab7cb444b@github.com>
Message-ID: <4ZhJjZtiOsmaTZzKbYFE99Q-J01WP_8kDB3Egx5znHY=.54b633f8-73ba-4083-8946-524c8bd6e47e@github.com>

On Fri, 2 May 2025 06:16:03 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Update the jtreg test
>>  - Merge branch 'master' into JDK-8354242
>>  - Addressed some review comments
>>    
>>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>>    2. Improve code comments.
>>  - Merge branch 'master' into JDK-8354242
>>  - Merge branch 'master' into JDK-8354242
>>  - 8354242: VectorAPI: combine vector not operation with compare
>>    
>>    This patch optimizes the following patterns:
>>    For integer types:
>>    ```
>>    (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    ```
>>    cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>>    negative comparison of cond.
>>    
>>    For float and double types:
>>    ```
>>    (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    ```
>>    cond can be eq or ne.
>>    
>>    Benchmarks on Nvidia Grace machine with 128-bit SVE2:
>>    With option `-XX:UseSVE=2`:
>>    ```
>>    Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>>    testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>>    testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>>    testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>>    testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>>    testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>>    testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>>    testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>>    testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>>    testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
>>    testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
>>    testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	1...
>
> src/hotspot/share/opto/vectornode.cpp line 2224:
> 
>> 2222:   //    => (VectorMaskCmp src1 src2 ncond)
>> 2223:   // cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>> 2224:   // negative comparison of cond.
> 
> Suggestion:
> 
>   // cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt.
>   // ncond is the negative comparison of cond.
> 
> I was getting lost in all the commas.

Done.

> src/hotspot/share/opto/vectornode.cpp line 2248:
> 
>> 2246:       !((VectorMaskCmpNode*) in1)->predicate_can_be_inverted() ||
>> 2247:       !VectorNode::is_all_ones_vector(in2)) {
>> 2248:     return VectorNode::Ideal(phase, can_reshape);
> 
> Hmm, so this is really the "else" case, if your optimization does not succeed, right?
> 
> Wrapping `VectorNode::Ideal` somewhere in the middle is going to make future optimizations here much harder.
> How would they check their conditions next to yours? That would be quite a mess.
> 
> I suggest you do this:
> - `XorVNode::Ideal` does
>   - checks `in1 == in2` case
>   - calls a method called `XorVNode::Ideal_XorV_VectorMaskCmp`. Check if it succeeded, i.e. returns `nullptr`.
>   - Finally, i.e. none of the optimizations above worked: call `VectorNode::Ideal`
> 
> Then you pack all your new logic here into `XorVNode::Ideal_XorV_VectorMaskCmp`. You can also find a better name, it is just what I came up with just now.
> 
> This gives us a much more **modular** design, and it is easier to add another new optimization to `XorVNode::Ideal`. It is easy to change the precedence of the optimizations by just changing the order, etc.

Done, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2076646028
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2076646366

From asmehra at openjdk.org  Wed May  7 02:40:15 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 7 May 2025 02:40:15 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v3]
In-Reply-To: <ZqN7me24ilvFxqQs47wNdM6lhli5RuQXWKP4fwRI4No=.4fae3be6-ceb5-4de2-b129-1fde746c0760@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <ZqN7me24ilvFxqQs47wNdM6lhli5RuQXWKP4fwRI4No=.4fae3be6-ceb5-4de2-b129-1fde746c0760@github.com>
Message-ID: <ghRbsTKv7mkvOeCIyZgGuy_sYvYjSJOgMGCSZJleU1c=.ebbd7a19-1672-49ac-b58e-5c6d9c522517@github.com>

On Mon, 5 May 2025 01:00:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>> 
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
>> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
>> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
>> 
>> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
>> 
>> Examples:
>> 
>> 
>> # Create an AOT cache with a single command:
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> Hello World
>> Temporary AOTConfiguration recorded: foo.aot.config
>> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
>> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
>> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
>> AOTCache creation is complete: foo.aot 10240000 bytes
>> 
>> # Create logging file for the AOT cache assembly phase
>> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> 
>> 
>> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @vnkozlov comments

src/hotspot/share/cds/cdsConfig.cpp line 428:

> 426: 
> 427:   // At least one AOT flag has been used
> 428:  _new_aot_flags_used = true;

indentation seems off?

src/hotspot/share/cds/cdsConfig.cpp line 490:

> 488:   bool has_output = !FLAG_IS_DEFAULT(AOTCacheOutput);
> 489: 
> 490:   if (has_output) {

Can this if-else block be refactored as:


if (!has_output && !has_config) {
  vm_exit_during_initialization("...");
}
if (has_output) {

}

This pattern in much easier to read IMO.

src/hotspot/share/cds/cdsConfig.cpp line 504:

> 502:   } else {
> 503:     if (!has_config) {
> 504:       vm_exit_during_initialization("-XX:AOTMode=record cannot be used without setting AOTCacheOutput or AOTConfiguration");

I suggest to be consistent in phrasing the error messages related to incomplete options. I liked the way it is worded in `check_aotmode_create()`. So  my preference is to replace `-XX:AOTMode=record cannot be used without setting AOTCacheOutput or AOTConfiguration` with `AOTCacheOutput or AOTConfiguration must be specified when using -XX:AOTMode=record`. But you may chose otherwise as long as the structure of the error messages is consistent.

src/hotspot/share/cds/cdsConfig.cpp line 526:

> 524: void CDSConfig::check_aotmode_create() {
> 525:   if (FLAG_IS_DEFAULT(AOTConfiguration)) {
> 526:     vm_exit_during_initialization("-XX:AOTMode=create cannot be used without setting AOTConfiguration");

Same suggestion regarding error msg:
Replace `-XX:AOTMode=create cannot be used without setting AOTConfiguration` 
with 
`AOTConfiguration must be specified when using -XX:AOTMode=create`

src/hotspot/share/cds/metaspaceShared.cpp line 1082:

> 1080:   for (int i = 0; i < Arguments::num_jvm_args(); i++) {
> 1081:     const char* arg = Arguments::jvm_args_array()[i];
> 1082:     if (strncmp("-XX:AOTCacheOutput=", arg, 19) == 0 ||

I have seen this hard coding of string length in the `strncmp` call many times in the code base. I wonder why we don't use something like this:

strncmp("-XX:AOTCacheOutput=", arg, sizeof("-XX:AOTCacheOutput=")-1)

Counting chars is really error prone. sizeof("...")-1 gives the same result.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076664964
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076665081
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076667404
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076667613
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076667744

From swen at openjdk.org  Wed May  7 03:08:14 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 7 May 2025 03:08:14 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v3]
In-Reply-To: <Rp5KEWwo32Q1xji7MPrEXzdLwOPRwFBqwBfyP4GviuA=.1dc73cc9-550f-4a1b-ac03-34a2fb302af1@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com>
 <kdQ0cQYPOnJu1nON4BYTube75JfjVWp-2CfsPfz2AU8=.f1fe7acf-a054-4e19-b51f-51e092daef39@github.com>
 <qGh4TxJ7MIudua-Xk4iMx354D_QLCN1in8u2G0qk4F0=.c6e77625-0a27-4876-99e6-49431ad78798@github.com>
 <Rp5KEWwo32Q1xji7MPrEXzdLwOPRwFBqwBfyP4GviuA=.1dc73cc9-550f-4a1b-ac03-34a2fb302af1@github.com>
Message-ID: <GoVjQ_q86ONHLp7dioqHSFXL5BWVPz4LATUGBuhoUWs=.f771947f-5b13-4d53-ac72-0f539fe7abc0@github.com>

On Tue, 6 May 2025 17:16:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> I have the old switch format in anticipation of faster startup.
>
> enhanced 'switch' is just syntax sugar and does not affect startup speed

I looked at the generated bytecode through javap and confirmed that the enhanced switch is just syntactic sugar and no additional classes are generated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2076686117

From swen at openjdk.org  Wed May  7 03:12:14 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 7 May 2025 03:12:14 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v4]
In-Reply-To: <Av9w-CHHrUGeABiUbfvlhVCfJtqKyQELdTIwbsCVNf0=.6dc0ed4b-ab3c-42fd-afdd-9539d8072d23@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <Av9w-CHHrUGeABiUbfvlhVCfJtqKyQELdTIwbsCVNf0=.6dc0ed4b-ab3c-42fd-afdd-9539d8072d23@github.com>
Message-ID: <kPUSblqe_-dwKo8_pMgp5b0_wvy5RHlgUtu8n248OiQ=.7da87900-da3a-4b9d-b019-8f7b119af683@github.com>

On Tue, 6 May 2025 12:32:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 121:

> 119:             return obj instanceof BasicKey that &&
> 120:                     returnType.equals(that.returnType) &&
> 121:                     stateName.equals(that.stateName);

Suggestion:

            return obj instanceof BasicKey that
                    && returnType.equals(that.returnType)
                    && stateName.equals(that.stateName);

In the JDK source code, the operator && is placed in front in most cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2076688887

From swen at openjdk.org  Wed May  7 03:22:13 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 7 May 2025 03:22:13 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v4]
In-Reply-To: <Av9w-CHHrUGeABiUbfvlhVCfJtqKyQELdTIwbsCVNf0=.6dc0ed4b-ab3c-42fd-afdd-9539d8072d23@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <Av9w-CHHrUGeABiUbfvlhVCfJtqKyQELdTIwbsCVNf0=.6dc0ed4b-ab3c-42fd-afdd-9539d8072d23@github.com>
Message-ID: <xASnVm_w4dvoU3nVzizAg9p1MkDhDb30JudBx3FTrOA=.29075706-30b8-4c38-a505-844d1401b653@github.com>

On Tue, 6 May 2025 12:32:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 78:

> 76:                 inputs.add(new BasicKey(c, layout.name().orElseThrow()));
> 77:             }
> 78:         }

Suggestion:

        for (MemoryLayout layout : CAPTURE_LAYOUT.memberLayouts()) {
            String name = layout.name().orElseThrow();
            inputs.add(new BasicKey(int.class, name));
            inputs.add(new BasicKey(long.class, name));
        }

There are only two classes, int.class and long.class, so this might be simpler.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2076694737

From swen at openjdk.org  Wed May  7 03:28:14 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 7 May 2025 03:28:14 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v4]
In-Reply-To: <Av9w-CHHrUGeABiUbfvlhVCfJtqKyQELdTIwbsCVNf0=.6dc0ed4b-ab3c-42fd-afdd-9539d8072d23@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <Av9w-CHHrUGeABiUbfvlhVCfJtqKyQELdTIwbsCVNf0=.6dc0ed4b-ab3c-42fd-afdd-9539d8072d23@github.com>
Message-ID: <Y8fUo3wWU2FsApwmoKKWQZb3fsxAiTbz1cbUaOcOPVI=.dee71eaf-4e42-4cb2-886a-c3155d1b32e8@github.com>

On Tue, 6 May 2025 12:32:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 215:

> 213:         }
> 214:         // Last takes first
> 215:         perm[target.type().parameterCount()] = 0;

Suggestion:

        for (int i = 0; i < perm.length - 1; i++) {
            perm[i] = i;
        }
        // Last takes first
        perm[perm.length - 1] = 0;

Here you can use perm.length - 1

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2076701381

From iklam at openjdk.org  Wed May  7 05:11:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 7 May 2025 05:11:01 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v4]
In-Reply-To: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
Message-ID: <CgpPXWhAoXLJ7nZ9DKtkje5ThhCJMoLUhM74sOeWwNQ=.62d971f4-8446-4ffd-8982-a430d87c0df0@github.com>

> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
> 
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
> 
> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
> 
> Examples:
> 
> 
> # Create an AOT cache with a single command:
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> Hello World
> Temporary AOTConfiguration recorded: foo.aot.config
> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
> AOTCache creation is complete: foo.aot 10240000 bytes
> 
> # Create logging file for the AOT cache assembly phase
> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> 
> 
> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24942/files
  - new: https://git.openjdk.org/jdk/pull/24942/files/0eb8b545..5004a0b7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=02-03

  Stats: 19 lines in 5 files changed: 4 ins; 4 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/24942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942

PR: https://git.openjdk.org/jdk/pull/24942

From iklam at openjdk.org  Wed May  7 05:11:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 7 May 2025 05:11:01 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v3]
In-Reply-To: <ghRbsTKv7mkvOeCIyZgGuy_sYvYjSJOgMGCSZJleU1c=.ebbd7a19-1672-49ac-b58e-5c6d9c522517@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <ZqN7me24ilvFxqQs47wNdM6lhli5RuQXWKP4fwRI4No=.4fae3be6-ceb5-4de2-b129-1fde746c0760@github.com>
 <ghRbsTKv7mkvOeCIyZgGuy_sYvYjSJOgMGCSZJleU1c=.ebbd7a19-1672-49ac-b58e-5c6d9c522517@github.com>
Message-ID: <ieEB6NT8a4ANt76e3Hgvb6Lc1egQQY6b4zzlHlkU338=.7a7a972c-dd89-4ced-b7fe-71b0ce813e64@github.com>

On Wed, 7 May 2025 02:33:50 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @vnkozlov comments
>
> src/hotspot/share/cds/cdsConfig.cpp line 428:
> 
>> 426: 
>> 427:   // At least one AOT flag has been used
>> 428:  _new_aot_flags_used = true;
> 
> indentation seems off?

Fixed.

> src/hotspot/share/cds/cdsConfig.cpp line 490:
> 
>> 488:   bool has_output = !FLAG_IS_DEFAULT(AOTCacheOutput);
>> 489: 
>> 490:   if (has_output) {
> 
> Can this if-else block be refactored as:
> 
> 
> if (!has_output && !has_config) {
>   vm_exit_during_initialization("...");
> }
> if (has_output) {
> 
> }
> 
> This pattern in much easier to read IMO.

Fixed.

> src/hotspot/share/cds/cdsConfig.cpp line 504:
> 
>> 502:   } else {
>> 503:     if (!has_config) {
>> 504:       vm_exit_during_initialization("-XX:AOTMode=record cannot be used without setting AOTCacheOutput or AOTConfiguration");
> 
> I suggest to be consistent in phrasing the error messages related to incomplete options. I liked the way it is worded in `check_aotmode_create()`. So  my preference is to replace `-XX:AOTMode=record cannot be used without setting AOTCacheOutput or AOTConfiguration` with `AOTCacheOutput or AOTConfiguration must be specified when using -XX:AOTMode=record`. But you may chose otherwise as long as the structure of the error messages is consistent.

I changed to "At least one of AOTCacheOutput and AOTConfiguration must be specified when using -XX:AOTMode=record", so it's clear that both option can be specified together.

> src/hotspot/share/cds/cdsConfig.cpp line 526:
> 
>> 524: void CDSConfig::check_aotmode_create() {
>> 525:   if (FLAG_IS_DEFAULT(AOTConfiguration)) {
>> 526:     vm_exit_during_initialization("-XX:AOTMode=create cannot be used without setting AOTConfiguration");
> 
> Same suggestion regarding error msg:
> Replace `-XX:AOTMode=create cannot be used without setting AOTConfiguration` 
> with 
> `AOTConfiguration must be specified when using -XX:AOTMode=create`

Fixed.

> src/hotspot/share/cds/metaspaceShared.cpp line 1082:
> 
>> 1080:   for (int i = 0; i < Arguments::num_jvm_args(); i++) {
>> 1081:     const char* arg = Arguments::jvm_args_array()[i];
>> 1082:     if (strncmp("-XX:AOTCacheOutput=", arg, 19) == 0 ||
> 
> I have seen this hard coding of string length in the `strncmp` call many times in the code base. I wonder why we don't use something like this:
> 
> strncmp("-XX:AOTCacheOutput=", arg, sizeof("-XX:AOTCacheOutput=")-1)
> 
> Counting chars is really error prone. sizeof("...")-1 gives the same result.

I end up using `strstr()`, as I don't want to repeat the string literal twice (risking a typo) or use a macro.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076796934
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076796911
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076796869
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076796827
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076796802

From alanb at openjdk.org  Wed May  7 06:09:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 May 2025 06:09:14 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v3]
In-Reply-To: <V_z1LM8NiXvm2IaCKIJHcr-WrAVCc7KVB7eYUjGSszU=.dd1c921c-a20b-471b-8e5f-be63360be0d8@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <V_z1LM8NiXvm2IaCKIJHcr-WrAVCc7KVB7eYUjGSszU=.dd1c921c-a20b-471b-8e5f-be63360be0d8@github.com>
Message-ID: <5sF6nQjDykFcP5-etCpaYidBIGkJvNUzjC6PYRGfuGA=.71fc9b7e-40c8-4ee1-8a67-9b9181cda6ae@github.com>

On Fri, 2 May 2025 18:19:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set

The implementation changes looks okay. I assume the CSR will be expanded, e.g. to list deleteOnExit as Jason mentioned, before we can review it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2857168778

From duke at openjdk.org  Wed May  7 06:19:17 2025
From: duke at openjdk.org (Bernd)
Date: Wed, 7 May 2025 06:19:17 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v3]
In-Reply-To: <V_z1LM8NiXvm2IaCKIJHcr-WrAVCc7KVB7eYUjGSszU=.dd1c921c-a20b-471b-8e5f-be63360be0d8@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <V_z1LM8NiXvm2IaCKIJHcr-WrAVCc7KVB7eYUjGSszU=.dd1c921c-a20b-471b-8e5f-be63360be0d8@github.com>
Message-ID: <Hn6az0Z169AKMD70VL6WdowhUsetWBpS37QMXvRUPdg=.04c90f8c-52b4-40f5-a704-222ea4a34ed2@github.com>

On Fri, 2 May 2025 18:19:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set

Maybe the Release Notes should mention that this does not care for Unix readonly (I.e. files without Read permissions). Some tools warn about deleting such files on Linux, too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2857201912

From duke at openjdk.org  Wed May  7 06:22:19 2025
From: duke at openjdk.org (Daishi Tabata)
Date: Wed, 7 May 2025 06:22:19 GMT
Subject: Integrated: 8355249: Remove the use of WMIC from the entire source
 code
In-Reply-To: <blL6FOj7XD1T3u_ODIwYPIPDXEowzSR0w5j92nC9gCo=.8a2428d9-1795-4dd0-91fd-8b604c7cc100@github.com>
References: <blL6FOj7XD1T3u_ODIwYPIPDXEowzSR0w5j92nC9gCo=.8a2428d9-1795-4dd0-91fd-8b604c7cc100@github.com>
Message-ID: <TILOWVnbzalDC0nmkZ9fHavBPe2HIOHzVdrBxdtEZ-U=.75968c36-7934-4ebf-a137-1695c2188ec2@github.com>

On Tue, 22 Apr 2025 07:29:08 GMT, Daishi Tabata <duke at openjdk.org> wrote:

> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI.
> 
> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency.
> 
> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file.
> Note: In my environment, it worked correctly even without these options.
> 
> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in:
> 
> - `environment.html`: `windows/system/os` section
> - `process.html`: `[Process ID]/windows/native/info` section
> 
> **Testing:**
> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes.

This pull request has now been integrated.

Changeset: 4458719a
Author:    Daishi Tabata <tabata.daishi at fujitsu.com>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4458719a108f45d3744d47a6ea081fe9ec3e675e
Stats:     32 lines in 4 files changed: 6 ins; 2 del; 24 mod

8355249: Remove the use of WMIC from the entire source code

Reviewed-by: erikj, ihse, asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/24791

From duke at openjdk.org  Wed May  7 06:23:24 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 7 May 2025 06:23:24 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v12]
In-Reply-To: <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>
Message-ID: <VPRIWrp3whc6RpjkVEB3Dcx579VcpYPRfwVgk5hwAok=.e255665c-3d00-48ea-983d-802648d60dd8@github.com>

On Tue, 6 May 2025 20:52:34 GMT, Markus KARG <duke at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - merge latest from master branch
>  - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted?
>  - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs
>  - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since.
>  - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.'
>  - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars()
>  - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()
>  - 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)'
>  - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted?
>  - Applied changes requested by Alan: Copies chars from this sequence into the given destination array
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a

Github Actions have successfully passed all checks. ?? ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2857242098

From alanb at openjdk.org  Wed May  7 06:34:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 May 2025 06:34:14 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v3]
In-Reply-To: <Hn6az0Z169AKMD70VL6WdowhUsetWBpS37QMXvRUPdg=.04c90f8c-52b4-40f5-a704-222ea4a34ed2@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <V_z1LM8NiXvm2IaCKIJHcr-WrAVCc7KVB7eYUjGSszU=.dd1c921c-a20b-471b-8e5f-be63360be0d8@github.com>
 <Hn6az0Z169AKMD70VL6WdowhUsetWBpS37QMXvRUPdg=.04c90f8c-52b4-40f5-a704-222ea4a34ed2@github.com>
Message-ID: <0ylrb_KFxt2743YSl-GAK03cv9xcQWQmXivbCu1jGsw=.84fa516a-cefe-4d45-98f9-f9262e04c5dd@github.com>

On Wed, 7 May 2025 06:16:53 GMT, Bernd <duke at openjdk.org> wrote:

> Maybe the Release Notes should mention that this does not care for Unix readonly (I.e. files without Read permissions).

The release note will be clear that this is a Windows only change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2857268088

From jlahoda at openjdk.org  Wed May  7 06:34:14 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 7 May 2025 06:34:14 GMT
Subject: RFR: 8354260: Launcher help text is wrong for -Xms
In-Reply-To: <GNQoFX12jZpR2aUADOyHxNQZLmKb1dvi3-xavm2FcGQ=.fc94ed09-4d39-45f8-bb14-fb9f2041bcc2@github.com>
References: <GNQoFX12jZpR2aUADOyHxNQZLmKb1dvi3-xavm2FcGQ=.fc94ed09-4d39-45f8-bb14-fb9f2041bcc2@github.com>
Message-ID: <kD71JNfYJim42QDKZKl88NnjzVAWjjuzcsM9CQh5wIA=.078f826a-3cf7-4357-b4d0-2dcb4b9cd61b@github.com>

On Tue, 6 May 2025 08:02:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this update to synchronize the extra help text for `-Xms` with the description given in the manpage.
> 
> Copied from the issue:
>> The launcher help text for -Xms is wrong and should be updated to match the manpage description. The actual meaning of -Xms is that it sets both the initial and minimum Java heap size, not just the initial Java heap size.
>>
>> ````
>> $ java -X
>> ...
>> -Xms<size> set initial Java heap size
>> ````
>>
>> From the manpage:
>> ````
>> `-Xms` *size*
>> : Sets the minimum and the initial size (in bytes) of the heap. This value
>>     must be a multiple of 1024 and greater than 1 MB. Append the letter `k` or
>>     `K` to indicate kilobytes, `m` or `M` to indicate megabytes, or `g` or `G`
>>     to indicate gigabytes. The following examples show how to set the size of
>>     allocated memory to 6 MB using various units:
>> ````

Looks good to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25058#pullrequestreview-2820511606

From alan.bateman at oracle.com  Wed May  7 06:54:33 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 7 May 2025 07:54:33 +0100
Subject: Request for Enhancement: java.io.Writer.of(Appendable) as an
 efficient alternative to java.io.StringWriter
In-Reply-To: <1b7d9c21-bfb1-43d1-945d-5d8597000968@headcrashing.eu>
References: <3d41a187-87f5-4a99-80c7-ba0593d4dbc1@headcrashing.eu>
 <CABe8uE2F=bROKVyNTccD7-o7R_8E1cjCKFncMvmtMrXybk3JrA@mail.gmail.com>
 <df49e253-1cea-4d4b-be10-5b5831092219@headcrashing.eu>
 <CABe8uE0Err3uUtkDqMxeVArp0LHKzeSr5k03zFG7VwswwdWZ3A@mail.gmail.com>
 <6ed5af05-6cc8-46ae-8ef4-4dbbc7f410e8@headcrashing.eu>
 <538b0443-bd36-4286-9a5f-cc6c7d161e37@headcrashing.eu>
 <54518836-3ec8-4253-8c6f-0f3670541c9f@oracle.com>
 <ca7582b9-be52-42bd-bb42-71058aec6558@headcrashing.eu>
 <CABe8uE22KZi9egWUCdg_UmKh-75yhSC8+yv9v5vt1NOPnh=zVQ@mail.gmail.com>
 <1b7d9c21-bfb1-43d1-945d-5d8597000968@headcrashing.eu>
Message-ID: <acaf96c3-04ed-4298-8907-b5c38a8d01fa@oracle.com>

On 15/03/2025 17:58, 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)?

I think the main issue with Writer.of(SB) is that the usages would 
requiring hopping between SB, Writer, then back to SB. That is, you 
start accumulating characters in the SB, then wrap it with a Writer to 
write/append characters with a different API, be careful to flush/close 
so that all characters get to the SB, then back to the SB to append more 
before creating the String. That seems a bit fragile and very different 
to the decoration/wrapping when using reader/writers.

You've made it clear that your motivation is performance and avoiding 
the synchronization and internal buffer of StringWriter. I think it 
would be useful if you could expand a bit on the pain points. Maye this 
is about rehabilitating StringWriter or maybe it's about making it 
easier and more efficient to bridge between StringWriter and other 
Appendables. Expanding more on the problem might help to give you some 
suggestions and directions to explore and prototype.

-Alan

From alanb at openjdk.org  Wed May  7 07:01:27 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 May 2025 07:01:27 GMT
Subject: RFR: 8354260: Launcher help text is wrong for -Xms
In-Reply-To: <GNQoFX12jZpR2aUADOyHxNQZLmKb1dvi3-xavm2FcGQ=.fc94ed09-4d39-45f8-bb14-fb9f2041bcc2@github.com>
References: <GNQoFX12jZpR2aUADOyHxNQZLmKb1dvi3-xavm2FcGQ=.fc94ed09-4d39-45f8-bb14-fb9f2041bcc2@github.com>
Message-ID: <W52Firvgt-CmYkqTAaFEZyqN4CrSKITyQWN14SzPVIY=.1b4191b0-3504-4d9e-98d7-02c449c1787a@github.com>

On Tue, 6 May 2025 08:02:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this update to synchronize the extra help text for `-Xms` with the description given in the manpage.
> 
> Copied from the issue:
>> The launcher help text for -Xms is wrong and should be updated to match the manpage description. The actual meaning of -Xms is that it sets both the initial and minimum Java heap size, not just the initial Java heap size.
>>
>> ````
>> $ java -X
>> ...
>> -Xms<size> set initial Java heap size
>> ````
>>
>> From the manpage:
>> ````
>> `-Xms` *size*
>> : Sets the minimum and the initial size (in bytes) of the heap. This value
>>     must be a multiple of 1024 and greater than 1 MB. Append the letter `k` or
>>     `K` to indicate kilobytes, `m` or `M` to indicate megabytes, or `g` or `G`
>>     to indicate gigabytes. The following examples show how to set the size of
>>     allocated memory to 6 MB using various units:
>> ````

I checked java.md to make sure that it doesn't need any update too, all good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25058#issuecomment-2857344128

From cstein at openjdk.org  Wed May  7 07:01:27 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 7 May 2025 07:01:27 GMT
Subject: Integrated: 8354260: Launcher help text is wrong for -Xms
In-Reply-To: <GNQoFX12jZpR2aUADOyHxNQZLmKb1dvi3-xavm2FcGQ=.fc94ed09-4d39-45f8-bb14-fb9f2041bcc2@github.com>
References: <GNQoFX12jZpR2aUADOyHxNQZLmKb1dvi3-xavm2FcGQ=.fc94ed09-4d39-45f8-bb14-fb9f2041bcc2@github.com>
Message-ID: <G9HMhH_Vf3DPRWDsUYSnHurkKwVTQuVYcuqRzUV76Ac=.6d5c39fb-1a8c-4374-a895-9e533b1c1635@github.com>

On Tue, 6 May 2025 08:02:21 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this update to synchronize the extra help text for `-Xms` with the description given in the manpage.
> 
> Copied from the issue:
>> The launcher help text for -Xms is wrong and should be updated to match the manpage description. The actual meaning of -Xms is that it sets both the initial and minimum Java heap size, not just the initial Java heap size.
>>
>> ````
>> $ java -X
>> ...
>> -Xms<size> set initial Java heap size
>> ````
>>
>> From the manpage:
>> ````
>> `-Xms` *size*
>> : Sets the minimum and the initial size (in bytes) of the heap. This value
>>     must be a multiple of 1024 and greater than 1 MB. Append the letter `k` or
>>     `K` to indicate kilobytes, `m` or `M` to indicate megabytes, or `g` or `G`
>>     to indicate gigabytes. The following examples show how to set the size of
>>     allocated memory to 6 MB using various units:
>> ````

This pull request has now been integrated.

Changeset: 910d77d3
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/910d77d39e6fb9ca339272c75fa4ff7ff99bffcf
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8354260: Launcher help text is wrong for -Xms

Reviewed-by: jsikstro, jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/25058

From alanb at openjdk.org  Wed May  7 07:02:42 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 May 2025 07:02:42 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v11]
In-Reply-To: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
References: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
Message-ID: <iIZQ5VxWNxeVTWlKx0_5V1J9JANf9rQsCpZ-BYV8pP8=.08b99c22-969a-4338-bdbb-0c4c107d625a@github.com>

> 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 20 commits:

 - Merge branch 'master' into JDK-8342486
 - Merge branch 'master' into JDK-8342486
 - Merge branch 'master' into JDK-8342486
 - Sync up from loom repo
 - Merge branch 'master' into JDK-8342486
 - Add JEP number, update copyright headers
 - Merge branch 'master' into JDK-8342486
 - Sync up from loom repo
 - Merge branch 'master' into JDK-8342486
 - Sync up from loom repo
 - ... and 10 more: https://git.openjdk.org/jdk/compare/0eb680ca...5fec717f

-------------

Changes: https://git.openjdk.org/jdk/pull/21934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21934&range=10
  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 jbhateja at openjdk.org  Wed May  7 07:03:32 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 7 May 2025 07:03:32 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v5]
In-Reply-To: <huhJ3Yq2fj9CJGBAqQFZxd8i0Wjnwad3moNHymXKyy8=.d64a2532-6bd5-4e58-84ee-18f682d7fe20@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <huhJ3Yq2fj9CJGBAqQFZxd8i0Wjnwad3moNHymXKyy8=.d64a2532-6bd5-4e58-84ee-18f682d7fe20@github.com>
Message-ID: <ItOPWOS6VHofCe7QYcIqnq0yCi-dXfEri_45HgrjfYY=.285d15ff-5b15-4a21-8a7c-1e4cabcc33b2@github.com>

On Wed, 7 May 2025 02:10:56 GMT, erifan <duke at openjdk.org> wrote:

>> This patch optimizes the following patterns:
>> For integer types:
>> 
>> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> 
>> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond.
>> 
>> For float and double types:
>> 
>> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> 
>> cond can be eq or ne.
>> 
>> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`:
>> 
>> Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>> testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>> testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>> testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>> testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>> testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>> testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>> testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>> testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>> testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
>> testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
>> testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
>> testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
>> testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
>> testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
>> testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
>> testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
>> testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
>> testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
>> testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
>> testCompareLTMaskNotInt		ops/s	16721...
>
> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Refactor code
>    
>    Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
>    optimization, making the code more modular.
>  - Merge branch 'master' into JDK-8354242
>  - Update the jtreg test
>  - Merge branch 'master' into JDK-8354242
>  - Addressed some review comments
>    
>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>    2. Improve code comments.
>  - Merge branch 'master' into JDK-8354242
>  - Merge branch 'master' into JDK-8354242
>  - 8354242: VectorAPI: combine vector not operation with compare
>    
>    This patch optimizes the following patterns:
>    For integer types:
>    ```
>    (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>        => (VectorMaskCmp src1 src2 ncond)
>    (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>        => (VectorMaskCmp src1 src2 ncond)
>    ```
>    cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>    negative comparison of cond.
>    
>    For float and double types:
>    ```
>    (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>    (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>    ```
>    cond can be eq or ne.
>    
>    Benchmarks on Nvidia Grace machine with 128-bit SVE2:
>    With option `-XX:UseSVE=2`:
>    ```
>    Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>    testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>    testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>    testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>    testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>    testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>    testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>    testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>    testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>    testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
>    testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4...

src/hotspot/share/opto/vectornode.cpp line 2231:

> 2229:   }
> 2230:   if (in1->Opcode() != Op_VectorMaskCmp || in1->outcnt() > 1 ||
> 2231:       !((VectorMaskCmpNode*) in1)->predicate_can_be_inverted() ||

Do you plan  to extend your testcase /  matching logic to cover following equivalent patterns:

- compare.xor(maskAll(true))
- compare.xor(VectorMask.fromLong(SPECIES, -1L))

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2076939541

From swen at openjdk.org  Wed May  7 07:11:22 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 7 May 2025 07:11:22 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v11]
In-Reply-To: <iIZQ5VxWNxeVTWlKx0_5V1J9JANf9rQsCpZ-BYV8pP8=.08b99c22-969a-4338-bdbb-0c4c107d625a@github.com>
References: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
 <iIZQ5VxWNxeVTWlKx0_5V1J9JANf9rQsCpZ-BYV8pP8=.08b99c22-969a-4338-bdbb-0c4c107d625a@github.com>
Message-ID: <ELnhU-JT9OGqKHJVhTskUCpRa4WFA0QhThLEyrBsZZ0=.509746ab-3331-48fa-89fa-7ffd19d42688@github.com>

On Wed, 7 May 2025 07:02:42 GMT, Alan Bateman <alanb at openjdk.org> 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 20 commits:
> 
>  - Merge branch 'master' into JDK-8342486
>  - Merge branch 'master' into JDK-8342486
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8342486
>  - Add JEP number, update copyright headers
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/0eb680ca...5fec717f

src/java.base/share/classes/java/util/concurrent/StructuredTaskScopeImpl.java line 51:

> 49:     private static final int ST_JOIN_STARTED   = 2;   // join started, can no longer fork
> 50:     private static final int ST_JOIN_COMPLETED = 3;   // join completed
> 51:     private static final int ST_CLOSED         = 4;   // closed

Suggestion:

    private static final int ST_NEW            = 0,
                             ST_FORKED         = 1,   // subtasks forked, need to join
                             ST_JOIN_STARTED   = 2,   // join started, can no longer fork
                             ST_JOIN_COMPLETED = 3,   // join completed
                             ST_CLOSED         = 4;   // closed

This is more readable

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2076953403

From swen at openjdk.org  Wed May  7 07:21:23 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 7 May 2025 07:21:23 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v11]
In-Reply-To: <iIZQ5VxWNxeVTWlKx0_5V1J9JANf9rQsCpZ-BYV8pP8=.08b99c22-969a-4338-bdbb-0c4c107d625a@github.com>
References: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
 <iIZQ5VxWNxeVTWlKx0_5V1J9JANf9rQsCpZ-BYV8pP8=.08b99c22-969a-4338-bdbb-0c4c107d625a@github.com>
Message-ID: <l_GIxbkloPyrjwdsuygZbrM_l9lpILQiSx3y_olNVD8=.b905e03f-3b60-444e-aa58-6b92d1dbf7a6@github.com>

On Wed, 7 May 2025 07:02:42 GMT, Alan Bateman <alanb at openjdk.org> 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 20 commits:
> 
>  - Merge branch 'master' into JDK-8342486
>  - Merge branch 'master' into JDK-8342486
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8342486
>  - Add JEP number, update copyright headers
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/0eb680ca...5fec717f

src/java.base/share/classes/java/util/concurrent/Joiners.java line 84:

> 82:             @SuppressWarnings("unchecked")
> 83:             var s = (Subtask<T>) subtask;
> 84:             subtasks.add(s);

Suggestion:

            subtasks.add((Subtask<T>) subtask);

The local variable s is only used once and can be simplified

src/java.base/share/classes/java/util/concurrent/Joiners.java line 103:

> 101:             } else {
> 102:                 return subtasks.stream();
> 103:             }

Suggestion:

            return subtasks.stream();

The else here is redundant

src/java.base/share/classes/java/util/concurrent/Joiners.java line 155:

> 153:                 case FAILED -> throw subtask.exception();
> 154:                 default -> throw new InternalError();
> 155:             };

Suggestion:

            return switch (subtask.state()) {
                case SUCCESS -> subtask.get();
                case FAILED  -> throw subtask.exception();
                default      -> throw new InternalError();
            };

The switch of the stateToInt method is aligned, so it should also be aligned here to keep the style consistent

src/java.base/share/classes/java/util/concurrent/Joiners.java line 183:

> 181:             } else {
> 182:                 return null;
> 183:             }

Suggestion:

            if (ex != null) {
                throw ex;
            }
            return null;

The else here is redundant

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 820:

> 818:     @PreviewFeature(feature = PreviewFeature.Feature.STRUCTURED_CONCURRENCY)
> 819:     final class TimeoutException extends RuntimeException {
> 820:         @java.io.Serial

Use import without full path

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2076962370
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2076959693
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2076964945
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2076957675
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2076968111

From mbaesken at openjdk.org  Wed May  7 07:23:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 7 May 2025 07:23:16 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <mv1LIyvIryUorv8s6UP5jSqhSqj14dNOUEF4TIpQC84=.fd0a5b7d-4cf1-42ab-bd17-615c6fc913a9@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
 <mv1LIyvIryUorv8s6UP5jSqhSqj14dNOUEF4TIpQC84=.fd0a5b7d-4cf1-42ab-bd17-615c6fc913a9@github.com>
Message-ID: <xu85M14VHYRGCeJ-RrzVxDVp6G6xSshwxjWx245axMo=.2524f3b6-5526-4241-9b4b-bd3195ebb56b@github.com>

On Wed, 16 Apr 2025 10:35:02 GMT, Matthias Baesken <mbaesken at openjdk.org> 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)

> @MBaesken I added an informative text about supported locales. I also lowered the fatal error of missing an UTF-8 locale into just a warning (for all platforms, not just AIX). Apparently it works with building on AIX for now, even with a undefined character encoding, but I will not guarantee that it will continue to work for all eternity. But a warning is probably be enough, and if it does work the user is free to try. :)


Sounds good to me ,  thanks for adjusting !

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24574#discussion_r2076970234

From swen at openjdk.org  Wed May  7 07:24:18 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 7 May 2025 07:24:18 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v11]
In-Reply-To: <iIZQ5VxWNxeVTWlKx0_5V1J9JANf9rQsCpZ-BYV8pP8=.08b99c22-969a-4338-bdbb-0c4c107d625a@github.com>
References: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
 <iIZQ5VxWNxeVTWlKx0_5V1J9JANf9rQsCpZ-BYV8pP8=.08b99c22-969a-4338-bdbb-0c4c107d625a@github.com>
Message-ID: <Xu-saQFXlH-ule-sBNuMYHLDpAPPUkTxRl3RcdBuoNI=.4bc086a0-3a71-4e17-8b45-691bcb29c955@github.com>

On Wed, 7 May 2025 07:02:42 GMT, Alan Bateman <alanb at openjdk.org> 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 20 commits:
> 
>  - Merge branch 'master' into JDK-8342486
>  - Merge branch 'master' into JDK-8342486
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8342486
>  - Add JEP number, update copyright headers
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/0eb680ca...5fec717f

src/java.base/share/classes/java/util/concurrent/StructuredTaskScopeImpl.java line 389:

> 387:                     Throwable ex = ((AltResult) result).exception();
> 388:                     yield "[Failed: " + ex + "]";
> 389:                 }

Suggestion:

            String stateAsString = switch (state()) {
                case UNAVAILABLE -> "[Unavailable]";
                case SUCCESS     -> "[Completed successfully]";
                case FAILED      -> "[Failed: " + ((AltResult) result).exception() + "]";
            };

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2076973064

From vyazici at openjdk.org  Wed May  7 07:29:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 May 2025 07:29:55 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v2]
In-Reply-To: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
Message-ID: <l3xoBLwwsAQrpneEdTdtlnrC7dOit7jokk7wLettH14=.472e261e-894b-44d2-a8cb-c34df74aeb43@github.com>

> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo in pre-existing JavaDoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24982/files
  - new: https://git.openjdk.org/jdk/pull/24982/files/ef88b10a..f0623258

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24982.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24982/head:pull/24982

PR: https://git.openjdk.org/jdk/pull/24982

From vyazici at openjdk.org  Wed May  7 07:29:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 May 2025 07:29:55 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v2]
In-Reply-To: <l3xoBLwwsAQrpneEdTdtlnrC7dOit7jokk7wLettH14=.472e261e-894b-44d2-a8cb-c34df74aeb43@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <l3xoBLwwsAQrpneEdTdtlnrC7dOit7jokk7wLettH14=.472e261e-894b-44d2-a8cb-c34df74aeb43@github.com>
Message-ID: <vvhGJycAKaABHPiX4k7vPYDFIh2NUNE-V-KxaZu9E2w=.97ed13c7-2039-4759-898e-1b1158889822@github.com>

On Wed, 7 May 2025 07:26:56 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in pre-existing JavaDoc

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 314:

> 312:      * <p>
> 313:      * <b>WARNING: The caller of this method shall relinquish and transfer the
> 314:      * ownership of the byte array to the callee</b>, since the later will not

Suggestion:

     * ownership of the byte array to the callee</b>, since the latter will not

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2076979439

From vyazici at openjdk.org  Wed May  7 07:29:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 May 2025 07:29:55 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v2]
In-Reply-To: <vn_pxxNKegLNvZ6QZXLLDws2ytOlYCTxAsvzW0a1rWs=.06ac1d03-dfa4-4d08-b2f5-e5c44dff0c71@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <vn_pxxNKegLNvZ6QZXLLDws2ytOlYCTxAsvzW0a1rWs=.06ac1d03-dfa4-4d08-b2f5-e5c44dff0c71@github.com>
Message-ID: <lTNW0SWK69sxR2krC7avL-PTWIPqRMNSBzjyWXl-jus=.a70dad48-c0a8-4f73-9b71-b8151ca881eb@github.com>

On Fri, 2 May 2025 14:39:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in pre-existing JavaDoc
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 314:
> 
>> 312:      * <p>
>> 313:      * <b>WARNING: The caller of this method shall relinquish and transfer the
>> 314:      * ownership of the byte array to the callee</b>, since the later will not
> 
> Typo:  "later" -> "latter". (pre-existing)

Fixed in f0623258e0506c68a274a1e094039bd6d76e3fa6.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2076980772

From vyazici at openjdk.org  Wed May  7 07:33:14 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 May 2025 07:33:14 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v2]
In-Reply-To: <dhJZfbBsKnkyOi4h8J6nOB1AhhAc67pZp82cB_Rr6Jk=.916994a4-0557-4043-b725-8c023272d76f@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <dhJZfbBsKnkyOi4h8J6nOB1AhhAc67pZp82cB_Rr6Jk=.916994a4-0557-4043-b725-8c023272d76f@github.com>
Message-ID: <7Tq127ca8kJ6NdghXUbeFL5cT4HC7dEe9-0ySUirpy8=.999f9f7c-2118-4d4a-83c1-d67fb006a2e4@github.com>

On Thu, 1 May 2025 13:00:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in pre-existing JavaDoc
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 315:
> 
>> 313:      * <b>WARNING: The caller of this method shall relinquish and transfer the
>> 314:      * ownership of the byte array to the callee</b>, since the later will not
>> 315:      * make a copy.
> 
> I think we should add a note on why no copy is made - there may be multiple reads to the input array for decoding, so the input array must not be accessible by untrusted code, which can racily modify it. A side effect is that this array is simply reused if it's eligible to be the string content array, which is unfortunately abused in a few places in the JDK.

@liach, thank you so much for the review and the feedback. We internally discussed this and decided leave the change as is. Resolving this conversation. Please let me know if you think otherwise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2076985931

From swen at openjdk.org  Wed May  7 07:37:18 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 7 May 2025 07:37:18 GMT
Subject: RFR: 8341184: Clean up the interaction between the launcher native
 code and the LauncherHelper [v16]
In-Reply-To: <JHBC_-2uIDzTy40hi2OfmFH2-eh_XXtZrgpgiQIxd3U=.5e271baf-04ca-4eaf-b51c-c85b9248fd40@github.com>
References: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
 <JHBC_-2uIDzTy40hi2OfmFH2-eh_XXtZrgpgiQIxd3U=.5e271baf-04ca-4eaf-b51c-c85b9248fd40@github.com>
Message-ID: <nFCLkc0TaSpNqcdPbxsVET3CYK6ZHsTg0Eu4jRIoHPM=.e4ef4036-6e4a-4ee8-bb09-0891b79b4505@github.com>

On Mon, 24 Feb 2025 09:46:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change, which simplifies the interaction between the `java` launcher's native code with the `sun.launcher.LauncherHelper`? 
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8341184, this proposed change reduces the back and forth between the launcher's native code and the `LauncherHelper` class. This also removes the additional reflective lookups from the native code after the main class and main method have been determined by the `LauncherHelper`. 
>> 
>> Although this is a clean up of the code, the changes in the `LauncherHelper` to return a `MainEntry` have been done in a way to facilitate additional upcoming changes in this area, which propose to get rid of the JAR manifest parsing from the launcher's native code.
>> 
>> No new tests have been added. Existing tests in tier1, tier2 and tier3 continue to pass.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/e410af00...d1ac5174

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 946:

> 944:                         JAVAFX_APPLICATION_CLASS_NAME);
> 945:             }
> 946:         }

Suggestion:

        if (!PreviewFeatures.isEnabled()) {
            int mods = mainMethod.getModifiers();
            if (!Modifier.isStatic(mods) || !Modifier.isPublic(mods) || mainMethod.getParameterCount() == 0) {
                abort(null, "java.launcher.cls.error2", builder.mainClass.getName(),
                        JAVAFX_APPLICATION_CLASS_NAME);
            }
        }

Remove variables that are only used once

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21256#discussion_r2076992705

From alanb at openjdk.org  Wed May  7 07:40:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 May 2025 07:40:14 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v2]
In-Reply-To: <l3xoBLwwsAQrpneEdTdtlnrC7dOit7jokk7wLettH14=.472e261e-894b-44d2-a8cb-c34df74aeb43@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <l3xoBLwwsAQrpneEdTdtlnrC7dOit7jokk7wLettH14=.472e261e-894b-44d2-a8cb-c34df74aeb43@github.com>
Message-ID: <vMVnGmw2Bg2qgbUiwI3yf2ky-L2DnIAOP6umt2Q2Tig=.04bb10da-692f-4be6-a0a1-ded8761d4b01@github.com>

On Wed, 7 May 2025 07:29:55 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in pre-existing JavaDoc

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 302:

> 300:      * <b>WARNING: This method does not perform any bound checks.</b>
> 301:      */
> 302:     int countPositives(byte[] ba, int off, int len);

Maybe we should change countPositives to do a bounds check and have a private method in StringCoding be the `@IntrinsicCandidate`. This would make it easier to audit. Right now it's hard to audit because there are usages of JLA.countPositives in faraway classes. I'm not suggested we do this as part of this PR of course but it would mean the warning comment could be removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2076997921

From pminborg at openjdk.org  Wed May  7 07:46:45 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 07:46:45 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v3]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <0zZ3FP80ivgauWazM5q4CdiLvcla2NFqSmKWB5wh-f8=.3ee0935f-87f6-4e9a-acd6-7e506c2965c0@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add a method handle based field updater

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/52e96c52..83ce9ac1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=01-02

  Stats: 95 lines in 2 files changed: 95 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040

PR: https://git.openjdk.org/jdk/pull/25040

From alanb at openjdk.org  Wed May  7 07:55:16 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 May 2025 07:55:16 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v2]
In-Reply-To: <l3xoBLwwsAQrpneEdTdtlnrC7dOit7jokk7wLettH14=.472e261e-894b-44d2-a8cb-c34df74aeb43@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <l3xoBLwwsAQrpneEdTdtlnrC7dOit7jokk7wLettH14=.472e261e-894b-44d2-a8cb-c34df74aeb43@github.com>
Message-ID: <CFt4DC6En9ErWBA__-tbOItlFmaXYN-rAvmaUfj-UzM=.60937a93-f095-47e6-ae63-aa89a1ac2e5f@github.com>

On Wed, 7 May 2025 07:29:55 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in pre-existing JavaDoc

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 332:

> 330:      * <p>
> 331:      * This method throws {@code CharacterCodingException} instead of replacing
> 332:      * when malformed input or unmappable characters are encountered.

Do we have a JBS issue to track renaming the "no replacement" methods? The naming has confused several people as not everyone is familiar with coding error actions.  Here, "no replacement" actually means that coding errors are reported.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2077022991

From pminborg at openjdk.org  Wed May  7 07:56:48 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 07:56:48 GMT
Subject: RFR: 8356114: java/foreign/TestBufferStackStress2.java failed with
 junit action timed out
Message-ID: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com>

This PR proposes to skip a stress test if the `main` thread is a virtual thread.

-------------

Commit messages:
 - Skip stress if main is a virtual thread

Changes: https://git.openjdk.org/jdk/pull/25084/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25084&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356114
  Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25084.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25084/head:pull/25084

PR: https://git.openjdk.org/jdk/pull/25084

From duke at openjdk.org  Wed May  7 07:57:19 2025
From: duke at openjdk.org (erifan)
Date: Wed, 7 May 2025 07:57:19 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v5]
In-Reply-To: <ItOPWOS6VHofCe7QYcIqnq0yCi-dXfEri_45HgrjfYY=.285d15ff-5b15-4a21-8a7c-1e4cabcc33b2@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <huhJ3Yq2fj9CJGBAqQFZxd8i0Wjnwad3moNHymXKyy8=.d64a2532-6bd5-4e58-84ee-18f682d7fe20@github.com>
 <ItOPWOS6VHofCe7QYcIqnq0yCi-dXfEri_45HgrjfYY=.285d15ff-5b15-4a21-8a7c-1e4cabcc33b2@github.com>
Message-ID: <Mni1X8gJrsj7to1bOryw7nhO-JxoS-Xyn1Bcyqfg1jQ=.09715eb2-b4aa-4aa6-af34-4b535a21669e@github.com>

On Wed, 7 May 2025 06:59:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Refactor code
>>    
>>    Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
>>    optimization, making the code more modular.
>>  - Merge branch 'master' into JDK-8354242
>>  - Update the jtreg test
>>  - Merge branch 'master' into JDK-8354242
>>  - Addressed some review comments
>>    
>>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>>    2. Improve code comments.
>>  - Merge branch 'master' into JDK-8354242
>>  - Merge branch 'master' into JDK-8354242
>>  - 8354242: VectorAPI: combine vector not operation with compare
>>    
>>    This patch optimizes the following patterns:
>>    For integer types:
>>    ```
>>    (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    ```
>>    cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>>    negative comparison of cond.
>>    
>>    For float and double types:
>>    ```
>>    (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    ```
>>    cond can be eq or ne.
>>    
>>    Benchmarks on Nvidia Grace machine with 128-bit SVE2:
>>    With option `-XX:UseSVE=2`:
>>    ```
>>    Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>>    testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>>    testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>>    testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>>    testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>>    testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>>    testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>>    testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>>    testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>>    testCompareGEMaskNotLong	ops/s	854496.156...
>
> src/hotspot/share/opto/vectornode.cpp line 2231:
> 
>> 2229:   }
>> 2230:   if (in1->Opcode() != Op_VectorMaskCmp || in1->outcnt() > 1 ||
>> 2231:       !((VectorMaskCmpNode*) in1)->predicate_can_be_inverted() ||
> 
> Do you plan  to extend your testcase /  matching logic to cover following equivalent patterns:
> 
> - compare.xor(maskAll(true))
> - compare.xor(VectorMask.fromLong(SPECIES, -1L))

Oh, I didn't think of this case, let me try. Thanks~

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2077026150

From swen at openjdk.org  Wed May  7 08:00:23 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 7 May 2025 08:00:23 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v3]
In-Reply-To: <0zZ3FP80ivgauWazM5q4CdiLvcla2NFqSmKWB5wh-f8=.3ee0935f-87f6-4e9a-acd6-7e506c2965c0@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <0zZ3FP80ivgauWazM5q4CdiLvcla2NFqSmKWB5wh-f8=.3ee0935f-87f6-4e9a-acd6-7e506c2965c0@github.com>
Message-ID: <dvvQb7iTnkNcpU146Tg6Yei9pOYyAueOpdekwHkunRk=.83d69bc7-022d-4b50-b868-ee3768d90d3a@github.com>

On Wed, 7 May 2025 07:46:45 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a method handle based field updater

src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 173:

> 171:         if (!underlying.type().parameterType(0).equals(Object.class)) {
> 172:             underlying = underlying.asType(underlying.type().changeParameterType(0, Object.class));
> 173:         }

Suggestion:

        var type = underlying.type();
        if (type.returnType() != int.class || type.parameterCount() != 1) {
            throw new IllegalArgumentException("Illegal underlying function: " + underlying);
        }
        if (!type.parameterType(0).equals(Object.class)) {
            underlying = underlying.asType(type.changeParameterType(0, Object.class));
        }

underlying.type() is used 4 times, local variables should be used

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077031643

From djelinski at openjdk.org  Wed May  7 08:03:18 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 7 May 2025 08:03:18 GMT
Subject: RFR: 8356114: java/foreign/TestBufferStackStress2.java failed with
 junit action timed out
In-Reply-To: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com>
References: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com>
Message-ID: <ReXs87UgQPDnxkDDJPX4aRcBcQLKPJ83F9XMx9ZPXP4=.bb5f02a7-164c-408a-94d2-089bf2981d45@github.com>

On Wed, 7 May 2025 07:52:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to skip a stress test if the `main` thread is a virtual thread.

test/jdk/java/foreign/TestBufferStackStress2.java line 69:

> 67:         // this stress test will not work as the main thread is always alive causing
> 68:         // us to wait forever for contraction.
> 69:         // Hence, we will skipp this test if the main thread is virtual.

Suggestion:

        // Hence, we will skip this test if the main thread is virtual.

test/jdk/java/foreign/TestBufferStackStress2.java line 70:

> 68:         // us to wait forever for contraction.
> 69:         // Hence, we will skipp this test if the main thread is virtual.
> 70:         if (Thread.currentThread().isVirtual()) {

Suggestion:

        Assumptions.assumeFalse(Thread.currentThread().isVirtual(), "Skipped because the main thread is a virtual thread");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25084#discussion_r2077033646
PR Review Comment: https://git.openjdk.org/jdk/pull/25084#discussion_r2077034970

From alanb at openjdk.org  Wed May  7 08:03:19 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 May 2025 08:03:19 GMT
Subject: RFR: 8356114: java/foreign/TestBufferStackStress2.java failed with
 junit action timed out
In-Reply-To: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com>
References: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com>
Message-ID: <GNRTrW6E7JyiMJW2P3XxYwKpzRWHJVreLbnAqxWjYIU=.56d554df-9420-48a6-94b5-5f5b544d7f74@github.com>

On Wed, 7 May 2025 07:52:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to skip a stress test if the `main` thread is a virtual thread.

test/jdk/java/foreign/TestBufferStackStress2.java line 73:

> 71:             System.out.println("Skipped because the main thread is a virtual thread");
> 72:             return;
> 73:         }

This is okay. An alternative that we use in a few other tests is to use the Assumptions API t, e.g. assumeFalse(Thread.currentThread().isVirtual(), "message").

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25084#discussion_r2077037194

From jpai at openjdk.org  Wed May  7 08:05:14 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 May 2025 08:05:14 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v2]
In-Reply-To: <l3xoBLwwsAQrpneEdTdtlnrC7dOit7jokk7wLettH14=.472e261e-894b-44d2-a8cb-c34df74aeb43@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <l3xoBLwwsAQrpneEdTdtlnrC7dOit7jokk7wLettH14=.472e261e-894b-44d2-a8cb-c34df74aeb43@github.com>
Message-ID: <oh1gWfG4LB8B0eGo6tDHz6CCh9h0Fv_KQi5WrsHPsJg=.5a141b2b-37f2-4cf6-b5d1-77c41eb95979@github.com>

On Wed, 7 May 2025 07:29:55 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in pre-existing JavaDoc

Hello Volkan, I checked with others on how to make it prominent, when reading code and when reviewing changes to code, that the usage of these methods needs extra careful attention.

In addition to updating the javadoc of these methods, we came to an agreement that each of these methods should be updated to have `unchecked` as the prefix in their method names. For example,  renaming `countPositives(...)` to `uncheckedCountPositives(...)`. Even though it means a few additional characters to the method names, this should help catch attention wherever these methods get used.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24982#issuecomment-2857500353

From alanb at openjdk.org  Wed May  7 08:05:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 May 2025 08:05:15 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v2]
In-Reply-To: <l3xoBLwwsAQrpneEdTdtlnrC7dOit7jokk7wLettH14=.472e261e-894b-44d2-a8cb-c34df74aeb43@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <l3xoBLwwsAQrpneEdTdtlnrC7dOit7jokk7wLettH14=.472e261e-894b-44d2-a8cb-c34df74aeb43@github.com>
Message-ID: <9IfMW-HLFSI8eeAfs6m3jZyfpzGRhnutoTgYFripC4U=.f84019f8-30d4-43ce-857a-6f3d71bfd713@github.com>

On Wed, 7 May 2025 07:29:55 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in pre-existing JavaDoc

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 355:

> 353:      * UTF-16 representation.
> 354:      * <p>
> 355:      * <b>WARNING: This method does not perform any bound checks.</b>

Maybe not this PR but this method is begging to be renamed. It's really hard to audit usage when the method is accessible to faraway code via shared secrets. So maybe not this PR but I think we need an issue in JBS to track renaming, I think Stuart suggested prefixing with "unchecked".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2077039719

From mbaesken at openjdk.org  Wed May  7 08:17:21 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 7 May 2025 08:17:21 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v5]
In-Reply-To: <Jb7VOfKdtOj2kvoGjgBsmb-J31uB_FHlkLY_ulG1um4=.7027776d-c936-4ff7-9afc-7e91ca110d21@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Jb7VOfKdtOj2kvoGjgBsmb-J31uB_FHlkLY_ulG1um4=.7027776d-c936-4ff7-9afc-7e91ca110d21@github.com>
Message-ID: <NvIKz3MmweON_wbHZOzy5CM3s6EQWn0C_mbsY2aSzA4=.3463dd3e-8893-488f-84b3-86752610560f@github.com>

On Tue, 6 May 2025 15:39:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into go-full-utf8
>  - Add informative message  about supported locales.
>  - Allow C locale with warning instead of fatal error
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim
>  - Also tell javadoc that we have utf-8 now
>  - Fix flags for Windows
>  - Mark java and native source code as utf-8
>  - Don't convert properties files to iso-8859-1.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/747c59ad...bea19a70

Marked as reviewed by mbaesken (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2820807425

From mdoerr at openjdk.org  Wed May  7 08:17:22 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 7 May 2025 08:17:22 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v5]
In-Reply-To: <Jb7VOfKdtOj2kvoGjgBsmb-J31uB_FHlkLY_ulG1um4=.7027776d-c936-4ff7-9afc-7e91ca110d21@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Jb7VOfKdtOj2kvoGjgBsmb-J31uB_FHlkLY_ulG1um4=.7027776d-c936-4ff7-9afc-7e91ca110d21@github.com>
Message-ID: <iRorxVeBIUdj16jxRIY6oUOmpyViZLwLp9aNWRNtLFo=.58a7cf19-9891-4fb6-9cc1-413fb0d10a3b@github.com>

On Tue, 6 May 2025 15:39:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into go-full-utf8
>  - Add informative message  about supported locales.
>  - Allow C locale with warning instead of fatal error
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim
>  - Also tell javadoc that we have utf-8 now
>  - Fix flags for Windows
>  - Mark java and native source code as utf-8
>  - Don't convert properties files to iso-8859-1.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/747c59ad...bea19a70

@sxa I guess UTF-8 locales will need to be documented for Adoptium AIX build requirements, too, when this change goes in.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2857536070

From pminborg at openjdk.org  Wed May  7 08:18:55 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 08:18:55 GMT
Subject: RFR: 8356114: java/foreign/TestBufferStackStress2.java failed with
 junit action timed out [v2]
In-Reply-To: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com>
References: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com>
Message-ID: <5sqR7qp4X4elVJwtAmtQi72cvDGh9azfT-6rnahuy6s=.b53b3c1b-eee4-493c-83a6-96d78f18cb51@github.com>

> This PR proposes to skip a stress test if the `main` thread is a virtual thread.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Update test/jdk/java/foreign/TestBufferStackStress2.java
   
   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
 - Update test/jdk/java/foreign/TestBufferStackStress2.java
   
   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25084/files
  - new: https://git.openjdk.org/jdk/pull/25084/files/6ee12db8..39bbc360

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25084&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25084&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25084.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25084/head:pull/25084

PR: https://git.openjdk.org/jdk/pull/25084

From pminborg at openjdk.org  Wed May  7 08:21:15 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 08:21:15 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v3]
In-Reply-To: <GoVjQ_q86ONHLp7dioqHSFXL5BWVPz4LATUGBuhoUWs=.f771947f-5b13-4d53-ac72-0f539fe7abc0@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <8lHsFNYOMDGU0YGxZ8Yqr7iswXNhT6hREMe1dpFtQF8=.cfb4b7e5-54eb-4a85-87f9-c0df5a0ed541@github.com>
 <kdQ0cQYPOnJu1nON4BYTube75JfjVWp-2CfsPfz2AU8=.f1fe7acf-a054-4e19-b51f-51e092daef39@github.com>
 <qGh4TxJ7MIudua-Xk4iMx354D_QLCN1in8u2G0qk4F0=.c6e77625-0a27-4876-99e6-49431ad78798@github.com>
 <Rp5KEWwo32Q1xji7MPrEXzdLwOPRwFBqwBfyP4GviuA=.1dc73cc9-550f-4a1b-ac03-34a2fb302af1@github.com>
 <GoVjQ_q86ONHLp7dioqHSFXL5BWVPz4LATUGBuhoUWs=.f771947f-5b13-4d53-ac72-0f539fe7abc0@github.com>
Message-ID: <ceepU3nsD2RBswsMXwF8m-z8-Ghaz6xNFN-HqZo1620=.23e5f34b-ccb6-4e72-a2ab-4aa3259f0458@github.com>

On Wed, 7 May 2025 03:05:31 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> enhanced 'switch' is just syntax sugar and does not affect startup speed
>
> I looked at the generated bytecode through javap and confirmed that the enhanced switch is just syntactic sugar and no additional classes are generated.

Thanks for clarifying this @wenshao ! I will go ahead and make the changes proposed by you here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2077073780

From pminborg at openjdk.org  Wed May  7 08:30:28 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 08:30:28 GMT
Subject: RFR: 8356114: java/foreign/TestBufferStackStress2.java failed with
 junit action timed out [v3]
In-Reply-To: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com>
References: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com>
Message-ID: <zIRQgngGZNfqnx8mAgBGLaLFa9m0XzExPr4z4K0Vtc8=.b28785c4-4d65-4082-9383-380c0417da05@github.com>

> This PR proposes to skip a stress test if the `main` thread is a virtual thread.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup merges

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25084/files
  - new: https://git.openjdk.org/jdk/pull/25084/files/39bbc360..5aeb01af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25084&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25084&range=01-02

  Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25084.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25084/head:pull/25084

PR: https://git.openjdk.org/jdk/pull/25084

From mli at openjdk.org  Wed May  7 08:36:15 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 7 May 2025 08:36:15 GMT
Subject: RFR: 8355698: JDK not supporting sleef could cause exception at
 runtime after JDK-8353786
In-Reply-To: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
Message-ID: <nRHndw3Ziw8wZk_pJxt0VzcOtG31HN4gRr3QvVCGmro=.a6923528-f357-43bd-bd5a-3036ae94ed52@github.com>

On Mon, 28 Apr 2025 10:34:49 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> 
> Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a released jdk not supportting sleef (for any reason, e.g. low gcc version, intrinsic not supported, rvv not supported, and so on) runs on machine support vector operation (e.g. on riscv, it supports rvv), it can not call into sleef, but will not fail either, it falls back to java scalar version implementation.
> But after [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), it will cause an exception thrown at runtime.
> 
> This change the behaviour of existing jdk, and it should not throw exception anyway.
> 
> @iwanowww @RealFYang 
> 
> Thanks!

Thanks, I'll check it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2857667370

From djelinski at openjdk.org  Wed May  7 08:37:24 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 7 May 2025 08:37:24 GMT
Subject: RFR: 8356114: java/foreign/TestBufferStackStress2.java failed with
 junit action timed out [v3]
In-Reply-To: <zIRQgngGZNfqnx8mAgBGLaLFa9m0XzExPr4z4K0Vtc8=.b28785c4-4d65-4082-9383-380c0417da05@github.com>
References: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com>
 <zIRQgngGZNfqnx8mAgBGLaLFa9m0XzExPr4z4K0Vtc8=.b28785c4-4d65-4082-9383-380c0417da05@github.com>
Message-ID: <mEIgRG11rXOTdldKpefyPuYIPoORf0OaxRSxmphUOJc=.d623daff-7f60-4366-a3bc-ba2823bb0954@github.com>

On Wed, 7 May 2025 08:30:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to skip a stress test if the `main` thread is a virtual thread.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup merges

LGTM.

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25084#pullrequestreview-2820883237

From pminborg at openjdk.org  Wed May  7 08:48:53 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 08:48:53 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v5]
In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
Message-ID: <X5q2MOXir_uZXH0-qGlq7LTzUzYlPvhMFPQdxIyrU7E=.1f1023b1-226b-4f15-b4ca-733139fdac61@github.com>

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits:

 - Simplify equals method
 - Use modern switch
 - Merge branch 'master' into errno-util3b
 - Address comments
 - Fix empty line at the end of a third file
 - Fix empty line at the end of another file
 - Fix empty line at the end of a file
 - Reformat more
 - Reformat
 - Use stable values
 - ... and 38 more: https://git.openjdk.org/jdk/compare/21f01e0c...f9511b88

-------------

Changes: https://git.openjdk.org/jdk/pull/25043/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=04
  Stats: 818 lines in 9 files changed: 804 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25043/head:pull/25043

PR: https://git.openjdk.org/jdk/pull/25043

From pminborg at openjdk.org  Wed May  7 08:54:43 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 08:54:43 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v6]
In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
Message-ID: <F8RBMzTtsq9FOypmIvv81VNwj442aoTSxdkU5Ce8jvc=.f2dc937e-a540-4dd7-ae78-1e2f7109f85c@github.com>

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Simplify

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25043/files
  - new: https://git.openjdk.org/jdk/pull/25043/files/f9511b88..e435762b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25043/head:pull/25043

PR: https://git.openjdk.org/jdk/pull/25043

From pminborg at openjdk.org  Wed May  7 08:54:44 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 08:54:44 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v4]
In-Reply-To: <xASnVm_w4dvoU3nVzizAg9p1MkDhDb30JudBx3FTrOA=.29075706-30b8-4c38-a505-844d1401b653@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <Av9w-CHHrUGeABiUbfvlhVCfJtqKyQELdTIwbsCVNf0=.6dc0ed4b-ab3c-42fd-afdd-9539d8072d23@github.com>
 <xASnVm_w4dvoU3nVzizAg9p1MkDhDb30JudBx3FTrOA=.29075706-30b8-4c38-a505-844d1401b653@github.com>
Message-ID: <Gxxp_vscR3Rwyx0mHYL1qdGJKGMAk1UzgWAdq4w6loY=.ade050d9-a71b-435f-bde7-4adb91174088@github.com>

On Wed, 7 May 2025 03:19:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments
>
> src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 78:
> 
>> 76:                 inputs.add(new BasicKey(c, layout.name().orElseThrow()));
>> 77:             }
>> 78:         }
> 
> Suggestion:
> 
>         for (MemoryLayout layout : CAPTURE_LAYOUT.memberLayouts()) {
>             String name = layout.name().orElseThrow();
>             inputs.add(new BasicKey(int.class, name));
>             inputs.add(new BasicKey(long.class, name));
>         }
> 
> There are only two classes, int.class and long.class, so this might be simpler.

I like the existing code better, but I'll guess that is a matter of taste.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2077145341

From asotona at openjdk.org  Wed May  7 08:55:15 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 7 May 2025 08:55:15 GMT
Subject: RFR: 8355775: Improve symbolic sharing in dynamic constant pool
 entries
In-Reply-To: <Uc29vIFCqWGt5qG78EKk7-GWz0Ur2axVtZOwgu10pv4=.348a21ca-ae61-49ee-a035-b4252b3d2c56@github.com>
References: <Uc29vIFCqWGt5qG78EKk7-GWz0Ur2axVtZOwgu10pv4=.348a21ca-ae61-49ee-a035-b4252b3d2c56@github.com>
Message-ID: <b1aDIoCoM1Sn5ck9-tiD1tXzB1MiLoypzSTXzm9u1-o=.bc4d5f6d-928d-4a80-8995-2ac7c7420a62@github.com>

On Mon, 28 Apr 2025 20:50:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> Some dynamic constant pool entries with heavy symbolic descriptors currently don't share them, yet they are used by stack map generation, and computing a new descriptor every time introduces a heavy cost.
> 
> This cost is obvious if bytecode generation uses constant dynamic - the stack map generator parses the whole dynamic constant symbol to interpret the return type of an ldc condy, such as in FFM downcalls.
> 
> Both the lack of expensive symbol caching in dynamic cp entries and the incorrect query in StackMapGenerator should be fixed.

Looks reasonable to me.
Is it visible in some benchmark numbers?

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24938#pullrequestreview-2820956106

From alanb at openjdk.org  Wed May  7 09:02:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 May 2025 09:02:14 GMT
Subject: RFR: 8356114: java/foreign/TestBufferStackStress2.java failed with
 junit action timed out [v3]
In-Reply-To: <zIRQgngGZNfqnx8mAgBGLaLFa9m0XzExPr4z4K0Vtc8=.b28785c4-4d65-4082-9383-380c0417da05@github.com>
References: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com>
 <zIRQgngGZNfqnx8mAgBGLaLFa9m0XzExPr4z4K0Vtc8=.b28785c4-4d65-4082-9383-380c0417da05@github.com>
Message-ID: <USAytewXqizHILrYfiXaOg8EicsdCM0hrSdtzPYIv-Q=.228d58a2-43cf-488b-8a1e-7381c8660568@github.com>

On Wed, 7 May 2025 08:30:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to skip a stress test if the `main` thread is a virtual thread.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup merges

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25084#pullrequestreview-2820982351

From pminborg at openjdk.org  Wed May  7 09:15:17 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 09:15:17 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v2]
In-Reply-To: <9CHAvFJuNMdvc-UdKIhL9Bv1vDU3m30YZARCta1LETc=.b4b95bbd-5b70-4a6a-bc7a-196344812610@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <dPNU_d4_dn_kdgjRtmQIY9kQJai2T5AeRwaxjJEqdEE=.aaf0100b-cbb0-40ff-b321-3a260fccef6b@github.com>
 <9CHAvFJuNMdvc-UdKIhL9Bv1vDU3m30YZARCta1LETc=.b4b95bbd-5b70-4a6a-bc7a-196344812610@github.com>
Message-ID: <6mGpPA6jay-y2UOlU6MWj6Od8MoFs6NL9YRcImf4mf0=.eec82983-2964-47ac-b200-1defe79f4d0d@github.com>

On Tue, 6 May 2025 15:34:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix raw long updater under 32-bit mode
>
> src/java.base/share/classes/java/net/URI.java line 558:
> 
>> 556: 
>> 557:     // Used reflectively by HASH_UPDATER
>> 558:     @Stable
> 
> What are the effect of this change on startup time? I remember that @cl4es made a number of changes to URI to improve startup. Maybe this change should be dropped out of this PR for now.

Yes. I think we should remove these public changes and maybe come back in a separate PR with those.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077189936

From pminborg at openjdk.org  Wed May  7 09:15:22 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 09:15:22 GMT
Subject: Integrated: 8356114: java/foreign/TestBufferStackStress2.java failed
 with junit action timed out
In-Reply-To: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com>
References: <7MmKx2bcFuAe7P8xua6-yUhBDaHIgTs34slPiItAaRU=.cfcc0548-366f-43f1-80ab-10505a5497d0@github.com>
Message-ID: <YFnBe755gjcPcvVHAc0ppc3uPPalE1IKV9eT2S27poU=.bb16b470-c83e-4a5f-b70f-6eb1a339a853@github.com>

On Wed, 7 May 2025 07:52:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to skip a stress test if the `main` thread is a virtual thread.

This pull request has now been integrated.

Changeset: 1bdff3cc
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1bdff3ccd069142e21c8b0a9ecf759b82302a2d2
Stats:     9 lines in 1 file changed: 9 ins; 0 del; 0 mod

8356114: java/foreign/TestBufferStackStress2.java failed with junit action timed out

Reviewed-by: djelinski, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25084

From pminborg at openjdk.org  Wed May  7 09:23:45 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 09:23:45 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v4]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <bbIIjNufb8B7cXMueePzk44qVT5JYT6RZjf_0_p_5zk=.29bc910c-c768-4475-980e-fa303f0e87c1@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Reformat
 - Revert changes in public classes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/83ce9ac1..4a42b271

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=02-03

  Stats: 62 lines in 2 files changed: 17 ins; 37 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/25040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040

PR: https://git.openjdk.org/jdk/pull/25040

From aph at openjdk.org  Wed May  7 09:28:19 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 7 May 2025 09:28:19 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v3]
In-Reply-To: <H3vvJxVRsOzXpLIAnz2vc3wU_Umd9IoyI1cgqYT6mq0=.79b289da-60f2-4f62-99bd-227e03e9df2b@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <H3vvJxVRsOzXpLIAnz2vc3wU_Umd9IoyI1cgqYT6mq0=.79b289da-60f2-4f62-99bd-227e03e9df2b@github.com>
Message-ID: <m-sqt9KlVF_WJ5Plh4_nJaia7LTBpzHkO8svt7mcisw=.2ffba1c6-a433-41e3-8a7f-b33ff874b472@github.com>

On Tue, 6 May 2025 21:45:34 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs.
>> 
>> | Input range(s)                                  | Throughput with baseline (op/s) | Throughput with intrinsic (op/s) | Speedup |
>> | :-------------------------------------: | :----------------------------------: | :----------------------------------: | :---------: |
>> | [-2^(-1022), 2^(-1022)]                   | 6568                                             | 17678                                          | 2.69x       |
>> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932                                         | 200897                                        | 1.45x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add new set of cbrt micro-benchmarks

src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp line 62:

> 60: {
> 61:     0, 3220193280
> 62: };

What is this constant?

Its value is 0xbff0400000000000, which is -ve bit set, bias (top bit of exponent) clear, but one of the bits in the fraction is set. So its value is -0x1.04p+0. As well as the exponent it also sets the 1 bit, just below the 5 most significant bits of the fraction. I guess this in effect rounds up the value that is added in the final rounding.

Is that right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2077214995

From duke at openjdk.org  Wed May  7 09:29:23 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 7 May 2025 09:29:23 GMT
Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2]
In-Reply-To: <KSLx3-ce2qLb74qQKBquuJqWRxYk0bAW2o3SJxrgvM0=.d96e1a7a-23e5-4d29-8657-1e08084dcb86@github.com>
References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
 <OQFS9tEyTK4cXqq9upD-EH8-B3H_LB0nfBAHkW-daXk=.fd5763c2-a86d-4b0b-9857-c8a70542ad31@github.com>
 <KSLx3-ce2qLb74qQKBquuJqWRxYk0bAW2o3SJxrgvM0=.d96e1a7a-23e5-4d29-8657-1e08084dcb86@github.com>
Message-ID: <NvU3PoU1SYtAczVy3B1VXaKPJQn5wPSAbGdGCbQGEd8=.bb201980-3f2f-41ac-8b7b-def0a32b3780@github.com>

On Tue, 6 May 2025 21:54:59 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> We must remember that the OpenJDK community is built by individuals with different backgrounds and motivations to engaging. Some people get paid to work on OpenJDK development, others do it in their own time. It would be next to impossible to dictate any kinds of rules to enforce engagement from reviewers as this would require companies and individuals to commit to prioritizing issues that may not be in their interest to spend time on.
> 
> Any kind of "if you engage in a discussion you must reply within X weeks" will most likely only result in less people engaging in the first place.

I *am* on of those unpaid fellows, actually. Sure, we are not the project police, and it is not about *controlling* people, but what I meant is that if we enforce "broad agreement" *piror* to a PR, then we MUST tell those people that they SHOULD react *prior* to the PR. Actually, currently many of them do not respond at all, even if they like to have a feature, as they think "I will chime in once the PR is there" (this is my recognized experience with my last PRs). So when you hold me back from PRs, the other side of the medal is that you tell all those people that they cannot wait for the PR anymore, but they MUST send at least "+1" or "proceed with PR" in the mailing list.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2857838032

From alanb at openjdk.org  Wed May  7 09:31:24 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 May 2025 09:31:24 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v11]
In-Reply-To: <l_GIxbkloPyrjwdsuygZbrM_l9lpILQiSx3y_olNVD8=.b905e03f-3b60-444e-aa58-6b92d1dbf7a6@github.com>
References: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
 <iIZQ5VxWNxeVTWlKx0_5V1J9JANf9rQsCpZ-BYV8pP8=.08b99c22-969a-4338-bdbb-0c4c107d625a@github.com>
 <l_GIxbkloPyrjwdsuygZbrM_l9lpILQiSx3y_olNVD8=.b905e03f-3b60-444e-aa58-6b92d1dbf7a6@github.com>
Message-ID: <doFaLerpa4zaXh6edSFKfqj7GBS4NKthfT-_ZjcAaos=.ca39159a-31e6-4542-89f2-765d8cd3b2a3@github.com>

On Wed, 7 May 2025 07:14:58 GMT, Shaojin Wen <swen at openjdk.org> 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 20 commits:
>> 
>>  - Merge branch 'master' into JDK-8342486
>>  - Merge branch 'master' into JDK-8342486
>>  - Merge branch 'master' into JDK-8342486
>>  - Sync up from loom repo
>>  - Merge branch 'master' into JDK-8342486
>>  - Add JEP number, update copyright headers
>>  - Merge branch 'master' into JDK-8342486
>>  - Sync up from loom repo
>>  - Merge branch 'master' into JDK-8342486
>>  - Sync up from loom repo
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/0eb680ca...5fec717f
>
> src/java.base/share/classes/java/util/concurrent/Joiners.java line 84:
> 
>> 82:             @SuppressWarnings("unchecked")
>> 83:             var s = (Subtask<T>) subtask;
>> 84:             subtasks.add(s);
> 
> Suggestion:
> 
>             subtasks.add((Subtask<T>) subtask);
> 
> The local variable s is only used once and can be simplified

No, it has to be a local to avoid broadening the use of SW.

> src/java.base/share/classes/java/util/concurrent/Joiners.java line 155:
> 
>> 153:                 case FAILED -> throw subtask.exception();
>> 154:                 default -> throw new InternalError();
>> 155:             };
> 
> Suggestion:
> 
>             return switch (subtask.state()) {
>                 case SUCCESS -> subtask.get();
>                 case FAILED  -> throw subtask.exception();
>                 default      -> throw new InternalError();
>             };
> 
> The switch of the stateToInt method is aligned, so it should also be aligned here to keep the style consistent

I'll look to re-align these in the loom repo for the next refresh.

> src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 820:
> 
>> 818:     @PreviewFeature(feature = PreviewFeature.Feature.STRUCTURED_CONCURRENCY)
>> 819:     final class TimeoutException extends RuntimeException {
>> 820:         @java.io.Serial
> 
> Use import without full path

I think `@java.io.Serial` is okay here, you'll see the same in many other areas.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2077217919
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2077215677
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2077222469

From jpai at openjdk.org  Wed May  7 10:08:24 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 May 2025 10:08:24 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v12]
In-Reply-To: <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>
Message-ID: <jEiVhGPtzqmaDHkc9c14nSGANyHLdBzM2_6tt0NxW4s=.59dfbc81-20ab-4f79-be81-777a57483512@github.com>

On Tue, 6 May 2025 20:52:34 GMT, Markus KARG <duke at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - merge latest from master branch
>  - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted?
>  - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs
>  - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since.
>  - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.'
>  - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars()
>  - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()
>  - 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)'
>  - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted?
>  - Applied changes requested by Alan: Copies chars from this sequence into the given destination array
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a

tier1 through tier3 testing of this PR passed without issues. The CSR has been approved and the changes in this PR look good to me.

Thank you for being patient and contributing this enhancement.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21730#pullrequestreview-2821184175

From duke at openjdk.org  Wed May  7 10:27:16 2025
From: duke at openjdk.org (erifan)
Date: Wed, 7 May 2025 10:27:16 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v5]
In-Reply-To: <ItOPWOS6VHofCe7QYcIqnq0yCi-dXfEri_45HgrjfYY=.285d15ff-5b15-4a21-8a7c-1e4cabcc33b2@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <huhJ3Yq2fj9CJGBAqQFZxd8i0Wjnwad3moNHymXKyy8=.d64a2532-6bd5-4e58-84ee-18f682d7fe20@github.com>
 <ItOPWOS6VHofCe7QYcIqnq0yCi-dXfEri_45HgrjfYY=.285d15ff-5b15-4a21-8a7c-1e4cabcc33b2@github.com>
Message-ID: <Jzqyfc2xxJRBY2ppai7XpFKaWS7y3CsnP4Y547KHq6o=.d482f244-a9dd-4ac4-a082-0b3180c1caad@github.com>

On Wed, 7 May 2025 06:59:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Refactor code
>>    
>>    Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
>>    optimization, making the code more modular.
>>  - Merge branch 'master' into JDK-8354242
>>  - Update the jtreg test
>>  - Merge branch 'master' into JDK-8354242
>>  - Addressed some review comments
>>    
>>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>>    2. Improve code comments.
>>  - Merge branch 'master' into JDK-8354242
>>  - Merge branch 'master' into JDK-8354242
>>  - 8354242: VectorAPI: combine vector not operation with compare
>>    
>>    This patch optimizes the following patterns:
>>    For integer types:
>>    ```
>>    (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    ```
>>    cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>>    negative comparison of cond.
>>    
>>    For float and double types:
>>    ```
>>    (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    ```
>>    cond can be eq or ne.
>>    
>>    Benchmarks on Nvidia Grace machine with 128-bit SVE2:
>>    With option `-XX:UseSVE=2`:
>>    ```
>>    Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>>    testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>>    testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>>    testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>>    testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>>    testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>>    testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>>    testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>>    testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>>    testCompareGEMaskNotLong	ops/s	854496.156...
>
> src/hotspot/share/opto/vectornode.cpp line 2231:
> 
>> 2229:   }
>> 2230:   if (in1->Opcode() != Op_VectorMaskCmp || in1->outcnt() > 1 ||
>> 2231:       !((VectorMaskCmpNode*) in1)->predicate_can_be_inverted() ||
> 
> Do you plan  to extend your testcase /  matching logic to cover following equivalent patterns:
> 
> - compare.xor(maskAll(true))
> - compare.xor(VectorMask.fromLong(SPECIES, -1L))

Hi @jatin-bhateja It is feasible. But I was thinking about whether another solution would be better, which is to turn  `VectorMask.fromLong(SPECIES, -1L)` into `MaskAll(true)` in the mid-end. In this way, we don't need to check this pattern in this optimization. What do you think ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2077316033

From duke at openjdk.org  Wed May  7 10:46:14 2025
From: duke at openjdk.org (kabutz)
Date: Wed, 7 May 2025 10:46:14 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com>
 <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com>
Message-ID: <YhkDQaU0FTyyP_42JTmUxM5x97rwSAHQbVYPJxRv3cI=.d70127c6-4f45-48b4-8b6c-eebad4084a34@github.com>

On Mon, 28 Apr 2025 19:48:40 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> @viktorklang-ora @DougLea @AlanBateman
>
> @kabutz Thanks for opening this PR?just confirming that it's on my to-review queue.

@viktorklang-ora any idea whom else we can ask to approve this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2858077986

From duke at openjdk.org  Wed May  7 10:56:19 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 7 May 2025 10:56:19 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v12]
In-Reply-To: <jEiVhGPtzqmaDHkc9c14nSGANyHLdBzM2_6tt0NxW4s=.59dfbc81-20ab-4f79-be81-777a57483512@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>
 <jEiVhGPtzqmaDHkc9c14nSGANyHLdBzM2_6tt0NxW4s=.59dfbc81-20ab-4f79-be81-777a57483512@github.com>
Message-ID: <S-5MDwDw_n_yc-uJKiFkFp0V5By4MiK2kUY8zM3Ls8A=.771e9ae9-6cc5-4e80-b10f-ae9326956be7@github.com>

On Wed, 7 May 2025 10:05:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> tier1 through tier3 testing of this PR passed without issues. The CSR has been approved and the changes in this PR look good to me.

Thank you, Jaikiran! Will this result convince everybody to actively mark this PR as officially reviewed, so I can finally integrate it? ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2858104713

From pminborg at openjdk.org  Wed May  7 11:04:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 11:04:14 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v4]
In-Reply-To: <CCcYfCqazfZBrch-cZLSBxXG5jn-khRNe7daYwDxGSY=.b301e715-0c55-4b13-9bf6-b8629b3dc835@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <SPkI2lv_w_TCf7Y2dVPbtpUCBH167Y_B1CPvsnli8DQ=.3297c679-4c6c-46ce-96ae-07ce2f2e5c21@github.com>
 <hTAYQU2pKnWPwjOaqfTWo6t6vn_kfO2S9Fb-pkfLof8=.6fd79252-39c9-4a7f-b4f9-b97a1d9b5732@github.com>
 <1zyhyBGMKNBM0S4KAB3q5eqByvPGFbNIOLFrR_KzIjQ=.b27c864f-4026-4b9b-b958-0215a73bc3db@github.com>
 <HXfHhZbkRR1isSZFkBGn-7lLHtTKxItntRpHLRWsqng=.8173537a-f789-43f1-85a4-d2b76f76df97@github.com>
 <CCcYfCqazfZBrch-cZLSBxXG5jn-khRNe7daYwDxGSY=.b301e715-0c55-4b13-9bf6-b8629b3dc835@github.com>
Message-ID: <Lg90G_jpGXNnrNxmJ3vHioiDLw6Z6aZG5EWI6NkuPcY=.79e09b7b-8b7f-4aac-94dd-5a341374d702@github.com>

On Tue, 6 May 2025 12:23:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This would require another implementation to be written. Maybe we can add that later?
>
> I feel like declaring a function is declaring redundant classes when we can just reuse a DirectMethodHandle pointing to an actual method. Also the zero alternative should be handled by the provided computing function/method instead of handled by this utility.

There is an MH variant now. The use of the zero alternative is optional, as if you put in `0`, it will have no effect.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077372099

From jbhateja at openjdk.org  Wed May  7 11:06:21 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 7 May 2025 11:06:21 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v5]
In-Reply-To: <Jzqyfc2xxJRBY2ppai7XpFKaWS7y3CsnP4Y547KHq6o=.d482f244-a9dd-4ac4-a082-0b3180c1caad@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <huhJ3Yq2fj9CJGBAqQFZxd8i0Wjnwad3moNHymXKyy8=.d64a2532-6bd5-4e58-84ee-18f682d7fe20@github.com>
 <ItOPWOS6VHofCe7QYcIqnq0yCi-dXfEri_45HgrjfYY=.285d15ff-5b15-4a21-8a7c-1e4cabcc33b2@github.com>
 <Jzqyfc2xxJRBY2ppai7XpFKaWS7y3CsnP4Y547KHq6o=.d482f244-a9dd-4ac4-a082-0b3180c1caad@github.com>
Message-ID: <gs98vNywMgB3pEcq_Bfv_jhLBiH7KS_1NhHGprSCtLs=.cd43836c-5de3-4642-afa1-1a5a04f0b17b@github.com>

On Wed, 7 May 2025 10:24:14 GMT, erifan <duke at openjdk.org> wrote:

>> src/hotspot/share/opto/vectornode.cpp line 2231:
>> 
>>> 2229:   }
>>> 2230:   if (in1->Opcode() != Op_VectorMaskCmp || in1->outcnt() > 1 ||
>>> 2231:       !((VectorMaskCmpNode*) in1)->predicate_can_be_inverted() ||
>> 
>> Do you plan  to extend your testcase /  matching logic to cover following equivalent patterns:
>> 
>> - compare.xor(maskAll(true))
>> - compare.xor(VectorMask.fromLong(SPECIES, -1L))
>
> Hi @jatin-bhateja It is feasible. But I was thinking about whether another solution would be better, which is to turn  `VectorMask.fromLong(SPECIES, -1L)` into `MaskAll(true)` in the mid-end. In this way, we don't need to check this pattern in this optimization. What do you think ?

Yes, that's the right approach. For this PR, I think you can mix some test points covering compare, xor(maskAll(true)).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2077373581

From duke at openjdk.org  Wed May  7 11:08:18 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 7 May 2025 11:08:18 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v12]
In-Reply-To: <S-5MDwDw_n_yc-uJKiFkFp0V5By4MiK2kUY8zM3Ls8A=.771e9ae9-6cc5-4e80-b10f-ae9326956be7@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>
 <jEiVhGPtzqmaDHkc9c14nSGANyHLdBzM2_6tt0NxW4s=.59dfbc81-20ab-4f79-be81-777a57483512@github.com>
 <S-5MDwDw_n_yc-uJKiFkFp0V5By4MiK2kUY8zM3Ls8A=.771e9ae9-6cc5-4e80-b10f-ae9326956be7@github.com>
Message-ID: <BRFr9LLWO0wnNpuh2v5Y4k5dx4SZG2WNMopOGrU-eOM=.cc9f8e54-1b0d-48b7-9e6f-2077a0a06967@github.com>

On Wed, 7 May 2025 10:53:09 GMT, Markus KARG <duke at openjdk.org> wrote:

> Thank you, Jaikiran! Will this result convince everybody to actively mark this PR as officially reviewed, so I can finally integrate it? ?

@liach For example, you could approve your outdated approval so this PR finally has to *current* reviews. Thanks.

>[Chen Liang](https://openjdk.org/census#liach) (@liach - Reviewer) ? **Re-review required** (review applies to [884e7dc1](https://git.openjdk.org/jdk/pull/21730/files/884e7dc14c25b47ff6e5056fb663cfccf17f243e))

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2858138560

From jbhateja at openjdk.org  Wed May  7 11:09:16 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 7 May 2025 11:09:16 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v2]
In-Reply-To: <7IGU54ppPKoebXOt0BaS9r-eYf92mtILbHLu8RsfmSk=.a0b3259c-e5ea-43a2-b34c-38d439bd0a41@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <QQODoGVCNFR2997tNKxhLIDr_9FHAK2GvOnpxzSdoGY=.0278d865-1b6b-4d92-a6e1-9e03ffcdd901@github.com>
 <T8MRYVDZjDOqZELBSXMRxlrmgoM9t4p_M_gae5GNRz8=.db58eb3b-62e0-4686-8766-32807c1faed8@github.com>
 <vK0TSeGLX6Ia4nwvi7M_GdJELzWws-7QRP7kivLG9Iw=.fb85da13-4d26-4c22-aad9-fd025128701d@github.com>
 <7IGU54ppPKoebXOt0BaS9r-eYf92mtILbHLu8RsfmSk=.a0b3259c-e5ea-43a2-b34c-38d439bd0a41@github.com>
Message-ID: <b7AMRUdAyeY33op3vyWU1kb2xxn_kgwxz8JknO18uR0=.cc68c182-baf0-4628-953b-d2bbe455f42f@github.com>

On Fri, 25 Apr 2025 09:17:02 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Thanks for telling me this information. Another more important reason to check outcnt here is to prevent this optimization when the uses of VectorMaskCmp is greater than 1, because this optimization may not be worthwhile. For example:
>> 
>> 
>>   public static void testVectorMaskCmp() {
>>     IntVector bv = IntVector.fromArray(I_SPECIES, ib, 0);
>>     IntVector av = IntVector.fromArray(I_SPECIES, ia, 0);
>>     VectorMask<Integer> m1 = av.compare(VectorOperators.NE, bv);  // two uses
>>     VectorMask<Integer> m2 =m1.not();
>>     m1.intoArray(m, 0);
>>     av.lanewise(VectorOperators.ABS, m2).intoArray(ia, 0);
>>   }
>> 
>> 
>> If we do not check outcnt and still do this optimization, two VectorMaskCmp nodes will be generated, and finally two VectorMaskCmp instructions will be generated. This is unreasonable because VectorMaskCmp has much higher latency than xor instruction on aarch64.
>
> Thanks, we can add this comment to the code where we are checking outcnt. What if all the other users are also XorNodes?.

At present, you are checking for one XOR user; shouldn't it be all or one scenario?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2077378879

From vyazici at openjdk.org  Wed May  7 11:20:26 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 May 2025 11:20:26 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v2]
In-Reply-To: <vMVnGmw2Bg2qgbUiwI3yf2ky-L2DnIAOP6umt2Q2Tig=.04bb10da-692f-4be6-a0a1-ded8761d4b01@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <l3xoBLwwsAQrpneEdTdtlnrC7dOit7jokk7wLettH14=.472e261e-894b-44d2-a8cb-c34df74aeb43@github.com>
 <vMVnGmw2Bg2qgbUiwI3yf2ky-L2DnIAOP6umt2Q2Tig=.04bb10da-692f-4be6-a0a1-ded8761d4b01@github.com>
Message-ID: <Mmh5sRiZ99XISUdmNPsE0tQaghFoHEvPPL9UZM6QEEo=.37df736e-0640-42b7-bd81-75eb8a378690@github.com>

On Wed, 7 May 2025 07:37:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in pre-existing JavaDoc
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 302:
> 
>> 300:      * <b>WARNING: This method does not perform any bound checks.</b>
>> 301:      */
>> 302:     int countPositives(byte[] ba, int off, int len);
> 
> Maybe we should change countPositives to do a bounds check and have a private method in StringCoding be the `@IntrinsicCandidate`. This would make it easier to audit. Right now it's hard to audit because there are usages of JLA.countPositives in faraway classes. I'm not suggested we do this as part of this PR of course but it would mean the warning comment could be removed.

Submitted [8356380](https://bugs.openjdk.org/browse/JDK-8356380) to address this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2077399743

From jbhateja at openjdk.org  Wed May  7 11:24:17 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 7 May 2025 11:24:17 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v5]
In-Reply-To: <huhJ3Yq2fj9CJGBAqQFZxd8i0Wjnwad3moNHymXKyy8=.d64a2532-6bd5-4e58-84ee-18f682d7fe20@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <huhJ3Yq2fj9CJGBAqQFZxd8i0Wjnwad3moNHymXKyy8=.d64a2532-6bd5-4e58-84ee-18f682d7fe20@github.com>
Message-ID: <fbwQ9Crn9VaJSb7zFzT1aj_AVRojWMT7EStONFdUecs=.1cd10882-f5ee-488a-bb49-e21f2ba702e5@github.com>

On Wed, 7 May 2025 02:10:56 GMT, erifan <duke at openjdk.org> wrote:

>> This patch optimizes the following patterns:
>> For integer types:
>> 
>> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> 
>> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond.
>> 
>> For float and double types:
>> 
>> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> 
>> cond can be eq or ne.
>> 
>> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`:
>> 
>> Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>> testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>> testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>> testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>> testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>> testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>> testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>> testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>> testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>> testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
>> testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
>> testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
>> testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
>> testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
>> testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
>> testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
>> testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
>> testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
>> testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
>> testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
>> testCompareLTMaskNotInt		ops/s	16721...
>
> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Refactor code
>    
>    Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
>    optimization, making the code more modular.
>  - Merge branch 'master' into JDK-8354242
>  - Update the jtreg test
>  - Merge branch 'master' into JDK-8354242
>  - Addressed some review comments
>    
>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>    2. Improve code comments.
>  - Merge branch 'master' into JDK-8354242
>  - Merge branch 'master' into JDK-8354242
>  - 8354242: VectorAPI: combine vector not operation with compare
>    
>    This patch optimizes the following patterns:
>    For integer types:
>    ```
>    (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>        => (VectorMaskCmp src1 src2 ncond)
>    (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>        => (VectorMaskCmp src1 src2 ncond)
>    ```
>    cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>    negative comparison of cond.
>    
>    For float and double types:
>    ```
>    (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>    (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>    ```
>    cond can be eq or ne.
>    
>    Benchmarks on Nvidia Grace machine with 128-bit SVE2:
>    With option `-XX:UseSVE=2`:
>    ```
>    Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>    testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>    testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>    testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>    testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>    testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>    testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>    testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>    testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>    testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
>    testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4...

test/micro/org/openjdk/bench/jdk/incubator/vector/MaskCompareNotBenchmark.java line 40:

> 38: @Fork(jvmArgs = { "--add-modules=jdk.incubator.vector" })
> 39: public class MaskCompareNotBenchmark {
> 40:     private static final int ARRAYLEN = 4096;

ARRAYLEN should be configurable @Param.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2077390413

From vklang at openjdk.org  Wed May  7 11:52:21 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 7 May 2025 11:52:21 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <YhkDQaU0FTyyP_42JTmUxM5x97rwSAHQbVYPJxRv3cI=.d70127c6-4f45-48b4-8b6c-eebad4084a34@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com>
 <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com>
 <YhkDQaU0FTyyP_42JTmUxM5x97rwSAHQbVYPJxRv3cI=.d70127c6-4f45-48b4-8b6c-eebad4084a34@github.com>
Message-ID: <cNgTWWn7HqULfARHITIGj8aL1_0mOmQWJTOhieRrXY0=.a4fa12c8-715d-4883-b7b1-60373da5ac38@github.com>

On Wed, 7 May 2025 10:43:55 GMT, kabutz <duke at openjdk.org> wrote:

>> @kabutz Thanks for opening this PR?just confirming that it's on my to-review queue.
>
> @viktorklang-ora any idea whom else we can ask to approve this PR?

@kabutz I think @AlanBateman might be able to have a look as well.

As for timing, it seems to me most reasonable if this PR (if it is to be integrated) to go in *after* JDK25 has been forked, to give enough time for JDK26 early access feedback and giving the changes time to harden. I hope that makes sense.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2858284560

From rgiulietti at openjdk.org  Wed May  7 11:57:20 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 May 2025 11:57:20 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v49]
In-Reply-To: <xpyRj89EdLeIFsZU8G6VQBoMBQFL6De4oudg3VZYykw=.03af0543-59be-4a57-878a-14e7ec328895@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <xpyRj89EdLeIFsZU8G6VQBoMBQFL6De4oudg3VZYykw=.03af0543-59be-4a57-878a-14e7ec328895@github.com>
Message-ID: <wGVZ0_cmGB_ohAh4NlmKRc5Tm__L2-ECgkmTKZ86QRo=.111bc975-5b57-43db-9bfa-07037966fac6@github.com>

On Wed, 30 Apr 2025 15:59:05 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify long power computing

test/micro/org/openjdk/bench/java/math/BigIntegerPow.java line 72:

> 70: 
> 71:         new Runner(opt).run();
> 72:     }

There's no need for these lines.

test/micro/org/openjdk/bench/java/math/BigIntegerPow.java line 117:

> 115:     @OperationsPerInvocation(TESTSIZE)
> 116:     public void testPowXS(Blackhole bh) {
> 117:         for (BigInteger s : xsArray) {

Suggestion:

        for (BigInteger xs : xsArray) {


and similarly for the other arrays.

test/micro/org/openjdk/bench/java/math/BigIntegerPow.java line 118:

> 116:     public void testPowXS(Blackhole bh) {
> 117:         for (BigInteger s : xsArray) {
> 118:             bh.consume(s.pow(xsExp));

Suggestion:

            bh.consume(s.pow(xsExp & ~0b0111_0101));
            bh.consume(s.pow(xsExp));
            bh.consume(s.pow(xsExp + 1));

or something similar, just to measure other than "all-ones" exponents as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077443258
PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077449324
PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077452722

From abimpoudis at openjdk.org  Wed May  7 12:02:26 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 7 May 2025 12:02:26 GMT
Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside
 the compiler
Message-ID: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>

While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation.

For example this is not valid Java (and protected) by javac:


byte b = 1;
switch (b) {
    case String s -> System.out.println("How did we get here? byte is " + s.getClass());
}


but this is a valid call (and not protected):


CallSite shortSwitch = SwitchBootstraps.typeSwitch(
    MethodHandles.lookup(), 
    "", 
    MethodType.methodType(int.class, short.class, int.class),  // models (short, int) -> int
    String.class);


The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. 

This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton.

-------------

Commit messages:
 - 8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler

Changes: https://git.openjdk.org/jdk/pull/25090/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25090&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354323
  Stats: 33 lines in 2 files changed: 27 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25090.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25090/head:pull/25090

PR: https://git.openjdk.org/jdk/pull/25090

From duke at openjdk.org  Wed May  7 12:11:19 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 7 May 2025 12:11:19 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v4]
In-Reply-To: <bbIIjNufb8B7cXMueePzk44qVT5JYT6RZjf_0_p_5zk=.29bc910c-c768-4475-980e-fa303f0e87c1@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <bbIIjNufb8B7cXMueePzk44qVT5JYT6RZjf_0_p_5zk=.29bc910c-c768-4475-980e-fa303f0e87c1@github.com>
Message-ID: <YItT336qs8A-iwBZEo3FSHOvmtk-iCSZM3tk0ChEF3M=.6a23d84b-95c8-470a-b8a7-455bac5f2dd3@github.com>

On Wed, 7 May 2025 09:23:45 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reformat
>  - Revert changes in public classes

Starting to look nicely idiomatic. If I saw this I would however want to add a thin wrapper specific for hash codes where the "zero replacement" and generic types are more hidden.
* HashCoder.forIntField(Foo.class, "hash", ...)
* HashCoder.forLongField(...)
I like that there's an annotation on the field now though!

test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 83:

> 81: 
> 82: 
> 83:     static // Intentionally in unblessed order to allow the example to look nice

Huh, not seen this before ... interesting.

test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 117:

> 115:         private static final ToIntFunction<LazyFoo> HASH_UPDATER =
> 116:                 StableFieldUpdater.ofInt(LazyFoo.class, "hash",
> 117:                         l -> Objects.hash(l.bar, l.baz), -1);

As someone unfamiliar with this, I'm given to ask "What's the -1 for?"

I *think* I can intuit that it's a value to be used *if* the hashcode actually ends up calculating zero (so any random bit pattern would (should?) be equally useful?

In example code if feels like this is not quite explaining itself enough to teach someone about its usage. For example (if it's what I think) it can't actually be passed as zero.

test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 149:

> 147:         private static final ToLongFunction<LazySpecifiedFoo> HASH_UPDATER =
> 148:                 StableFieldUpdater.ofLong(LazySpecifiedFoo.class, "hash",
> 149:                         l -> (l.bar == null && l.baz == null) ? 0 : Objects.hash(l.bar, l.baz), 1L << 32);

Maybe for an example, use a (private?) static method reference here `calculateHash`.
It helps visually distinguish plumbing and business logic IMO.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25040#pullrequestreview-2821463165
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077457809
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077457604
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077460209

From rgiulietti at openjdk.org  Wed May  7 12:14:24 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 May 2025 12:14:24 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v49]
In-Reply-To: <xpyRj89EdLeIFsZU8G6VQBoMBQFL6De4oudg3VZYykw=.03af0543-59be-4a57-878a-14e7ec328895@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <xpyRj89EdLeIFsZU8G6VQBoMBQFL6De4oudg3VZYykw=.03af0543-59be-4a57-878a-14e7ec328895@github.com>
Message-ID: <M-fMolL0wv56iWzHy7VcmX95z2LazQqxaGT4DfJPbsw=.88db1ea9-6b61-438e-8a9a-700b9ad3eee8@github.com>

On Wed, 30 Apr 2025 15:59:05 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify long power computing

src/java.base/share/classes/java/math/BigInteger.java line 2622:

> 2620: 
> 2621:         // Factor the powers of two out quickly by shifting right, if needed.
> 2622:         if (powersOfTwo > 0) {

`shiftRight()` returns `this` when the shift distance is 0, so there's no compelling need to have two branches for `powersOfTwo`

src/java.base/share/classes/java/math/BigInteger.java line 2626:

> 2624:             remainingBits = base.bitLength();
> 2625:             if (remainingBits == 1) {  // Nothing left but +/- 1?
> 2626:                 if (signum < 0 && (exponent&1) == 1) {

This `boolean` expression occurs many times.
It could be factored out in a local var.

src/java.base/share/classes/java/math/BigInteger.java line 2656:

> 2654: 
> 2655:             // Multiply back the powers of two (quickly, by shifting left)
> 2656:             return powersOfTwo == 0

I don't think there's a compelling need to "optimize" for `powersOfTwo == 0`.

src/java.base/share/classes/java/math/BigInteger.java line 2662:

> 2660:                             : new BigInteger(result, newSign).shiftLeft(bitsToShift));
> 2661:         } else {
> 2662:             if ((((bitLength() - 1L) * exponent) >>> 5) + 1L > MAX_MAG_LENGTH) {

Suggestion:

            if ((bitLength() - 1L) * exponent >= 32L * MAX_MAG_LENGTH) {

src/java.base/share/classes/java/math/BigInteger.java line 2718:

> 2716:             x *= x;
> 2717:         }
> 2718:         return pow;

This uselessly computes a square in the last iteration.
See the [suggested variant](https://github.com/openjdk/jdk/pull/24690#discussion_r2068549452) for inspiration.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077472392
PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077465904
PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077482776
PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077473938
PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077478542

From liach at openjdk.org  Wed May  7 12:57:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 12:57:17 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v4]
In-Reply-To: <bbIIjNufb8B7cXMueePzk44qVT5JYT6RZjf_0_p_5zk=.29bc910c-c768-4475-980e-fa303f0e87c1@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <bbIIjNufb8B7cXMueePzk44qVT5JYT6RZjf_0_p_5zk=.29bc910c-c768-4475-980e-fa303f0e87c1@github.com>
Message-ID: <ks7Fdtyi2OSDuzk69--M7xPcxUTJr3VtRKo4VFIXRyA=.8b84dea3-9ccf-40c9-9687-89aa8d685e1a@github.com>

On Wed, 7 May 2025 09:23:45 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reformat
>  - Revert changes in public classes

The MH+VH form should be much more lightweight: MH and VH are just MemberName references.

I wonder if we can advertise the MH+VH version as an indy BSM:

public static CallSite lazyAccessor(Lookup lookup, String unused, MethodType callType, VarHandle field, MethodHandle computer)


The CallSite would be constant, with `StableIntFieldUpdaterVarHandle.applyAsInt` bound to the specific updater. This way, we can even defer the creation of the updater.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25040#issuecomment-2858487803

From liach at openjdk.org  Wed May  7 12:59:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 12:59:14 GMT
Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2]
In-Reply-To: <OQFS9tEyTK4cXqq9upD-EH8-B3H_LB0nfBAHkW-daXk=.fd5763c2-a86d-4b0b-9857-c8a70542ad31@github.com>
References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
 <OQFS9tEyTK4cXqq9upD-EH8-B3H_LB0nfBAHkW-daXk=.fd5763c2-a86d-4b0b-9857-c8a70542ad31@github.com>
Message-ID: <uIlVudX5A_Y3z253O3-2RFOoFn0d3u5sTujDInwNpJE=.d50d768f-aa7f-4231-a153-270935f35e34@github.com>

On Sun, 4 May 2025 16:21:41 GMT, Markus KARG <duke at openjdk.org> 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`.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Undone copyright update of otherwise unchanged file.
>  - Update Of.java
>    
>    Applied changnes proposed by @liach: "the default toString already includes id=..., so I usually don't provide an explicit override to make the code concise."

I guess a better approach may be to allow periodical reminders if a thread gets no reply - many of us gets quite a few hundred mails every day on workdays.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2858492193

From liach at openjdk.org  Wed May  7 13:00:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 13:00:18 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v49]
In-Reply-To: <wGVZ0_cmGB_ohAh4NlmKRc5Tm__L2-ECgkmTKZ86QRo=.111bc975-5b57-43db-9bfa-07037966fac6@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <xpyRj89EdLeIFsZU8G6VQBoMBQFL6De4oudg3VZYykw=.03af0543-59be-4a57-878a-14e7ec328895@github.com>
 <wGVZ0_cmGB_ohAh4NlmKRc5Tm__L2-ECgkmTKZ86QRo=.111bc975-5b57-43db-9bfa-07037966fac6@github.com>
Message-ID: <o5rKvgnMlmdBjVP7_F5YFNsQyTLGtlK9ow_dXqv9q6A=.41270478-481f-4d38-acf7-b1408696f441@github.com>

On Wed, 7 May 2025 11:45:14 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify long power computing
>
> test/micro/org/openjdk/bench/java/math/BigIntegerPow.java line 72:
> 
>> 70: 
>> 71:         new Runner(opt).run();
>> 72:     }
> 
> There's no need for these lines.

These are here for convenience when a benchmark is run standalone. I think this has no harm.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077570983

From rgiulietti at openjdk.org  Wed May  7 13:10:21 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 May 2025 13:10:21 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v49]
In-Reply-To: <o5rKvgnMlmdBjVP7_F5YFNsQyTLGtlK9ow_dXqv9q6A=.41270478-481f-4d38-acf7-b1408696f441@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <xpyRj89EdLeIFsZU8G6VQBoMBQFL6De4oudg3VZYykw=.03af0543-59be-4a57-878a-14e7ec328895@github.com>
 <wGVZ0_cmGB_ohAh4NlmKRc5Tm__L2-ECgkmTKZ86QRo=.111bc975-5b57-43db-9bfa-07037966fac6@github.com>
 <o5rKvgnMlmdBjVP7_F5YFNsQyTLGtlK9ow_dXqv9q6A=.41270478-481f-4d38-acf7-b1408696f441@github.com>
Message-ID: <qs3PhmDlveLZ7N5WJbwJR0vX1lUPj2Yrg_jNMkCPgpc=.837f404a-1c9f-4c48-8f74-4c06a445ce32@github.com>

On Wed, 7 May 2025 12:57:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/math/BigIntegerPow.java line 72:
>> 
>>> 70: 
>>> 71:         new Runner(opt).run();
>>> 72:     }
>> 
>> There's no need for these lines.
>
> These are here for convenience when a benchmark is run standalone. I think this has no harm.

There's no harm, but no need either.

We can add a comment like so, to clarify that the benchmark is here to measure memory allocations, rather than running time.

You can run this test via the command line:
    $ make test TEST="micro:java.math.BigIntegerPow" MICRO="OPTIONS=-prof gc"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077590224

From rgiulietti at openjdk.org  Wed May  7 13:25:18 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 May 2025 13:25:18 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v2]
In-Reply-To: <9IfMW-HLFSI8eeAfs6m3jZyfpzGRhnutoTgYFripC4U=.f84019f8-30d4-43ce-857a-6f3d71bfd713@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <l3xoBLwwsAQrpneEdTdtlnrC7dOit7jokk7wLettH14=.472e261e-894b-44d2-a8cb-c34df74aeb43@github.com>
 <9IfMW-HLFSI8eeAfs6m3jZyfpzGRhnutoTgYFripC4U=.f84019f8-30d4-43ce-857a-6f3d71bfd713@github.com>
Message-ID: <bI_IZirW_8IhUnO_nVTVt135X9GDoVm63JdOEqKWweU=.a57bcfea-ceab-4ad4-b288-41728f5b4c47@github.com>

On Wed, 7 May 2025 08:02:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in pre-existing JavaDoc
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 355:
> 
>> 353:      * UTF-16 representation.
>> 354:      * <p>
>> 355:      * <b>WARNING: This method does not perform any bound checks.</b>
> 
> Maybe not this PR but this method is begging to be renamed. It's really hard to audit usage when the method is accessible to faraway code via shared secrets. So maybe not this PR but I think we need an issue in JBS to track renaming, I think Stuart suggested prefixing with "unchecked".

As mentioned by Alan and Jaikiran, at some point it is advisable to prefix the names with "unchecked".

For the "noRepl" names, perhaps the mouthful but clearer "noReplacementChar" might help.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2077617931

From pminborg at openjdk.org  Wed May  7 13:55:08 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 13:55:08 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v5]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <jrFR7pUJMqqF8CIbTWKuc0kNmt61MI_oZTV6sXwPB8M=.901b586c-f66b-4a1d-abc4-5eb140cf4f97@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

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 15 additional commits since the last revision:

 - Add low level variants
 - Merge branch 'master' into stable-updaters
 - Reformat
 - Revert changes in public classes
 - Add a method handle based field updater
 - Fix raw long updater under 32-bit mode
 - Address comments
 - Document field alignment assumption
 - Add unhecked call test
 - Move raw factories into inner class Raw
 - ... and 5 more: https://git.openjdk.org/jdk/compare/de41c1f3...6342fbd8

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/4a42b271..6342fbd8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=03-04

  Stats: 14466 lines in 388 files changed: 9105 ins; 3251 del; 2110 mod
  Patch: https://git.openjdk.org/jdk/pull/25040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040

PR: https://git.openjdk.org/jdk/pull/25040

From pminborg at openjdk.org  Wed May  7 13:55:10 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 13:55:10 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v4]
In-Reply-To: <YItT336qs8A-iwBZEo3FSHOvmtk-iCSZM3tk0ChEF3M=.6a23d84b-95c8-470a-b8a7-455bac5f2dd3@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <bbIIjNufb8B7cXMueePzk44qVT5JYT6RZjf_0_p_5zk=.29bc910c-c768-4475-980e-fa303f0e87c1@github.com>
 <YItT336qs8A-iwBZEo3FSHOvmtk-iCSZM3tk0ChEF3M=.6a23d84b-95c8-470a-b8a7-455bac5f2dd3@github.com>
Message-ID: <6V0vEbAOnYqONTavs8-eEVlInQI5pTcYDAo1tRYduNA=.0ff84e6a-73e6-40c3-b616-0c0753d330a3@github.com>

On Wed, 7 May 2025 11:54:09 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Reformat
>>  - Revert changes in public classes
>
> test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 117:
> 
>> 115:         private static final ToIntFunction<LazyFoo> HASH_UPDATER =
>> 116:                 StableFieldUpdater.ofInt(LazyFoo.class, "hash",
>> 117:                         l -> Objects.hash(l.bar, l.baz), -1);
> 
> As someone unfamiliar with this, I'm given to ask "What's the -1 for?"
> 
> I *think* I can intuit that it's a value to be used *if* the hashcode actually ends up calculating zero (so any random bit pattern would (should?) be equally useful?
> 
> In example code if feels like this is not quite explaining itself enough to teach someone about its usage. For example (if it's what I think) it can't actually be passed as zero.

I've added some verbiage around this now. Let me know if it can be improved further.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077688537

From liach at openjdk.org  Wed May  7 14:08:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 14:08:20 GMT
Subject: RFR: 8341184: Clean up the interaction between the launcher native
 code and the LauncherHelper [v16]
In-Reply-To: <nFCLkc0TaSpNqcdPbxsVET3CYK6ZHsTg0Eu4jRIoHPM=.e4ef4036-6e4a-4ee8-bb09-0891b79b4505@github.com>
References: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
 <JHBC_-2uIDzTy40hi2OfmFH2-eh_XXtZrgpgiQIxd3U=.5e271baf-04ca-4eaf-b51c-c85b9248fd40@github.com>
 <nFCLkc0TaSpNqcdPbxsVET3CYK6ZHsTg0Eu4jRIoHPM=.e4ef4036-6e4a-4ee8-bb09-0891b79b4505@github.com>
Message-ID: <Cj1MF-khSIO_BvqOteaMYNS5yfHmhp_3mNxuQIGHVUo=.1013fd02-b4e0-4659-b929-c4fadd6e4b65@github.com>

On Wed, 7 May 2025 07:34:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/e410af00...d1ac5174
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 946:
> 
>> 944:                         JAVAFX_APPLICATION_CLASS_NAME);
>> 945:             }
>> 946:         }
> 
> Suggestion:
> 
>         if (!PreviewFeatures.isEnabled()) {
>             int mods = mainMethod.getModifiers();
>             if (!Modifier.isStatic(mods) || !Modifier.isPublic(mods) || mainMethod.getParameterCount() == 0) {
>                 abort(null, "java.launcher.cls.error2", builder.mainClass.getName(),
>                         JAVAFX_APPLICATION_CLASS_NAME);
>             }
>         }
> 
> Remove variables that are only used once

This can now be removed. Compact source files and instance main methods have been integrated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21256#discussion_r2077717832

From liach at openjdk.org  Wed May  7 14:11:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 14:11:18 GMT
Subject: RFR: 8355775: Improve symbolic sharing in dynamic constant pool
 entries
In-Reply-To: <Uc29vIFCqWGt5qG78EKk7-GWz0Ur2axVtZOwgu10pv4=.348a21ca-ae61-49ee-a035-b4252b3d2c56@github.com>
References: <Uc29vIFCqWGt5qG78EKk7-GWz0Ur2axVtZOwgu10pv4=.348a21ca-ae61-49ee-a035-b4252b3d2c56@github.com>
Message-ID: <PDyaQj5V0z_4j17fUuhLBg27wsSU1pD668hyOFzb4HQ=.fec7a4e1-a7a1-4685-94b7-2ff014ad6108@github.com>

On Mon, 28 Apr 2025 20:50:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> Some dynamic constant pool entries with heavy symbolic descriptors currently don't share them, yet they are used by stack map generation, and computing a new descriptor every time introduces a heavy cost.
> 
> This cost is obvious if bytecode generation uses constant dynamic - the stack map generator parses the whole dynamic constant symbol to interpret the return type of an ldc condy, such as in FFM downcalls.
> 
> Both the lack of expensive symbol caching in dynamic cp entries and the incorrect query in StackMapGenerator should be fixed.

Yeah, this is visible if a condy is used due to that updated site in StackMapGenerator - it required a symbolic expansion. Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24938#issuecomment-2858740354

From liach at openjdk.org  Wed May  7 14:11:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 14:11:19 GMT
Subject: Integrated: 8355775: Improve symbolic sharing in dynamic constant pool
 entries
In-Reply-To: <Uc29vIFCqWGt5qG78EKk7-GWz0Ur2axVtZOwgu10pv4=.348a21ca-ae61-49ee-a035-b4252b3d2c56@github.com>
References: <Uc29vIFCqWGt5qG78EKk7-GWz0Ur2axVtZOwgu10pv4=.348a21ca-ae61-49ee-a035-b4252b3d2c56@github.com>
Message-ID: <gSk8iy5gbQttGeurubtMG7kxbWHJu_41EpM0NiqHNes=.65cd949f-db8a-43f9-830a-9ba605ea2e49@github.com>

On Mon, 28 Apr 2025 20:50:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> Some dynamic constant pool entries with heavy symbolic descriptors currently don't share them, yet they are used by stack map generation, and computing a new descriptor every time introduces a heavy cost.
> 
> This cost is obvious if bytecode generation uses constant dynamic - the stack map generator parses the whole dynamic constant symbol to interpret the return type of an ldc condy, such as in FFM downcalls.
> 
> Both the lack of expensive symbol caching in dynamic cp entries and the incorrect query in StackMapGenerator should be fixed.

This pull request has now been integrated.

Changeset: d7e648bb
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d7e648bb2737362d3cba3350cae63b1013967a66
Stats:     103 lines in 6 files changed: 56 ins; 34 del; 13 mod

8355775: Improve symbolic sharing in dynamic constant pool entries

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/24938

From duke at openjdk.org  Wed May  7 14:54:09 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 7 May 2025 14:54:09 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v50]
In-Reply-To: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
Message-ID: <WLVCxR7VBk3irmydtezvFz8IddBxf5bqJGNVdinb_4U=.b7761e94-dbf3-4ddc-b3bf-808f31749584@github.com>

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Suggested changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/b8ca4fe4..4103e491

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=49
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=48-49

  Stats: 110 lines in 2 files changed: 49 ins; 36 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From pminborg at openjdk.org  Wed May  7 14:58:33 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 14:58:33 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v6]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <2NWJRVHInokp4W8BO1R4QBKYYLYCbbVq5L7UGQGr0vI=.f68aac19-94d2-4a7e-98ba-0454e5b420e7@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add convenience methods and documentations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/6342fbd8..a01ba9ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=04-05

  Stats: 107 lines in 2 files changed: 106 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040

PR: https://git.openjdk.org/jdk/pull/25040

From duke at openjdk.org  Wed May  7 15:03:36 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 7 May 2025 15:03:36 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51]
In-Reply-To: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
Message-ID: <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Removed needless brackets

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/4103e491..5ebc16b7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=50
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=49-50

  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 pminborg at openjdk.org  Wed May  7 15:03:57 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 May 2025 15:03:57 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v7]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <nEBDyw_bzz0kktu7D84DKk6ljVKgydIVgoR3Pi-UODo=.98dec655-278c-4ee3-99ff-6dbc630bb10e@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Reformat

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/a01ba9ab..de8e2387

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=05-06

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040

PR: https://git.openjdk.org/jdk/pull/25040

From duke at openjdk.org  Wed May  7 15:10:16 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 7 May 2025 15:10:16 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v7]
In-Reply-To: <nEBDyw_bzz0kktu7D84DKk6ljVKgydIVgoR3Pi-UODo=.98dec655-278c-4ee3-99ff-6dbc630bb10e@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <nEBDyw_bzz0kktu7D84DKk6ljVKgydIVgoR3Pi-UODo=.98dec655-278c-4ee3-99ff-6dbc630bb10e@github.com>
Message-ID: <89tWdW-Z_osB8oN36zrb_w_BPPDjCd6mJ_pEpDjCfXQ=.9ce14d67-3867-4c37-9d72-4fe690c2e0bc@github.com>

On Wed, 7 May 2025 15:03:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat

`StableFieldUpdater?.checkAndAdapt(?)` also?performs an?implicit null?check:

-------------

PR Review: https://git.openjdk.org/jdk/pull/25040#pullrequestreview-2822161491

From duke at openjdk.org  Wed May  7 15:10:19 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 7 May 2025 15:10:19 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v6]
In-Reply-To: <2NWJRVHInokp4W8BO1R4QBKYYLYCbbVq5L7UGQGr0vI=.f68aac19-94d2-4a7e-98ba-0454e5b420e7@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <2NWJRVHInokp4W8BO1R4QBKYYLYCbbVq5L7UGQGr0vI=.f68aac19-94d2-4a7e-98ba-0454e5b420e7@github.com>
Message-ID: <NRYWxpUgBF_-o85c_9ZmEVHvmtGhi0WosIIPHNTT6YY=.0da6aa28-da0a-4bef-99eb-c66b7de19020@github.com>

On Wed, 7 May 2025 14:58:33 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add convenience methods and documentations

src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 257:

> 255:         check(accessor, int.class);
> 256:         Objects.requireNonNull(underlying);
> 257:         var adaptedUnderlying = checkAndAdapt(underlying, int.class);

Suggestion:

        // Implicit null checks:
        check(accessor, int.class);
        var adaptedUnderlying = checkAndAdapt(underlying, int.class);

src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 311:

> 309:         check(accessor, long.class);
> 310:         Objects.requireNonNull(underlying);
> 311:         var adaptedUnderlying = checkAndAdapt(underlying, long.class);

Suggestion:

        // Implicit null checks:
        check(accessor, long.class);
        var adaptedUnderlying = checkAndAdapt(underlying, long.class);

src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 588:

> 586: 
> 587:     private static MethodHandle checkAndAdapt(MethodHandle underlying, Class<?> returnType) {
> 588:         final var underlyingType = underlying.type();

Suggestion:

        // Implicit null check
        final var underlyingType = underlying.type();

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077860284
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077860770
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2077861275

From bpb at openjdk.org  Wed May  7 15:32:16 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 May 2025 15:32:16 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v3]
In-Reply-To: <5sF6nQjDykFcP5-etCpaYidBIGkJvNUzjC6PYRGfuGA=.71fc9b7e-40c8-4ee1-8a67-9b9181cda6ae@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <V_z1LM8NiXvm2IaCKIJHcr-WrAVCc7KVB7eYUjGSszU=.dd1c921c-a20b-471b-8e5f-be63360be0d8@github.com>
 <5sF6nQjDykFcP5-etCpaYidBIGkJvNUzjC6PYRGfuGA=.71fc9b7e-40c8-4ee1-8a67-9b9181cda6ae@github.com>
Message-ID: <asoHxCoJ1RyuSp7uP0au9Ela8zSV5eC45HSYzpYDU9U=.4e51421b-ccbf-4b89-a4b1-7662ef59f97d@github.com>

On Wed, 7 May 2025 06:06:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume the CSR will be expanded, e.g. to list deleteOnExit

Done.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24977#issuecomment-2859058406

From rgiulietti at openjdk.org  Wed May  7 15:45:21 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 May 2025 15:45:21 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51]
In-Reply-To: <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>
Message-ID: <n9pnTwLobj7zDjduh23IIvp5R0qaPzbL0DHIM-XRx6E=.241a736a-343c-4ffc-ba0a-d2cd50fa6b49@github.com>

On Wed, 7 May 2025 15:03:36 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed needless brackets

src/java.base/share/classes/java/math/BigInteger.java line 2607:

> 2605: 
> 2606:         BigInteger base = this.abs();
> 2607:         final boolean negative = signum < 0 && (exponent & 1) == 1;

Some effectively final locals are declared `final`, while others are not.

src/java.base/share/classes/java/math/BigInteger.java line 2643:

> 2641:                     : new BigInteger(result, newSign).shiftLeft(bitsToShift);
> 2642:         } else {
> 2643:             if ((bitLength() - 1L) * exponent >= (long) MAX_MAG_LENGTH << 5) {

Suggestion:

            if ((bitLength() - 1L) * exponent >= 32L * MAX_MAG_LENGTH) {

or
Suggestion:

            if ((bitLength() - 1L) * exponent >= (long) Integer.SIZE * MAX_MAG_LENGTH) {


Both variant are easier to read, more honest, and exactly as efficient as with the shift. The right-hand sides are compile-time constants, so they have no impact on runtime performance.

More generally, the runtime compilers are perfectly capable to optimize multiplications by constant powers of 2 and replace them with shifts, even if the other operand is not a constant.

test/micro/org/openjdk/bench/java/math/BigIntegerPow.java line 74:

> 72:          * Each array entry is atmost 64 bits
> 73:          * in size
> 74:          */

These should probably be part of the declarations:

private int xsExp = (1 << 20) - 1;
private BigInteger[] xsArray = new BigInteger[TESTSIZE];  // Each array entry is atmost 64 bits in size


Similarly for the other fields.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077924006
PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077942835
PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077949298

From duke at openjdk.org  Wed May  7 15:48:40 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 7 May 2025 15:48:40 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v52]
In-Reply-To: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
Message-ID: <FmqSMqzDZZnDT3G6UsU4QbvIMymx4CwCGcQB9CsG4vo=.d5ff74e7-a704-43d4-9534-1671f1ee79ce@github.com>

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Code simplification

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/5ebc16b7..e0816d55

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=51
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=50-51

  Stats: 4 lines in 1 file changed: 1 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 rgiulietti at openjdk.org  Wed May  7 15:48:40 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 May 2025 15:48:40 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51]
In-Reply-To: <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>
Message-ID: <Sb8SfroyAn2vRZ92CArn1RIxFho9k5CbGN4EvzJgqTQ=.0c057f63-c681-4893-887f-eddd7ee22eee@github.com>

On Wed, 7 May 2025 15:03:36 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed needless brackets

The large number algorithm loop in `pow()` might deserve an invariant in a comment.

Did you make sure that the existing tests also cover the `unsignedLongPow()` sufficiently well?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2859115099

From rgiulietti at openjdk.org  Wed May  7 15:51:19 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 May 2025 15:51:19 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51]
In-Reply-To: <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>
Message-ID: <aTR_6nvkvbxXIvXe4bfX7wh7ENG_rFJ6-KvaGIQLzBs=.53ed7461-e599-453d-a362-18b205b60935@github.com>

On Wed, 7 May 2025 15:03:36 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed needless brackets

JMH benchmarks look good for the random exponents as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2859124431

From rgiulietti at openjdk.org  Wed May  7 15:59:19 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 May 2025 15:59:19 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51]
In-Reply-To: <n9pnTwLobj7zDjduh23IIvp5R0qaPzbL0DHIM-XRx6E=.241a736a-343c-4ffc-ba0a-d2cd50fa6b49@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>
 <n9pnTwLobj7zDjduh23IIvp5R0qaPzbL0DHIM-XRx6E=.241a736a-343c-4ffc-ba0a-d2cd50fa6b49@github.com>
Message-ID: <pcRcwMwFC0RDrWgjt-EhAwYP50I13J8KPubYG53PGSw=.eadfbe4e-6044-414b-97d7-90ae945891f2@github.com>

On Wed, 7 May 2025 15:28:59 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed needless brackets
>
> src/java.base/share/classes/java/math/BigInteger.java line 2607:
> 
>> 2605: 
>> 2606:         BigInteger base = this.abs();
>> 2607:         final boolean negative = signum < 0 && (exponent & 1) == 1;
> 
> Some effectively final locals are declared `final`, while others are not.

Personally, I don't have a strong preference, but I prefer consistency.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2077981057

From duke at openjdk.org  Wed May  7 16:03:18 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 7 May 2025 16:03:18 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51]
In-Reply-To: <Sb8SfroyAn2vRZ92CArn1RIxFho9k5CbGN4EvzJgqTQ=.0c057f63-c681-4893-887f-eddd7ee22eee@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>
 <Sb8SfroyAn2vRZ92CArn1RIxFho9k5CbGN4EvzJgqTQ=.0c057f63-c681-4893-887f-eddd7ee22eee@github.com>
Message-ID: <FT6r2QaMrUF7_bbs_-_xllYzzrRqQGsD2jjomfNbP2w=.fdb1dc26-df7b-4f24-86cf-e531ba7f4ba8@github.com>

On Wed, 7 May 2025 15:46:16 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Did you make sure that the existing tests also cover the `unsignedLongPow()` sufficiently well?

@rgiulietti There are already the tests for `BigInteger`'s [pow](https://github.com/fabioromano1/jdk/blob/BigInteger-nth-root/test/jdk/java/math/BigInteger/BigIntegerTest.java#L219), since the code of `unsignedLongPow()` is basically equivalent to that one in the current implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2859155908

From rriggs at openjdk.org  Wed May  7 16:04:27 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 7 May 2025 16:04:27 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v12]
In-Reply-To: <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>
Message-ID: <szkflVlD-o9XS_Cm4ds6z8gAl-T-jb0uwgyUV5J2270=.bb354ad6-dcd6-4821-8112-9ea69d23a227@github.com>

On Tue, 6 May 2025 20:52:34 GMT, Markus KARG <duke at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - merge latest from master branch
>  - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted?
>  - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs
>  - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since.
>  - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.'
>  - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars()
>  - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()
>  - 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)'
>  - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted?
>  - Applied changes requested by Alan: Copies chars from this sequence into the given destination array
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a

Thanks for the persistence.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21730#pullrequestreview-2822378207

From joehw at openjdk.org  Wed May  7 16:22:33 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 7 May 2025 16:22:33 GMT
Subject: RFR: 8353232: Standardizing and Unifying XML Component Configurations
Message-ID: <uQtTZ15H-YxBBmb1xpXrrcHfgF-S7pxzEK2ydOjQN5I=.d6e3f373-da1f-4dbb-b552-48500f1dc6f5@github.com>

This is a refactor patch, no change in functionality.

This patch refactor the configuration code. Rather than for each factory to go through the whole configuration process, a base configuration as represented in JdkXmlConfig is created once, which includes loading of the JAXP Configuration file, factories then get their own copies of the property managers, created on top of the base ones rather than directly constructed.

The JDKCatalogResolver is lazily constructed as needed instead of created along with the security manager.

The rest of changes basically replace all direct constructions of XMLSecurityManager/XMLSecurityPropertyManager with calls to JdkXmlConfig's corresponding get methods, which return clones of the base instances. in the factory classes, these clones are updated with property settings on the factories. In non-public or legacy code paths (inherited from upstream components), such updates may not be necessary.

Tests: existing tests T1-3 passed; XML JCK tests passed.

-------------

Commit messages:
 - 8353232: Standardizing and Unifying XML Component Configurations

Changes: https://git.openjdk.org/jdk/pull/25102/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25102&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353232
  Stats: 582 lines in 31 files changed: 318 ins; 119 del; 145 mod
  Patch: https://git.openjdk.org/jdk/pull/25102.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25102/head:pull/25102

PR: https://git.openjdk.org/jdk/pull/25102

From liach at openjdk.org  Wed May  7 16:39:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 16:39:21 GMT
Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used
 outside the compiler
In-Reply-To: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
References: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
Message-ID: <5mcBz7IvDNxwrQJh9EjP-gKejbWG92idqojhc0MXjI8=.68a4d03a-5af9-430a-96de-20c8775d1dce@github.com>

On Wed, 7 May 2025 11:57:02 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation.
> 
> For example this is not valid Java (and protected) by javac:
> 
> 
> byte b = 1;
> switch (b) {
>     case String s -> System.out.println("How did we get here? byte is " + s.getClass());
> }
> 
> 
> but this is a valid call (and not protected):
> 
> 
> CallSite shortSwitch = SwitchBootstraps.typeSwitch(
>     MethodHandles.lookup(), 
>     "", 
>     MethodType.methodType(int.class, short.class, int.class),  // models (short, int) -> int
>     String.class);
> 
> 
> The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. 
> 
> This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 553:

> 551:                         continue;
> 552:                     }
> 553:                     else if (unconditionalExactnessCheck(selectorType, classLabel)) {

Can we merge this into `isNotValidPair(...) || unconditionalExactnessCheck(...)` then do nothing? The next label is already in theory immediately bound to the instruction after goto.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2078046340

From liach at openjdk.org  Wed May  7 16:42:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 16:42:30 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v12]
In-Reply-To: <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>
Message-ID: <M9UkHKuzzgAdAUZnVidM_8URMNw6z7H0_soOrfSwHxw=.f8fe664f-2c00-4dfd-b01b-8beefdff9ebe@github.com>

On Tue, 6 May 2025 20:52:34 GMT, Markus KARG <duke at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - merge latest from master branch
>  - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted?
>  - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs
>  - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since.
>  - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.'
>  - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars()
>  - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()
>  - 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)'
>  - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted?
>  - Applied changes requested by Alan: Copies chars from this sequence into the given destination array
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a

The latest iteration looks the same as the one I last reviewed.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21730#pullrequestreview-2822479972

From duke at openjdk.org  Wed May  7 16:42:31 2025
From: duke at openjdk.org (duke)
Date: Wed, 7 May 2025 16:42:31 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v12]
In-Reply-To: <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>
Message-ID: <TwYYJl94LAX4Kua6qUt0Z9TwIfb9wD_7UKrLBUnnBj4=.6c88c71a-91f0-4e9a-a650-21b63195efa8@github.com>

On Tue, 6 May 2025 20:52:34 GMT, Markus KARG <duke at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - merge latest from master branch
>  - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted?
>  - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs
>  - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since.
>  - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.'
>  - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars()
>  - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()
>  - 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)'
>  - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted?
>  - Applied changes requested by Alan: Copies chars from this sequence into the given destination array
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a

@mkarg 
Your change (at version 31537b7a4fa0a6b0ba235f6db4d901a9a134a6fa) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2859256566

From duke at openjdk.org  Wed May  7 16:55:17 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 7 May 2025 16:55:17 GMT
Subject: RFR: 8353795: Add Writer.of(StringBuilder) [v2]
In-Reply-To: <uIlVudX5A_Y3z253O3-2RFOoFn0d3u5sTujDInwNpJE=.d50d768f-aa7f-4231-a153-270935f35e34@github.com>
References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
 <OQFS9tEyTK4cXqq9upD-EH8-B3H_LB0nfBAHkW-daXk=.fd5763c2-a86d-4b0b-9857-c8a70542ad31@github.com>
 <uIlVudX5A_Y3z253O3-2RFOoFn0d3u5sTujDInwNpJE=.d50d768f-aa7f-4231-a153-270935f35e34@github.com>
Message-ID: <qSUSVP7Em2y2GKh0UU9PoEoOuaOvRa6qTR8jjsMKCx8=.fd54d3f9-35ab-4295-b779-790c8f358cdc@github.com>

On Wed, 7 May 2025 12:56:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> I guess a better approach may be to allow periodical reminders if a thread gets no reply - many of us gets quite a few hundred mails every day on workdays.

I think it is time to move this discussion into its own thread, but just a last word from my side:

Same with me. We need to find a way how external contributors can make progress even if the core team at Oracle has no time -- because you *mostly* have no time. ? Otherwise lots of contributions will simply not happen, as they linger around for years and then nobody likes to get back to it. ? 

One thing I hope you don't mind if I say is: Being a committer / reviewer is not just a power, it is also a responsibility to stay in contact with "normal" contributors in a timely manner. For that reason, in the open source projects where *I* am the code owner, I reserve time for working with contributors, and I always help others before working on my own stuff. Just as an idea. ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2859305952

From asmehra at openjdk.org  Wed May  7 16:58:15 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 7 May 2025 16:58:15 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v4]
In-Reply-To: <CgpPXWhAoXLJ7nZ9DKtkje5ThhCJMoLUhM74sOeWwNQ=.62d971f4-8446-4ffd-8982-a430d87c0df0@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <CgpPXWhAoXLJ7nZ9DKtkje5ThhCJMoLUhM74sOeWwNQ=.62d971f4-8446-4ffd-8982-a430d87c0df0@github.com>
Message-ID: <5EjPGeqBe78hoAgNgx8-1_BeO8cAyoP0H2t_e-41LnU=.2cfa426f-8240-43ab-9c9a-7352f2614243@github.com>

On Wed, 7 May 2025 05:11:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>> 
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
>> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
>> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
>> 
>> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
>> 
>> Examples:
>> 
>> 
>> # Create an AOT cache with a single command:
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> Hello World
>> Temporary AOTConfiguration recorded: foo.aot.config
>> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
>> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
>> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
>> AOTCache creation is complete: foo.aot 10240000 bytes
>> 
>> # Create logging file for the AOT cache assembly phase
>> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> 
>> 
>> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java

thanks for addressing the comments. lgtm

-------------

Marked as reviewed by asmehra (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2822524147

From duke at openjdk.org  Wed May  7 17:04:16 2025
From: duke at openjdk.org (kabutz)
Date: Wed, 7 May 2025 17:04:16 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <YhkDQaU0FTyyP_42JTmUxM5x97rwSAHQbVYPJxRv3cI=.d70127c6-4f45-48b4-8b6c-eebad4084a34@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com>
 <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com>
 <YhkDQaU0FTyyP_42JTmUxM5x97rwSAHQbVYPJxRv3cI=.d70127c6-4f45-48b4-8b6c-eebad4084a34@github.com>
Message-ID: <fT_4bHAK3fI6N5eRE7LgQ7FMt6o9C3WgTpfEh0ZbDkE=.579c1c92-0173-4f85-b7ff-83cbdf05b630@github.com>

On Wed, 7 May 2025 10:43:55 GMT, kabutz <duke at openjdk.org> wrote:

>> @kabutz Thanks for opening this PR?just confirming that it's on my to-review queue.
>
> @viktorklang-ora any idea whom else we can ask to approve this PR?

> @kabutz I think @AlanBateman might be able to have a look as well.
> 
> As for timing, it seems to me most reasonable if this PR (if it is to be integrated) to go in _after_ JDK25 has been forked, to give enough time for JDK26 early access feedback and giving the changes time to harden. I hope that makes sense.

That sound reasonable. When would this be?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2859366474

From naoto at openjdk.org  Wed May  7 17:07:23 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 May 2025 17:07:23 GMT
Subject: RFR: 8356221: Clarify Console.charset() method description
Message-ID: <iL2w8qXT36llrzI9WY2OgiTgy8w00gfAb-Ejcl29PFU=.2a91b9dd-70a1-42bd-921d-54e3ca0ad746@github.com>

Simple clarification of the `Console.charset()` method description, making explicit how the charset is applied.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/25103/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25103&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356221
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25103/head:pull/25103

PR: https://git.openjdk.org/jdk/pull/25103

From bpb at openjdk.org  Wed May  7 17:11:13 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 May 2025 17:11:13 GMT
Subject: RFR: 8356221: Clarify Console.charset() method description
In-Reply-To: <iL2w8qXT36llrzI9WY2OgiTgy8w00gfAb-Ejcl29PFU=.2a91b9dd-70a1-42bd-921d-54e3ca0ad746@github.com>
References: <iL2w8qXT36llrzI9WY2OgiTgy8w00gfAb-Ejcl29PFU=.2a91b9dd-70a1-42bd-921d-54e3ca0ad746@github.com>
Message-ID: <KptVr7l2zKIS-PWk-oaNV1Wt4Zex-zJ_M2s2Ij_wtEY=.5648199a-297c-4eb4-955c-71bd99eb9ad9@github.com>

On Wed, 7 May 2025 16:56:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple clarification of the `Console.charset()` method description, making explicit how the charset is applied.

Looks all right to me.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25103#pullrequestreview-2822560049

From duke at openjdk.org  Wed May  7 17:17:17 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 7 May 2025 17:17:17 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51]
In-Reply-To: <n9pnTwLobj7zDjduh23IIvp5R0qaPzbL0DHIM-XRx6E=.241a736a-343c-4ffc-ba0a-d2cd50fa6b49@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>
 <n9pnTwLobj7zDjduh23IIvp5R0qaPzbL0DHIM-XRx6E=.241a736a-343c-4ffc-ba0a-d2cd50fa6b49@github.com>
Message-ID: <Y8SCvTc1Wp0xYVmiPB4YKDNn--6T_jAaJTJgD2caUOc=.72ce333b-2f68-4bf1-8316-37ef8b69ccfc@github.com>

On Wed, 7 May 2025 15:38:41 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed needless brackets
>
> src/java.base/share/classes/java/math/BigInteger.java line 2643:
> 
>> 2641:                     : new BigInteger(result, newSign).shiftLeft(bitsToShift);
>> 2642:         } else {
>> 2643:             if ((bitLength() - 1L) * exponent >= (long) MAX_MAG_LENGTH << 5) {
> 
> Suggestion:
> 
>             if ((bitLength() - 1L) * exponent >= 32L * MAX_MAG_LENGTH) {
> 
> or
> Suggestion:
> 
>             if ((bitLength() - 1L) * exponent >= (long) Integer.SIZE * MAX_MAG_LENGTH) {
> 
> 
> Both variant are easier to read, more honest, and exactly as efficient as with the shift. The right-hand sides are compile-time constants, so they have no impact on runtime performance.
> 
> More generally, the runtime compilers are perfectly capable to optimize multiplications by constant powers of 2 and replace them with shifts, even if the other operand is not a constant.

@rgiulietti What about `(bitLength() - 1L) * exponent >= Integer.MAX_VALUE`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078107104

From duke at openjdk.org  Wed May  7 17:20:33 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Wed, 7 May 2025 17:20:33 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
Message-ID: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>

Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was called on the target library file before it was passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail.

Fix this problem by using `File.getAbsolutePath()` instead of `File.getCanonicalPath()` in `NativeLibraries.java`.

-------------

Commit messages:
 - 8348828: Windows dll loading now resolves symlinks

Changes: https://git.openjdk.org/jdk/pull/24694/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348828
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24694.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694

PR: https://git.openjdk.org/jdk/pull/24694

From duke at openjdk.org  Wed May  7 17:20:33 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Wed, 7 May 2025 17:20:33 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
In-Reply-To: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
Message-ID: <Q7xEuO6Ux7si5G_1kFA6ZeMbQf1TNXWe3z2C9wGuPPo=.b5c28fba-5346-4864-9f5b-85a53459735d@github.com>

On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was called on the target library file before it was passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail.
> 
> Fix this problem by using `File.getAbsolutePath()` instead of `File.getCanonicalPath()` in `NativeLibraries.java`.

by corporate OCA under "EngFlow Inc."

@AlanBateman @bplb Hello! Any chance either of you could be induced to sponsor and review this? Also, any idea how to accelerate the OCA verification process?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2810188272
PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2835812629

From alanb at openjdk.org  Wed May  7 17:20:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 May 2025 17:20:33 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
In-Reply-To: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
Message-ID: <ex5JW1XDoqn81Ft3-5iyNnjUId5X4JnFadoVdzfBiEU=.f960586b-af79-462d-9264-40b7a672cb0d@github.com>

On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was called on the target library file before it was passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail.
> 
> Fix this problem by using `File.getAbsolutePath()` instead of `File.getCanonicalPath()` in `NativeLibraries.java`.

This issue has the "oca" label so we cannot engage, sorry.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2835855589

From duke at openjdk.org  Wed May  7 17:20:33 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Wed, 7 May 2025 17:20:33 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
In-Reply-To: <ex5JW1XDoqn81Ft3-5iyNnjUId5X4JnFadoVdzfBiEU=.f960586b-af79-462d-9264-40b7a672cb0d@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <ex5JW1XDoqn81Ft3-5iyNnjUId5X4JnFadoVdzfBiEU=.f960586b-af79-462d-9264-40b7a672cb0d@github.com>
Message-ID: <Z6N-fyuZlFOPImDYHeJMDOw152xkBcccNbk1GNyAGu4=.bd665056-9d26-4b94-b7a2-214f38767383@github.com>

On Mon, 28 Apr 2025 16:42:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This issue has the "oca" label so we cannot engage, sorry.

Ah, sorry. I only asked because I saw a colleague of yours helping out with OCA verification over at https://github.com/openjdk/jdk/pull/23905#issuecomment-2762865417. Also, the [OCA FAQ](https://oca.opensource.oracle.com/?ojr=faq) suggests to "please reach out to project maintainers (e.g., through comments on your GitHub PR, Slack channels, or mailing lists)". Any breadcrumbs you can lay for me to escape this forest are appreciated!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2836014867

From duke at openjdk.org  Wed May  7 17:20:33 2025
From: duke at openjdk.org (simon)
Date: Wed, 7 May 2025 17:20:33 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
In-Reply-To: <Z6N-fyuZlFOPImDYHeJMDOw152xkBcccNbk1GNyAGu4=.bd665056-9d26-4b94-b7a2-214f38767383@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <ex5JW1XDoqn81Ft3-5iyNnjUId5X4JnFadoVdzfBiEU=.f960586b-af79-462d-9264-40b7a672cb0d@github.com>
 <Z6N-fyuZlFOPImDYHeJMDOw152xkBcccNbk1GNyAGu4=.bd665056-9d26-4b94-b7a2-214f38767383@github.com>
Message-ID: <bYUpkKqmxrf0BGVmyRQvdsmHvz4yH_8Xy8J4P_ZsTMA=.84b8d760-174c-4012-99f2-d57a53b80b8f@github.com>

On Mon, 28 Apr 2025 17:44:31 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

>> This issue has the "oca" label so we cannot engage, sorry.
>
>> This issue has the "oca" label so we cannot engage, sorry.
> 
> Ah, sorry. I only asked because I saw a colleague of yours helping out with OCA verification over at https://github.com/openjdk/jdk/pull/23905#issuecomment-2762865417. Also, the [OCA FAQ](https://oca.opensource.oracle.com/?ojr=faq) suggests to "please reach out to project maintainers (e.g., through comments on your GitHub PR, Slack channels, or mailing lists)". Any breadcrumbs you can lay for me to escape this forest are appreciated!

Hello @benjaminp! I think you should wait for the OCA process ? it's very fast. I'll just ping @robilad, as he might be able to help.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2836349678

From alanb at openjdk.org  Wed May  7 17:31:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 May 2025 17:31:20 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
In-Reply-To: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
Message-ID: <hROk9kr4cW0FJeNuRocS-_SF1IBZ3qJh5YBUwzq961c=.cdf34dad-26fb-4eed-8e03-466a11112601@github.com>

On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was called on the target library file before it was passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail.
> 
> Fix this problem by using `File.getAbsolutePath()` instead of `File.getCanonicalPath()` in `NativeLibraries.java`.

Are you the submitter of JDK-8348828? Asking because the configuration described seems very unusual and sounds like something that changed the JDK image so the DLLs from the JDK bin directory are moved to somewhere else and sym link put in place instead. I think we also need to understand if there is a bug in File::getCanonicalPath before change the usage.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2859466053

From rgiulietti at openjdk.org  Wed May  7 17:39:20 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 May 2025 17:39:20 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51]
In-Reply-To: <Y8SCvTc1Wp0xYVmiPB4YKDNn--6T_jAaJTJgD2caUOc=.72ce333b-2f68-4bf1-8316-37ef8b69ccfc@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>
 <n9pnTwLobj7zDjduh23IIvp5R0qaPzbL0DHIM-XRx6E=.241a736a-343c-4ffc-ba0a-d2cd50fa6b49@github.com>
 <Y8SCvTc1Wp0xYVmiPB4YKDNn--6T_jAaJTJgD2caUOc=.72ce333b-2f68-4bf1-8316-37ef8b69ccfc@github.com>
Message-ID: <p13Ns4IjLQBzWf--1shwwAp3GaxvEnr9l7DdhpB9uPk=.e5877744-c567-45d1-922f-9eb797f35885@github.com>

On Wed, 7 May 2025 17:14:19 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 2643:
>> 
>>> 2641:                     : new BigInteger(result, newSign).shiftLeft(bitsToShift);
>>> 2642:         } else {
>>> 2643:             if ((bitLength() - 1L) * exponent >= (long) MAX_MAG_LENGTH << 5) {
>> 
>> Suggestion:
>> 
>>             if ((bitLength() - 1L) * exponent >= 32L * MAX_MAG_LENGTH) {
>> 
>> or
>> Suggestion:
>> 
>>             if ((bitLength() - 1L) * exponent >= (long) Integer.SIZE * MAX_MAG_LENGTH) {
>> 
>> 
>> Both variant are easier to read, more honest, and exactly as efficient as with the shift. The right-hand sides are compile-time constants, so they have no impact on runtime performance.
>> 
>> More generally, the runtime compilers are perfectly capable to optimize multiplications by constant powers of 2 and replace them with shifts, even if the other operand is not a constant.
>
> @rgiulietti What about `(bitLength() - 1L) * exponent >= Integer.MAX_VALUE`?

Ah right, but you probably want
Suggestion:

            if ((bitLength() - 1L) * exponent > Integer.MAX_VALUE) {

I mean `>` rather than `>=`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078138621

From duke at openjdk.org  Wed May  7 17:39:21 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 7 May 2025 17:39:21 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51]
In-Reply-To: <p13Ns4IjLQBzWf--1shwwAp3GaxvEnr9l7DdhpB9uPk=.e5877744-c567-45d1-922f-9eb797f35885@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>
 <n9pnTwLobj7zDjduh23IIvp5R0qaPzbL0DHIM-XRx6E=.241a736a-343c-4ffc-ba0a-d2cd50fa6b49@github.com>
 <Y8SCvTc1Wp0xYVmiPB4YKDNn--6T_jAaJTJgD2caUOc=.72ce333b-2f68-4bf1-8316-37ef8b69ccfc@github.com>
 <p13Ns4IjLQBzWf--1shwwAp3GaxvEnr9l7DdhpB9uPk=.e5877744-c567-45d1-922f-9eb797f35885@github.com>
Message-ID: <qwYzwD80Mpsp5aAyQ1lIUXV4Tak08PNwoZsYL6LPPqg=.cc449ee0-4814-44dc-ba9b-414b7e5a750d@github.com>

On Wed, 7 May 2025 17:32:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Ah right, but you probably want

No, the sufficient condition to get the overflow is `(bitLength() - 1L) * exponent + 1L > Integer.MAX_VALUE`, which is equivalent to that one I wrote above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078142049

From rgiulietti at openjdk.org  Wed May  7 17:46:19 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 May 2025 17:46:19 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51]
In-Reply-To: <qwYzwD80Mpsp5aAyQ1lIUXV4Tak08PNwoZsYL6LPPqg=.cc449ee0-4814-44dc-ba9b-414b7e5a750d@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>
 <n9pnTwLobj7zDjduh23IIvp5R0qaPzbL0DHIM-XRx6E=.241a736a-343c-4ffc-ba0a-d2cd50fa6b49@github.com>
 <Y8SCvTc1Wp0xYVmiPB4YKDNn--6T_jAaJTJgD2caUOc=.72ce333b-2f68-4bf1-8316-37ef8b69ccfc@github.com>
 <p13Ns4IjLQBzWf--1shwwAp3GaxvEnr9l7DdhpB9uPk=.e5877744-c567-45d1-922f-9eb797f35885@github.com>
 <qwYzwD80Mpsp5aAyQ1lIUXV4Tak08PNwoZsYL6LPPqg=.cc449ee0-4814-44dc-ba9b-414b7e5a750d@github.com>
Message-ID: <F4OsBgEi7KkoRhmdeV4uohqK8xJYSvmFbkHyIoAmPwg=.a35307c7-06cd-45d5-aec8-8239f6ca6e85@github.com>

On Wed, 7 May 2025 17:34:27 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Ah right, but you probably want
>> Suggestion:
>> 
>>             if ((bitLength() - 1L) * exponent > Integer.MAX_VALUE) {
>> 
>> I mean `>` rather than `>=`
>
>> Ah right, but you probably want
> 
> No, the sufficient condition to get the overflow is `(bitLength() - 1L) * exponent + 1L > Integer.MAX_VALUE`, which is equivalent to that one I wrote above.

At some point you proposed

(bitLength() - 1L) * exponent >= (long) MAX_MAG_LENGTH << 5

Given the value of `MAX_MAG_LENGTH`, which is 2^26, this is equivalent to

(bitLength() - 1L) * exponent >= 1L << 31

that is, to

(bitLength() - 1L) * exponent > Integer.MAX_VALUE


What am I missing?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078163320

From lancea at openjdk.org  Wed May  7 17:46:28 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 7 May 2025 17:46:28 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v6]
In-Reply-To: <Uvb8haTDHaSUlFccwMonvOOpnMogpbjr2KpffroxpmQ=.0e863939-4729-4ab6-9d67-f276570e9084@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <Uvb8haTDHaSUlFccwMonvOOpnMogpbjr2KpffroxpmQ=.0e863939-4729-4ab6-9d67-f276570e9084@github.com>
Message-ID: <kqx3sTJHVWdZpzTKzo7Ak7bYnBJqbLD1hkkJtK4okwg=.e26d85ff-7ea4-40e1-8593-dd424a0739de@github.com>

On Tue, 6 May 2025 18:21:30 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore Validator access level

Hi Henry,

Thank you for tackling this one.  I am still going through this but have some initial comments on my 1st pass

Can you also please address the following in jar.properties:

-  remove the duplicate entry of `main.help.opt.extract `
- update `main.help.opt.main.validate` to document the additional actions --validate now takes

We also need to update `open/src/jdk.jartool/share/man/jar.md` as it currently contains no mentions of the `--validate `option

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 120:

> 118:     /**
> 119:      * Helper class to deduplicate entry names.
> 120:      * Keep a coutner for duplicate entry names and check if the entry name is valid on first add.

counter -> counter

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 122:

> 120:      * Keep a coutner for duplicate entry names and check if the entry name is valid on first add.
> 121:      */
> 122:     private class DedupEntryNames {

Need a better name for this class as it is hard to understand what its purpose is from the name

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 122:

> 120:      * Keep a coutner for duplicate entry names and check if the entry name is valid on first add.
> 121:      */
> 122:     private class DedupEntryNames {

This class and some of its methods I would rename as it is difficult to understand what their purpose is and this will help future maintainers

There also needs to be more meaningful class documentation given how the class/methods are used

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 124:

> 122:     private class DedupEntryNames {
> 123:         LinkedHashMap<String, Integer> entries = new LinkedHashMap<>();
> 124:         boolean isCEN;

An enum might be clearer vs using a boolean for clarity

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 127:

> 125: 
> 126:         public DedupEntryNames(boolean isCEN) {
> 127:             this.isCEN = isCEN;

Might be clearer if this was an enum vs boolean?

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 135:

> 133:                 isValid = false;
> 134:             } else if (!isZipEntryNameValid(entryName)) {
> 135:                 warn(formatMsg("error.validator.bad.entry.name", entryName));

I think we need to consider a better message as 'malformed' might not be clear enough (also looks like this message was added but not used previously)


error.validator.bad.entry.name=\
        entry name malformed, {0}

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 135:

> 133:                 isValid = false;
> 134:             } else if (!isZipEntryNameValid(entryName)) {
> 135:                 warn(formatMsg("error.validator.bad.entry.name", entryName));

This message for `error.validator.bad.entry.name` could be clearer as  I don't think "malformed" indicating the issues with the file name entry in the CEN/LOC Header.  We should also prefix it a "Warning:"

 `entry name malformed, {0}`

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 147:

> 145:                 warn(formatMsg(msg, count.toString(), counter.getKey()));
> 146:             }
> 147:             return true;

This seems to always be true as `warn()` results in `err.println` call (unless I am missing something)

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 150:

> 148:         }
> 149: 
> 150:         public LinkedList<String> dedup() {

Need a better method name and a comment for the method would be helpful for future maintainers

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 169:

> 167: 
> 168:     // Check next CEN entry is matching the specified name
> 169:     private boolean checkNextCenEntry(String locEntryName, LinkedList<String> cenEntryNames) {

The method description and method name could be clearer as to its purpose

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 184:

> 182: 
> 183:     /*
> 184:      * Retrieve entries from the XipInputStream to verify local file headers(LOC)

XipInputStream -> ZipInputStream

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 184:

> 182: 
> 183:     /*
> 184:      * Retrieve entries from the XipInputStream to verify local file headers(LOC)

Typo: `XipInputStream`

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 215:

> 213:     private boolean validate() {
> 214:         try {
> 215:             var dedupCEN = new DedupEntryNames(true);

Please use a more insightful variable name

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 217:

> 215:             var dedupCEN = new DedupEntryNames(true);
> 216:             zf.stream()
> 217:               .peek(e -> dedupCEN.add(e.getName()))

I am wondering if it might be clearer to consider breaking the above into a separate step for clarity vs part of the current stream traversal?  Otherwise  there should be more comments added for future maintainers

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 147:

> 145:         in incompatible public interfaces
> 146: warn.validator.duplicate.cen.entry=\
> 147:         Warning: {0} copies of {1} is detected in central directory

I would change:

`Warning: {0} copies of {1} is detected in central directory`
to:
`Warning: There were {0}  central directory headers found  for  file name {1} `

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 148:

> 146: warn.validator.duplicate.cen.entry=\
> 147:         Warning: {0} copies of {1} is detected in central directory
> 148: warn.validator.duplicate.loc.entry=\

Same comment as for `warn.validator.duplicate.cen.entry`

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 150:

> 148: warn.validator.duplicate.loc.entry=\
> 149:         Warning: {0} copies of {1} is detected in local file header
> 150: warn.validator.cen.only.entry=\

I would change

`Warning: Entry {0} in central directory is not in local file header`
to
`Warning:  An equivalent local file header was not found  for the central directory header for the file name: {0} `

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 151:

> 149:         Warning: {0} copies of {1} is detected in local file header
> 150: warn.validator.cen.only.entry=\
> 151:         Warning: Entry {0} in central directory is not in local file header

I would change the above to something like:

Warning: An equivalent  Local File header record  for  the  Central Directory Header record  for file {0} was not found

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 152:

> 150: warn.validator.cen.only.entry=\
> 151:         Warning: Entry {0} in central directory is not in local file header
> 152: warn.validator.loc.only.entry=\

Same comment as for `warn.validator.duplicate.loc.entry`

test/jdk/tools/jar/ValidatorTest.java line 106:

> 104:         var template = out.toByteArray();
> 105:         // ISO_8859_1 to keep the 8-bit value
> 106:         var s = new String(template, StandardCharsets.ISO_8859_1);

Is there a reason you are not using UTF8 here  given that is the charset being used for the zip creation?

test/jdk/tools/jar/ValidatorTest.java line 145:

> 143:         var template = out.toByteArray();
> 144:         // ISO_8859_1 to keep the 8-bit value
> 145:         var s = new String(template, StandardCharsets.ISO_8859_1);

Ok, but the zip is being created using UTF_8....

test/jdk/tools/jar/ValidatorTest.java line 232:

> 230:             var err = e.getMessage();
> 231:             System.out.println(err);
> 232:             Assertions.assertTrue(err.contains("Warning: 2 copies of META-INF/MANIFEST.MF is detected in local file header"));

Given you are importing Assertions, you should be able to just use `assertTrue`

-------------

PR Review: https://git.openjdk.org/jdk/pull/24430#pullrequestreview-2819609944
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076261620
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076262727
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077860557
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076291444
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078105322
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076275933
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077910292
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078098847
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076276973
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076281636
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076283433
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077916062
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077909330
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077908477
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078106177
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078078764
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078088807
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076319729
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078089755
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077731161
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078159472
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078131560

From duke at openjdk.org  Wed May  7 17:54:20 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 7 May 2025 17:54:20 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51]
In-Reply-To: <F4OsBgEi7KkoRhmdeV4uohqK8xJYSvmFbkHyIoAmPwg=.a35307c7-06cd-45d5-aec8-8239f6ca6e85@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>
 <n9pnTwLobj7zDjduh23IIvp5R0qaPzbL0DHIM-XRx6E=.241a736a-343c-4ffc-ba0a-d2cd50fa6b49@github.com>
 <Y8SCvTc1Wp0xYVmiPB4YKDNn--6T_jAaJTJgD2caUOc=.72ce333b-2f68-4bf1-8316-37ef8b69ccfc@github.com>
 <p13Ns4IjLQBzWf--1shwwAp3GaxvEnr9l7DdhpB9uPk=.e5877744-c567-45d1-922f-9eb797f35885@github.com>
 <qwYzwD80Mpsp5aAyQ1lIUXV4Tak08PNwoZsYL6LPPqg=.cc449ee0-4814-44dc-ba9b-414b7e5a750d@github.com>
 <F4OsBgEi7KkoRhmdeV4uohqK8xJYSvmFbkHyIoAmPwg=.a35307c7-06cd-45d5-aec8-8239f6ca6e85@github.com>
Message-ID: <XJoCoHvSpVlNyLXkCJ9y2f0i0N8Z1U5y6qNq0YHITNg=.bf7afdf6-cd56-4e36-8b40-e9a714043d68@github.com>

On Wed, 7 May 2025 17:43:30 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>>> Ah right, but you probably want
>> 
>> No, the sufficient condition to get the overflow is `(bitLength() - 1L) * exponent + 1L > Integer.MAX_VALUE`, which is equivalent to that one I wrote above.
>
> At some point you proposed
> 
> (bitLength() - 1L) * exponent >= (long) MAX_MAG_LENGTH << 5
> 
> Given the value of `MAX_MAG_LENGTH`, which is 2^26, this is equivalent to
> 
> (bitLength() - 1L) * exponent >= 1L << 31
> 
> that is, to
> 
> (bitLength() - 1L) * exponent > Integer.MAX_VALUE
> 
> 
> What am I missing?

The condition `A := (bitLength() - 1L) * exponent + 1L > Integer.MAX_VALUE` is more accurate, as it compares the bit length of the result, in fact `B := (bitLength() - 1L) * exponent >= (long) MAX_MAG_LENGTH << 5` implies `A`, but `A` does not imply `B`. The `BigInteger`s can have a mag length up to `MAX_MAG_LENGTH`, but `MAX_MAG_LENGTH * Integer.SIZE > Integer.MAX_VALUE`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078174586

From rgiulietti at openjdk.org  Wed May  7 18:01:25 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 May 2025 18:01:25 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51]
In-Reply-To: <XJoCoHvSpVlNyLXkCJ9y2f0i0N8Z1U5y6qNq0YHITNg=.bf7afdf6-cd56-4e36-8b40-e9a714043d68@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>
 <n9pnTwLobj7zDjduh23IIvp5R0qaPzbL0DHIM-XRx6E=.241a736a-343c-4ffc-ba0a-d2cd50fa6b49@github.com>
 <Y8SCvTc1Wp0xYVmiPB4YKDNn--6T_jAaJTJgD2caUOc=.72ce333b-2f68-4bf1-8316-37ef8b69ccfc@github.com>
 <p13Ns4IjLQBzWf--1shwwAp3GaxvEnr9l7DdhpB9uPk=.e5877744-c567-45d1-922f-9eb797f35885@github.com>
 <qwYzwD80Mpsp5aAyQ1lIUXV4Tak08PNwoZsYL6LPPqg=.cc449ee0-4814-44dc-ba9b-414b7e5a750d@github.com>
 <F4OsBgEi7KkoRhmdeV4uohqK8xJYSvmFbkHyIoAmPwg=.a35307c7-06cd-45d5-aec8-8239f6ca6e85@github.com>
 <XJoCoHvSpVlNyLXkCJ9y2f0i0N8Z1U5y6qNq0YHITNg=.bf7afdf6-cd56-4e36-8b40-e9a714043d68@github.com>
Message-ID: <ShmpUK2ujLHpziTThQ-SRgh6v7H35QhDGlQSUZXkyzY=.c2761581-93e5-41dd-a1c8-0bd2f8b7c715@github.com>

On Wed, 7 May 2025 17:51:05 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> At some point you proposed
>> 
>> (bitLength() - 1L) * exponent >= (long) MAX_MAG_LENGTH << 5
>> 
>> Given the value of `MAX_MAG_LENGTH`, which is 2^26, this is equivalent to
>> 
>> (bitLength() - 1L) * exponent >= 1L << 31
>> 
>> that is, to
>> 
>> (bitLength() - 1L) * exponent > Integer.MAX_VALUE
>> 
>> 
>> What am I missing?
>
> The condition `A := (bitLength() - 1L) * exponent + 1L > Integer.MAX_VALUE` is more accurate, as it compares the bit length of the result, in fact `B := (bitLength() - 1L) * exponent >= (long) MAX_MAG_LENGTH << 5` implies `A`, but `A` does not imply `B`. The `BigInteger`s can have a mag length up to `MAX_MAG_LENGTH`, but `MAX_MAG_LENGTH * Integer.SIZE > Integer.MAX_VALUE`.

OK.

But then your original expression

(((bitLength() - 1L) * exponent) >>> 5) + 1L > MAX_MAG_LENGTH

was a bit too restrictive as well, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078191934

From henryjen at openjdk.org  Wed May  7 18:02:33 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 7 May 2025 18:02:33 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v6]
In-Reply-To: <kqx3sTJHVWdZpzTKzo7Ak7bYnBJqbLD1hkkJtK4okwg=.e26d85ff-7ea4-40e1-8593-dd424a0739de@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <Uvb8haTDHaSUlFccwMonvOOpnMogpbjr2KpffroxpmQ=.0e863939-4729-4ab6-9d67-f276570e9084@github.com>
 <kqx3sTJHVWdZpzTKzo7Ak7bYnBJqbLD1hkkJtK4okwg=.e26d85ff-7ea4-40e1-8593-dd424a0739de@github.com>
Message-ID: <eF015vnVzEp-5sqCQ9q6hmfE_AVQbCmJkNcoSG7BTrc=.9a91c482-3db5-4db9-9e28-eec44cdefe3c@github.com>

On Wed, 7 May 2025 17:13:19 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore Validator access level
>
> src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 127:
> 
>> 125: 
>> 126:         public DedupEntryNames(boolean isCEN) {
>> 127:             this.isCEN = isCEN;
> 
> Might be clearer if this was an enum vs boolean?

I feel the same way but wondering if that's an overkill.

> src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 147:
> 
>> 145:                 warn(formatMsg(msg, count.toString(), counter.getKey()));
>> 146:             }
>> 147:             return true;
> 
> This seems to always be true as `warn()` results in `err.println` call (unless I am missing something)

I should clean that up better. As we just want to show the message but not really filter out that entry.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078195738
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078193636

From duke at openjdk.org  Wed May  7 18:04:17 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 7 May 2025 18:04:17 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51]
In-Reply-To: <ShmpUK2ujLHpziTThQ-SRgh6v7H35QhDGlQSUZXkyzY=.c2761581-93e5-41dd-a1c8-0bd2f8b7c715@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>
 <n9pnTwLobj7zDjduh23IIvp5R0qaPzbL0DHIM-XRx6E=.241a736a-343c-4ffc-ba0a-d2cd50fa6b49@github.com>
 <Y8SCvTc1Wp0xYVmiPB4YKDNn--6T_jAaJTJgD2caUOc=.72ce333b-2f68-4bf1-8316-37ef8b69ccfc@github.com>
 <p13Ns4IjLQBzWf--1shwwAp3GaxvEnr9l7DdhpB9uPk=.e5877744-c567-45d1-922f-9eb797f35885@github.com>
 <qwYzwD80Mpsp5aAyQ1lIUXV4Tak08PNwoZsYL6LPPqg=.cc449ee0-4814-44dc-ba9b-414b7e5a750d@github.com>
 <F4OsBgEi7KkoRhmdeV4uohqK8xJYSvmFbkHyIoAmPwg=.a35307c7-06cd-45d5-aec8-8239f6ca6e85@github.com>
 <XJoCoHvSpVlNyLXkCJ9y2f0i0N8Z1U5y6qNq0YHITNg=.bf7afdf6-cd56-4e36-8b40-e9a714043d68@github.com>
 <ShmpUK2ujLHpziTThQ-SRgh6v7H35QhDGlQSUZXkyzY=.c2761581-93e5-41dd-a1c8-0bd2f8b7c715@github.com>
Message-ID: <_alUFmxGCBuvqwe_2W-RKieexFHvhBz5LSxUHxAWcTY=.5a60a1b1-050a-46fd-993f-109b85768f82@github.com>

On Wed, 7 May 2025 17:58:11 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> OK.
> 
> But then your original expression
> 
> ```
> (((bitLength() - 1L) * exponent) >>> 5) + 1L > MAX_MAG_LENGTH
> ```
> 
> was a bit too restrictive as well, right?

On the contrary, it was too loose, as it admitted a  bit length equal to `2^31 > Integer.MAX_VALUE`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078197555

From rgiulietti at openjdk.org  Wed May  7 18:12:41 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 May 2025 18:12:41 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51]
In-Reply-To: <_alUFmxGCBuvqwe_2W-RKieexFHvhBz5LSxUHxAWcTY=.5a60a1b1-050a-46fd-993f-109b85768f82@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>
 <n9pnTwLobj7zDjduh23IIvp5R0qaPzbL0DHIM-XRx6E=.241a736a-343c-4ffc-ba0a-d2cd50fa6b49@github.com>
 <Y8SCvTc1Wp0xYVmiPB4YKDNn--6T_jAaJTJgD2caUOc=.72ce333b-2f68-4bf1-8316-37ef8b69ccfc@github.com>
 <p13Ns4IjLQBzWf--1shwwAp3GaxvEnr9l7DdhpB9uPk=.e5877744-c567-45d1-922f-9eb797f35885@github.com>
 <qwYzwD80Mpsp5aAyQ1lIUXV4Tak08PNwoZsYL6LPPqg=.cc449ee0-4814-44dc-ba9b-414b7e5a750d@github.com>
 <F4OsBgEi7KkoRhmdeV4uohqK8xJYSvmFbkHyIoAmPwg=.a35307c7-06cd-45d5-aec8-8239f6ca6e85@github.com>
 <XJoCoHvSpVlNyLXkCJ9y2f0i0N8Z1U5y6qNq0YHITNg=.bf7afdf6-cd56-4e36-8b40-e9a714043d68@github.com>
 <ShmpUK2ujLHpziTThQ-SRgh6v7H35QhDGlQSUZXkyzY=.c2761581-93e5-41dd-a1c8-0bd2f8b7c715@github.com>
 <_alUFmxGCBuvqwe_2W-RKieexFHvhBz5LSxUHxAWcTY=.5a60a1b1-050a-46fd-993f-109b85768f82@github.com>
Message-ID: <qlaE7L4pyfPfR9WDFjt7qnAB4tO_KDXRmdgKcRNTWOg=.1b9e8702-1f7c-4aa7-a474-47e721ca0c78@github.com>

On Wed, 7 May 2025 18:01:24 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> OK.
>> 
>> But then your original expression
>> 
>> (((bitLength() - 1L) * exponent) >>> 5) + 1L > MAX_MAG_LENGTH
>> 
>> was a bit too restrictive as well, right?
>
>> OK.
>> 
>> But then your original expression
>> 
>> ```
>> (((bitLength() - 1L) * exponent) >>> 5) + 1L > MAX_MAG_LENGTH
>> ```
>> 
>> was a bit too restrictive as well, right?
> 
> On the contrary, it was too loose, as it admitted a  bit length equal to `MAX_MAG_LENGTH * Integer.SIZE == 2^31 > Integer.MAX_VALUE`.

I mean, if B strictly implies A, then B is more restrictive (stronger).
Since B is equivalent to your original formulation, to me it means that it was more restrictive.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078218931

From abimpoudis at openjdk.org  Wed May  7 18:30:59 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 7 May 2025 18:30:59 GMT
Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used
 outside the compiler
In-Reply-To: <5mcBz7IvDNxwrQJh9EjP-gKejbWG92idqojhc0MXjI8=.68a4d03a-5af9-430a-96de-20c8775d1dce@github.com>
References: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
 <5mcBz7IvDNxwrQJh9EjP-gKejbWG92idqojhc0MXjI8=.68a4d03a-5af9-430a-96de-20c8775d1dce@github.com>
Message-ID: <EvPAXLk3WRoKdedYMVOu50tlAcK2frdzS9V8_XYA178=.4b72d568-299c-4b64-b27c-dc556ff225cf@github.com>

On Wed, 7 May 2025 16:36:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation.
>> 
>> For example this is not valid Java (and protected) by javac:
>> 
>> 
>> byte b = 1;
>> switch (b) {
>>     case String s -> System.out.println("How did we get here? byte is " + s.getClass());
>> }
>> 
>> 
>> but this is a valid call (and not protected):
>> 
>> 
>> CallSite shortSwitch = SwitchBootstraps.typeSwitch(
>>     MethodHandles.lookup(), 
>>     "", 
>>     MethodType.methodType(int.class, short.class, int.class),  // models (short, int) -> int
>>     String.class);
>> 
>> 
>> The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. 
>> 
>> This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 553:
> 
>> 551:                         continue;
>> 552:                     }
>> 553:                     else if (unconditionalExactnessCheck(selectorType, classLabel)) {
> 
> Can we merge this into `isNotValidPair(...) || unconditionalExactnessCheck(...)` then do nothing? The next label is already in theory immediately bound to the instruction after goto.

The empty body means that we unconditionally return the index `case 0 -> /*no if is generated*/ return 0;`.

I confirmed that by merging, the following test would not pass. It returns erroneously 0, instead of 1.


testPrimitiveType((byte) 1, byte.class,0, 1, boolean.class, byte.class);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2078206536

From liach at openjdk.org  Wed May  7 18:31:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 18:31:18 GMT
Subject: RFR: 8356126: Duplication handling and optimization of
 CaptureCallState [v9]
In-Reply-To: <9gn1nMQxoXSqk7Hpa1luMl8fAQdRJcdqm7s9YpZaGCw=.300a6c90-a049-42d0-95c2-d2279c8dca38@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
 <9gn1nMQxoXSqk7Hpa1luMl8fAQdRJcdqm7s9YpZaGCw=.300a6c90-a049-42d0-95c2-d2279c8dca38@github.com>
Message-ID: <2jO8bdVw7tAbJUIXsupJ8WMxlS0xafpPLMyK9cFvXXE=.38591311-e87f-4ab6-b786-dd10ae2ac286@github.com>

On Tue, 6 May 2025 22:11:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
>> 
>> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
>> 
>> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
>> 
>> Testing: jdk/lang/foreign, tier 1-3 in progress.
>
> Chen Liang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Indicate source file
>  - Keep in sync comments

Seems there is no new reviews. Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25025#issuecomment-2859734901

From liach at openjdk.org  Wed May  7 18:31:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 18:31:21 GMT
Subject: Integrated: 8356126: Duplication handling and optimization of
 CaptureCallState
In-Reply-To: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
References: <qYVqOtu-dzhGeRNbtOxLPWhNvi8FvKBGW0_nyO_OyJc=.fe69a0e7-aaf9-4e7c-86a2-a2c21982da27@github.com>
Message-ID: <kp6e-Zg5ug2gJmcB5T8VM9CPP8Y2TRonuZ_ljATsf10=.0c831349-45e1-4fb6-8a1d-ff1e2b6a5631@github.com>

On Sun, 4 May 2025 22:37:21 GMT, Chen Liang <liach at openjdk.org> wrote:

> Credit to @lukellmann that the duplication arg handling in #24742 avoided throwing exceptions but produced a wrong option. This patch fixes that and removed stream usages in CaptureCallState to speed up bootstrap.
> 
> Also, the previous patch affected the toString display of the option; I added a unit test to ensure the option prints names that is user-friendly.
> 
> Another thing I noted is `CapturableState` uses `OperatingSystem`; using `valueOf` brings a performance overhead due to setups with reflection, so I made this lazy. (The enum is thread safe, so we allow racy access to the cache field)
> 
> Testing: jdk/lang/foreign, tier 1-3 in progress.

This pull request has now been integrated.

Changeset: 8c1b915c
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c1b915c7ef2b3a6e65705b91f4eb464caaec4e7
Stats:     128 lines in 7 files changed: 37 ins; 44 del; 47 mod

8356126: Duplication handling and optimization of CaptureCallState

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/25025

From duke at openjdk.org  Wed May  7 18:32:50 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 7 May 2025 18:32:50 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v53]
In-Reply-To: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
Message-ID: <416Ep8OzMrQzitAI-WaIkgbhu7RAcriT9W63DZyblLc=.28549efe-7c6c-4a29-be36-df35f20d6035@github.com>

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Suggested changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/e0816d55..009937b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=52
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=51-52

  Stats: 64 lines in 2 files changed: 29 ins; 29 del; 6 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 May  7 18:32:50 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 7 May 2025 18:32:50 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v51]
In-Reply-To: <qlaE7L4pyfPfR9WDFjt7qnAB4tO_KDXRmdgKcRNTWOg=.1b9e8702-1f7c-4aa7-a474-47e721ca0c78@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <GgzrTsD2xfdwmdVXPkzF9m3ZwYGcFEQksTYJ7_EyAI4=.0222b6af-8635-4bfa-b434-0216c5d0c3be@github.com>
 <n9pnTwLobj7zDjduh23IIvp5R0qaPzbL0DHIM-XRx6E=.241a736a-343c-4ffc-ba0a-d2cd50fa6b49@github.com>
 <Y8SCvTc1Wp0xYVmiPB4YKDNn--6T_jAaJTJgD2caUOc=.72ce333b-2f68-4bf1-8316-37ef8b69ccfc@github.com>
 <p13Ns4IjLQBzWf--1shwwAp3GaxvEnr9l7DdhpB9uPk=.e5877744-c567-45d1-922f-9eb797f35885@github.com>
 <qwYzwD80Mpsp5aAyQ1lIUXV4Tak08PNwoZsYL6LPPqg=.cc449ee0-4814-44dc-ba9b-414b7e5a750d@github.com>
 <F4OsBgEi7KkoRhmdeV4uohqK8xJYSvmFbkHyIoAmPwg=.a35307c7-06cd-45d5-aec8-8239f6ca6e85@github.com>
 <XJoCoHvSpVlNyLXkCJ9y2f0i0N8Z1U5y6qNq0YHITNg=.bf7afdf6-cd56-4e36-8b40-e9a714043d68@github.com>
 <ShmpUK2ujLHpziTThQ-SRgh6v7H35QhDGlQSUZXkyzY=.c2761581-93e5-41dd-a1c8-0bd2f8b7c715@github.com>
 <_alUFmxGCBuvqwe_2W-RKieexFHvhBz5LSxUHxAWcTY=.5a60a1b1-050a-46fd-993f-109b85768f82@github.com>
 <qlaE7L4pyfPfR9WDFjt7qnAB4tO_KDXRmdg
 KcRNTWOg=.1b9e8702-1f7c-4aa7-a474-47e721ca0c78@github.com>
Message-ID: <HieXqHgqUz68aAFGQuXjFzmTGwoOKYxHlt257Q9EBSQ=.84674c80-8264-49fa-afd0-57231fe1ed20@github.com>

On Wed, 7 May 2025 18:10:36 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> I mean, if B strictly implies A, then B is more restrictive (stronger). Since B is equivalent to your original formulation, to me it means that it was more restrictive.

Exactly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2078224687

From kbarrett at openjdk.org  Wed May  7 18:33:08 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 7 May 2025 18:33:08 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v5]
In-Reply-To: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
Message-ID: <QH_8kqEb66kcuxbxezRuc4EmoOrQ3MswIjgQgmYPJUA=.e2418215-727b-43b2-b238-698d68bcfc77@github.com>

> 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 with a new target base 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:

 - use new waitForRefProc, some tidying
 - Merge branch 'master' into native-reference-get
 - remove timeout by using waitForReferenceProcessing
 - make ill-timed gc in non-concurrent case less likely
 - fix test package use
 - add package decl to test
 - parameterized return type of native get0
 - test native method
 - native Reference.get helper

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24315/files
  - new: https://git.openjdk.org/jdk/pull/24315/files/234465f4..48b7960c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=03-04

  Stats: 334519 lines in 3461 files changed: 113842 ins; 207130 del; 13547 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 vyazici at openjdk.org  Wed May  7 18:33:12 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 May 2025 18:33:12 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v2]
In-Reply-To: <bI_IZirW_8IhUnO_nVTVt135X9GDoVm63JdOEqKWweU=.a57bcfea-ceab-4ad4-b288-41728f5b4c47@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <l3xoBLwwsAQrpneEdTdtlnrC7dOit7jokk7wLettH14=.472e261e-894b-44d2-a8cb-c34df74aeb43@github.com>
 <9IfMW-HLFSI8eeAfs6m3jZyfpzGRhnutoTgYFripC4U=.f84019f8-30d4-43ce-857a-6f3d71bfd713@github.com>
 <bI_IZirW_8IhUnO_nVTVt135X9GDoVm63JdOEqKWweU=.a57bcfea-ceab-4ad4-b288-41728f5b4c47@github.com>
Message-ID: <e0Xmzz6GnSeh3tRg-1enMntnx5II2eMDb9oZGMlcW34=.4501f464-02f8-4d23-97a0-7a3d77b95961@github.com>

On Wed, 7 May 2025 13:22:11 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 355:
>> 
>>> 353:      * UTF-16 representation.
>>> 354:      * <p>
>>> 355:      * <b>WARNING: This method does not perform any bound checks.</b>
>> 
>> Maybe not this PR but this method is begging to be renamed. It's really hard to audit usage when the method is accessible to faraway code via shared secrets. So maybe not this PR but I think we need an issue in JBS to track renaming, I think Stuart suggested prefixing with "unchecked".
>
> As mentioned by Alan and Jaikiran, at some point it is advisable to prefix the names with "unchecked".
> 
> For the "noRepl" names, perhaps the mouthful but clearer "noReplacementChar" might help.

@jaikiran, @AlanBateman, implemented `unchecked` method prefix in 4d237efa053.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2078253548

From vyazici at openjdk.org  Wed May  7 18:33:11 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 May 2025 18:33:11 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v3]
In-Reply-To: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
Message-ID: <vfrf8Cx8oHAF4JpUITn4iqppXgIKVXzWBKojA_t4TqE=.8fb827e3-e60d-42e4-919b-f18f310694bf@github.com>

> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Prefix touched methods with `unchecked`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24982/files
  - new: https://git.openjdk.org/jdk/pull/24982/files/f0623258..4d237efa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=01-02

  Stats: 66 lines in 21 files changed: 0 ins; 3 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/24982.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24982/head:pull/24982

PR: https://git.openjdk.org/jdk/pull/24982

From vyazici at openjdk.org  Wed May  7 18:39:42 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 May 2025 18:39:42 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v2]
In-Reply-To: <CFt4DC6En9ErWBA__-tbOItlFmaXYN-rAvmaUfj-UzM=.60937a93-f095-47e6-ae63-aa89a1ac2e5f@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <l3xoBLwwsAQrpneEdTdtlnrC7dOit7jokk7wLettH14=.472e261e-894b-44d2-a8cb-c34df74aeb43@github.com>
 <CFt4DC6En9ErWBA__-tbOItlFmaXYN-rAvmaUfj-UzM=.60937a93-f095-47e6-ae63-aa89a1ac2e5f@github.com>
Message-ID: <Bxws5jpAA2Bp1uIxyXbOucwZjFuqbr-ycQdlZO7KDWw=.4eb84156-5a27-4f1c-8b7a-2f1306103aeb@github.com>

On Wed, 7 May 2025 07:52:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in pre-existing JavaDoc
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 332:
> 
>> 330:      * <p>
>> 331:      * This method throws {@code CharacterCodingException} instead of replacing
>> 332:      * when malformed input or unmappable characters are encountered.
> 
> Do we have a JBS issue to track renaming the "no replacement" methods? The naming has confused several people as not everyone is familiar with coding error actions.  Here, "no replacement" actually means that coding errors are reported.

Created [JDK-8356439](https://bugs.openjdk.org/browse/JDK-8356439) for this purpose.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2078269984

From duke at openjdk.org  Wed May  7 18:43:57 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Wed, 7 May 2025 18:43:57 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
In-Reply-To: <hROk9kr4cW0FJeNuRocS-_SF1IBZ3qJh5YBUwzq961c=.cdf34dad-26fb-4eed-8e03-466a11112601@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <hROk9kr4cW0FJeNuRocS-_SF1IBZ3qJh5YBUwzq961c=.cdf34dad-26fb-4eed-8e03-466a11112601@github.com>
Message-ID: <mENNrnMBLYdpUX1q_yWQOcLRqH6q1DKPe4w6nyy9HC4=.b8118419-463c-4b75-82c6-cf0c79e7ce31@github.com>

On Wed, 7 May 2025 17:28:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Are you the submitter of JDK-8348828?

Yes, I am.

> Asking because the configuration described seems very unusual and sounds like something that changed the JDK image so the DLLs from the JDK bin directory are moved to somewhere else and sym link put in place instead.

Correct, I explained a bit on the issue, but we have a system that replicates normal filesystem trees with symlink trees.

> I think we also need to understand if there is a bug in File::getCanonicalPath before change the usage.

I believe the problem is that `getCanonicalPath` is working too well and that symlink resolution of native libraries should be left to the system resolver.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2859855724

From liach at openjdk.org  Wed May  7 18:56:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 18:56:53 GMT
Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used
 outside the compiler
In-Reply-To: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
References: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
Message-ID: <z15J03JdSjj9UNtNTgihraDN4MTvr-htZZPrpdz2lVQ=.963158e8-b423-41b8-bf80-3b7e5afd6b2b@github.com>

On Wed, 7 May 2025 11:57:02 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation.
> 
> For example this is not valid Java (and protected) by javac:
> 
> 
> byte b = 1;
> switch (b) {
>     case String s -> System.out.println("How did we get here? byte is " + s.getClass());
> }
> 
> 
> but this is a valid call (and not protected):
> 
> 
> CallSite shortSwitch = SwitchBootstraps.typeSwitch(
>     MethodHandles.lookup(), 
>     "", 
>     MethodType.methodType(int.class, short.class, int.class),  // models (short, int) -> int
>     String.class);
> 
> 
> The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. 
> 
> This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton.

looks good!

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25090#pullrequestreview-2822890841

From alanb at openjdk.org  Wed May  7 19:07:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 May 2025 19:07:52 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
In-Reply-To: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
Message-ID: <RSw6f0K6lXGV1W1l3aA0dC6Pf8317W_caoDKCW3gEYs=.48da9942-f2c4-47e8-94df-b1e22721d70e@github.com>

On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was called on the target library file before it was passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail.
> 
> Fix this problem by using `File.getAbsolutePath()` instead of `File.getCanonicalPath()` in `NativeLibraries.java`.

Would it be possible to paste in here, or in the JBS issue, some examples of the path provided to LoadLibrary with some commentary on the sym links created on the file system.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2859921963

From lancea at openjdk.org  Wed May  7 19:13:50 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 7 May 2025 19:13:50 GMT
Subject: RFR: 8353232: Standardizing and Unifying XML Component
 Configurations
In-Reply-To: <uQtTZ15H-YxBBmb1xpXrrcHfgF-S7pxzEK2ydOjQN5I=.d6e3f373-da1f-4dbb-b552-48500f1dc6f5@github.com>
References: <uQtTZ15H-YxBBmb1xpXrrcHfgF-S7pxzEK2ydOjQN5I=.d6e3f373-da1f-4dbb-b552-48500f1dc6f5@github.com>
Message-ID: <2OoPRoRRxyUejk3PuSfSn5spQDNUnkdd4tHC1dzyh5k=.a10280df-0173-42d9-8b7c-751e8ef0ddc9@github.com>

On Wed, 7 May 2025 16:17:07 GMT, Joe Wang <joehw at openjdk.org> wrote:

> This is a refactor patch, no change in functionality.
> 
> This patch refactor the configuration code. Rather than for each factory to go through the whole configuration process, a base configuration as represented in JdkXmlConfig is created once, which includes loading of the JAXP Configuration file, factories then get their own copies of the property managers, created on top of the base ones rather than directly constructed.
> 
> The JDKCatalog and its Resolver are lazily initialized when external references are encountered. This code replaces the original code block within the security manager. This change also addresses JDK-8350189.
> 
> The rest of changes basically replace all direct constructions of XMLSecurityManager/XMLSecurityPropertyManager with calls to JdkXmlConfig's corresponding get methods, which return clones of the base instances. in the factory classes, these clones are updated with property settings on the factories. In non-public or legacy code paths (inherited from upstream components), such updates may not be necessary.
> 
> Tests: existing tests T1-3 passed; XML JCK tests passed.

Hi Joe,

This looks good overall.

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25102#pullrequestreview-2822928555

From duke at openjdk.org  Wed May  7 19:23:51 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Wed, 7 May 2025 19:23:51 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
In-Reply-To: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
Message-ID: <Ucruaw1JkQ45Hum7D0i0BIEcbJezDoHEfeKaAH0v6D0=.9dc5b65c-47a4-4a11-addc-34c9db00ab5d@github.com>

On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was called on the target library file before it was passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail.
> 
> Fix this problem by using `File.getAbsolutePath()` instead of `File.getCanonicalPath()` in `NativeLibraries.java`.

Going back to the reproducer in my OP on JBS:

> mv .\jdk-24\bin\jimage.dll rando
> New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value .\rando
> \jdk-24\bin\javac 

During JVM startup, `NativeImageBuffer` will execute `System.loadLibrary("jimage")`, which will eventually make its way into `NativeLibraries.loadLibrary`. `NativeLibraries` will search the native library path and identitfy `.\jdk-24\bin\jimage.dll` as a file to load. The `getCanonicalPath()` invocation changed in this PR will be invoked to determine the final path to load. At this point, the path to load will be `$PWD\rando` due to symlink resolution. Entering the VM, `NativeLibraries.load` will eventually pass `$PWD\rando` to `LoadLibrary`. Since `.\rando` lacks a `.dll` extension on its face, `LoadLibrary` will add it, observe that `$PWD\rando.dll` doesn't exist and fail. This chain of events is avoided by presenting `LoadLibrary` with `jimage.dll` and letting the system do the symlink resolution as happened previously in JDK23.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2859971671

From duke at openjdk.org  Wed May  7 19:33:05 2025
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Wed, 7 May 2025 19:33:05 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11]
In-Reply-To: <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
Message-ID: <atKRUhMNdEYjel5fHFp88lEj5VofUjZ2bxOHJBYBpHE=.4f1e7666-76ea-4106-9c49-b7ffa6699fd6@github.com>

On Sun, 22 Oct 2023 17:26:52 GMT, Laurent Bourg?s <lbourges at openjdk.org> 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 more time to check test coverage

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2859994821

From bpb at openjdk.org  Wed May  7 21:21:57 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 May 2025 21:21:57 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
In-Reply-To: <Ucruaw1JkQ45Hum7D0i0BIEcbJezDoHEfeKaAH0v6D0=.9dc5b65c-47a4-4a11-addc-34c9db00ab5d@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <Ucruaw1JkQ45Hum7D0i0BIEcbJezDoHEfeKaAH0v6D0=.9dc5b65c-47a4-4a11-addc-34c9db00ab5d@github.com>
Message-ID: <Yp4WHvFI87pD3pkMGj5oPgVvDRpHDLXYnXQlfHab7KI=.af8e2af3-088f-4451-b309-7aaa8026ab61@github.com>

On Wed, 7 May 2025 19:21:38 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

> > New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value .\rando

What if instead this were the following

> New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value .\rando.dll

where `.dll` is appended to the target?

> At this point, the path to load will be `$PWD\rando` due to symlink resolution.

Which is in fact correct, no?

> Entering the VM, `NativeLibraries.load` will eventually pass `$PWD\rando` to `LoadLibrary`. Since `.\rando` lacks a `.dll` extension on its face, `LoadLibrary` will add it, observe that `$PWD\rando.dll` doesn't exist and fail.

Indeed from the `LoadLibrary` documentation

If the string specifies a module name without a path and the file name extension is
omitted, the function appends the default library extension ".DLL" to the module name.
To prevent the function from appending ".DLL" to the module name, include a trailing
point character (.) in the module name string.

so a trailing `.` character on `rando` might equally resolve the problem?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2860411482

From duke at openjdk.org  Wed May  7 21:49:52 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Wed, 7 May 2025 21:49:52 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
In-Reply-To: <Yp4WHvFI87pD3pkMGj5oPgVvDRpHDLXYnXQlfHab7KI=.af8e2af3-088f-4451-b309-7aaa8026ab61@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <Ucruaw1JkQ45Hum7D0i0BIEcbJezDoHEfeKaAH0v6D0=.9dc5b65c-47a4-4a11-addc-34c9db00ab5d@github.com>
 <Yp4WHvFI87pD3pkMGj5oPgVvDRpHDLXYnXQlfHab7KI=.af8e2af3-088f-4451-b309-7aaa8026ab61@github.com>
Message-ID: <1ve-Noab3tn8XX0JOz0itDj8Jd-kwMmIkhJN2A8HsJE=.ba54241b-04c4-494d-a02b-5bdb1e7bbae7@github.com>

On Wed, 7 May 2025 21:19:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > > New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value .\rando
> 
> What if instead this were the following
> 
> ```
> > New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value .\rando.dll
> ```
> 
> where `.dll` is appended to the target?

I expect that would work given the `LoadLibrary` documentation you've quoted.

> 
> > At this point, the path to load will be `$PWD\rando` due to symlink resolution.
> 
> Which is in fact correct, no?

Correct in that that's the library that should be loaded. `LoadLibrary` doesn't want to cooperate, though.

> 
> > Entering the VM, `NativeLibraries.load` will eventually pass `$PWD\rando` to `LoadLibrary`. Since `.\rando` lacks a `.dll` extension on its face, `LoadLibrary` will add it, observe that `$PWD\rando.dll` doesn't exist and fail.
> 
> Indeed from the `LoadLibrary` documentation
> 
> ```
> If the string specifies a module name without a path and the file name extension is
> omitted, the function appends the default library extension ".DLL" to the module name.
> To prevent the function from appending ".DLL" to the module name, include a trailing
> point character (.) in the module name string.
> ```
> 
> so a trailing `.` character on `rando` might equally resolve the problem?

Perhaps. In my usecase, files come into the system "anonymously"; files that make up the symlink tree are received before it's known what the layout of the tree will be. A link to a given file could turn out to be, e.g., `myaudio.mp3`, `MyClass.java`, or `jimage.dll`. I'm disinclined to append `.` or `.DLL` to every file in off chance that it turns out to be a library that Java wants to load.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2860469015

From darcy at openjdk.org  Wed May  7 22:41:54 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 May 2025 22:41:54 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v7]
In-Reply-To: <aaICVEnXfyU4M46SkWhcWCosTmNK_vHQHy-dDT28GIE=.d33c3284-7a43-4ca8-970a-86d6d1f6c63a@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
 <bI8EA_l6SeFqopOMe9mls8148Vn0xnkVoi2Pt2L2eSY=.8faceb89-2e49-4124-bdff-ee0509b82346@github.com>
 <OXoOThY3wDYFLn7vmiBogUhcKTLR3xL_s-RGv40R5gU=.76d08e2e-a35f-48b8-820b-068c9a054ec8@github.com>
 <aaICVEnXfyU4M46SkWhcWCosTmNK_vHQHy-dDT28GIE=.d33c3284-7a43-4ca8-970a-86d6d1f6c63a@github.com>
Message-ID: <pIu-L9Q5sagyqcXq7aDV3TNpbVNEcZUFm12F71iY81I=.afb14f75-8ae1-4b3c-a7a1-bb7dab34f035@github.com>

On Fri, 2 May 2025 15:28:39 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> If I understand correctly, we are talking about several (primitive) array type fields having a `@Stable` annotation, in a single class, right? So we aren't really talking about levels?
>> If so, given what `@Stable` is documented to do, I don't think the number of fields annotated as `@Stable` plays any role in the C2 compiler generating the resultant code.
>
> @jaikiran "Levels" in the sense that Q_MIN depends on E_MIN, which depends on E_MAX, which depends on W, which depends on P.
> If `@Stable` helps, which I think it does, great. If it doesn't, it shouldn't matter in practice.

Generally good cleanup @rgiulietti.

I'd like to see some kind of representation of the grammar of strings being recognized included in this file, for example a cut-and-paste of the grammar from Double.valueOf(String) (with leading and trailing spaces):

    FloatValue:
        Sign_opt NaN 
        Sign_opt Infinity 
        Sign_opt FloatingPointLiteral 
        Sign_opt HexFloatingPointLiteral 
        SignedInteger 

    HexFloatingPointLiteral:
        HexSignificand BinaryExponent FloatTypeSuffixopt 

    HexSignificand:
        HexNumeral 
        HexNumeral . 
        0x HexDigitsopt . HexDigits 
        0X HexDigitsopt . HexDigits 

    BinaryExponent:
        BinaryExponentIndicator SignedInteger 

    BinaryExponentIndicator:
        p 
        P

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2860610215

From bchristi at openjdk.org  Wed May  7 22:44:54 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 7 May 2025 22:44:54 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v6]
In-Reply-To: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com>
Message-ID: <TiPThAUOnMD_ohZ8aHmPZ3ij5OI4Zk96U-3vrMTllnE=.392f4a6d-4971-4a55-a60a-4ca2f09791ab@github.com>

On Tue, 6 May 2025 15:23:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply reviewer suggestions for typos, javadoc, and copyright dates.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1912:

> 1910:      * @param count the count of characters in the original buffer
> 1911:      * @param index the insertion point
> 1912:      * @param s char[] array to insert from

Should be:
`@param` s `CharSequence` to insert from

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2078589707

From asemenyuk at openjdk.org  Wed May  7 22:49:54 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 7 May 2025 22:49:54 GMT
Subject: RFR: 8352480: Don't follow symlinks in additional content for app
 images [v3]
In-Reply-To: <nBloeGMFbz5uS_37AONMV0ApSWAtYHzgu-DQyqt0Oyo=.20e9ee1f-81ba-422e-93cf-a38ae4ec4318@github.com>
References: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
 <nBloeGMFbz5uS_37AONMV0ApSWAtYHzgu-DQyqt0Oyo=.20e9ee1f-81ba-422e-93cf-a38ae4ec4318@github.com>
Message-ID: <zP6X7Ijb_HVeCFpGxmSpnObvH9WInHbhnSV6IaSIHsA=.bd16b9db-0c64-4086-852e-87394164fbfa@github.com>

On Wed, 7 May 2025 02:07:03 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Symbolic links will not be followed for `--app-content` on all platforms.
>> - Added test to cover this case.
>> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8352480: [macos] Don't follow symlinks in additional content for app images [v5]

test/jdk/tools/jpackage/share/AppContentTest.java line 116:

> 114:     private static Path getAppContentPath(JPackageCommand cmd, Path name) {
> 115:         Path contentDir = cmd.appLayout().contentDirectory();
> 116:         // Links are always created in "Resources"

> Links are always created in "Resources"

All additional content on macOS is created in the "Resources" directory. On Linux there is no such requirement.

The return value of `getAppContentPath()` is not supposed to depend on the additional content type; the new "name" parameter doesn't make sense to me.

test/jdk/tools/jpackage/share/AppContentTest.java line 147:

> 145: 
> 146:         private static Path copyAppContentPath(Path appContentPath) throws IOException {
> 147:             Path appContentArg = TKit.createTempDirectory("app-content").resolve("Resources");

This is a redundant change

test/jdk/tools/jpackage/share/AppContentTest.java line 149:

> 147:             Path appContentArg = TKit.createTempDirectory("app-content").resolve("Resources");
> 148:             var srcPath = TKit.TEST_SRC_ROOT.resolve(appContentPath);
> 149:             Path dstPath = appContentArg.resolve(srcPath.getFileName());

This is a redundant change

test/jdk/tools/jpackage/share/AppContentTest.java line 164:

> 162:         private static List<Path> initAppContentPaths(List<Path> appContentPaths) {
> 163:             boolean copy = (copyInResources || appContentPaths.stream()
> 164:                             .anyMatch(s -> s.toString().contains("Link")));

`s.toString().contains("Link")` is a lousy way to detect if the path is a symlink. "s" can be an absolute path (to the local OpenJDK repo) that may have a "Link" substring in one of path components, like "/home/BLink/my-projects/open/test/jdk/tools/jpackage/non-existant". The test will fail, and we will have a very hard time figuring out the cause. I'd fix it by narrowing the scope from the full path to the filename; create a dedicated function for detecting if the given path is supposed to be a symlink instead of repeating `.toString().contains("Link")`:

private static boolean isSymlinkPath(Path v) {
    return v.getFileName().toString().contains("Link");
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2077510440
PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2077512476
PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2077512103
PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2077542387

From bpb at openjdk.org  Wed May  7 23:04:51 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 May 2025 23:04:51 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
In-Reply-To: <1ve-Noab3tn8XX0JOz0itDj8Jd-kwMmIkhJN2A8HsJE=.ba54241b-04c4-494d-a02b-5bdb1e7bbae7@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <Ucruaw1JkQ45Hum7D0i0BIEcbJezDoHEfeKaAH0v6D0=.9dc5b65c-47a4-4a11-addc-34c9db00ab5d@github.com>
 <Yp4WHvFI87pD3pkMGj5oPgVvDRpHDLXYnXQlfHab7KI=.af8e2af3-088f-4451-b309-7aaa8026ab61@github.com>
 <1ve-Noab3tn8XX0JOz0itDj8Jd-kwMmIkhJN2A8HsJE=.ba54241b-04c4-494d-a02b-5bdb1e7bbae7@github.com>
Message-ID: <f7xqGdrU1S7-zGmIRaKIWL1NQaWAB2lZMvV7-1a2uMY=.4f81ea93-4c99-4f70-a76c-13eeed13861d@github.com>

On Wed, 7 May 2025 21:47:37 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

> > > At this point, the path to load will be `$PWD\rando` due to symlink resolution.
> > 
> > 
> > Which is in fact correct, no?
> 
> Correct in that that's the library that should be loaded. `LoadLibrary` doesn't want to cooperate, though.

So is it correct to say that the link resolution appears correct but `LoadLibrary`'s quirks cause the intended behavior to fail?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2860642950

From bchristi at openjdk.org  Wed May  7 23:22:01 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 7 May 2025 23:22:01 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v6]
In-Reply-To: <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com>
Message-ID: <gzVdC9xTex_26RqYD_L5QUo303dl1O_-9lh78ayDXIY=.baf009fa-25d0-4874-b1cf-8268d4de59c1@github.com>

On Tue, 6 May 2025 15:23:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply reviewer suggestions for typos, javadoc, and copyright dates.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 2042:

> 2040:      * @param coder the coder of the buffer
> 2041:      * @param count the character count
> 2042:      * @param s a string

Should be:
`@param` s a `CharSequence`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2078645712

From duke at openjdk.org  Wed May  7 23:23:52 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Wed, 7 May 2025 23:23:52 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
In-Reply-To: <f7xqGdrU1S7-zGmIRaKIWL1NQaWAB2lZMvV7-1a2uMY=.4f81ea93-4c99-4f70-a76c-13eeed13861d@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <Ucruaw1JkQ45Hum7D0i0BIEcbJezDoHEfeKaAH0v6D0=.9dc5b65c-47a4-4a11-addc-34c9db00ab5d@github.com>
 <Yp4WHvFI87pD3pkMGj5oPgVvDRpHDLXYnXQlfHab7KI=.af8e2af3-088f-4451-b309-7aaa8026ab61@github.com>
 <1ve-Noab3tn8XX0JOz0itDj8Jd-kwMmIkhJN2A8HsJE=.ba54241b-04c4-494d-a02b-5bdb1e7bbae7@github.com>
 <f7xqGdrU1S7-zGmIRaKIWL1NQaWAB2lZMvV7-1a2uMY=.4f81ea93-4c99-4f70-a76c-13eeed13861d@github.com>
Message-ID: <ebad2jOjG9XOs3TzIgUVUjZ5miwWCJx-z9zeCS1U5M8=.52f68c5f-795b-4309-ad40-45ef0df59c9c@github.com>

On Wed, 7 May 2025 23:02:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > > > At this point, the path to load will be `$PWD\rando` due to symlink resolution.
> > > 
> > > 
> > > Which is in fact correct, no?
> > 
> > 
> > Correct in that that's the library that should be loaded. `LoadLibrary` doesn't want to cooperate, though.
> 
> So is it correct to say that the link resolution appears correct but `LoadLibrary`'s quirks cause the intended behavior to fail?

Yes. The `getCanonicalPath` canonicalization indeed produces the file pointed to by the symlink. However, in the context of `NativeLibraries`, doing path canonicalization is at best unnecessary and at worst yields the linked bug.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2860678324

From bpb at openjdk.org  Wed May  7 23:32:51 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 May 2025 23:32:51 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
In-Reply-To: <ebad2jOjG9XOs3TzIgUVUjZ5miwWCJx-z9zeCS1U5M8=.52f68c5f-795b-4309-ad40-45ef0df59c9c@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <Ucruaw1JkQ45Hum7D0i0BIEcbJezDoHEfeKaAH0v6D0=.9dc5b65c-47a4-4a11-addc-34c9db00ab5d@github.com>
 <Yp4WHvFI87pD3pkMGj5oPgVvDRpHDLXYnXQlfHab7KI=.af8e2af3-088f-4451-b309-7aaa8026ab61@github.com>
 <1ve-Noab3tn8XX0JOz0itDj8Jd-kwMmIkhJN2A8HsJE=.ba54241b-04c4-494d-a02b-5bdb1e7bbae7@github.com>
 <f7xqGdrU1S7-zGmIRaKIWL1NQaWAB2lZMvV7-1a2uMY=.4f81ea93-4c99-4f70-a76c-13eeed13861d@github.com>
 <ebad2jOjG9XOs3TzIgUVUjZ5miwWCJx-z9zeCS1U5M8=.52f68c5f-795b-4309-ad40-45ef0df59c9c@github.com>
Message-ID: <FE9iso2pi5Sv02XbNsP9T8bH-zLxwFv5Ut3lirQDpjk=.f1e5c667-8ce5-4c90-be70-d59f4fcbf0b4@github.com>

On Wed, 7 May 2025 23:21:20 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

> > So is it correct to say that the link resolution appears correct but `LoadLibrary`'s quirks cause the intended behavior to fail?
> 
> Yes. The `getCanonicalPath` canonicalization indeed produces the file pointed to by the symlink.

All right, it is good to know that it is behaving in the desired manner.

> However, in the context of `NativeLibraries`, doing path canonicalization is at best unnecessary and at worst yields the linked bug.

You might be correct. We'll see what @AlanBateman and others have to say about it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2860711420

From ccheung at openjdk.org  Thu May  8 00:28:07 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 8 May 2025 00:28:07 GMT
Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking
Message-ID: <aEW-5oqTUQgD8pJhkNbGxP_mUen4ld5hYVD_MRKvydE=.7b6900ba-ee3e-4d7a-a1fd-26d4510ffe8e@github.com>

This fix adds the `--add-reads` support for CDS and AOTClassLinking.
Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled:
`[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro`
During runtime, the archived full module graph will be disabled:
`[0.021s][info][cds       ] full module graph: disabled`

With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime.

Testing: tiers 1 - 4.

-------------

Commit messages:
 - fix trailing whitespace
 - 8354083: Support --add-reads with -XX:+AOTClassLinking

Changes: https://git.openjdk.org/jdk/pull/25109/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25109&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354083
  Stats: 111 lines in 4 files changed: 81 ins; 14 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25109.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25109/head:pull/25109

PR: https://git.openjdk.org/jdk/pull/25109

From duke at openjdk.org  Thu May  8 01:01:06 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 8 May 2025 01:01:06 GMT
Subject: Integrated: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <zsyV9LRSe3O7JWsMQqgmQuT-3SA2RUOip4XoH0kkzTs=.68e8b5db-087d-4bdb-abcc-0912d2ab40f1@github.com>

On Sat, 26 Oct 2024 15:48:11 GMT, Markus KARG <duke at openjdk.org> 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.

This pull request has now been integrated.

Changeset: 7642556a
Author:    Markus KARG <markus at headcrashing.eu>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7642556a5a131e9104033ad7d7abfdb4be5012cf
Stats:     470 lines in 8 files changed: 399 ins; 59 del; 12 mod

8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer

Reviewed-by: liach, jpai, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/21730

From xgong at openjdk.org  Thu May  8 01:53:58 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 8 May 2025 01:53:58 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v5]
In-Reply-To: <gs98vNywMgB3pEcq_Bfv_jhLBiH7KS_1NhHGprSCtLs=.cd43836c-5de3-4642-afa1-1a5a04f0b17b@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <huhJ3Yq2fj9CJGBAqQFZxd8i0Wjnwad3moNHymXKyy8=.d64a2532-6bd5-4e58-84ee-18f682d7fe20@github.com>
 <ItOPWOS6VHofCe7QYcIqnq0yCi-dXfEri_45HgrjfYY=.285d15ff-5b15-4a21-8a7c-1e4cabcc33b2@github.com>
 <Jzqyfc2xxJRBY2ppai7XpFKaWS7y3CsnP4Y547KHq6o=.d482f244-a9dd-4ac4-a082-0b3180c1caad@github.com>
 <gs98vNywMgB3pEcq_Bfv_jhLBiH7KS_1NhHGprSCtLs=.cd43836c-5de3-4642-afa1-1a5a04f0b17b@github.com>
Message-ID: <F6ofKcqVvH3NUwDokqmyIw823V1u6GGlAMdMCxJLtek=.433a6406-1ba0-4a58-b9a3-fde97d8f515d@github.com>

On Wed, 7 May 2025 11:02:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi @jatin-bhateja It is feasible. But I was thinking about whether another solution would be better, which is to turn  `VectorMask.fromLong(SPECIES, -1L)` into `MaskAll(true)` in the mid-end. In this way, we don't need to check this pattern in this optimization. What do you think ?
>
> Yes, that's the right approach. For this PR, I think you can mix some test points covering compare, xor(maskAll(true)).

Yes, converting `VectorMask.fromLong(SPECIES, -1L)` to `MaskAll()` would be better, and that will benefit AArch64 as well, since `MaskAll()` is much more cheaper than `fromLong()` on AArch64. We can add such a transformation with another PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2078760074

From iklam at openjdk.org  Thu May  8 03:24:50 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 8 May 2025 03:24:50 GMT
Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking
In-Reply-To: <aEW-5oqTUQgD8pJhkNbGxP_mUen4ld5hYVD_MRKvydE=.7b6900ba-ee3e-4d7a-a1fd-26d4510ffe8e@github.com>
References: <aEW-5oqTUQgD8pJhkNbGxP_mUen4ld5hYVD_MRKvydE=.7b6900ba-ee3e-4d7a-a1fd-26d4510ffe8e@github.com>
Message-ID: <s0fCcdSLPUVuyT_5NPbWJpRzqZX2FVH_fzYiHruYowY=.3b318ba9-d027-4ae8-8dab-976f50c87ce2@github.com>

On Thu, 8 May 2025 00:19:17 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This fix adds the `--add-reads` support for CDS and AOTClassLinking.
> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled:
> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro`
> During runtime, the archived full module graph will be disabled:
> `[0.021s][info][cds       ] full module graph: disabled`
> 
> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime.
> 
> Testing: tiers 1 - 4.

I think we need a test to validate that the `--add-reads` flag actually works. I wrote such a test when I implemented `--add-exports`: see [runtime/cds/appcds/jigsaw/modulepath/AddExports.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/AddExports.java)

I think we need a similar test for `--add-opens` as well.

Since the main reason for supporting `--add-{expors,opens,reads}` is for user of AOT class linking, I would suggest moving the above AddExports.java test to 

- runtime/cds/appcds/aotClassLinking/modules/AddExports.java

And then add AddReads.java and AddOpens.java there as well.

The reason for putting the tests inside aotClassLinking is that they will be excluded from the `hotspot_appcds_dynamic` and `hotspot_aot_classlinking` test groups, so you don't need to add special case code to handle those two test groups.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25109#issuecomment-2861575003

From alanb at openjdk.org  Thu May  8 07:10:35 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 May 2025 07:10:35 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v12]
In-Reply-To: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
References: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
Message-ID: <ISELAMnPefw2SNMh422IYY2it_UlyTdwcWb1hwWCVrM=.b38e6743-fdc0-4d84-b3c5-8c0349273a70@github.com>

> 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 22 commits:

 - Merge branch 'master' into JDK-8342486
 - Sync up from loom repo
 - Merge branch 'master' into JDK-8342486
 - Merge branch 'master' into JDK-8342486
 - Merge branch 'master' into JDK-8342486
 - Sync up from loom repo
 - Merge branch 'master' into JDK-8342486
 - Add JEP number, update copyright headers
 - Merge branch 'master' into JDK-8342486
 - Sync up from loom repo
 - ... and 12 more: https://git.openjdk.org/jdk/compare/52a5583d...c61ba159

-------------

Changes: https://git.openjdk.org/jdk/pull/21934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21934&range=11
  Stats: 4036 lines in 14 files changed: 1818 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 pminborg at openjdk.org  Thu May  8 07:16:28 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 May 2025 07:16:28 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v8]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <RT7r2o2lv_UhpBrgiUStZsES4gkQiirc3n680966RfQ=.2135d46d-ddd5-4a4c-a06e-faadaae8b252@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add lazy CallSite methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/de8e2387..e2a2d7bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=06-07

  Stats: 64 lines in 2 files changed: 62 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040

PR: https://git.openjdk.org/jdk/pull/25040

From pminborg at openjdk.org  Thu May  8 07:27:50 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 May 2025 07:27:50 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v9]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <wRlfMNSYAZyZaS0NPCWB_gLzTR2U2qaguJou6-Avw9M=.2632b0cc-015f-402e-ab45-c6f95edfa300@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes in stable classes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/e2a2d7bd..e928591a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=07-08

  Stats: 23 lines in 2 files changed: 8 ins; 13 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040

PR: https://git.openjdk.org/jdk/pull/25040

From pminborg at openjdk.org  Thu May  8 07:40:44 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 May 2025 07:40:44 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v7]
In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
Message-ID: <RV4mT9vQDK1loroCEBdjtBuWfJYb8SOkdHsrDlyqw5w=.27fe7084-b6eb-42c2-811a-88e8527465ed@github.com>

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Clean up and remove unrelated changed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25043/files
  - new: https://git.openjdk.org/jdk/pull/25043/files/e435762b..3a4cf9dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=05-06

  Stats: 115 lines in 5 files changed: 0 ins; 100 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/25043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25043/head:pull/25043

PR: https://git.openjdk.org/jdk/pull/25043

From pminborg at openjdk.org  Thu May  8 07:54:17 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 May 2025 07:54:17 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v8]
In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
Message-ID: <z8ki0hX0GbyirYXqZnv2xFI50gqw532pXWXHw5lwwvw=.33cbfe55-6f93-45c6-9e2b-bcf1a78f26a5@github.com>

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25043/files
  - new: https://git.openjdk.org/jdk/pull/25043/files/3a4cf9dc..c5159e5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=06-07

  Stats: 46 lines in 2 files changed: 0 ins; 45 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25043/head:pull/25043

PR: https://git.openjdk.org/jdk/pull/25043

From pminborg at openjdk.org  Thu May  8 07:54:17 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 May 2025 07:54:17 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v7]
In-Reply-To: <RV4mT9vQDK1loroCEBdjtBuWfJYb8SOkdHsrDlyqw5w=.27fe7084-b6eb-42c2-811a-88e8527465ed@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <RV4mT9vQDK1loroCEBdjtBuWfJYb8SOkdHsrDlyqw5w=.27fe7084-b6eb-42c2-811a-88e8527465ed@github.com>
Message-ID: <60XAq-TsBu_ZOi281yI0VKJDJsHIQQ6FHuM7oYMrdX4=.a5264b71-c008-48fa-bb64-fd31153373d5@github.com>

On Thu, 8 May 2025 07:40:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up and remove unrelated changed

Updated benchmarks:


Benchmark                                                  Mode  Cnt   Score   Error  Units
CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  34.138 ? 0.269  ns/op
CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30  12.660 ? 0.251  ns/op
CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  39.592 ? 0.319  ns/op
CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.379 ? 0.162  ns/op
CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  30.636 ? 0.410  ns/op
CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   4.990 ? 0.042  ns/op
CaptureStateUtilBench.explicitAllocationFail               avgt   30  39.763 ? 0.316  ns/op
CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  21.420 ? 0.241  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25043#issuecomment-2862103792

From vklang at openjdk.org  Thu May  8 08:02:02 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 8 May 2025 08:02:02 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v12]
In-Reply-To: <ISELAMnPefw2SNMh422IYY2it_UlyTdwcWb1hwWCVrM=.b38e6743-fdc0-4d84-b3c5-8c0349273a70@github.com>
References: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
 <ISELAMnPefw2SNMh422IYY2it_UlyTdwcWb1hwWCVrM=.b38e6743-fdc0-4d84-b3c5-8c0349273a70@github.com>
Message-ID: <CnkKoybD6sL92A5EvVJb4hJxDOe6Fw3zjGal0PvWlKE=.5429d4e1-fef1-458e-81bd-ffc88e44a632@github.com>

On Thu, 8 May 2025 07:10:35 GMT, Alan Bateman <alanb at openjdk.org> 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 22 commits:
> 
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8342486
>  - Merge branch 'master' into JDK-8342486
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8342486
>  - Add JEP number, update copyright headers
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/52a5583d...c61ba159

Marked as reviewed by vklang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21934#pullrequestreview-2824182310

From vklang at openjdk.org  Thu May  8 08:38:55 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 8 May 2025 08:38:55 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
Message-ID: <-elHwuRlU4xfy382a9QVdVT6WQMPoZyyEHANGR2TgmQ=.b4329ab0-7f2e-4c7b-9053-9917f2ea3a5f@github.com>

On Mon, 28 Apr 2025 15:23:18 GMT, kabutz <duke at openjdk.org> wrote:

> We logged several bugs on the LinkedBlockingDeque. This aggregates them into a single bug report and PR.
> 
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in put/take
> 
> The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down.
> 
> 2. LinkedBlockingDeque.clear() should preserve weakly-consistent iterators
> 
> LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work.
> 
> The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator thus all support self-linking.
> 
> This can be fixed very easily by linking both f.prev and f.next back to f.
> 
> 3. LinkedBlockingDeque offer() creates nodes even if capacity has been reached
> 
> In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking.
> 
> In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field.
> 
> 4. LinkedBlockingDeque allows us to overflow size with addAll()
> 
> In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst holding the lock, we check that we haven't exceed...

src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 341:

> 339:             if (count >= capacity)
> 340:                 return false;
> 341:             linkFirst(node);

I'm a bit uneasy about incrementing the `count` in `linkFirst` but not enforcing the invariant. What's the benefit to changing linkFirst and linkLast to return void instead of keeping the original returning a boolean?

src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 735:

> 733:      */
> 734:     public int remainingCapacity() {
> 735:         return capacity - count;

Nice improvement!

src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 817:

> 815:      */
> 816:     public int size() {
> 817:         return count;

Nice improvement here as well!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079178889
PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079183074
PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079183713

From sgehwolf at openjdk.org  Thu May  8 08:40:00 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 8 May 2025 08:40:00 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v17]
In-Reply-To: <ftsw92lx0y4ZTI_XZz1mgqEEKjNVB-L1G44AtJXvQM8=.cef4eac5-158a-4229-8ae5-6feae46e9f86@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
 <ftsw92lx0y4ZTI_XZz1mgqEEKjNVB-L1G44AtJXvQM8=.cef4eac5-158a-4229-8ae5-6feae46e9f86@github.com>
Message-ID: <y53dT7rff0wHm0GwfQ-SvCUUD0H9OAwUZYv0gQ9xdYQ=.8fdaa0f3-3a61-48b0-9901-1d17c051fa8d@github.com>

On Tue, 1 Apr 2025 14:59:37 GMT, Severin Gehwolf <sgehwolf at openjdk.org> 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, bot.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2862232316

From mcimadamore at openjdk.org  Thu May  8 08:46:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 8 May 2025 08:46:54 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v8]
In-Reply-To: <z8ki0hX0GbyirYXqZnv2xFI50gqw532pXWXHw5lwwvw=.33cbfe55-6f93-45c6-9e2b-bcf1a78f26a5@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <z8ki0hX0GbyirYXqZnv2xFI50gqw532pXWXHw5lwwvw=.33cbfe55-6f93-45c6-9e2b-bcf1a78f26a5@github.com>
Message-ID: <cuA2gUMH3DqJ4dN5b9Qqceretor4SeTe1cxzEntvGn8=.c82cae76-320c-4912-aeed-73de963a616b@github.com>

On Thu, 8 May 2025 07:54:17 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove class

src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 53:

> 51:     private static final BufferStack POOL = BufferStack.of(CAPTURE_LAYOUT);
> 52: 
> 53:     // Do not use a lambda in order to allow early use in the init sequence

This can be a local variable in the static initializer, right -- e.g. no need to expose it at class-level?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2079201294

From vklang at openjdk.org  Thu May  8 08:44:55 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 8 May 2025 08:44:55 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
Message-ID: <VjVR6fAsjI47ypazhGOkMo5b6Q451Y7yjyKPeNm-_e0=.371a3007-d96b-40e4-bfa3-4e14ab2d2ebe@github.com>

On Mon, 28 Apr 2025 15:23:18 GMT, kabutz <duke at openjdk.org> wrote:

> We logged several bugs on the LinkedBlockingDeque. This aggregates them into a single bug report and PR.
> 
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in put/take
> 
> The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down.
> 
> 2. LinkedBlockingDeque.clear() should preserve weakly-consistent iterators
> 
> LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work.
> 
> The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator thus all support self-linking.
> 
> This can be fixed very easily by linking both f.prev and f.next back to f.
> 
> 3. LinkedBlockingDeque offer() creates nodes even if capacity has been reached
> 
> In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking.
> 
> In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field.
> 
> 4. LinkedBlockingDeque allows us to overflow size with addAll()
> 
> In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst holding the lock, we check that we haven't exceed...

src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 860:

> 858:             // As historically specified in AbstractQueue#addAll
> 859:             throw new IllegalArgumentException();
> 860: 

We could likely check if there's any remaining capacity up front, and immediately return false?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079194580

From mcimadamore at openjdk.org  Thu May  8 08:50:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 8 May 2025 08:50:53 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v8]
In-Reply-To: <z8ki0hX0GbyirYXqZnv2xFI50gqw532pXWXHw5lwwvw=.33cbfe55-6f93-45c6-9e2b-bcf1a78f26a5@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <z8ki0hX0GbyirYXqZnv2xFI50gqw532pXWXHw5lwwvw=.33cbfe55-6f93-45c6-9e2b-bcf1a78f26a5@github.com>
Message-ID: <o1WtDR69SYhBzO7HFlXHnphfNtes1jGCDG1AtqJEn8Q=.367a0dcc-fc88-4727-ae78-a4a576019dc5@github.com>

On Thu, 8 May 2025 07:54:17 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove class

src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 110:

> 108: 
> 109:         @Override
> 110:         public int hashCode() {

isn't the default toString/hashCode/equals for records good enough? If these overload are added for bootstrapping, please say so in a comment

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2079206969

From vklang at openjdk.org  Thu May  8 08:53:58 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 8 May 2025 08:53:58 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
Message-ID: <jILvpQAJ0oVsW6l_nqj9SAUoMdiQUf5C0CbBZmELZDk=.64b50d50-9184-434e-a37c-eee8102d741a@github.com>

On Mon, 28 Apr 2025 15:23:18 GMT, kabutz <duke at openjdk.org> wrote:

> We logged several bugs on the LinkedBlockingDeque. This aggregates them into a single bug report and PR.
> 
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in put/take
> 
> The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down.
> 
> 2. LinkedBlockingDeque.clear() should preserve weakly-consistent iterators
> 
> LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work.
> 
> The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator thus all support self-linking.
> 
> This can be fixed very easily by linking both f.prev and f.next back to f.
> 
> 3. LinkedBlockingDeque offer() creates nodes even if capacity has been reached
> 
> In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking.
> 
> In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field.
> 
> 4. LinkedBlockingDeque allows us to overflow size with addAll()
> 
> In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst holding the lock, we check that we haven't exceed...

test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java line 1958:

> 1956:         q.add(four);
> 1957:         q.add(five);
> 1958:         q.add(six);

Out of curiosity, how does `it.remove()` work under these conditions?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079213178

From mcimadamore at openjdk.org  Thu May  8 09:02:02 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 8 May 2025 09:02:02 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v8]
In-Reply-To: <z8ki0hX0GbyirYXqZnv2xFI50gqw532pXWXHw5lwwvw=.33cbfe55-6f93-45c6-9e2b-bcf1a78f26a5@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <z8ki0hX0GbyirYXqZnv2xFI50gqw532pXWXHw5lwwvw=.33cbfe55-6f93-45c6-9e2b-bcf1a78f26a5@github.com>
Message-ID: <b7mWHOulO-fnvtfQUFmfdqMsCqt_DpqWH6GNs8ErhfM=.efcc003f-c0d0-4812-b8fd-54ad6ff075fc@github.com>

On Thu, 8 May 2025 07:54:17 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove class

src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 244:

> 242:     }
> 243: 
> 244:     private static MethodHandle makeBasicHandle(BasicKey basicKey) {

more than a "basic handle" this seems more a "return filter"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2079227117

From vklang at openjdk.org  Thu May  8 09:02:52 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 8 May 2025 09:02:52 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
Message-ID: <rO9njoSonLf7DLUrHaB9jMMXDTodgbWlZ-391cqxW50=.0f02cb42-105b-4aaf-88cf-9d6574e0d555@github.com>

On Mon, 28 Apr 2025 15:23:18 GMT, kabutz <duke at openjdk.org> wrote:

> We logged several bugs on the LinkedBlockingDeque. This aggregates them into a single bug report and PR.
> 
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in put/take
> 
> The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down.
> 
> 2. LinkedBlockingDeque.clear() should preserve weakly-consistent iterators
> 
> LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work.
> 
> The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator thus all support self-linking.
> 
> This can be fixed very easily by linking both f.prev and f.next back to f.
> 
> 3. LinkedBlockingDeque offer() creates nodes even if capacity has been reached
> 
> In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking.
> 
> In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field.
> 
> 4. LinkedBlockingDeque allows us to overflow size with addAll()
> 
> In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst holding the lock, we check that we haven't exceed...

src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 865:

> 863:         long n = 0;
> 864:         for (E e : c) {
> 865:             Objects.requireNonNull(e);

This makes me wonder: Does it make sense to create new nodes if we don't track if they will still fit into the capacity?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079229217

From rgiulietti at openjdk.org  Thu May  8 09:18:00 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 8 May 2025 09:18:00 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v53]
In-Reply-To: <416Ep8OzMrQzitAI-WaIkgbhu7RAcriT9W63DZyblLc=.28549efe-7c6c-4a29-be36-df35f20d6035@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <416Ep8OzMrQzitAI-WaIkgbhu7RAcriT9W63DZyblLc=.28549efe-7c6c-4a29-be36-df35f20d6035@github.com>
Message-ID: <Qbgk7BwX1zduMXOIWAGmxZteyLeXROFMDnbCJm0ptzU=.a8417923-3674-4839-89da-417a487345de@github.com>

On Wed, 7 May 2025 18:32:50 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggested changes

Last nits.

I'll approve the PR in the next couple of days for last minute small changes from you.

src/java.base/share/classes/java/math/BigInteger.java line 2656:

> 2654:             // Perform exponentiation using repeated squaring trick
> 2655:             // The loop relies on this invariant:
> 2656:             // base^exponent == answer^(2^expLen) * base^(exponent & (2^expLen - 1))

The invariant is correct, but it should minimally involve all running variables updated in the loop, including `workingExp`. Otherwise, reasoning about the invariant becomes harder.

Further, I suggest to replace the subexpression `exponent & (2^expLen - 1)` with the more mathematical `exponent % (2^expLen)`.

test/micro/org/openjdk/bench/java/math/BigIntegerPow.java line 62:

> 60:      * Each array entry is atmost 64 bits
> 61:      * in size
> 62:      */

This can be re-flowed more compactly like so (and similarly for the other fields)
Suggestion:

    private int xsExp = (1 << 20) - 1;
    /* Each array entry is at most 64 bits in size */
    private BigInteger[] xsArray = new BigInteger[TESTSIZE];

-------------

PR Review: https://git.openjdk.org/jdk/pull/24690#pullrequestreview-2824381118
PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2079247545
PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2079251316

From pminborg at openjdk.org  Thu May  8 09:21:35 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 May 2025 09:21:35 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v9]
In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
Message-ID: <IW-oLazvf8SaIXse_MiAPJ4B9FU4Exc-Krh_eAgiL3Q=.d3076c3d-007c-41fa-b280-5520eee059a6@github.com>

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.

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/25043/files
  - new: https://git.openjdk.org/jdk/pull/25043/files/c5159e5f..9772c703

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=07-08

  Stats: 51 lines in 3 files changed: 9 ins; 19 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/25043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25043/head:pull/25043

PR: https://git.openjdk.org/jdk/pull/25043

From pminborg at openjdk.org  Thu May  8 09:21:35 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 May 2025 09:21:35 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v8]
In-Reply-To: <o1WtDR69SYhBzO7HFlXHnphfNtes1jGCDG1AtqJEn8Q=.367a0dcc-fc88-4727-ae78-a4a576019dc5@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <z8ki0hX0GbyirYXqZnv2xFI50gqw532pXWXHw5lwwvw=.33cbfe55-6f93-45c6-9e2b-bcf1a78f26a5@github.com>
 <o1WtDR69SYhBzO7HFlXHnphfNtes1jGCDG1AtqJEn8Q=.367a0dcc-fc88-4727-ae78-a4a576019dc5@github.com>
Message-ID: <rdmcZLWIL-iyRZ-EOP2BL47_reTTgpkfEyTch9Zf0xo=.25de000c-f702-44c9-9d98-07335142b28c@github.com>

On Thu, 8 May 2025 08:47:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove class
>
> src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 110:
> 
>> 108: 
>> 109:         @Override
>> 110:         public int hashCode() {
> 
> isn't the default toString/hashCode/equals for records good enough? If these overload are added for bootstrapping, please say so in a comment

Added for bootstrapping but I think this could be addressed in another way (e.g. helloClass once this class is used).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2079258413

From mcimadamore at openjdk.org  Thu May  8 09:23:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 8 May 2025 09:23:53 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v9]
In-Reply-To: <IW-oLazvf8SaIXse_MiAPJ4B9FU4Exc-Krh_eAgiL3Q=.d3076c3d-007c-41fa-b280-5520eee059a6@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <IW-oLazvf8SaIXse_MiAPJ4B9FU4Exc-Krh_eAgiL3Q=.d3076c3d-007c-41fa-b280-5520eee059a6@github.com>
Message-ID: <zFgOb1BWtRTWtvHoAFcep0xCom0kp0shjuGrA69bQF8=.64c92026-3e00-487f-9a05-3f31f1d74816@github.com>

On Thu, 8 May 2025 09:21:35 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 15520:

> 15518:                </regions>
> 15519:             </uiComponent>
> 15520:             <uiIconRegion name="ErrorIcon" subregion="true" key="errorIcon" segmentExtractorKey="OptionPane.errorIcon">

Spurious commit?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2079264611

From ihse at openjdk.org  Thu May  8 10:19:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 May 2025 10:19:31 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v6]
In-Reply-To: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
Message-ID: <tBEVMB0n8bNbzfjJy7jgJUxOa0Z-4OojY27IiXoxci8=.eec6f271-a45c-47f7-9f20-9ca219f1faea@github.com>

> 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 with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into go-full-utf8
 - Merge branch 'master' into go-full-utf8
 - Add informative message  about supported locales.
 - Allow C locale with warning instead of fatal error
 - Also document UTF-8 requirements (solves JDK-8338973)
 - Let configure only accept utf-8 locales
 - Address review comments from Kim
 - Also tell javadoc that we have utf-8 now
 - Fix flags for Windows
 - Mark java and native source code as utf-8
 - ... and 4 more: https://git.openjdk.org/jdk/compare/2c1eb339...e68305db

-------------

Changes: https://git.openjdk.org/jdk/pull/24574/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=05
  Stats: 177 lines in 13 files changed: 49 ins; 105 del; 23 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 pminborg at openjdk.org  Thu May  8 10:42:54 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 May 2025 10:42:54 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v9]
In-Reply-To: <zFgOb1BWtRTWtvHoAFcep0xCom0kp0shjuGrA69bQF8=.64c92026-3e00-487f-9a05-3f31f1d74816@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <IW-oLazvf8SaIXse_MiAPJ4B9FU4Exc-Krh_eAgiL3Q=.d3076c3d-007c-41fa-b280-5520eee059a6@github.com>
 <zFgOb1BWtRTWtvHoAFcep0xCom0kp0shjuGrA69bQF8=.64c92026-3e00-487f-9a05-3f31f1d74816@github.com>
Message-ID: <z9-ZECfjF9koOfHZ1o2S4uH-BQscNkhshSx4LKV4eJs=.c1809619-c93a-44b2-821b-1e687c2810b9@github.com>

On Thu, 8 May 2025 09:21:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments
>
> src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 15520:
> 
>> 15518:                </regions>
>> 15519:             </uiComponent>
>> 15520:             <uiIconRegion name="ErrorIcon" subregion="true" key="errorIcon" segmentExtractorKey="OptionPane.errorIcon">
> 
> Spurious commit?

OOops!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25043#discussion_r2079464125

From pminborg at openjdk.org  Thu May  8 10:50:55 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 May 2025 10:50:55 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v10]
In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
Message-ID: <DrGwMv2P3SpsmVSU_2PsJgd4iqkl7ZFRA9M5EdwS3tU=.7093ffbf-24c5-45f7-a9e7-9d8aa4e75345@github.com>

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Revert more incidental changes
 - Revert incidental change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25043/files
  - new: https://git.openjdk.org/jdk/pull/25043/files/9772c703..4a6ae69e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25043&range=08-09

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25043/head:pull/25043

PR: https://git.openjdk.org/jdk/pull/25043

From vklang at openjdk.org  Thu May  8 12:04:53 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 8 May 2025 12:04:53 GMT
Subject: RFR: 8355938: Addressed rare lost unpark bug 8074773 by
 pre-loading LockSupport.class
In-Reply-To: <bLLsppdQBU2jMbn2p3NK70ShoBMbB8xxjnlDE_FYV_g=.13f7414c-a514-4076-a1df-7fe4c0d8b31b@github.com>
References: <tcZkZgScJXJYpRK68NSRUTl7gcOhePhABSQz0DOzArI=.137600e0-7656-4c7a-85de-c340173467fc@github.com>
 <M7K--fqIQU_E8LdwuAE4fXNMB90mjh6jVkCCegmmz0I=.04616e1e-4f8c-4df2-a699-02520ac96c7d@github.com>
 <bLLsppdQBU2jMbn2p3NK70ShoBMbB8xxjnlDE_FYV_g=.13f7414c-a514-4076-a1df-7fe4c0d8b31b@github.com>
Message-ID: <eCzml3Qt2zE4_ISVF9lYMdikBGO4UzpmsIalYFAFP-s=.caaa4287-40a8-4c56-8f82-277f220ac15c@github.com>

On Wed, 30 Apr 2025 11:25:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The bug description seems like it is a fault in the JVM implementation - if that is the case, a core library bypass is unreliable, as such faults might happen to other classes and cause other consequences; and we might need to fix it from the VM runtime or compiler side, as the original report implies.
>
>> The bug description seems like it is a fault in the JVM implementation - if that is the case, a core library bypass is unreliable, as such faults might happen to other classes and cause other consequences; and we might need to fix it from the VM runtime or compiler side, as the original report implies.
> 
> It seems to about nested parking that can arise with the first use of LockSupport.park from a class with a defining class loader that is not the boot loader. The first usage, say an invokestatic to call the park method, will call the loadClass on caller's defining class loader.  For the app class loader, and many other custom class loaders, that are parallel capable, then there will be a CHM to support the mapping of class names to locks. Contention on the CHM seems to have lead to the nested park.  CHM and a lot of other code has changed since and not clear that it will duplicate easily now. Martin's ParkLoops test from the 2015 issue is in the test tree but it might be that a variant of this that uses a custom class loader that overrides getClassLoadingLock or parks in loadClass might be able to trigger it. As a custom class loader's loadClass can do anything then it almost feels like creating a class loader needs it have it recorded immediately as an initiating class loader. Hop
 efully David will remember more of this when he gets back.

I'll second @AlanBateman 's sentiments here. I think a systemic issue needs a wholesale solution, otherwise it'll just lead to endless sprinkling of eager initializations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2862799361

From jpai at openjdk.org  Thu May  8 12:12:05 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 May 2025 12:12:05 GMT
Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for empty ZipEntry
Message-ID: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>

Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799?

`java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix.

tier testing is currently in progress.

-------------

Commit messages:
 - 8354799: ZipInputStream doesn't verify CRC for empty ZipEntry
 - 8354799: add test

Changes: https://git.openjdk.org/jdk/pull/25116/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25116&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354799
  Stats: 169 lines in 2 files changed: 168 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25116/head:pull/25116

PR: https://git.openjdk.org/jdk/pull/25116

From alanb at openjdk.org  Thu May  8 12:28:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 May 2025 12:28:51 GMT
Subject: RFR: 8355938: Addressed rare lost unpark bug 8074773 by
 pre-loading LockSupport.class
In-Reply-To: <bLLsppdQBU2jMbn2p3NK70ShoBMbB8xxjnlDE_FYV_g=.13f7414c-a514-4076-a1df-7fe4c0d8b31b@github.com>
References: <tcZkZgScJXJYpRK68NSRUTl7gcOhePhABSQz0DOzArI=.137600e0-7656-4c7a-85de-c340173467fc@github.com>
 <M7K--fqIQU_E8LdwuAE4fXNMB90mjh6jVkCCegmmz0I=.04616e1e-4f8c-4df2-a699-02520ac96c7d@github.com>
 <bLLsppdQBU2jMbn2p3NK70ShoBMbB8xxjnlDE_FYV_g=.13f7414c-a514-4076-a1df-7fe4c0d8b31b@github.com>
Message-ID: <oUPq_iF3kLf0mXLsmT0WNVOg9PQlX1gTKFwM6GEVfEw=.13e4cdbb-8ffd-40c7-af70-e24f1e010444@github.com>

On Wed, 30 Apr 2025 11:25:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The bug description seems like it is a fault in the JVM implementation - if that is the case, a core library bypass is unreliable, as such faults might happen to other classes and cause other consequences; and we might need to fix it from the VM runtime or compiler side, as the original report implies.
>
>> The bug description seems like it is a fault in the JVM implementation - if that is the case, a core library bypass is unreliable, as such faults might happen to other classes and cause other consequences; and we might need to fix it from the VM runtime or compiler side, as the original report implies.
> 
> It seems to about nested parking that can arise with the first use of LockSupport.park from a class with a defining class loader that is not the boot loader. The first usage, say an invokestatic to call the park method, will call the loadClass on caller's defining class loader.  For the app class loader, and many other custom class loaders, that are parallel capable, then there will be a CHM to support the mapping of class names to locks. Contention on the CHM seems to have lead to the nested park.  CHM and a lot of other code has changed since and not clear that it will duplicate easily now. Martin's ParkLoops test from the 2015 issue is in the test tree but it might be that a variant of this that uses a custom class loader that overrides getClassLoadingLock or parks in loadClass might be able to trigger it. As a custom class loader's loadClass can do anything then it almost feels like creating a class loader needs it have it recorded immediately as an initiating class loader. Hop
 efully David will remember more of this when he gets back.

> I'll second @AlanBateman 's sentiments here. I think a systemic issue needs a wholesale solution, otherwise it'll just lead to endless sprinkling of eager initializations.

Right, and even then, the issue is deeper than this. It's when the reference to LockSupport is from a class with a non-null defining class loader. In that scenario, the non-null class loader is the initiating class loader and any parking in the delegation chain to get to the boot loader could potentially consume the park permit. I don't think we should go down the road of supporting nested parking, instead it may be that we need some eager setup. I think we can close this PR for now as it doesn't really address the issue (LockSupport is already loaded before any user code executes).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2862877836

From alanb at openjdk.org  Thu May  8 13:03:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 May 2025 13:03:53 GMT
Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for empty ZipEntry
In-Reply-To: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
References: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
Message-ID: <izBPIV3nGQ5szsnt9P8B-8O9xVRXOpyN5QZbLx8dg9A=.0d7dfa26-b3f1-4557-abe4-75fdb436a74d@github.com>

On Thu, 8 May 2025 12:08:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799?
> 
> `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix.
> 
> tier testing is currently in progress.

Do you have any sense on whether there are JAR files in use that have wrong CRCs for empty entries? I'm just wondering if there are any wonky tools or plugins in the eco system, the output of which could be impacted by the more strict check.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25116#issuecomment-2862971376

From jpai at openjdk.org  Thu May  8 13:13:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 May 2025 13:13:57 GMT
Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for empty ZipEntry
In-Reply-To: <izBPIV3nGQ5szsnt9P8B-8O9xVRXOpyN5QZbLx8dg9A=.0d7dfa26-b3f1-4557-abe4-75fdb436a74d@github.com>
References: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
 <izBPIV3nGQ5szsnt9P8B-8O9xVRXOpyN5QZbLx8dg9A=.0d7dfa26-b3f1-4557-abe4-75fdb436a74d@github.com>
Message-ID: <lvbbrz5IveoVXEBYgV5PqoctEoTH8DS1KqtWnRBqQpA=.c1d51bec-34a2-444a-8849-4e7cbaf81cb1@github.com>

On Thu, 8 May 2025 13:01:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I'm just wondering if there are any wonky tools or plugins in the eco system, the output of which could be impacted by the more strict check.

I'll run some experiments and see what it shows up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25116#issuecomment-2863017735

From pminborg at openjdk.org  Thu May  8 13:16:25 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 May 2025 13:16:25 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v10]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <w3MMw5Cgcq8gTBYPG_uhvGujd42WZS9qjXQIw1FgINg=.de6593f1-470c-4bf1-a8b9-7aaae38ffb94@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add composition of functions and MHs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/e928591a..1628b264

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=08-09

  Stats: 292 lines in 4 files changed: 157 ins; 45 del; 90 mod
  Patch: https://git.openjdk.org/jdk/pull/25040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040

PR: https://git.openjdk.org/jdk/pull/25040

From nbenalla at openjdk.org  Thu May  8 13:18:07 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 8 May 2025 13:18:07 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v2]
In-Reply-To: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
Message-ID: <IQH5pfqDgtW2UCEbM800YyXfqbnB9VBT8f3T0oGZ3tY=.99cb3c22-45d4-43d8-a575-379b315bbc14@github.com>

> Get JDK 26 underway.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Update release date
 - Update --release 25 symbol information for JDK 25 build 21
   The macOS/AArch64 build 21 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
   
   # Conflicts:
   #	test/langtools/tools/javac/versions/Versions.java
 - feedback: never bump ASM version
 - Update copyright years
   
   Note: any commit hashes below might be outdated due to subsequent
   history rewriting (e.g. git rebase).
   
    + update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitorPreview.java due to 6077665a274
    + update src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java due to 6077665a274
    + update src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java due to 6077665a274
    + update test/langtools/tools/javac/api/TestGetSourceVersions.java due to 6077665a274
    + update test/langtools/tools/javac/classfiles/ClassVersionChecker.java due to 6077665a274
    + update test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java due to 6077665a274
    + update test/langtools/tools/javac/versions/Versions.java due to 6077665a274
 - Update --release 25 symbol information for JDK 24 build 20
   The macOS/AArch64 build 20 was taken from https://jdk.java.net/25/
 - initial commit start-of-JDK-26

-------------

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=01
  Stats: 1390 lines in 53 files changed: 1299 ins; 16 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/25008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008

PR: https://git.openjdk.org/jdk/pull/25008

From nbenalla at openjdk.org  Thu May  8 13:18:08 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 8 May 2025 13:18:08 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v2]
In-Reply-To: <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
 <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
Message-ID: <NZS8nG9pke2VR2jVtRZLeDMYst9ziR3FqvYdLxFOL14=.509579cd-046f-4c71-8cfa-952ffd787ca2@github.com>

On Fri, 2 May 2025 16:42:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50:
>> 
>>> 48: public class HelpOutputColumnWidthTest extends TestRunner {
>>> 49: 
>>> 50:     public static final int MAX_COLUMNS = 84;
>> 
>> What is this for?
>
> It is to accommodate the now longer list of --release values in the javac help output,the addition of ", 26".
> 
> Splitting the list of releases over two lines would be a better solution, but I didn't take that one when initially preparing the patch.

I'll split the releases over  two lines in the next update. The line is a little too long.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2079697514

From pminborg at openjdk.org  Thu May  8 13:28:56 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 May 2025 13:28:56 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v3]
In-Reply-To: <vfrf8Cx8oHAF4JpUITn4iqppXgIKVXzWBKojA_t4TqE=.8fb827e3-e60d-42e4-919b-f18f310694bf@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <vfrf8Cx8oHAF4JpUITn4iqppXgIKVXzWBKojA_t4TqE=.8fb827e3-e60d-42e4-919b-f18f310694bf@github.com>
Message-ID: <59OdbQo1ngGTIk-vHURu151vFfblIVyHRATwhTGqFY0=.e5a6c409-e23d-435c-a86c-4847ac392ef1@github.com>

On Wed, 7 May 2025 18:33:11 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prefix touched methods with `unchecked`

LGTM

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2825136323

From alanb at openjdk.org  Thu May  8 13:31:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 May 2025 13:31:51 GMT
Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for empty ZipEntry
In-Reply-To: <lvbbrz5IveoVXEBYgV5PqoctEoTH8DS1KqtWnRBqQpA=.c1d51bec-34a2-444a-8849-4e7cbaf81cb1@github.com>
References: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
 <izBPIV3nGQ5szsnt9P8B-8O9xVRXOpyN5QZbLx8dg9A=.0d7dfa26-b3f1-4557-abe4-75fdb436a74d@github.com>
 <lvbbrz5IveoVXEBYgV5PqoctEoTH8DS1KqtWnRBqQpA=.c1d51bec-34a2-444a-8849-4e7cbaf81cb1@github.com>
Message-ID: <pJbn0w0Yt5ZvyLhRnHWHdiIomcYAWowB8_Vd3Tk7wSA=.29411943-6453-4985-9c62-49bb0e3b9202@github.com>

On Thu, 8 May 2025 13:10:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I'll run some experiments and see what it shows up.

Thanks as that will help inform as to whether this will need a compatibility knob.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25116#issuecomment-2863078781

From vromero at openjdk.org  Thu May  8 13:33:45 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 8 May 2025 13:33:45 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Merge branch 'master' into JDK-8354556
 - addressing review comment
 - changes to test
 - Merge branch 'master' into JDK-8354556
 - updating test
 - final adjustments
 - additional refactorings
 - removing unneeded changes
 - more refactorings
 - more refactorings and tests
 - ... and 16 more: https://git.openjdk.org/jdk/compare/900b3ff7...5d834ce0

-------------

Changes: https://git.openjdk.org/jdk/pull/24746/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=05
  Stats: 497 lines in 25 files changed: 471 ins; 6 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

PR: https://git.openjdk.org/jdk/pull/24746

From eirbjo at openjdk.org  Thu May  8 13:34:53 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 8 May 2025 13:34:53 GMT
Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for empty ZipEntry
In-Reply-To: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
References: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
Message-ID: <CE-k-_kw24JWb1f8xzF8Mvs1yoSMmGw5orSvnsyjSNo=.8183c819-8887-42ed-affc-07d69eb9c293@github.com>

On Thu, 8 May 2025 12:08:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799?
> 
> `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix.
> 
> tier testing is currently in progress.

I found ?empty ZipEntry? in the title here somewhat confusing since that?s an API class and can?t be ?empty? as such.

We think ?ZIP entry with empty file data? would be more correct.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25116#issuecomment-2863085922

From lancea at openjdk.org  Thu May  8 13:39:55 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 8 May 2025 13:39:55 GMT
Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for empty ZipEntry
In-Reply-To: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
References: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
Message-ID: <gcXN6w4mPDBA8yGi2c3QOpAYdbxllM34keQwLrUpgLo=.cdec8b5d-b17b-4f06-bfca-7b40c279ccb6@github.com>

On Thu, 8 May 2025 12:08:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799?
> 
> `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix.
> 
> tier testing is currently in progress.

Hi Jai,

I think the changes overall look good.

You could simplify the test by creating a zip then converting the bytes to a Hex string/byte array and store it in the test.

I mention this as you are searching for a Data Descriptor signature that is optional in the test.  If you  capture the byte array/Hex String and then write it out as part of the start of the test.  The hex offsets from ZipDetails will be accurate.

Again, not a big deal either way, but wanted to mention it

test/jdk/java/util/zip/ZipInputStream/ZipInputStreamCRCCheck.java line 99:

> 97:             final ZipEntry entry = zis.getNextEntry();
> 98:             assertEquals(entryName, entry.getName(), "unexpected entry name");
> 99:             try {

I would consider changing this to something such as we did in open/test/jdk/java/util/zip/ZipInputStream/Zip64DataDescriptor.java:

` ZipException ex = assertThrows(ZipException.class, () -> {
            readZipInputStream(invalidZip64);
        });
        String msg = String.format("Expected exeption message to contain 'invalid entry size', was %s",
                ex.getMessage());
        assertTrue(ex.getMessage().contains("invalid entry size"), msg);
    }`

-------------

PR Review: https://git.openjdk.org/jdk/pull/25116#pullrequestreview-2825110440
PR Review Comment: https://git.openjdk.org/jdk/pull/25116#discussion_r2079701386

From lancea at openjdk.org  Thu May  8 13:46:56 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 8 May 2025 13:46:56 GMT
Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for empty ZipEntry
In-Reply-To: <pJbn0w0Yt5ZvyLhRnHWHdiIomcYAWowB8_Vd3Tk7wSA=.29411943-6453-4985-9c62-49bb0e3b9202@github.com>
References: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
 <izBPIV3nGQ5szsnt9P8B-8O9xVRXOpyN5QZbLx8dg9A=.0d7dfa26-b3f1-4557-abe4-75fdb436a74d@github.com>
 <lvbbrz5IveoVXEBYgV5PqoctEoTH8DS1KqtWnRBqQpA=.c1d51bec-34a2-444a-8849-4e7cbaf81cb1@github.com>
 <pJbn0w0Yt5ZvyLhRnHWHdiIomcYAWowB8_Vd3Tk7wSA=.29411943-6453-4985-9c62-49bb0e3b9202@github.com>
Message-ID: <BccBP00ww3iFq3kGftyGDVz5qmEfAemsq6VKtS5lc44=.75c12453-67fb-4cd2-af95-5ab78b290420@github.com>

On Thu, 8 May 2025 13:29:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I'll run some experiments and see what it shows up.
> 
> Thanks as that will help inform as to whether this will need a compatibility knob.

The crc is calculated as part of the write of the entry and I have not seen any cases, where the CRC is not 0 for a directory/ 0-length file

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25116#issuecomment-2863124377

From duke at openjdk.org  Thu May  8 13:49:54 2025
From: duke at openjdk.org (kabutz)
Date: Thu, 8 May 2025 13:49:54 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <-elHwuRlU4xfy382a9QVdVT6WQMPoZyyEHANGR2TgmQ=.b4329ab0-7f2e-4c7b-9053-9917f2ea3a5f@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <-elHwuRlU4xfy382a9QVdVT6WQMPoZyyEHANGR2TgmQ=.b4329ab0-7f2e-4c7b-9053-9917f2ea3a5f@github.com>
Message-ID: <EA5TgRWJRik6NTmG9n7L12cq-viCZ9wcOMu2spIgEPk=.06fc3b76-8949-45c5-a280-08424a898e45@github.com>

On Thu, 8 May 2025 08:33:06 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> I'm a bit uneasy about incrementing the `count` in `linkFirst` but not enforcing the invariant. What's the benefit to changing linkFirst and linkLast to return void instead of keeping the original returning a boolean?

I based the approach on the LBQ enqueue() and dequeue() methods, which also return void and have a comment with the assertion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079757838

From duke at openjdk.org  Thu May  8 13:55:54 2025
From: duke at openjdk.org (kabutz)
Date: Thu, 8 May 2025 13:55:54 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <VjVR6fAsjI47ypazhGOkMo5b6Q451Y7yjyKPeNm-_e0=.371a3007-d96b-40e4-bfa3-4e14ab2d2ebe@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <VjVR6fAsjI47ypazhGOkMo5b6Q451Y7yjyKPeNm-_e0=.371a3007-d96b-40e4-bfa3-4e14ab2d2ebe@github.com>
Message-ID: <znTHuGY13_blYpGZOhjbjcSZAbsdGmPqI1SZb4-Y7ek=.37c22106-d082-4f6a-a03e-7eaa6e897c87@github.com>

On Thu, 8 May 2025 08:41:52 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> We could likely check if there's any remaining capacity up front, and immediately return false?

We could if you like. I wanted to make as few changes as possible, to not introduce unexpected changes. This particular bug was to stop a size overflow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079769379

From alanb at openjdk.org  Thu May  8 14:01:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 May 2025 14:01:52 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
In-Reply-To: <RSw6f0K6lXGV1W1l3aA0dC6Pf8317W_caoDKCW3gEYs=.48da9942-f2c4-47e8-94df-b1e22721d70e@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <RSw6f0K6lXGV1W1l3aA0dC6Pf8317W_caoDKCW3gEYs=.48da9942-f2c4-47e8-94df-b1e22721d70e@github.com>
Message-ID: <FfiQ25MUw5uoY6GQy6eBVQLyD6yQ1uEJjjaZUXIn_4k=.c62d4703-b6e5-4b90-b1e4-b5d359c4459e@github.com>

On Wed, 7 May 2025 19:05:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was called on the target library file before it was passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail.
>> 
>> Fix this problem by using `File.getAbsolutePath()` instead of `File.getCanonicalPath()` in `NativeLibraries.java`.
>
> Would it be possible to paste in here, or in the JBS issue, some examples of the path provided to LoadLibrary with some commentary on the sym links created on the file system.

> You might be correct. We'll see what @AlanBateman and others have to say about it.

It's still puzzled as to why the DLLs have been moved from the JDK bin directory to some other location, and renamed so they don't have the ".dll" suffix. There most be some other product in the picture that we can't see. The quoted text from the Windows LoadLibrary documentation, where it appends the ".dll" suffix when not provided, is very useful as it  helps us understand why it fails.

As regards dropping the canonicalization then it would require thinking about the lock map used for mapping the library names to locks. It would need checking if it would break concurrent loading when using different names / file paths to the same DLL. There may be a route that involves adding a method to ClassLoaderHelper to post-process the path and the Windows version could add the "." when it doesn't have the ".dll" suffix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2863176924

From duke at openjdk.org  Thu May  8 14:30:57 2025
From: duke at openjdk.org (kabutz)
Date: Thu, 8 May 2025 14:30:57 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <rO9njoSonLf7DLUrHaB9jMMXDTodgbWlZ-391cqxW50=.0f02cb42-105b-4aaf-88cf-9d6574e0d555@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <rO9njoSonLf7DLUrHaB9jMMXDTodgbWlZ-391cqxW50=.0f02cb42-105b-4aaf-88cf-9d6574e0d555@github.com>
Message-ID: <evfaz5EKS-CJbYM0Ai3PqcC-0Soa6CC4TfJ_ZHAK1vs=.0515c9b9-7bec-4782-8482-86956e1cb173@github.com>

On Thu, 8 May 2025 08:59:59 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> We logged several bugs on the LinkedBlockingDeque. This aggregates them into a single bug report and PR.
>> 
>> 1. LinkedBlockingDeque does not immediately throw InterruptedException in put/take
>> 
>> The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down.
>> 
>> 2. LinkedBlockingDeque.clear() should preserve weakly-consistent iterators
>> 
>> LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work.
>> 
>> The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator thus all support self-linking.
>> 
>> This can be fixed very easily by linking both f.prev and f.next back to f.
>> 
>> 3. LinkedBlockingDeque offer() creates nodes even if capacity has been reached
>> 
>> In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking.
>> 
>> In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field.
>> 
>> 4. LinkedBlockingDeque allows us to overflow size with addAll()
>> 
>> In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst hol...
>
> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 865:
> 
>> 863:         long n = 0;
>> 864:         for (E e : c) {
>> 865:             Objects.requireNonNull(e);
> 
> This makes me wonder: Does it make sense to create new nodes if we don't track if they will still fit into the capacity?

We could if you like, but that would subtly change the current behaviour. I tried to make as few changes as possible.

> Out of curiosity, how does `it.remove()` work under these conditions?

If we call it.remove() on the first element, it delegates to unlinkFirst() (if we are using an ascending iterator), and unlinkLast (if we are using a descending iterator). Similarly, if we call it.remove() on the last element it will call unlinkLast() or unlinkFirst(). With unlinkFirst(), it will make f.next = f (thus linking back to itself) and with unlinkLast(), it will make l.prev = l.

If we call it.remove() on a middle element, then we simply link the p.next = n; n.prev = p; and does not do self-linking. Thus if we have an LBD with 1,2,3,4,5 with two iterators pointing onto 3, if one of them removes it, then the other will continue with 3 (cached), 4, 5, and it won't go back to the beginning and see duplicate elements.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079836006
PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2079833797

From pminborg at openjdk.org  Thu May  8 14:36:32 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 May 2025 14:36:32 GMT
Subject: RFR: 8356486: ReverseOrderListView::reversed should return `base`
Message-ID: <X2vnz1BagQ5K7q-2_oHt9X1JjejNJw5TE44vSUJKeaU=.28fad491-d94c-4fcb-9a44-001a62e0beb4@github.com>

This PR proposed to let `ReverseOrderListView::reversed` return `base` so that nested reversed views are avoided.

-------------

Commit messages:
 - Let ReverseOrderListView::reversed return base

Changes: https://git.openjdk.org/jdk/pull/25120/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25120&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356486
  Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25120.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25120/head:pull/25120

PR: https://git.openjdk.org/jdk/pull/25120

From liach at openjdk.org  Thu May  8 14:46:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 14:46:55 GMT
Subject: RFR: 8356486: ReverseOrderListView::reversed should return `base`
In-Reply-To: <X2vnz1BagQ5K7q-2_oHt9X1JjejNJw5TE44vSUJKeaU=.28fad491-d94c-4fcb-9a44-001a62e0beb4@github.com>
References: <X2vnz1BagQ5K7q-2_oHt9X1JjejNJw5TE44vSUJKeaU=.28fad491-d94c-4fcb-9a44-001a62e0beb4@github.com>
Message-ID: <EINLtspNPHYrnKfHa4KM28W921Q_CuMpBAvY6H8pnoM=.b554ca1e-732f-4f33-9078-6a34a33fabed@github.com>

On Thu, 8 May 2025 14:30:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to let `ReverseOrderListView::reversed` return `base` so that nested reversed views are avoided.

test/jdk/java/util/Collection/MOAT.java line 507:

> 505:     private static <T> void testImmutableSeqColl(final SequencedCollection<T> c, T t) {
> 506:         SequencedCollection<T> r = c.reversed();
> 507:         if (r instanceof List<T> list && list.reversed() != c) {

Shouldn't all double-reverse be identity? Why is this restricted to lists?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25120#discussion_r2079865444

From liach at openjdk.org  Thu May  8 14:55:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 14:55:07 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v3]
In-Reply-To: <vfrf8Cx8oHAF4JpUITn4iqppXgIKVXzWBKojA_t4TqE=.8fb827e3-e60d-42e4-919b-f18f310694bf@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <vfrf8Cx8oHAF4JpUITn4iqppXgIKVXzWBKojA_t4TqE=.8fb827e3-e60d-42e4-919b-f18f310694bf@github.com>
Message-ID: <X4qAmXI_8QngD0dLGKblYZVwileF21OQ31ermPeS3F0=.0ca215ee-c41e-411d-b5ba-2b9714c84e92@github.com>

On Wed, 7 May 2025 18:33:11 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prefix touched methods with `unchecked`

Reviewed missing copyright updates. Only files with comments need copyright year updates.

Let's re-approve after copyright fix.

src/java.base/share/classes/java/io/DataInputStream.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/java/io/ObjectInputStream.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/java/util/HexFormat.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/java/util/zip/ZipCoder.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/sun/nio/cs/CESU_8.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/sun/nio/cs/DoubleByte.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/sun/nio/cs/SingleByte.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/sun/nio/cs/US_ASCII.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/sun/nio/cs/UTF_8.java line 1:

> 1: /*

Copyright year

src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 1:

> 1: /*

Copyright year

src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template line 1:

> 1: /*

Copyright year

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2825397502
Changes requested by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2825413999
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079869063
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079869753
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079870851
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079871207
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079873366
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079874098
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079874388
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079874760
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079875143
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079875444
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079875789
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079876056
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079876669
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079877098

From lkorinth at openjdk.org  Thu May  8 15:02:42 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 15:02:42 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for change
 of default timeout factor
Message-ID: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>

This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).

The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.

In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).

My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.

These fixes have been created when I have plown through testcases:
JDK-8352719: Add an equals sign to the modules statement
JDK-8352709: Remove bad timing annotations from WhileOpTest.java
JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
CODETOOLS-7903961: Make default timeout configurable

Sometime in the future I will also fix:
8260555: Change the default TIMEOUT_FACTOR from 4 to 1

for which I am awaiting:
CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1

*After the review I will revert the two first commits, and update the copyrights*

-------------

Commit messages:
 - 8356171: Increase timeout for testcases as preparation for change of default timeout factor
 - Fix some tests that need an upgrade of JTREG --- REVERT THIS LATER
 - 8260555

Changes: https://git.openjdk.org/jdk/pull/25122/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25122&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356171
  Stats: 556 lines in 272 files changed: 59 ins; 96 del; 401 mod
  Patch: https://git.openjdk.org/jdk/pull/25122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25122/head:pull/25122

PR: https://git.openjdk.org/jdk/pull/25122

From rgiulietti at openjdk.org  Thu May  8 15:13:19 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 8 May 2025 15:13:19 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v3]
In-Reply-To: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
Message-ID: <djTclwh1LKH7n2fyWkCGSGT6Fwaj83QmxlG9sxrhntk=.bc07f557-ba6d-4c17-87ba-50b4a2112885@github.com>

> Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments.
> Further, add `unsignedMultiplyExact` methods as well.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Added tests.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25003/files
  - new: https://git.openjdk.org/jdk/pull/25003/files/2d3405f2..8c146e9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25003&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25003&range=01-02

  Stats: 392 lines in 1 file changed: 392 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25003/head:pull/25003

PR: https://git.openjdk.org/jdk/pull/25003

From duke at openjdk.org  Thu May  8 15:31:06 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 8 May 2025 15:31:06 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v10]
In-Reply-To: <w3MMw5Cgcq8gTBYPG_uhvGujd42WZS9qjXQIw1FgINg=.de6593f1-470c-4bf1-a8b9-7aaae38ffb94@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <w3MMw5Cgcq8gTBYPG_uhvGujd42WZS9qjXQIw1FgINg=.de6593f1-470c-4bf1-a8b9-7aaae38ffb94@github.com>
Message-ID: <K-tpXpxA22SjlA8AaNr-eVfLlKdRhy8tuclOw_xEkRc=.62f4eee3-e95b-47fc-9848-cd567f4174f4@github.com>

On Thu, 8 May 2025 13:16:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add composition of functions and MHs

test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 120:

> 118: 
> 119:         private static final ToIntFunction<LazyFoo> HASH_UPDATER =
> 120:                 StableFieldUpdater.ofInt(LazyFoo.class, "hash",

Very clean now.

test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 183:

> 181:     static
> 182: 
> 183:     public final class MhFoo {

I'm assuming this is explicitly the "behind the scenes" raw version of it in case anyone want's to step off the well-lit path. Hard to comment without seeing any surrounding docs. I don't suppose a link to the docs in which these are given can be added (just to give context for future maintainers)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2079941869
PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2079953010

From duke at openjdk.org  Thu May  8 15:33:17 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 8 May 2025 15:33:17 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v54]
In-Reply-To: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
Message-ID: <u50QX6oL3I2pglsUieiQRMKJ5Muy4e6IU4C14kwDQNU=.0bba7a91-4420-4205-80ec-8ce7d799b708@github.com>

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Suggested changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/009937b9..2e08f775

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=53
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=52-53

  Stats: 21 lines in 2 files changed: 0 ins; 5 del; 16 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 rgiulietti at openjdk.org  Thu May  8 15:50:55 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 8 May 2025 15:50:55 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v54]
In-Reply-To: <u50QX6oL3I2pglsUieiQRMKJ5Muy4e6IU4C14kwDQNU=.0bba7a91-4420-4205-80ec-8ce7d799b708@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <u50QX6oL3I2pglsUieiQRMKJ5Muy4e6IU4C14kwDQNU=.0bba7a91-4420-4205-80ec-8ce7d799b708@github.com>
Message-ID: <ZCZXZ5pUI4k1kWhD0EfI3oV9W4vYfGX24JoSRSPHrFM=.f58d3c53-be2a-4898-9734-5a407f08a619@github.com>

On Thu, 8 May 2025 15:33:17 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggested changes

Please update the 2nd copyright year in `BigInteger`.

Otherwise looks good.
As soon as you as you feel comfortable with your changes, let me know so that I can approve.

Thanks for yet another nice contribution!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2863533055

From pchilanomate at openjdk.org  Thu May  8 15:54:25 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 8 May 2025 15:54:25 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock
Message-ID: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>

Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments).

I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup).

I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix.

Thanks,
Patricio

-------------

Commit messages:
 - v1

Changes: https://git.openjdk.org/jdk/pull/25119/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25119&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346255
  Stats: 10 lines in 1 file changed: 5 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25119.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25119/head:pull/25119

PR: https://git.openjdk.org/jdk/pull/25119

From jpai at openjdk.org  Thu May  8 16:05:04 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 May 2025 16:05:04 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v12]
In-Reply-To: <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
 <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com>
Message-ID: <8ntdUbcNZXlhpmPdasBRHkvBiJ_sytIXP144tDZ53JA=.95b23097-a3dd-43f7-986e-dcee4b2a6fb4@github.com>

On Fri, 2 May 2025 15:17:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/ClassValue.java
>   
>   Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>

src/java.base/share/classes/java/lang/ClassValue.java line 241:

> 239:                 } else {
> 240:                     throw ex instanceof Error err ? err : new Error(ex);
> 241:                 }

Hello Chen, i think this if/else for exception type checks can instead just be replaced with an unconditional `throw ex`;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2080019642

From smarks at openjdk.org  Thu May  8 16:05:57 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 8 May 2025 16:05:57 GMT
Subject: RFR: 8356486: ReverseOrderListView::reversed should return `base`
In-Reply-To: <X2vnz1BagQ5K7q-2_oHt9X1JjejNJw5TE44vSUJKeaU=.28fad491-d94c-4fcb-9a44-001a62e0beb4@github.com>
References: <X2vnz1BagQ5K7q-2_oHt9X1JjejNJw5TE44vSUJKeaU=.28fad491-d94c-4fcb-9a44-001a62e0beb4@github.com>
Message-ID: <GrQz8XzY1qPrVDHsodwotspGsyr37X8RvY-zq_-ysC4=.810edd9b-3a77-4b72-837b-d34c9fb946cd@github.com>

On Thu, 8 May 2025 14:30:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to let `ReverseOrderListView::reversed` return `base` so that nested reversed views are avoided.

I think there are already tests to ensure that list.reversed().reversed() returns the original list. See also https://github.com/openjdk/jdk/pull/24990 which adds some tests (but these are mostly about synchronized wrappers and propagation of RandomAccess). But we can assess the need for tests after 24990 is integrated.

As I noted in the bug report ReverseOrderListView.reversed() really does end up returning base, but it does so in a roundabout fashion that could be cleaned up by adding the override as is done here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25120#issuecomment-2863573737

From stefank at openjdk.org  Thu May  8 16:09:00 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 May 2025 16:09:00 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Thanks for tackling this! I look forward to the day when you change TIMEOUT_FACTOR to be 1 by default. I think that will reduce confusion.

I made a cursory look through some GC files and I think that looked good.

doc/testing.md line 385:

> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
> 384: certain amount of time will apply this factor. If we run in
> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)

Maybe
Suggestion:

interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

-------------

PR Review: https://git.openjdk.org/jdk/pull/25122#pullrequestreview-2825661242
PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080028720

From liach at openjdk.org  Thu May  8 16:09:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 16:09:00 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v12]
In-Reply-To: <8ntdUbcNZXlhpmPdasBRHkvBiJ_sytIXP144tDZ53JA=.95b23097-a3dd-43f7-986e-dcee4b2a6fb4@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
 <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com>
 <8ntdUbcNZXlhpmPdasBRHkvBiJ_sytIXP144tDZ53JA=.95b23097-a3dd-43f7-986e-dcee4b2a6fb4@github.com>
Message-ID: <J4EUd7mG3iVgCDMaH6sIaV6ex2-RWv3RysXONHNfVPA=.a82ba9dc-cf61-4186-8c2d-166b561e684d@github.com>

On Thu, 8 May 2025 16:01:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/lang/ClassValue.java
>>   
>>   Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>
>
> src/java.base/share/classes/java/lang/ClassValue.java line 241:
> 
>> 239:                 } else {
>> 240:                     throw ex instanceof Error err ? err : new Error(ex);
>> 241:                 }
> 
> Hello Chen, i think this if/else for exception type checks can instead just be replaced with an unconditional `throw ex`;

I tried that and failed compilation before

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2080032029

From smarks at openjdk.org  Thu May  8 16:11:01 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 8 May 2025 16:11:01 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
In-Reply-To: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
Message-ID: <Rlf0LO25ddjS7CZQ7IIBCiwEhP-bFt_vJoODV7MFzSA=.76c65b2c-d478-4aa4-ba5f-bd25273d04b2@github.com>

On Fri, 2 May 2025 12:13:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
> 
> Unfortunately, this PR shows the total commit history for stable values.

src/java.base/share/classes/java/util/ImmutableCollections.java line 954:

> 952:                 return deepRoot(sub.root);
> 953:             }
> 954:             throw new InternalError("Should not reach here: " + list.getClass().getName());

Does this need to be recursive? There is logic to avoid nesting of sublists, and a sublist of a reversed view should end up being a reversed view of a sublist, so the most deep nesting that can occur is reversed(sublist(base)).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2080034660

From smarks at openjdk.org  Thu May  8 16:15:54 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 8 May 2025 16:15:54 GMT
Subject: RFR: 8356486: ReverseOrderListView::reversed should return `base`
In-Reply-To: <X2vnz1BagQ5K7q-2_oHt9X1JjejNJw5TE44vSUJKeaU=.28fad491-d94c-4fcb-9a44-001a62e0beb4@github.com>
References: <X2vnz1BagQ5K7q-2_oHt9X1JjejNJw5TE44vSUJKeaU=.28fad491-d94c-4fcb-9a44-001a62e0beb4@github.com>
Message-ID: <IgXAro0ZuX9jtuaE0FbWSS0F_Qx_-Qb91B_hq5JpAQU=.38fc0f4c-4a3e-4c4b-8aad-60cea6c44e6e@github.com>

On Thu, 8 May 2025 14:30:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to let `ReverseOrderListView::reversed` return `base` so that nested reversed views are avoided.

src/java.base/share/classes/java/util/ReverseOrderListView.java line 398:

> 396:     }
> 397: 
> 398:     @Override

I don't use the Override annotation in collections. It can be useful for catching errors, but once the code is tested properly, having the annotation merely adds clutter.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25120#discussion_r2080039319

From smarks at openjdk.org  Thu May  8 16:15:56 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 8 May 2025 16:15:56 GMT
Subject: RFR: 8356486: ReverseOrderListView::reversed should return `base`
In-Reply-To: <EINLtspNPHYrnKfHa4KM28W921Q_CuMpBAvY6H8pnoM=.b554ca1e-732f-4f33-9078-6a34a33fabed@github.com>
References: <X2vnz1BagQ5K7q-2_oHt9X1JjejNJw5TE44vSUJKeaU=.28fad491-d94c-4fcb-9a44-001a62e0beb4@github.com>
 <EINLtspNPHYrnKfHa4KM28W921Q_CuMpBAvY6H8pnoM=.b554ca1e-732f-4f33-9078-6a34a33fabed@github.com>
Message-ID: <R1KALQrvyYCiu1BsIG_De23Tvr_f1qnQWDZZDTshqUs=.509f270e-1564-4480-86e1-0fbbc2de5890@github.com>

On Thu, 8 May 2025 14:44:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR proposed to let `ReverseOrderListView::reversed` return `base` so that nested reversed views are avoided.
>
> test/jdk/java/util/Collection/MOAT.java line 507:
> 
>> 505:     private static <T> void testImmutableSeqColl(final SequencedCollection<T> c, T t) {
>> 506:         SequencedCollection<T> r = c.reversed();
>> 507:         if (r instanceof List<T> list && list.reversed() != c) {
> 
> Shouldn't all double-reverse be identity? Why is this restricted to lists?

This should already be covered by the testDoubleReverse() test in test/jdk/java/util/SequencedCollection/Basic.java.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25120#discussion_r2080043447

From jpai at openjdk.org  Thu May  8 16:21:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 May 2025 16:21:56 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v12]
In-Reply-To: <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
 <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com>
Message-ID: <4RbSYMakxOtOH_UBIhK1s2F_A03cf_tEOOq4MO8VOjc=.34548e69-dda1-4d8f-b378-2f7e70c374a1@github.com>

On Fri, 2 May 2025 15:17:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/ClassValue.java
>   
>   Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>

src/java.base/share/classes/java/lang/ClassValue.java line 463:

> 461:                 var updated = entry.refreshVersion(classValue.version);
> 462:                 if (updated != entry) {
> 463:                     put(classValue.identity, updated);

This appears to associate a value and contradicts the `readAccess` method name and the comment on the method that says "A simple read access to this map".

Did I misunderstand what `readAccess` is meant in the context of `ClassValue` semantics?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2080052630

From dfuchs at openjdk.org  Thu May  8 16:28:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 16:28:53 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <VKBSy10yl0qvIk0P_JQb3KGFkmaDEtWYzncAlEW7VV8=.bd136181-45be-437e-b684-2ad16ac419b5@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

@lkorinth have you run all the tiers where the old default timeout factor of 4 applied?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863633579

From jpai at openjdk.org  Thu May  8 16:28:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 May 2025 16:28:55 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v12]
In-Reply-To: <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
 <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com>
Message-ID: <Ma-r8qZd7F17_3rG0EE10KYXB89HufOY57jtlUZEgr8=.150c9372-f464-487e-a28c-db0ec0191872@github.com>

On Fri, 2 May 2025 15:17:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/ClassValue.java
>   
>   Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>

src/java.base/share/classes/java/lang/ClassValue.java line 222:

> 220:         }
> 221: 
> 222:         RemovalToken permission = (RemovalToken) accessed; // nullable

This might be better if renamed to `removalToken` or just `token` instead of `permission`, in order to have a consistent terminology.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2080064021

From duke at openjdk.org  Thu May  8 16:44:55 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 8 May 2025 16:44:55 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v54]
In-Reply-To: <ZCZXZ5pUI4k1kWhD0EfI3oV9W4vYfGX24JoSRSPHrFM=.f58d3c53-be2a-4898-9734-5a407f08a619@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <u50QX6oL3I2pglsUieiQRMKJ5Muy4e6IU4C14kwDQNU=.0bba7a91-4420-4205-80ec-8ce7d799b708@github.com>
 <ZCZXZ5pUI4k1kWhD0EfI3oV9W4vYfGX24JoSRSPHrFM=.f58d3c53-be2a-4898-9734-5a407f08a619@github.com>
Message-ID: <OMhVN7GRBgHEV7-pyCcHpghizrNxuCRCaDz8E6Z2J6c=.41605189-d7b2-44df-bd9e-555a8fd00582@github.com>

On Thu, 8 May 2025 15:48:30 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Suggested changes
>
> Please update the 2nd copyright year in `BigInteger`.
> 
> Otherwise looks good.
> As soon as you feel comfortable with your changes, let me know so that I can approve.
> 
> Thanks for yet another nice contribution!

@rgiulietti Could be useful [this optimization](https://github.com/openjdk/jdk/pull/24690#issuecomment-2846711109) for `int` bases whose result does not fit in a `long`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2863674473

From lkorinth at openjdk.org  Thu May  8 16:45:56 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 16:45:56 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Before this version, I had run tiers 1-8, with 11 fails.

** DONE 01 serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java#debug 700
** DONE 02 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 03 tools/javac/util/IteratorsTest.java 480
** DONE 04 java/math/BigInteger/LargeValueExceptions.java 480
** DONE 05 vmTestbase/gc/gctests/WeakReference/weak004/weak004.java OTHER
** DONE 06 compiler/loopstripmining/CheckLoopStripMining.java OTHER
** DONE 07 sun/security/tools/keytool/fakecacerts/TrustedCert.java 480
** DONE 08 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 09 containers/docker/TestJFRNetworkEvents.java OTHER
** DONE 10 java/foreign/TestMismatch.java 480
** DONE 11 linux-riscv64-open-cmp-baseline-linux-x64-build-796 OTHER

Six of those seems not related to my changes (marked `OTHER`),  five  I have updated for this run with new timeout.

I have fixed the timeouts and rebased (I had one conflict), and I am now again running tier1-8. It will take time, and it looks like I will have more (unrelated) fails this time.

After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863670496
PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863675379

From liach at openjdk.org  Thu May  8 16:46:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 16:46:00 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v12]
In-Reply-To: <4RbSYMakxOtOH_UBIhK1s2F_A03cf_tEOOq4MO8VOjc=.34548e69-dda1-4d8f-b378-2f7e70c374a1@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
 <-ZvY_CNZX_YdRxKNf69Pl-bDaj6ikRxBgbZdwAzS0P0=.448e9d55-8eb8-4308-8f0b-d8c9166c8f1a@github.com>
 <4RbSYMakxOtOH_UBIhK1s2F_A03cf_tEOOq4MO8VOjc=.34548e69-dda1-4d8f-b378-2f7e70c374a1@github.com>
Message-ID: <fn1NczzGIlEBc8_r5jKBv8jIdN3B5rb4-rgEJwqGW_U=.b4b8f38f-e043-44fd-b3bd-e8ee47d69461@github.com>

On Thu, 8 May 2025 16:19:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/lang/ClassValue.java
>>   
>>   Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>
>
> src/java.base/share/classes/java/lang/ClassValue.java line 463:
> 
>> 461:                 var updated = entry.refreshVersion(classValue.version);
>> 462:                 if (updated != entry) {
>> 463:                     put(classValue.identity, updated);
> 
> This appears to associate a value and contradicts the `readAccess` method name and the comment on the method that says "A simple read access to this map".
> 
> Did I misunderstand what `readAccess` is meant in the context of `ClassValue` semantics?

Yep, this is unfortunately required for the cache mechanism - `refreshVersion` returns an equivalent entry, except its version is the latest, so the cache can trust this entry, if present in the cache array of a ClassValue, is up-to-date.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2080089371

From duke at openjdk.org  Thu May  8 16:48:40 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 8 May 2025 16:48:40 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v55]
In-Reply-To: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
Message-ID: <7M-1pUEDXUNzktL20pvRvodXVXP4Lr88-TaNjt6TNmg=.b1a0c128-56c6-4fab-80e0-e2a5108daff5@github.com>

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Code simplification

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/2e08f775..261dd315

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=54
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=53-54

  Stats: 39 lines in 1 file changed: 12 ins; 12 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From erikj at openjdk.org  Thu May  8 16:55:02 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 8 May 2025 16:55:02 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v6]
In-Reply-To: <tBEVMB0n8bNbzfjJy7jgJUxOa0Z-4OojY27IiXoxci8=.eec6f271-a45c-47f7-9f20-9ca219f1faea@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <tBEVMB0n8bNbzfjJy7jgJUxOa0Z-4OojY27IiXoxci8=.eec6f271-a45c-47f7-9f20-9ca219f1faea@github.com>
Message-ID: <fPux4cGBwIwNR4DXUuxBR8ErjRjnII1aGfXSLjbySVc=.8a1cc9ea-78bf-4b43-af65-8a11c381fb05@github.com>

On Thu, 8 May 2025 10:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into go-full-utf8
>  - Merge branch 'master' into go-full-utf8
>  - Add informative message  about supported locales.
>  - Allow C locale with warning instead of fatal error
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim
>  - Also tell javadoc that we have utf-8 now
>  - Fix flags for Windows
>  - Mark java and native source code as utf-8
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/2c1eb339...e68305db

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2825782371

From lkorinth at openjdk.org  Thu May  8 17:06:02 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 17:06:02 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
Message-ID: <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>

On Thu, 8 May 2025 16:04:53 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> doc/testing.md line 385:
> 
>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>> 384: certain amount of time will apply this factor. If we run in
>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
> 
> Maybe
> Suggestion:
> 
> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080117016

From aph at openjdk.org  Thu May  8 17:23:09 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 8 May 2025 17:23:09 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v3]
In-Reply-To: <NQ32IYSUNxVd-tXxSsXcQws2oqloSMOOsFkLhZOZTHI=.79bb71a2-d132-4ebe-920f-2694761a7e06@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <VkBzyrZMCwgRSotwkP2RdSV3x6B83eJgZF4mU830098=.b0d247e3-966a-441c-b7a1-974613eed3b3@github.com>
 <NQ32IYSUNxVd-tXxSsXcQws2oqloSMOOsFkLhZOZTHI=.79bb71a2-d132-4ebe-920f-2694761a7e06@github.com>
Message-ID: <DSWIRvVOesuILrioviU6AKwaA1V_4olZcYcgkvWJG94=.576853bc-4c40-48fa-9568-58b1e6ed15d5@github.com>

On Wed, 30 Apr 2025 12:48:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> @theRealAph Can you include the update to javax/security/auth/Subject.java as part of this?

Fixed now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2863756144

From aph at openjdk.org  Thu May  8 17:23:09 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 8 May 2025 17:23:09 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v5]
In-Reply-To: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
Message-ID: <h49xNNsfCgZ8Nbnc9ZctlLktqYWV-n5j-ojQZUTHtEQ=.4d792781-40bf-4123-88ca-be9c10a420ff@github.com>

> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a null argument.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  ScopedValue::orElse() does not accept null as an argument.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24923/files
  - new: https://git.openjdk.org/jdk/pull/24923/files/8f626617..a80b034c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24923/head:pull/24923

PR: https://git.openjdk.org/jdk/pull/24923

From aph at openjdk.org  Thu May  8 17:29:08 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 8 May 2025 17:29:08 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v6]
In-Reply-To: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
Message-ID: <gn_ctjNLQw59RNq3o8RQxt1jPn3Exs-UZtKH68v8PPc=.6970ce11-ec2a-4554-82ec-1b7633424034@github.com>

> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a null argument.

Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Fix merge
 - Merge from https://github.com/openjdk/jdk
 - ScopedValue::orElse() does not accept null as an argument.
 - Remove unnecessary @since 25
 - Remove unnecessary @enablePreview in some tests
 - Since when?
 - ScopedValue::orElse() does not accept null as an argument.
 - 8355720: Implement JEP 506: Scoped Values
 - Implement JEP 506: Scoped Values

-------------

Changes: https://git.openjdk.org/jdk/pull/24923/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=05
  Stats: 21 lines in 5 files changed: 3 ins; 11 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24923/head:pull/24923

PR: https://git.openjdk.org/jdk/pull/24923

From aph at openjdk.org  Thu May  8 17:33:09 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 8 May 2025 17:33:09 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
Message-ID: <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>

> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a null argument.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Fix merge

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24923/files
  - new: https://git.openjdk.org/jdk/pull/24923/files/8354bcb5..7d354394

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24923/head:pull/24923

PR: https://git.openjdk.org/jdk/pull/24923

From asemenyuk at openjdk.org  Thu May  8 17:34:25 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 8 May 2025 17:34:25 GMT
Subject: RFR: 8356562: SigningAppImageTwoStepsTest test fails
Message-ID: <ff7TI1O2z-0h7B3OE84g2vUWJOCFYdHz1xBepLHMack=.2152c970-44ee-4a2c-9857-922dd1214e25@github.com>

Fix JPackageCommand.assertAppImageFile() method to make it pass the relative path to ".jpackag.xml" file to JPackageCommand.assertFileInAppImage().

-------------

Commit messages:
 - Fix a bug in JPackageCommand.assertFileInAppImage() uncovered by running signing tests after JDK-8356219 fix. JDK-8356219 added a legit assert to JPackageCommand.assertFileInAppImage() and it failed.

Changes: https://git.openjdk.org/jdk/pull/25126/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25126&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356562
  Stats: 13 lines in 1 file changed: 6 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25126.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25126/head:pull/25126

PR: https://git.openjdk.org/jdk/pull/25126

From asemenyuk at openjdk.org  Thu May  8 17:34:25 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 8 May 2025 17:34:25 GMT
Subject: RFR: 8356562: SigningAppImageTwoStepsTest test fails
In-Reply-To: <ff7TI1O2z-0h7B3OE84g2vUWJOCFYdHz1xBepLHMack=.2152c970-44ee-4a2c-9857-922dd1214e25@github.com>
References: <ff7TI1O2z-0h7B3OE84g2vUWJOCFYdHz1xBepLHMack=.2152c970-44ee-4a2c-9857-922dd1214e25@github.com>
Message-ID: <l6hzhsiTHe5ly2f8nxThHGPvNkkTcLcnjbq2aRRQdgI=.b5e72006-ee49-4355-b36c-0e105e1a76b0@github.com>

On Thu, 8 May 2025 17:23:48 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix JPackageCommand.assertAppImageFile() method to make it pass the relative path to ".jpackag.xml" file to JPackageCommand.assertFileInAppImage().

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25126#issuecomment-2863779796

From dfuchs at openjdk.org  Thu May  8 17:43:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 17:43:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Thank you. I have imported your PR locally and running some HTTP client tests in the CI.
Tests have not finished running - but I already see one intermittent failure:
`java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows.
It would be good to flush out any such intermittent failures before this PR is integrated.
This might require multiple runs before we can get confidence.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863805648

From duke at openjdk.org  Thu May  8 17:43:31 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Thu, 8 May 2025 17:43:31 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
In-Reply-To: <FfiQ25MUw5uoY6GQy6eBVQLyD6yQ1uEJjjaZUXIn_4k=.c62d4703-b6e5-4b90-b1e4-b5d359c4459e@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <RSw6f0K6lXGV1W1l3aA0dC6Pf8317W_caoDKCW3gEYs=.48da9942-f2c4-47e8-94df-b1e22721d70e@github.com>
 <FfiQ25MUw5uoY6GQy6eBVQLyD6yQ1uEJjjaZUXIn_4k=.c62d4703-b6e5-4b90-b1e4-b5d359c4459e@github.com>
Message-ID: <i6vnOnhWHrQwvtNRf2Pcz-JffMc8EK4EUvAwdl3XDkw=.3c9dd884-8f04-4c0c-864f-a0bc0e758247@github.com>

On Thu, 8 May 2025 13:58:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > You might be correct. We'll see what @AlanBateman and others have to say about it.
> 
> I'm still puzzled as to why the DLLs have been moved from the JDK bin directory to some other location, and renamed so they don't have the ".dll" suffix. There most be some other product in the picture that we can't see. The quoted text from the Windows LoadLibrary documentation, where it appends the ".dll" suffix when not provided, is very useful as it helps us understand why it fails.

Yes, the mystery product is my code. :) It makes a JDK image with a tree of symlinks to a data directory. The regular files in the data directory do not have file extensions.

> 
> As regards dropping the canonicalization then it would require thinking about the lock map used for mapping the library names to locks. It would need checking if it would break concurrent loading when using different names / file paths to the same DLL.

I can see that removing the canonicalization could break the lock map. (Though I see the current deduplication and locking scheme doesn't handle hardlinks. Probably it would have to be keyed by `FileKey` to do that.)

> There may be a route that involves adding a method to ClassLoaderHelper to post-process the path and the Windows version could add the "." when it doesn't have the ".dll" suffix.

I tried out this approach, and it solves my problem. I've now pushed the implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2863795234

From duke at openjdk.org  Thu May  8 17:43:31 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Thu, 8 May 2025 17:43:31 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v2]
In-Reply-To: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
Message-ID: <_4819zr4DrfeUquda3NCpnW7HQi5WjtofWHZT2Eoh1M=.f90ef3e4-bb86-4886-8241-b5943d71ee18@github.com>

> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail.
> 
> Fix this problem by appending a `.` to library paths after canonicalization on Windows. This trailing dot inhibits `LoadLibrary`'s own appending behavior.

Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision:

  new approach: append . to file name on Windows

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24694/files
  - new: https://git.openjdk.org/jdk/pull/24694/files/46040f1f..f16626be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=00-01

  Stats: 22 lines in 5 files changed: 21 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24694.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694

PR: https://git.openjdk.org/jdk/pull/24694

From bpb at openjdk.org  Thu May  8 17:49:58 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 May 2025 17:49:58 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v2]
In-Reply-To: <_4819zr4DrfeUquda3NCpnW7HQi5WjtofWHZT2Eoh1M=.f90ef3e4-bb86-4886-8241-b5943d71ee18@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <_4819zr4DrfeUquda3NCpnW7HQi5WjtofWHZT2Eoh1M=.f90ef3e4-bb86-4886-8241-b5943d71ee18@github.com>
Message-ID: <56SUxew3Qq8TIh7Vb3O-IXpqpUo3vRSI6JYWuKHABqs=.43ac5e5c-d450-445e-b8f3-23d825481e9f@github.com>

On Thu, 8 May 2025 17:43:31 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail.
>> 
>> Fix this problem by appending a `.` to library paths after canonicalization on Windows. This trailing dot inhibits `LoadLibrary`'s own appending behavior.
>
> Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   new approach: append . to file name on Windows

src/java.base/windows/classes/jdk/internal/loader/ClassLoaderHelper.java line 110:

> 108:      * Add a dot to the end of the library file name ultimately passed to
> 109:      * <code>LoadLibrary</code>. This prevents <code>LoadLibrary</code> from
> 110:      * automatically infering a .DLL extension.

`infering` -> `inferring`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24694#discussion_r2080181799

From duke at openjdk.org  Thu May  8 17:49:59 2025
From: duke at openjdk.org (Petr Portnov | PROgrm_JARvis)
Date: Thu, 8 May 2025 17:49:59 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
Message-ID: <o_ZGOUToREyR8QkQz4xtNtq6-U9IWhynBN27rGfFQ0E=.bcc1b4ca-fc3a-4c62-ac97-76c8f3eea5b4@github.com>

On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge

src/java.base/share/classes/java/lang/ScopedValue.java line 613:

> 611:      */
> 612:     public T orElse(T other) {
> 613:         Objects.requireNonNull(other);

Shouldn't the NPE be specified in the Javadoc?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24923#discussion_r2080181692

From naoto at openjdk.org  Thu May  8 17:54:58 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 May 2025 17:54:58 GMT
Subject: RFR: 8356221: Clarify Console.charset() method description
In-Reply-To: <iL2w8qXT36llrzI9WY2OgiTgy8w00gfAb-Ejcl29PFU=.2a91b9dd-70a1-42bd-921d-54e3ca0ad746@github.com>
References: <iL2w8qXT36llrzI9WY2OgiTgy8w00gfAb-Ejcl29PFU=.2a91b9dd-70a1-42bd-921d-54e3ca0ad746@github.com>
Message-ID: <zp4ziGpDWlAdpCRnZYmAI4VvA0BRXX7vJOX-ZV3XUaE=.17b11de4-7614-4a88-8726-e2a88b5e0806@github.com>

On Wed, 7 May 2025 16:56:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple clarification of the `Console.charset()` method description, making explicit how the charset is applied.

Thanks for the review, Brian

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25103#issuecomment-2863826743

From naoto at openjdk.org  Thu May  8 17:54:58 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 May 2025 17:54:58 GMT
Subject: Integrated: 8356221: Clarify Console.charset() method description
In-Reply-To: <iL2w8qXT36llrzI9WY2OgiTgy8w00gfAb-Ejcl29PFU=.2a91b9dd-70a1-42bd-921d-54e3ca0ad746@github.com>
References: <iL2w8qXT36llrzI9WY2OgiTgy8w00gfAb-Ejcl29PFU=.2a91b9dd-70a1-42bd-921d-54e3ca0ad746@github.com>
Message-ID: <xu2rrNeF4RIz1yGyl9wfc3IS-tl323bPgs6dvcld5vs=.854d2d1d-c984-402f-aad3-959a05161001@github.com>

On Wed, 7 May 2025 16:56:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple clarification of the `Console.charset()` method description, making explicit how the charset is applied.

This pull request has now been integrated.

Changeset: e4ecda2b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e4ecda2b2563fbdff96d82fbbed6c022e28a49da
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8356221: Clarify Console.charset() method description

Reviewed-by: bpb

-------------

PR: https://git.openjdk.org/jdk/pull/25103

From duke at openjdk.org  Thu May  8 17:55:36 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Thu, 8 May 2025 17:55:36 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v3]
In-Reply-To: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
Message-ID: <BO3XKg8xPmBsT_cw8N0qZNVCfw2YhtDTtLB4JBT_Mzg=.853a33c5-7c69-4a48-a146-8e64c2bb14d7@github.com>

> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail.
> 
> Fix this problem by appending a `.` to library paths after canonicalization on Windows. This trailing dot inhibits `LoadLibrary`'s own appending behavior.

Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision:

  fix spelling

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24694/files
  - new: https://git.openjdk.org/jdk/pull/24694/files/f16626be..70e943c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24694.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694

PR: https://git.openjdk.org/jdk/pull/24694

From liach at openjdk.org  Thu May  8 18:05:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 18:05:55 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <o_ZGOUToREyR8QkQz4xtNtq6-U9IWhynBN27rGfFQ0E=.bcc1b4ca-fc3a-4c62-ac97-76c8f3eea5b4@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
 <o_ZGOUToREyR8QkQz4xtNtq6-U9IWhynBN27rGfFQ0E=.bcc1b4ca-fc3a-4c62-ac97-76c8f3eea5b4@github.com>
Message-ID: <WF_FZi87cHdpZxxfsw6ni_AmiEaTfb3O1bvisjSS6Mc=.349014ba-1ff0-450f-86f1-1c3286dd7073@github.com>

On Thu, 8 May 2025 17:47:12 GMT, Petr Portnov | PROgrm_JARvis <duke at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix merge
>
> src/java.base/share/classes/java/lang/ScopedValue.java line 613:
> 
>> 611:      */
>> 612:     public T orElse(T other) {
>> 613:         Objects.requireNonNull(other);
> 
> Shouldn't the NPE be specified in the Javadoc?

In the class specification, right above the API notes:

 * <p> Unless otherwise specified, passing a {@code null} argument to a method in this
 * class will cause a {@link NullPointerException} to be thrown.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24923#discussion_r2080203356

From jlu at openjdk.org  Thu May  8 18:07:42 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 8 May 2025 18:07:42 GMT
Subject: RFR: 8352755: Misconceptions about j.text.DecimalFormat digits
 during parsing [v3]
In-Reply-To: <DbSlspa3gs2Bi6EzhpNX6NpcgO3kSp3SkJS39jKJXmI=.41a4afcc-f083-4332-ba05-3a2f4e2dc795@github.com>
References: <DbSlspa3gs2Bi6EzhpNX6NpcgO3kSp3SkJS39jKJXmI=.41a4afcc-f083-4332-ba05-3a2f4e2dc795@github.com>
Message-ID: <3SUlt-xiFDfPWHDJwbvMeUfONvc4zm5gwUlgiQGM8xg=.ae8b7ae7-37b4-4d67-b633-bfbb3565fd22@github.com>

> Please review this PR which clarifies the behavior for integer and fraction limits in NumberFormat and implementing classes. An associated CSR is filed.
> 
> There have been a few bugs submitted which indicate a misconception that these limits impact parsing. The actual behavior is that these limits only affect formatting. The specification is vague regarding this, and can be explicitly updated to eliminate confusion. As the implementing classes are updated to use `inheritDoc`, some shuffling around in the method specs are included in this change as well.
> 
> Alternatively I considered making this change as implementation specific to DecimalFormat and CompactNumberFormat only. (i.e. leave flexibility for other NumberFormat subclasses to define their own behavior on whether the limits affect parsing.) I am open to this option as well, but initially decided against it as 
> 1) Unlike formatting, it seems like a rare use case that you would want to suppress the range of digits of accepted during parsing. `setParseIntegerOnly()` already provides functionality to toggle between integer and fraction parsing.
> 2) The limits affecting formatting only has been the long-standing behavior for all the subclasses of NumberFormat provided by the OpenJDK reference implementation.

Justin Lu has updated the pull request with a new target base 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:

 - CSR review - directed inheritDoc; make 'concrete subclass' wording normative
 - Merge branch 'master' into JDK-8352755-limit-clarifications
 - Merge branch 'master' into JDK-8352755-limit-clarifications
 - Naoto's review: apiN -> implN. Rewording of maxintdig callout
 - init

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24265/files
  - new: https://git.openjdk.org/jdk/pull/24265/files/5fc8f37f..183356b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24265&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24265&range=01-02

  Stats: 347915 lines in 3714 files changed: 120818 ins; 211994 del; 15103 mod
  Patch: https://git.openjdk.org/jdk/pull/24265.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24265/head:pull/24265

PR: https://git.openjdk.org/jdk/pull/24265

From liach at openjdk.org  Thu May  8 18:20:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 18:20:54 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
Message-ID: <nT6D0pn8ukOB8fEymeCgTQz93g_xIA7COYgQyVIHw7E=.fe01335c-3c95-40d8-9b8a-525287ec045f@github.com>

On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge

I noted that `ThreadFlock` is using scoped values but throwing `StructureViolationException` introduced by structured concurrency - is it considered an implementation artifact and part of structured concurrency instead?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2863891143

From liach at openjdk.org  Thu May  8 18:23:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 18:23:54 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
Message-ID: <1r-gaHy_VBrhT8yIqt2UIJ6g87BHJUJOWsSsxMOzTyA=.97592f84-858c-4a18-a19c-2a04885fdef3@github.com>

On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge

Reviewed the Javadoc and specification updates and `@enablePreview` removals for the end of preview. These are all related tests that can have the directive removed, aside from the thread flock test I asked about.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24923#pullrequestreview-2825991095

From rgiulietti at openjdk.org  Thu May  8 18:24:58 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 8 May 2025 18:24:58 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v54]
In-Reply-To: <ZCZXZ5pUI4k1kWhD0EfI3oV9W4vYfGX24JoSRSPHrFM=.f58d3c53-be2a-4898-9734-5a407f08a619@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <u50QX6oL3I2pglsUieiQRMKJ5Muy4e6IU4C14kwDQNU=.0bba7a91-4420-4205-80ec-8ce7d799b708@github.com>
 <ZCZXZ5pUI4k1kWhD0EfI3oV9W4vYfGX24JoSRSPHrFM=.f58d3c53-be2a-4898-9734-5a407f08a619@github.com>
Message-ID: <pLydB5WL0vudDNvzwByrqkKLhu87LME-KXshgE9h7dc=.deea89ea-9724-44b7-951b-e9ee85c0ba6e@github.com>

On Thu, 8 May 2025 15:48:30 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Suggested changes
>
> Please update the 2nd copyright year in `BigInteger`.
> 
> Otherwise looks good.
> As soon as you feel comfortable with your changes, let me know so that I can approve.
> 
> Thanks for yet another nice contribution!

> @rgiulietti Could be useful [this optimization](https://github.com/openjdk/jdk/pull/24690#issuecomment-2846711109) for `int` bases whose result does not fit in a `long`?

There are endless optimizations and fast paths that one could conceive, but at some point we must decide to stop and turn our attention to other aspects of the platform. I think we have reached the turning point for this great PR.

Besides, the performance gains of yet another fast-path might be negligible in general usage, at the cost of another 50 lines or so of code that would probably only benefit very narrow use cases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2863897562

From duke at openjdk.org  Thu May  8 18:33:57 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 8 May 2025 18:33:57 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v54]
In-Reply-To: <ZCZXZ5pUI4k1kWhD0EfI3oV9W4vYfGX24JoSRSPHrFM=.f58d3c53-be2a-4898-9734-5a407f08a619@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <u50QX6oL3I2pglsUieiQRMKJ5Muy4e6IU4C14kwDQNU=.0bba7a91-4420-4205-80ec-8ce7d799b708@github.com>
 <ZCZXZ5pUI4k1kWhD0EfI3oV9W4vYfGX24JoSRSPHrFM=.f58d3c53-be2a-4898-9734-5a407f08a619@github.com>
Message-ID: <O0oAGoevH547ZcD01SHkquGMkyn_5j09jIdtjdsLmUg=.e9602002-b780-4820-b664-5f6aa0285073@github.com>

On Thu, 8 May 2025 15:48:30 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Otherwise looks good. As soon as you feel comfortable with your changes, let me know so that I can approve.

@rgiulietti For me, now the code is ready.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2863923412

From rgiulietti at openjdk.org  Thu May  8 18:38:58 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 8 May 2025 18:38:58 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v55]
In-Reply-To: <7M-1pUEDXUNzktL20pvRvodXVXP4Lr88-TaNjt6TNmg=.b1a0c128-56c6-4fab-80e0-e2a5108daff5@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <7M-1pUEDXUNzktL20pvRvodXVXP4Lr88-TaNjt6TNmg=.b1a0c128-56c6-4fab-80e0-e2a5108daff5@github.com>
Message-ID: <w6dN3H9b4-z0B_tNaJ3drcisumUQQsR9VQvmtPgSzvY=.63ab13fd-e834-4a6c-88c7-9cd4b6da3caf@github.com>

On Thu, 8 May 2025 16:48:40 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code simplification

Good.

Let's give another 24 hours for people around the globe to chime in for last minute comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2863949199

From alanb at openjdk.org  Thu May  8 18:40:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 May 2025 18:40:55 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <nT6D0pn8ukOB8fEymeCgTQz93g_xIA7COYgQyVIHw7E=.fe01335c-3c95-40d8-9b8a-525287ec045f@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
 <nT6D0pn8ukOB8fEymeCgTQz93g_xIA7COYgQyVIHw7E=.fe01335c-3c95-40d8-9b8a-525287ec045f@github.com>
Message-ID: <oszVdhpU15ledtaju36JyfGNG4N43Q7q_bXvWIwiv64=.17a88f47-ef05-4d5a-9df7-459c09bec3a2@github.com>

On Thu, 8 May 2025 18:18:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> I noted that `ThreadFlock` is using scoped values but throwing `StructureViolationException` introduced by structured concurrency - is it considered an implementation artifact and part of structured concurrency instead?

ThreadFlock supports the inheritance of scoped values into structured concurrency contexts. No changes in this PR to that construct.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2863955030

From bpb at openjdk.org  Thu May  8 18:53:52 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 May 2025 18:53:52 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v3]
In-Reply-To: <BO3XKg8xPmBsT_cw8N0qZNVCfw2YhtDTtLB4JBT_Mzg=.853a33c5-7c69-4a48-a146-8e64c2bb14d7@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <BO3XKg8xPmBsT_cw8N0qZNVCfw2YhtDTtLB4JBT_Mzg=.853a33c5-7c69-4a48-a146-8e64c2bb14d7@github.com>
Message-ID: <6EUJaRSx-tXXQRqe1Eve3K4bXRqy05rtH4iK0drXH90=.135e0acb-c0a6-42ef-8d7b-9447ae31e03b@github.com>

On Thu, 8 May 2025 17:55:36 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail.
>> 
>> Fix this problem by appending a `.` to library paths after canonicalization on Windows. This trailing dot inhibits `LoadLibrary`'s own appending behavior.
>
> Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix spelling

I built the JDK with the diff in 70e943c applied on Windows 11 and verified that it resolves the scenario presented in the issue description, namely that `jimage.dll` can be moved elsewhere, in this case `C:\Users\bpb\rando`, and a link created from `jimage.dll` to `rando` and with this config `java` and `jshell` can be run.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2863982556

From vromero at openjdk.org  Thu May  8 18:57:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 8 May 2025 18:57:54 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
Message-ID: <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>

On Thu, 8 May 2025 13:33:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Merge branch 'master' into JDK-8354556
>  - addressing review comment
>  - changes to test
>  - Merge branch 'master' into JDK-8354556
>  - updating test
>  - final adjustments
>  - additional refactorings
>  - removing unneeded changes
>  - more refactorings
>  - more refactorings and tests
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/900b3ff7...5d834ce0

note to reviewers: I had an offline discussion with Dan, I will introduce some changes to the implementation

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2863994317

From alanb at openjdk.org  Thu May  8 19:00:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 May 2025 19:00:54 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v3]
In-Reply-To: <DSWIRvVOesuILrioviU6AKwaA1V_4olZcYcgkvWJG94=.576853bc-4c40-48fa-9568-58b1e6ed15d5@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <VkBzyrZMCwgRSotwkP2RdSV3x6B83eJgZF4mU830098=.b0d247e3-966a-441c-b7a1-974613eed3b3@github.com>
 <NQ32IYSUNxVd-tXxSsXcQws2oqloSMOOsFkLhZOZTHI=.79bb71a2-d132-4ebe-920f-2694761a7e06@github.com>
 <DSWIRvVOesuILrioviU6AKwaA1V_4olZcYcgkvWJG94=.576853bc-4c40-48fa-9568-58b1e6ed15d5@github.com>
Message-ID: <FuN5J7ypBsvyW2GXNpr_9mIZ59fQrYtbfNoVK1gXgKY=.c93ce9f9-87cc-4108-a0bf-09528dc80f3c@github.com>

On Thu, 8 May 2025 17:18:12 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> @theRealAph Can you include the update to javax/security/auth/Subject.java as part of this?
>
>> @theRealAph Can you include the update to javax/security/auth/Subject.java as part of this?
> 
> Fixed now.

@theRealAph One other test that will need attention is runtime/ClassFile/ClassFileVersionTest.java.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2864000920

From naoto at openjdk.org  Thu May  8 19:01:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 May 2025 19:01:55 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v6]
In-Reply-To: <tBEVMB0n8bNbzfjJy7jgJUxOa0Z-4OojY27IiXoxci8=.eec6f271-a45c-47f7-9f20-9ca219f1faea@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <tBEVMB0n8bNbzfjJy7jgJUxOa0Z-4OojY27IiXoxci8=.eec6f271-a45c-47f7-9f20-9ca219f1faea@github.com>
Message-ID: <rMGUrYJ9KLsppRGF6Doy6GWs2k3lFEYIIVItmBCaQRM=.04d51a5b-f41a-4919-9ad8-3e2bbd471e13@github.com>

On Thu, 8 May 2025 10:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into go-full-utf8
>  - Merge branch 'master' into go-full-utf8
>  - Add informative message  about supported locales.
>  - Allow C locale with warning instead of fatal error
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim
>  - Also tell javadoc that we have utf-8 now
>  - Fix flags for Windows
>  - Mark java and native source code as utf-8
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/2c1eb339...e68305db

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2826102855

From alanb at openjdk.org  Thu May  8 19:02:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 May 2025 19:02:53 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v3]
In-Reply-To: <BO3XKg8xPmBsT_cw8N0qZNVCfw2YhtDTtLB4JBT_Mzg=.853a33c5-7c69-4a48-a146-8e64c2bb14d7@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <BO3XKg8xPmBsT_cw8N0qZNVCfw2YhtDTtLB4JBT_Mzg=.853a33c5-7c69-4a48-a146-8e64c2bb14d7@github.com>
Message-ID: <NKxCgSN5nElChgTRYL9xg8oa7pVlyXmafNFhkG3nuw0=.370e9b03-9af0-479a-9006-f89143300ae3@github.com>

On Thu, 8 May 2025 17:55:36 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail.
>> 
>> Fix this problem by appending a `.` to library paths after canonicalization on Windows. This trailing dot inhibits `LoadLibrary`'s own appending behavior.
>
> Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix spelling

src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 124:

> 122:                     return null;
> 123:                 }
> 124:                 name = file.getCanonicalPath() + ClassLoaderHelper.nativeLoaderFileNameSuffix();

For this proposal then the appending needs to conditional.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24694#discussion_r2080306580

From duke at openjdk.org  Thu May  8 19:09:01 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Thu, 8 May 2025 19:09:01 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v3]
In-Reply-To: <NKxCgSN5nElChgTRYL9xg8oa7pVlyXmafNFhkG3nuw0=.370e9b03-9af0-479a-9006-f89143300ae3@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <BO3XKg8xPmBsT_cw8N0qZNVCfw2YhtDTtLB4JBT_Mzg=.853a33c5-7c69-4a48-a146-8e64c2bb14d7@github.com>
 <NKxCgSN5nElChgTRYL9xg8oa7pVlyXmafNFhkG3nuw0=.370e9b03-9af0-479a-9006-f89143300ae3@github.com>
Message-ID: <Mkg-QGSATre8fW8iLj5wk4Ywti6vaIZVNPGQXOr7nWw=.63450aad-474d-4dfc-b9ec-6461cebd6a22@github.com>

On Thu, 8 May 2025 19:00:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Benjamin Peterson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix spelling
>
> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 124:
> 
>> 122:                     return null;
>> 123:                 }
>> 124:                 name = file.getCanonicalPath() + ClassLoaderHelper.nativeLoaderFileNameSuffix();
> 
> For this proposal then the appending needs to conditional.

Conditional on what?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24694#discussion_r2080313366

From alanb at openjdk.org  Thu May  8 19:16:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 May 2025 19:16:53 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v3]
In-Reply-To: <Mkg-QGSATre8fW8iLj5wk4Ywti6vaIZVNPGQXOr7nWw=.63450aad-474d-4dfc-b9ec-6461cebd6a22@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <BO3XKg8xPmBsT_cw8N0qZNVCfw2YhtDTtLB4JBT_Mzg=.853a33c5-7c69-4a48-a146-8e64c2bb14d7@github.com>
 <NKxCgSN5nElChgTRYL9xg8oa7pVlyXmafNFhkG3nuw0=.370e9b03-9af0-479a-9006-f89143300ae3@github.com>
 <Mkg-QGSATre8fW8iLj5wk4Ywti6vaIZVNPGQXOr7nWw=.63450aad-474d-4dfc-b9ec-6461cebd6a22@github.com>
Message-ID: <iyXlIOMdtX9Tc4ku1ho8XOzdQJI_T4W4Qj-JQaO1hMc=.a2a4f4ea-b0ec-41db-90f6-2276439390f1@github.com>

On Thu, 8 May 2025 19:05:56 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 124:
>> 
>>> 122:                     return null;
>>> 123:                 }
>>> 124:                 name = file.getCanonicalPath() + ClassLoaderHelper.nativeLoaderFileNameSuffix();
>> 
>> For this proposal then the appending needs to conditional.
>
> Conditional on what?

The appending of the "." is specific to the case where there isn't a .dll suffix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24694#discussion_r2080323162

From alanb at openjdk.org  Thu May  8 19:19:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 May 2025 19:19:51 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock
In-Reply-To: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
Message-ID: <HiNe8vwwicMUDOTFQYSP4npH2W9K6fwPYCzR_tVQu0s=.fa3de89f-fc21-4ed4-bf7e-3d5ea3559dd2@github.com>

On Thu, 8 May 2025 13:46:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments).
> 
> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup).
> 
> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix.
> 
> Thanks,
> Patricio

test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 99:

> 97:         System.out.println("Waiting for thread1 and thread2 to deadlock ...");
> 98:         awaitBlocked(thread1, reached1);
> 99:         awaitBlocked(thread2, reached2);

This looks okay but does mean that awaitBlocked is doing two things, maybe it should be rename to awaitTrueAndBlocked. 

An alternative that would remove AtomicReference from the picture is to just have two volatile booleans and have the main thread poll both until true. That would leave the use of awaitBlock unchanged but what you have is okay too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25119#discussion_r2080327776

From duke at openjdk.org  Thu May  8 19:41:53 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Thu, 8 May 2025 19:41:53 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v3]
In-Reply-To: <iyXlIOMdtX9Tc4ku1ho8XOzdQJI_T4W4Qj-JQaO1hMc=.a2a4f4ea-b0ec-41db-90f6-2276439390f1@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <BO3XKg8xPmBsT_cw8N0qZNVCfw2YhtDTtLB4JBT_Mzg=.853a33c5-7c69-4a48-a146-8e64c2bb14d7@github.com>
 <NKxCgSN5nElChgTRYL9xg8oa7pVlyXmafNFhkG3nuw0=.370e9b03-9af0-479a-9006-f89143300ae3@github.com>
 <Mkg-QGSATre8fW8iLj5wk4Ywti6vaIZVNPGQXOr7nWw=.63450aad-474d-4dfc-b9ec-6461cebd6a22@github.com>
 <iyXlIOMdtX9Tc4ku1ho8XOzdQJI_T4W4Qj-JQaO1hMc=.a2a4f4ea-b0ec-41db-90f6-2276439390f1@github.com>
Message-ID: <Qix6nH8PKCQyILYVg6cJ9VwGwMQghcq6l7A-gS9QWCI=.37745fda-d30e-401d-9bd8-3ab81e6be67e@github.com>

On Thu, 8 May 2025 19:13:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Conditional on what?
>
> The appending of the "." is specific to the case where there isn't a .dll suffix.

`LoadLibrary` appears to happily load files with a `.dll` extension even if a trailing `.` is appended. So, special casing doesn't appear necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24694#discussion_r2080359521

From pchilanomate at openjdk.org  Thu May  8 19:52:17 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 8 May 2025 19:52:17 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
Message-ID: <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>

> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments).
> 
> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup).
> 
> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Rename awaitBlocked to awaitTrueAndBlocked

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25119/files
  - new: https://git.openjdk.org/jdk/pull/25119/files/7c067865..c36728d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25119&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25119&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25119.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25119/head:pull/25119

PR: https://git.openjdk.org/jdk/pull/25119

From pchilanomate at openjdk.org  Thu May  8 19:52:17 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 8 May 2025 19:52:17 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <HiNe8vwwicMUDOTFQYSP4npH2W9K6fwPYCzR_tVQu0s=.fa3de89f-fc21-4ed4-bf7e-3d5ea3559dd2@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
 <HiNe8vwwicMUDOTFQYSP4npH2W9K6fwPYCzR_tVQu0s=.fa3de89f-fc21-4ed4-bf7e-3d5ea3559dd2@github.com>
Message-ID: <7Niz4vvjmS0vFVNtKbj5Wkur6sXeLSndE_7MU4QIpDE=.61dbd1d9-67e3-43d7-8908-1d7f3d378d35@github.com>

On Thu, 8 May 2025 19:17:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename awaitBlocked to awaitTrueAndBlocked
>
> test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 99:
> 
>> 97:         System.out.println("Waiting for thread1 and thread2 to deadlock ...");
>> 98:         awaitBlocked(thread1, reached1);
>> 99:         awaitBlocked(thread2, reached2);
> 
> This looks okay but does mean that awaitBlocked is doing two things, maybe it should be rename to awaitTrueAndBlocked. 
> 
> An alternative that would remove AtomicReference from the picture is to just have two volatile booleans and have the main thread poll both until true. That would leave the use of awaitBlock unchanged but what you have is okay too.

Yes, I actually had that in an initial version. Then I thought it was cleaner to just have all waiting logic in awaitBlocked so I changed it. I renamed `awaitBlocked` to `awaitTrueAndBlocked` for now. But let me know if you prefer the two volatile booleans instead.

Also, we could remove the `CyclicBarrier` and have each thread poll the other?s thread flag now, but given this bug was found due to the barrier I left it as is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25119#discussion_r2080371142

From liach at openjdk.org  Thu May  8 19:53:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 19:53:53 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
Message-ID: <p1-YD8qt9XC1iQmDHogYaEYqIepOV20IJ5Zhgipoq38=.6829d786-6557-49ad-94a1-b0f22290bac8@github.com>

On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge

May I provide a quick patch to use an alternative mechanism to test preview class file versions for that class instead of changing that in this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2864114798

From prr at openjdk.org  Thu May  8 20:02:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 8 May 2025 20:02:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

test/jdk/java/awt/font/NumericShaper/MTTest.java

- * @run main/timeout=300/othervm MTTest
+ * @run main/timeout=1200/othervm MTTest

I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.

https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java

So 300 was fine, and 1200 isn't needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864133534

From kevinw at openjdk.org  Thu May  8 20:10:53 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 8 May 2025 20:10:53 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
 <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
Message-ID: <LqGdRNr_zUBsyuA5yy44ly_sSynJ0j9M6umfjfnCeME=.8857875d-ceb0-4e00-b284-d997065246aa@github.com>

On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments).
>> 
>> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup).
>> 
>> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename awaitBlocked to awaitTrueAndBlocked

Hi, looks good!

(The flag is easier than trying to look at the name of the thing they are blocked on.)

-------------

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25119#pullrequestreview-2826251302

From naoto at openjdk.org  Thu May  8 21:06:31 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 May 2025 21:06:31 GMT
Subject: RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata
 downgrades after JDK-8342550
Message-ID: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>

Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case.
Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/25130/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25130&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356450
  Stats: 10 lines in 1 file changed: 7 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25130/head:pull/25130

PR: https://git.openjdk.org/jdk/pull/25130

From darcy at openjdk.org  Thu May  8 21:11:00 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 8 May 2025 21:11:00 GMT
Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal
Message-ID: <sW8AgNknCFUnkZKAns3Pvm-jbPS2XomYipktJhJNxIs=.1f4cddb5-675c-4be9-a7f2-953511f0abdf@github.com>

Fix javadoc tags.

-------------

Commit messages:
 - JDK-8356555: Incorrect use of {@link} in BigDecimal

Changes: https://git.openjdk.org/jdk/pull/25131/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25131&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356555
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25131/head:pull/25131

PR: https://git.openjdk.org/jdk/pull/25131

From asemenyuk at openjdk.org  Thu May  8 21:17:37 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 8 May 2025 21:17:37 GMT
Subject: RFR: 8333568: Test that jpackage doesn't modify R/O
 files/directories
In-Reply-To: <6oJYYaBMXvLOynz9QGSJRsoYapsAw5Gm0HxkEYagp5w=.ebe9abb7-8359-4c15-8818-65e3c51dfc8c@github.com>
References: <6oJYYaBMXvLOynz9QGSJRsoYapsAw5Gm0HxkEYagp5w=.ebe9abb7-8359-4c15-8818-65e3c51dfc8c@github.com>
Message-ID: <Jssn4MYlJeuxTKOMTAwV0OK-8UDxeKNfxQbiNlAIhvI=.73450025-10d5-471a-93c3-618e8a3e7253@github.com>

On Thu, 8 May 2025 20:19:43 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add a check that jpackage doesn't modify files/directories supplied with "--app-image", "--resource-dir", "--runtime-image", "--app-content", and "--mac-dmg-content" options to every jpackage test.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25129#issuecomment-2864322876

From asemenyuk at openjdk.org  Thu May  8 21:17:37 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 8 May 2025 21:17:37 GMT
Subject: RFR: 8333568: Test that jpackage doesn't modify R/O files/directories
Message-ID: <6oJYYaBMXvLOynz9QGSJRsoYapsAw5Gm0HxkEYagp5w=.ebe9abb7-8359-4c15-8818-65e3c51dfc8c@github.com>

Add a check that jpackage doesn't modify files/directories supplied with "--app-image", "--resource-dir", "--runtime-image", "--app-content", and "--mac-dmg-content" options to every jpackage test.

-------------

Commit messages:
 - Verify jpackage doesn't modify external directories passed to jpackage

Changes: https://git.openjdk.org/jdk/pull/25129/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25129&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333568
  Stats: 190 lines in 2 files changed: 185 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25129/head:pull/25129

PR: https://git.openjdk.org/jdk/pull/25129

From vlivanov at openjdk.org  Thu May  8 21:22:52 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 8 May 2025 21:22:52 GMT
Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner
 classes [v2]
In-Reply-To: <Xx7OLj80AjJ_Ay-yUz-Lgd9DRLg2QWyEn97WSrnvnxg=.c639e8e9-ba3c-4844-a0e2-d8bbcec728c1@github.com>
References: <JQCL1DGBobBWQqWeX3Ykuw1nZOis5D8k6kEllWluE0s=.a089b081-da05-436c-b0f7-ec021887ea57@github.com>
 <Xx7OLj80AjJ_Ay-yUz-Lgd9DRLg2QWyEn97WSrnvnxg=.c639e8e9-ba3c-4844-a0e2-d8bbcec728c1@github.com>
Message-ID: <0oWJ3zW0ykhbon1An-cbaib2XDdv-qBJS23f0CZkxcg=.faf3d22c-c6a1-4dd3-802c-40fde0a07846@github.com>

On Mon, 5 May 2025 23:50:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is a general fix for all the "points to a static field that may hold a different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330).
>> 
>> AOT-cached method handles quite often refer to the static fields in `MethodHandleImpl` or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. `CDSHeapVerifier` makes a very conservative check for such static fields, but sometimes gives false positives (as in the above two JBS issues)
>> 
>> In this PR, we AOT-initialize `MethodHandleImpl` and its inner classes. This is a more authentic snapshot of the state of `java.lang.invoke` during the assembly phase. We also avoid the need to add and maintain entries in the `cdsHeapVerifier.cpp` table.
>> 
>> I also added more code in `MethodHandleTest.java` to simulate potential usage patterns of `MethodHandle` by the Java core libraries. Hopefully this will reduce the likelihood for innocent core lib changes breaking the AOT assembly phase.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments from @liach and @ExE-Boss

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24956#pullrequestreview-2826395240

From iris at openjdk.org  Thu May  8 21:23:52 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 8 May 2025 21:23:52 GMT
Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal
In-Reply-To: <sW8AgNknCFUnkZKAns3Pvm-jbPS2XomYipktJhJNxIs=.1f4cddb5-675c-4be9-a7f2-953511f0abdf@github.com>
References: <sW8AgNknCFUnkZKAns3Pvm-jbPS2XomYipktJhJNxIs=.1f4cddb5-675c-4be9-a7f2-953511f0abdf@github.com>
Message-ID: <2k9DA41pta5T-PEwj8lw5bl7Ux7OvIJ-6KUyCQ8k6TE=.3a042137-e6a1-4a6b-846b-ac65a3cf11ab@github.com>

On Thu, 8 May 2025 21:07:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix javadoc tags.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25131#pullrequestreview-2826397554

From bpb at openjdk.org  Thu May  8 21:29:51 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 May 2025 21:29:51 GMT
Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal
In-Reply-To: <sW8AgNknCFUnkZKAns3Pvm-jbPS2XomYipktJhJNxIs=.1f4cddb5-675c-4be9-a7f2-953511f0abdf@github.com>
References: <sW8AgNknCFUnkZKAns3Pvm-jbPS2XomYipktJhJNxIs=.1f4cddb5-675c-4be9-a7f2-953511f0abdf@github.com>
Message-ID: <rLxfsjqmhhWSZdnuNKZvb5zHTWKrdfxp-Wk2oN9akb8=.46871dc9-f789-4ea0-902c-9c2a2ab452c6@github.com>

On Thu, 8 May 2025 21:07:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix javadoc tags.

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25131#pullrequestreview-2826409763

From jlu at openjdk.org  Thu May  8 21:37:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 8 May 2025 21:37:53 GMT
Subject: RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata
 downgrades after JDK-8342550
In-Reply-To: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
References: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
Message-ID: <p8DYgRQBThPIpFQdeGzymfSZ05V-glMuIXr7y1ZMmL4=.8488cf34-66fd-4c11-91b8-cda124a875a5@github.com>

On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case.
> Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater.

lgtm

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25130#pullrequestreview-2826420607

From bpb at openjdk.org  Thu May  8 21:37:52 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 May 2025 21:37:52 GMT
Subject: RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata
 downgrades after JDK-8342550
In-Reply-To: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
References: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
Message-ID: <A5JbV9XQNz8ZylGtTgFgEjbPUZu9xEkE_KPrW5ntNUw=.79fbbbbe-816a-4223-a1c0-ee224dffb2ae@github.com>

On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case.
> Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater.

Looks all right to me.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25130#pullrequestreview-2826417729

From jwaters at openjdk.org  Thu May  8 21:43:02 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 8 May 2025 21:43:02 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v7]
In-Reply-To: <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
Message-ID: <3JOhI_-acxlyIreUPgbY5reRbuy4o0Rdh99q9JDgkfw=.0d792d1c-b156-46e2-aa80-3c07d3c183fe@github.com>

On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters <jwaters at openjdk.org> 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-2864379663

From dholmes at openjdk.org  Thu May  8 22:01:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 May 2025 22:01:51 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
 <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
Message-ID: <mYU92_TN5g64lnUsbJhXf6GJ6QWcHSgWjzCGZZWGAmE=.e286e075-904e-4e6f-bf73-b67bb3c0ee89@github.com>

On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments).
>> 
>> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup).
>> 
>> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename awaitBlocked to awaitTrueAndBlocked

> we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). 

No, because that is an internal implementation detail.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25119#issuecomment-2864508184

From joehw at openjdk.org  Thu May  8 22:05:52 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 8 May 2025 22:05:52 GMT
Subject: RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata
 downgrades after JDK-8342550
In-Reply-To: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
References: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
Message-ID: <lYCR6beOJcANFu0iuIK2_VIDQxSXxVokXvldsRbpzhU=.b9816bb4-8a31-4a68-8d55-3cc3c7445f62@github.com>

On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case.
> Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater.

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25130#pullrequestreview-2826461648

From almatvee at openjdk.org  Thu May  8 22:08:52 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 8 May 2025 22:08:52 GMT
Subject: RFR: 8356562: SigningAppImageTwoStepsTest test fails
In-Reply-To: <ff7TI1O2z-0h7B3OE84g2vUWJOCFYdHz1xBepLHMack=.2152c970-44ee-4a2c-9857-922dd1214e25@github.com>
References: <ff7TI1O2z-0h7B3OE84g2vUWJOCFYdHz1xBepLHMack=.2152c970-44ee-4a2c-9857-922dd1214e25@github.com>
Message-ID: <hsn8Mm-onjH_g0rJ1uGXbSuKK61O1_lyZQ7nVC8mlU0=.cb2b62c6-8823-4102-9cca-24fec1b76150@github.com>

On Thu, 8 May 2025 17:23:48 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix JPackageCommand.assertAppImageFile() method to make it pass the relative path to ".jpackag.xml" file to JPackageCommand.assertFileInAppImage().

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25126#pullrequestreview-2826464922

From dholmes at openjdk.org  Thu May  8 22:09:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 May 2025 22:09:51 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
 <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
Message-ID: <eK7I7glqgviACe1Wo_e-k_Z05hPYj1sAvsCBBYpN3MI=.946b59b4-c9aa-4d02-8993-9b948b679946@github.com>

On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments).
>> 
>> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup).
>> 
>> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename awaitBlocked to awaitTrueAndBlocked

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25119#pullrequestreview-2826465546

From jwaters at openjdk.org  Thu May  8 22:14:58 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 8 May 2025 22:14:58 GMT
Subject: RFR: 8355573: Remove kludge_c++11.h from jpackage code
In-Reply-To: <ABRXOAFnthURb4yuEcE4Ex-2Vz28YrnyXp6a3iFX0os=.96006b49-051d-4eda-9c29-7e3b34f0e3cb@github.com>
References: <ABRXOAFnthURb4yuEcE4Ex-2Vz28YrnyXp6a3iFX0os=.96006b49-051d-4eda-9c29-7e3b34f0e3cb@github.com>
Message-ID: <QMq55HeW7471N2gl-rphumkkOLU617-hBfDL0F_5SfU=.2066029a-59ad-4d27-8d5c-0b20f90deab4@github.com>

On Fri, 25 Apr 2025 06:14:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> kludge_c++11.h was introduced to work around older C++ versions not having access to C++ utilities like std::unique_ptr. Since we are already on C++14 (And hopefully will get C++17 soon) this workaround can be removed from jpackage code.

Thanks both for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24868#issuecomment-2864546595

From jwaters at openjdk.org  Thu May  8 22:14:58 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 8 May 2025 22:14:58 GMT
Subject: Integrated: 8355573: Remove kludge_c++11.h from jpackage code
In-Reply-To: <ABRXOAFnthURb4yuEcE4Ex-2Vz28YrnyXp6a3iFX0os=.96006b49-051d-4eda-9c29-7e3b34f0e3cb@github.com>
References: <ABRXOAFnthURb4yuEcE4Ex-2Vz28YrnyXp6a3iFX0os=.96006b49-051d-4eda-9c29-7e3b34f0e3cb@github.com>
Message-ID: <4OHM8zzh2z1YR5YKktFQkwMt2EsMmXLBDvmhPmsZ7So=.984c015e-430a-476b-9a4e-731645e9a902@github.com>

On Fri, 25 Apr 2025 06:14:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> kludge_c++11.h was introduced to work around older C++ versions not having access to C++ utilities like std::unique_ptr. Since we are already on C++14 (And hopefully will get C++17 soon) this workaround can be removed from jpackage code.

This pull request has now been integrated.

Changeset: c2a4fa1d
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c2a4fa1d83bd690e4e453eb1dbe59c6503b5281d
Stats:     183 lines in 8 files changed: 1 ins; 182 del; 0 mod

8355573: Remove kludge_c++11.h from jpackage code

Reviewed-by: asemenyuk, almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/24868

From asemenyuk at openjdk.org  Thu May  8 22:21:57 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 8 May 2025 22:21:57 GMT
Subject: Integrated: 8356562: SigningAppImageTwoStepsTest test fails
In-Reply-To: <ff7TI1O2z-0h7B3OE84g2vUWJOCFYdHz1xBepLHMack=.2152c970-44ee-4a2c-9857-922dd1214e25@github.com>
References: <ff7TI1O2z-0h7B3OE84g2vUWJOCFYdHz1xBepLHMack=.2152c970-44ee-4a2c-9857-922dd1214e25@github.com>
Message-ID: <lLtBeJmLo_pOhcupiZ1Ll1OfWam_aCbg2GBbFujIUCY=.d9deed8d-b2bd-484b-b75c-94abe1b23ece@github.com>

On Thu, 8 May 2025 17:23:48 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix JPackageCommand.assertAppImageFile() method to make it pass the relative path to ".jpackag.xml" file to JPackageCommand.assertFileInAppImage().

This pull request has now been integrated.

Changeset: 8a8893ec
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a8893ec030b19583efd65bd0751e66254689ead
Stats:     13 lines in 1 file changed: 6 ins; 4 del; 3 mod

8356562: SigningAppImageTwoStepsTest test fails

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/25126

From almatvee at openjdk.org  Thu May  8 22:39:50 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 8 May 2025 22:39:50 GMT
Subject: RFR: 8333568: Test that jpackage doesn't modify R/O
 files/directories
In-Reply-To: <6oJYYaBMXvLOynz9QGSJRsoYapsAw5Gm0HxkEYagp5w=.ebe9abb7-8359-4c15-8818-65e3c51dfc8c@github.com>
References: <6oJYYaBMXvLOynz9QGSJRsoYapsAw5Gm0HxkEYagp5w=.ebe9abb7-8359-4c15-8818-65e3c51dfc8c@github.com>
Message-ID: <3fl9BqEDeRLc6T4fEfI1mV2gG2GbN5nNls975AQpx4Y=.2567c1bc-0850-4848-abd3-cb630e2320ef@github.com>

On Thu, 8 May 2025 20:19:43 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add a check that jpackage doesn't modify files/directories supplied with "--app-image", "--resource-dir", "--runtime-image", "--app-content", and "--mac-dmg-content" options to every jpackage test.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25129#pullrequestreview-2826499148

From jlu at openjdk.org  Thu May  8 23:00:26 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 8 May 2025 23:00:26 GMT
Subject: RFR: 8348351: Improve lazy initialization of the available currencies
 set
Message-ID: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>

Please review this PR which stems from discussion in the PR of JDK-8347949.

The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier.

(This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.)

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/25134/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25134&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348351
  Stats: 46 lines in 1 file changed: 3 ins; 2 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/25134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25134/head:pull/25134

PR: https://git.openjdk.org/jdk/pull/25134

From liach at openjdk.org  Thu May  8 23:10:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 23:10:52 GMT
Subject: RFR: 8348351: Improve lazy initialization of the available
 currencies set
In-Reply-To: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
References: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
Message-ID: <rMhgAOuhaVz9_97MeJIdg8pPrLZm_g8oO8GGkjc15i4=.d3ab9d25-cb31-4c9d-a334-3dbd93684b72@github.com>

On Thu, 8 May 2025 22:55:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which stems from discussion in the PR of JDK-8347949.
> 
> The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier.
> 
> (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.)

src/java.base/share/classes/java/util/Currency.java line 471:

> 469: 
> 470:     // Builds and returns the set of available Currencies
> 471:     private static HashSet<Currency> getCurrencies() {

I think we should rename this to `computeCurrencies` or `makeCurrencies` to indicate we are creating a new instance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25134#discussion_r2080606583

From lmesnik at openjdk.org  Thu May  8 23:12:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 8 May 2025 23:12:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
 <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>
Message-ID: <inHeApQE1qTo35yQi6vzs6LYuATsr8NxmEMOU_1x_5c=.6ea734d1-63f2-47dc-a245-23d3233c76e4@github.com>

On Thu, 8 May 2025 17:03:03 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> doc/testing.md line 385:
>> 
>>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>>> 384: certain amount of time will apply this factor. If we run in
>>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
>> 
>> Maybe
>> Suggestion:
>> 
>> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)
>
> Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

yep, let use Xcomp, the Xint is not really supported, a lot of tests might start failing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080606853

From jlu at openjdk.org  Thu May  8 23:30:06 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 8 May 2025 23:30:06 GMT
Subject: RFR: 8348351: Improve lazy initialization of the available
 currencies set [v2]
In-Reply-To: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
References: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
Message-ID: <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com>

> Please review this PR which stems from discussion in the PR of JDK-8347949.
> 
> The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier.
> 
> (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.)

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Chen's review - method name clarification

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25134/files
  - new: https://git.openjdk.org/jdk/pull/25134/files/f9e9c6b2..e2672ba1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25134&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25134&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25134/head:pull/25134

PR: https://git.openjdk.org/jdk/pull/25134

From liach at openjdk.org  Thu May  8 23:30:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 23:30:06 GMT
Subject: RFR: 8348351: Improve lazy initialization of the available
 currencies set [v2]
In-Reply-To: <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com>
References: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
 <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com>
Message-ID: <8fE6Y01KMk7bPnaE1KLFGMagSIZYdykjOMQdWsdk-X8=.8f190772-2f47-4a72-95eb-177c111d0799@github.com>

On Thu, 8 May 2025 23:26:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which stems from discussion in the PR of JDK-8347949.
>> 
>> The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier.
>> 
>> (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen's review - method name clarification

Looks great to me. Thanks!

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25134#pullrequestreview-2826594504

From jlu at openjdk.org  Thu May  8 23:30:06 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 8 May 2025 23:30:06 GMT
Subject: RFR: 8348351: Improve lazy initialization of the available
 currencies set [v2]
In-Reply-To: <rMhgAOuhaVz9_97MeJIdg8pPrLZm_g8oO8GGkjc15i4=.d3ab9d25-cb31-4c9d-a334-3dbd93684b72@github.com>
References: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
 <rMhgAOuhaVz9_97MeJIdg8pPrLZm_g8oO8GGkjc15i4=.d3ab9d25-cb31-4c9d-a334-3dbd93684b72@github.com>
Message-ID: <Zxc-E85yFzY2rKYx1bN_3CIffj6V3dmRo36Ij_ksbRE=.f124276b-9574-4a7a-b061-9f34de998d62@github.com>

On Thu, 8 May 2025 23:08:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Chen's review - method name clarification
>
> src/java.base/share/classes/java/util/Currency.java line 471:
> 
>> 469: 
>> 470:     // Builds and returns the set of available Currencies
>> 471:     private static HashSet<Currency> getCurrencies() {
> 
> I think we should rename this to `computeCurrencies` or `makeCurrencies` to indicate we are creating a new instance.

Definitely; updated in https://github.com/openjdk/jdk/pull/25134/commits/e2672ba1846c17b723d6bcbee0ef20488c0dca24.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25134#discussion_r2080621783

From naoto at openjdk.org  Thu May  8 23:38:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 May 2025 23:38:50 GMT
Subject: RFR: 8348351: Improve lazy initialization of the available
 currencies set [v2]
In-Reply-To: <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com>
References: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
 <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com>
Message-ID: <3Lj7qiOyPZvgDYuu8-O2INL8jaNVuTzRDbKxf3lhqeg=.71db798a-2fee-45c1-9ca2-639061127015@github.com>

On Thu, 8 May 2025 23:30:06 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which stems from discussion in the PR of JDK-8347949.
>> 
>> The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier.
>> 
>> (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen's review - method name clarification

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25134#pullrequestreview-2826610413

From nbenalla at openjdk.org  Fri May  9 00:08:51 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 9 May 2025 00:08:51 GMT
Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal
In-Reply-To: <sW8AgNknCFUnkZKAns3Pvm-jbPS2XomYipktJhJNxIs=.1f4cddb5-675c-4be9-a7f2-953511f0abdf@github.com>
References: <sW8AgNknCFUnkZKAns3Pvm-jbPS2XomYipktJhJNxIs=.1f4cddb5-675c-4be9-a7f2-953511f0abdf@github.com>
Message-ID: <UbQB_1BdfecWf_TTcgvHceW_wtOT5s6B8uiU2RJ7tUY=.0ad0140c-eff7-498e-ad7f-422a43af32b7@github.com>

On Thu, 8 May 2025 21:07:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix javadoc tags.

I think this looks good.

-------------

Marked as reviewed by nbenalla (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25131#pullrequestreview-2826639744

From asemenyuk at openjdk.org  Fri May  9 00:08:56 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 9 May 2025 00:08:56 GMT
Subject: Integrated: 8333568: Test that jpackage doesn't modify R/O
 files/directories
In-Reply-To: <6oJYYaBMXvLOynz9QGSJRsoYapsAw5Gm0HxkEYagp5w=.ebe9abb7-8359-4c15-8818-65e3c51dfc8c@github.com>
References: <6oJYYaBMXvLOynz9QGSJRsoYapsAw5Gm0HxkEYagp5w=.ebe9abb7-8359-4c15-8818-65e3c51dfc8c@github.com>
Message-ID: <n4e3bUdEaYEqntqYsEv6bEiARx9En7bINCm_opMduYY=.894a02ee-19e8-4e71-98d5-99339c1d9361@github.com>

On Thu, 8 May 2025 20:19:43 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add a check that jpackage doesn't modify files/directories supplied with "--app-image", "--resource-dir", "--runtime-image", "--app-content", and "--mac-dmg-content" options to every jpackage test.

This pull request has now been integrated.

Changeset: cc3a366e
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc3a366e2a616226b776f683dbfb7cddaf2270d3
Stats:     190 lines in 2 files changed: 185 ins; 1 del; 4 mod

8333568: Test that jpackage doesn't modify R/O files/directories

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/25129

From almatvee at openjdk.org  Fri May  9 00:13:51 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 9 May 2025 00:13:51 GMT
Subject: RFR: 8352480: Don't follow symlinks in additional content for app
 images [v3]
In-Reply-To: <zP6X7Ijb_HVeCFpGxmSpnObvH9WInHbhnSV6IaSIHsA=.bd16b9db-0c64-4086-852e-87394164fbfa@github.com>
References: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
 <nBloeGMFbz5uS_37AONMV0ApSWAtYHzgu-DQyqt0Oyo=.20e9ee1f-81ba-422e-93cf-a38ae4ec4318@github.com>
 <zP6X7Ijb_HVeCFpGxmSpnObvH9WInHbhnSV6IaSIHsA=.bd16b9db-0c64-4086-852e-87394164fbfa@github.com>
Message-ID: <LX4Q9p1HuZ1qoYzxo2cXY18oPVwFndIGqq10aQ1z5Ow=.a99d8c4d-8e7a-4189-90e9-77763c1b6075@github.com>

On Wed, 7 May 2025 12:26:54 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8352480: [macos] Don't follow symlinks in additional content for app images [v5]
>
> test/jdk/tools/jpackage/share/AppContentTest.java line 116:
> 
>> 114:     private static Path getAppContentPath(JPackageCommand cmd, Path name) {
>> 115:         Path contentDir = cmd.appLayout().contentDirectory();
>> 116:         // Links are always created in "Resources"
> 
>> Links are always created in "Resources"
> 
> All additional content on macOS is created in the "Resources" directory. On Linux there is no such requirement.
> 
> The return value of `getAppContentPath()` is not supposed to depend on the additional content type; the new "name" parameter doesn't make sense to me.

For links we creating link and corresponding text file, so for it we should put both files into folder and add it to `--app-content app-content-0/Resources`. Note `app-content-0` is temp folder with random name and if we using it directly we end up copying `app-content-0` into application bundle. In such case it will not be possible to figure out location of link without putting it under known folder name such as "Resources".

"name" is to figure out if it link and if link it should be under "Resources".

> test/jdk/tools/jpackage/share/AppContentTest.java line 147:
> 
>> 145: 
>> 146:         private static Path copyAppContentPath(Path appContentPath) throws IOException {
>> 147:             Path appContentArg = TKit.createTempDirectory("app-content").resolve("Resources");
> 
> This is a redundant change

Fixed.

> test/jdk/tools/jpackage/share/AppContentTest.java line 149:
> 
>> 147:             Path appContentArg = TKit.createTempDirectory("app-content").resolve("Resources");
>> 148:             var srcPath = TKit.TEST_SRC_ROOT.resolve(appContentPath);
>> 149:             Path dstPath = appContentArg.resolve(srcPath.getFileName());
> 
> This is a redundant change

Fixed.

> test/jdk/tools/jpackage/share/AppContentTest.java line 164:
> 
>> 162:         private static List<Path> initAppContentPaths(List<Path> appContentPaths) {
>> 163:             boolean copy = (copyInResources || appContentPaths.stream()
>> 164:                             .anyMatch(s -> s.toString().contains("Link")));
> 
> `s.toString().contains("Link")` is a lousy way to detect if the path is a symlink. "s" can be an absolute path (to the local OpenJDK repo) that may have a "Link" substring in one of path components, like "/home/BLink/my-projects/open/test/jdk/tools/jpackage/non-existant". The test will fail, and we will have a very hard time figuring out the cause. I'd fix it by narrowing the scope from the full path to the filename; create a dedicated function for detecting if the given path is supposed to be a symlink instead of repeating `.toString().contains("Link")`:
> 
> private static boolean isSymlinkPath(Path v) {
>     return v.getFileName().toString().contains("Link");
> }

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2080659287
PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2080659397
PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2080659613
PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2080659694

From rriggs at openjdk.org  Fri May  9 00:20:19 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 May 2025 00:20:19 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v7]
In-Reply-To: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
Message-ID: <wZnHF7lgvJkhjxpQNCsdCjcluNzGXj6k50zhrp9-K48=.10e0c396-c89e-4f65-9371-e3ec0b15fcd1@github.com>

> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
> Support methods are static, designed to pass all values as arguments and return a value.
> 
> The value byte array is reallocated under 3 conditions:
> - Increasing the capacity with the same encoder
> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
> - Inflation with the same capacity
> 
> Added StressSBTest to exercise public instance methods of StringBuilder.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Add an assert to inflateToUTF16 method
  Add doc of preconditions to appendChars... methods
  Correct misc javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24967/files
  - new: https://git.openjdk.org/jdk/pull/24967/files/efd6fed1..1404fa9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=05-06

  Stats: 15 lines in 1 file changed: 7 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24967.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24967/head:pull/24967

PR: https://git.openjdk.org/jdk/pull/24967

From lmesnik at openjdk.org  Fri May  9 00:55:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 9 May 2025 00:55:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
Message-ID: <2oUdV1ca6y_cEHL3kTptk3jAlwCwnvsLGhRIAhVEUo8=.010c2226-c5ec-4508-be7f-90d244b2b7dc@github.com>

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Can you please proposed fix for https://bugs.openjdk.org/browse/JDK-8260555 to make it more clear the complete goal of the fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864795990

From almatvee at openjdk.org  Fri May  9 01:39:07 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 9 May 2025 01:39:07 GMT
Subject: RFR: 8352480: Don't follow symlinks in additional content for app
 images [v4]
In-Reply-To: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
References: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
Message-ID: <BkMd6YH8WQG1vooguwyXEluf-HivXjYDC4wSRiMAkH4=.4216db96-278d-44b5-b7f6-22a98815546b@github.com>

> - Symbolic links will not be followed for `--app-content` on all platforms.
> - Added test to cover this case.
> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8352480: [macos] Don't follow symlinks in additional content for app images [v6]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24974/files
  - new: https://git.openjdk.org/jdk/pull/24974/files/166c3ffa..5c8dc6d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24974&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24974&range=02-03

  Stats: 56 lines in 1 file changed: 23 ins; 2 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/24974.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24974/head:pull/24974

PR: https://git.openjdk.org/jdk/pull/24974

From almatvee at openjdk.org  Fri May  9 01:40:50 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 9 May 2025 01:40:50 GMT
Subject: RFR: 8352480: Don't follow symlinks in additional content for app
 images [v3]
In-Reply-To: <nBloeGMFbz5uS_37AONMV0ApSWAtYHzgu-DQyqt0Oyo=.20e9ee1f-81ba-422e-93cf-a38ae4ec4318@github.com>
References: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
 <nBloeGMFbz5uS_37AONMV0ApSWAtYHzgu-DQyqt0Oyo=.20e9ee1f-81ba-422e-93cf-a38ae4ec4318@github.com>
Message-ID: <voC-2EUhu1BMpUVvVqrT2ImEbRIGW-DyzrRmml3QRis=.38a9dab9-ad71-439f-950c-c6f2cedd56f6@github.com>

On Wed, 7 May 2025 02:07:03 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Symbolic links will not be followed for `--app-content` on all platforms.
>> - Added test to cover this case.
>> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8352480: [macos] Don't follow symlinks in additional content for app images [v5]

8352480: [macos] Don't follow symlinks in additional content for app images [v6]
-  Fixed latest comments.
- Link will be created under "Links" folder to avoid confusion with reusing "Resources"
- Link creation moved under separate function `createAppContentLink` from `copyAppContentPath` to avoid confusion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24974#issuecomment-2864851703

From asemenyuk at openjdk.org  Fri May  9 01:56:52 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 9 May 2025 01:56:52 GMT
Subject: RFR: 8352480: Don't follow symlinks in additional content for app
 images [v4]
In-Reply-To: <BkMd6YH8WQG1vooguwyXEluf-HivXjYDC4wSRiMAkH4=.4216db96-278d-44b5-b7f6-22a98815546b@github.com>
References: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
 <BkMd6YH8WQG1vooguwyXEluf-HivXjYDC4wSRiMAkH4=.4216db96-278d-44b5-b7f6-22a98815546b@github.com>
Message-ID: <6xerWH9jtlW78EFeGGELdg66ZseR6xMQq7H0j0NFmL0=.8c2b0f90-0f62-43bf-b063-b8256ecee014@github.com>

On Fri, 9 May 2025 01:39:07 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Symbolic links will not be followed for `--app-content` on all platforms.
>> - Added test to cover this case.
>> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8352480: [macos] Don't follow symlinks in additional content for app images [v6]

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24974#pullrequestreview-2826761214

From asemenyuk at openjdk.org  Fri May  9 01:56:52 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 9 May 2025 01:56:52 GMT
Subject: RFR: 8352480: Don't follow symlinks in additional content for app
 images [v3]
In-Reply-To: <LX4Q9p1HuZ1qoYzxo2cXY18oPVwFndIGqq10aQ1z5Ow=.a99d8c4d-8e7a-4189-90e9-77763c1b6075@github.com>
References: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
 <nBloeGMFbz5uS_37AONMV0ApSWAtYHzgu-DQyqt0Oyo=.20e9ee1f-81ba-422e-93cf-a38ae4ec4318@github.com>
 <zP6X7Ijb_HVeCFpGxmSpnObvH9WInHbhnSV6IaSIHsA=.bd16b9db-0c64-4086-852e-87394164fbfa@github.com>
 <LX4Q9p1HuZ1qoYzxo2cXY18oPVwFndIGqq10aQ1z5Ow=.a99d8c4d-8e7a-4189-90e9-77763c1b6075@github.com>
Message-ID: <-XJNPKRmCHHRZnGdNEFKmOwDptTvMjO24F0jXMGMl1I=.62c2f09e-ee47-4fdb-b636-951a340618fa@github.com>

On Fri, 9 May 2025 00:10:34 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> test/jdk/tools/jpackage/share/AppContentTest.java line 116:
>> 
>>> 114:     private static Path getAppContentPath(JPackageCommand cmd, Path name) {
>>> 115:         Path contentDir = cmd.appLayout().contentDirectory();
>>> 116:         // Links are always created in "Resources"
>> 
>>> Links are always created in "Resources"
>> 
>> All additional content on macOS is created in the "Resources" directory. On Linux there is no such requirement.
>> 
>> The return value of `getAppContentPath()` is not supposed to depend on the additional content type; the new "name" parameter doesn't make sense to me.
>
> For links we creating link and corresponding text file, so for it we should put both files into folder and add it to `--app-content app-content-0/Resources`. Note `app-content-0` is temp folder with random name and if we using it directly we end up copying `app-content-0` into application bundle. In such case it will not be possible to figure out location of link without putting it under known folder name such as "Resources".
> 
> "name" is to figure out if it link and if link it should be under "Resources".

I can see you reverted the `getAppContentPath()` back. I guess it happened after your comment :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24974#discussion_r2080753720

From dholmes at openjdk.org  Fri May  9 02:08:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 02:08:58 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v2]
In-Reply-To: <IQH5pfqDgtW2UCEbM800YyXfqbnB9VBT8f3T0oGZ3tY=.99cb3c22-45d4-43d8-a575-379b315bbc14@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <IQH5pfqDgtW2UCEbM800YyXfqbnB9VBT8f3T0oGZ3tY=.99cb3c22-45d4-43d8-a575-379b315bbc14@github.com>
Message-ID: <iVZYQLfDj7Otw7cwmAhj4Q1YWpyXbCIpt3pIlzhB61Q=.504812a7-1024-4ce2-8a84-285db9f2452d@github.com>

On Thu, 8 May 2025 13:18:07 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Update release date
>  - Update --release 25 symbol information for JDK 25 build 21
>    The macOS/AArch64 build 21 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>    
>    # Conflicts:
>    #	test/langtools/tools/javac/versions/Versions.java
>  - feedback: never bump ASM version
>  - Update copyright years
>    
>    Note: any commit hashes below might be outdated due to subsequent
>    history rewriting (e.g. git rebase).
>    
>     + update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java due to 6077665a274
>     + update src/java.compiler/share/classes/...

Hotspot source and test changes look trivially good.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2826771967

From dholmes at openjdk.org  Fri May  9 02:47:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 02:47:53 GMT
Subject: RFR: 8355938: Addressed rare lost unpark bug 8074773 by
 pre-loading LockSupport.class
In-Reply-To: <bLLsppdQBU2jMbn2p3NK70ShoBMbB8xxjnlDE_FYV_g=.13f7414c-a514-4076-a1df-7fe4c0d8b31b@github.com>
References: <tcZkZgScJXJYpRK68NSRUTl7gcOhePhABSQz0DOzArI=.137600e0-7656-4c7a-85de-c340173467fc@github.com>
 <M7K--fqIQU_E8LdwuAE4fXNMB90mjh6jVkCCegmmz0I=.04616e1e-4f8c-4df2-a699-02520ac96c7d@github.com>
 <bLLsppdQBU2jMbn2p3NK70ShoBMbB8xxjnlDE_FYV_g=.13f7414c-a514-4076-a1df-7fe4c0d8b31b@github.com>
Message-ID: <b1toctRsBgSbX9dLHZ1Q_2F0VTIqHksrZFzq_ULBwsQ=.d72d9395-7219-4590-9586-10b08ddb4173@github.com>

On Wed, 30 Apr 2025 11:25:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Hopefully David will remember more of this when he gets back.

Sadly I have to page in all the details again like everyone else.

The underlying issue is nested-parking as Alan notes. From re-reading 8074773, pre-loading in any class loaded by the boot loader, has no affect on the bug. The issue was the action taken by the AppLoader that involved creating an entry in the lockMap CHM. That particular bug-path was closed when CHM was rewritten to use object monitors (did it re-open again when Loom came along?).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2864931853

From iklam at openjdk.org  Fri May  9 03:10:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 9 May 2025 03:10:41 GMT
Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner
 classes [v3]
In-Reply-To: <JQCL1DGBobBWQqWeX3Ykuw1nZOis5D8k6kEllWluE0s=.a089b081-da05-436c-b0f7-ec021887ea57@github.com>
References: <JQCL1DGBobBWQqWeX3Ykuw1nZOis5D8k6kEllWluE0s=.a089b081-da05-436c-b0f7-ec021887ea57@github.com>
Message-ID: <S9zZnq0QX9easygbGVzrlBGC7wF6qWVzRsWcV_8fFxc=.2a771144-acbe-46da-ab45-9b7e5b4ed859@github.com>

> This is a general fix for all the "points to a static field that may hold a different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330).
> 
> AOT-cached method handles quite often refer to the static fields in `MethodHandleImpl` or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. `CDSHeapVerifier` makes a very conservative check for such static fields, but sometimes gives false positives (as in the above two JBS issues)
> 
> In this PR, we AOT-initialize `MethodHandleImpl` and its inner classes. This is a more authentic snapshot of the state of `java.lang.invoke` during the assembly phase. We also avoid the need to add and maintain entries in the `cdsHeapVerifier.cpp` table.
> 
> I also added more code in `MethodHandleTest.java` to simulate potential usage patterns of `MethodHandle` by the Java core libraries. Hopefully this will reduce the likelihood for innocent core lib changes breaking the AOT assembly phase.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'master' into 8354890-aot-init-methodhandleimpl-and-inner-classes
 - Comments from @liach and @ExE-Boss
 - Added more test case to increase coverage on possible core-lib usage patterns for MethodHandles
 - Merge branch 'master' into 8354890-aot-init-methodhandleimpl-and-inner-classes
 - 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes
 - @fisk comment -- use proper HeapAccess to load referent; Also refactor AOTReferenceObjSupport::is_enabled()
 - Merge branch 'master' into 8354897-soft-weak-references-in-aot-cache
 - @fisk offline comments -- tighten up and simplify eligibility check; @DanHeidinga comment -- renamed to MethodType::assemblySetup()
 - @DanHeidinga comments
 - @fisk comment
 - ... and 10 more: https://git.openjdk.org/jdk/compare/9a0e6f33...0571ddc3

-------------

Changes: https://git.openjdk.org/jdk/pull/24956/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24956&range=02
  Stats: 181 lines in 8 files changed: 169 ins; 5 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24956/head:pull/24956

PR: https://git.openjdk.org/jdk/pull/24956

From dholmes at openjdk.org  Fri May  9 04:57:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 04:57:50 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

My biggest concern with this change is that potentially any test that implicitly uses the default timeout, and which passes with no problem with a factor of 4, may now need to have an explicit timeout set due to the factor of 1. I see this change in a number of tests (default timeout of 120s expressed as a new timeout of 480s to maintain equivalence**), but how many times did you run the tiers? I fear that the gatekeepers will be playing timeout whack-a-mole once these changes are put in.

** though another option would be to update the jtreg default timeout instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865099247

From alanb at openjdk.org  Fri May  9 05:56:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 05:56:51 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <p1-YD8qt9XC1iQmDHogYaEYqIepOV20IJ5Zhgipoq38=.6829d786-6557-49ad-94a1-b0f22290bac8@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
 <p1-YD8qt9XC1iQmDHogYaEYqIepOV20IJ5Zhgipoq38=.6829d786-6557-49ad-94a1-b0f22290bac8@github.com>
Message-ID: <oVXDQkJ3zdmpE0yOmrIyCS6r3riw-FXwy4dj4vKrSF0=.cc235b02-1a33-4466-afe4-d406b22a2f23@github.com>

On Thu, 8 May 2025 19:51:12 GMT, Chen Liang <liach at openjdk.org> wrote:

> May I provide a quick patch to use an alternative mechanism to test preview class file versions for that class instead of changing that in this PR?

That would be good as it shouldn't depend on ScopedValue being a preview API class.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2865223857

From iklam at openjdk.org  Fri May  9 06:03:02 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 9 May 2025 06:03:02 GMT
Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner
 classes [v3]
In-Reply-To: <EbhS0ferM7Z5YfWq09RQzb8ALc0xdE4Gx6e03lnxsA8=.69eb708e-e79d-4af8-a86d-3d47425e2fea@github.com>
References: <JQCL1DGBobBWQqWeX3Ykuw1nZOis5D8k6kEllWluE0s=.a089b081-da05-436c-b0f7-ec021887ea57@github.com>
 <Xx7OLj80AjJ_Ay-yUz-Lgd9DRLg2QWyEn97WSrnvnxg=.c639e8e9-ba3c-4844-a0e2-d8bbcec728c1@github.com>
 <EbhS0ferM7Z5YfWq09RQzb8ALc0xdE4Gx6e03lnxsA8=.69eb708e-e79d-4af8-a86d-3d47425e2fea@github.com>
Message-ID: <Yzkovl_J-_Nlpe5gWL_lyOUIwLf67Rqyjh84lTCG56Y=.459af69f-3839-4cb9-97be-f32a9ac39017@github.com>

On Mon, 5 May 2025 23:50:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Merge branch 'master' into 8354890-aot-init-methodhandleimpl-and-inner-classes
>>  - Comments from @liach and @ExE-Boss
>>  - Added more test case to increase coverage on possible core-lib usage patterns for MethodHandles
>>  - Merge branch 'master' into 8354890-aot-init-methodhandleimpl-and-inner-classes
>>  - 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes
>>  - @fisk comment -- use proper HeapAccess to load referent; Also refactor AOTReferenceObjSupport::is_enabled()
>>  - Merge branch 'master' into 8354897-soft-weak-references-in-aot-cache
>>  - @fisk offline comments -- tighten up and simplify eligibility check; @DanHeidinga comment -- renamed to MethodType::assemblySetup()
>>  - @DanHeidinga comments
>>  - @fisk comment
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/9a0e6f33...0571ddc3
>
> The Java code change and the BSM coverage looks good to me. Requiring another reviewer for hotspot changes.

Thanks @liach @iwanowww for the review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24956#issuecomment-2865231404

From iklam at openjdk.org  Fri May  9 06:03:02 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 9 May 2025 06:03:02 GMT
Subject: Integrated: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner
 classes
In-Reply-To: <JQCL1DGBobBWQqWeX3Ykuw1nZOis5D8k6kEllWluE0s=.a089b081-da05-436c-b0f7-ec021887ea57@github.com>
References: <JQCL1DGBobBWQqWeX3Ykuw1nZOis5D8k6kEllWluE0s=.a089b081-da05-436c-b0f7-ec021887ea57@github.com>
Message-ID: <pq0JyAKESxcY-fUN5xPq5w0Lm6k7ovi-ksbCb2m5-0A=.512ea0c7-2857-429e-8715-743c301eaf9a@github.com>

On Tue, 29 Apr 2025 22:59:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is a general fix for all the "points to a static field that may hold a different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330).
> 
> AOT-cached method handles quite often refer to the static fields in `MethodHandleImpl` or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. `CDSHeapVerifier` makes a very conservative check for such static fields, but sometimes gives false positives (as in the above two JBS issues)
> 
> In this PR, we AOT-initialize `MethodHandleImpl` and its inner classes. This is a more authentic snapshot of the state of `java.lang.invoke` during the assembly phase. We also avoid the need to add and maintain entries in the `cdsHeapVerifier.cpp` table.
> 
> I also added more code in `MethodHandleTest.java` to simulate potential usage patterns of `MethodHandle` by the Java core libraries. Hopefully this will reduce the likelihood for innocent core lib changes breaking the AOT assembly phase.

This pull request has now been integrated.

Changeset: 591e71eb
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/591e71ebe501e6e88249f46efda4134277f29b08
Stats:     181 lines in 8 files changed: 169 ins; 5 del; 7 mod

8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes

Reviewed-by: liach, vlivanov

-------------

PR: https://git.openjdk.org/jdk/pull/24956

From pminborg at openjdk.org  Fri May  9 06:27:54 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 9 May 2025 06:27:54 GMT
Subject: RFR: 8356486: ReverseOrderListView should override reversed() to
 return `base`
In-Reply-To: <R1KALQrvyYCiu1BsIG_De23Tvr_f1qnQWDZZDTshqUs=.509f270e-1564-4480-86e1-0fbbc2de5890@github.com>
References: <X2vnz1BagQ5K7q-2_oHt9X1JjejNJw5TE44vSUJKeaU=.28fad491-d94c-4fcb-9a44-001a62e0beb4@github.com>
 <EINLtspNPHYrnKfHa4KM28W921Q_CuMpBAvY6H8pnoM=.b554ca1e-732f-4f33-9078-6a34a33fabed@github.com>
 <R1KALQrvyYCiu1BsIG_De23Tvr_f1qnQWDZZDTshqUs=.509f270e-1564-4480-86e1-0fbbc2de5890@github.com>
Message-ID: <t13IxE_zW9i4zSHjC7EUUU57dJsaZ8_aNV4TedUqQ2E=.f6da327c-79ee-4445-97b8-434f9425bfbd@github.com>

On Thu, 8 May 2025 16:13:19 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> test/jdk/java/util/Collection/MOAT.java line 507:
>> 
>>> 505:     private static <T> void testImmutableSeqColl(final SequencedCollection<T> c, T t) {
>>> 506:         SequencedCollection<T> r = c.reversed();
>>> 507:         if (r instanceof List<T> list && list.reversed() != c) {
>> 
>> Shouldn't all double-reverse be identity? Why is this restricted to lists?
>
> This should already be covered by the testDoubleReverse() test in test/jdk/java/util/SequencedCollection/Basic.java.

There are some new collections (such as StableList) that are not covered in Basic. But maybe they should have their separate tests?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25120#discussion_r2081013384

From alanb at openjdk.org  Fri May  9 06:34:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 06:34:51 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
 <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
Message-ID: <_VEnZnG0YjPHzre6rmgbbgTFvIXXLyPEAEbzo6_fxYg=.f085651b-1c03-4d11-9fb1-bf2c1e8081b8@github.com>

On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments).
>> 
>> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup).
>> 
>> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename awaitBlocked to awaitTrueAndBlocked

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25119#pullrequestreview-2827165376

From alanb at openjdk.org  Fri May  9 06:34:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 06:34:52 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <7Niz4vvjmS0vFVNtKbj5Wkur6sXeLSndE_7MU4QIpDE=.61dbd1d9-67e3-43d7-8908-1d7f3d378d35@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
 <HiNe8vwwicMUDOTFQYSP4npH2W9K6fwPYCzR_tVQu0s=.fa3de89f-fc21-4ed4-bf7e-3d5ea3559dd2@github.com>
 <7Niz4vvjmS0vFVNtKbj5Wkur6sXeLSndE_7MU4QIpDE=.61dbd1d9-67e3-43d7-8908-1d7f3d378d35@github.com>
Message-ID: <GrTeVQOpUqy5D8KZ2sI6IcVWbhTtCLiEk1-gaNj0Qb0=.ba95f998-c45a-41c8-98df-1d9261c8648c@github.com>

On Thu, 8 May 2025 19:49:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 99:
>> 
>>> 97:         System.out.println("Waiting for thread1 and thread2 to deadlock ...");
>>> 98:         awaitBlocked(thread1, reached1);
>>> 99:         awaitBlocked(thread2, reached2);
>> 
>> This looks okay but does mean that awaitBlocked is doing two things, maybe it should be rename to awaitTrueAndBlocked. 
>> 
>> An alternative that would remove AtomicReference from the picture is to just have two volatile booleans and have the main thread poll both until true. That would leave the use of awaitBlock unchanged but what you have is okay too.
>
> Yes, I actually had that in an initial version. Then I thought it was cleaner to just have all waiting logic in awaitBlocked so I changed it. I renamed `awaitBlocked` to `awaitTrueAndBlocked` for now. But let me know if you prefer the two volatile booleans instead.
> 
> Also, we could remove the `CyclicBarrier` and have each thread poll the other?s thread flag now, but given this bug was found due to the barrier I left it as is.

Okay, I think what you have is good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25119#discussion_r2081022353

From alanb at openjdk.org  Fri May  9 06:40:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 06:40:00 GMT
Subject: RFR: 8355938: Addressed rare lost unpark bug 8074773 by
 pre-loading LockSupport.class
In-Reply-To: <b1toctRsBgSbX9dLHZ1Q_2F0VTIqHksrZFzq_ULBwsQ=.d72d9395-7219-4590-9586-10b08ddb4173@github.com>
References: <tcZkZgScJXJYpRK68NSRUTl7gcOhePhABSQz0DOzArI=.137600e0-7656-4c7a-85de-c340173467fc@github.com>
 <M7K--fqIQU_E8LdwuAE4fXNMB90mjh6jVkCCegmmz0I=.04616e1e-4f8c-4df2-a699-02520ac96c7d@github.com>
 <bLLsppdQBU2jMbn2p3NK70ShoBMbB8xxjnlDE_FYV_g=.13f7414c-a514-4076-a1df-7fe4c0d8b31b@github.com>
 <b1toctRsBgSbX9dLHZ1Q_2F0VTIqHksrZFzq_ULBwsQ=.d72d9395-7219-4590-9586-10b08ddb4173@github.com>
Message-ID: <Jvsqkm2TUPkIuCMDITmGYPABl-U6hQNZZrDVn5n0axE=.14379a3a-9d24-4829-9c60-8a4ff882cad5@github.com>

On Fri, 9 May 2025 02:45:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The underlying issue is nested-parking as Alan notes. From re-reading 8074773, pre-loading in any class loaded by the boot loader, has no affect on the bug. The issue was the action taken by the AppLoader that involved creating an entry in the lockMap CHM. That particular bug-path was closed when CHM was rewritten to use object monitors (did it re-open again when Loom came along?).

No, it will still uses synchronized if there is contention and this will not consume the park permit when it's a virtual thread. Im not sure if Heinz ran into an issue, or just remember the issue from 2015, Heinz?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2865320135

From david.holmes at oracle.com  Fri May  9 06:44:43 2025
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 9 May 2025 16:44:43 +1000
Subject: Runtime.exec and SIGPIPE + SIG_IGN
In-Reply-To: <CAA-vtUxC=GuSiycAVuKTWWJNMVWU9B9TTXM9fx5=WDWKk4MqZw@mail.gmail.com>
References: <CAA-vtUxC=GuSiycAVuKTWWJNMVWU9B9TTXM9fx5=WDWKk4MqZw@mail.gmail.com>
Message-ID: <ccbdaea9-8ffe-413c-87f2-9e98140bddc5@oracle.com>

Hi Thomas,

On 29/04/2025 7:04 pm, Thomas St?fe wrote:
> Hi,
> 
> I would like to gauge opinions on whether the following scenario is a 
> bug to fix or whether to accept it as standard behavior.
> 
> ---
> 
> A customer has the following problem:
> 
> - The JVM invokes a third-party JNI library that sets the signal 
> disposition of SIGPIPE to SIG_IGN (Boo! in this case, it is the FIPS 
> nspr library, which does this unconditionally.)
> - The JVM then spawns child processes
> - All child processes now ignore SIGPIPE, which leads to failures in 
> automation scripts
> 
> I was surprised. I always assumed the signal disposition of all signals 
> would be reset to SIG_DFL when exec'ing. However, seems I was wrong when 
> it came to SIG_IGN. Posix documents for execve() states [1]:
> 
> 1) " Signals set to the default action (SIG_DFL) in the calling process 
> image shall be set to the default action in the new process image."
> 
> and
> 
> 2) "Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the 
> calling process image shall be set to be ignored by the new process image."
> 
> and
> 
> 3) "Signals set to be caught by the calling process image shall be set 
> to the default action in the new process image (see /<signal.h>/ 
> <https://pubs.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html>)."
> 
> (2) and (3) are the interesting parts. (2) means that if the parent 
> process ignores SIGPIPE, child processes will also ignore SIGPIPE. (3) 
> means that if the parent process has a custom handler installed for 
> SIGPIPE, child processes will be started with SIG_DFL (default action) 
> for SIGPIPE. The default action for SIGPIPE is "terminate process".
> 
> The libjvm handles SIGPIPE. We install our `javaSignalHandler`. We do 
> this to eat up and ignore SIGPIPE. That we "manually" ignore the signal 
> beside the point here - what counts is that we set a custom signal 
> handler for SIGPIPE. Therefore, on execve, we behave according to rule 
> (3) and start the child with SIG_DFL as SIGPIPE disposition. As it 
> should be.
> 
> If third-party code sets the handler to SIG_IGN as in this example, 
> exeve will behave according to rule (2) and the child will start with 
> SIG_IGN as SIGPIPE disposition.
> 
> The libjig can be used to workaround this scenario, but I wonder if that 
> is more of an accident. The libjsig.so will preserve the JVM's SIGPIPE 
> handler even if third-party code attempts to set it to SIG_IGN. That 
> means that exeve still behaves according to rule (2): sets child's 
> SIGPIPE disposition to SIG_DFL.
> 
> ----
> 
> But I wonder whether this should not be considered a bug to fix 
> regardless of the jsig.so workaround? In jspawnhelper, we clean the 
> environment from various effects when exec'ing; among other things, we 
> reset the signal block mask for the process. The "ignore" state of 
> processes could be considered along the same line. We could reset all 
> signal handlers to SIG_DFL before execing the child.
> 
> I know that this area is super-tricky and problems are notoriously 
> difficult to analyze; we should therefore be extremely careful not to 
> break downward compatibility. Still, what do people think? Should be fix 
> this in jspawnhelper?

I think at most, the exec'ing code could restore the signals the VM has 
modified to their default disposition - which in practice would mean 
only those set to SIG_IGN would need to explicitly be changed, which in 
turn may mean only SIGPIPE is affected?

Even so, a library/application that ignores SIGPIPE and exec's other 
processes which it expects also ignore SIGPIPE, would not be happy with 
such a change.

In the customer scenario described maybe the simplest fix is to have 
them use libjsig.

Cheers,
David

> 
> Thanks, Thomas
> 
> (cc'ing Roger)
> 
> [1] https://pubs.opengroup.org/onlinepubs/009695399/functions/exec.html 
> <https://pubs.opengroup.org/onlinepubs/009695399/functions/exec.html>


From thomas.stuefe at gmail.com  Fri May  9 07:02:13 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 9 May 2025 09:02:13 +0200
Subject: Runtime.exec and SIGPIPE + SIG_IGN
In-Reply-To: <ccbdaea9-8ffe-413c-87f2-9e98140bddc5@oracle.com>
References: <CAA-vtUxC=GuSiycAVuKTWWJNMVWU9B9TTXM9fx5=WDWKk4MqZw@mail.gmail.com>
 <ccbdaea9-8ffe-413c-87f2-9e98140bddc5@oracle.com>
Message-ID: <CAA-vtUxq50_YGqAWAR23AMx8Qwg820SSbrTjA_0WdJw+etaY6Q@mail.gmail.com>

Hi David,

On Fri, May 9, 2025 at 8:44?AM David Holmes <david.holmes at oracle.com> wrote:

> Hi Thomas,
>
> On 29/04/2025 7:04 pm, Thomas St?fe wrote:
> > Hi,
> >
> > I would like to gauge opinions on whether the following scenario is a
> > bug to fix or whether to accept it as standard behavior.
> >
> > ---
> >
> > A customer has the following problem:
> >
> > - The JVM invokes a third-party JNI library that sets the signal
> > disposition of SIGPIPE to SIG_IGN (Boo! in this case, it is the FIPS
> > nspr library, which does this unconditionally.)
> > - The JVM then spawns child processes
> > - All child processes now ignore SIGPIPE, which leads to failures in
> > automation scripts
> >
> > I was surprised. I always assumed the signal disposition of all signals
> > would be reset to SIG_DFL when exec'ing. However, seems I was wrong when
> > it came to SIG_IGN. Posix documents for execve() states [1]:
> >
> > 1) " Signals set to the default action (SIG_DFL) in the calling process
> > image shall be set to the default action in the new process image."
> >
> > and
> >
> > 2) "Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the
> > calling process image shall be set to be ignored by the new process
> image."
> >
> > and
> >
> > 3) "Signals set to be caught by the calling process image shall be set
> > to the default action in the new process image (see /<signal.h>/
> > <https://pubs.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html
> >)."
> >
> > (2) and (3) are the interesting parts. (2) means that if the parent
> > process ignores SIGPIPE, child processes will also ignore SIGPIPE. (3)
> > means that if the parent process has a custom handler installed for
> > SIGPIPE, child processes will be started with SIG_DFL (default action)
> > for SIGPIPE. The default action for SIGPIPE is "terminate process".
> >
> > The libjvm handles SIGPIPE. We install our `javaSignalHandler`. We do
> > this to eat up and ignore SIGPIPE. That we "manually" ignore the signal
> > beside the point here - what counts is that we set a custom signal
> > handler for SIGPIPE. Therefore, on execve, we behave according to rule
> > (3) and start the child with SIG_DFL as SIGPIPE disposition. As it
> > should be.
> >
> > If third-party code sets the handler to SIG_IGN as in this example,
> > exeve will behave according to rule (2) and the child will start with
> > SIG_IGN as SIGPIPE disposition.
> >
> > The libjig can be used to workaround this scenario, but I wonder if that
> > is more of an accident. The libjsig.so will preserve the JVM's SIGPIPE
> > handler even if third-party code attempts to set it to SIG_IGN. That
> > means that exeve still behaves according to rule (2): sets child's
> > SIGPIPE disposition to SIG_DFL.
> >
> > ----
> >
> > But I wonder whether this should not be considered a bug to fix
> > regardless of the jsig.so workaround? In jspawnhelper, we clean the
> > environment from various effects when exec'ing; among other things, we
> > reset the signal block mask for the process. The "ignore" state of
> > processes could be considered along the same line. We could reset all
> > signal handlers to SIG_DFL before execing the child.
> >
> > I know that this area is super-tricky and problems are notoriously
> > difficult to analyze; we should therefore be extremely careful not to
> > break downward compatibility. Still, what do people think? Should be fix
> > this in jspawnhelper?
>
> I think at most, the exec'ing code could restore the signals the VM has
> modified to their default disposition - which in practice would mean
> only those set to SIG_IGN would need to explicitly be changed, which in
> turn may mean only SIGPIPE is affected?
>

Agreed, if I fix this in jspawnhelper, I fix it very conservatively for
only this signal.


>
> Even so, a library/application that ignores SIGPIPE and exec's other
> processes which it expects also ignore SIGPIPE, would not be happy with
> such a change.
>
>
The problem is that libjsig, albeit working, is clunky to use in practice
and requires control of the environment the customer may not have.

And there are no good solutions, since whatever decision one does it won't
work for a portion of customers. The way it works now is broken for at
least all accidental users of this FIPS library. They may not even know
that they use this library. And it is inconsistent, since the behavior is
different depending on whether the SIG_IGN had been set before or after VM
creation. So, it differs for custom launchers e.g. that set up signal
handling upfront before loading the libjvm.

My guess would be that the behavior now bothers more customers than a reset
to SIG_DFL for SIGPIPE would.

Cheers, Thomas

P.S. before doing any behavioral change, I plan to add good extensive
tracing to jspawnhelper, in order to make it simple to analyze situations
like this.

In the customer scenario described maybe the simplest fix is to have
> them use libjsig.
>
> Cheers,
> David
>
> >
> > Thanks, Thomas
> >
> > (cc'ing Roger)
> >
> > [1] https://pubs.opengroup.org/onlinepubs/009695399/functions/exec.html
> > <https://pubs.opengroup.org/onlinepubs/009695399/functions/exec.html>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250509/dba7af8a/attachment-0001.htm>

From pminborg at openjdk.org  Fri May  9 07:05:56 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 9 May 2025 07:05:56 GMT
Subject: RFR: 8356486: ReverseOrderListView should override reversed() to
 return `base`
In-Reply-To: <t13IxE_zW9i4zSHjC7EUUU57dJsaZ8_aNV4TedUqQ2E=.f6da327c-79ee-4445-97b8-434f9425bfbd@github.com>
References: <X2vnz1BagQ5K7q-2_oHt9X1JjejNJw5TE44vSUJKeaU=.28fad491-d94c-4fcb-9a44-001a62e0beb4@github.com>
 <EINLtspNPHYrnKfHa4KM28W921Q_CuMpBAvY6H8pnoM=.b554ca1e-732f-4f33-9078-6a34a33fabed@github.com>
 <R1KALQrvyYCiu1BsIG_De23Tvr_f1qnQWDZZDTshqUs=.509f270e-1564-4480-86e1-0fbbc2de5890@github.com>
 <t13IxE_zW9i4zSHjC7EUUU57dJsaZ8_aNV4TedUqQ2E=.f6da327c-79ee-4445-97b8-434f9425bfbd@github.com>
Message-ID: <f_8e1B3BB9mfaf_qz9naA7ARqVgDQP4Q6KUMy514MKU=.e8ecb4af-a4c2-498f-a334-ab442c723760@github.com>

On Fri, 9 May 2025 06:24:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This should already be covered by the testDoubleReverse() test in test/jdk/java/util/SequencedCollection/Basic.java.
>
> There are some new collections (such as StableList) that are not covered in Basic. But maybe they should have their separate tests?

`UnmodifiableSequencedCollection` double-reversed is not an identity function. But at least, it does not nest, as it returns a new USC with the underlying collection reversed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25120#discussion_r2081060529

From jpai at openjdk.org  Fri May  9 07:07:38 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 9 May 2025 07:07:38 GMT
Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for ZIP entry with
 empty file data [v2]
In-Reply-To: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
References: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
Message-ID: <eh0QjAzXgcATScECaeqQUbBLx2IRaf9hRGjknh8Q7g8=.7b30e0a9-36aa-4023-9ceb-e257aed902a8@github.com>

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799?
> 
> `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix.
> 
> tier testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Lance's suggestion - use assertThrows()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25116/files
  - new: https://git.openjdk.org/jdk/pull/25116/files/b2c011d1..0aea22fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25116&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25116&range=00-01

  Stats: 14 lines in 1 file changed: 2 ins; 5 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25116/head:pull/25116

PR: https://git.openjdk.org/jdk/pull/25116

From dfuchs at openjdk.org  Fri May  9 07:18:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 07:18:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
Message-ID: <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>

On Thu, 8 May 2025 17:41:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thank you. I have imported your PR locally and running some HTTP client tests in the CI.
> Tests have not finished running - but I already see one intermittent failure:
> `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows.
> It would be good to flush out any such intermittent failures before this PR is integrated.
> This might require multiple runs before we can get confidence.

Results came back - another intermittent timeout failure (much more frequent) observed in:
`java/net/httpclient/CancelledResponse.java` on macOS x64

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865413003

From cstein at openjdk.org  Fri May  9 07:36:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 07:36:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>
Message-ID: <P_bn9YLGadoCvpQ4U3pQCWqa_FgbqOs_Smf_TRfTUxw=.5db4086c-fef8-437b-aa77-26124ea44177@github.com>

On Fri, 9 May 2025 04:54:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> [...]
> ** though another option would be to update the jtreg default timeout instead.

And affect all other tests, too? I'd rather let the default stay on the former hard-coded 120s value.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865469908

From xgong at openjdk.org  Fri May  9 07:44:27 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 9 May 2025 07:44:27 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword
 gather load API
Message-ID: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>

JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]).

Two key areas require improvement:
1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance.
2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types  increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance.

This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures.

Main changes:
1. Java-side API refactoring:
   - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on
     architectures like AArch64.
2. C2 compiler IR refactoring:
   - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types.
3. Backend changes:
   - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level.

Performance:
The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below:

Benchmark                                                 Mode   Cnt Unit    SIZE    Before      After    Gain
GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  64    53682.012   52650.325  0.98
GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  256   14484.252   14255.156  0.98
GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  1024   3664.900    3595.615  0.98
GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  4096    908.312     935.269  1.02
GatherOperationsBenchmark.microByteGather128_MASK         thrpt  30  ops/ms  64    43040.148   44605.580  1.03
GatherOperationsBenchmark.microByteGather128_MASK         thrpt  30  ops/ms  256   12445.650   12928.102  1.03
GatherOperationsBenchmark.microByteGather128_MASK         thrpt  30  ops/ms  1024   3143.728    3294.173  1.04
GatherOperationsBenchmark.microByteGather128_MASK         thrpt  30  ops/ms  4096    801.516     842.951  1.05
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF  thrpt  30  ops/ms  64    40379.343   45255.490  1.12
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF  thrpt  30  ops/ms  256   11103.537   12971.581  1.16
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF  thrpt  30  ops/ms  1024   2767.870    3299.453  1.19
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF  thrpt  30  ops/ms  4096    704.610     840.908  1.19
GatherOperationsBenchmark.microByteGather128_NZ_OFF       thrpt  30  ops/ms  64    49066.340   53365.591  1.08
GatherOperationsBenchmark.microByteGather128_NZ_OFF       thrpt  30  ops/ms  256   14063.326   14286.067  1.01
GatherOperationsBenchmark.microByteGather128_NZ_OFF       thrpt  30  ops/ms  1024   3617.992    3621.272  1.00
GatherOperationsBenchmark.microByteGather128_NZ_OFF       thrpt  30  ops/ms  4096    861.026     938.055  1.08
GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  64    55844.814   48311.847  0.86
GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  256   15139.459   13009.848  0.85
GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  1024   3861.834    3284.944  0.85
GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  4096    938.665     817.673  0.87
GatherOperationsBenchmark.microByteGather256_MASK         thrpt  30  ops/ms  64    43942.924   43144.065  0.98
GatherOperationsBenchmark.microByteGather256_MASK         thrpt  30  ops/ms  256   12461.170   11580.981  0.92
GatherOperationsBenchmark.microByteGather256_MASK         thrpt  30  ops/ms  1024   3168.598    2945.698  0.92
GatherOperationsBenchmark.microByteGather256_MASK         thrpt  30  ops/ms  4096    803.515     738.049  0.91
GatherOperationsBenchmark.microByteGather256_MASK_NZ_OFF  thrpt  30  ops/ms  64    42197.440   43209.913  1.02
GatherOperationsBenchmark.microByteGather256_MASK_NZ_OFF  thrpt  30  ops/ms  256   11456.761   11713.265  1.02
GatherOperationsBenchmark.microByteGather256_MASK_NZ_OFF  thrpt  30  ops/ms  1024   2732.576    2949.724  1.07
GatherOperationsBenchmark.microByteGather256_MASK_NZ_OFF  thrpt  30  ops/ms  4096    726.062     744.774  1.02
GatherOperationsBenchmark.microByteGather256_NZ_OFF       thrpt  30  ops/ms  64    52915.781   49520.027  0.93
GatherOperationsBenchmark.microByteGather256_NZ_OFF       thrpt  30  ops/ms  256   14481.921   13496.835  0.93
GatherOperationsBenchmark.microByteGather256_NZ_OFF       thrpt  30  ops/ms  1024   3632.065    3362.372  0.92
GatherOperationsBenchmark.microByteGather256_NZ_OFF       thrpt  30  ops/ms  4096    892.825     845.809  0.94
GatherOperationsBenchmark.microByteGather512              thrpt  30  ops/ms  64    54528.404   54478.751  0.99
GatherOperationsBenchmark.microByteGather512              thrpt  30  ops/ms  256   15018.181   14673.727  0.97
GatherOperationsBenchmark.microByteGather512              thrpt  30  ops/ms  1024   3824.690    3589.530  0.93
GatherOperationsBenchmark.microByteGather512              thrpt  30  ops/ms  4096    923.601     906.245  0.98
GatherOperationsBenchmark.microByteGather512_MASK         thrpt  30  ops/ms  64    41248.192   42201.455  1.02
GatherOperationsBenchmark.microByteGather512_MASK         thrpt  30  ops/ms  256   11481.408   11559.655  1.00
GatherOperationsBenchmark.microByteGather512_MASK         thrpt  30  ops/ms  1024   2901.592    2912.954  1.00
GatherOperationsBenchmark.microByteGather512_MASK         thrpt  30  ops/ms  4096    732.899     730.381  0.99
GatherOperationsBenchmark.microByteGather512_MASK_NZ_OFF  thrpt  30  ops/ms  64    42287.123   43779.227  1.03
GatherOperationsBenchmark.microByteGather512_MASK_NZ_OFF  thrpt  30  ops/ms  256   11486.167   11448.966  0.99
GatherOperationsBenchmark.microByteGather512_MASK_NZ_OFF  thrpt  30  ops/ms  1024   2888.047    2928.612  1.01
GatherOperationsBenchmark.microByteGather512_MASK_NZ_OFF  thrpt  30  ops/ms  4096    731.056     738.300  1.00
GatherOperationsBenchmark.microByteGather512_NZ_OFF       thrpt  30  ops/ms  64    51777.670   54368.797  1.05
GatherOperationsBenchmark.microByteGather512_NZ_OFF       thrpt  30  ops/ms  256   14558.532   14662.164  1.00
GatherOperationsBenchmark.microByteGather512_NZ_OFF       thrpt  30  ops/ms  1024   3726.910    3714.448  0.99
GatherOperationsBenchmark.microByteGather512_NZ_OFF       thrpt  30  ops/ms  4096    907.863     903.544  0.99
GatherOperationsBenchmark.microByteGather64               thrpt  30  ops/ms  64    52980.507   54970.689  1.03
GatherOperationsBenchmark.microByteGather64               thrpt  30  ops/ms  256   15044.443   15828.237  1.05
GatherOperationsBenchmark.microByteGather64               thrpt  30  ops/ms  1024   3869.028    4098.172  1.05
GatherOperationsBenchmark.microByteGather64               thrpt  30  ops/ms  4096    912.372    1002.065  1.09
GatherOperationsBenchmark.microByteGather64_MASK          thrpt  30  ops/ms  64    44267.641   45864.381  1.03
GatherOperationsBenchmark.microByteGather64_MASK          thrpt  30  ops/ms  256   12303.206   12920.113  1.05
GatherOperationsBenchmark.microByteGather64_MASK          thrpt  30  ops/ms  1024   3100.867    3115.636  1.00
GatherOperationsBenchmark.microByteGather64_MASK          thrpt  30  ops/ms  4096    792.004     832.623  1.05
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF   thrpt  30  ops/ms  64    40417.638   45844.634  1.13
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF   thrpt  30  ops/ms  256   11628.508   12913.170  1.11
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF   thrpt  30  ops/ms  1024   2911.508    3260.388  1.11
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF   thrpt  30  ops/ms  4096    709.017     835.084  1.17
GatherOperationsBenchmark.microByteGather64_NZ_OFF        thrpt  30  ops/ms  64    48868.987   53585.210  1.09
GatherOperationsBenchmark.microByteGather64_NZ_OFF        thrpt  30  ops/ms  256   13617.963   15754.029  1.15
GatherOperationsBenchmark.microByteGather64_NZ_OFF        thrpt  30  ops/ms  1024   3504.745    3857.926  1.10
GatherOperationsBenchmark.microByteGather64_NZ_OFF        thrpt  30  ops/ms  4096    818.439     958.751  1.17
GatherOperationsBenchmark.microShortGather128             thrpt  30  ops/ms  64    41351.719   44337.947  1.07
GatherOperationsBenchmark.microShortGather128             thrpt  30  ops/ms  256   11175.501   12302.557  1.10
GatherOperationsBenchmark.microShortGather128             thrpt  30  ops/ms  1024   2854.546    3158.973  1.10
GatherOperationsBenchmark.microShortGather128             thrpt  30  ops/ms  4096    744.816     790.304  1.06
GatherOperationsBenchmark.microShortGather128_MASK        thrpt  30  ops/ms  64    35012.934   35728.068  1.02
GatherOperationsBenchmark.microShortGather128_MASK        thrpt  30  ops/ms  256    9408.162    9854.849  1.04
GatherOperationsBenchmark.microShortGather128_MASK        thrpt  30  ops/ms  1024   2352.723    2489.161  1.05
GatherOperationsBenchmark.microShortGather128_MASK        thrpt  30  ops/ms  4096    595.827     634.225  1.06
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF thrpt  30  ops/ms  64    31405.646   35728.077  1.13
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF thrpt  30  ops/ms  256    8459.702    9865.482  1.16
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF thrpt  30  ops/ms  1024   2095.461    2489.927  1.18
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF thrpt  30  ops/ms  4096    535.715     631.614  1.17
GatherOperationsBenchmark.microShortGather128_NZ_OFF      thrpt  30  ops/ms  64    39996.604   43811.259  1.09
GatherOperationsBenchmark.microShortGather128_NZ_OFF      thrpt  30  ops/ms  256   11058.636   12261.463  1.10
GatherOperationsBenchmark.microShortGather128_NZ_OFF      thrpt  30  ops/ms  1024   2847.482    3157.450  1.10
GatherOperationsBenchmark.microShortGather128_NZ_OFF      thrpt  30  ops/ms  4096    712.089     790.143  1.10
GatherOperationsBenchmark.microShortGather256             thrpt  30  ops/ms  64    51893.730   51975.295  1.00
GatherOperationsBenchmark.microShortGather256             thrpt  30  ops/ms  256   14226.104   14720.390  1.03
GatherOperationsBenchmark.microShortGather256             thrpt  30  ops/ms  1024   3491.958    3714.266  1.06
GatherOperationsBenchmark.microShortGather256             thrpt  30  ops/ms  4096    852.278     905.330  1.06
GatherOperationsBenchmark.microShortGather256_MASK        thrpt  30  ops/ms  64    38736.351   41797.516  1.07
GatherOperationsBenchmark.microShortGather256_MASK        thrpt  30  ops/ms  256   10250.508   11790.235  1.15
GatherOperationsBenchmark.microShortGather256_MASK        thrpt  30  ops/ms  1024   2558.449    2956.936  1.15
GatherOperationsBenchmark.microShortGather256_MASK        thrpt  30  ops/ms  4096    648.882     745.885  1.14
GatherOperationsBenchmark.microShortGather256_MASK_NZ_OFF thrpt  30  ops/ms  64    38315.594   39547.847  1.03
GatherOperationsBenchmark.microShortGather256_MASK_NZ_OFF thrpt  30  ops/ms  256   10471.955   11779.499  1.12
GatherOperationsBenchmark.microShortGather256_MASK_NZ_OFF thrpt  30  ops/ms  1024   2618.623    2679.970  1.02
GatherOperationsBenchmark.microShortGather256_MASK_NZ_OFF thrpt  30  ops/ms  4096    655.803     760.392  1.15
GatherOperationsBenchmark.microShortGather256_NZ_OFF      thrpt  30  ops/ms  64    47674.080   51325.185  1.07
GatherOperationsBenchmark.microShortGather256_NZ_OFF      thrpt  30  ops/ms  256   13446.700   14438.516  1.07
GatherOperationsBenchmark.microShortGather256_NZ_OFF      thrpt  30  ops/ms  1024   3371.433    3664.720  1.08
GatherOperationsBenchmark.microShortGather256_NZ_OFF      thrpt  30  ops/ms  4096    814.540     895.182  1.09
GatherOperationsBenchmark.microShortGather512             thrpt  30  ops/ms  64    48183.553   48374.790  1.01
GatherOperationsBenchmark.microShortGather512             thrpt  30  ops/ms  256   13669.806   12940.433  0.94
GatherOperationsBenchmark.microShortGather512             thrpt  30  ops/ms  1024   3371.708    3318.627  0.98
GatherOperationsBenchmark.microShortGather512             thrpt  30  ops/ms  4096    847.620     805.313  0.95
GatherOperationsBenchmark.microShortGather512_MASK        thrpt  30  ops/ms  64    39566.443   42845.296  1.08
GatherOperationsBenchmark.microShortGather512_MASK        thrpt  30  ops/ms  256   11926.440   10308.223  0.86
GatherOperationsBenchmark.microShortGather512_MASK        thrpt  30  ops/ms  1024   3008.542    2546.197  0.84
GatherOperationsBenchmark.microShortGather512_MASK        thrpt  30  ops/ms  4096    764.497     647.276  0.84
GatherOperationsBenchmark.microShortGather512_MASK_NZ_OFF thrpt  30  ops/ms  64    38106.800   42835.120  1.12
GatherOperationsBenchmark.microShortGather512_MASK_NZ_OFF thrpt  30  ops/ms  256   10405.171   11125.164  1.06
GatherOperationsBenchmark.microShortGather512_MASK_NZ_OFF thrpt  30  ops/ms  1024   2526.827    2799.209  1.10
GatherOperationsBenchmark.microShortGather512_MASK_NZ_OFF thrpt  30  ops/ms  4096    655.044     715.519  1.09
GatherOperationsBenchmark.microShortGather512_NZ_OFF      thrpt  30  ops/ms  64    48108.682   46654.427  0.96
GatherOperationsBenchmark.microShortGather512_NZ_OFF      thrpt  30  ops/ms  256   13197.197   12957.497  0.98
GatherOperationsBenchmark.microShortGather512_NZ_OFF      thrpt  30  ops/ms  1024   3397.959    3244.415  0.95
GatherOperationsBenchmark.microShortGather512_NZ_OFF      thrpt  30  ops/ms  4096    824.034     820.536  0.99
GatherOperationsBenchmark.microShortGather64              thrpt  30  ops/ms  64    44815.622   46913.289  1.04
GatherOperationsBenchmark.microShortGather64              thrpt  30  ops/ms  256   12317.166   13536.731  1.09
GatherOperationsBenchmark.microShortGather64              thrpt  30  ops/ms  1024   3157.683    3539.991  1.12
GatherOperationsBenchmark.microShortGather64              thrpt  30  ops/ms  4096    775.626     878.304  1.13
GatherOperationsBenchmark.microShortGather64_MASK         thrpt  30  ops/ms  64    37064.157   35649.776  0.96
GatherOperationsBenchmark.microShortGather64_MASK         thrpt  30  ops/ms  256   10120.291   9403.1319  0.92
GatherOperationsBenchmark.microShortGather64_MASK         thrpt  30  ops/ms  1024   2546.723    2642.781  1.03
GatherOperationsBenchmark.microShortGather64_MASK         thrpt  30  ops/ms  4096    644.270     648.432  1.00
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF  thrpt  30  ops/ms  64    34386.819   37883.550  1.10
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF  thrpt  30  ops/ms  256    9316.097   10500.473  1.12
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF  thrpt  30  ops/ms  1024   2344.570    2643.114  1.12
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF  thrpt  30  ops/ms  4096    594.445     595.301  1.00
GatherOperationsBenchmark.microShortGather64_NZ_OFF       thrpt  30  ops/ms  64    40240.772   48435.477  1.20
GatherOperationsBenchmark.microShortGather64_NZ_OFF       thrpt  30  ops/ms  256   11082.392   13736.985  1.23
GatherOperationsBenchmark.microShortGather64_NZ_OFF       thrpt  30  ops/ms  1024   2777.065    3549.704  1.27
GatherOperationsBenchmark.microShortGather64_NZ_OFF       thrpt  30  ops/ms  4096    697.671     877.411  1.25



Note that this patch is splitted from https://github.com/openjdk/jdk/pull/24679. A follow-up PR will implement the SVE subword gather load operations after this PR
is merged.

[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:
 - 8355563: VectorAPI: Refactor current implementation of subword gather load API

Changes: https://git.openjdk.org/jdk/pull/25138/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25138&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355563
  Stats: 441 lines in 15 files changed: 105 ins; 176 del; 160 mod
  Patch: https://git.openjdk.org/jdk/pull/25138.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25138/head:pull/25138

PR: https://git.openjdk.org/jdk/pull/25138

From xgong at openjdk.org  Fri May  9 07:44:27 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 9 May 2025 07:44:27 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API
In-Reply-To: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
Message-ID: <kp-UXohF0tz63v5g_uwAtGhuF8bfFHSJM09f-y5ODps=.f3ed7220-efa6-4093-a22d-e7e2b9a846ad@github.com>

On Fri, 9 May 2025 07:35:41 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]).
> 
> Two key areas require improvement:
> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance.
> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types  increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance.
> 
> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures.
> 
> Main changes:
> 1. Java-side API refactoring:
>    - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on
>      architectures like AArch64.
> 2. C2 compiler IR refactoring:
>    - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types.
> 3. Backend changes:
>    - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level.
> 
> Performance:
> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below:
> 
> Benchmark                                                 Mode   Cnt Unit    SIZE    Before      After    Gain
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  64    53682.012   52650.325  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  256   14484.252   14255.156  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  1024   3664.900    3595.615  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  4096    908.312     935.269  1.02
> GatherOperationsBenchmark.micr...

Hi @eme64 , could you please help take a look at this PR, which is a part of https://github.com/openjdk/jdk/pull/24679 ? Thanks a lot in advance!

Hi @jatin-bhateja , could you please kindly review this PR, especially the X86 codegen part? Thanks a lot in advance!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2865493287
PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2865495716

From pminborg at openjdk.org  Fri May  9 07:50:29 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 9 May 2025 07:50:29 GMT
Subject: RFR: 8356486: ReverseOrderListView should override reversed() to
 return `base` [v2]
In-Reply-To: <X2vnz1BagQ5K7q-2_oHt9X1JjejNJw5TE44vSUJKeaU=.28fad491-d94c-4fcb-9a44-001a62e0beb4@github.com>
References: <X2vnz1BagQ5K7q-2_oHt9X1JjejNJw5TE44vSUJKeaU=.28fad491-d94c-4fcb-9a44-001a62e0beb4@github.com>
Message-ID: <5KUYc9NQofLb7Ma3HLQuglTCcy6lE_3rHqA_Nzh-iPc=.d6de4b73-3bf7-4245-979f-e58b8554df3b@github.com>

> This PR proposed to let `ReverseOrderListView::reversed` directly return `base` instead of going though a more complicated code path.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Remove spurious class
 - Address comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25120/files
  - new: https://git.openjdk.org/jdk/pull/25120/files/546169f4..c21b9108

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25120&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25120&range=00-01

  Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25120.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25120/head:pull/25120

PR: https://git.openjdk.org/jdk/pull/25120

From alanb at openjdk.org  Fri May  9 08:12:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 08:12:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
Message-ID: <togAOydR2ZGmRMpEDKHz7PXzdWIRLYaU6sFIlHUXUw4=.cdb2a446-5f7c-438e-8f1e-2d8bad8c9327@github.com>

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ?  If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865581927

From aph at openjdk.org  Fri May  9 08:28:00 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 9 May 2025 08:28:00 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <nT6D0pn8ukOB8fEymeCgTQz93g_xIA7COYgQyVIHw7E=.fe01335c-3c95-40d8-9b8a-525287ec045f@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
 <nT6D0pn8ukOB8fEymeCgTQz93g_xIA7COYgQyVIHw7E=.fe01335c-3c95-40d8-9b8a-525287ec045f@github.com>
Message-ID: <tiQjg6Rvni0fJX1557KfFYZWy35Zn2k-491gLESdQEI=.6f8ff4e8-94c1-4a78-9b97-9e0cc82acb0b@github.com>

On Thu, 8 May 2025 18:18:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> I noted that `ThreadFlock` is using scoped values but throwing `StructureViolationException` introduced by structured concurrency - is it considered an implementation artifact and part of structured concurrency instead?
> 
> Context: test/jdk/jdk/internal/misc/ThreadFlock/WithScopedValue.java

That's an interesting question that I'll leave to @AlanBateman .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2865632535

From godmlzkf1 at naver.com  Fri May  9 08:31:21 2025
From: godmlzkf1 at naver.com (=?utf-8?B?7J6E66+87IiY?=)
Date: Fri, 09 May 2025 17:31:21 +0900
Subject: =?utf-8?B?VW5uZWNlc3NhcnkgbG9naWMgaXMgYWRkZWQgdG8gcmVtb3ZlRmlyc3QgYW5kIHJlbW92ZQ==?=
 =?utf-8?B?TGFzdCBvZiBBcnJheUxpc3Qu?=
Message-ID: <7e491593f46d08db170661bf75f8f15@cweb006.nm>

Hi.

In removeFirst, if size is not 0, the logic is the same as the remove logic.

removeLast also has the same logic as remove when size is not exceeded.

I want to fix this.

thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250509/ba3d7a41/attachment-0001.htm>

From vyazici at openjdk.org  Fri May  9 08:31:35 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 9 May 2025 08:31:35 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v4]
In-Reply-To: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
Message-ID: <EBXXrcYB3HoB7nEMu434D4-pr9L7L-jySD-JX4o28so=.7a6632a7-fb92-4b07-80af-696df33a2815@github.com>

> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright years

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24982/files
  - new: https://git.openjdk.org/jdk/pull/24982/files/4d237efa..121005ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=02-03

  Stats: 14 lines in 14 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/24982.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24982/head:pull/24982

PR: https://git.openjdk.org/jdk/pull/24982

From vyazici at openjdk.org  Fri May  9 08:31:38 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 9 May 2025 08:31:38 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v3]
In-Reply-To: <X4qAmXI_8QngD0dLGKblYZVwileF21OQ31ermPeS3F0=.0ca215ee-c41e-411d-b5ba-2b9714c84e92@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <vfrf8Cx8oHAF4JpUITn4iqppXgIKVXzWBKojA_t4TqE=.8fb827e3-e60d-42e4-919b-f18f310694bf@github.com>
 <X4qAmXI_8QngD0dLGKblYZVwileF21OQ31ermPeS3F0=.0ca215ee-c41e-411d-b5ba-2b9714c84e92@github.com>
Message-ID: <LfttRWeTY56EQm1dFWGdxLh_zN8ESg7eDpkMivbyn1w=.a761b77e-ea23-4f24-83f7-0b0f1e9ffa28@github.com>

On Thu, 8 May 2025 14:46:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Prefix touched methods with `unchecked`
>
> src/java.base/share/classes/java/io/DataInputStream.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/java/io/ObjectInputStream.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/java/util/HexFormat.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/java/util/zip/ZipCoder.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/sun/nio/cs/CESU_8.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/sun/nio/cs/DoubleByte.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/sun/nio/cs/SingleByte.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/sun/nio/cs/US_ASCII.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/sun/nio/cs/UTF_8.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190069
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190301
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190552
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190701
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190811
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190928
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081191033
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081191280
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081191511
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081191686
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081191903
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081192125
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081192310
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081192487

From lkorinth at openjdk.org  Fri May  9 08:32:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:32:55 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <uabWdORniwCo0BELgwEHL9xwszL7WvN02cMLTu253K4=.de2529aa-23d2-4c86-9133-504f4146c93e@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I feel almost all of the comments raised here are for me changing the timeout factor to `1`. I will try to answer those questions here as well, but note that the timeout factor is not to be changed to `1` in this pull request and will remain 4, so excluding bugs I might have introduced, tiers would --- if anything --- be running more stable after the change as I have only increased timeouts.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865644966

From alanb at openjdk.org  Fri May  9 08:32:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 08:32:57 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <dFux5Ige8612jyYeGHCX-gFS_grEz7AJC_0T337pvDk=.4a59627c-7100-452c-aa49-8c0295c1ae06@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
 <dFux5Ige8612jyYeGHCX-gFS_grEz7AJC_0T337pvDk=.4a59627c-7100-452c-aa49-8c0295c1ae06@github.com>
Message-ID: <N7XVebZ3fAxePrUsXVkQqUU-koehhmX-hVXevzK0tlM=.bb56e3f8-e79e-48ac-be82-45429dcaf714@github.com>

On Fri, 9 May 2025 08:28:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix merge
>
>> I'm getting a test failure in [ClassFileVersionTest.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java#45) because `ScopedValue` is not a Preview API. Should I just fix the test to use some other Preview Class?
> 
> Chen offered to change this test to use the ClassFile API and construct the class with the preview minor number. The PR to change this test is reviewed so I think all good, nothing more to do here.

> That's an interesting question that I'll leave to @AlanBateman .

Nothing to do as the test uses StructureViolationException so needs to continue to be compile/run with preview features enabled.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2865643883

From alanb at openjdk.org  Fri May  9 08:32:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 08:32:56 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
Message-ID: <dFux5Ige8612jyYeGHCX-gFS_grEz7AJC_0T337pvDk=.4a59627c-7100-452c-aa49-8c0295c1ae06@github.com>

On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge

> I'm getting a test failure in [ClassFileVersionTest.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java#45) because `ScopedValue` is not a Preview API. Should I just fix the test to use some other Preview Class?

Chen offered to change this test to use the ClassFile API and construct the class with the preview minor number. The PR to change this test is reviewed so I think all good, nothing more to do here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2865640747

From vyazici at openjdk.org  Fri May  9 08:33:58 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 9 May 2025 08:33:58 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v3]
In-Reply-To: <X4qAmXI_8QngD0dLGKblYZVwileF21OQ31ermPeS3F0=.0ca215ee-c41e-411d-b5ba-2b9714c84e92@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <vfrf8Cx8oHAF4JpUITn4iqppXgIKVXzWBKojA_t4TqE=.8fb827e3-e60d-42e4-919b-f18f310694bf@github.com>
 <X4qAmXI_8QngD0dLGKblYZVwileF21OQ31ermPeS3F0=.0ca215ee-c41e-411d-b5ba-2b9714c84e92@github.com>
Message-ID: <q9rYAmT6pK95rVa7MMtLTI8kUXWpiQxAp3kwpCFDeP4=.7123fa9f-2908-4a72-8c55-863dc62e0fa0@github.com>

On Thu, 8 May 2025 14:51:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Prefix touched methods with `unchecked`
>
> Let's re-approve after copyright fix.

@liach, @minborg, I've fixed the copyright years. I'd appreciate it if you can approve one last time.

This last copyright year fiasco made me do this:


alias git-license-year-violations='git diff --name-only upstream/master...HEAD | { y=$(date +%Y); while read f; do grep -qE "Copyright \(c\)( [0-9]{4},)? $y, Oracle" $f || echo $f; done; }'

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24982#issuecomment-2865648371

From godmlzkf1 at naver.com  Fri May  9 08:33:30 2025
From: godmlzkf1 at naver.com (=?utf-8?B?7J6E66+87IiY?=)
Date: Fri, 09 May 2025 17:33:30 +0900
Subject: =?utf-8?B?VW5uZWNlc3NhcnkgbG9naWMgaXMgYWRkZWQgdG8gcmVtb3ZlRmlyc3QgYW5kIHJlbW92ZQ==?=
 =?utf-8?B?TGFzdCBvZiBBcnJheUxpc3Qu?=
Message-ID: <7761d3554e8cd5fd861579a4fe705044@cweb008.nm>

Hi.

In removeFirst, if size is not 0, the logic is the same as the remove logic.

removeLast also has the same logic as remove when size is not exceeded.

I want to fix this.

thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250509/f4bc06f4/attachment-0001.htm>

From pminborg at openjdk.org  Fri May  9 08:38:39 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 9 May 2025 08:38:39 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v11]
In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
Message-ID: <MKvEHFjWiwXZgK18PPNT8MsstvuP8bL9QFDAPYYC0BE=.a222b97c-c722-4189-8175-4353a7d61eaa@github.com>

> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.

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 24 additional commits since the last revision:

 - Revert unintended change
 - Revert unintended change
 - Remove unused factories and add comment
 - Merge branch 'master' into stable-updaters
 - Add composition of functions and MHs
 - Revert changes in stable classes
 - Add lazy CallSite methods
 - Reformat
 - Add convenience methods and documentations
 - Add low level variants
 - ... and 14 more: https://git.openjdk.org/jdk/compare/6916dfd3...9a58db6a

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25040/files
  - new: https://git.openjdk.org/jdk/pull/25040/files/1628b264..9a58db6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25040&range=09-10

  Stats: 3102 lines in 128 files changed: 2035 ins; 528 del; 539 mod
  Patch: https://git.openjdk.org/jdk/pull/25040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25040/head:pull/25040

PR: https://git.openjdk.org/jdk/pull/25040

From pminborg at openjdk.org  Fri May  9 08:38:39 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 9 May 2025 08:38:39 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v10]
In-Reply-To: <K-tpXpxA22SjlA8AaNr-eVfLlKdRhy8tuclOw_xEkRc=.62f4eee3-e95b-47fc-9848-cd567f4174f4@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <w3MMw5Cgcq8gTBYPG_uhvGujd42WZS9qjXQIw1FgINg=.de6593f1-470c-4bf1-a8b9-7aaae38ffb94@github.com>
 <K-tpXpxA22SjlA8AaNr-eVfLlKdRhy8tuclOw_xEkRc=.62f4eee3-e95b-47fc-9848-cd567f4174f4@github.com>
Message-ID: <3Nb4WpG8VD6QdUuloCkv5v5MClYc-LU6PAbiZ_eOs54=.2c55b650-fe76-4494-bea9-706020015ccf@github.com>

On Thu, 8 May 2025 15:28:20 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add composition of functions and MHs
>
> test/jdk/java/lang/StableValue/StableFieldUpdaterExampleTest.java line 183:
> 
>> 181:     static
>> 182: 
>> 183:     public final class MhFoo {
> 
> I'm assuming this is explicitly the "behind the scenes" raw version of it in case anyone want's to step off the well-lit path. Hard to comment without seeing any surrounding docs. I don't suppose a link to the docs in which these are given can be added (just to give context for future maintainers)?

I have removed the unchecked factories now. I do not think we need them, and if we do, we could always add them back later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2081205297

From lkorinth at openjdk.org  Fri May  9 08:42:58 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:42:58 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
Message-ID: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>

On Fri, 9 May 2025 07:14:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thank you. I have imported your PR locally and running some HTTP client tests in the CI. Tests have not finished running - but I already see one intermittent failure: `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows. It would be good to flush out any such intermittent failures before this PR is integrated. This might require multiple runs before we can get confidence.

My change of timeout factor to `0.7` is only temporal, as I said: it will be reverted to `4` before integration. Naturally, a few test cases will timeout when I do this /temporal/ change, hopefully `java/net/httpclient/RedirectTimeoutTest.java` will behave well with a timeout factor of `1` instead of `0.7`, but note that I will revert the timeout factor to `4` before integration. 

The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865685066

From stefank at openjdk.org  Fri May  9 08:48:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 08:48:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
Message-ID: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.

Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865697701

From raffaello.giulietti at oracle.com  Fri May  9 08:55:38 2025
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Fri, 9 May 2025 10:55:38 +0200
Subject: Unnecessary logic is added to removeFirst and removeLast of
 ArrayList.
In-Reply-To: <7e491593f46d08db170661bf75f8f15@cweb006.nm>
References: <7e491593f46d08db170661bf75f8f15@cweb006.nm>
Message-ID: <a0044fab-93d5-427e-856b-db7219dea885@oracle.com>

Hi,

when the size if not zero, the logic in removeFirst() avoids an index 
check, which however must be enforced in remove(int).

There's no need for a "fix".


On 2025-05-09 10:31, ??? wrote:
> Hi.
> 
> In removeFirst, if size is not 0, the logic is the same as the remove logic.
> 
> removeLast also has the same logic as remove when size is not exceeded.
> 
> I want to fix this.
> 
> thank you.
> 


From lkorinth at openjdk.org  Fri May  9 09:02:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:02:55 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
Message-ID: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>

On Thu, 8 May 2025 20:00:21 GMT, Phil Race <prr at openjdk.org> wrote:

> test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
>     * * @run main/timeout=300/othervm MTTest
> 
> 
>     * * @run main/timeout=1200/othervm MTTest
> 
> 
> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
> 
> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
> So 300 was fine, and 1200 isn't needed.

I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865742871

From ihse at openjdk.org  Fri May  9 09:09:02 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 09:09:02 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v6]
In-Reply-To: <tBEVMB0n8bNbzfjJy7jgJUxOa0Z-4OojY27IiXoxci8=.eec6f271-a45c-47f7-9f20-9ca219f1faea@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <tBEVMB0n8bNbzfjJy7jgJUxOa0Z-4OojY27IiXoxci8=.eec6f271-a45c-47f7-9f20-9ca219f1faea@github.com>
Message-ID: <YuqyLDE7wSJcsedHIHISMEw_2b31nTcosz7H1jqifjQ=.03fcaa89-eea3-4b20-8901-7f69345498ff@github.com>

On Thu, 8 May 2025 10:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into go-full-utf8
>  - Merge branch 'master' into go-full-utf8
>  - Add informative message  about supported locales.
>  - Allow C locale with warning instead of fatal error
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim
>  - Also tell javadoc that we have utf-8 now
>  - Fix flags for Windows
>  - Mark java and native source code as utf-8
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/2c1eb339...e68305db

It seems to be difficult to find someone to get this tested on a Chinese locale on Windows. I'll integrate this, and handle any problems that might arise as followups.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2865761193

From ihse at openjdk.org  Fri May  9 09:09:03 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 09:09:03 GMT
Subject: Integrated: 8301971: Make JDK source code UTF-8
In-Reply-To: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
Message-ID: <1fDziF7qdWQ1gvZZ2pPh0MYEqRKAS0w3lPQbuYVUOa0=.f9283dc7-b8a0-4bfc-8dd5-4d124b225aa1@github.com>

On Thu, 10 Apr 2025 14:28:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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).

This pull request has now been integrated.

Changeset: 3aa2ea7e
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3aa2ea7e67c879dafa0f967073c2d8b98d62c996
Stats:     177 lines in 13 files changed: 49 ins; 105 del; 23 mod

8301971: Make JDK source code UTF-8
8338973: Document need to have UTF-8 locale available to build the JDK

Reviewed-by: erikj, naoto, mbaesken

-------------

PR: https://git.openjdk.org/jdk/pull/24574

From lkorinth at openjdk.org  Fri May  9 09:12:19 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:12:19 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
Message-ID: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>

On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> - * @run main/timeout=300/othervm MTTest
>> + * @run main/timeout=1200/othervm MTTest
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
>
>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>>     * * @run main/timeout=300/othervm MTTest
>> 
>> 
>>     * * @run main/timeout=1200/othervm MTTest
>> 
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
> 
> I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

> @lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ? If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change if the scaling is adjusted in the future. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

The code was run as it currently looks (with a timeout factor of `0.7`), what timeout factor do you think I should use to test, and for how many times?

At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to `1` will happen after the fork.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865784064

From alanb at openjdk.org  Fri May  9 09:12:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 09:12:59 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v3]
In-Reply-To: <Qix6nH8PKCQyILYVg6cJ9VwGwMQghcq6l7A-gS9QWCI=.37745fda-d30e-401d-9bd8-3ab81e6be67e@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <BO3XKg8xPmBsT_cw8N0qZNVCfw2YhtDTtLB4JBT_Mzg=.853a33c5-7c69-4a48-a146-8e64c2bb14d7@github.com>
 <NKxCgSN5nElChgTRYL9xg8oa7pVlyXmafNFhkG3nuw0=.370e9b03-9af0-479a-9006-f89143300ae3@github.com>
 <Mkg-QGSATre8fW8iLj5wk4Ywti6vaIZVNPGQXOr7nWw=.63450aad-474d-4dfc-b9ec-6461cebd6a22@github.com>
 <iyXlIOMdtX9Tc4ku1ho8XOzdQJI_T4W4Qj-JQaO1hMc=.a2a4f4ea-b0ec-41db-90f6-2276439390f1@github.com>
 <Qix6nH8PKCQyILYVg6cJ9VwGwMQghcq6l7A-gS9QWCI=.37745fda-d30e-401d-9bd8-3ab81e6be67e@github.com>
Message-ID: <rqRYQYzJUqaM2GQ-8T04L_iZQuIFqKEqR7INmQsMxQI=.7263e67e-50af-4a93-b666-439a934930ae@github.com>

On Thu, 8 May 2025 19:39:17 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

>> The appending of the "." is specific to the case where there isn't a .dll suffix.
>
> `LoadLibrary` appears to happily load files with a `.dll` extension even if a trailing `.` is appended. So, special casing doesn't appear necessary.

Is this documented in the Microsoft document for LoadLibrary? We don't want to rely on undocumented behavior as it could break at any time.

For the prototype, I think you can replace nativeLoaderFileNameSuffix() with mapToNativeLibraryName(String) so that other platforms can "return this". This would give the flexibility to prefix or do other mangling.

That said, I'm not so sure that we should changing the JDK to work in this unusual environment. Are you able to name the product that is move-renaming the DLLs and replacing them with sym links? Just trying to get some sense as to whether this is something that many people might run into it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24694#discussion_r2081271000

From cstein at openjdk.org  Fri May  9 09:15:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 09:15:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
 <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
Message-ID: <LWO7Q1kcmK2ygzbo5WovS47Dbuj_vfNTrTCvtPe8eLs=.4247df94-1d6d-4be7-bd56-77257bea18f7@github.com>

On Fri, 9 May 2025 09:09:34 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to 1 will happen after the fork.

Note, that I moved the timeout configuration feature to `jtreg` 7.5.2 - which will be released soon.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865793769

From lkorinth at openjdk.org  Fri May  9 09:15:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:15:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
Message-ID: <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>

On Fri, 9 May 2025 08:45:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> 
> Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865794195

From stefank at openjdk.org  Fri May  9 09:19:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 09:19:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
 <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>
Message-ID: <rN9e2v3Ja1Kz4w4CsS6pDyFKNs88tAacAG4wiwWaK6w=.abf1d75b-861b-4de9-8e7b-61deca3e5e05@github.com>

On Fri, 9 May 2025 09:13:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> > > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> > 
> > 
> > Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?
> 
> I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

I understand the risk of being blocked on JDK-8260555, but frankly, if someone wants to block the change from 4 to 1 I'm not sure this PR is worth doing. We have enough groups represented in this PR so let's ask here: is anyone is opposing the idea of JDK-8260555?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865804474

From vklang at openjdk.org  Fri May  9 09:23:56 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 9 May 2025 09:23:56 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v11]
In-Reply-To: <MKvEHFjWiwXZgK18PPNT8MsstvuP8bL9QFDAPYYC0BE=.a222b97c-c722-4189-8175-4353a7d61eaa@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <MKvEHFjWiwXZgK18PPNT8MsstvuP8bL9QFDAPYYC0BE=.a222b97c-c722-4189-8175-4353a7d61eaa@github.com>
Message-ID: <EsF1SXrga_auIgU7znNHoZQ2ElfTY2HMRSDqMfpU5zE=.faf77acc-3eb9-46cf-beb9-773acf27bc50@github.com>

On Fri, 9 May 2025 08:38:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`.
>
> 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 24 additional commits since the last revision:
> 
>  - Revert unintended change
>  - Revert unintended change
>  - Remove unused factories and add comment
>  - Merge branch 'master' into stable-updaters
>  - Add composition of functions and MHs
>  - Revert changes in stable classes
>  - Add lazy CallSite methods
>  - Reformat
>  - Add convenience methods and documentations
>  - Add low level variants
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/a3634a30...9a58db6a

src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 697:

> 695:                 return f;
> 696:             }
> 697:         }

Is there a specific reason not to use `Class::getDeclaredField(name)`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2081288110

From pminborg at openjdk.org  Fri May  9 09:34:00 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 9 May 2025 09:34:00 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
In-Reply-To: <Rlf0LO25ddjS7CZQ7IIBCiwEhP-bFt_vJoODV7MFzSA=.76c65b2c-d478-4aa4-ba5f-bd25273d04b2@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
 <Rlf0LO25ddjS7CZQ7IIBCiwEhP-bFt_vJoODV7MFzSA=.76c65b2c-d478-4aa4-ba5f-bd25273d04b2@github.com>
Message-ID: <ZSsYncqk1LPn6uuQ4Qt4PPnd7tecMSBITI29n0SdAl4=.bae840de-cca1-4054-9d86-baf77ed4dd1f@github.com>

On Thu, 8 May 2025 16:08:24 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
>> 
>> Unfortunately, this PR shows the total commit history for stable values.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 954:
> 
>> 952:                 return deepRoot(sub.root);
>> 953:             }
>> 954:             throw new InternalError("Should not reach here: " + list.getClass().getName());
> 
> Does this need to be recursive? There is logic to avoid nesting of sublists, and a sublist of a reversed view should end up being a reversed view of a sublist, so the most deep nesting that can occur is reversed(sublist(base)).

Actually, this introduces a bug. If there is a reversed(sublist(base)) op, then the sublist is disregarded. So we need to remove this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2081303938

From dfuchs at openjdk.org  Fri May  9 09:33:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 09:33:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
Message-ID: <vhPQ5uxCX4mkm_a34_Elnbjxazr49tOXu_ezw8YbY_g=.81d3c926-7a82-4f4a-95b2-336c63350801@github.com>

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE)

Yes - I understand. My point is that there are probably more tests that will need an extended timeout than those that you have already modified. And we want to find out which before the actual change from 4 to 1.0. IMO if a test fails intermittently with 0.7, it's a good indication that it might continue failling intermittently with 1.0, and therefore it should be updated in this PR too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865849069

From duke at openjdk.org  Fri May  9 09:40:54 2025
From: duke at openjdk.org (erifan)
Date: Fri, 9 May 2025 09:40:54 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v5]
In-Reply-To: <huhJ3Yq2fj9CJGBAqQFZxd8i0Wjnwad3moNHymXKyy8=.d64a2532-6bd5-4e58-84ee-18f682d7fe20@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <huhJ3Yq2fj9CJGBAqQFZxd8i0Wjnwad3moNHymXKyy8=.d64a2532-6bd5-4e58-84ee-18f682d7fe20@github.com>
Message-ID: <KUTHBhWhy5WCrwrSIz1qPNqs0g-vS5sFjsp440djxf4=.ae77d669-c561-4648-99c9-c099fe1e9938@github.com>

On Wed, 7 May 2025 02:10:56 GMT, erifan <duke at openjdk.org> wrote:

>> This patch optimizes the following patterns:
>> For integer types:
>> 
>> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> 
>> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond.
>> 
>> For float and double types:
>> 
>> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> 
>> cond can be eq or ne.
>> 
>> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`:
>> 
>> Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>> testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>> testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>> testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>> testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>> testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>> testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>> testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>> testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>> testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
>> testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
>> testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
>> testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
>> testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
>> testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
>> testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
>> testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
>> testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
>> testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
>> testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
>> testCompareLTMaskNotInt		ops/s	16721...
>
> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Refactor code
>    
>    Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
>    optimization, making the code more modular.
>  - Merge branch 'master' into JDK-8354242
>  - Update the jtreg test
>  - Merge branch 'master' into JDK-8354242
>  - Addressed some review comments
>    
>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>    2. Improve code comments.
>  - Merge branch 'master' into JDK-8354242
>  - Merge branch 'master' into JDK-8354242
>  - 8354242: VectorAPI: combine vector not operation with compare
>    
>    This patch optimizes the following patterns:
>    For integer types:
>    ```
>    (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>        => (VectorMaskCmp src1 src2 ncond)
>    (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>        => (VectorMaskCmp src1 src2 ncond)
>    ```
>    cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>    negative comparison of cond.
>    
>    For float and double types:
>    ```
>    (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>    (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>    ```
>    cond can be eq or ne.
>    
>    Benchmarks on Nvidia Grace machine with 128-bit SVE2:
>    With option `-XX:UseSVE=2`:
>    ```
>    Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>    testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>    testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>    testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>    testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>    testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>    testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>    testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>    testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>    testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
>    testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4...

I'll update the code next week, thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-2865870304

From duke at openjdk.org  Fri May  9 09:40:55 2025
From: duke at openjdk.org (erifan)
Date: Fri, 9 May 2025 09:40:55 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v5]
In-Reply-To: <F6ofKcqVvH3NUwDokqmyIw823V1u6GGlAMdMCxJLtek=.433a6406-1ba0-4a58-b9a3-fde97d8f515d@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <huhJ3Yq2fj9CJGBAqQFZxd8i0Wjnwad3moNHymXKyy8=.d64a2532-6bd5-4e58-84ee-18f682d7fe20@github.com>
 <ItOPWOS6VHofCe7QYcIqnq0yCi-dXfEri_45HgrjfYY=.285d15ff-5b15-4a21-8a7c-1e4cabcc33b2@github.com>
 <Jzqyfc2xxJRBY2ppai7XpFKaWS7y3CsnP4Y547KHq6o=.d482f244-a9dd-4ac4-a082-0b3180c1caad@github.com>
 <gs98vNywMgB3pEcq_Bfv_jhLBiH7KS_1NhHGprSCtLs=.cd43836c-5de3-4642-afa1-1a5a04f0b17b@github.com>
 <F6ofKcqVvH3NUwDokqmyIw823V1u6GGlAMdMCxJLtek=.433a6406-1ba0-4a58-b9a3-fde97d8f515d@github.com>
Message-ID: <uuIl_bBnVxLkKQ56E3xlJ9DefFBQKDYtoe-Gs4ZXYyo=.7cfbe1c9-8f0d-4432-a376-d81cc961dc4a@github.com>

On Thu, 8 May 2025 01:49:45 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Yes, that's the right approach. For this PR, I think you can mix some test points covering compare, xor(maskAll(true)).
>
> Yes, converting `VectorMask.fromLong(SPECIES, -1L)` to `MaskAll()` would be better, and that will benefit AArch64 as well, since `MaskAll()` is much more cheaper than `fromLong()` on AArch64. We can add such a transformation with another PR.

Ok, I'll extend the test to xor(maskAll(true) in the next commit, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2081313613

From duke at openjdk.org  Fri May  9 09:49:56 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Fri, 9 May 2025 09:49:56 GMT
Subject: RFR: 8356255: Add Stable Field Updaters to allow efficient lazy
 field evaluations [v11]
In-Reply-To: <EsF1SXrga_auIgU7znNHoZQ2ElfTY2HMRSDqMfpU5zE=.faf77acc-3eb9-46cf-beb9-773acf27bc50@github.com>
References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com>
 <MKvEHFjWiwXZgK18PPNT8MsstvuP8bL9QFDAPYYC0BE=.a222b97c-c722-4189-8175-4353a7d61eaa@github.com>
 <EsF1SXrga_auIgU7znNHoZQ2ElfTY2HMRSDqMfpU5zE=.faf77acc-3eb9-46cf-beb9-773acf27bc50@github.com>
Message-ID: <DyOTMoXXUwxBqUavqRB8p9vycpXjExMMtBTd44mAb84=.247bf0d6-9495-4bcd-933d-02afaa49b7d8@github.com>

On Fri, 9 May 2025 09:21:14 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> 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 24 additional commits since the last revision:
>> 
>>  - Revert unintended change
>>  - Revert unintended change
>>  - Remove unused factories and add comment
>>  - Merge branch 'master' into stable-updaters
>>  - Add composition of functions and MHs
>>  - Revert changes in stable classes
>>  - Add lazy CallSite methods
>>  - Reformat
>>  - Add convenience methods and documentations
>>  - Add low level variants
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/b9531363...9a58db6a
>
> src/java.base/share/classes/jdk/internal/lang/stable/StableFieldUpdater.java line 697:
> 
>> 695:                 return f;
>> 696:             }
>> 697:         }
> 
> Is there a specific reason not to use `Class::getDeclaredField(name)`?

Class::getDeclaredField(name) throws NoSuchFieldException if not found.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25040#discussion_r2081336037

From ihse at openjdk.org  Fri May  9 10:04:09 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 10:04:09 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters [v3]
In-Reply-To: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
Message-ID: <OaO3i0WE6Wt6FDeg9Chm58zh4Vg-jJ5oMOkpvc0PRhA=.208dfa65-1b75-4952-9a65-c326b1118c06@github.com>

> 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.

Magnus Ihse Bursie has updated the pull request with a new target base 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 unicode-sequence-in-comments
 - Merge branch 'master' into unicode-sequence-in-comments
 - 8354968: Replace unicode sequences in comment text with UTF-8 characters

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24727/files
  - new: https://git.openjdk.org/jdk/pull/24727/files/694b33dc..dd9a77c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24727&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24727&range=01-02

  Stats: 14771 lines in 491 files changed: 7892 ins; 4380 del; 2499 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 ihse at openjdk.org  Fri May  9 10:12:09 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 10:12:09 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters [v4]
In-Reply-To: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
Message-ID: <jYgZalrJrqF2-_kpxuxClN3v--h0fBc7QHn2urj-TP0=.d204338a-e538-47b8-8055-f0d840401fe2@github.com>

> 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.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Clarify non-ASCII characters with unicode code point

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24727/files
  - new: https://git.openjdk.org/jdk/pull/24727/files/dd9a77c5..53aa4066

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24727&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24727&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 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 ihse at openjdk.org  Fri May  9 10:12:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 10:12:12 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters [v2]
In-Reply-To: <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
 <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>
 <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>
Message-ID: <T7BaCfqTjE-a2Soo1fPYD3PnJ64bsS-YM27NLwxcuKY=.aa500d13-5cad-4bea-aaa5-c94f7118b21b@github.com>

On Tue, 6 May 2025 17:16:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base 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 unicode-sequence-in-comments
>>  - 8354968: Replace unicode sequences in comment text with UTF-8 characters
>
> src/java.base/share/classes/java/text/RuleBasedCollator.java line 594:
> 
>> 592:         // a three-digit number, one digit for primary, one for secondary, etc.
>> 593:         //
>> 594:         // String:              A     a     B   ?
> 
> Maybe "? (\u00e9, e-acute)"?

I used the `U+` code point notation here as well. I think that is better to make sure there are no misunderstandings, and no risk of the escaped character inadvertently being converted into an actual unicode character down the line by processors.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2081372676

From nbenalla at openjdk.org  Fri May  9 10:34:52 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 9 May 2025 10:34:52 GMT
Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal
In-Reply-To: <sW8AgNknCFUnkZKAns3Pvm-jbPS2XomYipktJhJNxIs=.1f4cddb5-675c-4be9-a7f2-953511f0abdf@github.com>
References: <sW8AgNknCFUnkZKAns3Pvm-jbPS2XomYipktJhJNxIs=.1f4cddb5-675c-4be9-a7f2-953511f0abdf@github.com>
Message-ID: <mGKvcmMbSiIrN6z5L9iq7Sb1HQ0D1ZxnQ9sN5JXAApk=.48c6dc9b-62e4-4c5f-989e-a258ddcf69fa@github.com>

On Thu, 8 May 2025 21:07:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix javadoc tags.

I just noticed there are a couple more javadoc tags that need to be fixed in this class, I still see two more warnings. I should have included these in the JBS issue when filling it.


src/java.base/share/classes/java/math/BigDecimal.java:363: warning: reference to non-visible type: BigDecimal.scale (use -protected or -private options to document non-public types)
     * The scale of this BigDecimal, as returned by {@link #scale}.
                                                    ^
src/java.base/share/classes/java/math/BigDecimal.java:366: warning: reference to non-visible type: BigDecimal.scale (use -protected or -private options to document non-public types)
     * @see #scale
       ^
       ```

-------------

Changes requested by nbenalla (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25131#pullrequestreview-2827841653

From ihse at openjdk.org  Fri May  9 10:47:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 10:47:53 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters [v4]
In-Reply-To: <jYgZalrJrqF2-_kpxuxClN3v--h0fBc7QHn2urj-TP0=.d204338a-e538-47b8-8055-f0d840401fe2@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
 <jYgZalrJrqF2-_kpxuxClN3v--h0fBc7QHn2urj-TP0=.d204338a-e538-47b8-8055-f0d840401fe2@github.com>
Message-ID: <xA7HUgNAtNicDp0v65bJcACLZBbMCZQjiUgARidIM0U=.fac13cc3-1cb0-4b99-a514-8584238d7ff0@github.com>

On Fri, 9 May 2025 10:12:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> 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.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify non-ASCII characters with unicode code point

Now that [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971) is committed, this PR is ready to be integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24727#issuecomment-2866080024

From asemenyuk at openjdk.org  Fri May  9 11:44:55 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 9 May 2025 11:44:55 GMT
Subject: RFR: 8333664: Decouple command line parsing and package building in
 jpackage
Message-ID: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>

Refactor jpackage to separate the configuration and execution phases.
At the configuration phase, jpackage parses command-line arguments and validates them.
At the execution phase, jpackage builds a bundle based on data collected at the configuration phase.

There was no clear separation between these phases. Both used the same data type (`Map<String, Object>`), making it hard to understand and use properly.

This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling.

The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map<String, Object>` "params".

Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers.

**Functional changes**
jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below.

 - Minimize copying of the source app image when doing native packaging.

Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations.

- PKG bundler: change "preinstall" and "postinstall" scripts in app bundles.

post- and pre- install PKG scripts for SimplePackageTest package before and after the change:
<table>
<thead>
<tr>
<th>Script</th>
<th>New</th>
<th>Old</th>
</tr>
</thead>
<tbody>
<tr>
<td nowrap>preinstall</td>
<td>
<pre>
#!/usr/bin/env sh<br>
if [ ! -d "/Applications/SimplePackageTest.app" ]
then
    mkdir -p "/Applications/SimplePackageTest.app"
fi<br>
exit 0
</pre>
</td>
<td>
<pre>
#!/usr/bin/env sh<br>
if [ ! -d "/Applications" ]
then
    mkdir -p "/Applications"
fi<br>
exit 0
</pre>
</td>
</tr>
<tr>
<td nowrap>postinstall</td>
<td>
<pre>
#!/usr/bin/env sh<br>
chown root:wheel "/Applications/SimplePackageTest.app"
chmod a+rX "/Applications/SimplePackageTest.app"
chmod +r "/Applications/SimplePackageTest.app/Contents/app/"*.jar<br>
exit 0
</pre>
</td>
<td>
<pre>
#!/usr/bin/env sh<br>
chown root:wheel "/Applications"
chmod a+rX "/Applications"
chmod +r "/Applications/SimplePackageTest.app/Contents/app/"*.jar<br>
exit 0
</pre>
</td>
</tr>
</tbody>
</table>

This change relates to the [JDK-8356047](https://bugs.openjdk.org/browse/JDK-8356047) issue. Although the scripts are different, they are functionally identical (they don't change anything in the system).

- PKG bundler: no "postinstall" and "preinstall" scripts in runtime bundles.

jpackage will not create post- and pre- install scripts in runtime PKGs. This doesn't make a difference as runtime bundling on macOS is currently broken, see [JDK-8351073](https://bugs.openjdk.org/browse/JDK-8351073) issue.

- macOS signing.

Use `java.security.cert.X509Certificate` class to parse the signing certificates data instead of "/usr/bin/openssl" invocations.

To identify the certificate unambiguously, the certificate's SHA1 hash is passed as a value of the "-s" parameter for codesign instead of the certificate name.

**Testing**
With these significant code changes, ensuring that jpackage still produces packages with the same properties for the given input was essential.

jpackage uses external tools for building packages, supplying them with the configuration files. Assuming that a packaging tool would produce the same package for the given configuration files, these configuration files created by the "old" jpackage and the "new" jpackage in every jpackage test were examined and verified for no substantial differences. ConfigFilesStasher.java and clean_stashed_files.sh tools served this purpose. Thanks to this way to test jpackage, [JDK-8356219](https://bugs.openjdk.org/browse/JDK-8356219) was uncovered.

-------------

Commit messages:
 - Add ConfigFilesStasher that allows to save contents of jpackage build directories in external directory; Add clean_stashed_files.sh
 - Merge branch 'master' into JDK-8333664
 - 8333568: Test that jpackage doesn't modify R/O files/directories
 - 8356562: SigningAppImageTwoStepsTest test fails
 - Remove clean_stashed_files.sh
 - OSVersionCondition: bugfix; CfgFile: minor; signing: fix entitlements
 - Merge branch 'master' into JDK-8333664
 - Merge branch 'master' into JDK-8333664
 - Fix FA tests
 - Add missing default jlink options
 - ... and 497 more: https://git.openjdk.org/jdk/compare/cc3a366e...9776f496

Changes: https://git.openjdk.org/jdk/pull/19668/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19668&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333664
  Stats: 23913 lines in 194 files changed: 17144 ins; 5680 del; 1089 mod
  Patch: https://git.openjdk.org/jdk/pull/19668.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19668/head:pull/19668

PR: https://git.openjdk.org/jdk/pull/19668

From asemenyuk at openjdk.org  Fri May  9 11:44:55 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 9 May 2025 11:44:55 GMT
Subject: RFR: 8333664: Decouple command line parsing and package building
 in jpackage
In-Reply-To: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>
References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>
Message-ID: <akN1zjxS5-DJYHava0ck5zP9ZvV4NlS4PB0_y18CkHo=.31f87c74-c8a3-4904-bc8b-408a18403d78@github.com>

On Wed, 12 Jun 2024 01:37:19 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Refactor jpackage to separate the configuration and execution phases.
> At the configuration phase, jpackage parses command-line arguments and validates them.
> At the execution phase, jpackage builds a bundle based on data collected at the configuration phase.
> 
> There was no clear separation between these phases. Both used the same data type (`Map<String, Object>`), making it hard to understand and use properly.
> 
> This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling.
> 
> The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map<String, Object>` "params".
> 
> Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers.
> 
> **Functional changes**
> jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below.
> 
>  - Minimize copying of the source app image when doing native packaging.
> 
> Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations.
> 
> - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles.
> 
> post- and pre- install PKG scripts for SimplePackageTest package before and after the change:
> <table>
> <thead>
> <tr>
> <th>Script</th>
> <th>New</th>
> <th>Old</th>
> </tr>
> </thead>
> <tbody>
> <tr>
> <td nowrap>preinstall</td>
> <td>
> <pre>
> #!/usr/bin/env sh<br>
> if [ ! -d "/Applications/SimplePackageTest.app" ]
> the...

keep the PR open

keep it open

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19668#issuecomment-2307257730
PR Comment: https://git.openjdk.org/jdk/pull/19668#issuecomment-2563789218
PR Comment: https://git.openjdk.org/jdk/pull/19668#issuecomment-2866228697

From pminborg at openjdk.org  Fri May  9 12:10:38 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 9 May 2025 12:10:38 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
 [v2]
In-Reply-To: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
Message-ID: <1tTlsd8W1XcfpCvL8P8pozXnvJWBmMtB_ObsAYLBZso=.029cc42a-a477-466f-846e-db19ac454c6b@github.com>

> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
> 
> Unfortunately, this PR shows the total commit history for stable values.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 384 commits:

 - Fix an issue with toString on nested constructs
 - Merge branch 'master' into jep502-followup
 - Merge branch 'master' into jep502-followup
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - Simplify furhter
 - Address comments in PR
 - Merge master
 - Remove unused method and add comment
 - Address comments
 - Merge branch 'master' into jep502-followup
 - ... and 374 more: https://git.openjdk.org/jdk/compare/900b3ff7...3eebd504

-------------

Changes: https://git.openjdk.org/jdk/pull/25004/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25004&range=01
  Stats: 361 lines in 13 files changed: 243 ins; 49 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/25004.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25004/head:pull/25004

PR: https://git.openjdk.org/jdk/pull/25004

From liach at openjdk.org  Fri May  9 12:17:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 12:17:02 GMT
Subject: RFR: 8356486: ReverseOrderListView should override reversed() to
 return `base` [v2]
In-Reply-To: <5KUYc9NQofLb7Ma3HLQuglTCcy6lE_3rHqA_Nzh-iPc=.d6de4b73-3bf7-4245-979f-e58b8554df3b@github.com>
References: <X2vnz1BagQ5K7q-2_oHt9X1JjejNJw5TE44vSUJKeaU=.28fad491-d94c-4fcb-9a44-001a62e0beb4@github.com>
 <5KUYc9NQofLb7Ma3HLQuglTCcy6lE_3rHqA_Nzh-iPc=.d6de4b73-3bf7-4245-979f-e58b8554df3b@github.com>
Message-ID: <iWtkxJzwBVWpgxVrE9I-pgvbHUwxKdwThgwMpFFBR78=.f4cb1cb4-04b2-4f74-9bef-455fb426b1d0@github.com>

On Fri, 9 May 2025 07:50:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposed to let `ReverseOrderListView::reversed` directly return `base` instead of going though a more complicated code path.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove spurious class
>  - Address comments

lgtm

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25120#pullrequestreview-2828087371

From dholmes at openjdk.org  Fri May  9 12:21:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 12:21:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <3CKLh1TDhqMNxlWyINFVMAI6MGe_s2rJrgnfzXYpx2M=.ab9a5cb5-9671-4b90-ba81-83f65b82cd6d@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I saw this PR as preparation for the change of the timeout factor so they could be reviewed distinctly and then integrated close together. So it is natural that people are querying how the proposed changes will work with that change - in particular if it will require explicit timeouts to be added to a lot of tests that don't presently have them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866338479

From lkorinth at openjdk.org  Fri May  9 12:51:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 12:51:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <d4WeSYdxBsFQG_bsWZgsyGDKPbRL5ks8pTVVkck5foc=.5f39ab1e-bbab-483c-8b19-568c6e5a80e4@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Every time I rerun the tests, some new testcase fails on timeouts. Even worse is that I get quite a few /totally unrelated/ test failures every time because I am running 8 tiers.  I could probably change the timeout factor to 0.6 to weed out some more tests faster, but I can not use a timeout factor of 0.5 or less because of CODETOOLS-7903937.

Every 0.1 percent corresponds to 12 seconds. So in absolute measurements I have a margin of 36 seconds now if I would go to a timeout factor of 1. I am also a bit afraid of having too big of a margin --- it will force me to convert possible huge amount of new test cases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866421573

From lkorinth at openjdk.org  Fri May  9 13:06:01 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 13:06:01 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <zfwQsPX7kHwfbD2VUx3dhQwyy1VjAsb-yITfpShYhLM=.2c91dacc-78e2-4393-a7c5-b196fb5be962@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Changing the timeout factor might be preferable to do after the fork.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866463008

From duke at openjdk.org  Fri May  9 13:12:30 2025
From: duke at openjdk.org (Abhishek N)
Date: Fri, 9 May 2025 13:12:30 GMT
Subject: RFR: 8355393: Create a Test case to have special cases coverage for
 currency.getInstance()
Message-ID: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>

Create a Test case to have special cases coverage for currency.getInstance().

The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API.

test results:

jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java
Directory "JTwork" not found: creating
Directory "JTreport" not found: creating
Test results: passed: 1
Report written to JTreport\html\report.html
Results written to JTwork

-------------

Commit messages:
 - remove trailing space
 - remove carriage return from txt and properties file
 - Update ValidateCurrencyCoverage.java test code and add more date cut off to properties and txt file
 - Update ValidateCurrncyCoverage.java to cover all currencies and print result in end
 - Replaced carriage return with newline and removed duplicate currencyParam.properties file
 - 8355393: Create a Test case to have special cases coverage for currency.getInstance()

Changes: https://git.openjdk.org/jdk/pull/25057/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25057&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355393
  Stats: 262 lines in 3 files changed: 262 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25057.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25057/head:pull/25057

PR: https://git.openjdk.org/jdk/pull/25057

From mullan at openjdk.org  Fri May  9 13:26:53 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 9 May 2025 13:26:53 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6]
In-Reply-To: <IGzpehDXDsv_5MZ1ZOO1MnrqLPp1bYNS4anT8Z-8f88=.577c3298-d6d9-48bc-86cf-21c83bfb910b@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <IGzpehDXDsv_5MZ1ZOO1MnrqLPp1bYNS4anT8Z-8f88=.577c3298-d6d9-48bc-86cf-21c83bfb910b@github.com>
Message-ID: <XIUm_tuA58_jwhqIDYBGu2ohThmDW54vfyJ2-PFvItU=.612b809e-c3e5-496c-87e0-f9b8a8a126d8@github.com>

On Fri, 2 May 2025 18:49:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Finalize the KDF API.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fine tuning debug log and exception message

We should also update the comments and info string of `com/sun/crypto/provider/SunJCE.java` with the HKDF algorithms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24520#issuecomment-2866532132

From rgiulietti at openjdk.org  Fri May  9 13:31:55 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 9 May 2025 13:31:55 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v7]
In-Reply-To: <wZnHF7lgvJkhjxpQNCsdCjcluNzGXj6k50zhrp9-K48=.10e0c396-c89e-4f65-9371-e3ec0b15fcd1@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <wZnHF7lgvJkhjxpQNCsdCjcluNzGXj6k50zhrp9-K48=.10e0c396-c89e-4f65-9371-e3ec0b15fcd1@github.com>
Message-ID: <Xh_K3fyk4JoFgH3bCBwphTdErOKgunIkjeJvS63yozo=.b99acd52-6e41-4ea0-ab5d-93dc793d12f2@github.com>

On Fri, 9 May 2025 00:20:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add an assert to inflateToUTF16 method
>   Add doc of preconditions to appendChars... methods
>   Correct misc javadoc

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 238:

> 236:      * {@return true if the byte array should be replaced due to increased capacity or coder change}
> 237:      * <ul>
> 238:      *     <li>The new coder is the different than the old coder

Suggestion:

     *     <li>The new coder is different than the old coder

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1901:

> 1899:         }
> 1900:         return value;
> 1901:     }

I think the logic can be simplified, without a need for the loop.

    private static byte[] putCharsAt(byte[] value, byte coder, int count, int index, char[] s, int off, int end) {
        if (isLatin1(coder)) {
            int latin1Len = StringUTF16.compress(s, off, value, index, end - off);
            if (latin1Len < end - off) {
                value = inflateToUTF16(value, count);
                StringUTF16.putCharsSB(value, index + latin1Len, s, off + latin1Len, end);
            }
        } else {
            StringUTF16.putCharsSB(value, index, s, off, end);
        }
        return value;
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2081686513
PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2081689712

From aph at openjdk.org  Fri May  9 14:16:06 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 9 May 2025 14:16:06 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory
Message-ID: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>

This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).


Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op

-------------

Commit messages:
 - 8354674: AArch64: Intrinsify Unsafe::setMemory
 - New test
 - Cleanup
 - Fixes
 - next cut
 - First cut

Changes: https://git.openjdk.org/jdk/pull/25147/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354674
  Stats: 99 lines in 2 files changed: 96 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25147/head:pull/25147

PR: https://git.openjdk.org/jdk/pull/25147

From ihse at openjdk.org  Fri May  9 14:20:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 14:20:31 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
Message-ID: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>

A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.

While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.

I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

-------------

Commit messages:
 - 8356644: Update encoding declaration to UTF-8

Changes: https://git.openjdk.org/jdk/pull/25148/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25148&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356644
  Stats: 794 lines in 53 files changed: 2 ins; 9 del; 783 mod
  Patch: https://git.openjdk.org/jdk/pull/25148.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25148/head:pull/25148

PR: https://git.openjdk.org/jdk/pull/25148

From aph at openjdk.org  Fri May  9 14:25:50 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 9 May 2025 14:25:50 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory
In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
Message-ID: <gVMxVkLjFPF0JeqPBGFrm_6PjaBaFRuSFyhtnCvdAi0=.c944eb66-254d-4163-bb93-8e93ee1a68ff@github.com>

On Fri, 9 May 2025 14:11:27 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
> 
> 
> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op

Apple M1, small memory blocks:


Benchmark                       (aligned)  (size)  Mode  Cnt  Score   Error  Units
MemorySegmentFillUnsafe.panama       true       1  avgt   10  1.731 ? 0.001  ns/op
MemorySegmentFillUnsafe.panama       true       2  avgt   10  1.570 ? 0.001  ns/op
MemorySegmentFillUnsafe.panama       true       3  avgt   10  1.583 ? 0.014  ns/op
MemorySegmentFillUnsafe.panama       true       4  avgt   10  1.734 ? 0.014  ns/op
MemorySegmentFillUnsafe.panama       true       5  avgt   10  1.736 ? 0.001  ns/op
MemorySegmentFillUnsafe.panama       true       6  avgt   10  1.731 ? 0.001  ns/op
MemorySegmentFillUnsafe.panama       true       7  avgt   10  1.744 ? 0.002  ns/op
MemorySegmentFillUnsafe.panama       true       8  avgt   10  2.365 ? 0.005  ns/op
MemorySegmentFillUnsafe.panama       true      15  avgt   10  2.681 ? 0.001  ns/op
MemorySegmentFillUnsafe.panama       true      16  avgt   10  2.503 ? 0.003  ns/op
MemorySegmentFillUnsafe.panama       true      63  avgt   10  3.615 ? 0.003  ns/op
MemorySegmentFillUnsafe.panama       true      64  avgt   10  4.701 ? 0.056  ns/op
MemorySegmentFillUnsafe.panama       true     255  avgt   10  4.848 ? 0.004  ns/op
MemorySegmentFillUnsafe.panama       true     256  avgt   10  5.003 ? 0.003  ns/op
MemorySegmentFillUnsafe.panama      false       1  avgt   10  1.729 ? 0.001  ns/op
MemorySegmentFillUnsafe.panama      false       2  avgt   10  1.571 ? 0.003  ns/op
MemorySegmentFillUnsafe.panama      false       3  avgt   10  1.579 ? 0.010  ns/op
MemorySegmentFillUnsafe.panama      false       4  avgt   10  1.728 ? 0.002  ns/op
MemorySegmentFillUnsafe.panama      false       5  avgt   10  1.739 ? 0.019  ns/op
MemorySegmentFillUnsafe.panama      false       6  avgt   10  1.731 ? 0.002  ns/op
MemorySegmentFillUnsafe.panama      false       7  avgt   10  1.744 ? 0.012  ns/op
MemorySegmentFillUnsafe.panama      false       8  avgt   10  2.367 ? 0.002  ns/op
MemorySegmentFillUnsafe.panama      false      15  avgt   10  2.694 ? 0.030  ns/op
MemorySegmentFillUnsafe.panama      false      16  avgt   10  2.517 ? 0.057  ns/op
MemorySegmentFillUnsafe.panama      false      63  avgt   10  3.619 ? 0.009  ns/op
MemorySegmentFillUnsafe.panama      false      64  avgt   10  4.708 ? 0.057  ns/op
MemorySegmentFillUnsafe.panama      false     255  avgt   10  5.018 ? 0.057  ns/op
MemorySegmentFillUnsafe.panama      false     256  avgt   10  5.038 ? 0.068  ns/op
MemorySegmentFillUnsafe.unsafe       true       1  avgt   10  2.815 ? 0.002  ns/op
MemorySegmentFillUnsafe.unsafe       true       2  avgt   10  2.821 ? 0.022  ns/op
MemorySegmentFillUnsafe.unsafe       true       3  avgt   10  2.502 ? 0.002  ns/op
MemorySegmentFillUnsafe.unsafe       true       4  avgt   10  2.815 ? 0.004  ns/op
MemorySegmentFillUnsafe.unsafe       true       5  avgt   10  2.502 ? 0.003  ns/op
MemorySegmentFillUnsafe.unsafe       true       6  avgt   10  2.505 ? 0.022  ns/op
MemorySegmentFillUnsafe.unsafe       true       7  avgt   10  2.193 ? 0.019  ns/op
MemorySegmentFillUnsafe.unsafe       true       8  avgt   10  2.190 ? 0.002  ns/op
MemorySegmentFillUnsafe.unsafe       true      15  avgt   10  2.043 ? 0.027  ns/op
MemorySegmentFillUnsafe.unsafe       true      16  avgt   10  2.191 ? 0.003  ns/op
MemorySegmentFillUnsafe.unsafe       true      63  avgt   10  2.061 ? 0.040  ns/op
MemorySegmentFillUnsafe.unsafe       true      64  avgt   10  2.196 ? 0.027  ns/op
MemorySegmentFillUnsafe.unsafe       true     255  avgt   10  3.756 ? 0.001  ns/op
MemorySegmentFillUnsafe.unsafe       true     256  avgt   10  3.752 ? 0.002  ns/op
MemorySegmentFillUnsafe.unsafe      false       1  avgt   10  2.813 ? 0.001  ns/op
MemorySegmentFillUnsafe.unsafe      false       2  avgt   10  2.817 ? 0.003  ns/op
MemorySegmentFillUnsafe.unsafe      false       3  avgt   10  2.502 ? 0.003  ns/op
MemorySegmentFillUnsafe.unsafe      false       4  avgt   10  2.816 ? 0.002  ns/op
MemorySegmentFillUnsafe.unsafe      false       5  avgt   10  2.507 ? 0.027  ns/op
MemorySegmentFillUnsafe.unsafe      false       6  avgt   10  2.507 ? 0.025  ns/op
MemorySegmentFillUnsafe.unsafe      false       7  avgt   10  2.195 ? 0.025  ns/op
MemorySegmentFillUnsafe.unsafe      false       8  avgt   10  2.192 ? 0.005  ns/op
MemorySegmentFillUnsafe.unsafe      false      15  avgt   10  2.050 ? 0.025  ns/op
MemorySegmentFillUnsafe.unsafe      false      16  avgt   10  2.188 ? 0.001  ns/op
MemorySegmentFillUnsafe.unsafe      false      63  avgt   10  2.051 ? 0.027  ns/op
MemorySegmentFillUnsafe.unsafe      false      64  avgt   10  2.196 ? 0.015  ns/op
MemorySegmentFillUnsafe.unsafe      false     255  avgt   10  4.619 ? 0.029  ns/op
MemorySegmentFillUnsafe.unsafe      false     256  avgt   10  4.618 ? 0.047  ns/op

Graviton 4, small memory blocks:


Benchmark                       (aligned)  (size)  Mode  Cnt  Score    Error  Units
MemorySegmentFillUnsafe.panama       true       1  avgt   10  1.970 ?  0.002  ns/op
MemorySegmentFillUnsafe.panama       true       2  avgt   10  1.966 ?  0.020  ns/op
MemorySegmentFillUnsafe.panama       true       3  avgt   10  1.963 ?  0.014  ns/op
MemorySegmentFillUnsafe.panama       true       4  avgt   10  1.989 ?  0.004  ns/op
MemorySegmentFillUnsafe.panama       true       5  avgt   10  2.030 ?  0.010  ns/op
MemorySegmentFillUnsafe.panama       true       6  avgt   10  2.027 ?  0.010  ns/op
MemorySegmentFillUnsafe.panama       true       7  avgt   10  2.077 ?  0.006  ns/op
MemorySegmentFillUnsafe.panama       true       8  avgt   10  2.557 ?  0.004  ns/op
MemorySegmentFillUnsafe.panama       true      15  avgt   10  3.176 ?  0.002  ns/op
MemorySegmentFillUnsafe.panama       true      16  avgt   10  2.779 ?  0.001  ns/op
MemorySegmentFillUnsafe.panama       true      63  avgt   10  4.302 ?  0.002  ns/op
MemorySegmentFillUnsafe.panama       true      64  avgt   10  4.292 ?  0.007  ns/op
MemorySegmentFillUnsafe.panama       true     255  avgt   10  6.311 ?  0.013  ns/op
MemorySegmentFillUnsafe.panama       true     256  avgt   10  5.394 ?  0.003  ns/op
MemorySegmentFillUnsafe.panama      false       1  avgt   10  1.970 ?  0.001  ns/op
MemorySegmentFillUnsafe.panama      false       2  avgt   10  1.937 ?  0.017  ns/op
MemorySegmentFillUnsafe.panama      false       3  avgt   10  1.954 ?  0.014  ns/op
MemorySegmentFillUnsafe.panama      false       4  avgt   10  1.985 ?  0.005  ns/op
MemorySegmentFillUnsafe.panama      false       5  avgt   10  2.006 ?  0.008  ns/op
MemorySegmentFillUnsafe.panama      false       6  avgt   10  2.015 ?  0.008  ns/op
MemorySegmentFillUnsafe.panama      false       7  avgt   10  2.138 ?  0.035  ns/op
MemorySegmentFillUnsafe.panama      false       8  avgt   10  2.553 ?  0.005  ns/op
MemorySegmentFillUnsafe.panama      false      15  avgt   10  3.178 ?  0.002  ns/op
MemorySegmentFillUnsafe.panama      false      16  avgt   10  2.775 ?  0.005  ns/op
MemorySegmentFillUnsafe.panama      false      63  avgt   10  4.296 ?  0.007  ns/op
MemorySegmentFillUnsafe.panama      false      64  avgt   10  4.290 ?  0.001  ns/op
MemorySegmentFillUnsafe.panama      false     255  avgt   10  6.334 ?  0.013  ns/op
MemorySegmentFillUnsafe.panama      false     256  avgt   10  5.472 ?  0.009  ns/op
MemorySegmentFillUnsafe.unsafe       true       1  avgt   10  3.218 ?  0.001  ns/op
MemorySegmentFillUnsafe.unsafe       true       2  avgt   10  2.860 ?  0.001  ns/op
MemorySegmentFillUnsafe.unsafe       true       3  avgt   10  2.860 ?  0.001  ns/op
MemorySegmentFillUnsafe.unsafe       true       4  avgt   10  2.860 ?  0.001  ns/op
MemorySegmentFillUnsafe.unsafe       true       5  avgt   10  2.860 ?  0.001  ns/op
MemorySegmentFillUnsafe.unsafe       true       6  avgt   10  2.503 ?  0.001  ns/op
MemorySegmentFillUnsafe.unsafe       true       7  avgt   10  2.860 ?  0.001  ns/op
MemorySegmentFillUnsafe.unsafe       true       8  avgt   10  2.145 ?  0.001  ns/op
MemorySegmentFillUnsafe.unsafe       true      15  avgt   10  2.886 ?  0.100  ns/op
MemorySegmentFillUnsafe.unsafe       true      16  avgt   10  2.145 ?  0.001  ns/op
MemorySegmentFillUnsafe.unsafe       true      63  avgt   10  3.781 ?  0.013  ns/op
MemorySegmentFillUnsafe.unsafe       true      64  avgt   10  2.735 ?  0.016  ns/op
MemorySegmentFillUnsafe.unsafe       true     255  avgt   10  5.079 ?  0.014  ns/op
MemorySegmentFillUnsafe.unsafe       true     256  avgt   10  4.007 ?  0.112  ns/op
MemorySegmentFillUnsafe.unsafe      false       1  avgt   10  3.218 ?  0.001  ns/op
MemorySegmentFillUnsafe.unsafe      false       2  avgt   10  2.860 ?  0.001  ns/op
MemorySegmentFillUnsafe.unsafe      false       3  avgt   10  2.861 ?  0.001  ns/op
MemorySegmentFillUnsafe.unsafe      false       4  avgt   10  2.864 ?  0.016  ns/op
MemorySegmentFillUnsafe.unsafe      false       5  avgt   10  2.860 ?  0.001  ns/op
MemorySegmentFillUnsafe.unsafe      false       6  avgt   10  2.503 ?  0.001  ns/op
MemorySegmentFillUnsafe.unsafe      false       7  avgt   10  2.860 ?  0.001  ns/op
MemorySegmentFillUnsafe.unsafe      false       8  avgt   10  2.145 ?  0.001  ns/op
MemorySegmentFillUnsafe.unsafe      false      15  avgt   10  2.571 ?  0.040  ns/op
MemorySegmentFillUnsafe.unsafe      false      16  avgt   10  2.146 ?  0.001  ns/op
MemorySegmentFillUnsafe.unsafe      false      63  avgt   10  4.531 ?  0.021  ns/op
MemorySegmentFillUnsafe.unsafe      false      64  avgt   10  5.134 ?  0.099  ns/op
MemorySegmentFillUnsafe.unsafe      false     255  avgt   10  6.603 ?  0.031  ns/op
MemorySegmentFillUnsafe.unsafe      false     256  avgt   10  7.148 ?  0.025  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2866747058
PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2866751204

From vromero at openjdk.org  Fri May  9 14:35:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 9 May 2025 14:35:38 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v7]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <BErjvrR3lrvxuwYJtLzLhXTLwQ-TlxslD2MnWABEwCA=.7c1639f8-d72d-42a6-b12d-f02fdb54945f@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  documentation and adding alias to lint categories

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/5d834ce0..d52ec33b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=05-06

  Stats: 101 lines in 9 files changed: 36 ins; 28 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

PR: https://git.openjdk.org/jdk/pull/24746

From dfuchs at openjdk.org  Fri May  9 14:39:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 14:39:53 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v5]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <l0kZnNDdN-TbltTkaEW4yohiocDPHWvIJu34Nl8em8g=.02e58472-5252-414f-bfa6-9c06af35d5b6@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 422 commits:

 - merge latest changes from master branch
 - Undo whitespace change
 - Remove unnecessary import
 - Merge remote-tracking branch 'origin/master' into http3
 - Fix test license
 - Remove leftover file (test was moved to parent directory)
 - Remove unnecessary import
 - Update throws clauses
 - Merge remote-tracking branch 'origin/master' into http3
 - 8354275: Add HTTP/3 tests to `EmptyAuthenticate`
 - ... and 412 more: https://git.openjdk.org/jdk/compare/568dcc15...8c27f53c

-------------

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=04
  Stats: 103018 lines in 469 files changed: 100164 ins; 1347 del; 1507 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 liach at openjdk.org  Fri May  9 14:42:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 14:42:52 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v7]
In-Reply-To: <BErjvrR3lrvxuwYJtLzLhXTLwQ-TlxslD2MnWABEwCA=.7c1639f8-d72d-42a6-b12d-f02fdb54945f@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <BErjvrR3lrvxuwYJtLzLhXTLwQ-TlxslD2MnWABEwCA=.7c1639f8-d72d-42a6-b12d-f02fdb54945f@github.com>
Message-ID: <DlQOmW_D7TLbjg1as-pR0bIXPdatgg4Ri-RkIxoRJJs=.23ddc244-e1b5-4147-8bd3-c480c1387898@github.com>

On Fri, 9 May 2025 14:35:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   documentation and adding alias to lint categories

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 434:

> 432:             // we need to do this as forward references are not allowed
> 433:             if (alias != null) {
> 434:                 alias.alias = this;

I think we wish to make this a union-find-like structure (if you are familiar with leetcode problems) - we need to have some category as roots that point to themselves. Other category like synchronization can point to identity. When we use a `LintCategory` we do a "find root" to find the actual category to use.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2081830955

From mcimadamore at openjdk.org  Fri May  9 14:46:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 9 May 2025 14:46:58 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
 [v2]
In-Reply-To: <1tTlsd8W1XcfpCvL8P8pozXnvJWBmMtB_ObsAYLBZso=.029cc42a-a477-466f-846e-db19ac454c6b@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
 <1tTlsd8W1XcfpCvL8P8pozXnvJWBmMtB_ObsAYLBZso=.029cc42a-a477-466f-846e-db19ac454c6b@github.com>
Message-ID: <qlHmAsklMjWL0jTUKB_m98SugpclKQdeYINa-dV6WJs=.3fa9b220-02ac-4223-aaaa-19de1ed0a97c@github.com>

On Fri, 9 May 2025 12:10:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
>> 
>> Unfortunately, this PR shows the total commit history for stable values.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 384 commits:
> 
>  - Fix an issue with toString on nested constructs
>  - Merge branch 'master' into jep502-followup
>  - Merge branch 'master' into jep502-followup
>  - Update src/java.base/share/classes/java/lang/StableValue.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Simplify furhter
>  - Address comments in PR
>  - Merge master
>  - Remove unused method and add comment
>  - Address comments
>  - Merge branch 'master' into jep502-followup
>  - ... and 374 more: https://git.openjdk.org/jdk/compare/900b3ff7...3eebd504

StableAPI javadoc changes look good!

-------------

PR Review: https://git.openjdk.org/jdk/pull/25004#pullrequestreview-2828627039

From vklang at openjdk.org  Fri May  9 14:47:56 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 9 May 2025 14:47:56 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <evfaz5EKS-CJbYM0Ai3PqcC-0Soa6CC4TfJ_ZHAK1vs=.0515c9b9-7bec-4782-8482-86956e1cb173@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <rO9njoSonLf7DLUrHaB9jMMXDTodgbWlZ-391cqxW50=.0f02cb42-105b-4aaf-88cf-9d6574e0d555@github.com>
 <evfaz5EKS-CJbYM0Ai3PqcC-0Soa6CC4TfJ_ZHAK1vs=.0515c9b9-7bec-4782-8482-86956e1cb173@github.com>
Message-ID: <eiBoOtieObh-4z7uZVy2eKfK6XrAt_tAh5kHec51uf8=.442c782c-f58a-4e0d-8e61-45f7e6cf6154@github.com>

On Thu, 8 May 2025 14:28:18 GMT, kabutz <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 865:
>> 
>>> 863:         long n = 0;
>>> 864:         for (E e : c) {
>>> 865:             Objects.requireNonNull(e);
>> 
>> This makes me wonder: Does it make sense to create new nodes if we don't track if they will still fit into the capacity?
>
> We could if you like, but that would subtly change the current behaviour. I tried to make as few changes as possible.

On the other hand, there could be intermediate operations modifying the underlying collection before the lock is obtained, so checking wouldn't help.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2081840954

From mcimadamore at openjdk.org  Fri May  9 14:49:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 9 May 2025 14:49:54 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v10]
In-Reply-To: <DrGwMv2P3SpsmVSU_2PsJgd4iqkl7ZFRA9M5EdwS3tU=.7093ffbf-24c5-45f7-a9e7-9d8aa4e75345@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
 <DrGwMv2P3SpsmVSU_2PsJgd4iqkl7ZFRA9M5EdwS3tU=.7093ffbf-24c5-45f7-a9e7-9d8aa4e75345@github.com>
Message-ID: <3JVT36sXI35rxZUAP0TTK270tQV0eZBeN5hXL3Xr0ro=.62770fd7-0812-4616-9574-953f48be3186@github.com>

On Thu, 8 May 2025 10:50:55 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert more incidental changes
>  - Revert incidental change

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25043#pullrequestreview-2828633505

From vklang at openjdk.org  Fri May  9 14:53:52 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 9 May 2025 14:53:52 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <EA5TgRWJRik6NTmG9n7L12cq-viCZ9wcOMu2spIgEPk=.06fc3b76-8949-45c5-a280-08424a898e45@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <-elHwuRlU4xfy382a9QVdVT6WQMPoZyyEHANGR2TgmQ=.b4329ab0-7f2e-4c7b-9053-9917f2ea3a5f@github.com>
 <EA5TgRWJRik6NTmG9n7L12cq-viCZ9wcOMu2spIgEPk=.06fc3b76-8949-45c5-a280-08424a898e45@github.com>
Message-ID: <eM3g9-uUtCPlJYoGAQ0r-mz5TSghOaxSxIsOtHY2XJY=.1bbc2579-0a82-4d0d-a65c-5dcb23b1a2d0@github.com>

On Thu, 8 May 2025 13:47:41 GMT, kabutz <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 341:
>> 
>>> 339:             if (count >= capacity)
>>> 340:                 return false;
>>> 341:             linkFirst(node);
>> 
>> I'm a bit uneasy about incrementing the `count` in `linkFirst` but not enforcing the invariant. What's the benefit to changing linkFirst and linkLast to return void instead of keeping the original returning a boolean?
>
>> I'm a bit uneasy about incrementing the `count` in `linkFirst` but not enforcing the invariant. What's the benefit to changing linkFirst and linkLast to return void instead of keeping the original returning a boolean?
> 
> I based the approach on the LBQ enqueue() and dequeue() methods, which also return void and have a comment with the assertion.

I understand, alas LBQ enqueue() and dequeue() don't increment a counter. It seems a bit brittle that the invariant needs to be maintained *externally* to the state modification. For the sake of maintainability I think the checks and the increment/decrement belongs in the same unit of work.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2081852042

From acobbs at openjdk.org  Fri May  9 15:00:56 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 9 May 2025 15:00:56 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v7]
In-Reply-To: <BErjvrR3lrvxuwYJtLzLhXTLwQ-TlxslD2MnWABEwCA=.7c1639f8-d72d-42a6-b12d-f02fdb54945f@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <BErjvrR3lrvxuwYJtLzLhXTLwQ-TlxslD2MnWABEwCA=.7c1639f8-d72d-42a6-b12d-f02fdb54945f@github.com>
Message-ID: <BpTRu7UQNj2Mout2Jc-ptU27dlRW0vFWdcT9c8QgD2g=.a7f3a1e3-8ddf-4a44-b0f3-96dbe3377dbe@github.com>

On Fri, 9 May 2025 14:35:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   documentation and adding alias to lint categories

I don't understand the point of having two separate `LintCategory`'s `SYNCHRONIZATION` and `IDENTITY`.  That's like having two different humans just so you can call them `Robert` or `Bobby`.

Put another way, are we proposing here to temporarily support compiler configurations like `Xlint:-identity,synchronization` and `Xlint:-synchronization,identity`?
* If not, then there should be a single `LintCategory.IDENTITY` that is addressable through all the usual naming mechanisms (i.e., `@SuppressWarnings`, `-Xlint:foo`) as either `"synchronization"` or `"identity"`. That is `"synchronization"` is just a true alias.
* If so, then we are creating a future backward-incompatibility when we merge `SYNCHRONIZATION` into `IDENTITY`. After that merge, what is `Xlint:-synchronization,identity` or `Xlint:-identity,-synchronization` supposed to mean?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2866880798

From pchilanomate at openjdk.org  Fri May  9 15:07:58 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 9 May 2025 15:07:58 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <_VEnZnG0YjPHzre6rmgbbgTFvIXXLyPEAEbzo6_fxYg=.f085651b-1c03-4d11-9fb1-bf2c1e8081b8@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
 <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
 <_VEnZnG0YjPHzre6rmgbbgTFvIXXLyPEAEbzo6_fxYg=.f085651b-1c03-4d11-9fb1-bf2c1e8081b8@github.com>
Message-ID: <0YcCb_ThphXvVjENLXPNn-Z5EKdj_VIUKKAWPYdOc04=.f5571a2c-9afb-4a34-b13c-abb530e64960@github.com>

On Fri, 9 May 2025 06:32:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename awaitBlocked to awaitTrueAndBlocked
>
> Marked as reviewed by alanb (Reviewer).

Thanks for the reviews @AlanBateman, @kevinjwalls and @dholmes-ora!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25119#issuecomment-2866899837

From pchilanomate at openjdk.org  Fri May  9 15:07:57 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 9 May 2025 15:07:57 GMT
Subject: RFR: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock [v2]
In-Reply-To: <mYU92_TN5g64lnUsbJhXf6GJ6QWcHSgWjzCGZZWGAmE=.e286e075-904e-4e6f-bf73-b67bb3c0ee89@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
 <IW-lY_CFlg7ffPki7ylZp_H8L-ntJ0aXeegdv1oYdc8=.2b4300c7-edd0-4306-9aeb-6b848228e792@github.com>
 <mYU92_TN5g64lnUsbJhXf6GJ6QWcHSgWjzCGZZWGAmE=.e286e075-904e-4e6f-bf73-b67bb3c0ee89@github.com>
Message-ID: <WCjH2ad94orGe9oWN5J5ylcX2IUYuVtEOr6gHVZrNyw=.fb8f3818-17ea-46ad-acb1-f3307e43c687@github.com>

On Thu, 8 May 2025 21:59:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly().
> 
> No, because that is an internal implementation detail. It is a grey area. There is no such thing as an uninterruptible-wait in the Java language, so if we marked the thread as waiting and yet it failed to stop waiting if interrupted, then that would appear to be a bug.
>
I see, thanks for the clarification David.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25119#issuecomment-2866895215

From pchilanomate at openjdk.org  Fri May  9 15:07:59 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 9 May 2025 15:07:59 GMT
Subject: Integrated: 8346255:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no
 deadlock
In-Reply-To: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
References: <aApNpN7-HNvNzNQHv-SZvMgWYOy0ds_sUMm-Zgs5eSs=.3b038e54-6c54-452d-99e9-0d5770431fc1@github.com>
Message-ID: <vDmLNPc2R36mJlMHNJtn7EXVtQo5aptN9G_z-VQCJn4=.eca13064-7eda-4f32-ab59-6d1d2488e0aa@github.com>

On Thu, 8 May 2025 13:46:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments).
> 
> I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don?t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup).
> 
> I was able to reproduce the failure and verified it doesn?t reproduce anymore with the fix.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: 9ebb5d42
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ebb5d42d43a743cf3a5197c7dabe46ac8120474
Stats:     10 lines in 1 file changed: 5 ins; 0 del; 5 mod

8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock

Reviewed-by: kevinw, dholmes, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25119

From liach at openjdk.org  Fri May  9 15:16:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 15:16:58 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v7]
In-Reply-To: <BErjvrR3lrvxuwYJtLzLhXTLwQ-TlxslD2MnWABEwCA=.7c1639f8-d72d-42a6-b12d-f02fdb54945f@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <BErjvrR3lrvxuwYJtLzLhXTLwQ-TlxslD2MnWABEwCA=.7c1639f8-d72d-42a6-b12d-f02fdb54945f@github.com>
Message-ID: <DCD-qgyrUoWynl5O9lO18RwhCSlvOCpVeyCQ9jrjyJk=.02877687-1c4b-4e9b-aac8-f06992e086c4@github.com>

On Fri, 9 May 2025 14:35:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   documentation and adding alias to lint categories

Good point; maybe instead of creating new `LintCategory`, we use this union-find approach to deduplicate when we parse LintCategory from strings.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2866948054

From aph at openjdk.org  Fri May  9 15:20:53 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 9 May 2025 15:20:53 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory
In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
Message-ID: <NNbc9xS8W5EVnmWypbsNGeVcLUjn5piALWHgpX6V9uY=.14a41464-8b6c-4343-b315-a6a0683075a0@github.com>

On Fri, 9 May 2025 14:11:27 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
> 
> 
> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op

Apple M1:


Benchmark                              (ELEM_SIZE)  Mode  Cnt        Score       Error  Units
SegmentBulkFill.heapSegmentFillJava              2  avgt   10        1.727 ?     0.017  ns/op
SegmentBulkFill.heapSegmentFillJava              3  avgt   10        1.721 ?     0.002  ns/op
SegmentBulkFill.heapSegmentFillJava              4  avgt   10        1.876 ?     0.002  ns/op
SegmentBulkFill.heapSegmentFillJava              5  avgt   10        1.876 ?     0.001  ns/op
SegmentBulkFill.heapSegmentFillJava              6  avgt   10        1.876 ?     0.002  ns/op
SegmentBulkFill.heapSegmentFillJava              7  avgt   10        1.876 ?     0.002  ns/op
SegmentBulkFill.heapSegmentFillJava              8  avgt   10        2.502 ?     0.003  ns/op
SegmentBulkFill.heapSegmentFillJava             64  avgt   10        4.064 ?     0.002  ns/op
SegmentBulkFill.heapSegmentFillJava            512  avgt   10        6.601 ?     0.051  ns/op
SegmentBulkFill.heapSegmentFillJava           4096  avgt   10       44.050 ?     0.076  ns/op
SegmentBulkFill.heapSegmentFillJava          32768  avgt   10      330.328 ?     0.450  ns/op
SegmentBulkFill.heapSegmentFillJava         262144  avgt   10     4138.154 ?     6.509  ns/op
SegmentBulkFill.heapSegmentFillJava        2097152  avgt   10    33089.966 ?    48.068  ns/op
SegmentBulkFill.heapSegmentFillJava       16777216  avgt   10   352669.548 ?   571.433  ns/op
SegmentBulkFill.heapSegmentFillJava      134217728  avgt   10  4482510.192 ?  7177.637  ns/op
SegmentBulkFill.heapSegmentFillLoop              2  avgt   10        1.977 ?     0.003  ns/op
SegmentBulkFill.heapSegmentFillLoop              3  avgt   10        3.447 ?     0.002  ns/op
SegmentBulkFill.heapSegmentFillLoop              4  avgt   10        4.073 ?     0.042  ns/op
SegmentBulkFill.heapSegmentFillLoop              5  avgt   10        4.377 ?     0.004  ns/op
SegmentBulkFill.heapSegmentFillLoop              6  avgt   10        5.337 ?     0.071  ns/op
SegmentBulkFill.heapSegmentFillLoop              7  avgt   10        5.629 ?     0.004  ns/op
SegmentBulkFill.heapSegmentFillLoop              8  avgt   10        5.947 ?     0.010  ns/op
SegmentBulkFill.heapSegmentFillLoop             64  avgt   10        8.127 ?     0.003  ns/op
SegmentBulkFill.heapSegmentFillLoop            512  avgt   10       16.045 ?     0.027  ns/op
SegmentBulkFill.heapSegmentFillLoop           4096  avgt   10       46.627 ?     0.164  ns/op
SegmentBulkFill.heapSegmentFillLoop          32768  avgt   10      333.233 ?     1.040  ns/op
SegmentBulkFill.heapSegmentFillLoop         262144  avgt   10     4134.009 ?    11.125  ns/op
SegmentBulkFill.heapSegmentFillLoop        2097152  avgt   10    33148.671 ?   322.905  ns/op
SegmentBulkFill.heapSegmentFillLoop       16777216  avgt   10   343832.913 ?   233.881  ns/op
SegmentBulkFill.heapSegmentFillLoop      134217728  avgt   10  4475821.911 ?  6101.380  ns/op
SegmentBulkFill.heapSegmentFillUnsafe            2  avgt   10        3.133 ?     0.034  ns/op
SegmentBulkFill.heapSegmentFillUnsafe            3  avgt   10        3.130 ?     0.005  ns/op
SegmentBulkFill.heapSegmentFillUnsafe            4  avgt   10        3.128 ?     0.004  ns/op
SegmentBulkFill.heapSegmentFillUnsafe            5  avgt   10        3.139 ?     0.030  ns/op
SegmentBulkFill.heapSegmentFillUnsafe            6  avgt   10        3.135 ?     0.035  ns/op
SegmentBulkFill.heapSegmentFillUnsafe            7  avgt   10        3.135 ?     0.030  ns/op
SegmentBulkFill.heapSegmentFillUnsafe            8  avgt   10        2.665 ?     0.006  ns/op
SegmentBulkFill.heapSegmentFillUnsafe           64  avgt   10        2.841 ?     0.032  ns/op
SegmentBulkFill.heapSegmentFillUnsafe          512  avgt   10        6.246 ?     0.100  ns/op
SegmentBulkFill.heapSegmentFillUnsafe         4096  avgt   10       41.241 ?     0.107  ns/op
SegmentBulkFill.heapSegmentFillUnsafe        32768  avgt   10      331.001 ?     4.521  ns/op
SegmentBulkFill.heapSegmentFillUnsafe       262144  avgt   10     3038.808 ?    29.750  ns/op
SegmentBulkFill.heapSegmentFillUnsafe      2097152  avgt   10    21996.375 ?  2617.947  ns/op
SegmentBulkFill.heapSegmentFillUnsafe     16777216  avgt   10   241814.864 ? 24300.854  ns/op
SegmentBulkFill.heapSegmentFillUnsafe    134217728  avgt   10  2811655.392 ? 24737.911  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2866961810

From liach at openjdk.org  Fri May  9 15:21:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 15:21:03 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
 [v2]
In-Reply-To: <1tTlsd8W1XcfpCvL8P8pozXnvJWBmMtB_ObsAYLBZso=.029cc42a-a477-466f-846e-db19ac454c6b@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
 <1tTlsd8W1XcfpCvL8P8pozXnvJWBmMtB_ObsAYLBZso=.029cc42a-a477-466f-846e-db19ac454c6b@github.com>
Message-ID: <11qM0h_1z3Sws5UhAMhkDr4Kr5IEYPzSOKlyJz04OWM=.b1b2caa6-9bc6-4eaa-a119-9e1bf40f4fce@github.com>

On Fri, 9 May 2025 12:10:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
>> 
>> Unfortunately, this PR shows the total commit history for stable values.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 384 commits:
> 
>  - Fix an issue with toString on nested constructs
>  - Merge branch 'master' into jep502-followup
>  - Merge branch 'master' into jep502-followup
>  - Update src/java.base/share/classes/java/lang/StableValue.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Simplify furhter
>  - Address comments in PR
>  - Merge master
>  - Remove unused method and add comment
>  - Address comments
>  - Merge branch 'master' into jep502-followup
>  - ... and 374 more: https://git.openjdk.org/jdk/compare/900b3ff7...3eebd504

Looks good, some bikeshedding

src/java.base/share/classes/java/util/ImmutableCollections.java line 140:

> 138:                 }
> 139:                 public <E> List<E> stableList(int size, IntFunction<? extends E> mapper) {
> 140:                     // A stable list is not Serializable so, we cannot return `List.of()` if `size == 0`

Suggestion:

                    // A stable list is not Serializable, so we cannot return `List.of()` if `size == 0`

src/java.base/share/classes/java/util/ImmutableCollections.java line 144:

> 142:                 }
> 143:                 public <K, V> Map<K, V> stableMap(Set<K> keys, Function<? super K, ? extends V> mapper) {
> 144:                     // A stable map is not Serializable so, we cannot return `Map.of()` if `keys.isEmpty()`

Suggestion:

                    // A stable map is not Serializable, so we cannot return `Map.of()` if `keys.isEmpty()`

bikeshedding.

src/java.base/share/classes/java/util/ImmutableCollections.java line 879:

> 877:         public List<E> subList(int fromIndex, int toIndex) {
> 878:             final int size = size();
> 879:             subListRangeCheck(fromIndex, toIndex, size);

Suggestion:

            subListRangeCheck(fromIndex, toIndex, size());

Redundant variable.

src/java.base/share/classes/java/util/ImmutableCollections.java line 1715:

> 1713: 
> 1714:                 // For @ValueBased
> 1715:                 static private <K, V> LazyMapIterator<K, V> of(StableMapEntrySet<K, V> outer) {

Suggestion:

                private static <K, V> LazyMapIterator<K, V> of(StableMapEntrySet<K, V> outer) {

src/java.base/share/classes/java/util/ReverseOrderListView.java line 46:

> 44:     final List<E> base;
> 45:     @Stable
> 46:     final boolean modifiable;

Unfortunately, stable on boolean only works for true - wish we can get trusted or strict final soon :)

-------------

PR Review: https://git.openjdk.org/jdk/pull/25004#pullrequestreview-2828636051
PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2081846330
PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2081847091
PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2081851704
PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2081858151
PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2081860387

From rriggs at openjdk.org  Fri May  9 15:23:36 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 May 2025 15:23:36 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v8]
In-Reply-To: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
Message-ID: <YdCjUFuHJlZoBvyRMGj-TR-7x18366wYIdWogIboVpU=.380d1bec-8fde-4fbe-a79a-7e389f4d20d9@github.com>

> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
> Support methods are static, designed to pass all values as arguments and return a value.
> 
> The value byte array is reallocated under 3 conditions:
> - Increasing the capacity with the same encoder
> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
> - Inflation with the same capacity
> 
> Added StressSBTest to exercise public instance methods of StringBuilder.

Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:

 - Refactor ensureCapacityNewCoder to compute newCapacity first and
   add an assert to check the count of characters fit within the new capacity.
   The same and different coder paths had slightly different computations for newCapacity.
 - Add a test exercising the buffer capacity changes during SB.replace.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24967/files
  - new: https://git.openjdk.org/jdk/pull/24967/files/1404fa9e..8f731431

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=06-07

  Stats: 72 lines in 2 files changed: 56 ins; 8 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24967.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24967/head:pull/24967

PR: https://git.openjdk.org/jdk/pull/24967

From rriggs at openjdk.org  Fri May  9 15:23:36 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 May 2025 15:23:36 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v6]
In-Reply-To: <pvRO0pa8yXucxsNl9Fo5Tz2MbiK-v3qLqcXQcwGr0dM=.6de1e943-a440-4b73-936b-6346a54478a8@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <_NsIGgzOOhVxFE8QZFKhyVYk_eu7W8Zj-Z4ojMdilM4=.d120437c-85bc-4d56-964e-fb80bdfc8d91@github.com>
 <pvRO0pa8yXucxsNl9Fo5Tz2MbiK-v3qLqcXQcwGr0dM=.6de1e943-a440-4b73-936b-6346a54478a8@github.com>
Message-ID: <h_2CUIFoKotW2Lhx7cbLy7h-Dm2wDFdxZqJ1P9qJKa4=.0c541f4d-1e3c-4b53-b3e7-114849490bd5@github.com>

On Tue, 6 May 2025 16:18:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply reviewer suggestions for typos, javadoc, and copyright dates.
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 270:
> 
>> 268:     private static byte[] ensureCapacityNewCoder(byte[] value, byte coder, int count,
>> 269:                                                  int minimumCapacity, byte newCoder) {
>> 270:         assert coder == newCoder || newCoder == UTF16 : "bad new coder UTF16 -> LATIN1";
> 
> I recommend an additional assertion `count <= minimumCapacity`; even though all callers ensure this currently, in case this is accidentally violated, we are sending dangerous arguments to `StringLatin1.inflate`.
> 
> Also, the message string of assertion can include the `coder` and `newCoder` values. Same for the other assertions we add.

Added the assertion(s) without the extra message formatting overhead/codesize.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2081918105

From aph at openjdk.org  Fri May  9 15:30:53 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 9 May 2025 15:30:53 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory
In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
Message-ID: <2yBNv1pe_7PYsML-ySuw5EMb2cqamuF1wDiDgRtNP3Y=.0fa1c070-d627-472f-9255-376d3a4bd7b6@github.com>

On Fri, 9 May 2025 14:11:27 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
> 
> 
> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op

Graviton 4:


Benchmark                              (ELEM_SIZE)  Mode  Cnt        Score      Error  Units
SegmentBulkFill.heapSegmentFillJava              2  avgt   10        2.324 ?    0.066  ns/op
SegmentBulkFill.heapSegmentFillJava              3  avgt   10        2.427 ?    0.031  ns/op
SegmentBulkFill.heapSegmentFillJava              4  avgt   10        2.231 ?    0.009  ns/op
SegmentBulkFill.heapSegmentFillJava              5  avgt   10        2.523 ?    0.040  ns/op
SegmentBulkFill.heapSegmentFillJava              6  avgt   10        2.632 ?    0.017  ns/op
SegmentBulkFill.heapSegmentFillJava              7  avgt   10        2.394 ?    0.007  ns/op
SegmentBulkFill.heapSegmentFillJava              8  avgt   10        3.004 ?    0.032  ns/op
SegmentBulkFill.heapSegmentFillJava             64  avgt   10        4.813 ?    0.417  ns/op
SegmentBulkFill.heapSegmentFillJava            512  avgt   10        9.151 ?    0.040  ns/op
SegmentBulkFill.heapSegmentFillJava           4096  avgt   10       60.127 ?    0.078  ns/op
SegmentBulkFill.heapSegmentFillJava          32768  avgt   10      461.292 ?    2.127  ns/op
SegmentBulkFill.heapSegmentFillJava         262144  avgt   10     3666.851 ?    0.280  ns/op
SegmentBulkFill.heapSegmentFillJava        2097152  avgt   10    35169.510 ?   22.507  ns/op
SegmentBulkFill.heapSegmentFillJava       16777216  avgt   10   227182.710 ?  903.546  ns/op
SegmentBulkFill.heapSegmentFillJava      134217728  avgt   10  1946761.410 ? 3033.447  ns/op
SegmentBulkFill.heapSegmentFillLoop              2  avgt   10        2.902 ?    0.038  ns/op
SegmentBulkFill.heapSegmentFillLoop              3  avgt   10        3.870 ?    0.004  ns/op
SegmentBulkFill.heapSegmentFillLoop              4  avgt   10        5.438 ?    0.013  ns/op
SegmentBulkFill.heapSegmentFillLoop              5  avgt   10        5.714 ?    0.033  ns/op
SegmentBulkFill.heapSegmentFillLoop              6  avgt   10        5.748 ?    0.019  ns/op
SegmentBulkFill.heapSegmentFillLoop              7  avgt   10        5.909 ?    0.004  ns/op
SegmentBulkFill.heapSegmentFillLoop              8  avgt   10        6.330 ?    0.295  ns/op
SegmentBulkFill.heapSegmentFillLoop             64  avgt   10        8.769 ?    0.003  ns/op
SegmentBulkFill.heapSegmentFillLoop            512  avgt   10       16.935 ?    0.007  ns/op
SegmentBulkFill.heapSegmentFillLoop           4096  avgt   10       57.822 ?    0.510  ns/op
SegmentBulkFill.heapSegmentFillLoop          32768  avgt   10      376.849 ?    0.311  ns/op
SegmentBulkFill.heapSegmentFillLoop         262144  avgt   10     3059.064 ?    0.419  ns/op
SegmentBulkFill.heapSegmentFillLoop        2097152  avgt   10    24398.571 ?    8.618  ns/op
SegmentBulkFill.heapSegmentFillLoop       16777216  avgt   10   225721.136 ?  608.041  ns/op
SegmentBulkFill.heapSegmentFillLoop      134217728  avgt   10  1940987.569 ? 2156.239  ns/op
SegmentBulkFill.heapSegmentFillUnsafe            2  avgt   10        3.628 ?    0.022  ns/op
SegmentBulkFill.heapSegmentFillUnsafe            3  avgt   10        3.670 ?    0.011  ns/op
SegmentBulkFill.heapSegmentFillUnsafe            4  avgt   10        3.583 ?    0.002  ns/op
SegmentBulkFill.heapSegmentFillUnsafe            5  avgt   10        3.651 ?    0.016  ns/op
SegmentBulkFill.heapSegmentFillUnsafe            6  avgt   10        3.659 ?    0.015  ns/op
SegmentBulkFill.heapSegmentFillUnsafe            7  avgt   10        3.687 ?    0.016  ns/op
SegmentBulkFill.heapSegmentFillUnsafe            8  avgt   10        3.193 ?    0.022  ns/op
SegmentBulkFill.heapSegmentFillUnsafe           64  avgt   10        3.365 ?    0.034  ns/op
SegmentBulkFill.heapSegmentFillUnsafe          512  avgt   10        6.443 ?    0.006  ns/op
SegmentBulkFill.heapSegmentFillUnsafe         4096  avgt   10       48.261 ?    0.081  ns/op
SegmentBulkFill.heapSegmentFillUnsafe        32768  avgt   10      389.793 ?    0.777  ns/op
SegmentBulkFill.heapSegmentFillUnsafe       262144  avgt   10     3123.758 ?    1.048  ns/op
SegmentBulkFill.heapSegmentFillUnsafe      2097152  avgt   10    25039.904 ?   55.467  ns/op
SegmentBulkFill.heapSegmentFillUnsafe     16777216  avgt   10   223579.037 ?  306.005  ns/op
SegmentBulkFill.heapSegmentFillUnsafe    134217728  avgt   10  1931370.983 ? 1110.364  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2867002071

From aph at openjdk.org  Fri May  9 15:39:35 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 9 May 2025 15:39:35 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v2]
In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
Message-ID: <bnf8iIIZzedQLKLZSnqIeoVz_C-YTIEIVDKqCVFT_qY=.cdd3180a-7062-4a3d-882e-2e8de719d5ff@github.com>

> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
> 
> 
> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  generate_unsafecopy_common_error_exit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25147/files
  - new: https://git.openjdk.org/jdk/pull/25147/files/c3d4c414..1078ba8c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=00-01

  Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25147/head:pull/25147

PR: https://git.openjdk.org/jdk/pull/25147

From rgiulietti at openjdk.org  Fri May  9 15:57:57 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 9 May 2025 15:57:57 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v7]
In-Reply-To: <Xh_K3fyk4JoFgH3bCBwphTdErOKgunIkjeJvS63yozo=.b99acd52-6e41-4ea0-ab5d-93dc793d12f2@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <wZnHF7lgvJkhjxpQNCsdCjcluNzGXj6k50zhrp9-K48=.10e0c396-c89e-4f65-9371-e3ec0b15fcd1@github.com>
 <Xh_K3fyk4JoFgH3bCBwphTdErOKgunIkjeJvS63yozo=.b99acd52-6e41-4ea0-ab5d-93dc793d12f2@github.com>
Message-ID: <uCQ973SLOxoob-c7rb4gxfZmODCXBr3WvkAvR6kVHDA=.b5b84074-1545-4b6f-8e75-eb2e234a805d@github.com>

On Fri, 9 May 2025 13:28:44 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add an assert to inflateToUTF16 method
>>   Add doc of preconditions to appendChars... methods
>>   Correct misc javadoc
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1901:
> 
>> 1899:         }
>> 1900:         return value;
>> 1901:     }
> 
> I think the logic can be simplified, without a need for the loop.
> 
>     private static byte[] putCharsAt(byte[] value, byte coder, int count, int index, char[] s, int off, int end) {
>         if (isLatin1(coder)) {
>             int latin1Len = StringUTF16.compress(s, off, value, index, end - off);
>             if (latin1Len < end - off) {
>                 value = inflateToUTF16(value, count);
>                 StringUTF16.putCharsSB(value, index + latin1Len, s, off + latin1Len, end);
>             }
>         } else {
>             StringUTF16.putCharsSB(value, index, s, off, end);
>         }
>         return value;
>     }

Unfortunately, my simplification isn't sound when `s` is concurrently modified.
Please disregard.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2081978097

From kbarrett at openjdk.org  Fri May  9 15:59:38 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 9 May 2025 15:59:38 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v6]
In-Reply-To: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
Message-ID: <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com>

> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Merge branch 'master' into native-reference-get
 - use new waitForRefProc, some tidying
 - Merge branch 'master' into native-reference-get
 - remove timeout by using waitForReferenceProcessing
 - make ill-timed gc in non-concurrent case less likely
 - fix test package use
 - add package decl to test
 - parameterized return type of native get0
 - test native method
 - native Reference.get helper

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24315/files
  - new: https://git.openjdk.org/jdk/pull/24315/files/48b7960c..6b4e4c76

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=04-05

  Stats: 6281 lines in 341 files changed: 3313 ins; 1807 del; 1161 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 dfuchs at openjdk.org  Fri May  9 16:01:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 16:01:51 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <xYLb16pp1-tzU59PSQJwkT13-nO_nm6t51FoewRQkEc=.943e14e7-46c2-4620-83c9-b5557b7480ae@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

Changes to net-properties.html LGTM

-------------

PR Review: https://git.openjdk.org/jdk/pull/25148#pullrequestreview-2828873053

From naoto at openjdk.org  Fri May  9 16:08:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 May 2025 16:08:50 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters [v4]
In-Reply-To: <jYgZalrJrqF2-_kpxuxClN3v--h0fBc7QHn2urj-TP0=.d204338a-e538-47b8-8055-f0d840401fe2@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
 <jYgZalrJrqF2-_kpxuxClN3v--h0fBc7QHn2urj-TP0=.d204338a-e538-47b8-8055-f0d840401fe2@github.com>
Message-ID: <d8w5t3NiWOgO1Yrp8hxcnKDEvaBgqBlgewshQe9qLU8=.a37e2def-3802-478d-bc4d-f66dd5519b8a@github.com>

On Fri, 9 May 2025 10:12:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> 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.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify non-ASCII characters with unicode code point

LGTM. Thanks for the changes

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24727#pullrequestreview-2828887346

From darcy at openjdk.org  Fri May  9 16:15:11 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 9 May 2025 16:15:11 GMT
Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal [v2]
In-Reply-To: <sW8AgNknCFUnkZKAns3Pvm-jbPS2XomYipktJhJNxIs=.1f4cddb5-675c-4be9-a7f2-953511f0abdf@github.com>
References: <sW8AgNknCFUnkZKAns3Pvm-jbPS2XomYipktJhJNxIs=.1f4cddb5-675c-4be9-a7f2-953511f0abdf@github.com>
Message-ID: <xHzMrlV37ty92gKaUfMbD394QzKl6oD2XoNipDuWmEs=.604f8669-fba2-483e-99a4-d41d572d579c@github.com>

> Fix javadoc tags.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25131/files
  - new: https://git.openjdk.org/jdk/pull/25131/files/d1c2345a..212261bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25131&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25131&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25131/head:pull/25131

PR: https://git.openjdk.org/jdk/pull/25131

From darcy at openjdk.org  Fri May  9 16:10:57 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 9 May 2025 16:10:57 GMT
Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal
In-Reply-To: <mGKvcmMbSiIrN6z5L9iq7Sb1HQ0D1ZxnQ9sN5JXAApk=.48c6dc9b-62e4-4c5f-989e-a258ddcf69fa@github.com>
References: <sW8AgNknCFUnkZKAns3Pvm-jbPS2XomYipktJhJNxIs=.1f4cddb5-675c-4be9-a7f2-953511f0abdf@github.com>
 <mGKvcmMbSiIrN6z5L9iq7Sb1HQ0D1ZxnQ9sN5JXAApk=.48c6dc9b-62e4-4c5f-989e-a258ddcf69fa@github.com>
Message-ID: <Ft36oqis9UbMqFngT2oCjwt0ueusZPcmEmgWi88P-l0=.29101ce5-81fd-48d6-9f54-6953e1e9c4eb@github.com>

On Fri, 9 May 2025 10:32:27 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> I just noticed there are a couple more javadoc tags that need to be fixed in this class, I still see two more warnings. I should have included these in the JBS issue when filling it.
> 
> ```
> src/java.base/share/classes/java/math/BigDecimal.java:363: warning: reference to non-visible type: BigDecimal.scale (use -protected or -private options to document non-public types)
>      * The scale of this BigDecimal, as returned by {@link #scale}.
>                                                     ^
> src/java.base/share/classes/java/math/BigDecimal.java:366: warning: reference to non-visible type: BigDecimal.scale (use -protected or -private options to document non-public types)
>      * @see #scale
>        ^
>        ```
> ```

Okay; I'll add a fix for that, although the javadoc text is one a private field so is not generated by default.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25131#issuecomment-2867109531

From naoto at openjdk.org  Fri May  9 16:20:00 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 May 2025 16:20:00 GMT
Subject: RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata
 downgrades after JDK-8342550
In-Reply-To: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
References: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
Message-ID: <B0rJU1nYHatPkSnGM0ZAsMYEC_JpmlN_Opc88CWhWaM=.fdac19cd-39e1-4866-a4b1-005a64746508@github.com>

On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case.
> Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25130#issuecomment-2867133483

From naoto at openjdk.org  Fri May  9 16:20:01 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 May 2025 16:20:01 GMT
Subject: Integrated: 8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata
 downgrades after JDK-8342550
In-Reply-To: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
References: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
Message-ID: <Ir6iDLZE7TCkZgJnPy6C4ra8fTLDqTV4jm_Y3EOUCF8=.df4f3a38-cf01-45d2-a51c-0815b37848ff@github.com>

On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case.
> Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater.

This pull request has now been integrated.

Changeset: 5f00c877
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5f00c877e26f1716da231771b611234db5607fa7
Stats:     10 lines in 1 file changed: 7 ins; 1 del; 2 mod

8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata downgrades after JDK-8342550

Reviewed-by: bpb, jlu, joehw

-------------

PR: https://git.openjdk.org/jdk/pull/25130

From nbenalla at openjdk.org  Fri May  9 16:22:51 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 9 May 2025 16:22:51 GMT
Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal [v2]
In-Reply-To: <xHzMrlV37ty92gKaUfMbD394QzKl6oD2XoNipDuWmEs=.604f8669-fba2-483e-99a4-d41d572d579c@github.com>
References: <sW8AgNknCFUnkZKAns3Pvm-jbPS2XomYipktJhJNxIs=.1f4cddb5-675c-4be9-a7f2-953511f0abdf@github.com>
 <xHzMrlV37ty92gKaUfMbD394QzKl6oD2XoNipDuWmEs=.604f8669-fba2-483e-99a4-d41d572d579c@github.com>
Message-ID: <gAHBDV0BQv-uYMwLguFw9If7j-PZ9ml0bnKy4U6HUms=.527986c3-fdfe-4116-9638-eaf4d5c66b21@github.com>

On Fri, 9 May 2025 16:15:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Fix javadoc tags.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Looks good!

-------------

Marked as reviewed by nbenalla (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25131#pullrequestreview-2828933840

From liach at openjdk.org  Fri May  9 16:26:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 16:26:55 GMT
Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal [v2]
In-Reply-To: <xHzMrlV37ty92gKaUfMbD394QzKl6oD2XoNipDuWmEs=.604f8669-fba2-483e-99a4-d41d572d579c@github.com>
References: <sW8AgNknCFUnkZKAns3Pvm-jbPS2XomYipktJhJNxIs=.1f4cddb5-675c-4be9-a7f2-953511f0abdf@github.com>
 <xHzMrlV37ty92gKaUfMbD394QzKl6oD2XoNipDuWmEs=.604f8669-fba2-483e-99a4-d41d572d579c@github.com>
Message-ID: <7YmRRAotqqh-90KZ3CaMwWPiFyevfBiupHI24ORvB3Q=.a418860a-94c1-4539-871c-cc6a66d08725@github.com>

On Fri, 9 May 2025 16:15:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Fix javadoc tags.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25131#pullrequestreview-2828942139

From bpb at openjdk.org  Fri May  9 16:30:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 May 2025 16:30:54 GMT
Subject: RFR: 8356555: Incorrect use of {@link} in BigDecimal [v2]
In-Reply-To: <xHzMrlV37ty92gKaUfMbD394QzKl6oD2XoNipDuWmEs=.604f8669-fba2-483e-99a4-d41d572d579c@github.com>
References: <sW8AgNknCFUnkZKAns3Pvm-jbPS2XomYipktJhJNxIs=.1f4cddb5-675c-4be9-a7f2-953511f0abdf@github.com>
 <xHzMrlV37ty92gKaUfMbD394QzKl6oD2XoNipDuWmEs=.604f8669-fba2-483e-99a4-d41d572d579c@github.com>
Message-ID: <4HYcWFe2bgyoumYenJrfBMcj3xiLYLW1E5JmtHo5Y-0=.054f959f-d30e-4bbc-af3c-5d80c7095631@github.com>

On Fri, 9 May 2025 16:15:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Fix javadoc tags.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25131#pullrequestreview-2828951810

From darcy at openjdk.org  Fri May  9 16:38:59 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 9 May 2025 16:38:59 GMT
Subject: Integrated: 8356555: Incorrect use of {@link} in BigDecimal
In-Reply-To: <sW8AgNknCFUnkZKAns3Pvm-jbPS2XomYipktJhJNxIs=.1f4cddb5-675c-4be9-a7f2-953511f0abdf@github.com>
References: <sW8AgNknCFUnkZKAns3Pvm-jbPS2XomYipktJhJNxIs=.1f4cddb5-675c-4be9-a7f2-953511f0abdf@github.com>
Message-ID: <4Uk4QI1N7TIJegN8bHqwHBo2p4CkqLbbqliLu04ocmg=.d22f26f2-e683-460c-8f10-e34888f4a4e2@github.com>

On Thu, 8 May 2025 21:07:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix javadoc tags.

This pull request has now been integrated.

Changeset: bed29a03
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bed29a03d198a9717f7d258ee21330462775136e
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8356555: Incorrect use of {@link} in BigDecimal

Reviewed-by: bpb, nbenalla, liach, iris

-------------

PR: https://git.openjdk.org/jdk/pull/25131

From rriggs at openjdk.org  Fri May  9 16:41:39 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 May 2025 16:41:39 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v9]
In-Reply-To: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
Message-ID: <iJrQbiBRYwsvUoqSn8pEloR8rSPoBgC17UjuS8g08iY=.18822b98-0d34-41dc-bdb4-ddfae851fd1a@github.com>

> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
> Support methods are static, designed to pass all values as arguments and return a value.
> 
> The value byte array is reallocated under 3 conditions:
> - Increasing the capacity with the same encoder
> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
> - Inflation with the same capacity
> 
> Added StressSBTest to exercise public instance methods of StringBuilder.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Removed extraneous "the"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24967/files
  - new: https://git.openjdk.org/jdk/pull/24967/files/8f731431..e7aa6303

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24967.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24967/head:pull/24967

PR: https://git.openjdk.org/jdk/pull/24967

From almatvee at openjdk.org  Fri May  9 16:49:56 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 9 May 2025 16:49:56 GMT
Subject: Integrated: 8352480: Don't follow symlinks in additional content for
 app images
In-Reply-To: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
References: <Ej7z1w8aD71RiZjvoOEKd7ipR7P9huzdbRct2qtmSwI=.8e7f0a07-6ef0-4f3a-80eb-3caeee18ec46@github.com>
Message-ID: <Nbj2i-bHdnhDYfm5uzqBpQZpw2WGudqitCOZlYasT1c=.1a3a3baf-83a0-49ea-9ca1-342107511cc3@github.com>

On Wed, 30 Apr 2025 20:17:57 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Symbolic links will not be followed for `--app-content` on all platforms.
> - Added test to cover this case.
> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links.

This pull request has now been integrated.

Changeset: 601f05e0
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/601f05e06d3c364ab5b151785d4ac49183cf61b5
Stats:     96 lines in 3 files changed: 57 ins; 24 del; 15 mod

8352480: Don't follow symlinks in additional content for app images

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/24974

From jlu at openjdk.org  Fri May  9 16:54:56 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 9 May 2025 16:54:56 GMT
Subject: RFR: 8355393: Create a Test case to have special cases coverage
 for currency.getInstance()
In-Reply-To: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
Message-ID: <PPMYhIYYJN4Tpait5mRLKCd5GUaEkGkIC3f9ixG1GJo=.2d28500e-e2a6-4502-bbc7-e9818e13e7b2@github.com>

On Tue, 6 May 2025 07:25:36 GMT, Abhishek N <duke at openjdk.org> wrote:

> Create a Test case to have special cases coverage for currency.getInstance().
> 
> The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API.
> 
> test results:
> 
> jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java
> Directory "JTwork" not found: creating
> Directory "JTreport" not found: creating
> Test results: passed: 1
> Report written to JTreport\html\report.html
> Results written to JTwork

Hi @abhn-git, thanks for contributing the test but it's not clear to me what the purpose of this PR is. It seems to be testing the Currency overriding mechanism via the system property but that behavior is already tested. If you are attempting to test the future cut-over behavior for a standard ISO 4217 currency in `currencyData.properties`, the override mechanism does not simulate this 1-1.

For a standard ISO 4217 currency in `currencyData.properties`, a currency transition for a locale can occur at any time, (i.e. subsequent `getInstance(Locale)` calls can return different currencies). For the override mechanism, the transition is checked in the static block, and the resulting currency selected is fixed for the duration of the application's lifecycle.

-------------

Changes requested by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25057#pullrequestreview-2829069916

From rgiulietti at openjdk.org  Fri May  9 16:55:01 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 9 May 2025 16:55:01 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v55]
In-Reply-To: <7M-1pUEDXUNzktL20pvRvodXVXP4Lr88-TaNjt6TNmg=.b1a0c128-56c6-4fab-80e0-e2a5108daff5@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <7M-1pUEDXUNzktL20pvRvodXVXP4Lr88-TaNjt6TNmg=.b1a0c128-56c6-4fab-80e0-e2a5108daff5@github.com>
Message-ID: <_ib9SlZnCi08sAjh2SZ5LrPC3Q4_LK7du9wKhQpsuWE=.f0e5d603-0342-4e9f-a567-54c7b10130d9@github.com>

On Thu, 8 May 2025 16:48:40 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code simplification

Marked as reviewed by rgiulietti (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24690#pullrequestreview-2829069025

From kbarrett at openjdk.org  Fri May  9 16:56:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 9 May 2025 16:56:55 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v4]
In-Reply-To: <xX5EKcKwH9_IR2zSoU40ZHwOTI3pZXOh87v8IDWkKe4=.ce8f4110-855d-407d-ba9a-a9e5f2901d7c@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <KZ41_YxAj8W5EVG9t2V5EOX86wBGgnV9K_iviT2aFZ0=.3fd302c5-63c3-4165-b3a5-340b1c8a586d@github.com>
 <Da-M41gzpUv7UR8e5dmcsBH4LmEzrOq36zNVDdqfgc0=.eaf20690-a632-44eb-8cae-cc5ff1ed3938@github.com>
 <xX5EKcKwH9_IR2zSoU40ZHwOTI3pZXOh87v8IDWkKe4=.ce8f4110-855d-407d-ba9a-a9e5f2901d7c@github.com>
Message-ID: <93k3k6NWe-yOZtaoWAO6UEDM-tcbCnD-2B1sIAin42g=.5a393055-540d-4df5-8fea-9b2bb0a97e1e@github.com>

On Fri, 11 Apr 2025 08:14:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> 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.

Test has now been changed to use the new `WhiteBox::waitForReferenceProcessing()`.
So how about some reviews...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2082106208

From rgiulietti at openjdk.org  Fri May  9 16:56:57 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 9 May 2025 16:56:57 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v9]
In-Reply-To: <iJrQbiBRYwsvUoqSn8pEloR8rSPoBgC17UjuS8g08iY=.18822b98-0d34-41dc-bdb4-ddfae851fd1a@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <iJrQbiBRYwsvUoqSn8pEloR8rSPoBgC17UjuS8g08iY=.18822b98-0d34-41dc-bdb4-ddfae851fd1a@github.com>
Message-ID: <QlEmS3mK6mz4tvQ6GpoFKwPUNzFKlYYabb3KWKuQf1w=.ba23e061-de56-416a-b355-d9cdfe6089ba@github.com>

On Fri, 9 May 2025 16:41:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed extraneous "the"

Thanks @RogerRiggs

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24967#pullrequestreview-2829074577

From duke at openjdk.org  Fri May  9 17:04:00 2025
From: duke at openjdk.org (duke)
Date: Fri, 9 May 2025 17:04:00 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v55]
In-Reply-To: <7M-1pUEDXUNzktL20pvRvodXVXP4Lr88-TaNjt6TNmg=.b1a0c128-56c6-4fab-80e0-e2a5108daff5@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
 <7M-1pUEDXUNzktL20pvRvodXVXP4Lr88-TaNjt6TNmg=.b1a0c128-56c6-4fab-80e0-e2a5108daff5@github.com>
Message-ID: <9JhxqnfUH0boq5pOvDrJWVDheuysPs6OrtmVamMNES4=.fc18b49f-9c24-40d9-b3c1-988c033650fd@github.com>

On Thu, 8 May 2025 16:48:40 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code simplification

@fabioromano1 
Your change (at version 261dd315537f6135a4f065b3dcbcfe045d4a27db) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2867305168

From duke at openjdk.org  Fri May  9 17:09:05 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 9 May 2025 17:09:05 GMT
Subject: Integrated: 8355719: Reduce memory consumption of BigInteger.pow()
In-Reply-To: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
References: <NmByLY3KOGiKMFQYyZxzkUCbvhXFYY0z5nLnt0KOagA=.c0d99cc7-8209-45f8-b32e-46adc4b6f5a1@github.com>
Message-ID: <R-_NIKslEWjGUjJGtggZnbcVCWwhwfn0VJqABlrg6x8=.c09c13f7-e416-4b01-bc73-c2ed7bd5c277@github.com>

On Wed, 16 Apr 2025 13:45:55 GMT, fabioromano1 <duke at openjdk.org> wrote:

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

This pull request has now been integrated.

Changeset: 1c5eb370
Author:    Fabio Romano <fabio19298 at gmail.com>
Committer: Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1c5eb370b7dbe7558b535bf27c9df292c2007b9b
Stats:     329 lines in 2 files changed: 231 ins; 49 del; 49 mod

8355719: Reduce memory consumption of BigInteger.pow()

Reviewed-by: rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/24690

From liach at openjdk.org  Fri May  9 17:14:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 17:14:53 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v9]
In-Reply-To: <iJrQbiBRYwsvUoqSn8pEloR8rSPoBgC17UjuS8g08iY=.18822b98-0d34-41dc-bdb4-ddfae851fd1a@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <iJrQbiBRYwsvUoqSn8pEloR8rSPoBgC17UjuS8g08iY=.18822b98-0d34-41dc-bdb4-ddfae851fd1a@github.com>
Message-ID: <cCLsv0mKVwxiSFxiWgVd1v3HULpI0rHDwXTFeK2mnoA=.21ba0dce-e8ee-45a1-a0b3-d38675d1913e@github.com>

On Fri, 9 May 2025 16:41:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed extraneous "the"

The new safeguards look good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24967#pullrequestreview-2829109097

From joehw at openjdk.org  Fri May  9 17:15:59 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 9 May 2025 17:15:59 GMT
Subject: Integrated: 8353232: Standardizing and Unifying XML Component
 Configurations
In-Reply-To: <uQtTZ15H-YxBBmb1xpXrrcHfgF-S7pxzEK2ydOjQN5I=.d6e3f373-da1f-4dbb-b552-48500f1dc6f5@github.com>
References: <uQtTZ15H-YxBBmb1xpXrrcHfgF-S7pxzEK2ydOjQN5I=.d6e3f373-da1f-4dbb-b552-48500f1dc6f5@github.com>
Message-ID: <-jL2Xj52A9qNbSU-iKomS2rRkQT2MeSJ1q_Ydknej3I=.0a67e659-98b3-4eea-869b-8c02998c2ce3@github.com>

On Wed, 7 May 2025 16:17:07 GMT, Joe Wang <joehw at openjdk.org> wrote:

> This is a refactor patch, no change in functionality.
> 
> This patch refactor the configuration code. Rather than for each factory to go through the whole configuration process, a base configuration as represented in JdkXmlConfig is created once, which includes loading of the JAXP Configuration file, factories then get their own copies of the property managers, created on top of the base ones rather than directly constructed.
> 
> The JDKCatalog and its Resolver are lazily initialized when external references are encountered. This code replaces the original code block within the security manager. This change also addresses JDK-8350189.
> 
> The rest of changes basically replace all direct constructions of XMLSecurityManager/XMLSecurityPropertyManager with calls to JdkXmlConfig's corresponding get methods, which return clones of the base instances. in the factory classes, these clones are updated with property settings on the factories. In non-public or legacy code paths (inherited from upstream components), such updates may not be necessary.
> 
> Tests: existing tests T1-3 passed; XML JCK tests passed.

This pull request has now been integrated.

Changeset: 66f04427
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/66f044271324643ee17df13ad3ef254bc4dbd798
Stats:     582 lines in 31 files changed: 318 ins; 119 del; 145 mod

8353232: Standardizing and Unifying XML Component Configurations

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk/pull/25102

From asemenyuk at openjdk.org  Fri May  9 17:28:19 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 9 May 2025 17:28:19 GMT
Subject: RFR: 8333664: Decouple command line parsing and package building
 in jpackage [v2]
In-Reply-To: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>
References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>
Message-ID: <zGDshFxXHnz4cz4ligl_MYt4Sw9MED956Fve7s8cxqo=.2a3efe3a-c2dc-4058-ac8e-7df8db5c0a9a@github.com>

> Refactor jpackage to separate the configuration and execution phases.
> At the configuration phase, jpackage parses command-line arguments and validates them.
> At the execution phase, jpackage builds a bundle based on data collected at the configuration phase.
> 
> There was no clear separation between these phases. Both used the same data type (`Map<String, Object>`), making it hard to understand and use properly.
> 
> This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling.
> 
> The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map<String, Object>` "params".
> 
> Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers.
> 
> jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html
> 
> **Functional changes**
> jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below.
> 
>  - Minimize copying of the source app image when doing native packaging.
> 
> Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations.
> 
> - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles.
> 
> post- and pre- install PKG scripts for SimplePackageTest package before and after the change:
> <table>
> <thead>
> <tr>
> <th>Script</th>
> <th>New</th>
> <th>Old</th>
> </tr>
> </thead>
> <tbody...

Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits:

 - Add ConfigFilesStasher that allows to save contents of jpackage build directories in external directory; Add clean_stashed_files.sh
 - Adapt JDK-8352480 fix
 - Merge branch 'master' into JDK-8333664
 - Fix javadoc
 - Merge branch 'master' into JDK-8333664
 - 8333568: Test that jpackage doesn't modify R/O files/directories
   
   Reviewed-by: almatvee
 - 8356562: SigningAppImageTwoStepsTest test fails
   
   Reviewed-by: almatvee
 - Remove clean_stashed_files.sh
 - OSVersionCondition: bugfix; CfgFile: minor; signing: fix entitlements
 - Merge branch 'master' into JDK-8333664
 - ... and 500 more: https://git.openjdk.org/jdk/compare/601f05e0...b7865ff0

-------------

Changes: https://git.openjdk.org/jdk/pull/19668/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19668&range=01
  Stats: 23918 lines in 195 files changed: 17145 ins; 5682 del; 1091 mod
  Patch: https://git.openjdk.org/jdk/pull/19668.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19668/head:pull/19668

PR: https://git.openjdk.org/jdk/pull/19668

From asemenyuk at openjdk.org  Fri May  9 17:34:21 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 9 May 2025 17:34:21 GMT
Subject: RFR: 8333664: Decouple command line parsing and package building
 in jpackage [v3]
In-Reply-To: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>
References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>
Message-ID: <lhNKC4eQgpcKGa63if-X5HBOzR6kp5xXlP_Bj9xyAdA=.5deeebdb-cbdc-4013-b0bc-5b505dde0ffc@github.com>

> Refactor jpackage to separate the configuration and execution phases.
> At the configuration phase, jpackage parses command-line arguments and validates them.
> At the execution phase, jpackage builds a bundle based on data collected at the configuration phase.
> 
> There was no clear separation between these phases. Both used the same data type (`Map<String, Object>`), making it hard to understand and use properly.
> 
> This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling.
> 
> The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map<String, Object>` "params".
> 
> Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers.
> 
> jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html
> 
> **Functional changes**
> jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below.
> 
>  - Minimize copying of the source app image when doing native packaging.
> 
> Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations.
> 
> - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles.
> 
> post- and pre- install PKG scripts for SimplePackageTest package before and after the change:
> <table>
> <thead>
> <tr>
> <th>Script</th>
> <th>New</th>
> <th>Old</th>
> </tr>
> </thead>
> <tbody...

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant StandardBundlerParam.createResource()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19668/files
  - new: https://git.openjdk.org/jdk/pull/19668/files/b7865ff0..30e2a722

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19668&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19668&range=01-02

  Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19668.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19668/head:pull/19668

PR: https://git.openjdk.org/jdk/pull/19668

From duke at openjdk.org  Fri May  9 17:42:14 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Fri, 9 May 2025 17:42:14 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v4]
In-Reply-To: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
Message-ID: <-mnTMxvetLwkde03sxvgoVHtnNrrBEUWHwoXuf6wRqA=.94d9759b-a2d9-4eff-afb0-562892b14c15@github.com>

> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail.
> 
> Fix this problem by appending a `.` to library paths after canonicalization on Windows. This trailing dot inhibits `LoadLibrary`'s own appending behavior.

Benjamin Peterson has updated the pull request with a new target base 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:

 - switch platform helper to be mapToNativeLibraryName
 - Merge remote-tracking branch 'upstream/master' into nativelibraries-fix
 - fix spelling
 - new approach: append . to file name on Windows
 - 8348828: Windows dll loading now resolves symlinks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24694/files
  - new: https://git.openjdk.org/jdk/pull/24694/files/70e943c8..58d644a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=02-03

  Stats: 90263 lines in 2420 files changed: 66254 ins; 14855 del; 9154 mod
  Patch: https://git.openjdk.org/jdk/pull/24694.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694

PR: https://git.openjdk.org/jdk/pull/24694

From duke at openjdk.org  Fri May  9 17:42:14 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Fri, 9 May 2025 17:42:14 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v3]
In-Reply-To: <rqRYQYzJUqaM2GQ-8T04L_iZQuIFqKEqR7INmQsMxQI=.7263e67e-50af-4a93-b666-439a934930ae@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <BO3XKg8xPmBsT_cw8N0qZNVCfw2YhtDTtLB4JBT_Mzg=.853a33c5-7c69-4a48-a146-8e64c2bb14d7@github.com>
 <NKxCgSN5nElChgTRYL9xg8oa7pVlyXmafNFhkG3nuw0=.370e9b03-9af0-479a-9006-f89143300ae3@github.com>
 <Mkg-QGSATre8fW8iLj5wk4Ywti6vaIZVNPGQXOr7nWw=.63450aad-474d-4dfc-b9ec-6461cebd6a22@github.com>
 <iyXlIOMdtX9Tc4ku1ho8XOzdQJI_T4W4Qj-JQaO1hMc=.a2a4f4ea-b0ec-41db-90f6-2276439390f1@github.com>
 <Qix6nH8PKCQyILYVg6cJ9VwGwMQghcq6l7A-gS9QWCI=.37745fda-d30e-401d-9bd8-3ab81e6be67e@github.com>
 <rqRYQYzJUqaM2GQ-8T04L_iZQuIFqKEqR7INmQsMxQI=.7263e67e-50af-4a93-b666-439a934930ae@github.com>
Message-ID: <3B3YzTERC8bABG-b9P6fiKfLZnq0HYjH3awaW3jaivY=.30a8f806-20c2-4a2e-b91d-491e0bd1870e@github.com>

On Fri, 9 May 2025 09:10:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Is this documented in the Microsoft document for LoadLibrary? We don't want to rely on undocumented behavior as it could break at any time.

[LoadLibraryEx` documentation](https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibraryexa) states:

To prevent the function from appending ".DLL" to the module name, include a trailing point character (.) in the module name string.

which isn't incompatible with not adding `.dll` when the extension is already present.

Practically speaking, I imagine the behavior of a common operating system API available since at least Windows XP is completly ossified.

> 
> For the prototype, I think you can replace nativeLoaderFileNameSuffix() with mapToNativeLibraryName(String) so that other platforms can "return this". This would give the flexibility to prefix or do other mangling.

I've changed the implementation to do this.

> 
> That said, I'm not so sure that we should changing the JDK to work in this unusual environment. Are you able to name the product that is move-renaming the DLLs and replacing them with sym links? Just trying to get some sense as to whether this is something that many people might run into it.

I understand the narrow reproducer in the bug is weird, but it was isolated from a generically useful system. As I explained in https://bugs.openjdk.org/browse/JDK-8348828?focusedId=14744766&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14744766, this arises in a generic system my company offers for executing tasks in distributed fashion across many machines. We don't have any particular interest in DLLs or even JDK installations; we simply create a symlinks for all data required by tasks that our system is asked to execute.

This system worked fine with JDKS through Java 23 and all previous versions we've tried.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24694#discussion_r2082174367

From vromero at openjdk.org  Fri May  9 17:56:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 9 May 2025 17:56:38 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v8]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <R8STKNBDgmA68EdQ0ZCv3I816482MKqwetdf7xw2sQw=.4eb9760e-7c6d-4434-b06d-595ffb7b004e@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  additional documentation changes and bug fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/d52ec33b..1ff2f2c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=06-07

  Stats: 79 lines in 7 files changed: 41 ins; 7 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

PR: https://git.openjdk.org/jdk/pull/24746

From wxiao at openjdk.org  Fri May  9 18:21:51 2025
From: wxiao at openjdk.org (Weibing Xiao)
Date: Fri, 9 May 2025 18:21:51 GMT
Subject: RFR: 8355393: Create a Test case to have special cases coverage
 for currency.getInstance()
In-Reply-To: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
Message-ID: <Rx9As4Awi1e-G0GMq48N3dsw6NdatXeerTTAEH9OlVU=.9b3a8232-770b-4d7c-b61d-052956bde505@github.com>

On Tue, 6 May 2025 07:25:36 GMT, Abhishek N <duke at openjdk.org> wrote:

> Create a Test case to have special cases coverage for currency.getInstance().
> 
> The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API.
> 
> test results:
> 
> jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java
> Directory "JTwork" not found: creating
> Directory "JTreport" not found: creating
> Test results: passed: 1
> Report written to JTreport\html\report.html
> Results written to JTwork

The root cause of the failure in https://bugs.openjdk.org/browse/JDK-8353433 was written by @coffeys in the bug. Right now It needs a test case to verify when future cut-over time is passing and the currency is going to work properly. Here is the example defined in CurrencyData.properties, "CW=ANG;2026-04-01-04-00-00;XCG".  Technically it needs to overwrite the return value of System.currentTimeMillis() and make it return with future time to trigger the test for future currency.

see this line https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/Currency.java#L423.

BTW, @justin-curtis-lu made the change in the mainline of JDK at https://bugs.openjdk.org/browse/JDK-8354344. Since it is using ClassFiie API, it can not be backported to jdk with version 23 or lower.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2867537361

From smarks at openjdk.org  Fri May  9 18:53:53 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 9 May 2025 18:53:53 GMT
Subject: RFR: 8356486: ReverseOrderListView should override reversed() to
 return `base` [v2]
In-Reply-To: <5KUYc9NQofLb7Ma3HLQuglTCcy6lE_3rHqA_Nzh-iPc=.d6de4b73-3bf7-4245-979f-e58b8554df3b@github.com>
References: <X2vnz1BagQ5K7q-2_oHt9X1JjejNJw5TE44vSUJKeaU=.28fad491-d94c-4fcb-9a44-001a62e0beb4@github.com>
 <5KUYc9NQofLb7Ma3HLQuglTCcy6lE_3rHqA_Nzh-iPc=.d6de4b73-3bf7-4245-979f-e58b8554df3b@github.com>
Message-ID: <EcmWaJdIl65v6Devp2WAIJmMLCWBmBCbsj9cahujOuw=.80da773e-ea94-4c57-8b10-6c832457317b@github.com>

On Fri, 9 May 2025 07:50:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposed to let `ReverseOrderListView::reversed` directly return `base` instead of going though a more complicated code path.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove spurious class
>  - Address comments

Looks good.

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25120#pullrequestreview-2829404293

From smarks at openjdk.org  Fri May  9 18:53:54 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 9 May 2025 18:53:54 GMT
Subject: RFR: 8356486: ReverseOrderListView should override reversed() to
 return `base` [v2]
In-Reply-To: <f_8e1B3BB9mfaf_qz9naA7ARqVgDQP4Q6KUMy514MKU=.e8ecb4af-a4c2-498f-a334-ab442c723760@github.com>
References: <X2vnz1BagQ5K7q-2_oHt9X1JjejNJw5TE44vSUJKeaU=.28fad491-d94c-4fcb-9a44-001a62e0beb4@github.com>
 <EINLtspNPHYrnKfHa4KM28W921Q_CuMpBAvY6H8pnoM=.b554ca1e-732f-4f33-9078-6a34a33fabed@github.com>
 <R1KALQrvyYCiu1BsIG_De23Tvr_f1qnQWDZZDTshqUs=.509f270e-1564-4480-86e1-0fbbc2de5890@github.com>
 <t13IxE_zW9i4zSHjC7EUUU57dJsaZ8_aNV4TedUqQ2E=.f6da327c-79ee-4445-97b8-434f9425bfbd@github.com>
 <f_8e1B3BB9mfaf_qz9naA7ARqVgDQP4Q6KUMy514MKU=.e8ecb4af-a4c2-498f-a334-ab442c723760@github.com>
Message-ID: <h9UrsBC69Qdo_DDiRBc7KiDyEGdT18zkqcXvHaxyyDQ=.c57af0a1-1de1-4240-b224-6ce6b030782f@github.com>

On Fri, 9 May 2025 07:03:30 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> There are some new collections (such as StableList) that are not covered in Basic. But maybe they should have their separate tests?
>
> `UnmodifiableSequencedCollection` double-reversed is not an identity function. But at least, it does not nest, as it returns a new USC with the underlying collection reversed.

Re the testing strategy: perhaps ideally, everything would be covered by MOAT, but its architecture is kind of cobbled together and doesn't support new features very well. The SequencedCollection/Basic tests are decent for SC but there's some uncomfortable overlap with MOAT. So there's some tension here.

For a new "kind" of collection like StableX it's unclear whether they should have their own tests or be added to a centralized place. It would be nice if StableX could rely on the tests for "typical" collection semantics. However, I'm not sure of their semantics of Stable collections when certain operations are performed. It looks like certain operations like contains(), indexOf(), and toArray() all eagerly evaluate the mapper function. So if the values have all been established, all the usual assertions for ordinary unmodifiable collections should apply. However, there are probably other operations that don't want to evaluate the element, so you'll want to have separate tests for those.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25120#discussion_r2082338587

From bchristi at openjdk.org  Fri May  9 19:20:55 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 9 May 2025 19:20:55 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v9]
In-Reply-To: <iJrQbiBRYwsvUoqSn8pEloR8rSPoBgC17UjuS8g08iY=.18822b98-0d34-41dc-bdb4-ddfae851fd1a@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <iJrQbiBRYwsvUoqSn8pEloR8rSPoBgC17UjuS8g08iY=.18822b98-0d34-41dc-bdb4-ddfae851fd1a@github.com>
Message-ID: <48Z0yWp-3t3IYySh3EQflD9TfUnGSTKgHoiM408ZMvE=.f0682895-7a6b-4067-9dda-c6f23996a840@github.com>

On Fri, 9 May 2025 16:41:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed extraneous "the"

Marked as reviewed by bchristi (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24967#pullrequestreview-2829460339

From prr at openjdk.org  Fri May  9 19:24:53 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 19:24:53 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
Message-ID: <tWgLVluDO0fcZ3e9N1V1GU6rmEcz-tyTVkNuJdr06Pw=.749ad3d3-b55a-486b-8d74-40091899e657@github.com>

On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> > test/jdk/java/awt/font/NumericShaper/MTTest.java
> > ```
> > * * @run main/timeout=300/othervm MTTest
> > 
> > 
> > * * @run main/timeout=1200/othervm MTTest
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
> > https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
> > So 300 was fine, and 1200 isn't needed.
> 
> I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

I think 300 is correct for this test. Setting the timeout factor to < 1 is an interesting experiment but I don't think tests that timeout in such a case are automatic candidates to have an increased time out and this one shows why.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2867676176

From naoto at openjdk.org  Fri May  9 19:58:01 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 May 2025 19:58:01 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in
Message-ID: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>

With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/25155/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356420
  Stats: 29 lines in 3 files changed: 21 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/25155.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25155/head:pull/25155

PR: https://git.openjdk.org/jdk/pull/25155

From weijun at openjdk.org  Fri May  9 20:05:10 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 9 May 2025 20:05:10 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v7]
In-Reply-To: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
Message-ID: <vNY7UaUfDQbUMHYep-RikluWmdvHfsH6s8bev3nvhMM=.f7dc3bc4-041a-4854-a9f0-20c5dc82f2da@github.com>

> Finalize the KDF API.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  new algorithms in SunJCE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24520/files
  - new: https://git.openjdk.org/jdk/pull/24520/files/f44dc9bd..aeb82ccf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=05-06

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 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 acobbs at openjdk.org  Fri May  9 20:16:54 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 9 May 2025 20:16:54 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
 <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
Message-ID: <VInvs8NiAub_DyV0XF_p9XniiQ9GTvKWwHX6xR3cjDw=.501b40a5-3206-4327-af1e-329f1ee21781@github.com>

On Thu, 8 May 2025 18:55:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
>> 
>>  - Merge branch 'master' into JDK-8354556
>>  - addressing review comment
>>  - changes to test
>>  - Merge branch 'master' into JDK-8354556
>>  - updating test
>>  - final adjustments
>>  - additional refactorings
>>  - removing unneeded changes
>>  - more refactorings
>>  - more refactorings and tests
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/900b3ff7...5d834ce0
>
> note to reviewers: I had an offline discussion with Dan, I will introduce some changes to the implementation

@vicente-romero-oracle, please see my [`identity-alias-synchronization`](https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:identity-alias-synchronization?files) branch for an example of only having a single `LintCategory` with an alias. This branch passes `make test TEST="langtools_javac"`. This patch is based on an another PR that I already had lying around which had some related changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867784880

From bpb at openjdk.org  Fri May  9 20:18:56 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 May 2025 20:18:56 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in
In-Reply-To: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
Message-ID: <5VNROQyYyBCaN10gxHSokbthQ-kIFC_RvHu9gPQSYxA=.9a58551f-c758-4497-b555-bd2431fe6a7b@github.com>

On Fri, 9 May 2025 19:53:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.

Looks good.

src/java.base/share/classes/java/lang/System.java line 136:

> 134:      *     new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
> 135:      * }
> 136:      * Or with a {@link java.util.Scanner Scanner}:

"Or with" -> "Using a" or "Or using a" for consistency? Up to you.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25155#pullrequestreview-2829563522
PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2082436990

From vromero at openjdk.org  Fri May  9 20:28:12 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 9 May 2025 20:28:12 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  fixing bugs, removing dead code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/1ff2f2c6..ea631161

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=07-08

  Stats: 57 lines in 3 files changed: 12 ins; 34 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

PR: https://git.openjdk.org/jdk/pull/24746

From vromero at openjdk.org  Fri May  9 20:28:14 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 9 May 2025 20:28:14 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
 <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
Message-ID: <BPoc_smVnc5o4qfZIYiUBzfek5OspUXWQrsjODDrnME=.64da805b-726a-4f1c-8b02-025060946455@github.com>

On Thu, 8 May 2025 18:55:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
>> 
>>  - Merge branch 'master' into JDK-8354556
>>  - addressing review comment
>>  - changes to test
>>  - Merge branch 'master' into JDK-8354556
>>  - updating test
>>  - final adjustments
>>  - additional refactorings
>>  - removing unneeded changes
>>  - more refactorings
>>  - more refactorings and tests
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/900b3ff7...5d834ce0
>
> note to reviewers: I had an offline discussion with Dan, I will introduce some changes to the implementation

> @vicente-romero-oracle, please see my [`identity-alias-synchronization`](https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:identity-alias-synchronization?files) branch for an example of only having a single `LintCategory` with an alias. This branch passes `make test TEST="langtools_javac"`. This patch is based on an another PR that I already had lying around which had some related changes.

I was working on something in this line too, just pushed the patch

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867804036

From naoto at openjdk.org  Fri May  9 20:39:27 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 May 2025 20:39:27 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v2]
In-Reply-To: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
Message-ID: <IUaQ6Yonc_bF1-v0A9KMyYJNoQpMQDXBOfJqqV_nuU8=.23dfb463-560d-47f7-9274-82fab0955199@github.com>

> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects a review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25155/files
  - new: https://git.openjdk.org/jdk/pull/25155/files/844aa0a7..496dd39d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25155.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25155/head:pull/25155

PR: https://git.openjdk.org/jdk/pull/25155

From bpb at openjdk.org  Fri May  9 20:39:27 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 May 2025 20:39:27 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v2]
In-Reply-To: <IUaQ6Yonc_bF1-v0A9KMyYJNoQpMQDXBOfJqqV_nuU8=.23dfb463-560d-47f7-9274-82fab0955199@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <IUaQ6Yonc_bF1-v0A9KMyYJNoQpMQDXBOfJqqV_nuU8=.23dfb463-560d-47f7-9274-82fab0955199@github.com>
Message-ID: <h_7SlZ8maw5exHpcZA8pepGAzH3XmEHi1EDjASCpeYk=.215be32c-d910-44f1-a322-409442a528de@github.com>

On Fri, 9 May 2025 20:36:07 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects a review comment

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25155#pullrequestreview-2829592684

From naoto at openjdk.org  Fri May  9 20:39:27 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 May 2025 20:39:27 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v2]
In-Reply-To: <5VNROQyYyBCaN10gxHSokbthQ-kIFC_RvHu9gPQSYxA=.9a58551f-c758-4497-b555-bd2431fe6a7b@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <5VNROQyYyBCaN10gxHSokbthQ-kIFC_RvHu9gPQSYxA=.9a58551f-c758-4497-b555-bd2431fe6a7b@github.com>
Message-ID: <tinXktGBtFIxBaQ5FyRkYfyaA8AMJCEsX0P4cuf4bs0=.a182782c-b477-4790-9b83-8d4f6a9ccfa6@github.com>

On Fri, 9 May 2025 20:15:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects a review comment
>
> src/java.base/share/classes/java/lang/System.java line 136:
> 
>> 134:      *     new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
>> 135:      * }
>> 136:      * Or with a {@link java.util.Scanner Scanner}:
> 
> "Or with" -> "Using a" or "Or using a" for consistency? Up to you.

Thanks. That flows better. Corrected.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2082453780

From bpb at openjdk.org  Fri May  9 20:39:28 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 May 2025 20:39:28 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v2]
In-Reply-To: <tinXktGBtFIxBaQ5FyRkYfyaA8AMJCEsX0P4cuf4bs0=.a182782c-b477-4790-9b83-8d4f6a9ccfa6@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <5VNROQyYyBCaN10gxHSokbthQ-kIFC_RvHu9gPQSYxA=.9a58551f-c758-4497-b555-bd2431fe6a7b@github.com>
 <tinXktGBtFIxBaQ5FyRkYfyaA8AMJCEsX0P4cuf4bs0=.a182782c-b477-4790-9b83-8d4f6a9ccfa6@github.com>
Message-ID: <SUPI3zroopDcyAjcSy4R2oUcXuP33Hdkg1UIRYSSHPo=.c9fd6ae7-dff2-4c69-a6aa-a93091a1e2a2@github.com>

On Fri, 9 May 2025 20:31:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 136:
>> 
>>> 134:      *     new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
>>> 135:      * }
>>> 136:      * Or with a {@link java.util.Scanner Scanner}:
>> 
>> "Or with" -> "Using a" or "Or using a" for consistency? Up to you.
>
> Thanks. That flows better. Corrected.

You're welcome. Re-approved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2082457972

From aturbanov at openjdk.org  Fri May  9 20:41:11 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 9 May 2025 20:41:11 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v12]
In-Reply-To: <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>
Message-ID: <QQz0fuco5e10bsnlLrLkV-52s9ONaPJwfqCpXfZCfK4=.75cd9f62-b37c-4c7d-8883-0b8333322131@github.com>

On Tue, 6 May 2025 20:52:34 GMT, Markus KARG <duke at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - merge latest from master branch
>  - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted?
>  - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs
>  - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since.
>  - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.'
>  - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars()
>  - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()
>  - 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)'
>  - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted?
>  - Applied changes requested by Alan: Copies chars from this sequence into the given destination array
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a

src/java.base/share/classes/java/lang/CharSequence.java line 313:

> 311:      * at index {@code dstBegin} and ending at index:
> 312:      * <pre>{@code
> 313:      * dstbegin + (srcEnd-srcBegin) - 1

Shouldn't it be dstBegin?

* dstBegin + (srcEnd-srcBegin) - 1

src/java.base/share/classes/java/lang/CharSequence.java line 329:

> 327:      *             {@code this.length()}.
> 328:      *             <li>{@code dstBegin+srcEnd-srcBegin} is greater than
> 329:      *             {@code dst.length}

I think we should have `.` at the end of each case. Now it's inconsistent

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2082456985
PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2082459665

From liach at openjdk.org  Fri May  9 20:46:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 20:46:57 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
Message-ID: <5xTeZSIFVd9QbREf8ocKEh-nZ9Jx_kd2mUNgc8lJJMA=.80ec43f7-5d16-4dc3-9948-5f9d92f0d903@github.com>

On Fri, 9 May 2025 20:28:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing bugs, removing dead code

make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 2216:

> 2214:             }
> 2215:             case ModuleMainClassAttribute a -> ((ModuleHeaderDescription) feature).moduleMainClass = a.mainClass().asInternalName();
> 2216:             case RuntimeVisibleTypeAnnotationsAttribute a -> {/* do nothing for now */}

I think this will make createsymbol created older reference/weakhashmap APIs' type parameter for older releases always have this annotation; but this should be fine. We can fix this for 26. The question is that now their type parameter and the actual parameter uses will see some inconsistent values for releases < 25 in the future.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2082465503

From prr at openjdk.org  Fri May  9 20:53:52 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 20:53:52 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <Smz6J8OkGf1azxvWU7doxgpYm42StyU8_196s8ZNmGU=.70a7da27-72e6-40dc-81b0-c57f65d4cfdc@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25148#pullrequestreview-2829627877

From iris at openjdk.org  Fri May  9 20:56:52 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 9 May 2025 20:56:52 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v2]
In-Reply-To: <IUaQ6Yonc_bF1-v0A9KMyYJNoQpMQDXBOfJqqV_nuU8=.23dfb463-560d-47f7-9274-82fab0955199@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <IUaQ6Yonc_bF1-v0A9KMyYJNoQpMQDXBOfJqqV_nuU8=.23dfb463-560d-47f7-9274-82fab0955199@github.com>
Message-ID: <mh0_JkWTqcvl7J4YJVRrfc-Oqi4yf6cGXOzRIuLWF_g=.6aefde1d-6b41-4777-8cf1-f8223fc40354@github.com>

On Fri, 9 May 2025 20:39:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects a review comment

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25155#pullrequestreview-2829630775

From vromero at openjdk.org  Fri May  9 20:56:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 9 May 2025 20:56:54 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <5xTeZSIFVd9QbREf8ocKEh-nZ9Jx_kd2mUNgc8lJJMA=.80ec43f7-5d16-4dc3-9948-5f9d92f0d903@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
 <5xTeZSIFVd9QbREf8ocKEh-nZ9Jx_kd2mUNgc8lJJMA=.80ec43f7-5d16-4dc3-9948-5f9d92f0d903@github.com>
Message-ID: <6zIXpQATpCOWVMh3AdcX0h7_M8H2nqHgK2Ok9ym7sys=.035df212-854c-4b1a-968c-0f3853d13c5a@github.com>

On Fri, 9 May 2025 20:43:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing bugs, removing dead code
>
> make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 2216:
> 
>> 2214:             }
>> 2215:             case ModuleMainClassAttribute a -> ((ModuleHeaderDescription) feature).moduleMainClass = a.mainClass().asInternalName();
>> 2216:             case RuntimeVisibleTypeAnnotationsAttribute a -> {/* do nothing for now */}
> 
> I think this will make createsymbol created older reference/weakhashmap APIs' type parameter for older releases always have this annotation; but this should be fine. We can fix this for 26. The question is that now their type parameter and the actual parameter uses will see some inconsistent values for releases < 25 in the future.

Jan is taking a look at the changes for CreateSymbols. The change included in this PR is the minimum for the build to pass, I will double check with him if what he is doing will be pushed in a separate PR or as part of this PR, not sure yet. Time is tight and we want this in 25 this is why I decided to move on with this PR even though the CreateSymbols code complete. I forgot to mention this before, sorry

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2082482663

From liach at openjdk.org  Fri May  9 20:56:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 20:56:53 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v2]
In-Reply-To: <IUaQ6Yonc_bF1-v0A9KMyYJNoQpMQDXBOfJqqV_nuU8=.23dfb463-560d-47f7-9274-82fab0955199@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <IUaQ6Yonc_bF1-v0A9KMyYJNoQpMQDXBOfJqqV_nuU8=.23dfb463-560d-47f7-9274-82fab0955199@github.com>
Message-ID: <uHkKOA301QC7Ttm5sXGwK_Q6-11kSqQT-jkZ_Q6qlFg=.3eae1ad8-44ea-46fc-bc0d-9177c6fb3d33@github.com>

On Fri, 9 May 2025 20:39:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects a review comment

src/java.base/share/classes/java/util/Scanner.java line 81:

> 79:  * }
> 80:  *
> 81:  * <p>To read lines from {@link System#in} with {@link System##stdin.encoding

Other 2 example paragraphs start with "this code allows..." and I think we should start this paragraph with: (you might need to wrap lines)
Suggestion:

 * <p>This code reads lines from {@link System#in} with {@link System##stdin.encoding

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2082482111

From rriggs at openjdk.org  Fri May  9 21:02:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 May 2025 21:02:55 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v16]
In-Reply-To: <2AyhnZiLia6FKXoJlSzArzhIiWCchzGM_EJ9hWj93_Y=.175dfeff-fc4e-46f8-9c80-413b9e4971e3@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <2AyhnZiLia6FKXoJlSzArzhIiWCchzGM_EJ9hWj93_Y=.175dfeff-fc4e-46f8-9c80-413b9e4971e3@github.com>
Message-ID: <iZ7ZlG8-TI1cBqQFuP_PBAz_W_Ei45nigtVTm1tCL48=.e1f0fe1c-c087-4b5c-b186-f9d5c37aedaf@github.com>

On Tue, 6 May 2025 15:43:07 GMT, Brian Burkhalter <bpb at openjdk.org> 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: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test

This is right pair of methods on Reader to cover the use cases. 
The names are clear and concise.
Some editorial suggestions are included to the text, use as you see fit.
I think its clear and complete enough to get the CSR drafted and into the proposed queue for review for JDK 25.

src/java.base/share/classes/java/io/Reader.java line 438:

> 436:      *
> 437:      * @throws     IOException  If an I/O error occurs
> 438:      *

Editorial suggestion:
Literally/liberally use the description of lines and terminators from String.lines().
Move the implementation limit to the @apiNote and reduce to the maximum size of UTF16 strings.
Added the @throw for OOME, to make it clear there is a limit that also applies to readAllLines().

Suggestion:

    /**
     * Reads all remaining characters as lines of text.
     * <p>
     * A <i>line</i> is either a sequence of zero or more characters
     * followed by a line terminator, or it is a sequence of one or
     * more characters followed by the end of the stream.
     * A line does not include the line terminator.
     * <p>
     * A <i>line terminator</i> is one of the following:
     * a line feed character {@code "\n"} (U+000A),
     * a carriage return character {@code "\r"} (U+000D),
     * or a carriage return followed immediately by a line feed
     * {@code "\r\n"} (U+000D U+000A).
     *
     * <p>  The method does not close this reader nor its underlying stream.
     * If an I/O error occurs, the states of the reader and its underlying
     * stream are unspecified.
     *
     * @apiNote
     * This method is intended for simple cases where it is convenient
     * to read all remaining characters in a single operation. It is not
     * intended for reading a large number of characters, for example, greater than 1G.
     *
     * @return     the remaining characters as lines of text stored in an
     *             unmodifiable {@code List} of strings in the order they are read
     *
     * @throws     IOException  If an I/O error occurs
     * @throws     OutOfMemoryError  If the number of remaining characters exceeds the
     *              implementation limit for String.
     *

src/java.base/share/classes/java/io/Reader.java line 470:

> 468:      * @throws     OutOfMemoryError  If the remaining content is extremely
> 469:      *                               large, for example larger than {@code 2GB}
> 470:      *

Editorial suggestions:
Change 'content' to 'characters' to match rest of descriptions.
Move mention of implementation limit, 1G to the @apiNote
Changed the @throw OOME to just say it exceeds the implementation limit of string.

Suggestion:

    /**
     * Reads all remaining characters into a string.
     *
     * <p> This method reads all remaining characters including all line separators
     * to the end of the stream. The resulting string will contain line
     * separators as they appear in the stream.
     *
     * <p>  The method does not close this reader nor its underlying stream.
     * If an I/O error occurs, the states of the reader and its underlying
     * stream are unspecified.
     *
     * @apiNote
     * This method is intended for simple cases where it is appropriate and
     * convenient to read all remaining characters into a String. It is not
     * intended for reading a large number of characters, for example, greater than 1G.
     *
     * @return     a String containing all remaining characters
     *
     * @throws     IOException       If an I/O error occurs
     * @throws     OutOfMemoryError  If the number of remaining characters exceeds the
     *              implementation limit for String.
     *

-------------

PR Review: https://git.openjdk.org/jdk/pull/24728#pullrequestreview-2829623531
PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2082474638
PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2082474398

From acobbs at openjdk.org  Fri May  9 21:09:53 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 9 May 2025 21:09:53 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <BPoc_smVnc5o4qfZIYiUBzfek5OspUXWQrsjODDrnME=.64da805b-726a-4f1c-8b02-025060946455@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
 <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
 <BPoc_smVnc5o4qfZIYiUBzfek5OspUXWQrsjODDrnME=.64da805b-726a-4f1c-8b02-025060946455@github.com>
Message-ID: <ke72Wce0xsvGp_9sZM-YBpn5MeoiAKH2oOcrtvbm_go=.f1c89d3b-3b84-4184-9861-f87cefc85f64@github.com>

On Fri, 9 May 2025 20:25:40 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> I was working on something in this line too, just pushed the patch

Looks reasonable, a couple of comments...

Can't `LintCategory.alias` be `final`? If so I think this obviates the patch to `DetectMutableStaticFields.java`.

This is not a general solution to aliasing of lint categories. For example, if someone were to add an alias `filenames` for `path`, then [this code](https://github.com/openjdk/jdk/blob/68a118509a562334eb8c099129d79520041b10cf/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java#L506-L507) and a few other examples like it would break.

Do we care about that? If so then we might want to implement a proper fix for lint aliases as a separate pre-requisite to this issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867878715

From liach at openjdk.org  Fri May  9 21:09:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 21:09:54 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
Message-ID: <-kiskE2-Ejcqxz1znbiJRJ-ZtGdkyZmY7awv7fasv4E=.a52127c6-0339-473b-8018-a97aa93f9efb@github.com>

On Fri, 9 May 2025 20:28:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing bugs, removing dead code

Note: The tests and the core library changes look good to me.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 428:

> 426:             this.alias = alias;
> 427:             map.put(option, this);
> 428:             // we need to do this as forward references are not allowed

Suggestion:


Redundant comment from last revision.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 454:

> 452:         public final boolean annotationSuppression;
> 453: 
> 454:         public String alias;

Suggestion:

        public final String alias;

We are no longer storing LintCategory objects.

test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java line 96:

> 94:         ignore("com/sun/tools/javac/file/JRTIndex", "sharedInstance");
> 95:         ignore("com/sun/tools/javac/main/JavaCompiler", "versionRB");
> 96:         ignore("com/sun/tools/javac/code/Lint$LintCategory", "alias");

Can remove this once alias is final

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867879980
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2082492124
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2082496953
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2082497326

From rriggs at openjdk.org  Fri May  9 21:12:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 May 2025 21:12:53 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v2]
In-Reply-To: <IUaQ6Yonc_bF1-v0A9KMyYJNoQpMQDXBOfJqqV_nuU8=.23dfb463-560d-47f7-9274-82fab0955199@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <IUaQ6Yonc_bF1-v0A9KMyYJNoQpMQDXBOfJqqV_nuU8=.23dfb463-560d-47f7-9274-82fab0955199@github.com>
Message-ID: <ogHQ3PoOcoLH3xBaddo4C8pWY7rxIAjswRhO6simpRM=.d67e2d4d-5dda-4e38-9f59-1b1087e4e48d@github.com>

On Fri, 9 May 2025 20:39:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects a review comment

src/java.base/share/classes/java/lang/System.java line 135:

> 133:      * {@snippet lang=java :
> 134:      *     new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
> 135:      * }

So, ok as far as it goes.  Does this example imply that one should always use the 2 arg constructor.
When should the 1-arg constructor that uses the defaultEncoding vs the 2-arg constructor with stdin.encoding be used?
Is that understood to be described elsewhere?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2082502132

From liach at openjdk.org  Fri May  9 21:12:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 21:12:53 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <ke72Wce0xsvGp_9sZM-YBpn5MeoiAKH2oOcrtvbm_go=.f1c89d3b-3b84-4184-9861-f87cefc85f64@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
 <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
 <BPoc_smVnc5o4qfZIYiUBzfek5OspUXWQrsjODDrnME=.64da805b-726a-4f1c-8b02-025060946455@github.com>
 <ke72Wce0xsvGp_9sZM-YBpn5MeoiAKH2oOcrtvbm_go=.f1c89d3b-3b84-4184-9861-f87cefc85f64@github.com>
Message-ID: <m8gmGD58e_TJJ0ik_n842YC7bACrA_wYqNED6QZbeos=.58a6b464-4313-474e-9362-d7f80fbac8f1@github.com>

On Fri, 9 May 2025 21:06:09 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Do we care about that? If so then we might want to implement a proper fix for lint aliases as a separate pre-requisite to this issue.

I think if we do that, we should encapsulate `option` and move all access, such as `option.isSet`, to dedicated methods on `LintCategory`. We are a bit short on time for this, so IMO our best approach is to open a followup issue that we can work on for 26 given the short time to RDP1.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867884046

From acobbs at openjdk.org  Fri May  9 21:27:54 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 9 May 2025 21:27:54 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <m8gmGD58e_TJJ0ik_n842YC7bACrA_wYqNED6QZbeos=.58a6b464-4313-474e-9362-d7f80fbac8f1@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
 <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
 <BPoc_smVnc5o4qfZIYiUBzfek5OspUXWQrsjODDrnME=.64da805b-726a-4f1c-8b02-025060946455@github.com>
 <ke72Wce0xsvGp_9sZM-YBpn5MeoiAKH2oOcrtvbm_go=.f1c89d3b-3b84-4184-9861-f87cefc85f64@github.com>
 <m8gmGD58e_TJJ0ik_n842YC7bACrA_wYqNED6QZbeos=.58a6b464-4313-474e-9362-d7f80fbac8f1@github.com>
Message-ID: <WP_HCElTvyntrwXlrXvgC-hLlyaftjWDDYtThJwG-Kk=.7a0810c7-f185-407f-8908-87f3c4870173@github.com>

On Fri, 9 May 2025 21:09:46 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think if we do that, we should encapsulate `option` and move all access, such as `option.isSet`, to dedicated methods on `LintCategory`. We are a bit short on time for this, so IMO our best approach is to open a followup issue that we can work on for 26 given the short time to RDP1.

That's why I was offering my existing patch which basically does that already. But it's OK to wait if you prefer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867906064

From naoto at openjdk.org  Fri May  9 21:29:09 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 May 2025 21:29:09 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v3]
In-Reply-To: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
Message-ID: <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com>

> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects another review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25155/files
  - new: https://git.openjdk.org/jdk/pull/25155/files/496dd39d..6f8101cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25155.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25155/head:pull/25155

PR: https://git.openjdk.org/jdk/pull/25155

From naoto at openjdk.org  Fri May  9 21:29:09 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 May 2025 21:29:09 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v2]
In-Reply-To: <ogHQ3PoOcoLH3xBaddo4C8pWY7rxIAjswRhO6simpRM=.d67e2d4d-5dda-4e38-9f59-1b1087e4e48d@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <IUaQ6Yonc_bF1-v0A9KMyYJNoQpMQDXBOfJqqV_nuU8=.23dfb463-560d-47f7-9274-82fab0955199@github.com>
 <ogHQ3PoOcoLH3xBaddo4C8pWY7rxIAjswRhO6simpRM=.d67e2d4d-5dda-4e38-9f59-1b1087e4e48d@github.com>
Message-ID: <8dzBg7q2XBJFz4Yajv7C-odescuIL8Qe2xterGxOZ98=.7fc22c24-d9d6-4d56-ade0-fcd9de470a5e@github.com>

On Fri, 9 May 2025 21:10:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects a review comment
>
> src/java.base/share/classes/java/lang/System.java line 135:
> 
>> 133:      * {@snippet lang=java :
>> 134:      *     new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
>> 135:      * }
> 
> So, ok as far as it goes.  Does this example imply that one should always use the 2 arg constructor.
> When should the 1-arg constructor that uses the defaultEncoding vs the 2-arg constructor with stdin.encoding be used?
> Is that understood to be described elsewhere?

For reading from `System.in`, yes. For other cases, depends on the user's situation. This is the first to modify our documents to guide users as `stdin.encoding` is a new property. There are some descriptions for `System.out` and `System.err` in the JEP 400 though. Probably we will need to update the JEP too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2082519023

From naoto at openjdk.org  Fri May  9 21:29:09 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 May 2025 21:29:09 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v2]
In-Reply-To: <uHkKOA301QC7Ttm5sXGwK_Q6-11kSqQT-jkZ_Q6qlFg=.3eae1ad8-44ea-46fc-bc0d-9177c6fb3d33@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <IUaQ6Yonc_bF1-v0A9KMyYJNoQpMQDXBOfJqqV_nuU8=.23dfb463-560d-47f7-9274-82fab0955199@github.com>
 <uHkKOA301QC7Ttm5sXGwK_Q6-11kSqQT-jkZ_Q6qlFg=.3eae1ad8-44ea-46fc-bc0d-9177c6fb3d33@github.com>
Message-ID: <YikCuxLOXSTykBlRufzI8flkwnkdlkecBtGP_cGFv8E=.7e952059-3eee-4db2-8d51-69bb7792dbd1@github.com>

On Fri, 9 May 2025 20:53:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects a review comment
>
> src/java.base/share/classes/java/util/Scanner.java line 81:
> 
>> 79:  * }
>> 80:  *
>> 81:  * <p>To read lines from {@link System#in} with {@link System##stdin.encoding
> 
> Other 2 example paragraphs start with "this code allows..." and I think we should start this paragraph with: (you might need to wrap lines)
> Suggestion:
> 
>  * <p>This code reads lines from {@link System#in} with {@link System##stdin.encoding

Thanks. Modified

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2082520238

From rriggs at openjdk.org  Fri May  9 21:50:58 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 May 2025 21:50:58 GMT
Subject: Integrated: 8351443: Improve robustness of StringBuilder
In-Reply-To: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
Message-ID: <fNg7T2EN_dfoBkme5sS1JAe2LRu3epjgql_s6sWB78I=.e40857da-cd63-44fa-9a2b-231c6c01095f@github.com>

On Wed, 30 Apr 2025 14:12:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
> Support methods are static, designed to pass all values as arguments and return a value.
> 
> The value byte array is reallocated under 3 conditions:
> - Increasing the capacity with the same encoder
> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
> - Inflation with the same capacity
> 
> Added StressSBTest to exercise public instance methods of StringBuilder.

This pull request has now been integrated.

Changeset: 8fadf295
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8fadf295b0ba720a5bc728c6b4d159e60447de97
Stats:     1010 lines in 8 files changed: 733 ins; 68 del; 209 mod

8351443: Improve robustness of StringBuilder

Reviewed-by: liach, rgiulietti, bchristi, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/24967

From rgiulietti at openjdk.org  Fri May  9 22:34:48 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 9 May 2025 22:34:48 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v8]
In-Reply-To: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
Message-ID: <Y5Bf4PcRm-vhEtCdYtmvilWgR4n5eNKL4mEL3PMrrUI=.2896f961-e4b8-4296-a1da-20ea00cc7674@github.com>

> See the JBS bug for some details.

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Added javadoc to refer to the grammar in j.l.Double.
 - Merge branch 'master' into 8343829
 - Make some static arrays @Stable.
 - Remove unused BIG_DECIMAL_EXPONENT
 - Merge branch 'master' into 8343829
 - Merge branch 'master' into 8343829
 - Redacted comments.
 - Merge branch 'master' into 8343829
 - Minors in comments.
 - Removed repeated comment.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/ad02a4cb...9d14562a

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22737/files
  - new: https://git.openjdk.org/jdk/pull/22737/files/41d070ec..9d14562a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=06-07

  Stats: 20641 lines in 746 files changed: 12447 ins; 4900 del; 3294 mod
  Patch: https://git.openjdk.org/jdk/pull/22737.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22737/head:pull/22737

PR: https://git.openjdk.org/jdk/pull/22737

From liach at openjdk.org  Fri May  9 22:41:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 22:41:58 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <WP_HCElTvyntrwXlrXvgC-hLlyaftjWDDYtThJwG-Kk=.7a0810c7-f185-407f-8908-87f3c4870173@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
 <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
 <BPoc_smVnc5o4qfZIYiUBzfek5OspUXWQrsjODDrnME=.64da805b-726a-4f1c-8b02-025060946455@github.com>
 <ke72Wce0xsvGp_9sZM-YBpn5MeoiAKH2oOcrtvbm_go=.f1c89d3b-3b84-4184-9861-f87cefc85f64@github.com>
 <m8gmGD58e_TJJ0ik_n842YC7bACrA_wYqNED6QZbeos=.58a6b464-4313-474e-9362-d7f80fbac8f1@github.com>
 <WP_HCElTvyntrwXlrXvgC-hLlyaftjWDDYtThJwG-Kk=.7a0810c7-f185-407f-8908-87f3c4870173@github.com>
Message-ID: <CdtTwok4N_tN_rF-m6hmHx4frol7Yz7RuGuXg2d50Ek=.a6b01a79-5410-404a-9773-e9e406c17d01@github.com>

On Fri, 9 May 2025 21:24:58 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> That's why I was offering my existing patch which basically does that already. But it's OK to wait if you prefer.

Sure, I think vicente is open to patches and PRs to his fork. And I can help review; just remember to @liach.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867998674

From rgiulietti at openjdk.org  Fri May  9 22:48:34 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 9 May 2025 22:48:34 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v9]
In-Reply-To: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
Message-ID: <LS-sIBRy1Kgr5ysuB7SisZlUP-DGTvWkf8yiUvJsLUI=.2a3b2780-deb9-49c1-9f59-30ded314c4c3@github.com>

> See the JBS bug for some details.

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:

 - Removed useless comment.
 - Merge branch 'master' into 8343829
 - Added javadoc to refer to the grammar in j.l.Double.
 - Merge branch 'master' into 8343829
 - Make some static arrays @Stable.
 - Remove unused BIG_DECIMAL_EXPONENT
 - Merge branch 'master' into 8343829
 - Merge branch 'master' into 8343829
 - Redacted comments.
 - Merge branch 'master' into 8343829
 - ... and 4 more: https://git.openjdk.org/jdk/compare/e19291a2...88fe2c08

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22737/files
  - new: https://git.openjdk.org/jdk/pull/22737/files/9d14562a..88fe2c08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=07-08

  Stats: 1064 lines in 14 files changed: 761 ins; 81 del; 222 mod
  Patch: https://git.openjdk.org/jdk/pull/22737.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22737/head:pull/22737

PR: https://git.openjdk.org/jdk/pull/22737

From liach at openjdk.org  Fri May  9 23:02:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 23:02:00 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v9]
In-Reply-To: <LS-sIBRy1Kgr5ysuB7SisZlUP-DGTvWkf8yiUvJsLUI=.2a3b2780-deb9-49c1-9f59-30ded314c4c3@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
 <LS-sIBRy1Kgr5ysuB7SisZlUP-DGTvWkf8yiUvJsLUI=.2a3b2780-deb9-49c1-9f59-30ded314c4c3@github.com>
Message-ID: <MFj2qSpVPBKYBDuyh9Q2JMfHyrRkKsx5NB9X3uhFDnk=.0c7e2e14-4fac-4a56-8653-482c21dd2075@github.com>

On Fri, 9 May 2025 22:48:34 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> See the JBS bug for some details.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Removed useless comment.
>  - Merge branch 'master' into 8343829
>  - Added javadoc to refer to the grammar in j.l.Double.
>  - Merge branch 'master' into 8343829
>  - Make some static arrays @Stable.
>  - Remove unused BIG_DECIMAL_EXPONENT
>  - Merge branch 'master' into 8343829
>  - Merge branch 'master' into 8343829
>  - Redacted comments.
>  - Merge branch 'master' into 8343829
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/e0e999c4...88fe2c08

Took a look over the string parsing part. Not professional enough about floating numbers.

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1964:

> 1962: 
> 1963:         /* Skip opt [FfDd]? suffix. */
> 1964:         if (i < len && (((ch = in.charAt(i) | 0b10_0000)) == 'f' || ch == 'd')) {

Is it really right to ignore these suffix for all ix values?

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 2006:

> 2004:          *
> 2005:          *         |lz            |pt |tnz  |stop
> 2006:          * 0000000012345600000023.4567000000000

Suggestion:

         *         |lz            |pt |tnz     |stop
         * 0000000012345600000023.4567000000000

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 2265:

> 2263: 
> 2264:     /* Arithmetically "appends the digit" ch to v >= 0, clamping at 10^10. */
> 2265:     private static long appendDigit(long v, int ch) {

Since this appends only decimal digit, should we name it `appendDecDegit`? In the use site we already note all exponents are decimals.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22737#pullrequestreview-2829815281
PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2082593368
PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2082588752
PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2082592192

From naoto at openjdk.org  Fri May  9 23:18:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 May 2025 23:18:50 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <UqQ7Tm8xYaIcxM4GvA9ISQi7kDMs1WwuEvbC2kRo1CQ=.a38e9c07-04dd-4fba-a118-4afd33951c06@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25148#pullrequestreview-2829881137

From bchristi at openjdk.org  Fri May  9 23:28:25 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 9 May 2025 23:28:25 GMT
Subject: RFR: 8356107: [java.lang] Use @requires tag instead of exiting based
 on os.name or separatorChar property
Message-ID: <tZiBKIvIBGsfgLaEtvf87nGGC4cdBrLkPYMNRlIHg1Q=.bcc1ff0b-ca04-4adc-9f61-9641c33f1807@github.com>

For `java.lang` tests, use the `@requires` facility in place of checking the `os.name` system property or `File.separatorChar`.

Automated test results are omitted as expected.

-------------

Commit messages:
 - add @requires

Changes: https://git.openjdk.org/jdk/pull/25163/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25163&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356107
  Stats: 20 lines in 4 files changed: 4 ins; 10 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25163.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25163/head:pull/25163

PR: https://git.openjdk.org/jdk/pull/25163

From almatvee at openjdk.org  Fri May  9 23:42:26 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 9 May 2025 23:42:26 GMT
Subject: RFR: 8356664: [macos] AppContentTest fails after JDK-8352480
Message-ID: <K3Fsdclj065E8rIypNMsh2b3lTv1yo5Y5aB_w4YHV1w=.991b336b-21ce-4540-a59a-dc3bf20b3d51@github.com>

- Regression from JDK-8352480.
- On macOS we should create `Links` folder under `Resources`. Which means `--app-content` should point to `app-content/Resources` and not to `app-content/Resources/Links`.

-------------

Commit messages:
 - 8356664: [macos] AppContentTest fails after JDK-8352480

Changes: https://git.openjdk.org/jdk/pull/25164/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25164&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356664
  Stats: 7 lines in 1 file changed: 4 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25164/head:pull/25164

PR: https://git.openjdk.org/jdk/pull/25164

From bpb at openjdk.org  Fri May  9 23:45:51 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 May 2025 23:45:51 GMT
Subject: RFR: 8356107: [java.lang] Use @requires tag instead of exiting
 based on os.name or separatorChar property
In-Reply-To: <tZiBKIvIBGsfgLaEtvf87nGGC4cdBrLkPYMNRlIHg1Q=.bcc1ff0b-ca04-4adc-9f61-9641c33f1807@github.com>
References: <tZiBKIvIBGsfgLaEtvf87nGGC4cdBrLkPYMNRlIHg1Q=.bcc1ff0b-ca04-4adc-9f61-9641c33f1807@github.com>
Message-ID: <SA4sHJfxN1fZpxHzCwP4e0v5D4H-xXE10hjpUgsMeWA=.a4f1a057-5136-421e-b201-13aef1a76569@github.com>

On Fri, 9 May 2025 23:23:27 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> For `java.lang` tests, use the `@requires` facility in place of checking the `os.name` system property or `File.separatorChar`.
> 
> Automated test results are omitted as expected.

test/jdk/java/lang/RuntimeTests/exec/Space.java line 42:

> 40:                 throw new RuntimeException("Extra space in command.");
> 41:         } catch (IOException e) {
> 42:             // not Win NT - cmd doesnt exist

As long as you're there: `doesnt` -> `doesn't`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25163#discussion_r2082640179

From naoto at openjdk.org  Sat May 10 00:27:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 10 May 2025 00:27:51 GMT
Subject: RFR: 8356107: [java.lang] Use @requires tag instead of exiting
 based on os.name or separatorChar property
In-Reply-To: <tZiBKIvIBGsfgLaEtvf87nGGC4cdBrLkPYMNRlIHg1Q=.bcc1ff0b-ca04-4adc-9f61-9641c33f1807@github.com>
References: <tZiBKIvIBGsfgLaEtvf87nGGC4cdBrLkPYMNRlIHg1Q=.bcc1ff0b-ca04-4adc-9f61-9641c33f1807@github.com>
Message-ID: <t8wn9Ui1LQODIKte2N9MoY93vzHKMgmNFeJTIW_0WQ8=.400efa3f-7560-4316-974b-d4f950062361@github.com>

On Fri, 9 May 2025 23:23:27 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> For `java.lang` tests, use the `@requires` facility in place of checking the `os.name` system property or `File.separatorChar`.
> 
> Automated test results are omitted as expected.

I think `test/jdk/java/lang/System/NonAnsiFileEncodingTest.java` can be removed, as it does not provide any value today :-
- It intends to run on Windows 2000/XP, which are both no longer supported.
- The test requires manual set up to one of those locales on Windows.
- `file.encoding` is always UTF-8 since JDK 18. (and it is actually comparing it with "utf-8" in case-insensitive way)

-------------

PR Review: https://git.openjdk.org/jdk/pull/25163#pullrequestreview-2829970870

From asemenyuk at openjdk.org  Sat May 10 00:58:02 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 10 May 2025 00:58:02 GMT
Subject: RFR: 8356664: [macos] AppContentTest fails after JDK-8352480
In-Reply-To: <K3Fsdclj065E8rIypNMsh2b3lTv1yo5Y5aB_w4YHV1w=.991b336b-21ce-4540-a59a-dc3bf20b3d51@github.com>
References: <K3Fsdclj065E8rIypNMsh2b3lTv1yo5Y5aB_w4YHV1w=.991b336b-21ce-4540-a59a-dc3bf20b3d51@github.com>
Message-ID: <lueof08UESHje7ZDx80Sz4zJXz220lScgZxR6NFmUeA=.85db6d75-bc51-479c-bcca-0a680e52717b@github.com>

On Fri, 9 May 2025 23:36:44 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Regression from JDK-8352480.
> - On macOS we should create `Links` folder under `Resources`. Which means `--app-content` should point to `app-content/Resources` and not to `app-content/Resources/Links`.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25164#pullrequestreview-2830001571

From almatvee at openjdk.org  Sat May 10 03:11:02 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 10 May 2025 03:11:02 GMT
Subject: Integrated: 8356664: [macos] AppContentTest fails after JDK-8352480
In-Reply-To: <K3Fsdclj065E8rIypNMsh2b3lTv1yo5Y5aB_w4YHV1w=.991b336b-21ce-4540-a59a-dc3bf20b3d51@github.com>
References: <K3Fsdclj065E8rIypNMsh2b3lTv1yo5Y5aB_w4YHV1w=.991b336b-21ce-4540-a59a-dc3bf20b3d51@github.com>
Message-ID: <To5jPLvN3r4Mm4UUuwIXz42ECIXtGw7MyXA2lkpXaVk=.1c6f9162-a960-4946-910d-1cec1cb1382b@github.com>

On Fri, 9 May 2025 23:36:44 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Regression from JDK-8352480.
> - On macOS we should create `Links` folder under `Resources`. Which means `--app-content` should point to `app-content/Resources` and not to `app-content/Resources/Links`.

This pull request has now been integrated.

Changeset: fa7c5a65
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa7c5a65ba62da9b6598d484db923119ace0cf90
Stats:     7 lines in 1 file changed: 4 ins; 1 del; 2 mod

8356664: [macos] AppContentTest fails after JDK-8352480

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/25164

From rgiulietti at openjdk.org  Sat May 10 10:02:59 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sat, 10 May 2025 10:02:59 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v9]
In-Reply-To: <MFj2qSpVPBKYBDuyh9Q2JMfHyrRkKsx5NB9X3uhFDnk=.0c7e2e14-4fac-4a56-8653-482c21dd2075@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
 <LS-sIBRy1Kgr5ysuB7SisZlUP-DGTvWkf8yiUvJsLUI=.2a3b2780-deb9-49c1-9f59-30ded314c4c3@github.com>
 <MFj2qSpVPBKYBDuyh9Q2JMfHyrRkKsx5NB9X3uhFDnk=.0c7e2e14-4fac-4a56-8653-482c21dd2075@github.com>
Message-ID: <WDbN75p_tbyKxPoCu246rSRPskJhZZqGVL8w_vxAttc=.15dfa4c8-9a86-4db0-8149-0a1bb577c531@github.com>

On Fri, 9 May 2025 22:58:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
>> 
>>  - Removed useless comment.
>>  - Merge branch 'master' into 8343829
>>  - Added javadoc to refer to the grammar in j.l.Double.
>>  - Merge branch 'master' into 8343829
>>  - Make some static arrays @Stable.
>>  - Remove unused BIG_DECIMAL_EXPONENT
>>  - Merge branch 'master' into 8343829
>>  - Merge branch 'master' into 8343829
>>  - Redacted comments.
>>  - Merge branch 'master' into 8343829
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/8862cc91...88fe2c08
>
> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1964:
> 
>> 1962: 
>> 1963:         /* Skip opt [FfDd]? suffix. */
>> 1964:         if (i < len && (((ch = in.charAt(i) | 0b10_0000)) == 'f' || ch == 'd')) {
> 
> Is it really right to ignore these suffix for all ix values?

Although this might seem surprising, yes, it is right.
This is what the `[Double|Float].valueOf(String)` specs say (these are the "main clients" of this class):
> Note that trailing format specifiers, [...] do not influence the results of this method.

> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 2006:
> 
>> 2004:          *
>> 2005:          *         |lz            |pt |tnz  |stop
>> 2006:          * 0000000012345600000023.4567000000000
> 
> Suggestion:
> 
>          *         |lz            |pt |tnz     |stop
>          * 0000000012345600000023.4567000000000

Addressed.

> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 2265:
> 
>> 2263: 
>> 2264:     /* Arithmetically "appends the digit" ch to v >= 0, clamping at 10^10. */
>> 2265:     private static long appendDigit(long v, int ch) {
> 
> Since this appends only decimal digit, should we name it `appendDecDegit`? In the use site we already note all exponents are decimals.

Addressed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2083096389
PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2083096060
PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2083096070

From rgiulietti at openjdk.org  Sat May 10 10:08:39 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sat, 10 May 2025 10:08:39 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v10]
In-Reply-To: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
Message-ID: <3i5Up4OJbfk1ytccMO66B0VtzqOS5pgMeLv7Lb_N5EE=.df0f670f-ef4f-4205-892b-cad0001ec397@github.com>

> See the JBS bug for some details.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Addressed reviewer comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22737/files
  - new: https://git.openjdk.org/jdk/pull/22737/files/88fe2c08..dbb5a272

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=08-09

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22737.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22737/head:pull/22737

PR: https://git.openjdk.org/jdk/pull/22737

From swen at openjdk.org  Sat May 10 11:20:35 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 10 May 2025 11:20:35 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 UTF16::compress & Unsafe::copyMemory [v5]
In-Reply-To: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
Message-ID: <e_RlOx7ra1rutPci_0nx0IbWKYi9ai8yoDYK4OeexBo=.f2a0ac77-f14b-474e-bf1a-1f190d1ae70c@github.com>

> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.
> 
> For these scenarios, we can use the intrinsic method StringUTF16.compress and Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - copyright
 - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/AbstractStringBuilder.java
 - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/AbstractStringBuilder.java
 - Merge remote-tracking branch 'upstream/master' into optim_sb_append_chars_202504
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/StringUTF16.java
 - putCharsUnchecked
 - copyright
 - Using StringUTF16.compress to speed up LATIN1 StringBuilder append(char[])
 - Using Unsafe.copyMemory to speed up UTF16 StringBuilder append(char[])
 - add append(char[]) benchmark

-------------

Changes: https://git.openjdk.org/jdk/pull/24773/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24773&range=04
  Stats: 42 lines in 2 files changed: 36 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24773/head:pull/24773

PR: https://git.openjdk.org/jdk/pull/24773

From duke at openjdk.org  Sat May 10 11:53:38 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 10 May 2025 11:53:38 GMT
Subject: RFR: 8077587: BigInteger Roots [v5]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <hsMJh9lf39oR5sP15p1HQsRu4aYgaBt2Ndw1a466Whc=.7e858b45-bb49-435a-a5a2-a0d111ab9497@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 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 'openjdk:master' into nth-root-branch
 - Update to resolve conflicts
 - An optimization
 - Correct unsigned division
 - Correct typo in comment
 - No need to avoid overflow
 - Merge branch 'openjdk:master' into BigInteger-nth-root
 - Optimized nth root iteration loop
 - Systematization of special cases in BigInteger.pow(int)
 - Some optimizations
 - ... and 34 more: https://git.openjdk.org/jdk/compare/fa7c5a65...4729a468

-------------

Changes: https://git.openjdk.org/jdk/pull/24898/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=04
  Stats: 136 lines in 1 file changed: 136 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From duke at openjdk.org  Sat May 10 11:57:32 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 10 May 2025 11:57:32 GMT
Subject: RFR: 8077587: BigInteger Roots [v6]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <Yx-DylQSsz_gUYUWsEq0VOZyZjkXc-3gxPe2l2HYpT8=.a9c3746b-6383-4450-83bf-9b4b5590178d@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'nth-root-branch' of https://github.com/fabioromano1/jdk into nth-root-branch
 - Restore nthRoot() public methods in BigInteger.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/4729a468..823d2f63

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=04-05

  Stats: 74 lines in 1 file changed: 74 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From liach at openjdk.org  Sat May 10 14:34:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 10 May 2025 14:34:57 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v2]
In-Reply-To: <h0NG79gUPcH1_prs_0-BfqFkNnXGmlyJR6M79uUnJhU=.efdcbe80-3565-4be8-8fe3-b88c9791effb@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
 <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
 <J8LYjKyW-DOppkSZxTWcRYllmQ_WzAwgTxLTdkh9Z4g=.e0d18849-bb60-45ab-851b-d034a26fe6bd@github.com>
 <cc8J6tnifhUTh3SCu7VWsvJHc1afHMZeFQpNgqFF7Ew=.09f294a6-f5ac-4905-9868-17c4a174a123@github.com>
 <h0NG79gUPcH1_prs_0-BfqFkNnXGmlyJR6M79uUnJhU=.efdcbe80-3565-4be8-8fe3-b88c9791effb@github.com>
Message-ID: <nE3vY86gAkbMoBwkJJcKRHrTgv25Bauh7Zhu87waQRM=.5bcf63ed-06bd-45b5-9225-797eccc4c21c@github.com>

On Fri, 2 May 2025 17:19:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release <N>` argument or migrate class file parsing to ClassFile API.
>
>> I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release <N>` argument or migrate class file parsing to ClassFile API.
> 
> Sounds good. I think prepping such a change is outside the scope of what @nizarbenalla or myself should do as part of the start of JDK 26 patch.

See #25124.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2083210454

From acobbs at openjdk.org  Sat May 10 15:27:52 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 10 May 2025 15:27:52 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <CdtTwok4N_tN_rF-m6hmHx4frol7Yz7RuGuXg2d50Ek=.a6b01a79-5410-404a-9773-e9e406c17d01@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
 <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
 <BPoc_smVnc5o4qfZIYiUBzfek5OspUXWQrsjODDrnME=.64da805b-726a-4f1c-8b02-025060946455@github.com>
 <ke72Wce0xsvGp_9sZM-YBpn5MeoiAKH2oOcrtvbm_go=.f1c89d3b-3b84-4184-9861-f87cefc85f64@github.com>
 <m8gmGD58e_TJJ0ik_n842YC7bACrA_wYqNED6QZbeos=.58a6b464-4313-474e-9362-d7f80fbac8f1@github.com>
 <WP_HCElTvyntrwXlrXvgC-hLlyaftjWDDYtThJwG-Kk=.7a0810c7-f185-407f-8908-87f3c4870173@github.com>
 <CdtTwok4N_tN_rF-m6hmHx4frol7Yz7RuGuXg2d50Ek=.a6b01a79-5410-404a-9773-e9e406c17d01@github.com>
Message-ID: <CAf7PHYDZAibVVrsKlRlXvFGJ9XAfM9rjh9soCvDDIE=.a4ab7a2b-93e2-4f90-80c0-be9187290b1c@github.com>

On Fri, 9 May 2025 22:39:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> Sure, I think vicente is open to patches and PRs to his fork. And I can help review; just remember to @liach.

OK thanks. I've rebased my changes on @vicente-romero-oracle's branch to simply any evaluation. [Here's the diff](https://github.com/vicente-romero-oracle/jdk/compare/JDK-8354556...archiecobbs:jdk:JDK-8354556+aliases).

@vicente-romero-oracle please feel free to take it or leave it, I'm not trying to butt in to your PR, rather just trying to avoid a small bit of technical debt. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868963258

From vromero at openjdk.org  Sat May 10 15:31:45 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 15:31:45 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v10]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <Xfb8mMaM4ZG2HbsEQuP8PoR_Mn0JybO8mhqDMvbYsUQ=.35f17611-2eca-4068-a3d4-889d34eeb1c1@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  integrating code from Archie

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/ea631161..a9a53783

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=08-09

  Stats: 151 lines in 7 files changed: 98 ins; 25 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

PR: https://git.openjdk.org/jdk/pull/24746

From liach at openjdk.org  Sat May 10 15:33:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 10 May 2025 15:33:52 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
Message-ID: <OumhW90asXXtvx7mmxJXL63qq_PobA4heS5Phgb6BrI=.aeb99e3d-e4de-4a43-9922-d47ac8fdf36b@github.com>

On Fri, 9 May 2025 20:28:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing bugs, removing dead code

Thanks. Looks good, but the Lint to all option names streaming can be replaced by the static map lookup/iteration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868971783

From vromero at openjdk.org  Sat May 10 15:37:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 15:37:51 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <CAf7PHYDZAibVVrsKlRlXvFGJ9XAfM9rjh9soCvDDIE=.a4ab7a2b-93e2-4f90-80c0-be9187290b1c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
 <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
 <BPoc_smVnc5o4qfZIYiUBzfek5OspUXWQrsjODDrnME=.64da805b-726a-4f1c-8b02-025060946455@github.com>
 <ke72Wce0xsvGp_9sZM-YBpn5MeoiAKH2oOcrtvbm_go=.f1c89d3b-3b84-4184-9861-f87cefc85f64@github.com>
 <m8gmGD58e_TJJ0ik_n842YC7bACrA_wYqNED6QZbeos=.58a6b464-4313-474e-9362-d7f80fbac8f1@github.com>
 <WP_HCElTvyntrwXlrXvgC-hLlyaftjWDDYtThJwG-Kk=.7a0810c7-f185-407f-8908-87f3c4870173@github.com>
 <CdtTwok4N_tN_rF-m6hmHx4frol7Yz7RuGuXg2d50Ek=.a6b01a79-5410-404a-9773-e9e406c17d01@github.com>
 <CAf7PHYDZAibVVrsKlRlXvFGJ9XAfM9rjh9soCvDDIE=.a4ab7a2b-93e2-4f90-80c0-be9187290b1c@github.com>
Message-ID: <bv-ku-BDfYjHJu7CFwqKJvAya2TtIpWZn-TasyxVRI0=.0e62d976-4ecd-4bfa-a0d4-92ffca7b94e9@github.com>

On Sat, 10 May 2025 15:24:52 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>>> That's why I was offering my existing patch which basically does that already. But it's OK to wait if you prefer.
>> 
>> Sure, I think vicente is open to patches and PRs to his fork. And I can help review; just remember to @liach.
>
>> Sure, I think vicente is open to patches and PRs to his fork. And I can help review; just remember to @liach.
> 
> OK thanks. I've rebased my changes on @vicente-romero-oracle's branch to simply any evaluation. [Here's the diff](https://github.com/vicente-romero-oracle/jdk/compare/JDK-8354556...archiecobbs:jdk:JDK-8354556+aliases).
> 
> @vicente-romero-oracle please feel free to take it or leave it, I'm not trying to butt in to your PR, rather just trying to avoid a small bit of technical debt. Thanks!

I have integrated @archiecobbs's code. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868972990

From vromero at openjdk.org  Sat May 10 15:37:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 15:37:52 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <OumhW90asXXtvx7mmxJXL63qq_PobA4heS5Phgb6BrI=.aeb99e3d-e4de-4a43-9922-d47ac8fdf36b@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
 <OumhW90asXXtvx7mmxJXL63qq_PobA4heS5Phgb6BrI=.aeb99e3d-e4de-4a43-9922-d47ac8fdf36b@github.com>
Message-ID: <nib-ZZMyLpeB93Q5ENIt-eFINj0q2yWEGqDZ7bo78_o=.4e9f97aa-90dc-4b8f-93d5-eaa4995d456b@github.com>

On Sat, 10 May 2025 15:31:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing bugs, removing dead code
>
> Thanks. Looks good, but the Lint to all option names streaming can be replaced by the static map lookup/iteration.

> > Sure, I think vicente is open to patches and PRs to his fork. And I can help review; just remember to @liach.
> 
> OK thanks. I've rebased my changes on @vicente-romero-oracle's branch to simply any evaluation. [Here's the diff](https://github.com/vicente-romero-oracle/jdk/compare/JDK-8354556...archiecobbs:jdk:JDK-8354556+aliases).
> 
> @vicente-romero-oracle please feel free to take it or leave it, I'm not trying to butt in to your PR, rather just trying to avoid a small bit of technical debt. Thanks!

heh, I was doing the same, thanks anyway :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868973659

From acobbs at openjdk.org  Sat May 10 15:43:54 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 10 May 2025 15:43:54 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <nib-ZZMyLpeB93Q5ENIt-eFINj0q2yWEGqDZ7bo78_o=.4e9f97aa-90dc-4b8f-93d5-eaa4995d456b@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
 <OumhW90asXXtvx7mmxJXL63qq_PobA4heS5Phgb6BrI=.aeb99e3d-e4de-4a43-9922-d47ac8fdf36b@github.com>
 <nib-ZZMyLpeB93Q5ENIt-eFINj0q2yWEGqDZ7bo78_o=.4e9f97aa-90dc-4b8f-93d5-eaa4995d456b@github.com>
Message-ID: <I3FPARS1QhUMONXA1VULa0L2Jigu0QHpG7fep5DF8UQ=.a753305f-e8b0-44c0-8bdc-ffb9958ba28e@github.com>

On Sat, 10 May 2025 15:35:16 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> heh, I was doing the same, thanks anyway :)

Awesome, thanks!

Apologies for the mid-air collision :) I've merged your latest merge into my merge, leaving just a few minor fixes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868976097

From nbenalla at openjdk.org  Sat May 10 15:44:51 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Sat, 10 May 2025 15:44:51 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v2]
In-Reply-To: <nE3vY86gAkbMoBwkJJcKRHrTgv25Bauh7Zhu87waQRM=.5bcf63ed-06bd-45b5-9225-797eccc4c21c@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
 <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
 <J8LYjKyW-DOppkSZxTWcRYllmQ_WzAwgTxLTdkh9Z4g=.e0d18849-bb60-45ab-851b-d034a26fe6bd@github.com>
 <cc8J6tnifhUTh3SCu7VWsvJHc1afHMZeFQpNgqFF7Ew=.09f294a6-f5ac-4905-9868-17c4a174a123@github.com>
 <h0NG79gUPcH1_prs_0-BfqFkNnXGmlyJR6M79uUnJhU=.efdcbe80-3565-4be8-8fe3-b88c9791effb@github.com>
 <nE3vY86gAkbMoBwkJJcKRHrTgv25Bauh7Zhu87waQRM=.5bcf63ed-06bd-45b5-9225-797eccc4c21c@github.com>
Message-ID: <vmbm4WtGBMVdkQQTbwPIM65_xTpPTF-rn8es_pImq3Q=.a1f79864-3b8f-4132-ad95-8dbe58b62654@github.com>

On Sat, 10 May 2025 14:32:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>>> I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release <N>` argument or migrate class file parsing to ClassFile API.
>> 
>> Sounds good. I think prepping such a change is outside the scope of what @nizarbenalla or myself should do as part of the start of JDK 26 patch.
>
> See #25124.

Thanks Chen!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2083223695

From acobbs at openjdk.org  Sat May 10 16:00:58 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 10 May 2025 16:00:58 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <OumhW90asXXtvx7mmxJXL63qq_PobA4heS5Phgb6BrI=.aeb99e3d-e4de-4a43-9922-d47ac8fdf36b@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
 <OumhW90asXXtvx7mmxJXL63qq_PobA4heS5Phgb6BrI=.aeb99e3d-e4de-4a43-9922-d47ac8fdf36b@github.com>
Message-ID: <Jl13VWa5dPTXvqGhuVkOfQPCQPZL7c0Q-vPgjQ9p8eo=.8e30584f-76e1-4537-a5b6-71d81dc3ac0b@github.com>

On Sat, 10 May 2025 15:31:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> Thanks. Looks good, but the Lint to all option names streaming can be replaced by the static map lookup/iteration.

Good point... I prototyped that in commit be160a3261b.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868989327

From vromero at openjdk.org  Sat May 10 16:05:59 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 16:05:59 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v10]
In-Reply-To: <Xfb8mMaM4ZG2HbsEQuP8PoR_Mn0JybO8mhqDMvbYsUQ=.35f17611-2eca-4068-a3d4-889d34eeb1c1@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <Xfb8mMaM4ZG2HbsEQuP8PoR_Mn0JybO8mhqDMvbYsUQ=.35f17611-2eca-4068-a3d4-889d34eeb1c1@github.com>
Message-ID: <_tMq_VvOY6ER-1qTRe7TDbBBCPWFW7080gRydehdBME=.7131f939-c8dc-4443-8c44-ce31fbc227a3@github.com>

On Sat, 10 May 2025 15:31:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   integrating code from Archie

> > Thanks. Looks good, but the Lint to all option names streaming can be replaced by the static map lookup/iteration.
> 
> Good point... I prototyped that in commit [be160a3](https://github.com/openjdk/jdk/commit/be160a3261bebcbd09c350a3feda6e696f26a3e3).

thanks! I will integrate it

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868993387

From vromero at openjdk.org  Sat May 10 16:05:59 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 16:05:59 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <I3FPARS1QhUMONXA1VULa0L2Jigu0QHpG7fep5DF8UQ=.a753305f-e8b0-44c0-8bdc-ffb9958ba28e@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
 <OumhW90asXXtvx7mmxJXL63qq_PobA4heS5Phgb6BrI=.aeb99e3d-e4de-4a43-9922-d47ac8fdf36b@github.com>
 <nib-ZZMyLpeB93Q5ENIt-eFINj0q2yWEGqDZ7bo78_o=.4e9f97aa-90dc-4b8f-93d5-eaa4995d456b@github.com>
 <I3FPARS1QhUMONXA1VULa0L2Jigu0QHpG7fep5DF8UQ=.a753305f-e8b0-44c0-8bdc-ffb9958ba28e@github.com>
Message-ID: <j7Yb8_4DGE2zRvsEH8fOYKGiq9iJNi2COuZnMTj0b4w=.d42d37a8-d3c2-459b-bf93-917d3db1d1dd@github.com>

On Sat, 10 May 2025 15:41:18 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> > heh, I was doing the same, thanks anyway :)
> 
> Awesome, thanks!
> 
> Apologies for the mid-air collision :) I've merged your latest merge into my merge, leaving just a few minor fixes.

thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868993581

From vromero at openjdk.org  Sat May 10 16:39:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 16:39:38 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v11]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <K5NLszEQ8y7LlGY4ffAG8rIkl5csr29qlTKBcf4ehEs=.77ec03c1-1d0f-441a-b997-0c70ee9a588b@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:

 - additional changes from Archie
 - removing dead code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/a9a53783..973307eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=09-10

  Stats: 66 lines in 7 files changed: 16 ins; 35 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

PR: https://git.openjdk.org/jdk/pull/24746

From vromero at openjdk.org  Sat May 10 16:39:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 16:39:38 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v10]
In-Reply-To: <Xfb8mMaM4ZG2HbsEQuP8PoR_Mn0JybO8mhqDMvbYsUQ=.35f17611-2eca-4068-a3d4-889d34eeb1c1@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <Xfb8mMaM4ZG2HbsEQuP8PoR_Mn0JybO8mhqDMvbYsUQ=.35f17611-2eca-4068-a3d4-889d34eeb1c1@github.com>
Message-ID: <QFz-yN_7ifVnh8V9LqQXJ8emqZ1ct5gFFqSjAUiKTjo=.d97305ed-8b9c-44f8-a47a-aa3918555b07@github.com>

On Sat, 10 May 2025 15:31:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   integrating code from Archie

I integrated the rest of Archie's changes, thanks guys for the contributions and the reviews

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2869007212

From vromero at openjdk.org  Sat May 10 16:50:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 16:50:51 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <j7Yb8_4DGE2zRvsEH8fOYKGiq9iJNi2COuZnMTj0b4w=.d42d37a8-d3c2-459b-bf93-917d3db1d1dd@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
 <OumhW90asXXtvx7mmxJXL63qq_PobA4heS5Phgb6BrI=.aeb99e3d-e4de-4a43-9922-d47ac8fdf36b@github.com>
 <nib-ZZMyLpeB93Q5ENIt-eFINj0q2yWEGqDZ7bo78_o=.4e9f97aa-90dc-4b8f-93d5-eaa4995d456b@github.com>
 <I3FPARS1QhUMONXA1VULa0L2Jigu0QHpG7fep5DF8UQ=.a753305f-e8b0-44c0-8bdc-ffb9958ba28e@github.com>
 <j7Yb8_4DGE2zRvsEH8fOYKGiq9iJNi2COuZnMTj0b4w=.d42d37a8-d3c2-459b-bf93-917d3db1d1dd@github.com>
Message-ID: <ksTB2GyTHMoCi2I9APkJdJo45dfd0NA2ctndzuuD4fo=.0f91cb05-df3a-4ef4-97de-36f90a19da4b@github.com>

On Sat, 10 May 2025 16:03:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> > heh, I was doing the same, thanks anyway :)
> 
> Awesome, thanks!
> 
> Apologies for the mid-air collision :) I've merged your latest merge into my merge, leaving just a few minor fixes.

thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2869011552

From asemenyuk at openjdk.org  Sat May 10 19:02:45 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 10 May 2025 19:02:45 GMT
Subject: RFR: 8333664: Decouple command line parsing and package building
 in jpackage [v4]
In-Reply-To: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>
References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>
Message-ID: <_IWCckFl77gXXM8TOCh1GlDTBrqrHTvJjNvvcaGt3-A=.7f61f15f-a5bf-4182-b609-1f3d6e199d89@github.com>

> Refactor jpackage to separate the configuration and execution phases.
> At the configuration phase, jpackage parses command-line arguments and validates them.
> At the execution phase, jpackage builds a bundle based on data collected at the configuration phase.
> 
> There was no clear separation between these phases. Both used the same data type (`Map<String, Object>`), making it hard to understand and use properly.
> 
> This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling.
> 
> The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map<String, Object>` "params".
> 
> Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers.
> 
> jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html
> 
> **Functional changes**
> jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below.
> 
>  - Minimize copying of the source app image when doing native packaging.
> 
> Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations.
> 
> - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles.
> 
> post- and pre- install PKG scripts for SimplePackageTest package before and after the change:
> <table>
> <thead>
> <tr>
> <th>Script</th>
> <th>New</th>
> <th>Old</th>
> </tr>
> </thead>
> <tbody...

Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 512 commits:

 - Add ConfigFilesStasher that allows to save contents of jpackage build directories in external directory; Add clean_stashed_files.sh
 - Merge branch 'master' into JDK-8333664
 - Remove redundant StandardBundlerParam.createResource()
 - Adapt JDK-8352480 fix
 - Merge branch 'master' into JDK-8333664
 - Fix javadoc
 - Merge branch 'master' into JDK-8333664
 - 8333568: Test that jpackage doesn't modify R/O files/directories
   
   Reviewed-by: almatvee
 - 8356562: SigningAppImageTwoStepsTest test fails
   
   Reviewed-by: almatvee
 - Remove clean_stashed_files.sh
 - ... and 502 more: https://git.openjdk.org/jdk/compare/43696030...011eb710

-------------

Changes: https://git.openjdk.org/jdk/pull/19668/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19668&range=03
  Stats: 23912 lines in 195 files changed: 17137 ins; 5686 del; 1089 mod
  Patch: https://git.openjdk.org/jdk/pull/19668.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19668/head:pull/19668

PR: https://git.openjdk.org/jdk/pull/19668

From liach at openjdk.org  Sat May 10 19:39:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 10 May 2025 19:39:52 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v11]
In-Reply-To: <K5NLszEQ8y7LlGY4ffAG8rIkl5csr29qlTKBcf4ehEs=.77ec03c1-1d0f-441a-b997-0c70ee9a588b@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <K5NLszEQ8y7LlGY4ffAG8rIkl5csr29qlTKBcf4ehEs=.77ec03c1-1d0f-441a-b997-0c70ee9a588b@github.com>
Message-ID: <naEEBS9Un6FvBFlwxzsXR8RwpgL-zzTLEB8hglPk_ho=.16af1305-422a-45ad-b9ca-b855cf4af583@github.com>

On Sat, 10 May 2025 16:39:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - additional changes from Archie
>  - removing dead code

As much as I dislike streams, I think we will probably keep them for their conciseness except this one, which made things less concise.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 422:

> 420:             ArrayList<String> optionList = new ArrayList<>(1 + aliases.length);
> 421:             optionList.add(option);
> 422:             Stream.of(aliases).forEach(optionList::add);

Suggestion:

            Collections.addAll(optionList, aliases);

-------------

PR Review: https://git.openjdk.org/jdk/pull/24746#pullrequestreview-2831052002
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2083275193

From acobbs at openjdk.org  Sat May 10 20:04:52 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 10 May 2025 20:04:52 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v11]
In-Reply-To: <naEEBS9Un6FvBFlwxzsXR8RwpgL-zzTLEB8hglPk_ho=.16af1305-422a-45ad-b9ca-b855cf4af583@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <K5NLszEQ8y7LlGY4ffAG8rIkl5csr29qlTKBcf4ehEs=.77ec03c1-1d0f-441a-b997-0c70ee9a588b@github.com>
 <naEEBS9Un6FvBFlwxzsXR8RwpgL-zzTLEB8hglPk_ho=.16af1305-422a-45ad-b9ca-b855cf4af583@github.com>
Message-ID: <GL17OxIMdIiO8YrxKCiLvwodQvmi9PeQqqPFm-Ey3e0=.dbbda840-cf4b-4151-8a59-f1535571c07d@github.com>

On Sat, 10 May 2025 19:32:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - additional changes from Archie
>>  - removing dead code
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 422:
> 
>> 420:             ArrayList<String> optionList = new ArrayList<>(1 + aliases.length);
>> 421:             optionList.add(option);
>> 422:             Stream.of(aliases).forEach(optionList::add);
> 
> Suggestion:
> 
>             Collections.addAll(optionList, aliases);

Wow, somehow I never knew `Collections.addAll()` existed. Thanks for the tip - that's simpler.

(I'll let @vicente-romero-oracle fix it.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2083280028

From vromero at openjdk.org  Sat May 10 20:28:39 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 20:28:39 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v12]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <aywAMR14DaO2dPfzllNsKNfkjbXEIINzNB8aZUBevYo=.a6901bc0-35a0-4fbc-84af-7532f3da8a4c@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/973307eb..63fd151f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=10-11

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

PR: https://git.openjdk.org/jdk/pull/24746

From vromero at openjdk.org  Sat May 10 20:28:39 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 20:28:39 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v11]
In-Reply-To: <naEEBS9Un6FvBFlwxzsXR8RwpgL-zzTLEB8hglPk_ho=.16af1305-422a-45ad-b9ca-b855cf4af583@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <K5NLszEQ8y7LlGY4ffAG8rIkl5csr29qlTKBcf4ehEs=.77ec03c1-1d0f-441a-b997-0c70ee9a588b@github.com>
 <naEEBS9Un6FvBFlwxzsXR8RwpgL-zzTLEB8hglPk_ho=.16af1305-422a-45ad-b9ca-b855cf4af583@github.com>
Message-ID: <s5XwKCIy9MBpOGUZTR_ZuzI2mz-bsXE_-z2QErrrIGw=.e077c752-7c50-4937-95a4-ebd5b445ec92@github.com>

On Sat, 10 May 2025 19:36:52 GMT, Chen Liang <liach at openjdk.org> wrote:

> As much as I dislike streams, I think we will probably keep them for their conciseness except this one, which made things less concise.

thanks! committed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2869141760

From acobbs at openjdk.org  Sat May 10 20:40:54 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 10 May 2025 20:40:54 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v12]
In-Reply-To: <aywAMR14DaO2dPfzllNsKNfkjbXEIINzNB8aZUBevYo=.a6901bc0-35a0-4fbc-84af-7532f3da8a4c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <aywAMR14DaO2dPfzllNsKNfkjbXEIINzNB8aZUBevYo=.a6901bc0-35a0-4fbc-84af-7532f3da8a4c@github.com>
Message-ID: <3mgdx3uS6hYjqdiYla9QMMDB34uAyqNxZoLnxSO1yjI=.0c900a96-b1c6-449b-9155-100618aad111@github.com>

On Sat, 10 May 2025 20:28:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

FYI, this issue now effectively fixes [JDK-7004476 Lint.LintCategory should support aliases](https://bugs.openjdk.org/browse/JDK-7004476), which happened to be closed as "Rejected" on Monday. Not sure if anything needs to be done.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2869145567

From liach at openjdk.org  Sat May 10 20:43:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 10 May 2025 20:43:20 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v13]
In-Reply-To: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
Message-ID: <OuorxBjLrAKkDp6t_zdsjDsGH33vTd7mOViD6fMjP5M=.e97b26c5-2bad-40de-abf8-8505c03c5286@github.com>

> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
> 
> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
> 
> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
> 
> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:

 - Jaikiran comments, improve thread reference tracking, more documents
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
 - Update src/java.base/share/classes/java/lang/ClassValue.java
   
   Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
 - Reviews from viktor
 - Rewrite impl to follow the new simplified spec
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
 - Try to simplify the model - use the finish of computeValue
   
 - Test updates - remove repetition, test case for no stale installation
 - Fix incorrect promise removal when unnecessary and add regression test
 - ... and 12 more: https://git.openjdk.org/jdk/compare/c7a6f415...e24a1fd7

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24043/files
  - new: https://git.openjdk.org/jdk/pull/24043/files/3d68f09a..e24a1fd7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=11-12

  Stats: 27783 lines in 969 files changed: 17000 ins; 6516 del; 4267 mod
  Patch: https://git.openjdk.org/jdk/pull/24043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24043/head:pull/24043

PR: https://git.openjdk.org/jdk/pull/24043

From vromero at openjdk.org  Sat May 10 22:48:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 22:48:52 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v12]
In-Reply-To: <3mgdx3uS6hYjqdiYla9QMMDB34uAyqNxZoLnxSO1yjI=.0c900a96-b1c6-449b-9155-100618aad111@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <aywAMR14DaO2dPfzllNsKNfkjbXEIINzNB8aZUBevYo=.a6901bc0-35a0-4fbc-84af-7532f3da8a4c@github.com>
 <3mgdx3uS6hYjqdiYla9QMMDB34uAyqNxZoLnxSO1yjI=.0c900a96-b1c6-449b-9155-100618aad111@github.com>
Message-ID: <7sbyHtJrLFM2tyXex553OXX12Mch_Q2mXwJg3qKSEqk=.e568d019-99d3-4c04-8ad6-0c6d071aef62@github.com>

On Sat, 10 May 2025 20:38:36 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> FYI, this issue now effectively fixes [JDK-7004476 Lint.LintCategory should support aliases](https://bugs.openjdk.org/browse/JDK-7004476), which happened to be closed as "Rejected" on Monday. Not sure if anything needs to be done.

I guess we can add a note to that bug once this one goes through

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2869184983

From godmlzkf1 at naver.com  Sun May 11 08:21:21 2025
From: godmlzkf1 at naver.com (=?utf-8?B?7J6E66+87IiY?=)
Date: Sun, 11 May 2025 17:21:21 +0900
Subject: =?utf-8?B?QXJyYXlMaXN0IHByaW50IGNhcGFjaXR5?=
Message-ID: <5b359bff7665f93daacbe7a210bedd3a@cweb004.nm>

Hi

It seems that there is no code to print Capacity in ArrayList.

Vector, a friend of ArrayList, can be printed through capacity().

I want to add code to print Capacity of ArrayList as elementData.length.

Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250511/ee06176e/attachment.htm>

From duke at openjdk.org  Sun May 11 08:42:41 2025
From: duke at openjdk.org (Abhishek N)
Date: Sun, 11 May 2025 08:42:41 GMT
Subject: RFR: 8355393: Create a Test case to have special cases coverage
 for currency.getInstance() [v2]
In-Reply-To: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
Message-ID: <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>

> Create a Test case to have special cases coverage for currency.getInstance().
> 
> The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API.
> 
> test results:
> 
> jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java
> Directory "JTwork" not found: creating
> Directory "JTreport" not found: creating
> Test results: passed: 1
> Report written to JTreport\html\report.html
> Results written to JTwork

Abhishek N has updated the pull request incrementally with one additional commit since the last revision:

  correcting jtreg header order, add meaningful comments for each test methods and properties file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25057/files
  - new: https://git.openjdk.org/jdk/pull/25057/files/77ae234a..7207e7c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25057&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25057&range=00-01

  Stats: 24 lines in 3 files changed: 17 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25057.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25057/head:pull/25057

PR: https://git.openjdk.org/jdk/pull/25057

From forax at univ-mlv.fr  Sun May 11 10:03:28 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 11 May 2025 12:03:28 +0200 (CEST)
Subject: ArrayList print capacity
In-Reply-To: <5b359bff7665f93daacbe7a210bedd3a@cweb004.nm>
References: <5b359bff7665f93daacbe7a210bedd3a@cweb004.nm>
Message-ID: <1145605941.260696498.1746957808830.JavaMail.zimbra@univ-eiffel.fr>

Hello, 
this is not an overlook, 
the less you expose (make public), the easier it is to change the implementation in the future. 

Also, the collection API was design to avoid (if possible) to have more public methods in the implementation (ArrayList) than you have in the interface (List). 
So as a user, you can always use a List as parameter of a public method instead of an ArrayList. 

regards, 
R?mi 

> From: "???" <godmlzkf1 at naver.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Sunday, May 11, 2025 10:21:21 AM
> Subject: ArrayList print capacity

> Hi
> It seems that there is no code to print Capacity in ArrayList.

> Vector, a friend of ArrayList, can be printed through capacity().

> I want to add code to print Capacity of ArrayList as elementData.length.

> Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250511/8b6f009e/attachment.htm>

From forax at univ-mlv.fr  Sun May 11 10:16:17 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 11 May 2025 12:16:17 +0200 (CEST)
Subject: Unnecessary logic is added to removeFirst and removeLast of
 ArrayList.
In-Reply-To: <7761d3554e8cd5fd861579a4fe705044@cweb008.nm>
References: <7761d3554e8cd5fd861579a4fe705044@cweb008.nm>
Message-ID: <1675779578.260699311.1746958577836.JavaMail.zimbra@univ-eiffel.fr>

> From: "???" <godmlzkf1 at naver.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Friday, May 9, 2025 10:33:30 AM
> Subject: Unnecessary logic is added to removeFirst and removeLast of ArrayList.

> Hi.

> In removeFirst, if size is not 0, the logic is the same as the remove logic.

> removeLast also has the same logic as remove when size is not exceeded.

> I want to fix this.

> thank you.

Duplicating the logic is bad in some cases and not that bad in other cases. 

Here ArrayList is one of the most used class in Java (with String and HashMap), it is heavily optimized (to the point where the generated assembly code by the JITs is checked by humans), so duplicating the logic is not a bad idea, 
>From a documentation POV, you do not have to jump through many methods if you want to see the implementation and in terms of performance, you want the inlining to be done by hand because the methods of ArrayList are usually deep in the call graph, so you may reach the inlining threshold right inside removeFirst(). 

In general, you do not optimize applications and libraries the same way. 
Usually, you do not optimize application code that often but for a library, if a lot of people are using it, it may worth to spend time to optimize for the benefit of everybody. 

regards, 
R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250511/2efc53c1/attachment.htm>

From syan at openjdk.org  Sun May 11 14:36:50 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 11 May 2025 14:36:50 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v2]
In-Reply-To: <bnf8iIIZzedQLKLZSnqIeoVz_C-YTIEIVDKqCVFT_qY=.cdd3180a-7062-4a3d-882e-2e8de719d5ff@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
 <bnf8iIIZzedQLKLZSnqIeoVz_C-YTIEIVDKqCVFT_qY=.cdd3180a-7062-4a3d-882e-2e8de719d5ff@github.com>
Message-ID: <KwCneGmvqrRUKwV_0xcU1M6HCt4-Fgdh5cjemRb3qlQ=.10fc4c4c-a7e2-40a5-b195-62ad7d774dcc@github.com>

On Fri, 9 May 2025 15:39:35 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
>> 
>> 
>> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
>> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
>> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
>> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
>> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   generate_unsafecopy_common_error_exit

Changes requested by syan (Committer).

test/micro/org/openjdk/bench/java/lang/foreign/MemorySegmentFillUnsafe.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

2025 maybe more suitable

-------------

PR Review: https://git.openjdk.org/jdk/pull/25147#pullrequestreview-2831415179
PR Review Comment: https://git.openjdk.org/jdk/pull/25147#discussion_r2083540891

From liach at openjdk.org  Sun May 11 15:17:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 11 May 2025 15:17:55 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v3]
In-Reply-To: <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com>
Message-ID: <roVX3LMQmky1O4czbD4Csm_8nKwMt2ig2LtDqSD513E=.85520961-f85d-4568-bc4c-21f7c5f3ce27@github.com>

On Fri, 9 May 2025 21:29:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects another review comment

I looked for the other mentions of System.in without references to stdin.encoding, notably:
1. FileDescriptor.in: Unfortunately FileInputStream(FileDescriptor) has no overload that supports custom charsets. We should probably document both on this FD and that constructor.
2. JShell.in and JavaShellToolBuilder.in 
3. A few usages in security, like password reading in sun.security.tools.keytool.Main, or javax.security.auth.callback.CallbackHandler

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25155#issuecomment-2869933924

From chen.l.liang at oracle.com  Sun May 11 15:41:25 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sun, 11 May 2025 15:41:25 +0000
Subject: Unnecessary logic is added to removeFirst and removeLast of
 ArrayList.
In-Reply-To: <1675779578.260699311.1746958577836.JavaMail.zimbra@univ-eiffel.fr>
References: <7761d3554e8cd5fd861579a4fe705044@cweb008.nm>
 <1675779578.260699311.1746958577836.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <SJ2PR10MB7669B7D8414AC6578BABC38DA294A@SJ2PR10MB7669.namprd10.prod.outlook.com>

>  where the generated assembly code by the JITs is checked by humans

Is it? I have heard anecdotes that it is still slower than direct array usage, presumably due to the modCount tracking mechanism. Don't know if escape analysis and the resulting stack allocation in the compiled code eliminates that field.

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Sunday, May 11, 2025 5:16 AM
To: ??? <godmlzkf1 at naver.com>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: Unnecessary logic is added to removeFirst and removeLast of ArrayList.

Duplicating the logic is bad in some cases and not that bad in other cases.

Here ArrayList is one of the most used class in Java (with String and HashMap), it is heavily optimized (to the point where the generated assembly code by the JITs is checked by humans), so duplicating the logic is not a bad idea,
From a documentation POV, you do not have to jump through many methods if you want to see the implementation and in terms of performance, you want the inlining to be done by hand because the methods of ArrayList are usually deep in the call graph, so you may reach the inlining threshold right inside removeFirst().

In general, you do not optimize applications and libraries the same way.
Usually, you do not optimize application code that often but for a library, if a lot of people are using it, it may worth to spend time to optimize for the benefit of everybody.

regards,
R?mi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250511/353301d3/attachment.htm>

From alanb at openjdk.org  Sun May 11 16:48:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 11 May 2025 16:48:52 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v3]
In-Reply-To: <roVX3LMQmky1O4czbD4Csm_8nKwMt2ig2LtDqSD513E=.85520961-f85d-4568-bc4c-21f7c5f3ce27@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com>
 <roVX3LMQmky1O4czbD4Csm_8nKwMt2ig2LtDqSD513E=.85520961-f85d-4568-bc4c-21f7c5f3ce27@github.com>
Message-ID: <qCYw6HZXz7G6A5oP8TMu6gDveR92Oqmi4AV-eWm5HCo=.f22a833b-f769-4613-bd9a-512f47f281eb@github.com>

On Sun, 11 May 2025 15:15:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> 1. FileDescriptor.in: Unfortunately FileInputStream(FileDescriptor) has no overload that supports custom charsets. We should probably document both on this FD and that constructor.

FYI, FileInputStream is an InputStream so reading bytes, not chars, and should not say anything about Chrasets.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25155#issuecomment-2869974486

From alanb at openjdk.org  Sun May 11 17:09:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 11 May 2025 17:09:52 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
Message-ID: <0dcTQBkhjRuEbzel6ux6ZX6pGg9BgVWSbSXYI5QI3L4=.0f7b1564-ede4-4c43-b3a2-29fb0b54d8cf@github.com>

On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge

Marked as reviewed by alanb (Reviewer).

I ran tier1-6 so I think we are good and there isn't anything left to bring over from the loom repo. There are a few files that will need their copyright header updated before integration. The CSR also needs to be finalized.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24923#pullrequestreview-2831452149
PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2870007648

From liach at openjdk.org  Sun May 11 17:37:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 11 May 2025 17:37:50 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v3]
In-Reply-To: <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com>
Message-ID: <uO7LaR7qFVG_zma9pimzrifARz6HqZQ3af7ZOveJwas=.91fb26e6-cb73-422d-8464-69539197aaa5@github.com>

On Fri, 9 May 2025 21:29:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects another review comment

Oops, I meant the wrong constructor - the `FileReader(FileDescriptor fd)` one that does not have a charset overload.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25155#issuecomment-2870021180

From forax at univ-mlv.fr  Sun May 11 17:43:53 2025
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sun, 11 May 2025 19:43:53 +0200 (CEST)
Subject: Unnecessary logic is added to removeFirst and removeLast of
 ArrayList.
In-Reply-To: <SJ2PR10MB7669B7D8414AC6578BABC38DA294A@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <7761d3554e8cd5fd861579a4fe705044@cweb008.nm>
 <1675779578.260699311.1746958577836.JavaMail.zimbra@univ-eiffel.fr>
 <SJ2PR10MB7669B7D8414AC6578BABC38DA294A@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <833229561.260895323.1746985433257.JavaMail.zimbra@univ-eiffel.fr>

> From: "Chen Liang" <chen.l.liang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Sunday, May 11, 2025 5:41:25 PM
> Subject: Re: Unnecessary logic is added to removeFirst and removeLast of
> ArrayList.

> > where the generated assembly code by the JITs is checked by humans

> Is it?

At least, it was true during the Java 8 timeframe :) 
At that time, i was involved in the effort of updating the collection API to use lambdas. 

I suppose that the introduction of value types will trigger a similar effort (even if it seems less easier to use value types to optimize the collection API because the spec allows a lot of modifications). 

> I have heard anecdotes that it is still slower than direct array usage,
> presumably due to the modCount tracking mechanism. Don't know if escape
> analysis and the resulting stack allocation in the compiled code eliminates
> that field.

I've recently bench array vs arraylist (while testing the performance of StableValue.list()), 
for 1024 string ("0", "1", "2" etc), on my Mac M2 air, i get 

// Benchmark                    Mode  Cnt     Score   Error  Units 
// StableListBench.array        avgt    5   427,889 ? 1,553  ns/op 
// StableListBench.arraylist    avgt    5   605,542 ? 1,372  ns/op 
// StableListBench.asList       avgt    5   572,532 ? 2,574  ns/op 
// StableListBench.list_of      avgt    5   615,069 ? 0,341  ns/op 
// StableListBench.stable_list  avgt    5  1897,948 ? 2,119  ns/op 
with 
@Benchmark 
public int list_of () { 
var sum = 0 ; 
for ( var item : listof ) { 
sum += item .length(); 
} 
return sum ; 
} 

So at least, I can say that on my mac, direct array usage is more efficient. 
(BTW, using an arraylist is more effcient than using List.of()/List.copyOf() because ListN inherits from the iterator of AbstractList instead of having its own). 

regards, 
R?mi 

> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax
> <forax at univ-mlv.fr>
> Sent: Sunday, May 11, 2025 5:16 AM
> To: ??? <godmlzkf1 at naver.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.org>
> Subject: Re: Unnecessary logic is added to removeFirst and removeLast of
> ArrayList.
> Duplicating the logic is bad in some cases and not that bad in other cases.

> Here ArrayList is one of the most used class in Java (with String and HashMap),
> it is heavily optimized (to the point where the generated assembly code by the
> JITs is checked by humans), so duplicating the logic is not a bad idea,
> From a documentation POV, you do not have to jump through many methods if you
> want to see the implementation and in terms of performance, you want the
> inlining to be done by hand because the methods of ArrayList are usually deep
> in the call graph, so you may reach the inlining threshold right inside
> removeFirst().

> In general, you do not optimize applications and libraries the same way.
> Usually, you do not optimize application code that often but for a library, if a
> lot of people are using it, it may worth to spend time to optimize for the
> benefit of everybody.

> regards,
> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250511/211c962c/attachment-0001.htm>

From j3graham at gmail.com  Sun May 11 18:37:15 2025
From: j3graham at gmail.com (Johannes Graham)
Date: Sun, 11 May 2025 14:37:15 -0400
Subject: Optimization of BigDecimal.valueOf(double)
Message-ID: <CALfq9Lupg+F70KN+1ZZt8noNRmGX2RWoEcyqsiYt1J=kjhbiaQ@mail.gmail.com>

This is somewhat of followup to a conversation a few months ago [1]
regarding the non-existence of a BigDecimal.valueOf(float) method. While it
wasn't the primary issue, the matter of performance did come up.  Based on
that, I have been experimenting with making some improvements there.

I have a draft PR [2] open that leads to an improvement of around 6x for
me. If there is interest in this change, I would need someone to open a
JIRA for this.

Thanks,

Johannes

[1]
https://mail.openjdk.org/pipermail/core-libs-dev/2025-January/139074.html
[2] https://github.com/openjdk/jdk/pull/25173
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250511/dba71cb9/attachment.htm>

From kbarrett at openjdk.org  Sun May 11 19:13:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 11 May 2025 19:13:52 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v12]
In-Reply-To: <aywAMR14DaO2dPfzllNsKNfkjbXEIINzNB8aZUBevYo=.a6901bc0-35a0-4fbc-84af-7532f3da8a4c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <aywAMR14DaO2dPfzllNsKNfkjbXEIINzNB8aZUBevYo=.a6901bc0-35a0-4fbc-84af-7532f3da8a4c@github.com>
Message-ID: <tkStczMT5a1Bn13ih4GEUb2YqYTZboeaIlqCLAW5ul4=.07c5fbd7-743c-4067-80b5-1f2c695af54d@github.com>

On Sat, 10 May 2025 20:28:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

I'm coming here from "far away" and am not familiar with all the work leading
up to this proposal, so maybe there's some rationale that I don't know about.
(I did look, but didn't find anything other than this draft JEP:
https://openjdk.org/jeps/8340476. And that doesn't really deal with the issue
I discuss below.)

Keeping that in mind, I'm surprised by some parts of this change.  Specifically

2) Apply the annotation to the following:
- The referent parameter of all constructors in classes PhantomReference, SoftReference, and WeakReference
...
 - The type parameter T of Reference, PhantomReference, SoftReference, WeakReference, and ReferenceQueue 

I wonder why it is not sufficient to apply the annotation to the type
parameter T of Reference, and leave it at that?

The type parameter of the subclasses is passed as the type parameter to
Reference in the `extends` clause. I would expect if the type parameter for a
subclass didn't satisfy the annotation that would be noticed there. Indeed, if
that isn't the case then many uses of Reference types won't benefit from this
annotation, since they are using classes derived from one of those subclasses
and won't have this internal annotation. That would significantly limit the
utility of this annotation in this area.

Similarly, I wonder why the constructors need the annotation. And why don't
the return type of `get` or the argument for `Reference::refersTo` need it?
(Maybe because those values can be null? But there's nothing that prevents
passing null to one of the constructors. It's not very useful to do so, but
not forbidden.  I've even seen a use-case for doing so.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2870055928

From duke at openjdk.org  Sun May 11 21:54:56 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Sun, 11 May 2025 21:54:56 GMT
Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used
 outside the compiler
In-Reply-To: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
References: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
Message-ID: <tKZ73v7oP5r5MvRUIcg-8wy8w6k_KX-Gd4B3cfxAPnk=.9ffd9314-39ef-4ccf-8ab9-ff0802a79f0f@github.com>

On Wed, 7 May 2025 11:57:02 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation.
> 
> For example this is not valid Java (and protected) by javac:
> 
> 
> byte b = 1;
> switch (b) {
>     case String s -> System.out.println("How did we get here? byte is " + s.getClass());
> }
> 
> 
> but this is a valid call (and not protected):
> 
> 
> CallSite shortSwitch = SwitchBootstraps.typeSwitch(
>     MethodHandles.lookup(), 
>     "", 
>     MethodType.methodType(int.class, short.class, int.class),  // models (short, int) -> int
>     String.class);
> 
> 
> The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. 
> 
> This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 782:

> 780:         else if (selectorType.equals(targetType) ||
> 781:                 (targetType.isPrimitive() && selectorType.isPrimitive() &&
> 782:                     ((selectorType.equals(byte.class) && !targetType.equals(char.class)) ||

Will `unconditionalExactnessMatch(byte.class, boolean.class` return `true`? I think it shouldn't, even if `isNotValidPair` is called before.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2083628555

From jpai at openjdk.org  Mon May 12 01:11:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 May 2025 01:11:00 GMT
Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for ZIP entry with
 empty file data [v2]
In-Reply-To: <eh0QjAzXgcATScECaeqQUbBLx2IRaf9hRGjknh8Q7g8=.7b30e0a9-36aa-4023-9ceb-e257aed902a8@github.com>
References: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
 <eh0QjAzXgcATScECaeqQUbBLx2IRaf9hRGjknh8Q7g8=.7b30e0a9-36aa-4023-9ceb-e257aed902a8@github.com>
Message-ID: <SvhlgYgzo9cTMQpJS-q6826at7jX-A6qjC3XJhM5kd4=.c239a51f-91d6-4850-90c0-e5ee0e550d43@github.com>

On Fri, 9 May 2025 07:07:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799?
>> 
>> `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix.
>> 
>> tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's suggestion - use assertThrows()

Hello Alan,

> > > I'll run some experiments and see what it shows up.
> > 
> > 
> > Thanks as that will help inform as to whether this will need a compatibility knob.
> 
> The crc is calculated as part of the write of the entry and I have not seen any cases, where the CRC is not 0 for a directory/ 0-length file

In addition to Lance's investigation, I also ran some experiments against a large number of jars. The results show that none of them are impacted by this change. More specifically, like Lance notes, the CRC values for the case of empty file data (or directory), the CRC is always 0. So the proposed change in this PR isn't expected to run into a JAR/ZIP which will trigger an exception when this CRC is now checked for such entries.

So I think we won't need a configuration property for this case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25116#issuecomment-2870444933

From jpai at openjdk.org  Mon May 12 01:20:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 May 2025 01:20:07 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v12]
In-Reply-To: <QQz0fuco5e10bsnlLrLkV-52s9ONaPJwfqCpXfZCfK4=.75cd9f62-b37c-4c7d-8883-0b8333322131@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>
 <QQz0fuco5e10bsnlLrLkV-52s9ONaPJwfqCpXfZCfK4=.75cd9f62-b37c-4c7d-8883-0b8333322131@github.com>
Message-ID: <xcxCND4TolntVAJ07uxXC3cXgCKscV3Dul1NFyN3BYs=.d2643648-e18f-49ec-b604-6b9c0b7f79a1@github.com>

On Fri, 9 May 2025 20:35:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Markus KARG 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 latest from master branch
>>  - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted?
>>  - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs
>>  - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since.
>>  - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.'
>>  - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars()
>>  - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()
>>  - 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)'
>>  - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted?
>>  - Applied changes requested by Alan: Copies chars from this sequence into the given destination array
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a
>
> src/java.base/share/classes/java/lang/CharSequence.java line 313:
> 
>> 311:      * at index {@code dstBegin} and ending at index:
>> 312:      * <pre>{@code
>> 313:      * dstbegin + (srcEnd-srcBegin) - 1
> 
> Shouldn't it be dstBegin?
> 
> * dstBegin + (srcEnd-srcBegin) - 1

Hello Andrey, what you note is right. This and the other change you have proposed to this text seems reasonable. Do you want to create a JBS issue and raise a PR proposing this change?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2083686557

From liach at openjdk.org  Mon May 12 02:22:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 May 2025 02:22:27 GMT
Subject: RFR: 8356694: Removed unused subclass audits in
 ObjectInput/OutputStream
Message-ID: <Bpn80v8P8rOPoX9YaJwvzFPXMsPeP58D8BPoPOVtNIg=.f585f37b-1a6d-4eeb-a235-8b21c5add944@github.com>

These two subclass audits in ObjectInputStream and ObjectOutputStream were only used when security managers are present, which is no longer the case in releases 24 and newer. Thus, we can remove these two redundant `ClassValue` and the computation methods safely.

Testing: java/io/Serializable and ObjectInput, jdk tier 1-3 in progress

-------------

Commit messages:
 - 8356694: Removed unused subclass audits in ObjectInput/OutputStream

Changes: https://git.openjdk.org/jdk/pull/25174/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25174&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356694
  Stats: 71 lines in 2 files changed: 0 ins; 69 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25174.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25174/head:pull/25174

PR: https://git.openjdk.org/jdk/pull/25174

From alanb at openjdk.org  Mon May 12 06:26:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 May 2025 06:26:56 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v16]
In-Reply-To: <2AyhnZiLia6FKXoJlSzArzhIiWCchzGM_EJ9hWj93_Y=.175dfeff-fc4e-46f8-9c80-413b9e4971e3@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <2AyhnZiLia6FKXoJlSzArzhIiWCchzGM_EJ9hWj93_Y=.175dfeff-fc4e-46f8-9c80-413b9e4971e3@github.com>
Message-ID: <82sPe3Kc8mt9lhFzvvgWkQNWjVwSnRnfZcluBehOfZI=.a124a4bc-82ee-4105-a4de-94bb7eca7cb2@github.com>

On Tue, 6 May 2025 15:43:07 GMT, Brian Burkhalter <bpb at openjdk.org> 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: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test

For the APIs then both methods will need to specify what they return when already at end of stream, does readAllAsString return an empty or null, does readAllLines return an empty list?  

Also, you look at the paragraph that we put in InputStream.readAllBytes to cover the case where the reader is asynchronously closed or the thread interrupted while blocked reading the remaining characters?  There is also wording about the I/O error case that I think can come over too as it is more complete than what is in the current PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2871020072

From alanb at openjdk.org  Mon May 12 06:31:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 May 2025 06:31:52 GMT
Subject: RFR: 8356694: Removed unused subclass audits in
 ObjectInput/OutputStream
In-Reply-To: <Bpn80v8P8rOPoX9YaJwvzFPXMsPeP58D8BPoPOVtNIg=.f585f37b-1a6d-4eeb-a235-8b21c5add944@github.com>
References: <Bpn80v8P8rOPoX9YaJwvzFPXMsPeP58D8BPoPOVtNIg=.f585f37b-1a6d-4eeb-a235-8b21c5add944@github.com>
Message-ID: <6aSSeleHyKu2MpKIcaJsO-hMCcsmSueFM2w_5E0QYTs=.9d928a88-e996-45df-b56b-43497da18972@github.com>

On Mon, 12 May 2025 02:18:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> These two subclass audits in ObjectInputStream and ObjectOutputStream were only used when security managers are present, which is no longer the case in releases 24 and newer. Thus, we can remove these two redundant `ClassValue` and the computation methods safely.
> 
> Testing: java/io/Serializable and ObjectInput, jdk tier 1-3 in progress

Looks okay, looks like it was missed in the post JEP 486 cleanup.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25174#pullrequestreview-2831959455

From pminborg at openjdk.org  Mon May 12 06:54:51 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 May 2025 06:54:51 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v2]
In-Reply-To: <bnf8iIIZzedQLKLZSnqIeoVz_C-YTIEIVDKqCVFT_qY=.cdd3180a-7062-4a3d-882e-2e8de719d5ff@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
 <bnf8iIIZzedQLKLZSnqIeoVz_C-YTIEIVDKqCVFT_qY=.cdd3180a-7062-4a3d-882e-2e8de719d5ff@github.com>
Message-ID: <xZsmD7wHsVKZ64HybXNJX5JDHHDASkPcv8mtkm331zU=.345ade62-4784-45a9-a79f-25ab0bc3a66c@github.com>

On Fri, 9 May 2025 15:39:35 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
>> 
>> 
>> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
>> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
>> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
>> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
>> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   generate_unsafecopy_common_error_exit

Looking at the improvements made, I suggest we also change (in `SegmentBulkOperations`):


private static final int NATIVE_THRESHOLD_FILL = powerOfPropertyOr("fill", Architecture.isAARCH64() ? 18 : 5); 


to 


 private static final int NATIVE_THRESHOLD_FILL = powerOfPropertyOr("fill",  5);

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2871092439

From pminborg at openjdk.org  Mon May 12 07:03:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 May 2025 07:03:03 GMT
Subject: Integrated: 8347408: Create an internal method handle adapter for
 system calls with errno
In-Reply-To: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
References: <3mYJJIhuMlNCcAWSmU5x4QpZHvwbDx_-QMtz1YzMKvU=.70bbede9-4698-4df4-bd7b-9def30f15e1d@github.com>
Message-ID: <p_ax7oAetRYT5hZ6ckRPQ-o-qK_awA84rVzQ0hlL3O0=.336a64ae-257c-4b4a-ae41-fcc63a5ff879@github.com>

On Mon, 5 May 2025 16:53:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.

This pull request has now been integrated.

Changeset: 45cf32bd
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45cf32bd2c9e44e2fcbb4b8d0714b87e078cdb7c
Stats:     650 lines in 4 files changed: 649 ins; 0 del; 1 mod

8347408: Create an internal method handle adapter for system calls with errno

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/25043

From alanb at openjdk.org  Mon May 12 07:03:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 May 2025 07:03:56 GMT
Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for ZIP entry with
 empty file data [v2]
In-Reply-To: <SvhlgYgzo9cTMQpJS-q6826at7jX-A6qjC3XJhM5kd4=.c239a51f-91d6-4850-90c0-e5ee0e550d43@github.com>
References: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
 <eh0QjAzXgcATScECaeqQUbBLx2IRaf9hRGjknh8Q7g8=.7b30e0a9-36aa-4023-9ceb-e257aed902a8@github.com>
 <SvhlgYgzo9cTMQpJS-q6826at7jX-A6qjC3XJhM5kd4=.c239a51f-91d6-4850-90c0-e5ee0e550d43@github.com>
Message-ID: <ZALp5jjfu74sBbxMEhctm3IgkwVMJaN84IPBmlWZMp8=.28a2bdde-1136-4c66-b3be-a259797bea82@github.com>

On Mon, 12 May 2025 01:08:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> In addition to Lance's investigation, I also ran some experiments against a large number of jars. The results show that none of them are impacted by this change. More specifically, like Lance notes, the CRC values for the case of empty file data (or directory), the CRC is always 0. So the proposed change in this PR isn't expected to run into a JAR/ZIP which will trigger an exception when this CRC is now checked for such entries.

Thanks for the investigations, this helps with the confidence that this isn't going to be disruptive.  The main concern with any tightening of validation is that a popular tool or plugin is generated ZIP or JAR files that fail this validation. So I think the change is okay and if something comes up then we still have the option of introducing a compatibility knob in the future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25116#issuecomment-2871116967

From pminborg at openjdk.org  Mon May 12 07:14:59 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 May 2025 07:14:59 GMT
Subject: Integrated: 8356486: ReverseOrderListView should override reversed()
 to return `base`
In-Reply-To: <X2vnz1BagQ5K7q-2_oHt9X1JjejNJw5TE44vSUJKeaU=.28fad491-d94c-4fcb-9a44-001a62e0beb4@github.com>
References: <X2vnz1BagQ5K7q-2_oHt9X1JjejNJw5TE44vSUJKeaU=.28fad491-d94c-4fcb-9a44-001a62e0beb4@github.com>
Message-ID: <QjvukaKEycsBQOpiXAGnMk2sIirMIyjd9tbvftXfwFc=.32bf5b2c-3ba0-4256-9e9a-83e47a3677fa@github.com>

On Thu, 8 May 2025 14:30:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to let `ReverseOrderListView::reversed` directly return `base` instead of going though a more complicated code path.

This pull request has now been integrated.

Changeset: 43008b42
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43008b42cf98466b4c4528d357bfcc2ae309770a
Stats:     7 lines in 1 file changed: 4 ins; 2 del; 1 mod

8356486: ReverseOrderListView should override reversed() to return `base`

Reviewed-by: liach, smarks

-------------

PR: https://git.openjdk.org/jdk/pull/25120

From pminborg at openjdk.org  Mon May 12 07:16:59 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 May 2025 07:16:59 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
 [v2]
In-Reply-To: <11qM0h_1z3Sws5UhAMhkDr4Kr5IEYPzSOKlyJz04OWM=.b1b2caa6-9bc6-4eaa-a119-9e1bf40f4fce@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
 <1tTlsd8W1XcfpCvL8P8pozXnvJWBmMtB_ObsAYLBZso=.029cc42a-a477-466f-846e-db19ac454c6b@github.com>
 <11qM0h_1z3Sws5UhAMhkDr4Kr5IEYPzSOKlyJz04OWM=.b1b2caa6-9bc6-4eaa-a119-9e1bf40f4fce@github.com>
Message-ID: <KWY1b4ZGqtefMNISWaOeu8NpaYnbbXHXjpa5SeIhenk=.5232d0ca-0065-459a-ad5e-9ebce7717429@github.com>

On Fri, 9 May 2025 14:55:06 GMT, Chen Liang <liach at openjdk.org> 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 384 commits:
>> 
>>  - Fix an issue with toString on nested constructs
>>  - Merge branch 'master' into jep502-followup
>>  - Merge branch 'master' into jep502-followup
>>  - Update src/java.base/share/classes/java/lang/StableValue.java
>>    
>>    Co-authored-by: Chen Liang <liach at openjdk.org>
>>  - Simplify furhter
>>  - Address comments in PR
>>  - Merge master
>>  - Remove unused method and add comment
>>  - Address comments
>>  - Merge branch 'master' into jep502-followup
>>  - ... and 374 more: https://git.openjdk.org/jdk/compare/900b3ff7...3eebd504
>
> src/java.base/share/classes/java/util/ReverseOrderListView.java line 46:
> 
>> 44:     final List<E> base;
>> 45:     @Stable
>> 46:     final boolean modifiable;
> 
> Unfortunately, stable on boolean only works for true - wish we can get trusted or strict final soon :)

We could change it to `Boolean`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2083985618

From alanb at openjdk.org  Mon May 12 07:24:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 May 2025 07:24:56 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v3]
In-Reply-To: <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com>
Message-ID: <Z6bJ68IgNergbAKVTl_RtS3MpFYOF2280WddkZKd1z8=.c1364895-268d-4503-a6f3-d1a3fee3adf8@github.com>

On Fri, 9 May 2025 21:29:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects another review comment

src/java.base/share/classes/java/io/InputStreamReader.java line 54:

> 52:  * }
> 53:  * This example also demonstrates how to wrap {@link System#in} with {@link
> 54:  * System##stdin.encoding stdin.encoding}.

This example communicate two concerns, one is buffering, the other is the charset to use when running from System.in. I think we should separate these two, make with two examples.

src/java.base/share/classes/java/util/Scanner.java line 82:

> 80:  *
> 81:  * <p>This code reads lines from {@link System#in} with {@link
> 82:  * System##stdin.encoding stdin.encoding}:

"from System.in with stdin.encoding" isn't very clear. I think you we can expand the sentence, or make it two sentences, so to that is uses a Scanner to read lines from System.in, and uses the value of stdin.encoding as the charset.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2083997044
PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2083991533

From pminborg at openjdk.org  Mon May 12 07:42:16 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 May 2025 07:42:16 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
 [v3]
In-Reply-To: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
Message-ID: <qh0f5DcpfqP7C07o9Ynhm-bUnzpZwhXyACKKzILTwok=.83a38bb6-55f0-41ed-941d-62ab826b483c@github.com>

> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
> 
> Unfortunately, this PR shows the total commit history for stable values.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 386 commits:

 - Address comments
 - Merge branch 'master' into jep502-followup
 - Fix an issue with toString on nested constructs
 - Merge branch 'master' into jep502-followup
 - Merge branch 'master' into jep502-followup
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - Simplify furhter
 - Address comments in PR
 - Merge master
 - Remove unused method and add comment
 - ... and 376 more: https://git.openjdk.org/jdk/compare/43008b42...a2826336

-------------

Changes: https://git.openjdk.org/jdk/pull/25004/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25004&range=02
  Stats: 358 lines in 13 files changed: 237 ins; 49 del; 72 mod
  Patch: https://git.openjdk.org/jdk/pull/25004.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25004/head:pull/25004

PR: https://git.openjdk.org/jdk/pull/25004

From vklang at openjdk.org  Mon May 12 08:14:03 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 12 May 2025 08:14:03 GMT
Subject: RFR: 8350765: Need to pin when accessing thread container from
 virtual thread
In-Reply-To: <G5nHVCpo-Kzs-63jq0uQXFpiXqObL8sapYh-Z8gA7rk=.4fe730d0-8571-4147-81b4-0b34f57ec54e@github.com>
References: <G5nHVCpo-Kzs-63jq0uQXFpiXqObL8sapYh-Z8gA7rk=.4fe730d0-8571-4147-81b4-0b34f57ec54e@github.com>
Message-ID: <HYt0QmBGKf3ZrOVDQOGeX4EfP2XZiYCWN0XOvpiJ6CA=.ac9f870c-d095-4bda-97a6-d77c9529df05@github.com>

On Wed, 26 Feb 2025 19:46:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Data structures that are accessed by both virtual threads and their carriers require the virtual thread to pin the continuation to avoid potential deadlock. A deadlock can arise when a virtual thread is preempted, is selected and scheduled to be the next owner of the lock/resource, but can't execute because all carriers are blocking on the same lock/resource. There are a small number of places that need to pin. One that was missed is the the notification to the thread container when threads are started or terminate. This is not currently an issue at this time but it is a potential hazard for ongoing and future work that will add further scheduling points to the code.  Continuation.pin/unpin have intrinsics since JDK-8338745, and Continuation is initialized early in startup. Finally, the changes have been in the loom repo for several months with no issues.
> 
> Testing tier1-5, quick statup/footprint, noreg-hard

Nice work, Alan

src/java.base/share/classes/jdk/internal/vm/ContinuationSupport.java line 57:

> 55:      */
> 56:     public static void pinIfSupported() {
> 57:         if (ContinuationSupport.isSupported()) {

Suggestion:

        if (isSupported()) {

src/java.base/share/classes/jdk/internal/vm/ContinuationSupport.java line 66:

> 64:      */
> 65:     public static void unpinIfSupported() {
> 66:         if (ContinuationSupport.isSupported()) {

Suggestion:

        if (isSupported()) {

-------------

Changes requested by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23810#pullrequestreview-2829366716
PR Review Comment: https://git.openjdk.org/jdk/pull/23810#discussion_r2082318599
PR Review Comment: https://git.openjdk.org/jdk/pull/23810#discussion_r2082318783

From alanb at openjdk.org  Mon May 12 08:14:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 May 2025 08:14:03 GMT
Subject: RFR: 8350765: Need to pin when accessing thread container from virtual
 thread
Message-ID: <G5nHVCpo-Kzs-63jq0uQXFpiXqObL8sapYh-Z8gA7rk=.4fe730d0-8571-4147-81b4-0b34f57ec54e@github.com>

Data structures that are accessed by both virtual threads and their carriers require the virtual thread to pin the continuation to avoid potential deadlock. A deadlock can arise when a virtual thread is preempted, is selected and scheduled to be the next owner of the lock/resource, but can't execute because all carriers are blocking on the same lock/resource. There are a small number of places that need to pin. One that was missed is the the notification to the thread container when threads are started or terminate. This is not currently an issue at this time but it is a potential hazard for ongoing and future work that will add further scheduling points to the code.  Continuation.pin/unpin have intrinsics since JDK-8338745, and Continuation is initialized early in startup. Finally, the changes have been in the loom repo for several months with no issues.

Testing tier1-5, quick statup/footprint, noreg-hard

-------------

Commit messages:
 - No need to used qualified name
 - Merge branch 'master' into JDK-8350765
 - Update
 - Merge branch 'master' into JDK-8350765
 - Add method to ContinuationSupport
 - Missing /
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/23810/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23810&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350765
  Stats: 92 lines in 6 files changed: 48 ins; 25 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/23810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23810/head:pull/23810

PR: https://git.openjdk.org/jdk/pull/23810

From pminborg at openjdk.org  Mon May 12 08:27:00 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 May 2025 08:27:00 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v4]
In-Reply-To: <EBXXrcYB3HoB7nEMu434D4-pr9L7L-jySD-JX4o28so=.7a6632a7-fb92-4b07-80af-696df33a2815@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <EBXXrcYB3HoB7nEMu434D4-pr9L7L-jySD-JX4o28so=.7a6632a7-fb92-4b07-80af-696df33a2815@github.com>
Message-ID: <wtypfoR1ssVgV2szzJe6ZuWY2PGTy3nlR0j_PO8QnWk=.bd74752d-1669-42cf-b7d2-ad949f57324d@github.com>

On Fri, 9 May 2025 08:31:35 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright years

Latest changes look good.

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2832285086

From jpai at openjdk.org  Mon May 12 08:51:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 May 2025 08:51:53 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v4]
In-Reply-To: <EBXXrcYB3HoB7nEMu434D4-pr9L7L-jySD-JX4o28so=.7a6632a7-fb92-4b07-80af-696df33a2815@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <EBXXrcYB3HoB7nEMu434D4-pr9L7L-jySD-JX4o28so=.7a6632a7-fb92-4b07-80af-696df33a2815@github.com>
Message-ID: <LOv6YRT8KmIA7Hd5vfvUczgOYNkm6Xs1vxF-KiONvuA=.9efae4e6-0951-45b3-88ae-943f43a31f0e@github.com>

On Fri, 9 May 2025 08:31:35 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright years

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 2:

> 1: /*
> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

Hello Volkan, this should be `2024, 2025, `

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2084166104

From jpai at openjdk.org  Mon May 12 08:54:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 May 2025 08:54:54 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v4]
In-Reply-To: <EBXXrcYB3HoB7nEMu434D4-pr9L7L-jySD-JX4o28so=.7a6632a7-fb92-4b07-80af-696df33a2815@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <EBXXrcYB3HoB7nEMu434D4-pr9L7L-jySD-JX4o28so=.7a6632a7-fb92-4b07-80af-696df33a2815@github.com>
Message-ID: <BcqL5sH2nV9UW5oYM4gEnubzLcCkGfImWoXtkj-BP8k=.7848b5c8-427a-47dc-9d78-6e8b4c00578a@github.com>

On Fri, 9 May 2025 08:31:35 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright years

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 461:

> 459:      * make a copy.
> 460:      */
> 461:     Object stringConcat1(String[] constants);

Is this missing the `unchecked` prefix to the method name?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2084172186

From pminborg at openjdk.org  Mon May 12 09:03:32 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 May 2025 09:03:32 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed again
 with junit action timed out
Message-ID: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>

This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.

Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.

-------------

Commit messages:
 - Add safety net around stalled thread

Changes: https://git.openjdk.org/jdk/pull/25177/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356658
  Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25177/head:pull/25177

PR: https://git.openjdk.org/jdk/pull/25177

From jpai at openjdk.org  Mon May 12 09:03:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 May 2025 09:03:53 GMT
Subject: RFR: 8350765: Need to pin when accessing thread container from
 virtual thread
In-Reply-To: <G5nHVCpo-Kzs-63jq0uQXFpiXqObL8sapYh-Z8gA7rk=.4fe730d0-8571-4147-81b4-0b34f57ec54e@github.com>
References: <G5nHVCpo-Kzs-63jq0uQXFpiXqObL8sapYh-Z8gA7rk=.4fe730d0-8571-4147-81b4-0b34f57ec54e@github.com>
Message-ID: <j7F_yzUSSYJ3i1xGTncWVHOsIoBzl2YzQ_Y20GOrLOw=.81451ffb-a5ac-451a-a95f-ab21a307411d@github.com>

On Wed, 26 Feb 2025 19:46:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Data structures that are accessed by both virtual threads and their carriers require the virtual thread to pin the continuation to avoid potential deadlock. A deadlock can arise when a virtual thread is preempted, is selected and scheduled to be the next owner of the lock/resource, but can't execute because all carriers are blocking on the same lock/resource. There are a small number of places that need to pin. One that was missed is the the notification to the thread container when threads are started or terminate. This is not currently an issue at this time but it is a potential hazard for ongoing and future work that will add further scheduling points to the code.  Continuation.pin/unpin have intrinsics since JDK-8338745, and Continuation is initialized early in startup. Finally, the changes have been in the loom repo for several months with no issues.
> 
> Testing tier1-5, quick statup/footprint, noreg-hard

src/java.base/share/classes/jdk/internal/vm/ThreadContainer.java line 97:

> 95:     public final void add(Thread thread) {
> 96:         // Prevent a virtual thread from being preempted as this could potentially
> 97:         // deadlock with a carrier is removing a virtual thread from the container

Is there a typo in this sentence? Should "with a carrier" have been "when a carrier ..." ? Similar comment in the remove(...) method too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23810#discussion_r2084191952

From mcimadamore at openjdk.org  Mon May 12 09:19:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 May 2025 09:19:51 GMT
Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used
 outside the compiler
In-Reply-To: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
References: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
Message-ID: <Z6edQzqZJOW0plvUyTl6J5FxLgcbEsKDf0bKi5PCflg=.78f6180e-fb77-4507-a578-8cca193d8894@github.com>

On Wed, 7 May 2025 11:57:02 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation.
> 
> For example this is not valid Java (and protected) by javac:
> 
> 
> byte b = 1;
> switch (b) {
>     case String s -> System.out.println("How did we get here? byte is " + s.getClass());
> }
> 
> 
> but this is a valid call (and not protected):
> 
> 
> CallSite shortSwitch = SwitchBootstraps.typeSwitch(
>     MethodHandles.lookup(), 
>     "", 
>     MethodType.methodType(int.class, short.class, int.class),  // models (short, int) -> int
>     String.class);
> 
> 
> The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. 
> 
> This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 725:

> 723: 
> 724:     private static boolean isNotValidPair(Class<?> selectorType, Object caseLabel) {
> 725:         return (selectorType == boolean.class && caseLabel != boolean.class && caseLabel != Boolean.class) ||

What happens if `caseLabel` is a reference class? E.g. a `boolean` selector is incompatible with `String`.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 786:

> 784:                      (selectorType.equals(char.class)  && (selectorWrapper.isStrictSubRangeOf(targetWrapper)))  ||
> 785:                      (selectorType.equals(int.class)   && (targetType.equals(double.class) || targetType.equals(long.class))) ||
> 786:                      (selectorType.equals(float.class) && (selectorWrapper.isStrictSubRangeOf(targetWrapper)))))) return true;

Is `double` the only allowed target for `float` ? If so, perhaps we could simplify like for other selector types.
Or, alternatively, I wonder if it wouldn't be simpler to _always_ check for strict subrange on the wrappers, but then ban the conversions that are not exact (e.g. int -> float), as those are few?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2084222014
PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2084221014

From adinn at openjdk.org  Mon May 12 09:20:52 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 12 May 2025 09:20:52 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v2]
In-Reply-To: <bnf8iIIZzedQLKLZSnqIeoVz_C-YTIEIVDKqCVFT_qY=.cdd3180a-7062-4a3d-882e-2e8de719d5ff@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
 <bnf8iIIZzedQLKLZSnqIeoVz_C-YTIEIVDKqCVFT_qY=.cdd3180a-7062-4a3d-882e-2e8de719d5ff@github.com>
Message-ID: <w2xj_OTt0lVIIcL9nVTC-jWTLU5TzbuiYuqYScWb740=.c77c28bb-bc3e-4646-bd60-e3090e0accd3@github.com>

On Fri, 9 May 2025 15:39:35 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
>> 
>> 
>> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
>> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
>> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
>> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
>> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   generate_unsafecopy_common_error_exit

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 2611:

> 2609: 
> 2610:       __ subs(count, count, 64);
> 2611:       __ add(dest, dest, 64);

This add could be elided by employing a post-increment on dest in each of the two writes above, saving on code size. Is there a reason to prefer the add?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25147#discussion_r2084225622

From pminborg at openjdk.org  Mon May 12 09:35:08 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 May 2025 09:35:08 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out [v2]
In-Reply-To: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
Message-ID: <sPsiKUOg8qvw01UPmwD8ZKDc6av8j1ZCE55tbCGJgnU=.9781dc44-1114-406a-9f71-5c5d60ba5f41@github.com>

> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
> 
> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add shutdown

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25177/files
  - new: https://git.openjdk.org/jdk/pull/25177/files/3547359f..c4f50471

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25177/head:pull/25177

PR: https://git.openjdk.org/jdk/pull/25177

From jpai at openjdk.org  Mon May 12 09:35:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 May 2025 09:35:08 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out [v2]
In-Reply-To: <sPsiKUOg8qvw01UPmwD8ZKDc6av8j1ZCE55tbCGJgnU=.9781dc44-1114-406a-9f71-5c5d60ba5f41@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
 <sPsiKUOg8qvw01UPmwD8ZKDc6av8j1ZCE55tbCGJgnU=.9781dc44-1114-406a-9f71-5c5d60ba5f41@github.com>
Message-ID: <2obeae4mCNTHQck4IShjXJr07D5vtl-Z-_P7dYYNIO4=.e6b60cc7-8d71-4c46-ad51-0961bc43182d@github.com>

On Mon, 12 May 2025 09:32:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
>> 
>> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add shutdown

test/jdk/java/foreign/TestBufferStackStress2.java line 139:

> 137:             // This is a corner case for rare configurations
> 138:             System.out.println(duration(begin) + "ABORTED");
> 139:             System.exit(0);

Hello Per, a `System.exit(...)` call isn't recommended in a jtreg test (https://openjdk.org/jtreg/faq.html#should-a-test-call-the-system.exit-method)

On a general note though, I think this test might need a different solution to address the issue. For one, I think it might be better to use `@run junit/othervm` instead of the current `@run junit` to prevent any agent VM specific state to interfere with this test.

Secondly, I think in its current form the test may still have a race. The main thread which does the `quiescent.notify();` may execute before the other thread reaches the `quiescent.wait();`. That can cause the other thread to wait forever. I think to avoid this, a `CountDownLatch` might be more appropriate. Something like (the untested change below):


diff --git a/test/jdk/java/foreign/TestBufferStackStress2.java b/test/jdk/java/foreign/TestBufferStackStress2.java
index 8ec5d512ff6..0ba28ad6f9e 100644
--- a/test/jdk/java/foreign/TestBufferStackStress2.java
+++ b/test/jdk/java/foreign/TestBufferStackStress2.java
@@ -38,6 +38,7 @@
 import java.lang.foreign.ValueLayout;
 import java.time.Duration;
 import java.time.temporal.ChronoUnit;
+import java.util.concurrent.CountDownLatch;
 import java.util.concurrent.Executors;
 import java.util.concurrent.ForkJoinWorkerThread;
 import java.util.concurrent.atomic.AtomicBoolean;
@@ -78,7 +79,7 @@ void movingVirtualThreadWithGc() throws InterruptedException {
 
         var done = new AtomicBoolean();
         var completed = new AtomicBoolean();
-        var quiescent = new Object();
+        var quiescentLatch = new CountDownLatch(1);
         var executor = Executors.newVirtualThreadPerTaskExecutor();
 
         executor.submit(() -> {
@@ -93,12 +94,11 @@ void movingVirtualThreadWithGc() throws InterruptedException {
             try (Arena arena = pool.pushFrame(SMALL_ALLOC_SIZE, 1)) {
                 MemorySegment segment = arena.allocate(SMALL_ALLOC_SIZE);
                 done.set(true);
-                synchronized (quiescent) {
-                    try {
-                        quiescent.wait();
-                    } catch (Throwable ex) {
-                        throw new AssertionError(ex);
-                    }
+                // wait for ForkJoinPool to contract
+                try {
+                    quiescentLatch.await();
+                } catch (Throwable ex) {
+                    throw new AssertionError(ex);
                 }
                 System.out.println(duration(begin) + "ACCESSING SEGMENT");
 
@@ -123,10 +123,7 @@ void movingVirtualThreadWithGc() throws InterruptedException {
         } while (count > 0);
 
         System.out.println(duration(begin) + "FJP HAS CONTRACTED");
-
-        synchronized (quiescent) {
-            quiescent.notify();
-        }
+        quiescentLatch.countDown(); // notify the thread that accesses the MemorySegment
 
         System.out.println(duration(begin) + "CLOSING EXECUTOR");
         executor.close();

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25177#discussion_r2084250912

From aph at openjdk.org  Mon May 12 09:37:24 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 May 2025 09:37:24 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v3]
In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
Message-ID: <Gix8VStTsn9J1qfuhtqlIo0rWzhEV6r-rpi5eiUTWTc=.1ebe73c3-cac9-4de1-9def-022077bb6ba4@github.com>

> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
> 
> 
> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Stub stack frame

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25147/files
  - new: https://git.openjdk.org/jdk/pull/25147/files/1078ba8c..47179d57

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=01-02

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25147/head:pull/25147

PR: https://git.openjdk.org/jdk/pull/25147

From aph at openjdk.org  Mon May 12 09:37:24 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 May 2025 09:37:24 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v2]
In-Reply-To: <w2xj_OTt0lVIIcL9nVTC-jWTLU5TzbuiYuqYScWb740=.c77c28bb-bc3e-4646-bd60-e3090e0accd3@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
 <bnf8iIIZzedQLKLZSnqIeoVz_C-YTIEIVDKqCVFT_qY=.cdd3180a-7062-4a3d-882e-2e8de719d5ff@github.com>
 <w2xj_OTt0lVIIcL9nVTC-jWTLU5TzbuiYuqYScWb740=.c77c28bb-bc3e-4646-bd60-e3090e0accd3@github.com>
Message-ID: <8nuQIwaoVWwaSrsAE8oni5LET--OIIsSloJYgenOUY8=.68950b83-957d-48f6-87e1-a63f88197df5@github.com>

On Mon, 12 May 2025 09:18:13 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   generate_unsafecopy_common_error_exit
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 2611:
> 
>> 2609: 
>> 2610:       __ subs(count, count, 64);
>> 2611:       __ add(dest, dest, 64);
> 
> This add could be elided by employing a post-increment on dest in each of the two writes above, saving on code size. Is there a reason to prefer the add?

Yes, there is. A post-increment is often an extra cycle.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25147#discussion_r2084252981

From alanb at openjdk.org  Mon May 12 09:37:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 May 2025 09:37:52 GMT
Subject: RFR: 8350765: Need to pin when accessing thread container from
 virtual thread
In-Reply-To: <j7F_yzUSSYJ3i1xGTncWVHOsIoBzl2YzQ_Y20GOrLOw=.81451ffb-a5ac-451a-a95f-ab21a307411d@github.com>
References: <G5nHVCpo-Kzs-63jq0uQXFpiXqObL8sapYh-Z8gA7rk=.4fe730d0-8571-4147-81b4-0b34f57ec54e@github.com>
 <j7F_yzUSSYJ3i1xGTncWVHOsIoBzl2YzQ_Y20GOrLOw=.81451ffb-a5ac-451a-a95f-ab21a307411d@github.com>
Message-ID: <eitQ6rKX1dxakWviW_D0xetK1fRx80pJMlXvTo2HJR4=.3254db7c-7f26-42d9-b932-560ee780a43a@github.com>

On Mon, 12 May 2025 09:01:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Data structures that are accessed by both virtual threads and their carriers require the virtual thread to pin the continuation to avoid potential deadlock. A deadlock can arise when a virtual thread is preempted, is selected and scheduled to be the next owner of the lock/resource, but can't execute because all carriers are blocking on the same lock/resource. There are a small number of places that need to pin. One that was missed is the the notification to the thread container when threads are started or terminate. This is not currently an issue at this time but it is a potential hazard for ongoing and future work that will add further scheduling points to the code.  Continuation.pin/unpin have intrinsics since JDK-8338745, and Continuation is initialized early in startup. Finally, the changes have been in the loom repo for several months with no issues.
>> 
>> Testing tier1-5, quick statup/footprint, noreg-hard
>
> src/java.base/share/classes/jdk/internal/vm/ThreadContainer.java line 97:
> 
>> 95:     public final void add(Thread thread) {
>> 96:         // Prevent a virtual thread from being preempted as this could potentially
>> 97:         // deadlock with a carrier is removing a virtual thread from the container
> 
> Is there a typo in this sentence? Should "with a carrier" have been "when a carrier ..." ? Similar comment in the remove(...) method too.

You are right, there is a pre-existing typo in that comment (the sentence was copied to here from RQ).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23810#discussion_r2084260621

From aph at openjdk.org  Mon May 12 09:42:51 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 May 2025 09:42:51 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v2]
In-Reply-To: <xZsmD7wHsVKZ64HybXNJX5JDHHDASkPcv8mtkm331zU=.345ade62-4784-45a9-a79f-25ab0bc3a66c@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
 <bnf8iIIZzedQLKLZSnqIeoVz_C-YTIEIVDKqCVFT_qY=.cdd3180a-7062-4a3d-882e-2e8de719d5ff@github.com>
 <xZsmD7wHsVKZ64HybXNJX5JDHHDASkPcv8mtkm331zU=.345ade62-4784-45a9-a79f-25ab0bc3a66c@github.com>
Message-ID: <6iRBKELx-Xnkgfm4MbONISmz9D3SjO_38PlaQXijv7w=.d6cb630c-7e83-4695-9ccc-6cfa30da5e17@github.com>

On Mon, 12 May 2025 06:52:12 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Looking at the improvements made, I suggest we also change (in `SegmentBulkOperations`):
> 
> ```
> private static final int NATIVE_THRESHOLD_FILL = powerOfPropertyOr("fill", Architecture.isAARCH64() ? 18 : 5); 
> ```
> 
> to
> 
> ```
>  private static final int NATIVE_THRESHOLD_FILL = powerOfPropertyOr("fill",  5);
> ```

Possibly so, yes, but I'm still looking at the reasons for the differences.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2871790462

From duke at openjdk.org  Mon May 12 09:45:02 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 12 May 2025 09:45:02 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
Message-ID: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>

Adding read-only support to ZipFileSystem.

The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.

This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.

By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

-------------

Commit messages:
 - Read only Zip file system support.

Changes: https://git.openjdk.org/jdk/pull/25178/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350880
  Stats: 373 lines in 5 files changed: 310 ins; 20 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

PR: https://git.openjdk.org/jdk/pull/25178

From adinn at openjdk.org  Mon May 12 09:50:52 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 12 May 2025 09:50:52 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v3]
In-Reply-To: <Gix8VStTsn9J1qfuhtqlIo0rWzhEV6r-rpi5eiUTWTc=.1ebe73c3-cac9-4de1-9def-022077bb6ba4@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
 <Gix8VStTsn9J1qfuhtqlIo0rWzhEV6r-rpi5eiUTWTc=.1ebe73c3-cac9-4de1-9def-022077bb6ba4@github.com>
Message-ID: <BDF-sv4M_Vyv0rK3MIUGXOdFwpSjxUciBNjJkSyEdSk=.5b89a5d3-592e-4398-9d56-9c01e375f28d@github.com>

On Mon, 12 May 2025 09:37:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
>> 
>> 
>> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
>> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
>> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
>> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
>> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Stub stack frame

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 2619:

> 2617: 
> 2618:     __ bind(tail);
> 2619:     // __ add(count, count, 64);

I can see why you commented this out (and prefer that to deleting it). However, a comment explaining why it is not needed might avoid maintainers being side-tracked.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25147#discussion_r2084293642

From alanb at openjdk.org  Mon May 12 10:04:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 May 2025 10:04:53 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out [v2]
In-Reply-To: <sPsiKUOg8qvw01UPmwD8ZKDc6av8j1ZCE55tbCGJgnU=.9781dc44-1114-406a-9f71-5c5d60ba5f41@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
 <sPsiKUOg8qvw01UPmwD8ZKDc6av8j1ZCE55tbCGJgnU=.9781dc44-1114-406a-9f71-5c5d60ba5f41@github.com>
Message-ID: <8R2mz4GuYNoqtgW8VOc_DGcNAxa0-1s5x_DL-w8R8TE=.e498ab31-d1bd-4736-83e3-04cf0390f518@github.com>

On Mon, 12 May 2025 09:35:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
>> 
>> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add shutdown

Jai is correct that we can't use System.exit in tests.

I added a comment to the JBS issue as it looks like the bug report is with a Zero build. Zero doesn't have VM continuations support so there will be no scheduler and no ForkJoinWorkerThreads.  This creates the race where the main thread does the quiescent.notify before the virtual thread waits.

Adding `@requires vm.continuations` to the test will skip it for this configuraiton.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25177#issuecomment-2871874731

From duke at openjdk.org  Mon May 12 10:05:59 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 12 May 2025 10:05:59 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
In-Reply-To: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
Message-ID: <Oy0qyz1t7uiPneV1X2Na2hoQEknB3zxsIGFVoKvlm1o=.4919bdb1-b994-4afe-8fa4-200118e117bd@github.com>

On Mon, 12 May 2025 09:40:56 GMT, David Beaumont <duke at openjdk.org> wrote:

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

Preloading some explanatory comment.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 83:

> 81:     private static final boolean isWindows = System.getProperty("os.name")
> 82:             .startsWith("Windows");
> 83:     private static final byte[] ROOTPATH = new byte[]{'/'};

Whitespace format changes from my editor - will revert (sorry hadn't spotted).

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 89:

> 87: 
> 88:     // Posix file permissions allow per-file access control in a posix-like fashion.
> 89:     // Note that using a "readOnly" access mode will force all files, and the

Not correct now - will fix.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 198:

> 196:         this.defaultOwner = supportPosix ? initOwner(zfpath, env) : null;
> 197:         this.defaultGroup = supportPosix ? initGroup(zfpath, env) : null;
> 198:         this.defaultPermissions = supportPosix ? Collections.unmodifiableSet(initPermissions(env)) : null;

Ensuring this is unmodifiable to avoid risk of returning a modifiable enum set.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 221:

> 219:         }
> 220:         // sm and existence check
> 221:         zfpath.getFileSystem().provider().checkAccess(zfpath, java.nio.file.AccessMode.READ);

Type name clash with existing AccessMode class. Since new enum is private, happy to rename.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 241:

> 239:         // is why they are the only non-final fields), and it requires that the
> 240:         // inode map has been initialized.
> 241:         Optional<Integer> multiReleaseVersion = determineReleaseVersion(env);

Now release version and entry lookup determination always happen on a read-only file system.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 259:

> 257: 
> 258:         // Pass "this" as a parameter after everything else is set up.
> 259:         this.rootdir = new ZipPath(this, new byte[]{'/'});

This could probably be set above release version etc. but it's a choice of either:
1. waiting until everything is set up before passing "this"
2. letting an incomplete "this" instance get passed to another class (possible escape risk?)

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 264:

> 262:     /**
> 263:      * Return the compression method to use (STORED or DEFLATED).  If the
> 264:      * property {@code compressionMethod} is set use its value to determine

Typo fix (too many m's).

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 377:

> 375:         Object o = env.get(PROPERTY_DEFAULT_PERMISSIONS);
> 376:         if (o == null) {
> 377:             return PosixFilePermissions.fromString("rwxrwxrwx");

Since DEFAULT_PERMISSIONS was mutable and only used exactly once, it seems better to just inline it where it's clear what it actually is based off. Better readability.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1458:

> 1456:      * use its value to determine the requested version. If not use the value of the "multi-release" property.
> 1457:      */
> 1458:     private Optional<Integer> determineReleaseVersion(Map<String, ?> env) throws IOException {

Refactored to return the value rather than side-effect instance fields.

test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 180:

> 178:      */
> 179:     @Test
> 180:     public void testNoSuchFileFailure() {

In theory some of these could be split more, but they are uncomplicated sanity checks.

test/jdk/jdk/nio/zipfs/Utils.java line 52:

> 50:      */
> 51:     static Path createJarFile(String name, String... entries) throws IOException {
> 52:         Path jarFile = Paths.get(name);

Previous tests always had the test file called the same thing.
Note that in jtreg tests, the file of the same name often already exists in the test directory.
I tried adding a "ensure file doesn't already exist" check and it fails lots of tests.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25178#pullrequestreview-2832583353
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084284309
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084288335
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084292488
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084296094
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084297859
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084301697
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084302415
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084306071
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084307536
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084311454
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084317768

From aph at openjdk.org  Mon May 12 10:06:51 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 May 2025 10:06:51 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v3]
In-Reply-To: <BDF-sv4M_Vyv0rK3MIUGXOdFwpSjxUciBNjJkSyEdSk=.5b89a5d3-592e-4398-9d56-9c01e375f28d@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
 <Gix8VStTsn9J1qfuhtqlIo0rWzhEV6r-rpi5eiUTWTc=.1ebe73c3-cac9-4de1-9def-022077bb6ba4@github.com>
 <BDF-sv4M_Vyv0rK3MIUGXOdFwpSjxUciBNjJkSyEdSk=.5b89a5d3-592e-4398-9d56-9c01e375f28d@github.com>
Message-ID: <-74qcaU_hYstfJykNB6hvffkOH9WQVtZOVNza8TGdMs=.10f80939-81e6-403e-930c-8e12ee6cb35d@github.com>

On Mon, 12 May 2025 09:48:03 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Stub stack frame
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 2619:
> 
>> 2617: 
>> 2618:     __ bind(tail);
>> 2619:     // __ add(count, count, 64);
> 
> I can see why you commented this out (and prefer that to deleting it). However, a comment explaining why it is not needed might avoid maintainers being side-tracked.

Eh, people enjoy a little puzzle. OK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25147#discussion_r2084323192

From duke at openjdk.org  Mon May 12 10:11:11 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 12 May 2025 10:11:11 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v2]
In-Reply-To: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
Message-ID: <1WMrvLWTwMWR2ECtF4E8hcQXIL1sxeQA4Cf1mamF6Ho=.80041034-907d-48aa-957c-108d59c3b3e8@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Remove unwanted reformatting.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/da3dfc6f..376e3acf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

PR: https://git.openjdk.org/jdk/pull/25178

From duke at openjdk.org  Mon May 12 10:16:33 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 12 May 2025 10:16:33 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
Message-ID: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Fix comment based on current behaviour.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/376e3acf..9b356a24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

PR: https://git.openjdk.org/jdk/pull/25178

From vyazici at openjdk.org  Mon May 12 10:17:46 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 10:17:46 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v5]
In-Reply-To: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
Message-ID: <rZ_wRH1QaItXeulAFBBv_xMDtbEmBd1ACr-nkFl__Xc=.9d10d155-02a0-4963-bc99-fd7f587a9008@github.com>

> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
 - Fix `HexDigits` copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24982/files
  - new: https://git.openjdk.org/jdk/pull/24982/files/121005ee..5da9465c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=03-04

  Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24982.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24982/head:pull/24982

PR: https://git.openjdk.org/jdk/pull/24982

From vyazici at openjdk.org  Mon May 12 10:17:48 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 10:17:48 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v4]
In-Reply-To: <BcqL5sH2nV9UW5oYM4gEnubzLcCkGfImWoXtkj-BP8k=.7848b5c8-427a-47dc-9d78-6e8b4c00578a@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <EBXXrcYB3HoB7nEMu434D4-pr9L7L-jySD-JX4o28so=.7a6632a7-fb92-4b07-80af-696df33a2815@github.com>
 <BcqL5sH2nV9UW5oYM4gEnubzLcCkGfImWoXtkj-BP8k=.7848b5c8-427a-47dc-9d78-6e8b4c00578a@github.com>
Message-ID: <naUUVWALj8qogfo8VnvcXPbo3ezCH0eFs8CwkptUwo4=.4926f2b8-25ad-4336-88da-2ae4e3c9beed@github.com>

On Mon, 12 May 2025 08:52:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright years
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 461:
> 
>> 459:      * make a copy.
>> 460:      */
>> 461:     Object stringConcat1(String[] constants);
> 
> Is this missing the `unchecked` prefix to the method name?

Fixed in 5da9465ce7f.

> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Hello Volkan, this should be `2024, 2025, `

Fixed in f94af95d8d0.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2084345953
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2084345343

From duke at openjdk.org  Mon May 12 10:21:50 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 12 May 2025 10:21:50 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: <CsSc99Cja-dHbnO52ZAFTF7U6JtsCnoWGEw1uRDO7HE=.6602a8a2-db94-4a46-a0c2-d20c886d920a@github.com>

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

Obvious mistakes now fixed (it's amazing what you only spot when looking at code in a review UI).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25178#issuecomment-2871935949

From pminborg at openjdk.org  Mon May 12 10:30:31 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 May 2025 10:30:31 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out [v3]
In-Reply-To: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
Message-ID: <EMJZuz9LF-PAHTpj0YH3fsrsqrWctIl_L1-oLRqTstQ=.bcc1d5d7-2762-4296-bd7a-f5217e2428d6@github.com>

> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
> 
> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rework solution

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25177/files
  - new: https://git.openjdk.org/jdk/pull/25177/files/c4f50471..bb612982

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=01-02

  Stats: 28 lines in 1 file changed: 7 ins; 14 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25177/head:pull/25177

PR: https://git.openjdk.org/jdk/pull/25177

From duke at openjdk.org  Mon May 12 10:37:04 2025
From: duke at openjdk.org (Markus KARG)
Date: Mon, 12 May 2025 10:37:04 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v12]
In-Reply-To: <xcxCND4TolntVAJ07uxXC3cXgCKscV3Dul1NFyN3BYs=.d2643648-e18f-49ec-b604-6b9c0b7f79a1@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>
 <QQz0fuco5e10bsnlLrLkV-52s9ONaPJwfqCpXfZCfK4=.75cd9f62-b37c-4c7d-8883-0b8333322131@github.com>
 <xcxCND4TolntVAJ07uxXC3cXgCKscV3Dul1NFyN3BYs=.d2643648-e18f-49ec-b604-6b9c0b7f79a1@github.com>
Message-ID: <Pwg387UD70trpGMPa3_eu0cC0ruDrMUxCnnj--zljTo=.1ddcdc99-93b9-40f4-a5cc-c5944d577641@github.com>

On Mon, 12 May 2025 01:17:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/CharSequence.java line 313:
>> 
>>> 311:      * at index {@code dstBegin} and ending at index:
>>> 312:      * <pre>{@code
>>> 313:      * dstbegin + (srcEnd-srcBegin) - 1
>> 
>> Shouldn't it be dstBegin?
>> 
>> * dstBegin + (srcEnd-srcBegin) - 1
>
> Hello Andrey, what you note is right. This and the other change you have proposed to this text seems reasonable. Do you want to create a JBS issue and raise a PR proposing this change?

We could also simply include it in the PR for https://bugs.openjdk.org/browse/JDK-8356679 to reduce organizational overhead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2084384684

From alanb at openjdk.org  Mon May 12 10:47:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 May 2025 10:47:52 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out [v3]
In-Reply-To: <EMJZuz9LF-PAHTpj0YH3fsrsqrWctIl_L1-oLRqTstQ=.bcc1d5d7-2762-4296-bd7a-f5217e2428d6@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
 <EMJZuz9LF-PAHTpj0YH3fsrsqrWctIl_L1-oLRqTstQ=.bcc1d5d7-2762-4296-bd7a-f5217e2428d6@github.com>
Message-ID: <6iLIocajLhCunmHWfesaMMAP324cbfKxN22JHT7RbLs=.f4632de1-0ece-4be0-a7a8-55361d3aaf03@github.com>

On Mon, 12 May 2025 10:30:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
>> 
>> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework solution

test/jdk/java/foreign/TestBufferStackStress2.java line 28:

> 26:  *
> 27:  * If the VM does not have continuations, then no VTs can ever be scheduled
> 28:  * @requires vm.continuations

The comment isn't quite right. Virtual threads will still be scheduled, it's just that the OS scheduler will be used as each virtual thread is backed by an OS thread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25177#discussion_r2084399659

From jpai at openjdk.org  Mon May 12 10:47:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 May 2025 10:47:51 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out [v3]
In-Reply-To: <EMJZuz9LF-PAHTpj0YH3fsrsqrWctIl_L1-oLRqTstQ=.bcc1d5d7-2762-4296-bd7a-f5217e2428d6@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
 <EMJZuz9LF-PAHTpj0YH3fsrsqrWctIl_L1-oLRqTstQ=.bcc1d5d7-2762-4296-bd7a-f5217e2428d6@github.com>
Message-ID: <lP-ozyjcqNiStLEgmLIkenng-WpAOiFMr85f6ujF6bk=.4c4ea430-6aba-4bd8-9466-74a6ba2f1433@github.com>

On Mon, 12 May 2025 10:30:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
>> 
>> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework solution

test/jdk/java/foreign/TestBufferStackStress2.java line 27:

> 25:  * @test
> 26:  *
> 27:  * If the VM does not have continuations, then no VTs can ever be scheduled

Nit - jtreg allows for a `@comment` tag in the test definition https://openjdk.org/jtreg/tag-spec.html. It would be good to prefix this line with `@comment`.

test/jdk/java/foreign/TestBufferStackStress2.java line 48:

> 46: import java.util.concurrent.Executors;
> 47: import java.util.concurrent.ForkJoinWorkerThread;
> 48: import java.util.concurrent.TimeUnit;

Likely no longer needed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25177#discussion_r2084398966
PR Review Comment: https://git.openjdk.org/jdk/pull/25177#discussion_r2084401253

From pminborg at openjdk.org  Mon May 12 10:54:05 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 May 2025 10:54:05 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out [v4]
In-Reply-To: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
Message-ID: <BPtr1FDaxXTM4xqZgTTsWu9uQiHAHN4ZJbIpqJuYqDU=.55ac7713-7a2f-437d-b323-62d9a6e71365@github.com>

> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
> 
> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.

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/25177/files
  - new: https://git.openjdk.org/jdk/pull/25177/files/bb612982..6e3f7eeb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25177/head:pull/25177

PR: https://git.openjdk.org/jdk/pull/25177

From jpai at openjdk.org  Mon May 12 11:06:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 May 2025 11:06:56 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out [v4]
In-Reply-To: <BPtr1FDaxXTM4xqZgTTsWu9uQiHAHN4ZJbIpqJuYqDU=.55ac7713-7a2f-437d-b323-62d9a6e71365@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
 <BPtr1FDaxXTM4xqZgTTsWu9uQiHAHN4ZJbIpqJuYqDU=.55ac7713-7a2f-437d-b323-62d9a6e71365@github.com>
Message-ID: <9cfLMQKs9naPI2ISlRk8CY1OMJf0_lQMJyWph4oZv_k=.4a3eb13a-e7a0-4e52-a062-74e32593096c@github.com>

On Mon, 12 May 2025 10:54:05 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
>> 
>> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

Sorry Per, I didn't notice this in the previous round - I think we should add `@bug 8356658` to the test definition, given the nature of the change to this test. Other than that, the rest of the changes in `6e3f7ee` look good to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25177#issuecomment-2872077214

From dl at openjdk.org  Mon May 12 11:11:51 2025
From: dl at openjdk.org (Doug Lea)
Date: Mon, 12 May 2025 11:11:51 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <eM3g9-uUtCPlJYoGAQ0r-mz5TSghOaxSxIsOtHY2XJY=.1bbc2579-0a82-4d0d-a65c-5dcb23b1a2d0@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <-elHwuRlU4xfy382a9QVdVT6WQMPoZyyEHANGR2TgmQ=.b4329ab0-7f2e-4c7b-9053-9917f2ea3a5f@github.com>
 <EA5TgRWJRik6NTmG9n7L12cq-viCZ9wcOMu2spIgEPk=.06fc3b76-8949-45c5-a280-08424a898e45@github.com>
 <eM3g9-uUtCPlJYoGAQ0r-mz5TSghOaxSxIsOtHY2XJY=.1bbc2579-0a82-4d0d-a65c-5dcb23b1a2d0@github.com>
Message-ID: <ldU1flEaTNPUBY-_JhsferP8eruBm3DKi79_t_NNwSc=.d6f249b7-36eb-4bcf-9ea9-2926d4cc3348@github.com>

On Fri, 9 May 2025 14:50:49 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>>> I'm a bit uneasy about incrementing the `count` in `linkFirst` but not enforcing the invariant. What's the benefit to changing linkFirst and linkLast to return void instead of keeping the original returning a boolean?
>> 
>> I based the approach on the LBQ enqueue() and dequeue() methods, which also return void and have a comment with the assertion.
>
> I understand, alas LBQ enqueue() and dequeue() don't increment a counter. It seems a bit brittle that the invariant needs to be maintained *externally* to the state modification. For the sake of maintainability I think the checks and the increment/decrement belongs in the same unit of work.

This is what I meant about reducing sequential consistency. But it does work out in terms of maintaining specs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2084442740

From jd at civilian-framework.org  Mon May 12 11:16:37 2025
From: jd at civilian-framework.org (=?UTF-8?Q?Johannes_D=C3=B6bler?=)
Date: Mon, 12 May 2025 13:16:37 +0200
Subject: potential performance improvement in sun.nio.cs.UTF_8
Message-ID: <0d6ae598-f90e-4879-8fb8-0714afb7beea@civilian-framework.org>

I have a suggestion for a performance improvement in sun.nio.cs.UTF_8, 
the workhorse for stream based UTF-8 encoding and decoding, but don't 
know if this has been discussed before.
I explain my idea for the decoding case:
Claes Redestad describes in his blog 
https://cl4es.github.io/2021/02/23/Faster-Charset-Decoding.html? how he 
used SIMD intrinsics (now JavaLangAccess.decodeASCII) to speed UTF_8 
decoding when buffers are backed by arrays:

https://github.com/openjdk/jdk/blob/0258d9998ebc523a6463818be00353c6ac8b7c9c/src/java.base/share/classes/sun/nio/cs/UTF_8.java#L231

  * first a call to JLA.decodeASCII harvests all ASCII-characters
    (=1-byte UTF-8 sequence) at the beginning of the input
  * then enters the slow loop of looking at UTF-8 byte sequences in the
    input buffer and writing to the output buffer (this is basically the
    old implementation)

If the input is all ASCII all decoding work is done in JLA.decodeASCII 
resulting in an extreme performance boost. But if the input contains a 
non-ASCII it will fall back to the slow array loop.

Now here is my idea: Why not call JLA.decodeASCI whenever an ASCII input 
is seen:

while (sp < sl) {
 ??? int b1 = sa[sp];
 ??? if (b1 >= 0) {
 ??????? // 1 byte, 7 bits: 0xxxxxxx
 ??????? if (dp >= dl)
 ??????????? return xflow(src, sp, sl, dst, dp, 1);
 ??????? // my change
*??????? int n = JLA.decodeASCII(sa, sp, da, dp, Math.min(sl - sp, dl - 
dp));
 ??????? sp += n;
 ??????? dp += n;
*??? } else if ((b1 >> 5) == -2 && (b1 & 0x1e) != 0) {

I setup a small improvised benchmark to get an idea of the impact:

Benchmark???????????????????? (data) Mode? Cnt??????? Score?? Error? Units
DecoderBenchmark.jdkDecoder? TD_8000? thrpt??? 2 2045960,037????????? ops/s
DecoderBenchmark.jdkDecoder? TD_3999? thrpt??? 2 263744,675????????? ops/s
DecoderBenchmark.jdkDecoder?? TD_999? thrpt??? 2 154232,940????????? ops/s
DecoderBenchmark.jdkDecoder?? TD_499? thrpt??? 2 142239,763????????? ops/s
DecoderBenchmark.jdkDecoder??? TD_99? thrpt??? 2 128678,229????????? ops/s
DecoderBenchmark.jdkDecoder???? TD_9? thrpt??? 2 127388,649????????? ops/s
DecoderBenchmark.jdkDecoder???? TD_4? thrpt??? 2 119834,183????????? ops/s
DecoderBenchmark.jdkDecoder???? TD_2? thrpt??? 2 111733,115????????? ops/s
DecoderBenchmark.jdkDecoder???? TD_1? thrpt??? 2 102397,455????????? ops/s
DecoderBenchmark.newDecoder? TD_8000? thrpt??? 2 2022997,518????????? ops/s
DecoderBenchmark.newDecoder? TD_3999? thrpt??? 2 2909450,005????????? ops/s
DecoderBenchmark.newDecoder?? TD_999? thrpt??? 2 2140307,712????????? ops/s
DecoderBenchmark.newDecoder?? TD_499? thrpt??? 2 1171970,809????????? ops/s
DecoderBenchmark.newDecoder??? TD_99? thrpt??? 2 686771,614????????? ops/s
DecoderBenchmark.newDecoder???? TD_9? thrpt??? 2 95181,541????????? ops/s
DecoderBenchmark.newDecoder???? TD_4? thrpt??? 2 65656,184????????? ops/s
DecoderBenchmark.newDecoder???? TD_2? thrpt??? 2 45439,240????????? ops/s
DecoderBenchmark.newDecoder???? TD_1? thrpt??? 2 36994,738????????? ops/s

(The benchmark uses only memory buffers, each test input is a UTF-8 
encoded byte buffer which produces 8000 chars and consists of various 
length of pure ascii bytes, followed by a 2-byte UTF-8 sequence 
producing a non-ASCII char:
TD_8000: 8000 ascii bytes -> 1 call to JLA.decodeASCII
TD_3999: 3999 ascii bytes + 2 non-ascii bytes, repeated 2 times -> 2 
calls to JLA.decodeASCII
...
TD_1: 1 ascii byte + 2 non-ascii bytes, repeated 4000 times -> 4000 
calls to JLA.decodeASCII

Interpretation:

  * Input all ASCII: same performance as before
  * Input contains pure ASCII sequence of considerable length
    interrupted by non ASCII bytes: now seeing huge performance
    improvements similar to the pure ASCII case.
  * Input has lot of short sequences of ASCII-bytes interrupted by non
    ASCII bytes: at some point performance drops below current
    implementation.

Thanks for reading and happy to hear your opinions,
Johannes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250512/3d26dcc4/attachment.htm>

From jpai at openjdk.org  Mon May 12 11:27:35 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 May 2025 11:27:35 GMT
Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for ZIP entry with
 empty file data [v3]
In-Reply-To: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
References: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
Message-ID: <uSCkEpxPEocKZrI3TEo9oi5R-nzbhQOxg2t-FC0XR30=.1ddf943c-49f3-466f-aff5-f33fd1678004@github.com>

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799?
> 
> `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix.
> 
> tier testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Lance's suggestion - simplify argument creation, given just a handful number of argument values

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25116/files
  - new: https://git.openjdk.org/jdk/pull/25116/files/0aea22fa..d1361736

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25116&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25116&range=01-02

  Stats: 9 lines in 1 file changed: 0 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/25116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25116/head:pull/25116

PR: https://git.openjdk.org/jdk/pull/25116

From pminborg at openjdk.org  Mon May 12 11:45:29 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 May 2025 11:45:29 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out [v5]
In-Reply-To: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
Message-ID: <Jls0SYduqmTaeBFssvUKee7JwGLMov1yMpuBgonXy18=.d32df953-4569-4f74-ae42-83fdda556f44@github.com>

> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
> 
> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add @bug definition

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25177/files
  - new: https://git.openjdk.org/jdk/pull/25177/files/6e3f7eeb..82e68046

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=03-04

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25177/head:pull/25177

PR: https://git.openjdk.org/jdk/pull/25177

From mullan at openjdk.org  Mon May 12 12:19:56 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 12:19:56 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v7]
In-Reply-To: <vNY7UaUfDQbUMHYep-RikluWmdvHfsH6s8bev3nvhMM=.f7dc3bc4-041a-4854-a9f0-20c5dc82f2da@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <vNY7UaUfDQbUMHYep-RikluWmdvHfsH6s8bev3nvhMM=.f7dc3bc4-041a-4854-a9f0-20c5dc82f2da@github.com>
Message-ID: <HSOcYbKCScm1rg-Avq2zAv1wjKrxs9QsxvAy-0Qx_3I=.8a39a3ce-5328-4528-ad76-fdc23ad659aa@github.com>

On Fri, 9 May 2025 20:05:10 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Finalize the KDF API.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   new algorithms in SunJCE

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24520#pullrequestreview-2833006989

From alanb at openjdk.org  Mon May 12 12:36:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 May 2025 12:36:54 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out [v5]
In-Reply-To: <Jls0SYduqmTaeBFssvUKee7JwGLMov1yMpuBgonXy18=.d32df953-4569-4f74-ae42-83fdda556f44@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
 <Jls0SYduqmTaeBFssvUKee7JwGLMov1yMpuBgonXy18=.d32df953-4569-4f74-ae42-83fdda556f44@github.com>
Message-ID: <Yk3jAUa9YV-_x5eraRhtXuken9ub2IGHOzcChfJvFD8=.4b1aeaaf-d7a5-40b5-a128-15e90eb118ca@github.com>

On Mon, 12 May 2025 11:45:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
>> 
>> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @bug definition

I assume the changes to switch this from wait/notify to CountDownLatch aren't needed. A carrier can't terminate with a mounted virtual thread. It's okay to change the test but I think the original issue is about Zero or running with -XX:-VMContinautions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25177#issuecomment-2872382778

From pminborg at openjdk.org  Mon May 12 12:39:54 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 May 2025 12:39:54 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out [v5]
In-Reply-To: <Yk3jAUa9YV-_x5eraRhtXuken9ub2IGHOzcChfJvFD8=.4b1aeaaf-d7a5-40b5-a128-15e90eb118ca@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
 <Jls0SYduqmTaeBFssvUKee7JwGLMov1yMpuBgonXy18=.d32df953-4569-4f74-ae42-83fdda556f44@github.com>
 <Yk3jAUa9YV-_x5eraRhtXuken9ub2IGHOzcChfJvFD8=.4b1aeaaf-d7a5-40b5-a128-15e90eb118ca@github.com>
Message-ID: <GmQqlZbDUdYx_85J6PE57bs6uLA1iCee0U5GIwvMfrM=.96633c4d-972d-44c3-af8d-655afb9d2d79@github.com>

On Mon, 12 May 2025 12:34:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume the changes to switch this from wait/notify to CountDownLatch aren't needed. A carrier can't terminate with a mounted virtual thread. It's okay to change the test but I think the original issue is about Zero or running with -XX:-VMContinautions.

Yes. This just eliminates potential races, but is not strictly needed to avoid the problem at hand.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25177#issuecomment-2872391132

From alanb at openjdk.org  Mon May 12 12:46:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 May 2025 12:46:53 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out [v5]
In-Reply-To: <GmQqlZbDUdYx_85J6PE57bs6uLA1iCee0U5GIwvMfrM=.96633c4d-972d-44c3-af8d-655afb9d2d79@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
 <Jls0SYduqmTaeBFssvUKee7JwGLMov1yMpuBgonXy18=.d32df953-4569-4f74-ae42-83fdda556f44@github.com>
 <Yk3jAUa9YV-_x5eraRhtXuken9ub2IGHOzcChfJvFD8=.4b1aeaaf-d7a5-40b5-a128-15e90eb118ca@github.com>
 <GmQqlZbDUdYx_85J6PE57bs6uLA1iCee0U5GIwvMfrM=.96633c4d-972d-44c3-af8d-655afb9d2d79@github.com>
Message-ID: <a-lSozcAkxrRFVkaXb2M0lfw7Q8XPp45MP00JfPe9-A=.e06f4d75-cc1c-46fd-9d89-ff4f592a2a6f@github.com>

On Mon, 12 May 2025 12:37:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> > I assume the changes to switch this from wait/notify to CountDownLatch aren't needed. A carrier can't terminate with a mounted virtual thread. It's okay to change the test but I think the original issue is about Zero or running with -XX:-VMContinautions.
> 
> Yes. This just eliminates potential races, but is not strictly needed to avoid the problem at hand.

Okay, but I don't think there is a race as the only scheduler point right now is the wait. Maybe the future we might have additional scheduling points that would impact this. So I think what you have is okay.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25177#issuecomment-2872422477

From jpai at openjdk.org  Mon May 12 13:44:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 May 2025 13:44:51 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out [v5]
In-Reply-To: <Jls0SYduqmTaeBFssvUKee7JwGLMov1yMpuBgonXy18=.d32df953-4569-4f74-ae42-83fdda556f44@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
 <Jls0SYduqmTaeBFssvUKee7JwGLMov1yMpuBgonXy18=.d32df953-4569-4f74-ae42-83fdda556f44@github.com>
Message-ID: <1GL6_g0L3wPIO5N7RIih6gb-2DQQ-p7NUFEECDRmRhU=.517abf75-526a-4937-ad7a-b50c31c10046@github.com>

On Mon, 12 May 2025 11:45:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
>> 
>> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @bug definition

test/jdk/java/foreign/TestBufferStackStress2.java line 30:

> 28:  * @requires vm.continuations
> 29:  *
> 30:  * @bug 8356114, 8356658

jtreg doesn't like the presence of comma in those values and the GitHub job has caught that failure in this test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25177#discussion_r2084707435

From duke at openjdk.org  Mon May 12 13:59:57 2025
From: duke at openjdk.org (kabutz)
Date: Mon, 12 May 2025 13:59:57 GMT
Subject: RFR: 8355938: Addressed rare lost unpark bug 8074773 by
 pre-loading LockSupport.class
In-Reply-To: <Jvsqkm2TUPkIuCMDITmGYPABl-U6hQNZZrDVn5n0axE=.14379a3a-9d24-4829-9c60-8a4ff882cad5@github.com>
References: <tcZkZgScJXJYpRK68NSRUTl7gcOhePhABSQz0DOzArI=.137600e0-7656-4c7a-85de-c340173467fc@github.com>
 <M7K--fqIQU_E8LdwuAE4fXNMB90mjh6jVkCCegmmz0I=.04616e1e-4f8c-4df2-a699-02520ac96c7d@github.com>
 <bLLsppdQBU2jMbn2p3NK70ShoBMbB8xxjnlDE_FYV_g=.13f7414c-a514-4076-a1df-7fe4c0d8b31b@github.com>
 <b1toctRsBgSbX9dLHZ1Q_2F0VTIqHksrZFzq_ULBwsQ=.d72d9395-7219-4590-9586-10b08ddb4173@github.com>
 <Jvsqkm2TUPkIuCMDITmGYPABl-U6hQNZZrDVn5n0axE=.14379a3a-9d24-4829-9c60-8a4ff882cad5@github.com>
Message-ID: <hqV9EH92aMMOdF9VpwcMld8zi1SlUlp5fPhse6q3XLs=.5deceba5-17e7-4220-bea4-addf9228b297@github.com>

On Fri, 9 May 2025 06:37:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> No, it will still uses synchronized if there is contention and this will not consume the park permit when it's a virtual thread. Im not sure if Heinz ran into an issue, or just remember the issue from 2015, Heinz?

I saw this comment in the JavaDoc of LockSupport: https://github.com/openjdk/jdk/blob/7ae52ce572794f9d17446c66381f703ea1bb8b7c/src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java#L135 

I then searched through the JDK classes and the only ones that used LockSupport and that did not have the static {var clazz = LockSupport.class;} were the newer classes that arrived with Java 19, plus also Exchanger (which may have been an oversight).

If this is no longer an issue, and we are 100% sure of that, then we can perhaps change the example to not have that static loader?

I have not tried to reproduce the bug, and from what Martin Buchholz described it is extremely elusive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2872683811

From alanb at openjdk.org  Mon May 12 14:01:16 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 May 2025 14:01:16 GMT
Subject: RFR: 8350765: Need to pin when accessing thread container from
 virtual thread [v2]
In-Reply-To: <G5nHVCpo-Kzs-63jq0uQXFpiXqObL8sapYh-Z8gA7rk=.4fe730d0-8571-4147-81b4-0b34f57ec54e@github.com>
References: <G5nHVCpo-Kzs-63jq0uQXFpiXqObL8sapYh-Z8gA7rk=.4fe730d0-8571-4147-81b4-0b34f57ec54e@github.com>
Message-ID: <TDzypb6IecvtvXcVDPFKqBMCbnzjgQalYHWorlmfcYk=.b30df142-447a-4361-8d11-b28b7668a826@github.com>

> Data structures that are accessed by both virtual threads and their carriers require the virtual thread to pin the continuation to avoid potential deadlock. A deadlock can arise when a virtual thread is preempted, is selected and scheduled to be the next owner of the lock/resource, but can't execute because all carriers are blocking on the same lock/resource. There are a small number of places that need to pin. One that was missed is the the notification to the thread container when threads are started or terminate. This is not currently an issue at this time but it is a potential hazard for ongoing and future work that will add further scheduling points to the code.  Continuation.pin/unpin have intrinsics since JDK-8338745, and Continuation is initialized early in startup. Finally, the changes have been in the loom repo for several months with no issues.
> 
> Testing tier1-5, quick statup/footprint, noreg-hard

Alan Bateman has updated the pull request with a new target base 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:

 - Fix/improve comment
 - Merge branch 'master' into JDK-8350765
 - Merge branch 'master' into JDK-8350765
 - No need to used qualified name
 - Merge branch 'master' into JDK-8350765
 - Update
 - Merge branch 'master' into JDK-8350765
 - Add method to ContinuationSupport
 - Missing /
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23810/files
  - new: https://git.openjdk.org/jdk/pull/23810/files/2959e070..5ff93aea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23810&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23810&range=00-01

  Stats: 2069 lines in 129 files changed: 1811 ins; 61 del; 197 mod
  Patch: https://git.openjdk.org/jdk/pull/23810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23810/head:pull/23810

PR: https://git.openjdk.org/jdk/pull/23810

From jengebr at amazon.com  Mon May 12 14:35:02 2025
From: jengebr at amazon.com (Engebretson, John)
Date: Mon, 12 May 2025 14:35:02 +0000
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: <ce3a00343e4b4395b16bd06462f83685@amazon.com>
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 <A8899F82-5CB0-44B8-AF34-6D3EF5A77CC3@oracle.com>
 <a5120cdf1d5946c9add0a1c615f6440c@amazon.com>
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 <aa7fabbb-94e3-4510-b20c-b1ed7518858a@oracle.com>
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
 <CABe8uE0W81CY7Acas0fm9ZMpMW4R+oPbhkwpdDW9TEXhSEJf-g@mail.gmail.com>
 <CANSoFxuJZZtd0PCTmCz4CJDg0kAHU0Ldj19E0VRtmOiqVHkVFQ@mail.gmail.com>
 <e132ab48b8df4246b9a8c91a8c1ec0ff@amazon.com>
 <4741eceb3beb40c2bc82613c67836d66@amazon.com>
 <CANSoFxsZ0AV96KggvSCOW4T80B55HrdBWOP67PQKpgbMpszcsw@mail.gmail.com>
 <CANSoFxu75tpy_kq9T-a3fDz5dZ-k+qhtJO8LoYxxWRO-SRXE6A@mail.gmail.com>
 <CALfq9LuBH=AcPTuJpwzPZOGQNUgty_jJfTsX2sNzgv8pdYO31w@mail.gmail.com>
 <4c4aac5737d844a4959885c65f17efee@amazon.com>
 <0249c80513c74209b34b63cce0f7a2c8@amazon.com>
 <4d239bc7086c49f6b56f9b3c741f13c6@amazon.com>
 <efd7d719-dc18-4ae4-b6bc-9e00bf9fe0e0@oracle.com>
 <ce3a00343e4b4395b16bd06462f83685@amazon.com>
Message-ID: <BN6PR1801MB2019284D0EEEECE910236369D097A@BN6PR1801MB2019.namprd18.prod.outlook.com>

  Friendly ping.  There seems to be support for this idea in some form (especially on the PR) but I haven?t received anything definitive from this email discussion.  The safest proposal on the table is from @liach: make this a JDK-internal class (for now) and modify JDK classes to rely on it.  Assuming good results, we consider making it public in future releases.
  Could I please get some form of signoff from the core team?  I?d really like to deliver something here soon, otherwise I have to move on.
  Thank you very much!  ?
    John

From: core-libs-dev <core-libs-dev-retn at openjdk.org> On Behalf Of Engebretson, John
Sent: Tuesday, April 22, 2025 7:52 AM


  Thank you Alan!  I?ll try to address each of your points, apologies if I miss anything:

        Maybe the two efforts should be separated.

  I?m good with that, and will operate that way unless someone argues otherwise.

       The factory methods can return a different implementation, in particular BAOS.unsynchronized (or whatever name it gets) does not need to collect the bytes in a contiguous array. So having a BAOS.unsynchronized may help with some of the scenarios that you are looking at.

  I think this is a clever way to go and I?m in favor? just not sold on the name.  I won?t abandon the effort if you feel otherwise.  ?  Let me know if we?re ready to proceed with this or another name.

      I think the PR proposing MemoryOutputStream is a bit premature

  This was intended solely to share code for discussion, and it?s been effective in that sense.  I agree that the PR is nowhere near merging.

      Maybe you have explored a segment like API or a cursor or consumer API to handle the bytes?

  The current version of the PR is along these lines, providing one public class whose contents are available via views (SeekableByteChannel, BAOS, ByteArrayInputStream) as well as the usual add/write/updates, long size(), and lambda-based applyToSegment(Function) and applyToIndex(Function).  The public wrapping needs to evolve but I think these provide the core of the API.
    John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250512/4555f8b5/attachment-0001.htm>

From pminborg at openjdk.org  Mon May 12 14:41:27 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 May 2025 14:41:27 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out [v6]
In-Reply-To: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
Message-ID: <PyQZw4HIrWt4SmlesS5nONMrfMm_X5WdNgYXGUwDRtw=.c7d23eb7-2a37-4bfe-834d-f606e2f7381d@github.com>

> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
> 
> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove delimiter between JBS issues

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25177/files
  - new: https://git.openjdk.org/jdk/pull/25177/files/82e68046..7bf3be63

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25177&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25177/head:pull/25177

PR: https://git.openjdk.org/jdk/pull/25177

From duke at openjdk.org  Mon May 12 14:43:09 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 12 May 2025 14:43:09 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double)
Message-ID: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>

Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.

-------------

Commit messages:
 - add bug number to test, fix typo
 - wait for real bug number to set it in header
 - Dates again
 - Fix licence format
 - Fix licence dates
 - Add licence, update test directives
 - Improve variable names
 - optimize BigDecimal.valueOf(double)

Changes: https://git.openjdk.org/jdk/pull/25173/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25173&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356709
  Stats: 188 lines in 4 files changed: 179 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/25173.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25173/head:pull/25173

PR: https://git.openjdk.org/jdk/pull/25173

From liach at openjdk.org  Mon May 12 14:43:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 May 2025 14:43:10 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double)
In-Reply-To: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
Message-ID: <GiGj_Q_kQHbDHfmlgJDxdADvEwJZ_t2lMkZAUKfu2LY=.1df90c7f-7b47-41f1-987c-5db459204d4c@github.com>

On Sun, 11 May 2025 16:22:11 GMT, Johannes Graham <duke at openjdk.org> wrote:

> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.

Thanks for this improvement! Looks great!

Sorry, didn't see your core-libs-dev mail. Created an issue for you at https://bugs.openjdk.org/browse/JDK-8356709

test/jdk/java/math/BigDecimal/ValueOfDouble.java line 14:

> 12: 
> 13: public class ValueOfDouble {
> 14:     private static final String DIGITS = "1234567899123456789"; // Enough digits to fill a long

Should we consider including 0 in this list?

This file needs a license header, and the jtreg directive should be `/*` instead of `/**` and usually placed before imports, and usually we include a `@bug` tag (once there is an issue ID) and a `@summary` tag.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25173#pullrequestreview-2831469156
PR Comment: https://git.openjdk.org/jdk/pull/25173#issuecomment-2870517444
PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2083592761

From duke at openjdk.org  Mon May 12 14:43:11 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 12 May 2025 14:43:11 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double)
In-Reply-To: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
Message-ID: <5qPlXTcqytoUz9n4SVAymurrnPSztCLg-CWWEOnsa98=.d2163abb-e96b-43c1-b821-547fe01d56dd@github.com>

On Sun, 11 May 2025 16:22:11 GMT, Johannes Graham <duke at openjdk.org> wrote:

> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.

On Aarch64 M4:

Benchmark                                Mode  Cnt   Score   Error  Units
+ BigDecimals.testValueOfWithDouble        avgt   15   9.913 ? 0.080  ns/op
- BigDecimals.testValueOfWithDoubleString  avgt   15  65.846 ? 0.801  ns/op

src/java.base/share/classes/java/math/BigDecimal.java line 1398:

> 1396:     public static BigDecimal valueOf(double val) {
> 1397:         if (!Double.isFinite(val)) {
> 1398:             throw new NumberFormatException("Infinite or NaN");

Note, this changes the exception message. The new message is consistent with `new BigDecimal(double)`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25173#issuecomment-2869969120
PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2083568201

From rgiulietti at openjdk.org  Mon May 12 14:43:11 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 12 May 2025 14:43:11 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double)
In-Reply-To: <5qPlXTcqytoUz9n4SVAymurrnPSztCLg-CWWEOnsa98=.d2163abb-e96b-43c1-b821-547fe01d56dd@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
 <5qPlXTcqytoUz9n4SVAymurrnPSztCLg-CWWEOnsa98=.d2163abb-e96b-43c1-b821-547fe01d56dd@github.com>
Message-ID: <KIm6d3Rf58ekubL-j1HQ3hejsMQm3m30bqXgz1iQXkc=.efc2db02-a6e1-456b-968a-d7e4308869dd@github.com>

On Sun, 11 May 2025 16:32:02 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.
>
> On Aarch64 M4:
> 
> Benchmark                                Mode  Cnt   Score   Error  Units
> + BigDecimals.testValueOfWithDouble        avgt   15   9.913 ? 0.080  ns/op
> - BigDecimals.testValueOfWithDoubleString  avgt   15  65.846 ? 0.801  ns/op

@j3graham This seems like a nice improvement.
I'll take a deeper look in some days from now.

@j3graham Since @liach created the JBS issue, you should change the PR title to match the title of the issue.

> src/java.base/share/classes/java/math/BigDecimal.java line 1398:
> 
>> 1396:     public static BigDecimal valueOf(double val) {
>> 1397:         if (!Double.isFinite(val)) {
>> 1398:             throw new NumberFormatException("Infinite or NaN");
> 
> Note, this changes the exception message. The new message is consistent with `new BigDecimal(double)`

Yeas, we usually only rely on the exception type, not on the specific message, which is not part of the method spec.
While it is nice to keep the message unchanged over releases, it is sometimes hard to do so consistently.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25173#issuecomment-2872414863
PR Comment: https://git.openjdk.org/jdk/pull/25173#issuecomment-2872438246
PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2084598684

From rgiulietti at openjdk.org  Mon May 12 14:43:12 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 12 May 2025 14:43:12 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double)
In-Reply-To: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
Message-ID: <Vib49PIUMUuHAfLYlVMdnk1rFo0e3HSkilxYAkd0c4c=.bcdc59aa-0941-4069-a27f-d565a093cf2a@github.com>

On Sun, 11 May 2025 16:22:11 GMT, Johannes Graham <duke at openjdk.org> wrote:

> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.

macOS 15.4.1 / M1 Pro / 32 GiB RAM

BigDecimals.testValueOfWithDouble        avgt   15    12.448 ?   0.280  ns/op
BigDecimals.testValueOfWithDoubleString  avgt   15   115.253 ?   4.349  ns/op

src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 38:

> 36:  * f and e meeting d = f 10^e.
> 37:  * It then rounds d to the appropriate number of digits, as per specification,
> 38:  * and extracts the digits of both the significand and, where required, the?

Suggestion:

 * and extracts the digits of both the significand and, where required, the

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25173#issuecomment-2872554601
PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2084591912

From duke at openjdk.org  Mon May 12 14:43:12 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 12 May 2025 14:43:12 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double)
In-Reply-To: <GiGj_Q_kQHbDHfmlgJDxdADvEwJZ_t2lMkZAUKfu2LY=.1df90c7f-7b47-41f1-987c-5db459204d4c@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
 <GiGj_Q_kQHbDHfmlgJDxdADvEwJZ_t2lMkZAUKfu2LY=.1df90c7f-7b47-41f1-987c-5db459204d4c@github.com>
Message-ID: <x9cK_MjYEcg1FLMygTXYIqqThvuhD1QJBmWW_tHZJ7w=.72a9d20e-bf79-45f3-ac9c-72705d3f2869@github.com>

On Sun, 11 May 2025 18:45:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.
>
> test/jdk/java/math/BigDecimal/ValueOfDouble.java line 14:
> 
>> 12: 
>> 13: public class ValueOfDouble {
>> 14:     private static final String DIGITS = "1234567899123456789"; // Enough digits to fill a long
> 
> Should we consider including 0 in this list?
> 
> This file needs a license header, and the jtreg directive should be `/*` instead of `/**` and usually placed before imports, and usually we include a `@bug` tag (once there is an issue ID) and a `@summary` tag.

I left out 0 specifically to ensure the all  precisions  were tried. The loop over the exponents effectively adds zeros afterwards.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2083600670

From chen.l.liang at oracle.com  Mon May 12 14:50:38 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Mon, 12 May 2025 14:50:38 +0000
Subject: potential performance improvement in sun.nio.cs.UTF_8
In-Reply-To: <0d6ae598-f90e-4879-8fb8-0714afb7beea@civilian-framework.org>
References: <0d6ae598-f90e-4879-8fb8-0714afb7beea@civilian-framework.org>
Message-ID: <SJ2PR10MB7669258D84FC03804A23A1EEA297A@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Johannes,
I think the 3rd scenario you've mentioned is likely: we have Swedish or other languages that extend the ascii encoding with diacritics, which are non-ascii bytes are frequently interrupting ascii. For non-ascii heavy languages like Chinese, sometimes the text can include spaces or ascii digits; invoking the intrinsic for that scenario sounds a bit unwise too.

Regards,
Chen Liang
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Johannes D?bler <jd at civilian-framework.org>
Sent: Monday, May 12, 2025 6:16 AM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: potential performance improvement in sun.nio.cs.UTF_8

I have a suggestion for a performance improvement in sun.nio.cs.UTF_8, the workhorse for stream based UTF-8 encoding and decoding, but don't know if this has been discussed before.
I explain my idea for the decoding case:
Claes Redestad describes in his blog https://cl4es.github.io/2021/02/23/Faster-Charset-Decoding.html  how he used SIMD intrinsics (now JavaLangAccess.decodeASCII) to speed UTF_8 decoding when buffers are backed by arrays:

https://github.com/openjdk/jdk/blob/0258d9998ebc523a6463818be00353c6ac8b7c9c/src/java.base/share/classes/sun/nio/cs/UTF_8.java#L231

  *   first a call to JLA.decodeASCII harvests all ASCII-characters (=1-byte UTF-8 sequence) at the beginning of the input
  *   then enters the slow loop of looking at UTF-8 byte sequences in the input buffer and writing to the output buffer (this is basically the old implementation)

If the input is all ASCII all decoding work is done in JLA.decodeASCII resulting in an extreme performance boost. But if the input contains a non-ASCII it will fall back to the slow array loop.

Now here is my idea: Why not call JLA.decodeASCI whenever an ASCII input is seen:

while (sp < sl) {
    int b1 = sa[sp];
    if (b1 >= 0) {
        // 1 byte, 7 bits: 0xxxxxxx
        if (dp >= dl)
            return xflow(src, sp, sl, dst, dp, 1);
        // my change
        int n = JLA.decodeASCII(sa, sp, da, dp, Math.min(sl - sp, dl - dp));
        sp += n;
        dp += n;
    } else if ((b1 >> 5) == -2 && (b1 & 0x1e) != 0) {

I setup a small improvised benchmark to get an idea of the impact:

Benchmark                     (data)   Mode  Cnt        Score   Error  Units
DecoderBenchmark.jdkDecoder  TD_8000  thrpt    2  2045960,037          ops/s
DecoderBenchmark.jdkDecoder  TD_3999  thrpt    2   263744,675          ops/s
DecoderBenchmark.jdkDecoder   TD_999  thrpt    2   154232,940          ops/s
DecoderBenchmark.jdkDecoder   TD_499  thrpt    2   142239,763          ops/s
DecoderBenchmark.jdkDecoder    TD_99  thrpt    2   128678,229          ops/s
DecoderBenchmark.jdkDecoder     TD_9  thrpt    2   127388,649          ops/s
DecoderBenchmark.jdkDecoder     TD_4  thrpt    2   119834,183          ops/s
DecoderBenchmark.jdkDecoder     TD_2  thrpt    2   111733,115          ops/s
DecoderBenchmark.jdkDecoder     TD_1  thrpt    2   102397,455          ops/s
DecoderBenchmark.newDecoder  TD_8000  thrpt    2  2022997,518          ops/s
DecoderBenchmark.newDecoder  TD_3999  thrpt    2  2909450,005          ops/s
DecoderBenchmark.newDecoder   TD_999  thrpt    2  2140307,712          ops/s
DecoderBenchmark.newDecoder   TD_499  thrpt    2  1171970,809          ops/s
DecoderBenchmark.newDecoder    TD_99  thrpt    2   686771,614          ops/s
DecoderBenchmark.newDecoder     TD_9  thrpt    2    95181,541          ops/s
DecoderBenchmark.newDecoder     TD_4  thrpt    2    65656,184          ops/s
DecoderBenchmark.newDecoder     TD_2  thrpt    2    45439,240          ops/s
DecoderBenchmark.newDecoder     TD_1  thrpt    2    36994,738          ops/s

(The benchmark uses only memory buffers, each test input is a UTF-8 encoded byte buffer which produces 8000 chars and consists of various length of pure ascii bytes, followed by a 2-byte UTF-8 sequence producing a non-ASCII char:
TD_8000: 8000 ascii bytes -> 1 call to JLA.decodeASCII
TD_3999: 3999 ascii bytes + 2 non-ascii bytes, repeated 2 times -> 2 calls to JLA.decodeASCII
...
TD_1: 1 ascii byte + 2 non-ascii bytes, repeated 4000 times -> 4000 calls to JLA.decodeASCII

Interpretation:

  *   Input all ASCII: same performance as before
  *   Input contains pure ASCII sequence of considerable length interrupted by non ASCII bytes: now seeing huge performance improvements similar to the pure ASCII case.
  *   Input has lot of short sequences of ASCII-bytes interrupted by non ASCII bytes: at some point performance drops below current implementation.

Thanks for reading and happy to hear your opinions,
Johannes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250512/f5e57b73/attachment-0001.htm>

From jpai at openjdk.org  Mon May 12 14:54:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 May 2025 14:54:52 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out [v6]
In-Reply-To: <PyQZw4HIrWt4SmlesS5nONMrfMm_X5WdNgYXGUwDRtw=.c7d23eb7-2a37-4bfe-834d-f606e2f7381d@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
 <PyQZw4HIrWt4SmlesS5nONMrfMm_X5WdNgYXGUwDRtw=.c7d23eb7-2a37-4bfe-834d-f606e2f7381d@github.com>
Message-ID: <ej0DV98xhrbSmI1u0C6a16eSj2sZebhLMtYwpPI3Khs=.75db301a-62f7-4db5-bfd3-2b8e5261ac71@github.com>

On Mon, 12 May 2025 14:41:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
>> 
>> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove delimiter between JBS issues

Looks good to me and thank you for the updates.

If this was failing every single time in tier5, then it might be useful to run these changes once in tier5 in our CI before integrating.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25177#pullrequestreview-2833538419

From liach at openjdk.org  Mon May 12 15:07:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 May 2025 15:07:00 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
 [v3]
In-Reply-To: <qh0f5DcpfqP7C07o9Ynhm-bUnzpZwhXyACKKzILTwok=.83a38bb6-55f0-41ed-941d-62ab826b483c@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
 <qh0f5DcpfqP7C07o9Ynhm-bUnzpZwhXyACKKzILTwok=.83a38bb6-55f0-41ed-941d-62ab826b483c@github.com>
Message-ID: <MqFlqvfA_71cE-tBYuLtPmH--rXy2HUzbvweeZXXxYc=.c0b496ae-d354-4ae6-83f8-e5dcf011d8b1@github.com>

On Mon, 12 May 2025 07:42:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
>> 
>> Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example.
>> 
>> Unfortunately, this PR shows the total commit history for stable values.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 386 commits:
> 
>  - Address comments
>  - Merge branch 'master' into jep502-followup
>  - Fix an issue with toString on nested constructs
>  - Merge branch 'master' into jep502-followup
>  - Merge branch 'master' into jep502-followup
>  - Update src/java.base/share/classes/java/lang/StableValue.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Simplify furhter
>  - Address comments in PR
>  - Merge master
>  - Remove unused method and add comment
>  - ... and 376 more: https://git.openjdk.org/jdk/compare/43008b42...a2826336

lgtm!

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25004#pullrequestreview-2833581429

From rriggs at openjdk.org  Mon May 12 15:24:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 May 2025 15:24:51 GMT
Subject: RFR: 8356694: Removed unused subclass audits in
 ObjectInput/OutputStream
In-Reply-To: <Bpn80v8P8rOPoX9YaJwvzFPXMsPeP58D8BPoPOVtNIg=.f585f37b-1a6d-4eeb-a235-8b21c5add944@github.com>
References: <Bpn80v8P8rOPoX9YaJwvzFPXMsPeP58D8BPoPOVtNIg=.f585f37b-1a6d-4eeb-a235-8b21c5add944@github.com>
Message-ID: <UxLPfHAyNhKZ8KKIV8rNj4LmuqAjX-CMq4FrhVZWJSM=.1f0659dd-ed01-450a-a0c7-816dae5208ed@github.com>

On Mon, 12 May 2025 02:18:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> These two subclass audits in ObjectInputStream and ObjectOutputStream were only used when security managers are present, which is no longer the case in releases 24 and newer. Thus, we can remove these two redundant `ClassValue` and the computation methods safely.
> 
> Testing: java/io/Serializable and ObjectInput, jdk tier 1-3 in progress

looks good

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25174#pullrequestreview-2833637774

From liach at openjdk.org  Mon May 12 15:24:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 May 2025 15:24:52 GMT
Subject: RFR: 8356694: Removed unused subclass audits in
 ObjectInput/OutputStream
In-Reply-To: <Bpn80v8P8rOPoX9YaJwvzFPXMsPeP58D8BPoPOVtNIg=.f585f37b-1a6d-4eeb-a235-8b21c5add944@github.com>
References: <Bpn80v8P8rOPoX9YaJwvzFPXMsPeP58D8BPoPOVtNIg=.f585f37b-1a6d-4eeb-a235-8b21c5add944@github.com>
Message-ID: <cpjNVy6Z-L7J5QsH1pa5KlZSVD1ihcTav7SNQLsueOw=.87b82da4-b9bd-4e64-abc0-094db1ec69fd@github.com>

On Mon, 12 May 2025 02:18:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> These two subclass audits in ObjectInputStream and ObjectOutputStream were only used when security managers are present, which is no longer the case in releases 24 and newer. Thus, we can remove these two redundant `ClassValue` and the computation methods safely.
> 
> Testing: java/io/Serializable and ObjectInput, jdk tier 1-3 in progress

Thanks for the reviews! JDK tier 1-3 all pass. Will wait for review from all time zones before integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25174#issuecomment-2873005732

From kvn at openjdk.org  Mon May 12 15:39:52 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 12 May 2025 15:39:52 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v4]
In-Reply-To: <CgpPXWhAoXLJ7nZ9DKtkje5ThhCJMoLUhM74sOeWwNQ=.62d971f4-8446-4ffd-8982-a430d87c0df0@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <CgpPXWhAoXLJ7nZ9DKtkje5ThhCJMoLUhM74sOeWwNQ=.62d971f4-8446-4ffd-8982-a430d87c0df0@github.com>
Message-ID: <Uta4SHWuQAdbeFP9BUyxeweOqIWB0ahn_1IJwTnaV1c=.9eda54bb-9a7a-414f-8462-822f8a332834@github.com>

On Wed, 7 May 2025 05:11:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>> 
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
>> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
>> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
>> 
>> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
>> 
>> Examples:
>> 
>> 
>> # Create an AOT cache with a single command:
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> Hello World
>> Temporary AOTConfiguration recorded: foo.aot.config
>> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
>> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
>> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
>> AOTCache creation is complete: foo.aot 10240000 bytes
>> 
>> # Create logging file for the AOT cache assembly phase
>> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> 
>> 
>> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java

@dholmes-ora pointed that we forgot update Java man page with new AOT flags.
@iklam, please do that here for this JEP and JEP 483.

-------------

Changes requested by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2833694086

From jd at civilian-framework.org  Mon May 12 15:46:24 2025
From: jd at civilian-framework.org (=?UTF-8?Q?Johannes_D=C3=B6bler?=)
Date: Mon, 12 May 2025 17:46:24 +0200
Subject: potential performance improvement in sun.nio.cs.UTF_8
In-Reply-To: <SJ2PR10MB7669258D84FC03804A23A1EEA297A@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <0d6ae598-f90e-4879-8fb8-0714afb7beea@civilian-framework.org>
 <SJ2PR10MB7669258D84FC03804A23A1EEA297A@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <ea028732-e42d-42fd-91f4-376cb89e489b@civilian-framework.org>

Hi Chen,

thanks for your feedback. Indeed it does not make sense to optimize 
UTF-8 processing for a rather vague set of beneficiaries when there are 
realistic counterexamples.
Still I don't want to give up on my idea too early :-)
I tried this modification:

  * harvest pure ASCII-bytes before the loop (as in the current decoder)
  * within the loop if a 1-byte-UTF8-sequence is recognized invoke
    JLA.decodeAscii but only limited times (e.g. 10), else just copy the
    byte to the output buffer (like in the current implementation)
  * in my benchmark timings this give the JLA.decodeAscii-boost for
    inputs which have rather long ASCII input sequences, whereas not
    degrading performance due to JLA call overhead in other scenarios

Thanks
Johannes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250512/9ad5648e/attachment.htm>

From rriggs at openjdk.org  Mon May 12 15:58:25 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 May 2025 15:58:25 GMT
Subject: RFR: 8356695: java/lang/StringBuilder/HugeCapacity.java failing with
 OOME
Message-ID: <a5Qzkrh2nxcTPCzip4yWh3upLsYyhluyqgjING8kbZg=.f71d5fb7-3508-4f81-adf3-5417ba9bd700@github.com>

The failure of the new StringBuilder HugeCapacity test testHugePlus is intermittent with some GC's.
It could be reliably reproduced with the serialGC and parallelGC's.

Raise the memory limit from 6G to 8G to accommodate the new test with all GCs.

-------------

Commit messages:
 - 8356695: java/lang/StringBuilder/HugeCapacity.java failing with OOME

Changes: https://git.openjdk.org/jdk/pull/25186/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25186&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356695
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25186/head:pull/25186

PR: https://git.openjdk.org/jdk/pull/25186

From alanb at openjdk.org  Mon May 12 16:06:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 May 2025 16:06:52 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: <a_t_Ftohx-cl2pt1hLnu5WeC6mavdNK4ZUPVsufsX1s=.0a08bd89-3320-4031-99b8-9aad787f59f0@github.com>

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

src/jdk.zipfs/share/classes/module-info.java line 160:

> 158:  *       will always be opened <em>read-write</em> (see {@code "accessMode"}
> 159:  *       below), regardless of whether the underlying ZIP already existed or
> 160:  *       not.

In the default provider, "read-only && create" ignores the create option so the open fails if the file does not exist.

For the zipfs provider then doing the same, or having this combination be an error, is okay. I think it might be a bit too surprising to have "read-only && create" create a read-write file system.

src/jdk.zipfs/share/classes/module-info.java line 281:

> 279:  *       Even if a zip file system is writable ({@code fs.isReadOnly() == false}),
> 280:  *       this says nothing about whether individual files can be created or
> 281:  *       modified, simply that it might be possible.

Initially I thought this was to allow for POSIX file permissions but not sure after reading it a second time. Can you say if this is what you mean?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2084997941
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2085009060

From abarashev at openjdk.org  Mon May 12 16:12:04 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 12 May 2025 16:12:04 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are not
 being checked with default SunX509 key manager
Message-ID: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>

When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3

X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.

-------------

Commit messages:
 - Add unit test
 - Code refactoring
 - Fix open unit tests
 - Adding a system property to skip the constraints checking. Remove SunX509c.
 - Fix constraints check
 - Revert SSLHandshake.java. Set SunX509c as default. Update copyright.
 - 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager
 - Address review comments
 - Skip explicit KeyPair initialization and let the provider default set it
 - Rework unit tests
 - ... and 3 more: https://git.openjdk.org/jdk/compare/cd8adf13...75528109

Changes: https://git.openjdk.org/jdk/pull/25016/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353113
  Stats: 1168 lines in 15 files changed: 769 ins; 333 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

PR: https://git.openjdk.org/jdk/pull/25016

From scolebourne at joda.org  Mon May 12 16:28:28 2025
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 12 May 2025 17:28:28 +0100
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: <BN6PR1801MB2019284D0EEEECE910236369D097A@BN6PR1801MB2019.namprd18.prod.outlook.com>
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 <A8899F82-5CB0-44B8-AF34-6D3EF5A77CC3@oracle.com>
 <a5120cdf1d5946c9add0a1c615f6440c@amazon.com>
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 <aa7fabbb-94e3-4510-b20c-b1ed7518858a@oracle.com>
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
 <CABe8uE0W81CY7Acas0fm9ZMpMW4R+oPbhkwpdDW9TEXhSEJf-g@mail.gmail.com>
 <CANSoFxuJZZtd0PCTmCz4CJDg0kAHU0Ldj19E0VRtmOiqVHkVFQ@mail.gmail.com>
 <e132ab48b8df4246b9a8c91a8c1ec0ff@amazon.com>
 <4741eceb3beb40c2bc82613c67836d66@amazon.com>
 <CANSoFxsZ0AV96KggvSCOW4T80B55HrdBWOP67PQKpgbMpszcsw@mail.gmail.com>
 <CANSoFxu75tpy_kq9T-a3fDz5dZ-k+qhtJO8LoYxxWRO-SRXE6A@mail.gmail.com>
 <CALfq9LuBH=AcPTuJpwzPZOGQNUgty_jJfTsX2sNzgv8pdYO31w@mail.gmail.com>
 <4c4aac5737d844a4959885c65f17efee@amazon.com>
 <0249c80513c74209b34b63cce0f7a2c8@amazon.com>
 <4d239bc7086c49f6b56f9b3c741f13c6@amazon.com>
 <efd7d719-dc18-4ae4-b6bc-9e00bf9fe0e0@oracle.com>
 <ce3a00343e4b4395b16bd06462f83685@amazon.com>
 <BN6PR1801MB2019284D0EEEECE910236369D097A@BN6PR1801MB2019.namprd18.prod.outlook.com>
Message-ID: <CACzrW9BKwyHTgLVgzLxLHevDGk4o+N-BoGKkPeE_bP6f5FuE7g@mail.gmail.com>

I agree that ByteArrayOutputStream is a problem child, and often a
performance pain. While it probably doesn't add much to the debate, I
recently wrote my own replacement class
https://github.com/JodaOrg/joda-beans/blob/main/src/main/java/org/joda/beans/ser/LinkedByteArrayOutputStream.java
thanks
Stephen


On Mon, 12 May 2025 at 15:36, Engebretson, John <jengebr at amazon.com> wrote:
>
>   Friendly ping.  There seems to be support for this idea in some form (especially on the PR) but I haven?t received anything definitive from this email discussion.  The safest proposal on the table is from @liach: make this a JDK-internal class (for now) and modify JDK classes to rely on it.  Assuming good results, we consider making it public in future releases.
>
>   Could I please get some form of signoff from the core team?  I?d really like to deliver something here soon, otherwise I have to move on.
>
>   Thank you very much!  ?
>
>     John
>
>
>
> From: core-libs-dev <core-libs-dev-retn at openjdk.org> On Behalf Of Engebretson, John
> Sent: Tuesday, April 22, 2025 7:52 AM
>
>
>
>   Thank you Alan!  I?ll try to address each of your points, apologies if I miss anything:
>
>
>
>         Maybe the two efforts should be separated.
>
>
>
>   I?m good with that, and will operate that way unless someone argues otherwise.
>
>
>
>        The factory methods can return a different implementation, in particular BAOS.unsynchronized (or whatever name it gets) does not need to collect the bytes in a contiguous array. So having a BAOS.unsynchronized may help with some of the scenarios that you are looking at.
>
>
>
>   I think this is a clever way to go and I?m in favor? just not sold on the name.  I won?t abandon the effort if you feel otherwise.  ?  Let me know if we?re ready to proceed with this or another name.
>
>
>
>       I think the PR proposing MemoryOutputStream is a bit premature
>
>
>
>   This was intended solely to share code for discussion, and it?s been effective in that sense.  I agree that the PR is nowhere near merging.
>
>
>
>       Maybe you have explored a segment like API or a cursor or consumer API to handle the bytes?
>
>
>
>   The current version of the PR is along these lines, providing one public class whose contents are available via views (SeekableByteChannel, BAOS, ByteArrayInputStream) as well as the usual add/write/updates, long size(), and lambda-based applyToSegment(Function) and applyToIndex(Function).  The public wrapping needs to evolve but I think these provide the core of the API.
>
>     John
>
>

From archie.cobbs at gmail.com  Mon May 12 17:00:39 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 12 May 2025 12:00:39 -0500
Subject: Proposal: Add new methods get(int) and set(int, E) to ArrayDeque
Message-ID: <CANSoFxscr4w-1c5dG2GPHwDTcmMmnW7KZBH-RycYkMkhh0VDdA@mail.gmail.com>

I was wondering for the n'th time why ArrayDeque does not have
get(int) and set(int,
E) methods and eventually came across JDK-8143850
<https://bugs.openjdk.org/browse/JDK-8143850> which was created 10 years
ago...

This comment exactly describes my own experience:

People write code, they need an "addFirst" or "removeLast" type method.
> Especially for "removeLast" they find that for List this is the rather
> wordy "list.remove(list.size() - 1);" with that ugly -1 constant. So they
> try an ArrayDeque, and are happy that these methods exist there and show
> the intent clearly... only to find a few minutes later that ArrayDeque
> doesn't have a get by index method, even though the structure can support
> that trivially in O(1) time -- people really expect it to be there, as an
> queue backed by an array almost implies it. I'm pretty sure that it is the
> 3rd or 4th time I tried using an ArrayDeque over the past few years only to
> realize (again) that this method is missing.


I would like to offer to do the following:

   - Change the title of this bug from "retrofit ArrayDeque to implement
   List" to "Add indexed get() and set() methods to ArrayDeque"


   - Propose a corresponding PR and CSR to add get(int) and set(int, E)
   methods to ArrayDeque

But first I want to check with this list first to see if there are any
objections?

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250512/610b4e1e/attachment-0001.htm>

From markus.karg at gmx.net  Sun May 11 06:45:39 2025
From: markus.karg at gmx.net (Markus KARG)
Date: Sun, 11 May 2025 08:45:39 +0200
Subject: RFC: 8356679: Using CharSequence::getChars internally
Message-ID: <f4cf0270-eb00-4c52-99a4-8e8057bb2bc9@gmx.net>

Dear Core Libs Team,

I am hereby requesting comments on JDK-8356679.

I would like to invest some time and set up a PR implementing Chen 
Liangs's proposal laid out in 
https://bugs.openjdk.org/browse/JDK-8356679. For your convenience, the 
text of that JBS is copied below. According to the Developer's Guide I 
do need to get broad agreement BEFORE filing a PR. Therefore, I kindly 
ask everybody to briefly show consent, so I may file a PR.

Thanks
-Markus


Copy from https://bugs.openjdk.org/browse/JDK-8356679:

Recently OpenJDK adopted the new method CharSequence::getChars(int, int, 
char[], int) for inclusion in Java 25. As a bulk reader method, it 
allows potentially improved efficiency over the previously available 
char-by-char reader method CharSequence::charAt(int).

Chen Liang suggested on March 23rd on the core-lib-dev mailing list to 
use the new method within the internal source code of OpenJDK for the 
implementation of Appendables (see 
https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). 
The idea behind this is that the implementations might be more efficient 
then.

A quick analysis of the OpenJDK source code identified (at least) the 
following classes which could potentially run more efficient when using 
CharSequence::getChars internally, thanks to bulk reading and / or 
prevention of internal copies / toString() conversions:
* java.io.Writer
* java.io.StringWriter
* java.io.PrintWriter
* java.io.BufferedWriter
* java.io.CharArrayWriter
* java.io.FileWriter
* java.io.OutputStreamWriter
* sun.nio.cs.StreamEncoder
* java.io.PrintStream
* java.nio.CharBuffer

In the sense of "eat your own dog food", it makes sense to implement 
Chen's idea in (at least) those classes. Possibly more classes could get 
identified when taking a deeper look. Besides the potential efficiency 
improvements, it would be a good show case for the usage of the new API.

The risk of this change should be low, as test coverage exists, and as 
the intended changes are solely internal to the implementation. No API 
will get changed. In some cases the JavaDocs will get slightly adapted 
where it currently exposes the actual implementation (to not lie in future).


From godmlzkf1 at naver.com  Tue May  6 07:18:35 2025
From: godmlzkf1 at naver.com (=?utf-8?B?7J6E66+87IiY?=)
Date: Tue, 06 May 2025 16:18:35 +0900
Subject: =?utf-8?B?VW5uZWNlc3NhcnkgbG9naWMgaXMgYWRkZWQgdG8gcmVtb3ZlRmlyc3QgYW5kIHJlbW92ZQ==?=
 =?utf-8?B?TGFzdCBvZiBBcnJheUxpc3Qu?=
Message-ID: <d42a6c268c35caa2c729d8a3557e5a9c@cweb014.nm>

Hi.

In removeFirst, if size is not 0, the logic is the same as the remove logic.

removeLast also has the same logic as remove when size is not exceeded.

I want to fix this.

thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250506/03f2da65/attachment.htm>

From rriggs at openjdk.org  Mon May 12 17:20:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 May 2025 17:20:03 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v5]
In-Reply-To: <rZ_wRH1QaItXeulAFBBv_xMDtbEmBd1ACr-nkFl__Xc=.9d10d155-02a0-4963-bc99-fd7f587a9008@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <rZ_wRH1QaItXeulAFBBv_xMDtbEmBd1ACr-nkFl__Xc=.9d10d155-02a0-4963-bc99-fd7f587a9008@github.com>
Message-ID: <ife8OTi1OVfy2TNVA2wnVosXdUCWRWj0XtrUtujjUek=.39fcfec9-f446-4dc0-8552-8ea8bef73eac@github.com>

On Mon, 12 May 2025 10:17:46 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
>  - Fix `HexDigits` copyright year

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 328:

> 326:      * {@linkplain java.nio.charset.Charset charset}.
> 327:      * <p>
> 328:      * <b>WARNING: This method return the {@code byte[]} backing the provided

Suggestion:

     * <b>WARNING: This method returns the {@code byte[]} backing the provided

Should this more explicitly say the returned byte array must not be modified?

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 413:

> 411: 
> 412:     /**
> 413:      * Encodes ASCII codepoints as possible from the source array into

Suggestion:

     * Encodes as many ASCII codepoints as possible from the source array into

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2085106836
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2085112564

From alanb at openjdk.org  Mon May 12 17:25:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 May 2025 17:25:55 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out [v6]
In-Reply-To: <PyQZw4HIrWt4SmlesS5nONMrfMm_X5WdNgYXGUwDRtw=.c7d23eb7-2a37-4bfe-834d-f606e2f7381d@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
 <PyQZw4HIrWt4SmlesS5nONMrfMm_X5WdNgYXGUwDRtw=.c7d23eb7-2a37-4bfe-834d-f606e2f7381d@github.com>
Message-ID: <ml5UYB-ZzBxEIl0A0da0RsLKXAG0NlEaZ7ZHR1Dnaho=.45b38735-c4e1-4a90-b8b4-6a4f4fe39ca4@github.com>

On Mon, 12 May 2025 14:41:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
>> 
>> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove delimiter between JBS issues

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25177#pullrequestreview-2833962965

From rgiulietti at openjdk.org  Mon May 12 17:40:51 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 12 May 2025 17:40:51 GMT
Subject: RFR: 8077587: BigInteger Roots [v6]
In-Reply-To: <Yx-DylQSsz_gUYUWsEq0VOZyZjkXc-3gxPe2l2HYpT8=.a9c3746b-6383-4450-83bf-9b4b5590178d@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <Yx-DylQSsz_gUYUWsEq0VOZyZjkXc-3gxPe2l2HYpT8=.a9c3746b-6383-4450-83bf-9b4b5590178d@github.com>
Message-ID: <PQSVjWwisaYeX5N1GVyas9W91tGjlgOP7y34TRkpae8=.771ec10c-9571-4a8f-b5bd-fcf0ff6fe77f@github.com>

On Sat, 10 May 2025 11:57:32 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'nth-root-branch' of https://github.com/fabioromano1/jdk into nth-root-branch
>  - Restore nthRoot() public methods in BigInteger.java

@fabioromano1 Is [this proof](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf) still relevant?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2873412219

From bchristi at openjdk.org  Mon May 12 17:50:51 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 12 May 2025 17:50:51 GMT
Subject: RFR: 8356107: [java.lang] Use @requires tag instead of exiting
 based on os.name or separatorChar property
In-Reply-To: <t8wn9Ui1LQODIKte2N9MoY93vzHKMgmNFeJTIW_0WQ8=.400efa3f-7560-4316-974b-d4f950062361@github.com>
References: <tZiBKIvIBGsfgLaEtvf87nGGC4cdBrLkPYMNRlIHg1Q=.bcc1ff0b-ca04-4adc-9f61-9641c33f1807@github.com>
 <t8wn9Ui1LQODIKte2N9MoY93vzHKMgmNFeJTIW_0WQ8=.400efa3f-7560-4316-974b-d4f950062361@github.com>
Message-ID: <y4Q0Y90uiLFuGCKsZUcR5ICVTZw9sQkmlGg5sgLVYAc=.0980b398-a26a-47e9-b09d-f8f6a656337e@github.com>

On Sat, 10 May 2025 00:25:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I think `test/jdk/java/lang/System/NonAnsiFileEncodingTest.java` can be removed, as it does not provide any value today

OK, great! Thanks, Naoto.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25163#issuecomment-2873452048

From bchristi at openjdk.org  Mon May 12 17:55:33 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 12 May 2025 17:55:33 GMT
Subject: RFR: 8356107: [java.lang] Use @requires tag instead of exiting
 based on os.name or separatorChar property [v2]
In-Reply-To: <tZiBKIvIBGsfgLaEtvf87nGGC4cdBrLkPYMNRlIHg1Q=.bcc1ff0b-ca04-4adc-9f61-9641c33f1807@github.com>
References: <tZiBKIvIBGsfgLaEtvf87nGGC4cdBrLkPYMNRlIHg1Q=.bcc1ff0b-ca04-4adc-9f61-9641c33f1807@github.com>
Message-ID: <4-ABB3u3CsP-o3Y-daEGVJuOi_MkYdqzz5I9oJAL_T0=.aec2d7cf-850b-48b2-9602-96fa5f6e3cd6@github.com>

> For `java.lang` tests, use the `@requires` facility in place of checking the `os.name` system property or `File.separatorChar`.
> 
> Automated test results are omitted as expected.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  NonAnsiFileEncodingTest.java is no longer applicable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25163/files
  - new: https://git.openjdk.org/jdk/pull/25163/files/c5a255a8..737b222d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25163&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25163&range=00-01

  Stats: 64 lines in 1 file changed: 0 ins; 64 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25163.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25163/head:pull/25163

PR: https://git.openjdk.org/jdk/pull/25163

From bchristi at openjdk.org  Mon May 12 17:58:29 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 12 May 2025 17:58:29 GMT
Subject: RFR: 8356107: [java.lang] Use @requires tag instead of exiting
 based on os.name or separatorChar property [v3]
In-Reply-To: <tZiBKIvIBGsfgLaEtvf87nGGC4cdBrLkPYMNRlIHg1Q=.bcc1ff0b-ca04-4adc-9f61-9641c33f1807@github.com>
References: <tZiBKIvIBGsfgLaEtvf87nGGC4cdBrLkPYMNRlIHg1Q=.bcc1ff0b-ca04-4adc-9f61-9641c33f1807@github.com>
Message-ID: <spfrwUbddiCRErnmad2oty-PKR-MVcADR0Yj7Y454T8=.80e1ff19-5137-48bb-81f6-7a4c8ff67681@github.com>

> For `java.lang` tests, use the `@requires` facility in place of checking the `os.name` system property or `File.separatorChar`.
> 
> Automated test results are omitted as expected.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  apostrophize

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25163/files
  - new: https://git.openjdk.org/jdk/pull/25163/files/737b222d..5b05ee36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25163&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25163&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25163.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25163/head:pull/25163

PR: https://git.openjdk.org/jdk/pull/25163

From roger.riggs at oracle.com  Mon May 12 18:18:20 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 12 May 2025 14:18:20 -0400
Subject: RFC: 8356679: Using CharSequence::getChars internally
In-Reply-To: <f4cf0270-eb00-4c52-99a4-8e8057bb2bc9@gmx.net>
References: <f4cf0270-eb00-4c52-99a4-8e8057bb2bc9@gmx.net>
Message-ID: <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com>

Hi Markus,

On the surface, its looks constructive.
I suspect that many of these cases will turn into discussions about the 
right/best/better way to buffer the characters.
The getChars method only helps when extracting to a char array, many of 
the current implementations create strings as the intermediary. The 
advantage of the 1 character at a time technique is not needing a 
(separated allocated) buffer.
Consider taking a few at a time before launching into the whole set.

$.02, Roger

On 5/11/25 2:45 AM, Markus KARG wrote:
> Dear Core Libs Team,
>
> I am hereby requesting comments on JDK-8356679.
>
> I would like to invest some time and set up a PR implementing Chen 
> Liangs's proposal laid out in 
> https://bugs.openjdk.org/browse/JDK-8356679. For your convenience, the 
> text of that JBS is copied below. According to the Developer's Guide I 
> do need to get broad agreement BEFORE filing a PR. Therefore, I kindly 
> ask everybody to briefly show consent, so I may file a PR.
>
> Thanks
> -Markus
>
>
> Copy from https://bugs.openjdk.org/browse/JDK-8356679:
>
> Recently OpenJDK adopted the new method CharSequence::getChars(int, 
> int, char[], int) for inclusion in Java 25. As a bulk reader method, 
> it allows potentially improved efficiency over the previously 
> available char-by-char reader method CharSequence::charAt(int).
>
> Chen Liang suggested on March 23rd on the core-lib-dev mailing list to 
> use the new method within the internal source code of OpenJDK for the 
> implementation of Appendables (see 
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). 
> The idea behind this is that the implementations might be more 
> efficient then.
>
> A quick analysis of the OpenJDK source code identified (at least) the 
> following classes which could potentially run more efficient when 
> using CharSequence::getChars internally, thanks to bulk reading and / 
> or prevention of internal copies / toString() conversions:
> * java.io.Writer
> * java.io.StringWriter
> * java.io.PrintWriter
> * java.io.BufferedWriter
> * java.io.CharArrayWriter
> * java.io.FileWriter
> * java.io.OutputStreamWriter
> * sun.nio.cs.StreamEncoder
> * java.io.PrintStream
> * java.nio.CharBuffer
>
> In the sense of "eat your own dog food", it makes sense to implement 
> Chen's idea in (at least) those classes. Possibly more classes could 
> get identified when taking a deeper look. Besides the potential 
> efficiency improvements, it would be a good show case for the usage of 
> the new API.
>
> The risk of this change should be low, as test coverage exists, and as 
> the intended changes are solely internal to the implementation. No API 
> will get changed. In some cases the JavaDocs will get slightly adapted 
> where it currently exposes the actual implementation (to not lie in 
> future).
>


From rriggs at openjdk.org  Mon May 12 18:35:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 May 2025 18:35:53 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v4]
In-Reply-To: <KOHIfa0AS_WepowGrmopq0fgWM-P7aI22AXONSWH1Xc=.867948c7-6ecc-49bb-b0f1-6301d6deca44@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <V8ZrRweDmVS9HD5kY8TM6xIVWBfiZy8StMHs6LPO78o=.59017549-3ec8-4627-b206-a9e897045081@github.com>
 <Wxyg9SVuqu7LVRudUKXl7K7kSw8_iA9ArJ18oBHb-rY=.02811a97-01ad-4185-9e61-474090ed2f89@github.com>
 <KOHIfa0AS_WepowGrmopq0fgWM-P7aI22AXONSWH1Xc=.867948c7-6ecc-49bb-b0f1-6301d6deca44@github.com>
Message-ID: <UHjRw4soBJIZkvrX7i8qOyJ7h9LHDjD15k6G34r1mik=.a2e07ba1-e251-462a-a8f8-bd9c805a51cf@github.com>

On Fri, 2 May 2025 18:11:54 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringUTF16.java line 1322:
>> 
>>> 1320:                 val,
>>> 1321:                 Unsafe.ARRAY_BYTE_BASE_OFFSET + ((long) index << 1),
>>> 1322:                 ((long) (end - off)) << 1);
>> 
>> This use of Unsafe is not warranted. If it can't be done with arrayCopy, leave the original code as is.
>
>> This use of Unsafe is not warranted. If it can't be done with arrayCopy, leave the original code as is.
> 
> The core library also uses Unsafe.copyMemory in many places. Can it be used in this scenario? Or can we find other ways to copy char[] to byte[]?

You may have overlooked the behavior of putChar to swap the order of the bytes depending on whether its big or little endian.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2085236701

From naoto at openjdk.org  Mon May 12 18:40:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 May 2025 18:40:50 GMT
Subject: RFR: 8356107: [java.lang] Use @requires tag instead of exiting
 based on os.name or separatorChar property [v3]
In-Reply-To: <spfrwUbddiCRErnmad2oty-PKR-MVcADR0Yj7Y454T8=.80e1ff19-5137-48bb-81f6-7a4c8ff67681@github.com>
References: <tZiBKIvIBGsfgLaEtvf87nGGC4cdBrLkPYMNRlIHg1Q=.bcc1ff0b-ca04-4adc-9f61-9641c33f1807@github.com>
 <spfrwUbddiCRErnmad2oty-PKR-MVcADR0Yj7Y454T8=.80e1ff19-5137-48bb-81f6-7a4c8ff67681@github.com>
Message-ID: <ymRslT5v0hcks1iSMaUAtb2ZsAsGcibshK8YGHWsulA=.d1320b0d-10af-40f5-b4d5-1ae8b6edb296@github.com>

On Mon, 12 May 2025 17:58:29 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> For `java.lang` tests, use the `@requires` facility in place of checking the `os.name` system property or `File.separatorChar`.
>> 
>> Automated test results are omitted as expected.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   apostrophize

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25163#pullrequestreview-2834153460

From abarashev at openjdk.org  Mon May 12 18:45:10 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 12 May 2025 18:45:10 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v2]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <1Gpnwbv3_IexuWpsDF0ebvnlgcVpRzY_t3NTR639sMA=.c69a02d9-8139-4068-bfba-23ba8424b5f7@github.com>

> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
> 
> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Add PeerConstraintsCheck unit test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/75528109..88cd4016

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=00-01

  Stats: 284 lines in 3 files changed: 277 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

PR: https://git.openjdk.org/jdk/pull/25016

From vyazici at openjdk.org  Mon May 12 19:13:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 19:13:29 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v6]
In-Reply-To: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
Message-ID: <Cw9fgPxG3Zeawp37S6AH_CVKGoFDoeWkbMoqJVHnm34=.2082087e-3587-454e-9d14-7f640e4e5c12@github.com>

> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24982/files
  - new: https://git.openjdk.org/jdk/pull/24982/files/5da9465c..0ac2101a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24982.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24982/head:pull/24982

PR: https://git.openjdk.org/jdk/pull/24982

From duke at openjdk.org  Mon May 12 19:25:53 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 12 May 2025 19:25:53 GMT
Subject: RFR: 8077587: BigInteger Roots [v6]
In-Reply-To: <PQSVjWwisaYeX5N1GVyas9W91tGjlgOP7y34TRkpae8=.771ec10c-9571-4a8f-b5bd-fcf0ff6fe77f@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <Yx-DylQSsz_gUYUWsEq0VOZyZjkXc-3gxPe2l2HYpT8=.a9c3746b-6383-4450-83bf-9b4b5590178d@github.com>
 <PQSVjWwisaYeX5N1GVyas9W91tGjlgOP7y34TRkpae8=.771ec10c-9571-4a8f-b5bd-fcf0ff6fe77f@github.com>
Message-ID: <q09MluNDbj5IA54dR3dZB-BhWUGHK4WYcGXUr7GKcdY=.317f0eb7-df16-4488-8f82-d6b3655ebd96@github.com>

On Mon, 12 May 2025 17:37:54 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'nth-root-branch' of https://github.com/fabioromano1/jdk into nth-root-branch
>>  - Restore nthRoot() public methods in BigInteger.java
>
> @fabioromano1 Is [this proof](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf) still relevant?

@rgiulietti No, the proof of the recurrence used is the one by Zimmermann linked in the code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2873741605

From liach at openjdk.org  Mon May 12 19:29:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 May 2025 19:29:53 GMT
Subject: RFR: 8356695: java/lang/StringBuilder/HugeCapacity.java failing
 with OOME
In-Reply-To: <a5Qzkrh2nxcTPCzip4yWh3upLsYyhluyqgjING8kbZg=.f71d5fb7-3508-4f81-adf3-5417ba9bd700@github.com>
References: <a5Qzkrh2nxcTPCzip4yWh3upLsYyhluyqgjING8kbZg=.f71d5fb7-3508-4f81-adf3-5417ba9bd700@github.com>
Message-ID: <NvTJmjKOFtA3b6ejUZjiQrYxIgtfUCCukNluxB0LUgw=.0d626b03-cd5a-452a-890b-0a4d175d1c97@github.com>

On Mon, 12 May 2025 15:53:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The failure of the new StringBuilder HugeCapacity test testHugePlus is intermittent with some GC's.
> It could be reliably reproduced with the serialGC and parallelGC's.
> 
> Raise the memory limit from 6G to 8G to accommodate the new test with all GCs.

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25186#pullrequestreview-2834264417

From vyazici at openjdk.org  Mon May 12 19:42:15 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 19:42:15 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v7]
In-Reply-To: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
Message-ID: <RAcEfEBZgn1o13wOeDQi9KG7s8koI8uizmFVGhqw0sk=.f65f7f8a-b8cf-4bbe-9dbd-8838e92453c6@github.com>

> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.

Volkan Yazici has updated the pull request with a new target base 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:

 - Merge remote-tracking branch 'upstream/master' into jla
 - Improve `uncheckedGetBytesNoRepl` docs
 - Apply suggestions from code review
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
 - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
 - Fix `HexDigits` copyright year
 - Fix copyright years
 - Prefix touched methods with `unchecked`
 - Fix typo in pre-existing JavaDoc
 - Improve `JavaLangAccess` documentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24982/files
  - new: https://git.openjdk.org/jdk/pull/24982/files/0ac2101a..0e06ce1d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=05-06

  Stats: 38505 lines in 1296 files changed: 26044 ins; 7087 del; 5374 mod
  Patch: https://git.openjdk.org/jdk/pull/24982.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24982/head:pull/24982

PR: https://git.openjdk.org/jdk/pull/24982

From vyazici at openjdk.org  Mon May 12 19:42:15 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 19:42:15 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v5]
In-Reply-To: <ife8OTi1OVfy2TNVA2wnVosXdUCWRWj0XtrUtujjUek=.39fcfec9-f446-4dc0-8552-8ea8bef73eac@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <rZ_wRH1QaItXeulAFBBv_xMDtbEmBd1ACr-nkFl__Xc=.9d10d155-02a0-4963-bc99-fd7f587a9008@github.com>
 <ife8OTi1OVfy2TNVA2wnVosXdUCWRWj0XtrUtujjUek=.39fcfec9-f446-4dc0-8552-8ea8bef73eac@github.com>
Message-ID: <HnAv4zoCVmVLscWJBnWo_i4JU4KEY6sfGP-2Id0raJ8=.cca7421c-e447-4b1a-bded-774a497dca03@github.com>

On Mon, 12 May 2025 17:07:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
>>  - Fix `HexDigits` copyright year
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 328:
> 
>> 326:      * {@linkplain java.nio.charset.Charset charset}.
>> 327:      * <p>
>> 328:      * <b>WARNING: This method return the {@code byte[]} backing the provided
> 
> Suggestion:
> 
>      * <b>WARNING: This method returns the {@code byte[]} backing the provided
> 
> Should this more explicitly say the returned byte array must not be modified?

Improved as suggested in cd156fbab46.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2085329577

From lancea at openjdk.org  Mon May 12 19:49:52 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 12 May 2025 19:49:52 GMT
Subject: RFR: 8356695: java/lang/StringBuilder/HugeCapacity.java failing
 with OOME
In-Reply-To: <a5Qzkrh2nxcTPCzip4yWh3upLsYyhluyqgjING8kbZg=.f71d5fb7-3508-4f81-adf3-5417ba9bd700@github.com>
References: <a5Qzkrh2nxcTPCzip4yWh3upLsYyhluyqgjING8kbZg=.f71d5fb7-3508-4f81-adf3-5417ba9bd700@github.com>
Message-ID: <NWg3_BNTXukIKRMYsJf5vLP24-EljSTnPCOo-4-PgCo=.61ecaefd-0183-4553-98e2-8a9ed77b904c@github.com>

On Mon, 12 May 2025 15:53:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The failure of the new StringBuilder HugeCapacity test testHugePlus is intermittent with some GC's.
> It could be reliably reproduced with the serialGC and parallelGC's.
> 
> Raise the memory limit from 6G to 8G to accommodate the new test with all GCs.

Looks good to me

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25186#pullrequestreview-2834305295

From rgiulietti at openjdk.org  Mon May 12 19:58:51 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 12 May 2025 19:58:51 GMT
Subject: RFR: 8356695: java/lang/StringBuilder/HugeCapacity.java failing
 with OOME
In-Reply-To: <a5Qzkrh2nxcTPCzip4yWh3upLsYyhluyqgjING8kbZg=.f71d5fb7-3508-4f81-adf3-5417ba9bd700@github.com>
References: <a5Qzkrh2nxcTPCzip4yWh3upLsYyhluyqgjING8kbZg=.f71d5fb7-3508-4f81-adf3-5417ba9bd700@github.com>
Message-ID: <INWQyGecCJdKEQO5vVUURYIHu3VU0otw0scgPKk1-70=.4b0971da-4c18-4968-9590-21b117cada69@github.com>

On Mon, 12 May 2025 15:53:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The failure of the new StringBuilder HugeCapacity test testHugePlus is intermittent with some GC's.
> It could be reliably reproduced with the serialGC and parallelGC's.
> 
> Raise the memory limit from 6G to 8G to accommodate the new test with all GCs.

Marked as reviewed by rgiulietti (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25186#pullrequestreview-2834324813

From rriggs at openjdk.org  Mon May 12 20:04:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 May 2025 20:04:56 GMT
Subject: Integrated: 8356695: java/lang/StringBuilder/HugeCapacity.java failing
 with OOME
In-Reply-To: <a5Qzkrh2nxcTPCzip4yWh3upLsYyhluyqgjING8kbZg=.f71d5fb7-3508-4f81-adf3-5417ba9bd700@github.com>
References: <a5Qzkrh2nxcTPCzip4yWh3upLsYyhluyqgjING8kbZg=.f71d5fb7-3508-4f81-adf3-5417ba9bd700@github.com>
Message-ID: <7fKJIeDWzh9ebXj2hju1EzYfcDyRVBmfJzn_bgHNqVg=.9092cad6-b6ae-444a-822b-b4712a2c19e9@github.com>

On Mon, 12 May 2025 15:53:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The failure of the new StringBuilder HugeCapacity test testHugePlus is intermittent with some GC's.
> It could be reliably reproduced with the serialGC and parallelGC's.
> 
> Raise the memory limit from 6G to 8G to accommodate the new test with all GCs.

This pull request has now been integrated.

Changeset: 0f5c6081
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0f5c608143413bc0d40fca31e097c7b40c7a6618
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8356695: java/lang/StringBuilder/HugeCapacity.java failing with OOME

Reviewed-by: liach, lancea, rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/25186

From abarashev at openjdk.org  Mon May 12 20:05:18 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 12 May 2025 20:05:18 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v3]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>

> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
> 
> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Make sure the exception happens during KeyManager's algorithm check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/88cd4016..5c137c14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=01-02

  Stats: 17 lines in 1 file changed: 2 ins; 5 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

PR: https://git.openjdk.org/jdk/pull/25016

From duke at openjdk.org  Mon May 12 20:11:18 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 12 May 2025 20:11:18 GMT
Subject: RFR: 8077587: BigInteger Roots [v7]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <2CM-BPYVSY7yVGxTMnU-R1-Vd0OD5g9kMy3zw4BjW1M=.7532a6d6-91f5-4cda-ad23-0db6d00965ec@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Factor out newton's recurrence in a separate method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/823d2f63..30a1b828

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=05-06

  Stats: 29 lines in 1 file changed: 15 ins; 12 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From duke at openjdk.org  Mon May 12 20:15:52 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 12 May 2025 20:15:52 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <a_t_Ftohx-cl2pt1hLnu5WeC6mavdNK4ZUPVsufsX1s=.0a08bd89-3320-4031-99b8-9aad787f59f0@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <a_t_Ftohx-cl2pt1hLnu5WeC6mavdNK4ZUPVsufsX1s=.0a08bd89-3320-4031-99b8-9aad787f59f0@github.com>
Message-ID: <t3kMzppof8NK7ouOx3QdU32-Jf2v0IWXs70l1k58OVw=.be19d6b2-67a8-4495-bc39-3458f9afec82@github.com>

On Mon, 12 May 2025 16:04:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> src/jdk.zipfs/share/classes/module-info.java line 281:
> 
>> 279:  *       Even if a zip file system is writable ({@code fs.isReadOnly() == false}),
>> 280:  *       this says nothing about whether individual files can be created or
>> 281:  *       modified, simply that it might be possible.
> 
> Initially I thought this was to allow for POSIX file permissions but not sure after reading it a second time. Can you say if this is what you mean?

Hmm, you're right, it's not totally clear. It's trying to draw the same sort of distinction that you have with mounted file systems, in which the mode that something is mounted in doesn't override any underlying read-only state.

For example you can still open a ZipFileSystem for a ZIP file which is on a remote drive, where the permissions show the underlying file as "writable", but an attempt to modify the contents would still fail.

The POSIX stuff is mentioned at the end, and while it's related, it's not quite the same point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2085372871

From duke at openjdk.org  Mon May 12 20:19:09 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 12 May 2025 20:19:09 GMT
Subject: RFR: 8077587: BigInteger Roots [v8]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <SHjR7FkPgKzOFcqZNGLrKHzsPfWdteBwY_Cweuxqnl0=.949c2726-e740-46be-852b-6ed39dd314f1@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  correct typos

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/30a1b828..3e3d45c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From duke at openjdk.org  Mon May 12 20:21:51 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 12 May 2025 20:21:51 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <a_t_Ftohx-cl2pt1hLnu5WeC6mavdNK4ZUPVsufsX1s=.0a08bd89-3320-4031-99b8-9aad787f59f0@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <a_t_Ftohx-cl2pt1hLnu5WeC6mavdNK4ZUPVsufsX1s=.0a08bd89-3320-4031-99b8-9aad787f59f0@github.com>
Message-ID: <jpu6AaHhiBzIuwqmpMUdjutvU63uE-rKM2EKcWfXhuQ=.859ef831-0603-47ff-8373-66ae4fc0f6fe@github.com>

On Mon, 12 May 2025 15:57:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> src/jdk.zipfs/share/classes/module-info.java line 160:
> 
>> 158:  *       will always be opened <em>read-write</em> (see {@code "accessMode"}
>> 159:  *       below), regardless of whether the underlying ZIP already existed or
>> 160:  *       not.
> 
> In the default provider, "read-only && create" ignores the create option so the open fails if the file does not exist.
> 
> For the zipfs provider then doing the same, or having this combination be an error, is okay. I think it might be a bit too surprising to have "read-only && create" create a read-write file system.

Is this comment just agreeing with the proposed behaviour stated here?

At the moment the code prohibits "read-only && create". It's an illegal argument exception (see tests).

The only allowed access mode options with "create" are "readWrite" or <no-option>, and in both cases you get back a ZipFileSystem for which "isReadOnly()" is false. We'd already agreed that any explicit access mode needs to always be honoured.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2085381219

From liach at openjdk.org  Mon May 12 20:25:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 May 2025 20:25:57 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v7]
In-Reply-To: <RAcEfEBZgn1o13wOeDQi9KG7s8koI8uizmFVGhqw0sk=.f65f7f8a-b8cf-4bbe-9dbd-8838e92453c6@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <RAcEfEBZgn1o13wOeDQi9KG7s8koI8uizmFVGhqw0sk=.f65f7f8a-b8cf-4bbe-9dbd-8838e92453c6@github.com>
Message-ID: <iUp97OSdzUCxuR3hbeEFZzf6lEfGQ7Ot5JNV4cZJeAQ=.bfe4586d-a1af-4066-aa2c-71805d4e11c3@github.com>

On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request with a new target base 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:
> 
>  - Merge remote-tracking branch 'upstream/master' into jla
>  - Improve `uncheckedGetBytesNoRepl` docs
>  - Apply suggestions from code review
>    
>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>  - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
>  - Fix `HexDigits` copyright year
>  - Fix copyright years
>  - Prefix touched methods with `unchecked`
>  - Fix typo in pre-existing JavaDoc
>  - Improve `JavaLangAccess` documentation

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2834380249

From jlu at openjdk.org  Mon May 12 20:37:58 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 May 2025 20:37:58 GMT
Subject: RFR: 8348351: Improve lazy initialization of the available
 currencies set [v2]
In-Reply-To: <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com>
References: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
 <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com>
Message-ID: <ZI_b_n-gtWiTKOCCDysrQjPzX_7l_JqnAmiaww7mwiM=.0ee52d8e-b41d-4a2b-8ad5-237422cf313f@github.com>

On Thu, 8 May 2025 23:30:06 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which stems from discussion in the PR of JDK-8347949.
>> 
>> The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier.
>> 
>> (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen's review - method name clarification

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25134#issuecomment-2873923357

From jlu at openjdk.org  Mon May 12 20:37:59 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 May 2025 20:37:59 GMT
Subject: Integrated: 8348351: Improve lazy initialization of the available
 currencies set
In-Reply-To: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
References: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
Message-ID: <nOGOiSB3McS9N81nNkqswlEnWXmGt6WS-Y8Il2rXjhk=.3902981e-ea2d-4e66-9400-70cf172af221@github.com>

On Thu, 8 May 2025 22:55:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which stems from discussion in the PR of JDK-8347949.
> 
> The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier.
> 
> (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.)

This pull request has now been integrated.

Changeset: b6b5ac1e
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6b5ac1ef9042ed62a8358aa6943b8dc87dcf0ab
Stats:     46 lines in 1 file changed: 3 ins; 2 del; 41 mod

8348351: Improve lazy initialization of the available currencies set

Reviewed-by: liach, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/25134

From duke at openjdk.org  Mon May 12 21:00:01 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Mon, 12 May 2025 21:00:01 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
 [v3]
In-Reply-To: <qh0f5DcpfqP7C07o9Ynhm-bUnzpZwhXyACKKzILTwok=.83a38bb6-55f0-41ed-941d-62ab826b483c@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
 <qh0f5DcpfqP7C07o9Ynhm-bUnzpZwhXyACKKzILTwok=.83a38bb6-55f0-41ed-941d-62ab826b483c@github.com>
Message-ID: <jmXHrPICRVNH3BzfyxM7d7RfihYFrZaSk_kupJ2TWoc=.60dc1e33-b96c-4af7-a9c9-243537678894@github.com>

On Mon, 12 May 2025 07:42:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
>> 
>> Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example.
>> 
>> Unfortunately, this PR shows the total commit history for stable values.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 386 commits:
> 
>  - Address comments
>  - Merge branch 'master' into jep502-followup
>  - Fix an issue with toString on nested constructs
>  - Merge branch 'master' into jep502-followup
>  - Merge branch 'master' into jep502-followup
>  - Update src/java.base/share/classes/java/lang/StableValue.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Simplify furhter
>  - Address comments in PR
>  - Merge master
>  - Remove unused method and add comment
>  - ... and 376 more: https://git.openjdk.org/jdk/compare/43008b42...a2826336

src/java.base/share/classes/java/lang/StableValue.java line 730:

> 728:      * <p>
> 729:      * Any {@link Map#values()} or {@link Map#entrySet()} views of the returned map are
> 730:      * also stable.

You resolved https://github.com/openjdk/jdk/pull/23972#discussion_r2058903119, so the following lines can also get rid of "direct":
https://github.com/openjdk/jdk/blob/fbc4691bfa11f31601fd89d05da63e689343e214/src/java.base/share/classes/java/lang/StableValue.java#L687-L688

src/java.base/share/classes/java/util/ImmutableCollections.java line 518:

> 516: 
> 517:         private boolean allowNulls() {
> 518:             return root instanceof ListN<?> listN && listN.allowNulls;

I think this should stay here (or some other change is needed). `StableSubList` doesn't override `indexOf` and `lastIndexOf`, so they will throw when given `null`, even though the list could contain `null`.

src/java.base/share/classes/java/util/ImmutableCollections.java line 884:

> 882:         @Override
> 883:         public String toString() {
> 884:             return StableUtil.renderElements(this, "StableList", delegates);

Suggestion:

            return StableUtil.renderElements(this, "StableCollection", delegates);

I think `StableList`, `StableSubList`, `StableReverseOrderListView`, `StableMapEntrySet` and `StableMapValues` should all use `"StableCollection"` to be consistent with `AbstractCollection`'s use of `"Collection"`. `StableMap` should use `"StableMap"` to be consistent with `AbstractMap`'s use of `"Map"`.

src/java.base/share/classes/java/util/ImmutableCollections.java line 1660:

> 1658:             @Override
> 1659:             public String toString() {
> 1660:                 return StableUtil.renderMappings(this, "StableSet", delegateEntrySet, false);

Suggestion:

                return StableUtil.renderMappings(this, "StableCollection", delegateEntrySet, false);

I think `StableList`, `StableSubList`, `StableReverseOrderListView`, `StableMapEntrySet` and `StableMapValues` should all use `"StableCollection"` to be consistent with `AbstractCollection`'s use of `"Collection"`. `StableMap` should use `"StableMap"` to be consistent with `AbstractMap`'s use of `"Map"`.

src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 70:

> 68:         }
> 69:         final int index = value.ordinal() - firstOrdinal;
> 70:         final StableValueImpl<R> delegate;

Suggestion:


This local variable is no longer used.

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 57:

> 55:             UNSAFE.objectFieldOffset(StableValueImpl.class, "contents");
> 56: 
> 57:     // Used to indicate a holder value is `null` (see field `value` below)

Suggestion:

    // Used to indicate a holder value is `null` (see field `contents` below)

The field is named `contents`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2085444718
PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2085348072
PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2085372556
PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2085422959
PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2085265954
PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2085289780

From duke at openjdk.org  Mon May 12 21:00:03 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Mon, 12 May 2025 21:00:03 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
 [v2]
In-Reply-To: <11qM0h_1z3Sws5UhAMhkDr4Kr5IEYPzSOKlyJz04OWM=.b1b2caa6-9bc6-4eaa-a119-9e1bf40f4fce@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
 <1tTlsd8W1XcfpCvL8P8pozXnvJWBmMtB_ObsAYLBZso=.029cc42a-a477-466f-846e-db19ac454c6b@github.com>
 <11qM0h_1z3Sws5UhAMhkDr4Kr5IEYPzSOKlyJz04OWM=.b1b2caa6-9bc6-4eaa-a119-9e1bf40f4fce@github.com>
Message-ID: <T73Y6Ppt5Nyc-qy6foYN69wqWzp7OGMXRWuNvkYyCQI=.4f48bde4-75ab-4fd5-aaba-3f14be86e19a@github.com>

On Fri, 9 May 2025 14:53:59 GMT, Chen Liang <liach at openjdk.org> 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 384 commits:
>> 
>>  - Fix an issue with toString on nested constructs
>>  - Merge branch 'master' into jep502-followup
>>  - Merge branch 'master' into jep502-followup
>>  - Update src/java.base/share/classes/java/lang/StableValue.java
>>    
>>    Co-authored-by: Chen Liang <liach at openjdk.org>
>>  - Simplify furhter
>>  - Address comments in PR
>>  - Merge master
>>  - Remove unused method and add comment
>>  - Address comments
>>  - Merge branch 'master' into jep502-followup
>>  - ... and 374 more: https://git.openjdk.org/jdk/compare/900b3ff7...3eebd504
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 1715:
> 
>> 1713: 
>> 1714:                 // For @ValueBased
>> 1715:                 static private <K, V> LazyMapIterator<K, V> of(StableMapEntrySet<K, V> outer) {
> 
> Suggestion:
> 
>                 private static <K, V> LazyMapIterator<K, V> of(StableMapEntrySet<K, V> outer) {

This doesn't seem to be resolved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2085387406

From duke at openjdk.org  Mon May 12 21:05:04 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Mon, 12 May 2025 21:05:04 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
 [v3]
In-Reply-To: <qh0f5DcpfqP7C07o9Ynhm-bUnzpZwhXyACKKzILTwok=.83a38bb6-55f0-41ed-941d-62ab826b483c@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
 <qh0f5DcpfqP7C07o9Ynhm-bUnzpZwhXyACKKzILTwok=.83a38bb6-55f0-41ed-941d-62ab826b483c@github.com>
Message-ID: <zfsFHGHMIB7BEHDKlDMtA1BfoWJ4Huvhfog4NK_WCJ8=.4d332862-1d05-46e8-ad32-b4f0394e8fd4@github.com>

On Mon, 12 May 2025 07:42:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
>> 
>> Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example.
>> 
>> Unfortunately, this PR shows the total commit history for stable values.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 386 commits:
> 
>  - Address comments
>  - Merge branch 'master' into jep502-followup
>  - Fix an issue with toString on nested constructs
>  - Merge branch 'master' into jep502-followup
>  - Merge branch 'master' into jep502-followup
>  - Update src/java.base/share/classes/java/lang/StableValue.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Simplify furhter
>  - Address comments in PR
>  - Merge master
>  - Remove unused method and add comment
>  - ... and 376 more: https://git.openjdk.org/jdk/compare/43008b42...a2826336

I noticed that this code will throw `NoSuchElementException` instead of `IndexOutOfBoundsException` and will swallow the message because of the `try`/`catch` in `ImmutableCollections.ListItr.next`/`previous`:

StableValue
    .list(42, _ -> {throw new IndexOutOfBoundsException("important message");})
    .listIterator(5)
    .next(); // same for previous()

Do you plan to implement this suggestion: https://github.com/openjdk/jdk/pull/23972#discussion_r2050713377?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25004#issuecomment-2874060190
PR Comment: https://git.openjdk.org/jdk/pull/25004#issuecomment-2874062775

From bpb at openjdk.org  Mon May 12 21:06:03 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 12 May 2025 21:06:03 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v16]
In-Reply-To: <2AyhnZiLia6FKXoJlSzArzhIiWCchzGM_EJ9hWj93_Y=.175dfeff-fc4e-46f8-9c80-413b9e4971e3@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <2AyhnZiLia6FKXoJlSzArzhIiWCchzGM_EJ9hWj93_Y=.175dfeff-fc4e-46f8-9c80-413b9e4971e3@github.com>
Message-ID: <CMDIq552aM4aePJsad4Gjf3qnb4N6f0vedF-0cyZN_8=.9db2f946-2051-4da7-abf1-dcbeeb2e9b6d@github.com>

On Tue, 6 May 2025 15:43:07 GMT, Brian Burkhalter <bpb at openjdk.org> 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: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test

> Both methods will need to specify what they return when already at end of stream, does readAllAsString return an empty or null,

Empty string.

> does readAllLines return an empty list?

Empty list.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2874062856

From duke at openjdk.org  Mon May 12 21:15:04 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Mon, 12 May 2025 21:15:04 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
 [v3]
In-Reply-To: <jmXHrPICRVNH3BzfyxM7d7RfihYFrZaSk_kupJ2TWoc=.60dc1e33-b96c-4af7-a9c9-243537678894@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
 <qh0f5DcpfqP7C07o9Ynhm-bUnzpZwhXyACKKzILTwok=.83a38bb6-55f0-41ed-941d-62ab826b483c@github.com>
 <jmXHrPICRVNH3BzfyxM7d7RfihYFrZaSk_kupJ2TWoc=.60dc1e33-b96c-4af7-a9c9-243537678894@github.com>
Message-ID: <c_GdSAnRwx8LOZ7tuA1MhEAdijO4DL0bNORvUYCuQDw=.308d5c17-6acd-437f-b8bc-fc730ad6ad3e@github.com>

On Mon, 12 May 2025 19:53:41 GMT, Luca Kellermann <duke at openjdk.org> 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 386 commits:
>> 
>>  - Address comments
>>  - Merge branch 'master' into jep502-followup
>>  - Fix an issue with toString on nested constructs
>>  - Merge branch 'master' into jep502-followup
>>  - Merge branch 'master' into jep502-followup
>>  - Update src/java.base/share/classes/java/lang/StableValue.java
>>    
>>    Co-authored-by: Chen Liang <liach at openjdk.org>
>>  - Simplify furhter
>>  - Address comments in PR
>>  - Merge master
>>  - Remove unused method and add comment
>>  - ... and 376 more: https://git.openjdk.org/jdk/compare/43008b42...a2826336
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 518:
> 
>> 516: 
>> 517:         private boolean allowNulls() {
>> 518:             return root instanceof ListN<?> listN && listN.allowNulls;
> 
> I think this should stay here (or some other change is needed). `StableSubList` doesn't override `indexOf` and `lastIndexOf`, so they will throw when given `null`, even though the list could contain `null`.

Example code that I think will fail with the changes in this PR:

var list = StableValue.list(42, x -> x == 23 ? null : x);
IO.println(list.indexOf(null)); // 23
IO.println(list.subList(10, 30).indexOf(null)); // NPE, should be 13

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2085512298

From iklam at openjdk.org  Mon May 12 21:17:10 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 12 May 2025 21:17:10 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v5]
In-Reply-To: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
Message-ID: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com>

> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
> 
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
> 
> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
> 
> Examples:
> 
> 
> # Create an AOT cache with a single command:
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> Hello World
> Temporary AOTConfiguration recorded: foo.aot.config
> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
> AOTCache creation is complete: foo.aot 10240000 bytes
> 
> # Create logging file for the AOT cache assembly phase
> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> 
> 
> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
 - Update java man page
 - Use one-step training by default in AOT testing
 - Implemented JTREG=AOT_JDK=(onestep|twostep); default is onestep
 - @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java
 - @vnkozlov comments
 - AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS
 - Remove %t restriction
 - Added %p substitution; clean up
 - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
 - ... and 4 more: https://git.openjdk.org/jdk/compare/45dfc2c6...b044953e

-------------

Changes: https://git.openjdk.org/jdk/pull/24942/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=04
  Stats: 1893 lines in 22 files changed: 1387 ins; 456 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/24942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942

PR: https://git.openjdk.org/jdk/pull/24942

From naoto at openjdk.org  Mon May 12 21:17:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 May 2025 21:17:53 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v3]
In-Reply-To: <qCYw6HZXz7G6A5oP8TMu6gDveR92Oqmi4AV-eWm5HCo=.f22a833b-f769-4613-bd9a-512f47f281eb@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com>
 <roVX3LMQmky1O4czbD4Csm_8nKwMt2ig2LtDqSD513E=.85520961-f85d-4568-bc4c-21f7c5f3ce27@github.com>
 <qCYw6HZXz7G6A5oP8TMu6gDveR92Oqmi4AV-eWm5HCo=.f22a833b-f769-4613-bd9a-512f47f281eb@github.com>
Message-ID: <snM9Qqvx_QsAnyX4F2IJCWzpbfbbmTsM7QHYpxA8d6w=.0533ad50-925c-4ed1-9aa5-b3a455287ff8@github.com>

On Sun, 11 May 2025 16:46:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 1. FileDescriptor.in: Unfortunately FileInputStream(FileDescriptor) has no overload that supports custom charsets. We should probably document both on this FD and that constructor.

The description of `FileDescriptor.in` reads:

Usually, this file descriptor is not used directly, but rather via the input stream known as System.in

And its `System.in` is hyperlinked. So I'd not add an example here.

> 2. JShell.in and JavaShellToolBuilder.in

(I assumed the first one as `JShell.Builder.in`)

These are not fields but methods to set the InputStream, so I don't think this example exercise applies to either. `jdk.jshell` package info has a code sample which uses `System.console()` instead of reading from `System.in` which is good.

> 3. A few usages in security, like password reading in sun.security.tools.keytool.Main, or javax.security.auth.callback.CallbackHandler

The former are within `sun` package which is internal, so no need for examples. The latter has code sample in the class description. In there:

new InputStreamReader(System.in)

So this one indeed need to be updated. Will address it in the next iteration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25155#issuecomment-2874120922

From iklam at openjdk.org  Mon May 12 21:35:52 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 12 May 2025 21:35:52 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v5]
In-Reply-To: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com>
Message-ID: <l_oftdAoNop7ouGXldcHeeui_MQ_ea9mBdI4xAzzbVA=.25b50119-8ae4-4d47-9319-4c3084b0343e@github.com>

On Mon, 12 May 2025 21:17:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>> 
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
>> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
>> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
>> 
>> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
>> 
>> Examples:
>> 
>> 
>> # Create an AOT cache with a single command:
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> Hello World
>> Temporary AOTConfiguration recorded: foo.aot.config
>> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
>> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
>> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
>> AOTCache creation is complete: foo.aot 10240000 bytes
>> 
>> # Create logging file for the AOT cache assembly phase
>> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> 
>> 
>> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
>  - Update java man page
>  - Use one-step training by default in AOT testing
>  - Implemented JTREG=AOT_JDK=(onestep|twostep); default is onestep
>  - @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java
>  - @vnkozlov comments
>  - AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS
>  - Remove %t restriction
>  - Added %p substitution; clean up
>  - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/45dfc2c6...b044953e

Per suggestion by @katyapav , I've updated RunTests.gmk to use the new "one step training" when creating the AOT cache for running jtreg test cases. `twostep` is the old behavior. E.g.:


make test JTREG=AOT_JDK=onestep TEST=open/test/hotspot/jtreg/runtime/invokedynamic
make test JTREG=AOT_JDK=twostep TEST=open/test/hotspot/jtreg/runtime/invokedynamic


Also, for the existing CDS jtreg tests that use CDSAppTester, the default testing mode is to use  "one step training" for creating the AOT cache.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24942#issuecomment-2874205674

From erikj at openjdk.org  Mon May 12 21:43:53 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 12 May 2025 21:43:53 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v5]
In-Reply-To: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com>
Message-ID: <8FryhUnn09RpstrSVIOwKLTPBwgh3HzS50dY2cMct5w=.b9e0840e-e585-4178-bd41-f19db4a6a016@github.com>

On Mon, 12 May 2025 21:17:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>> 
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
>> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
>> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
>> 
>> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
>> 
>> Examples:
>> 
>> 
>> # Create an AOT cache with a single command:
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> Hello World
>> Temporary AOTConfiguration recorded: foo.aot.config
>> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
>> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
>> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
>> AOTCache creation is complete: foo.aot 10240000 bytes
>> 
>> # Create logging file for the AOT cache assembly phase
>> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> 
>> 
>> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
>  - Update java man page
>  - Use one-step training by default in AOT testing
>  - Implemented JTREG=AOT_JDK=(onestep|twostep); default is onestep
>  - @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java
>  - @vnkozlov comments
>  - AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS
>  - Remove %t restriction
>  - Added %p substitution; clean up
>  - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/45dfc2c6...b044953e

This change in functionality for the `JTREG=AOT_JDK` makefile argument should probably be mentioned somewhere in `doc/testing.md`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2834697107

From duke at openjdk.org  Mon May 12 21:46:06 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 12 May 2025 21:46:06 GMT
Subject: RFR: 8077587: BigInteger Roots [v9]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <LxefDLX6xXIRIUvXQun_e3oL3DtVQct5aB6xe0M1GhI=.333b83ae-6303-477f-81c0-8686a07fbc81@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Removed useless code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/3e3d45c4..08e94a79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=07-08

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From bpb at openjdk.org  Mon May 12 21:58:18 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 12 May 2025 21:58:18 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v17]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: <tgT8z69pZ5hGbh3wMq5Y7iYsvU3-mABCnvVS3Biymkg=.0fb43ffc-b836-4480-a633-c3f78492b6b4@github.com>

> 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:

 - Update src/java.base/share/classes/java/io/Reader.java
   
   8354724: Apply suggested changes for readAllLines.
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
 - Update src/java.base/share/classes/java/io/Reader.java
   
   8354724: Apply suggested changes for readAllAsString.
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/983aeb50..a4cf9224

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=15-16

  Stats: 22 lines in 1 file changed: 9 ins; 0 del; 13 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 naoto at openjdk.org  Mon May 12 21:59:29 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 May 2025 21:59:29 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v4]
In-Reply-To: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
Message-ID: <xW-uW8MiDC5kYwq-D7Aon88zlVbLf7dedQK3eo_dy5s=.c7d5b4b1-7100-465b-93bc-230bd867b024@github.com>

> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects more comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25155/files
  - new: https://git.openjdk.org/jdk/pull/25155/files/6f8101cf..9621320c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=02-03

  Stats: 16 lines in 3 files changed: 8 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25155.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25155/head:pull/25155

PR: https://git.openjdk.org/jdk/pull/25155

From naoto at openjdk.org  Mon May 12 21:59:30 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 May 2025 21:59:30 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v3]
In-Reply-To: <Z6bJ68IgNergbAKVTl_RtS3MpFYOF2280WddkZKd1z8=.c1364895-268d-4503-a6f3-d1a3fee3adf8@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <3W4QAdIVjNbh-J9AeEuLzB1_s2xIVzf1BodFl0h5AAc=.f31e2336-3570-4c74-b2e2-e2f67c61694c@github.com>
 <Z6bJ68IgNergbAKVTl_RtS3MpFYOF2280WddkZKd1z8=.c1364895-268d-4503-a6f3-d1a3fee3adf8@github.com>
Message-ID: <aLKeiUMIKbKjFq-HwgCZENL6dxTdGpLqDELD5Iuhymk=.375eb122-c619-4729-9257-b40bf3ee3d4e@github.com>

On Mon, 12 May 2025 07:21:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects another review comment
>
> src/java.base/share/classes/java/io/InputStreamReader.java line 54:
> 
>> 52:  * }
>> 53:  * This example also demonstrates how to wrap {@link System#in} with {@link
>> 54:  * System##stdin.encoding stdin.encoding}.
> 
> This example communicates two concerns, one is buffering, the other is the charset to use when running from System.in. I think we should separate these two, maybe with two examples?

Made it two examples.

> src/java.base/share/classes/java/util/Scanner.java line 82:
> 
>> 80:  *
>> 81:  * <p>This code reads lines from {@link System#in} with {@link
>> 82:  * System##stdin.encoding stdin.encoding}:
> 
> "from System.in with stdin.encoding" isn't very clear. I think you we can expand the sentence, or make it two sentences, so to that is uses a Scanner to read lines from System.in, and uses the value of stdin.encoding as the charset.

Made it two sentences.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2085595822
PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2085595798

From swen at openjdk.org  Mon May 12 22:50:52 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 12 May 2025 22:50:52 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v4]
In-Reply-To: <UHjRw4soBJIZkvrX7i8qOyJ7h9LHDjD15k6G34r1mik=.a2e07ba1-e251-462a-a8f8-bd9c805a51cf@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <V8ZrRweDmVS9HD5kY8TM6xIVWBfiZy8StMHs6LPO78o=.59017549-3ec8-4627-b206-a9e897045081@github.com>
 <Wxyg9SVuqu7LVRudUKXl7K7kSw8_iA9ArJ18oBHb-rY=.02811a97-01ad-4185-9e61-474090ed2f89@github.com>
 <KOHIfa0AS_WepowGrmopq0fgWM-P7aI22AXONSWH1Xc=.867948c7-6ecc-49bb-b0f1-6301d6deca44@github.com>
 <UHjRw4soBJIZkvrX7i8qOyJ7h9LHDjD15k6G34r1mik=.a2e07ba1-e251-462a-a8f8-bd9c805a51cf@github.com>
Message-ID: <CGhOyak6HT7pmDla4nYteIx4uEOufcUyALcbHRy1bgw=.46520046-ee1d-4b9f-a6e8-7828d39363a1@github.com>

On Mon, 12 May 2025 18:33:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> This use of Unsafe is not warranted. If it can't be done with arrayCopy, leave the original code as is.
>> 
>> The core library also uses Unsafe.copyMemory in many places. Can it be used in this scenario? Or can we find other ways to copy char[] to byte[]?
>
> You may have overlooked the behavior of putChar to swap the order of the bytes depending on whether its big or little endian.

There is no endianness issue here. The byte[] of StringUTF16 has the same endianness order in memory as char[].

The Unsafe::CopyMemory operation here is the same as the Unsafe::putChar and StringUTF16::putChar operation on StringUTF16 byte[], so there is no endianness issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2085638167

From duke at openjdk.org  Mon May 12 23:14:10 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 12 May 2025 23:14:10 GMT
Subject: RFR: 8077587: BigInteger Roots [v10]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <ptrvXDdggWl5Qhir2CuuVgOH8tvgLLGT7f5Ze_X1Eec=.9ec754bc-5fe9-4d43-96d6-709c52cfbd08@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'nth-root-branch' of https://github.com/fabioromano1/jdk into nth-root-branch
 - correct and optimize the final loop

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/08e94a79..8f55229f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=08-09

  Stats: 15 lines in 1 file changed: 9 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From liach at openjdk.org  Mon May 12 23:23:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 May 2025 23:23:57 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v4]
In-Reply-To: <xW-uW8MiDC5kYwq-D7Aon88zlVbLf7dedQK3eo_dy5s=.c7d5b4b1-7100-465b-93bc-230bd867b024@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <xW-uW8MiDC5kYwq-D7Aon88zlVbLf7dedQK3eo_dy5s=.c7d5b4b1-7100-465b-93bc-230bd867b024@github.com>
Message-ID: <k3kZhxMx4nTyQT6dVeUJUlRfG6FLJPbhGBkMd9jlZKc=.7d8d2786-f1a0-40ce-8c2c-aaad0420e3b4@github.com>

On Mon, 12 May 2025 21:59:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects more comments

Do we need a CSR for this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25155#issuecomment-2874442044

From epavlova at openjdk.org  Mon May 12 23:24:04 2025
From: epavlova at openjdk.org (Ekaterina Pavlova)
Date: Mon, 12 May 2025 23:24:04 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v5]
In-Reply-To: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com>
Message-ID: <cIWtNPL0NCx0dc9fWNfTkq_kEaJn5aAyLSjwNBxifQY=.fc19b20b-0309-4e12-8ad9-cab030c2218f@github.com>

On Mon, 12 May 2025 21:17:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>> 
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
>> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
>> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
>> 
>> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
>> 
>> Examples:
>> 
>> 
>> # Create an AOT cache with a single command:
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> Hello World
>> Temporary AOTConfiguration recorded: foo.aot.config
>> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
>> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
>> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
>> AOTCache creation is complete: foo.aot 10240000 bytes
>> 
>> # Create logging file for the AOT cache assembly phase
>> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> 
>> 
>> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
>  - Update java man page
>  - Use one-step training by default in AOT testing
>  - Implemented JTREG=AOT_JDK=(onestep|twostep); default is onestep
>  - @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java
>  - @vnkozlov comments
>  - AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS
>  - Remove %t restriction
>  - Added %p substitution; clean up
>  - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/45dfc2c6...b044953e

make/RunTests.gmk changes look good to me.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2834836628

From jlu at openjdk.org  Mon May 12 23:26:55 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 May 2025 23:26:55 GMT
Subject: RFR: 8355393: Create a Test case to have special cases coverage
 for currency.getInstance() [v2]
In-Reply-To: <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
 <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>
Message-ID: <ajlqyimXKCirhh8qg0TP5wCaW-yoHzXpPD3zqsyvBmw=.d88ad90e-d619-422a-93f6-45c8218a50d3@github.com>

On Sun, 11 May 2025 08:42:41 GMT, Abhishek N <duke at openjdk.org> wrote:

>> Create a Test case to have special cases coverage for currency.getInstance().
>> 
>> The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API.
>> 
>> test results:
>> 
>> jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java
>> Directory "JTwork" not found: creating
>> Directory "JTreport" not found: creating
>> Test results: passed: 1
>> Report written to JTreport\html\report.html
>> Results written to JTwork
>
> Abhishek N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correcting jtreg header order, add meaningful comments for each test methods and properties file

Hi @abhn-git, I think it would be beneficial if we first addressed the concerns raised before continuing work on this PR. [JDK-8355393](https://bugs.openjdk.org/browse/JDK-8355393) assigned to you and [JDK-8355045](https://bugs.openjdk.org/browse/JDK-8355045) assigned to @weibxiao  appear to be duplicates.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2874462568

From bpb at openjdk.org  Mon May 12 23:51:19 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 12 May 2025 23:51:19 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v18]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: <ckd-UcxICCx3Zq-ehw1KBV7jQ3JfjX9jtZ0_DsxnlTE=.fb7f1026-cfa9-42a2-bf92-1622939a2b8d@github.com>

> Implement the requested methods and add a test thereof.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:

 - 8354724: Attempt to further improve verbiage
 - Merge
 - Update src/java.base/share/classes/java/io/Reader.java
   
   8354724: Apply suggested changes for readAllLines.
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
 - Update src/java.base/share/classes/java/io/Reader.java
   
   8354724: Apply suggested changes for readAllAsString.
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
 - 8354724: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test
 - 8354724: Fix potential NPE in test
 - 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test
 - 8354724: Improve test per reviewer comments
 - 8354724: Add missing toList(), tweak verbiage; update test
 - 8354724: Add Reader.readAllLines; test not yet updated
 - ... and 11 more: https://git.openjdk.org/jdk/compare/b1ab1054...1d811589

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/a4cf9224..1d811589

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=16-17

  Stats: 94574 lines in 2581 files changed: 69278 ins; 15222 del; 10074 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 iklam at openjdk.org  Tue May 13 00:01:39 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 13 May 2025 00:01:39 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v6]
In-Reply-To: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
Message-ID: <AFE4-6B75t8qSh78PcWGAllZBysTjy6cGJ90QA8WbYk=.218b246c-4e92-435e-8f3b-84fd30de5c89@github.com>

> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
> 
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
> 
> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
> 
> Examples:
> 
> 
> # Create an AOT cache with a single command:
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> Hello World
> Temporary AOTConfiguration recorded: foo.aot.config
> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
> AOTCache creation is complete: foo.aot 10240000 bytes
> 
> # Create logging file for the AOT cache assembly phase
> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> 
> 
> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Allow one-step training even when -XX:AOTMode=auto is specified

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24942/files
  - new: https://git.openjdk.org/jdk/pull/24942/files/b044953e..f33d5994

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=04-05

  Stats: 81 lines in 3 files changed: 62 ins; 3 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942

PR: https://git.openjdk.org/jdk/pull/24942

From bpb at openjdk.org  Tue May 13 00:03:51 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 May 2025 00:03:51 GMT
Subject: RFR: 8356107: [java.lang] Use @requires tag instead of exiting
 based on os.name or separatorChar property [v3]
In-Reply-To: <spfrwUbddiCRErnmad2oty-PKR-MVcADR0Yj7Y454T8=.80e1ff19-5137-48bb-81f6-7a4c8ff67681@github.com>
References: <tZiBKIvIBGsfgLaEtvf87nGGC4cdBrLkPYMNRlIHg1Q=.bcc1ff0b-ca04-4adc-9f61-9641c33f1807@github.com>
 <spfrwUbddiCRErnmad2oty-PKR-MVcADR0Yj7Y454T8=.80e1ff19-5137-48bb-81f6-7a4c8ff67681@github.com>
Message-ID: <SXiHYS5_1qNQ7MbhXD42jOrCqDx_t36AKdXN2Vn_sqk=.1c9b11a0-b72e-4367-b454-7090730aef09@github.com>

On Mon, 12 May 2025 17:58:29 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> For `java.lang` tests, use the `@requires` facility in place of checking the `os.name` system property or `File.separatorChar`.
>> 
>> Automated test results are omitted as expected.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   apostrophize

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25163#pullrequestreview-2834957477

From serb at openjdk.org  Tue May 13 00:13:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 00:13:50 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <E8b4gHUmdOVT14qtrvzEySgduI7s9R9v8sv_dayKXF0=.1f5975b7-00b6-4566-bd41-a9a77f8a9d71@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

src/demo/share/jfc/CodePointIM/README.html line 5:

> 3: <head>
> 4:   <title>README - CodePointIM</title>
> 5:   <meta http-equiv="content-type" content="text/html; charset=utf-8">

I believe this line is equivalent to simple `<meta charset="utf-8"/>` which is widely used in java.desktop's docs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25148#discussion_r2085710719

From darcy at openjdk.org  Tue May 13 00:21:51 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 13 May 2025 00:21:51 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v4]
In-Reply-To: <k3kZhxMx4nTyQT6dVeUJUlRfG6FLJPbhGBkMd9jlZKc=.7d8d2786-f1a0-40ce-8c2c-aaad0420e3b4@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <xW-uW8MiDC5kYwq-D7Aon88zlVbLf7dedQK3eo_dy5s=.c7d5b4b1-7100-465b-93bc-230bd867b024@github.com>
 <k3kZhxMx4nTyQT6dVeUJUlRfG6FLJPbhGBkMd9jlZKc=.7d8d2786-f1a0-40ce-8c2c-aaad0420e3b4@github.com>
Message-ID: <5faXt--bztWwFfeQ-eHeLK6BWuE4qYisWy6ctMeN-Zs=.721f2f24-6152-4081-8d93-05de39e22ac8@github.com>

On Mon, 12 May 2025 23:21:15 GMT, Chen Liang <liach at openjdk.org> wrote:

> Do we need a CSR for this?

No; from a quick look, I don't see a need for a CSR here as the semantics aren't being changed. HTH

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25155#issuecomment-2874629944

From liach at openjdk.org  Tue May 13 00:25:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 May 2025 00:25:51 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v4]
In-Reply-To: <xW-uW8MiDC5kYwq-D7Aon88zlVbLf7dedQK3eo_dy5s=.c7d5b4b1-7100-465b-93bc-230bd867b024@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <xW-uW8MiDC5kYwq-D7Aon88zlVbLf7dedQK3eo_dy5s=.c7d5b4b1-7100-465b-93bc-230bd867b024@github.com>
Message-ID: <Skpwmlvcn2P5-CBJuYTd8W4iOGMUMr5W851nPX8ZRO4=.bcbb3003-4e4b-46e3-b73c-9fb4d79db8d3@github.com>

On Mon, 12 May 2025 21:59:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects more comments

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25155#pullrequestreview-2834978752

From almatvee at openjdk.org  Tue May 13 00:35:08 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 13 May 2025 00:35:08 GMT
Subject: RFR: 8356819: [macos] MacSign should use "openssl" and "faketime" from
 Homebrew by default
Message-ID: <jEwKDDQdZMgD0e3COH80ToqMISmNetDLzavuybWGsbM=.f6c3dfbf-a6c1-4d92-b61e-0ca3a778b9b2@github.com>

`openssl` from macOS will ignore `faketime` and as result expired certificates will not be generated correctly. By default we should use these tools from Homebrew.

-------------

Commit messages:
 - 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default

Changes: https://git.openjdk.org/jdk/pull/25196/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25196&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356819
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25196.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25196/head:pull/25196

PR: https://git.openjdk.org/jdk/pull/25196

From smarks at openjdk.org  Tue May 13 00:57:52 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 13 May 2025 00:57:52 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v4]
In-Reply-To: <xW-uW8MiDC5kYwq-D7Aon88zlVbLf7dedQK3eo_dy5s=.c7d5b4b1-7100-465b-93bc-230bd867b024@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <xW-uW8MiDC5kYwq-D7Aon88zlVbLf7dedQK3eo_dy5s=.c7d5b4b1-7100-465b-93bc-230bd867b024@github.com>
Message-ID: <AA9cYDbhLveU1lvujFXtvVNbk4DDGC4DYvuL-DtwpEA=.eaa367ba-9ecc-4691-bd4e-80f89efdab9b@github.com>

On Mon, 12 May 2025 21:59:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects more comments

src/java.base/share/classes/java/lang/System.java line 129:

> 127:      * within the object that handles character encoding. After this is done,
> 128:      * subsequent reading should use only the wrapper object; operating directly
> 129:      * on {@code System.in} results in unspecified behavior.

Sorry, I think I suggested this wording initially, but I now think it needs to be changed. I'd suggest changing the text after the semicolon to

> continuing to operate directly on {@code System.in} results in unspecified behavior.

src/java.base/share/classes/javax/security/auth/callback/CallbackHandler.java line 116:

> 114:      *          System.err.flush();
> 115:      *          nc.setName((new BufferedReader
> 116:      *                  (new InputStreamReader(System.in, "stdin.encoding"))).readLine());

Needs to be `System.getProperty("stdin.encoding"))`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2085741488
PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2085739806

From smarks at openjdk.org  Tue May 13 01:02:59 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 13 May 2025 01:02:59 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v4]
In-Reply-To: <xW-uW8MiDC5kYwq-D7Aon88zlVbLf7dedQK3eo_dy5s=.c7d5b4b1-7100-465b-93bc-230bd867b024@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <xW-uW8MiDC5kYwq-D7Aon88zlVbLf7dedQK3eo_dy5s=.c7d5b4b1-7100-465b-93bc-230bd867b024@github.com>
Message-ID: <FD_mtO4UI8We38KZvv-ETlxOua0Y9K6qtJqVIwdj9NQ=.a5d479de-61d6-46ed-ba79-f56175288a03@github.com>

On Mon, 12 May 2025 21:59:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects more comments

src/java.base/share/classes/java/util/Scanner.java line 89:

> 87:  *          String aLine = sc.nextLine();
> 88:  *      }
> 89:  * }

Now that I'm looking at the other examples, I have what I think is better example for using Scanner on System.in. Take this example and move it after the example below, which reads long values from the file `myNumbers`. The new example could do the same thing with the hasNextLong/nextLong loop. But instead it would read from System.in using the encoding specified by `stdin.encoding`. The example could explain that reading from files uses the default encoding (`file.encoding`) whereas reading from System.in should use `stdin.encoding` because on some systems this differs from the default encoding.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2085745213

From asemenyuk at openjdk.org  Tue May 13 01:53:02 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 13 May 2025 01:53:02 GMT
Subject: RFR: 8356819: [macos] MacSign should use "openssl" and "faketime"
 from Homebrew by default
In-Reply-To: <jEwKDDQdZMgD0e3COH80ToqMISmNetDLzavuybWGsbM=.f6c3dfbf-a6c1-4d92-b61e-0ca3a778b9b2@github.com>
References: <jEwKDDQdZMgD0e3COH80ToqMISmNetDLzavuybWGsbM=.f6c3dfbf-a6c1-4d92-b61e-0ca3a778b9b2@github.com>
Message-ID: <NRd5Zvn88737N1CEJZqJzF-rXqANhHhoNh_XCBswtVk=.5914c5b8-a16c-4fdf-b66e-8b3da962e202@github.com>

On Tue, 13 May 2025 00:30:08 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> `openssl` from macOS will ignore `faketime` and as result expired certificates will not be generated correctly. By default we should use these tools from Homebrew.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25196#pullrequestreview-2835070598

From jpai at openjdk.org  Tue May 13 02:11:03 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 May 2025 02:11:03 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v12]
In-Reply-To: <Pwg387UD70trpGMPa3_eu0cC0ruDrMUxCnnj--zljTo=.1ddcdc99-93b9-40f4-a5cc-c5944d577641@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <RNjfXmLSFjOSDLSAVLrWIlUKJttDTPTKCC8oxAXV_TI=.1f3d4e59-a095-4416-81e9-fd178c5faab4@github.com>
 <QQz0fuco5e10bsnlLrLkV-52s9ONaPJwfqCpXfZCfK4=.75cd9f62-b37c-4c7d-8883-0b8333322131@github.com>
 <xcxCND4TolntVAJ07uxXC3cXgCKscV3Dul1NFyN3BYs=.d2643648-e18f-49ec-b604-6b9c0b7f79a1@github.com>
 <Pwg387UD70trpGMPa3_eu0cC0ruDrMUxCnnj--zljTo=.1ddcdc99-93b9-40f4-a5cc-c5944d577641@github.com>
Message-ID: <TiO7lSPfdrDJDRFphq2VR8S7LryJLF4Mh62UeDzlIvE=.712eb78f-f402-41d5-bf43-122a50610afd@github.com>

On Mon, 12 May 2025 10:34:37 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Hello Andrey, what you note is right. This and the other change you have proposed to this text seems reasonable. Do you want to create a JBS issue and raise a PR proposing this change?
>
> We could also simply include it in the PR for https://bugs.openjdk.org/browse/JDK-8356679 to reduce organizational overhead.

Hello Markus, it's OK to do this text change as part of JDK-8356679. Like Roger noted in the corresponding core-libs-dev mailing list, it would be good to do the 8356679 changes in smaller pieces and include this change in one of those.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2085794320

From naoto at openjdk.org  Tue May 13 02:31:42 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 May 2025 02:31:42 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v5]
In-Reply-To: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
Message-ID: <RfgnxL_Dcr5OtdpLB9Av2WIkQ3D-2M9YzCyUkSGEyu0=.5adad739-bdf5-424c-9660-32534b216c0b@github.com>

> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting further comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25155/files
  - new: https://git.openjdk.org/jdk/pull/25155/files/9621320c..9af90274

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=03-04

  Stats: 28 lines in 3 files changed: 15 ins; 10 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25155.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25155/head:pull/25155

PR: https://git.openjdk.org/jdk/pull/25155

From naoto at openjdk.org  Tue May 13 02:31:43 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 May 2025 02:31:43 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v4]
In-Reply-To: <AA9cYDbhLveU1lvujFXtvVNbk4DDGC4DYvuL-DtwpEA=.eaa367ba-9ecc-4691-bd4e-80f89efdab9b@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <xW-uW8MiDC5kYwq-D7Aon88zlVbLf7dedQK3eo_dy5s=.c7d5b4b1-7100-465b-93bc-230bd867b024@github.com>
 <AA9cYDbhLveU1lvujFXtvVNbk4DDGC4DYvuL-DtwpEA=.eaa367ba-9ecc-4691-bd4e-80f89efdab9b@github.com>
Message-ID: <QYFJiCs7olehtwlpISYIFkMCOE-9E72CBn8TAm9y6ro=.7aec8962-a2c2-4217-b0aa-f79ac03fd0fb@github.com>

On Tue, 13 May 2025 00:55:14 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects more comments
>
> src/java.base/share/classes/java/lang/System.java line 129:
> 
>> 127:      * within the object that handles character encoding. After this is done,
>> 128:      * subsequent reading should use only the wrapper object; operating directly
>> 129:      * on {@code System.in} results in unspecified behavior.
> 
> Sorry, I think I suggested this wording initially, but I now think it needs to be changed. I'd suggest changing the text after the semicolon to
> 
>> continuing to operate directly on {@code System.in} results in unspecified behavior.

Done.

> src/java.base/share/classes/java/util/Scanner.java line 89:
> 
>> 87:  *          String aLine = sc.nextLine();
>> 88:  *      }
>> 89:  * }
> 
> Now that I'm looking at the other examples, I have what I think is better example for using Scanner on System.in. Take this example and move it after the example below, which reads long values from the file `myNumbers`. The new example could do the same thing with the hasNextLong/nextLong loop. But instead it would read from System.in using the encoding specified by `stdin.encoding`. The example could explain that reading from files uses the default encoding (`file.encoding`) whereas reading from System.in should use `stdin.encoding` because on some systems this differs from the default encoding.

I added an extra sentence for the explanation.

> src/java.base/share/classes/javax/security/auth/callback/CallbackHandler.java line 116:
> 
>> 114:      *          System.err.flush();
>> 115:      *          nc.setName((new BufferedReader
>> 116:      *                  (new InputStreamReader(System.in, "stdin.encoding"))).readLine());
> 
> Needs to be `System.getProperty("stdin.encoding"))`.

Good catch! Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2085812565
PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2085812615
PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2085812480

From iklam at openjdk.org  Tue May 13 03:06:44 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 13 May 2025 03:06:44 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v7]
In-Reply-To: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
Message-ID: <qctRiRRA6GVy-SAwn4k2Gfo0jmlPbZn5w9QgKjWjmY4=.34fdf078-b7a5-40f0-88fa-503885ccba2f@github.com>

> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
> 
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
> 
> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
> 
> Examples:
> 
> 
> # Create an AOT cache with a single command:
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> Hello World
> Temporary AOTConfiguration recorded: foo.aot.config
> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
> AOTCache creation is complete: foo.aot 10240000 bytes
> 
> # Create logging file for the AOT cache assembly phase
> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> 
> 
> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Added param to makefile function SetupAOT for choosing onestep vs twostep

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24942/files
  - new: https://git.openjdk.org/jdk/pull/24942/files/f33d5994..3cc2cb3a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=05-06

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942

PR: https://git.openjdk.org/jdk/pull/24942

From naoto at openjdk.org  Tue May 13 03:15:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 May 2025 03:15:25 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v6]
In-Reply-To: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
Message-ID: <VwNp5Cm91ConpVD6zzob2uwVNNf5GuUc7s6mVeefp0g=.13138944-a496-4487-b906-3eb4b69f28f7@github.com>

> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Removed an erroneous curly brace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25155/files
  - new: https://git.openjdk.org/jdk/pull/25155/files/9af90274..cfcae707

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25155&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25155.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25155/head:pull/25155

PR: https://git.openjdk.org/jdk/pull/25155

From hchao at openjdk.org  Tue May 13 03:58:53 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 13 May 2025 03:58:53 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v3]
In-Reply-To: <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>
Message-ID: <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com>

On Mon, 12 May 2025 20:05:18 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
>> 
>> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make sure the exception happens during KeyManager's algorithm check

It is nice to refactor the common code for algorithm constraints checking into a new class, `X509KeyManagerConstraints.java`, used by both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a new system property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. When setting this property to true, it will disable the existing RFC compliant algorithm constraints checking even in `X509KeyManagerImpl`, and we?d want to avoid that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2874984309

From darcy at openjdk.org  Tue May 13 04:02:04 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 13 May 2025 04:02:04 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v10]
In-Reply-To: <3i5Up4OJbfk1ytccMO66B0VtzqOS5pgMeLv7Lb_N5EE=.df0f670f-ef4f-4205-892b-cad0001ec397@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
 <3i5Up4OJbfk1ytccMO66B0VtzqOS5pgMeLv7Lb_N5EE=.df0f670f-ef4f-4205-892b-cad0001ec397@github.com>
Message-ID: <fHaWPZrbjqDv5Im0ggCfbW3gX_vE6T6g7CTqGDcfZ0s=.1e81634d-abea-44bc-8139-266b958fa9ab@github.com>

On Sat, 10 May 2025 10:08:39 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> See the JBS bug for some details.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed reviewer comments.

Marked as reviewed by darcy (Reviewer).

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1878:

> 1876: 
> 1877:         /*
> 1878:          * In some places the idiom

Might be easier to read the code if this logic were refactored into a method.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22737#pullrequestreview-2835206552
PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2085876226

From duke at openjdk.org  Tue May 13 04:06:34 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Tue, 13 May 2025 04:06:34 GMT
Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with
 exitValue = 1 [v2]
In-Reply-To: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
Message-ID: <BirOeZpJHWOKWkrxpjqmg383z27oi9s7YG6n4xIWr1U=.1a3420ac-cc51-4330-8b51-bb57515693e6@github.com>

> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1

PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:

  Update TestDockerMemoryMetricsSubgroup.java
  
  remove extra space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24930/files
  - new: https://git.openjdk.org/jdk/pull/24930/files/1b131d86..ad855247

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24930&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24930&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24930/head:pull/24930

PR: https://git.openjdk.org/jdk/pull/24930

From darcy at openjdk.org  Tue May 13 04:07:52 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 13 May 2025 04:07:52 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double)
In-Reply-To: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
Message-ID: <EoyCv_MTPq6FkFPmYskgEBHMSk_Jqj_GuZaU97bEPUk=.a8cc93fa-7e26-43b9-8336-10da9d445834@github.com>

On Sun, 11 May 2025 16:22:11 GMT, Johannes Graham <duke at openjdk.org> wrote:

> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.

src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 141:

> 139:     /**
> 140:      * Value <code>scale</code>, such that
> 141:      * <code> value = (f &times; 10<sup>-scale</sup>)</code>

Raw javadoc nit: wherever possible, please use `{@code foo}` rather than `<code>foo</code>`. I find the former much easier to read and it is fewer characters too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2085880551

From smarks at openjdk.org  Tue May 13 04:53:57 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 13 May 2025 04:53:57 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v6]
In-Reply-To: <VwNp5Cm91ConpVD6zzob2uwVNNf5GuUc7s6mVeefp0g=.13138944-a496-4487-b906-3eb4b69f28f7@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <VwNp5Cm91ConpVD6zzob2uwVNNf5GuUc7s6mVeefp0g=.13138944-a496-4487-b906-3eb4b69f28f7@github.com>
Message-ID: <TeWrCPdt0tvbyg1Z-ch6WFFSO33m7u9XJV-Lr0nOo5I=.2ae303fc-aaee-4b10-85a7-40552933b1b2@github.com>

On Tue, 13 May 2025 03:15:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed an erroneous curly brace

Thanks for the updates! Looks good.

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25155#pullrequestreview-2835259395

From darcy at openjdk.org  Tue May 13 05:06:54 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 13 May 2025 05:06:54 GMT
Subject: RFR: 8355992: Add unsignedMultiplyExact and *powExact methods to
 Math and StrictMath [v3]
In-Reply-To: <djTclwh1LKH7n2fyWkCGSGT6Fwaj83QmxlG9sxrhntk=.bc07f557-ba6d-4c17-87ba-50b4a2112885@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
 <djTclwh1LKH7n2fyWkCGSGT6Fwaj83QmxlG9sxrhntk=.bc07f557-ba6d-4c17-87ba-50b4a2112885@github.com>
Message-ID: <To7Hv-y85YXXLUYKYimAcDRaQ3kakOSWDE2NlCAIDLk=.d0516a59-1a3e-4bfc-906c-a3bf8f16be86@github.com>

On Thu, 8 May 2025 15:13:19 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments.
>> Further, add `unsignedMultiplyExact` methods as well.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added tests.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25003#pullrequestreview-2835276748

From pminborg at openjdk.org  Tue May 13 05:49:59 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 13 May 2025 05:49:59 GMT
Subject: RFR: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out [v6]
In-Reply-To: <PyQZw4HIrWt4SmlesS5nONMrfMm_X5WdNgYXGUwDRtw=.c7d23eb7-2a37-4bfe-834d-f606e2f7381d@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
 <PyQZw4HIrWt4SmlesS5nONMrfMm_X5WdNgYXGUwDRtw=.c7d23eb7-2a37-4bfe-834d-f606e2f7381d@github.com>
Message-ID: <5WpfLr2AvhUjY8uD3QfVNo46T0Jew2PfpUm9cHjiC3k=.8423e3d7-186f-41a3-bed4-7773f87fd090@github.com>

On Mon, 12 May 2025 14:41:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
>> 
>> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove delimiter between JBS issues

Test run in tier5 passes now. Thanks for the reviews and suggestions for improvement here!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25177#issuecomment-2875116994

From pminborg at openjdk.org  Tue May 13 05:49:59 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 13 May 2025 05:49:59 GMT
Subject: Integrated: 8356658: java/foreign/TestBufferStackStress2.java failed
 again with junit action timed out
In-Reply-To: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
References: <ZZPpDcRjPTwAPkriWm943W97w6Cvail_4bZz2jwHgFI=.89a14c43-b029-4be9-b5b0-5a77a9cf7ed2@github.com>
Message-ID: <xFqQnYcc0IseWHM8fOsHKwcSWVXsI92xL44j7Yjsl4E=.a3069ba5-1603-4a07-a7f0-16a53c652a26@github.com>

On Mon, 12 May 2025 08:57:59 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add a safety net around closing the executor. Apparently, in some rare configuration, the VT is not run/notified correctly.
> 
> Not completing the test for such a configuration is unlikely to mask potential issues that this test is supposed to reveal.

This pull request has now been integrated.

Changeset: 6e084691
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6e0846918ce1286ea1571a6ec0de8e6b44e24218
Stats:     19 lines in 1 file changed: 8 ins; 4 del; 7 mod

8356658: java/foreign/TestBufferStackStress2.java failed again with junit action timed out

Reviewed-by: jpai, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25177

From alanb at openjdk.org  Tue May 13 06:14:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 May 2025 06:14:51 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <jpu6AaHhiBzIuwqmpMUdjutvU63uE-rKM2EKcWfXhuQ=.859ef831-0603-47ff-8373-66ae4fc0f6fe@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <a_t_Ftohx-cl2pt1hLnu5WeC6mavdNK4ZUPVsufsX1s=.0a08bd89-3320-4031-99b8-9aad787f59f0@github.com>
 <jpu6AaHhiBzIuwqmpMUdjutvU63uE-rKM2EKcWfXhuQ=.859ef831-0603-47ff-8373-66ae4fc0f6fe@github.com>
Message-ID: <QET6mMWDxaRvVJMd0EUzmC4hh32F06SPU4-yt0o9bp8=.4f4b0493-c0e3-463c-b882-5e5f3aa1744e@github.com>

On Mon, 12 May 2025 20:19:43 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/jdk.zipfs/share/classes/module-info.java line 160:
>> 
>>> 158:  *       will always be opened <em>read-write</em> (see {@code "accessMode"}
>>> 159:  *       below), regardless of whether the underlying ZIP already existed or
>>> 160:  *       not.
>> 
>> In the default provider, "read-only && create" ignores the create option so the open fails if the file does not exist.
>> 
>> For the zipfs provider then doing the same, or having this combination be an error, is okay. I think it might be a bit too surprising to have "read-only && create" create a read-write file system.
>
> Is this comment just agreeing with the proposed behaviour stated here?
> 
> At the moment the code prohibits "read-only && create". It's an illegal argument exception (see tests).
> 
> The only allowed access mode options with "create" are "readWrite" or <no-option>, and in both cases you get back a ZipFileSystem for which "isReadOnly()" is false. We'd already agreed that any explicit access mode needs to always be honoured.

I agree that read-only && create is a combination to be rejected.  My comment is about the update to the description of the "create" option. It's the first row in the table and the changes suggests that it is forcing the file system to be read-write. I think the wording for the "readOnly" option is sufficient, meaning just one place to document the conflict between these two options.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2085993836

From pminborg at openjdk.org  Tue May 13 06:25:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 13 May 2025 06:25:03 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
 [v3]
In-Reply-To: <c_GdSAnRwx8LOZ7tuA1MhEAdijO4DL0bNORvUYCuQDw=.308d5c17-6acd-437f-b8bc-fc730ad6ad3e@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
 <qh0f5DcpfqP7C07o9Ynhm-bUnzpZwhXyACKKzILTwok=.83a38bb6-55f0-41ed-941d-62ab826b483c@github.com>
 <jmXHrPICRVNH3BzfyxM7d7RfihYFrZaSk_kupJ2TWoc=.60dc1e33-b96c-4af7-a9c9-243537678894@github.com>
 <c_GdSAnRwx8LOZ7tuA1MhEAdijO4DL0bNORvUYCuQDw=.308d5c17-6acd-437f-b8bc-fc730ad6ad3e@github.com>
Message-ID: <7Q5c-KaZ4iDbK_Byf57NABfWRZUMNy-KIpNwYF9910g=.88424cfa-c849-4a1f-aef8-ce37fafa25a1@github.com>

On Mon, 12 May 2025 21:12:36 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ImmutableCollections.java line 518:
>> 
>>> 516: 
>>> 517:         private boolean allowNulls() {
>>> 518:             return root instanceof ListN<?> listN && listN.allowNulls;
>> 
>> I think this should stay here (or some other change is needed). `StableSubList` doesn't override `indexOf` and `lastIndexOf`, so they will throw when given `null`, even though the list could contain `null`.
>
> Example code that I think will fail with the changes in this PR:
> 
> var list = StableValue.list(42, x -> x == 23 ? null : x);
> IO.println(list.indexOf(null)); // 23
> IO.println(list.subList(10, 30).indexOf(null)); // NPE, should be 13

Good catch. I will add a test that will test all list view combinations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2086007633

From pminborg at openjdk.org  Tue May 13 07:31:58 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 13 May 2025 07:31:58 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
 [v3]
In-Reply-To: <qh0f5DcpfqP7C07o9Ynhm-bUnzpZwhXyACKKzILTwok=.83a38bb6-55f0-41ed-941d-62ab826b483c@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
 <qh0f5DcpfqP7C07o9Ynhm-bUnzpZwhXyACKKzILTwok=.83a38bb6-55f0-41ed-941d-62ab826b483c@github.com>
Message-ID: <06AUoZOUqKnr59GqEmJeVU8X38OXrOJq6c4Oh18-KY8=.275c08eb-8778-41b5-bc03-390d74e91883@github.com>

On Mon, 12 May 2025 07:42:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
>> 
>> Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example.
>> 
>> Unfortunately, this PR shows the total commit history for stable values.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 386 commits:
> 
>  - Address comments
>  - Merge branch 'master' into jep502-followup
>  - Fix an issue with toString on nested constructs
>  - Merge branch 'master' into jep502-followup
>  - Merge branch 'master' into jep502-followup
>  - Update src/java.base/share/classes/java/lang/StableValue.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Simplify furhter
>  - Address comments in PR
>  - Merge master
>  - Remove unused method and add comment
>  - ... and 376 more: https://git.openjdk.org/jdk/compare/43008b42...a2826336

> I noticed that this code will throw `NoSuchElementException` instead of `IndexOutOfBoundsException` and will swallow the message because of the `try`/`catch` in `ImmutableCollections.ListItr.next`/`previous`:
> 
> ```java
> StableValue
>     .list(42, _ -> {throw new IndexOutOfBoundsException("important message");})
>     .listIterator(5)
>     .next(); // same for previous()
> ```

We will take a look at this under a separate issue: https://bugs.openjdk.org/browse/JDK-8356842

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25004#issuecomment-2875362328

From pminborg at openjdk.org  Tue May 13 07:57:15 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 13 May 2025 07:57:15 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
 [v4]
In-Reply-To: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
Message-ID: <yJoCuLgZ3VRFyQKOS8HuV8xE3M80Ta5MwGwkYZVtFh8=.ccea0f91-038e-4fa0-a3f1-aa626a011b7a@github.com>

> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
> 
> Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example.
> 
> Unfortunately, this PR shows the total commit history for stable values.

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/25004/files
  - new: https://git.openjdk.org/jdk/pull/25004/files/a2826336..cebd1c0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25004&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25004&range=02-03

  Stats: 83 lines in 6 files changed: 71 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25004.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25004/head:pull/25004

PR: https://git.openjdk.org/jdk/pull/25004

From alanb at openjdk.org  Tue May 13 08:34:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 May 2025 08:34:52 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v6]
In-Reply-To: <VwNp5Cm91ConpVD6zzob2uwVNNf5GuUc7s6mVeefp0g=.13138944-a496-4487-b906-3eb4b69f28f7@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <VwNp5Cm91ConpVD6zzob2uwVNNf5GuUc7s6mVeefp0g=.13138944-a496-4487-b906-3eb4b69f28f7@github.com>
Message-ID: <gGxnYLFnYvfWmeUlJxMJOGcSLBbqqvYeTtit4Q_uvfo=.c21ae8b8-cebf-4e39-b0d1-7728cad851bb@github.com>

On Tue, 13 May 2025 03:15:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed an erroneous curly brace

Good.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25155#pullrequestreview-2835788543

From alanb at openjdk.org  Tue May 13 08:46:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 May 2025 08:46:05 GMT
Subject: Integrated: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview)
In-Reply-To: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
References: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
Message-ID: <CmE-2nJ8fV0yrLwNqTFTDk0UF5VGZcsnzPlYEdHoBeo=.c1208eb0-0a8a-46e1-8202-8d72c7c4592c@github.com>

On Wed, 6 Nov 2024 15:47:55 GMT, Alan Bateman <alanb at openjdk.org> 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.

This pull request has now been integrated.

Changeset: 132a890a
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/132a890a9b3b70f2358237ebd9242b6747ba03dd
Stats:     4036 lines in 14 files changed: 1818 ins; 1438 del; 780 mod

8342486: Implement JEP 505: Structured Concurrency (Fifth Preview)

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Co-authored-by: Viktor Klang <vklang at openjdk.org>
Reviewed-by: vklang

-------------

PR: https://git.openjdk.org/jdk/pull/21934

From markus at headcrashing.eu  Tue May 13 09:05:59 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Tue, 13 May 2025 11:05:59 +0200
Subject: RFC: 8356679: Using CharSequence::getChars internally
In-Reply-To: <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com>
References: <f4cf0270-eb00-4c52-99a4-8e8057bb2bc9@gmx.net>
 <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com>
Message-ID: <f4330452-258c-42f8-a24b-9217da839892@headcrashing.eu>

Thank you, Roger.

Actually the method helps in the "toString()" variants, too, as in some 
places we could *get rid* of "toString()" (which is more work than 
"just" a buffer due to the added compression complexity).

In fact, I already took the time to rewrite *all* of them while waiting 
for the approval of this list posting. In *all* cases *less* buffering / 
copying is needed, and *less* "toString()" conversion (which is a copy 
under the hood) is needed. So if I would be allowed to show the code as 
a PR, it would be much easier to explain and discuss.

A PR is the best place to discuss "how to code would change". In the 
worst case, let's drop it if we see that it is actually a bad thing.

-Markus


Am 12.05.2025 um 20:18 schrieb Roger Riggs:
> Hi Markus,
>
> On the surface, its looks constructive.
> I suspect that many of these cases will turn into discussions about 
> the right/best/better way to buffer the characters.
> The getChars method only helps when extracting to a char array, many 
> of the current implementations create strings as the intermediary. The 
> advantage of the 1 character at a time technique is not needing a 
> (separated allocated) buffer.
> Consider taking a few at a time before launching into the whole set.
>
> $.02, Roger
>
> On 5/11/25 2:45 AM, Markus KARG wrote:
>> Dear Core Libs Team,
>>
>> I am hereby requesting comments on JDK-8356679.
>>
>> I would like to invest some time and set up a PR implementing Chen 
>> Liangs's proposal laid out in 
>> https://bugs.openjdk.org/browse/JDK-8356679. For your convenience, 
>> the text of that JBS is copied below. According to the Developer's 
>> Guide I do need to get broad agreement BEFORE filing a PR. Therefore, 
>> I kindly ask everybody to briefly show consent, so I may file a PR.
>>
>> Thanks
>> -Markus
>>
>>
>> Copy from https://bugs.openjdk.org/browse/JDK-8356679:
>>
>> Recently OpenJDK adopted the new method CharSequence::getChars(int, 
>> int, char[], int) for inclusion in Java 25. As a bulk reader method, 
>> it allows potentially improved efficiency over the previously 
>> available char-by-char reader method CharSequence::charAt(int).
>>
>> Chen Liang suggested on March 23rd on the core-lib-dev mailing list 
>> to use the new method within the internal source code of OpenJDK for 
>> the implementation of Appendables (see 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). 
>> The idea behind this is that the implementations might be more 
>> efficient then.
>>
>> A quick analysis of the OpenJDK source code identified (at least) the 
>> following classes which could potentially run more efficient when 
>> using CharSequence::getChars internally, thanks to bulk reading and / 
>> or prevention of internal copies / toString() conversions:
>> * java.io.Writer
>> * java.io.StringWriter
>> * java.io.PrintWriter
>> * java.io.BufferedWriter
>> * java.io.CharArrayWriter
>> * java.io.FileWriter
>> * java.io.OutputStreamWriter
>> * sun.nio.cs.StreamEncoder
>> * java.io.PrintStream
>> * java.nio.CharBuffer
>>
>> In the sense of "eat your own dog food", it makes sense to implement 
>> Chen's idea in (at least) those classes. Possibly more classes could 
>> get identified when taking a deeper look. Besides the potential 
>> efficiency improvements, it would be a good show case for the usage 
>> of the new API.
>>
>> The risk of this change should be low, as test coverage exists, and 
>> as the intended changes are solely internal to the implementation. No 
>> API will get changed. In some cases the JavaDocs will get slightly 
>> adapted where it currently exposes the actual implementation (to not 
>> lie in future).
>>
>

From abimpoudis at openjdk.org  Tue May 13 09:16:53 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 13 May 2025 09:16:53 GMT
Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used
 outside the compiler
In-Reply-To: <Z6edQzqZJOW0plvUyTl6J5FxLgcbEsKDf0bKi5PCflg=.78f6180e-fb77-4507-a578-8cca193d8894@github.com>
References: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
 <Z6edQzqZJOW0plvUyTl6J5FxLgcbEsKDf0bKi5PCflg=.78f6180e-fb77-4507-a578-8cca193d8894@github.com>
Message-ID: <Um0llRWhZJJbcFXvLDgJ4sz7e87tat7L8i6Y2Lk-PuU=.3b2f3d0e-c64c-4ccf-abf8-52cba8d7d72d@github.com>

On Mon, 12 May 2025 09:16:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation.
>> 
>> For example this is not valid Java (and protected) by javac:
>> 
>> 
>> byte b = 1;
>> switch (b) {
>>     case String s -> System.out.println("How did we get here? byte is " + s.getClass());
>> }
>> 
>> 
>> but this is a valid call (and not protected):
>> 
>> 
>> CallSite shortSwitch = SwitchBootstraps.typeSwitch(
>>     MethodHandles.lookup(), 
>>     "", 
>>     MethodType.methodType(int.class, short.class, int.class),  // models (short, int) -> int
>>     String.class);
>> 
>> 
>> The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. 
>> 
>> This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 725:
> 
>> 723: 
>> 724:     private static boolean isNotValidPair(Class<?> selectorType, Object caseLabel) {
>> 725:         return (selectorType == boolean.class && caseLabel != boolean.class && caseLabel != Boolean.class) ||
> 
> What happens if `caseLabel` is a reference class? E.g. a `boolean` selector is incompatible with `String`.

`(selectorType == boolean.class && caseLabel != boolean.class && caseLabel != Boolean.class)` -> true so it is not a valid pair. Do you think it is wrong?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2086329296

From shade at openjdk.org  Tue May 13 09:16:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 May 2025 09:16:56 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v4]
In-Reply-To: <YoHw-NBBOF6dHnbNX2nlxarBy1jnHdHUhuSEZlcSp_k=.536fcce1-7010-461f-a934-52505f473170@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
 <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
 <YoHw-NBBOF6dHnbNX2nlxarBy1jnHdHUhuSEZlcSp_k=.536fcce1-7010-461f-a934-52505f473170@github.com>
Message-ID: <SDkQonj1CXwsIBXyyO_M3mYj25kA3ya9nhDa4Fw-Y7M=.a2776cde-7544-4972-89c0-d289838ad714@github.com>

On Tue, 6 May 2025 10:51:14 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Add bug ID
>>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>>  - Pull message into a field
>>  - Test cases
>>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>>  - Initial fix
>>    
>>    Good spawnhelper failure message
>>    
>>    Trying tests
>>    
>>    Print helper message on all IOExceptions
>>    
>>    Final
>
> src/java.base/unix/native/libjava/ProcessImpl_md.c line 377:
> 
>> 375:       throwIOExceptionImpl(env, errnum, defaultDetail, "");
>> 376:   }
>> 377: }
> 
> Why only for POSIX_SPAWN? We use jspawnhelper also for fork/vfork+exec.

Er? This is news to me. Where do you see this? I see we only pass the `helperpath` (carrying `jspawnhelper` path only to `POSIX_SPAWN` mode:


static pid_t
startChild(JNIEnv *env, jobject process, ChildStuff *c, const char *helperpath) {
    switch (c->mode) {
/* vfork(2) is deprecated on Darwin*/
      #ifndef __APPLE__
      case MODE_VFORK:
        return vforkChild(c);
      #endif
      case MODE_FORK:
        return forkChild(c);
      case MODE_POSIX_SPAWN:
        return spawnChild(env, process, c, helperpath);
      default:
        return -1;
    }
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2086328349

From abimpoudis at openjdk.org  Tue May 13 09:16:54 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 13 May 2025 09:16:54 GMT
Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used
 outside the compiler
In-Reply-To: <tKZ73v7oP5r5MvRUIcg-8wy8w6k_KX-Gd4B3cfxAPnk=.9ffd9314-39ef-4ccf-8ab9-ff0802a79f0f@github.com>
References: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
 <tKZ73v7oP5r5MvRUIcg-8wy8w6k_KX-Gd4B3cfxAPnk=.9ffd9314-39ef-4ccf-8ab9-ff0802a79f0f@github.com>
Message-ID: <XtHrPjjFTAXZWRxy5I6kTUTcaO4LwG_gfoVHwbY_DSg=.28788347-83d5-4559-9401-052e42362e74@github.com>

On Sun, 11 May 2025 21:45:46 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation.
>> 
>> For example this is not valid Java (and protected) by javac:
>> 
>> 
>> byte b = 1;
>> switch (b) {
>>     case String s -> System.out.println("How did we get here? byte is " + s.getClass());
>> }
>> 
>> 
>> but this is a valid call (and not protected):
>> 
>> 
>> CallSite shortSwitch = SwitchBootstraps.typeSwitch(
>>     MethodHandles.lookup(), 
>>     "", 
>>     MethodType.methodType(int.class, short.class, int.class),  // models (short, int) -> int
>>     String.class);
>> 
>> 
>> The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. 
>> 
>> This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 782:
> 
>> 780:         else if (selectorType.equals(targetType) ||
>> 781:                 (targetType.isPrimitive() && selectorType.isPrimitive() &&
>> 782:                     ((selectorType.equals(byte.class) && !targetType.equals(char.class)) ||
> 
> Will `unconditionalExactnessMatch(byte.class, boolean.class` return `true`? I think it shouldn't, even if `isNotValidPair` is called before.

`unconditionalExactnessMatch` needs to return an answer whether a pair is unconditional assuming it is applicable. Fusing them would need to elaborate the type of the returned answer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2086329089

From shade at openjdk.org  Tue May 13 09:23:10 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 May 2025 09:23:10 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v4]
In-Reply-To: <YoHw-NBBOF6dHnbNX2nlxarBy1jnHdHUhuSEZlcSp_k=.536fcce1-7010-461f-a934-52505f473170@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
 <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
 <YoHw-NBBOF6dHnbNX2nlxarBy1jnHdHUhuSEZlcSp_k=.536fcce1-7010-461f-a934-52505f473170@github.com>
Message-ID: <2_ZJ4felyiQJG0af-znFqWwU0DPFohr6hN7duZn7Rqs=.37dfe269-aad6-429c-a068-8576a0e84977@github.com>

On Tue, 6 May 2025 10:56:54 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Add bug ID
>>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>>  - Pull message into a field
>>  - Test cases
>>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>>  - Initial fix
>>    
>>    Good spawnhelper failure message
>>    
>>    Trying tests
>>    
>>    Print helper message on all IOExceptions
>>    
>>    Final
>
> src/java.base/unix/native/libjava/ProcessImpl_md.c line 348:
> 
>> 346:     }
>> 347:     /* ASCII Decimal representation uses 2.4 times as many bits as binary. */
>> 348:     fmtsize = sizeof(IOE_FORMAT) + strlen(internalErrorDetail) + strlen(detail) + 3 * sizeof(errnum);
> 
> Suggestion:
> 
>     fmtsize = sizeof(IOE_FORMAT) + 3 * sizeof(errnum) + strlen(detail) +  strlen(internalErrorDetail) + 1;
> 
> ... just to appease my OCD.

Right. Will be done in new commit.

> src/java.base/unix/native/libjava/ProcessImpl_md.c line 351:
> 
>> 349:     errmsg = NEW(char, fmtsize);
>> 350:     if (errmsg == NULL)
>> 351:         return;
> 
> Preexisting: seems to be weird to just quietly swallow the allocation error.

Yes. I am guessing the allocation error here means we are likely unable to allocate the `IOException` later on. History shows this check was added by JDK-8008118 -- and it looks only to please the static analysis tools. So I left this unchanged.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2086340557
PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2086340234

From abimpoudis at openjdk.org  Tue May 13 09:25:11 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 13 May 2025 09:25:11 GMT
Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used
 outside the compiler [v2]
In-Reply-To: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
References: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
Message-ID: <WqGkHWw4OavDqdPr152XyyVmPcjdaLwRI-RIq1My5UI=.60366643-be05-47dc-a89f-599b215b9bbd@github.com>

> While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation.
> 
> For example this is not valid Java (and protected) by javac:
> 
> 
> byte b = 1;
> switch (b) {
>     case String s -> System.out.println("How did we get here? byte is " + s.getClass());
> }
> 
> 
> but this is a valid call (and not protected):
> 
> 
> CallSite shortSwitch = SwitchBootstraps.typeSwitch(
>     MethodHandles.lookup(), 
>     "", 
>     MethodType.methodType(int.class, short.class, int.class),  // models (short, int) -> int
>     String.class);
> 
> 
> The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. 
> 
> This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton.

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Add test for boolean selector and String case label

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25090/files
  - new: https://git.openjdk.org/jdk/pull/25090/files/835fb6ab..7b030bee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25090&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25090&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25090.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25090/head:pull/25090

PR: https://git.openjdk.org/jdk/pull/25090

From abimpoudis at openjdk.org  Tue May 13 09:25:12 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 13 May 2025 09:25:12 GMT
Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used
 outside the compiler [v2]
In-Reply-To: <Um0llRWhZJJbcFXvLDgJ4sz7e87tat7L8i6Y2Lk-PuU=.3b2f3d0e-c64c-4ccf-abf8-52cba8d7d72d@github.com>
References: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
 <Z6edQzqZJOW0plvUyTl6J5FxLgcbEsKDf0bKi5PCflg=.78f6180e-fb77-4507-a578-8cca193d8894@github.com>
 <Um0llRWhZJJbcFXvLDgJ4sz7e87tat7L8i6Y2Lk-PuU=.3b2f3d0e-c64c-4ccf-abf8-52cba8d7d72d@github.com>
Message-ID: <YZEI4jjxXVotcDvk-eiSvYHnP0Z2ISX_h1d4GAeKS8U=.7797a5f2-4a73-4c84-80e5-b3f12decfbad@github.com>

On Tue, 13 May 2025 09:14:28 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 725:
>> 
>>> 723: 
>>> 724:     private static boolean isNotValidPair(Class<?> selectorType, Object caseLabel) {
>>> 725:         return (selectorType == boolean.class && caseLabel != boolean.class && caseLabel != Boolean.class) ||
>> 
>> What happens if `caseLabel` is a reference class? E.g. a `boolean` selector is incompatible with `String`.
>
> `(selectorType == boolean.class && caseLabel != boolean.class && caseLabel != Boolean.class)` -> true so it is not a valid pair. Do you think it is wrong?

e.g., https://github.com/openjdk/jdk/pull/25090/commits/7b030bee3e23206c030970f6c24be3bcb5241361

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2086343743

From abimpoudis at openjdk.org  Tue May 13 09:56:31 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 13 May 2025 09:56:31 GMT
Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used
 outside the compiler [v3]
In-Reply-To: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
References: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
Message-ID: <cbTTjOpj_o-DygYlZWeN74wFETw3RFWawy_xGk2T9Qk=.d74b62b8-eb54-4120-81e3-e7fa7c7411f3@github.com>

> While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation.
> 
> For example this is not valid Java (and protected) by javac:
> 
> 
> byte b = 1;
> switch (b) {
>     case String s -> System.out.println("How did we get here? byte is " + s.getClass());
> }
> 
> 
> but this is a valid call (and not protected):
> 
> 
> CallSite shortSwitch = SwitchBootstraps.typeSwitch(
>     MethodHandles.lookup(), 
>     "", 
>     MethodType.methodType(int.class, short.class, int.class),  // models (short, int) -> int
>     String.class);
> 
> 
> The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. 
> 
> This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton.

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Simplify unconditional exactness in both Types and SwitchBootstraps

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25090/files
  - new: https://git.openjdk.org/jdk/pull/25090/files/7b030bee..a7c4e398

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25090&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25090&range=01-02

  Stats: 15 lines in 2 files changed: 0 ins; 5 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25090.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25090/head:pull/25090

PR: https://git.openjdk.org/jdk/pull/25090

From abimpoudis at openjdk.org  Tue May 13 09:58:52 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 13 May 2025 09:58:52 GMT
Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used
 outside the compiler [v3]
In-Reply-To: <Z6edQzqZJOW0plvUyTl6J5FxLgcbEsKDf0bKi5PCflg=.78f6180e-fb77-4507-a578-8cca193d8894@github.com>
References: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
 <Z6edQzqZJOW0plvUyTl6J5FxLgcbEsKDf0bKi5PCflg=.78f6180e-fb77-4507-a578-8cca193d8894@github.com>
Message-ID: <k1DtPVi2xBMYbYetj35T4L8jULr6uyUUzvreLKFx1dY=.86a83430-87ed-4512-8f75-87b53497f770@github.com>

On Mon, 12 May 2025 09:15:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify unconditional exactness in both Types and SwitchBootstraps
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 786:
> 
>> 784:                      (selectorType.equals(char.class)  && (selectorWrapper.isStrictSubRangeOf(targetWrapper)))  ||
>> 785:                      (selectorType.equals(int.class)   && (targetType.equals(double.class) || targetType.equals(long.class))) ||
>> 786:                      (selectorType.equals(float.class) && (selectorWrapper.isStrictSubRangeOf(targetWrapper)))))) return true;
> 
> Is `double` the only allowed target for `float` ? If so, perhaps we could simplify like for other selector types.
> Or, alternatively, I wonder if it wouldn't be simpler to _always_ check for strict subrange on the wrappers, but then ban the conversions that are not exact (e.g. int -> float), as those are few?

Thanks @mcimadamore. I gave it a shot, despite the fact that it touches the mirrored code in Types because it is a good recommendation. But please take a look again since it is a very central part: https://github.com/openjdk/jdk/pull/25090/commits/a7c4e398f2a163083853a2a6e58a97d6a06d592f

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2086413064

From shade at openjdk.org  Tue May 13 10:30:14 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 May 2025 10:30:14 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v5]
In-Reply-To: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
Message-ID: <bpJt9PjA94QvUxfVv-hO-UdDvEUG-VMeeRGFpQZQalM=.e9d2bb18-1d47-43eb-995c-42659ae4d5a9@github.com>

> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong.
> 
> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. 
> 
> I am very open to bike-shedding about the actual message :)
> 
> Additional testing:
>  - [x] Ad-hoc experiments with breaking jspawnhelper
>  - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder`

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - Print error decoding
 - Touch up formatting message
 - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
 - Add bug ID
 - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
 - Pull message into a field
 - Test cases
 - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
 - Initial fix
   
   Good spawnhelper failure message
   
   Trying tests
   
   Print helper message on all IOExceptions
   
   Final

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24149/files
  - new: https://git.openjdk.org/jdk/pull/24149/files/74ddf9af..254f7f88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24149&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24149&range=03-04

  Stats: 38080 lines in 1284 files changed: 25679 ins; 7079 del; 5322 mod
  Patch: https://git.openjdk.org/jdk/pull/24149.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24149/head:pull/24149

PR: https://git.openjdk.org/jdk/pull/24149

From shade at openjdk.org  Tue May 13 10:30:17 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 May 2025 10:30:17 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v4]
In-Reply-To: <YoHw-NBBOF6dHnbNX2nlxarBy1jnHdHUhuSEZlcSp_k=.536fcce1-7010-461f-a934-52505f473170@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
 <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
 <YoHw-NBBOF6dHnbNX2nlxarBy1jnHdHUhuSEZlcSp_k=.536fcce1-7010-461f-a934-52505f473170@github.com>
Message-ID: <GnxCynAEyPCc5KZC225vIZQKmpzTRhcbrAfbYDXuu8o=.40b03034-3777-4d62-b939-d4e27791a800@github.com>

On Tue, 6 May 2025 11:23:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Add bug ID
>>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>>  - Pull message into a field
>>  - Test cases
>>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>>  - Initial fix
>>    
>>    Good spawnhelper failure message
>>    
>>    Trying tests
>>    
>>    Print helper message on all IOExceptions
>>    
>>    Final
>
> src/java.base/unix/native/libjava/ProcessImpl_md.c line 346:
> 
>> 344:         if (ret != EINVAL)
>> 345:             detail = tmpbuf;
>> 346:     }
> 
> Pre-existing, possibly as follow-up: 
> 
> I wonder whether we can do more. I don't like how we either only print out the errno string, or only print out the "Default" detail (I don't like the "default" prefix since it's really useful context information about this errno). 
> 
> For a problem on this side, we mostly pass in errno, then swallow the "defaultdetail". E.g. for posix_spawn failure, we'd print e.g. "12:Out of memory\nPossible reasons: ... " (or whatever localized string strerror returns).
> 
> For errors that happen inside the jspawnhelper (see line 790ff where we pass 0 for the errno), we print out "0:Bad code from spawn helper\nPossible reasons: ... ", so we swallow the errno we got from the jspawnhelper.
> 
> Could we print out instead the default, then the errno string, then the Possible reasons text? E.g.
> "posix_spawn failed (12:Out of memory)\nPossible reasons: ..."
> or
> "Bad code from spawn helper (12:Out of memory)\nPossible reasons: ..." 
> 
> There is an issue of errnum values from the far side possibly intersecting with valid errno. Could be solved simply by assigning negative values to ERR_MALLOC, ERR_PIPE and ERR_ARGS. I am not aware of any errno values being negative. The errno printing would need to recognise these three values in addition to errno values. We also could remove the +3 workaround in the test.
> 
> The only argument I see against is some vague form of backward compatibility, in case people get confused about the new information, or that existing tools parse this output.

Yeah, I dislike `defaultDetail` naming and the fact we swallow it. I see good reason to print it unconditionally. I think we can do this with just a little code massaging. See new commit. It prints the message like:


Recursively executing 'JspawnhelperProtocol simulateCrashInChild4'
posix_spawn:0
java.io.IOException: Cannot run program "pwd": Failed to exec spawn helper: pid: 1405770, exit code: 4, error: 0 (none) 
Possible reasons:
  - Spawn helper ran into JDK version mismatch
  - Spawn helper ran into unexpected internal error
  - Spawn helper was terminated by another process
Possible solutions:
  - Restart JVM, especially after in-place JDK updates
  - Check system logs for JDK-related errors
  - Re-install JDK to fix permission/versioning problems
  - Switch to legacy launch mechanism with -Djdk.lang.Process.launchMechanism=VFORK

	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1044)
	at java.base/java.lang.Runtime.exec(Runtime.java:605)
	at java.base/java.lang.Runtime.exec(Runtime.java:470)
	at JspawnhelperProtocol.parentCode(JspawnhelperProtocol.java:58)
	at JspawnhelperProtocol.main(JspawnhelperProtocol.java:232)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2086480179

From duke at openjdk.org  Tue May 13 10:33:33 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 13 May 2025 10:33:33 GMT
Subject: RFR: 8077587: BigInteger Roots [v11]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <MHA-OHflGJxnK3zEqdF4FFvkbwPgUmCEZdVg7-3CxWA=.ecb6309e-5dc8-4231-ac46-8067b3afe004@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Avoid needless box/unbox conversion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/8f55229f..3d8562f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From alanb at openjdk.org  Tue May 13 10:59:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 May 2025 10:59:05 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v18]
In-Reply-To: <ckd-UcxICCx3Zq-ehw1KBV7jQ3JfjX9jtZ0_DsxnlTE=.fb7f1026-cfa9-42a2-bf92-1622939a2b8d@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <ckd-UcxICCx3Zq-ehw1KBV7jQ3JfjX9jtZ0_DsxnlTE=.fb7f1026-cfa9-42a2-bf92-1622939a2b8d@github.com>
Message-ID: <MgSf88SFgz_Xjk14lqVo8avX-OzNupRGIgFmX7bjhZw=.f244aef2-2eeb-4895-b6f2-3c718cc306f0@github.com>

On Mon, 12 May 2025 23:51:19 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
> 
>  - 8354724: Attempt to further improve verbiage
>  - Merge
>  - Update src/java.base/share/classes/java/io/Reader.java
>    
>    8354724: Apply suggested changes for readAllLines.
>    
>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>  - Update src/java.base/share/classes/java/io/Reader.java
>    
>    8354724: Apply suggested changes for readAllAsString.
>    
>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>  - 8354724: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test
>  - 8354724: Fix potential NPE in test
>  - 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test
>  - 8354724: Improve test per reviewer comments
>  - 8354724: Add missing toList(), tweak verbiage; update test
>  - 8354724: Add Reader.readAllLines; test not yet updated
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/fa3173d5...1d811589

src/java.base/share/classes/java/io/Reader.java line 430:

> 428:      * <p> The behavior for the case where the reader is
> 429:      * <i>asynchronously closed</i>, or the thread interrupted during the
> 430:      * read, is highly input stream specific, and therefore not specified.

The carry over of this paragraph needs to replace "input stream" with reader (same thing in the other method).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2086530955

From alanb at openjdk.org  Tue May 13 11:10:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 May 2025 11:10:59 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v18]
In-Reply-To: <ckd-UcxICCx3Zq-ehw1KBV7jQ3JfjX9jtZ0_DsxnlTE=.fb7f1026-cfa9-42a2-bf92-1622939a2b8d@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <ckd-UcxICCx3Zq-ehw1KBV7jQ3JfjX9jtZ0_DsxnlTE=.fb7f1026-cfa9-42a2-bf92-1622939a2b8d@github.com>
Message-ID: <r312O2BHHZVTKnsKhbFYHWSYNEWY99th8b4PTsR6mqk=.7b75215f-33e2-4321-b449-af7309afe25d@github.com>

On Mon, 12 May 2025 23:51:19 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
> 
>  - 8354724: Attempt to further improve verbiage
>  - Merge
>  - Update src/java.base/share/classes/java/io/Reader.java
>    
>    8354724: Apply suggested changes for readAllLines.
>    
>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>  - Update src/java.base/share/classes/java/io/Reader.java
>    
>    8354724: Apply suggested changes for readAllAsString.
>    
>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>  - 8354724: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test
>  - 8354724: Fix potential NPE in test
>  - 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test
>  - 8354724: Improve test per reviewer comments
>  - 8354724: Add missing toList(), tweak verbiage; update test
>  - 8354724: Add Reader.readAllLines; test not yet updated
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/fea75845...1d811589

A lot of iterations and changes in direction but I think the API proposal in 1d811589 is okay. 

The method names and API docs looks fine. One thing that is missing is specifying how the 2 methods behaves when the reader is closed. Sadly, we can't do this because the base methods doesn't specify this so it becomes Reader specific.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2876052846

From rgiulietti at openjdk.org  Tue May 13 11:26:53 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 13 May 2025 11:26:53 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v10]
In-Reply-To: <fHaWPZrbjqDv5Im0ggCfbW3gX_vE6T6g7CTqGDcfZ0s=.1e81634d-abea-44bc-8139-266b958fa9ab@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
 <3i5Up4OJbfk1ytccMO66B0VtzqOS5pgMeLv7Lb_N5EE=.df0f670f-ef4f-4205-892b-cad0001ec397@github.com>
 <fHaWPZrbjqDv5Im0ggCfbW3gX_vE6T6g7CTqGDcfZ0s=.1e81634d-abea-44bc-8139-266b958fa9ab@github.com>
Message-ID: <4LHUOWN7xir23Jm2Cc356LRCZUh227lQU4HttoJtbVw=.17eb22b5-d759-4be8-bc0d-981fe75f8396@github.com>

On Tue, 13 May 2025 03:58:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed reviewer comments.
>
> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1878:
> 
>> 1876: 
>> 1877:         /*
>> 1878:          * In some places the idiom
> 
> Might be easier to read the code if this logic were refactored into a method.

Right.
I'll take this note into account in the next phase of the cleanup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22737#discussion_r2086586796

From vyazici at openjdk.org  Tue May 13 11:41:54 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 13 May 2025 11:41:54 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v6]
In-Reply-To: <VwNp5Cm91ConpVD6zzob2uwVNNf5GuUc7s6mVeefp0g=.13138944-a496-4487-b906-3eb4b69f28f7@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <VwNp5Cm91ConpVD6zzob2uwVNNf5GuUc7s6mVeefp0g=.13138944-a496-4487-b906-3eb4b69f28f7@github.com>
Message-ID: <3ey9JGc8I3CPIi98S4kUZeKAVhmMw4nohRwU3-y9MBc=.a2fef848-06e1-4c4e-bfef-0e0a53bdc6f1@github.com>

On Tue, 13 May 2025 03:15:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed an erroneous curly brace

src/java.base/share/classes/java/io/InputStreamReader.java line 59:

> 57:  *     new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
> 58:  * }
> 59:  *

There are several places in the sources that still contain `new InputStreamReader(System.in)`. Shouldn't they be replaced with `new InputStreamReader(System.in, System.getProperty("stdin.encoding"))` too?)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2086612688

From jpai at openjdk.org  Tue May 13 11:54:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 May 2025 11:54:54 GMT
Subject: RFR: 8350765: Need to pin when accessing thread container from
 virtual thread [v2]
In-Reply-To: <TDzypb6IecvtvXcVDPFKqBMCbnzjgQalYHWorlmfcYk=.b30df142-447a-4361-8d11-b28b7668a826@github.com>
References: <G5nHVCpo-Kzs-63jq0uQXFpiXqObL8sapYh-Z8gA7rk=.4fe730d0-8571-4147-81b4-0b34f57ec54e@github.com>
 <TDzypb6IecvtvXcVDPFKqBMCbnzjgQalYHWorlmfcYk=.b30df142-447a-4361-8d11-b28b7668a826@github.com>
Message-ID: <4gAZ3IXpfztVsnHnnwWt9uApLl3OGqt5fp2FpaeuSnk=.ee029f80-79b0-423c-bca1-133570a31bb0@github.com>

On Mon, 12 May 2025 14:01:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Data structures that are accessed by both virtual threads and their carriers require the virtual thread to pin the continuation to avoid potential deadlock. A deadlock can arise when a virtual thread is preempted, is selected and scheduled to be the next owner of the lock/resource, but can't execute because all carriers are blocking on the same lock/resource. There are a small number of places that need to pin. One that was missed is the the notification to the thread container when threads are started or terminate. This is not currently an issue at this time but it is a potential hazard for ongoing and future work that will add further scheduling points to the code.  Continuation.pin/unpin have intrinsics since JDK-8338745, and Continuation is initialized early in startup. Finally, the changes have been in the loom repo for several months with no issues.
>> 
>> Testing tier1-5, quick statup/footprint, noreg-hard
>
> Alan Bateman has updated the pull request with a new target base 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:
> 
>  - Fix/improve comment
>  - Merge branch 'master' into JDK-8350765
>  - Merge branch 'master' into JDK-8350765
>  - No need to used qualified name
>  - Merge branch 'master' into JDK-8350765
>  - Update
>  - Merge branch 'master' into JDK-8350765
>  - Add method to ContinuationSupport
>  - Missing /
>  - Initial commit

Thank you for the update Alan. The change looks reasonable to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23810#pullrequestreview-2836451768

From liach at openjdk.org  Tue May 13 12:32:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 May 2025 12:32:04 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
 [v4]
In-Reply-To: <yJoCuLgZ3VRFyQKOS8HuV8xE3M80Ta5MwGwkYZVtFh8=.ccea0f91-038e-4fa0-a3f1-aa626a011b7a@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
 <yJoCuLgZ3VRFyQKOS8HuV8xE3M80Ta5MwGwkYZVtFh8=.ccea0f91-038e-4fa0-a3f1-aa626a011b7a@github.com>
Message-ID: <sXFhci_fvMZwPBDXIc1alYyPZ_nsk9FCobi3dAFp68Q=.d6414292-c233-43f2-82fe-7f686a2bf579@github.com>

On Tue, 13 May 2025 07:57:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
>> 
>> Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example.
>> 
>> Unfortunately, this PR shows the total commit history for stable values.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

The latest change set looks fine.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25004#pullrequestreview-2836572592

From jpai at openjdk.org  Tue May 13 12:35:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 May 2025 12:35:58 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: <oa3a1r5ufXR_UsMRudd9pdfEVwTDNWT04sNBcnxX-cs=.4639f165-00f3-4f4d-a3dc-465ef7935d83@github.com>

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 147:

> 145:     // this could exist somewhere common, but if it's definitely never going to
> 146:     // be shared, it could be made public here.
> 147:     private enum AccessMode {

Hello David, I think having it `private` is fine and in fact more appropriate. I would suggest removing the comment though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2086711632

From liach at openjdk.org  Tue May 13 12:36:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 May 2025 12:36:53 GMT
Subject: RFR: 8354076: LinkedBlockingDeque offer() creates nodes even if
 capacity has been reached
In-Reply-To: <B25P1OYOnE91pRMJ9q_3hr6B_UIFlgd11CdPrDYD83Q=.966b35db-55b1-4a54-9190-bbfcf3c00d8f@github.com>
References: <B25P1OYOnE91pRMJ9q_3hr6B_UIFlgd11CdPrDYD83Q=.966b35db-55b1-4a54-9190-bbfcf3c00d8f@github.com>
Message-ID: <e7ZdhVaRtJrnH3KpfdpvJS9kcmsd3j5F1xazpkqW4SI=.9fcaa5cf-7a69-41ec-97ef-9000592a8c4a@github.com>

On Tue, 8 Apr 2025 18:39:30 GMT, kabutz <duke at openjdk.org> 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()

@viktorklang-ora Is it possible for you to take a look at this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24521#issuecomment-2876335323

From liach at openjdk.org  Tue May 13 12:36:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 May 2025 12:36:58 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v6]
In-Reply-To: <3ey9JGc8I3CPIi98S4kUZeKAVhmMw4nohRwU3-y9MBc=.a2fef848-06e1-4c4e-bfef-0e0a53bdc6f1@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <VwNp5Cm91ConpVD6zzob2uwVNNf5GuUc7s6mVeefp0g=.13138944-a496-4487-b906-3eb4b69f28f7@github.com>
 <3ey9JGc8I3CPIi98S4kUZeKAVhmMw4nohRwU3-y9MBc=.a2fef848-06e1-4c4e-bfef-0e0a53bdc6f1@github.com>
Message-ID: <zE3BSueBiyvogX6S7fMMSUoe7bn5NTMf11_kH39xfLw=.5630b3f0-1178-4d54-a905-b02863ae8a85@github.com>

On Tue, 13 May 2025 11:39:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed an erroneous curly brace
>
> src/java.base/share/classes/java/io/InputStreamReader.java line 59:
> 
>> 57:  *     new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
>> 58:  * }
>> 59:  *
> 
> There are several places in the sources that still contain `new InputStreamReader(System.in)`. Shouldn't they be replaced with `new InputStreamReader(System.in, System.getProperty("stdin.encoding"))` too?)

How did you search for those sources? I searched for literal `System.in` and my comments are the only ones I could find in the JDK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2086713392

From vklang at openjdk.org  Tue May 13 12:46:57 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 13 May 2025 12:46:57 GMT
Subject: RFR: 8354076: LinkedBlockingDeque offer() creates nodes even if
 capacity has been reached
In-Reply-To: <e7ZdhVaRtJrnH3KpfdpvJS9kcmsd3j5F1xazpkqW4SI=.9fcaa5cf-7a69-41ec-97ef-9000592a8c4a@github.com>
References: <B25P1OYOnE91pRMJ9q_3hr6B_UIFlgd11CdPrDYD83Q=.966b35db-55b1-4a54-9190-bbfcf3c00d8f@github.com>
 <e7ZdhVaRtJrnH3KpfdpvJS9kcmsd3j5F1xazpkqW4SI=.9fcaa5cf-7a69-41ec-97ef-9000592a8c4a@github.com>
Message-ID: <Ztd0UoaO47l62lbiqf89AvboeYVq-ewzlGsN1KTYlLk=.27e32d0b-e3d5-4dd6-ba42-6cbdd59c2faa@github.com>

On Tue, 13 May 2025 12:34:38 GMT, Chen Liang <liach at openjdk.org> 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()
>
> @viktorklang-ora Is it possible for you to take a look at this?

@liach This PR should be closed, it's superseded by https://github.com/openjdk/jdk/pull/24925

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24521#issuecomment-2876363296

From jpai at openjdk.org  Tue May 13 12:46:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 May 2025 12:46:59 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: <UqTwrOhdX6qNfNgqy995eaemSHRp86Z4T3FMFopK9z8=.10444401-1684-4493-8ccf-c63f01a30b9e@github.com>

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

src/jdk.zipfs/share/classes/module-info.java line 277:

> 275:  *   <td>
> 276:  *       A value defining the desired read/write access mode of the file system
> 277:  *       (either <em>read-write</em> or <em>read-only</em>).

This line is slightly confusing. Initially I thought `read-write` and `read-only` are the actual values that this environment property will accept. But further review suggests that the actual literals supported are `readOnly` and `readWrite` and this line here I think is trying to explain the supported semantics of the file system.

Perhaps we could reword this to something like:

>
> A value defining the desired access mode of the file system. A ZIP file system can be created to allow for read-write access or read-only access.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2086732377

From vklang at openjdk.org  Tue May 13 12:46:56 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 13 May 2025 12:46:56 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <fT_4bHAK3fI6N5eRE7LgQ7FMt6o9C3WgTpfEh0ZbDkE=.579c1c92-0173-4f85-b7ff-83cbdf05b630@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com>
 <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com>
 <YhkDQaU0FTyyP_42JTmUxM5x97rwSAHQbVYPJxRv3cI=.d70127c6-4f45-48b4-8b6c-eebad4084a34@github.com>
 <fT_4bHAK3fI6N5eRE7LgQ7FMt6o9C3WgTpfEh0ZbDkE=.579c1c92-0173-4f85-b7ff-83cbdf05b630@github.com>
Message-ID: <LyZhpoeP4NnTHa0mSzdcRfEdvrtb3nvJST8yCz62XDo=.327dd96c-ab3a-4251-a7bd-8a23b92b2731@github.com>

On Wed, 7 May 2025 17:01:29 GMT, kabutz <duke at openjdk.org> wrote:

> > @kabutz I think @AlanBateman might be able to have a look as well.
> > As for timing, it seems to me most reasonable if this PR (if it is to be integrated) to go in _after_ JDK25 has been forked, to give enough time for JDK26 early access feedback and giving the changes time to harden. I hope that makes sense.
> 
> That sound reasonable. When would this be?

About a month or so.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2876366432

From stuefe at openjdk.org  Tue May 13 12:50:08 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 13 May 2025 12:50:08 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v4]
In-Reply-To: <SDkQonj1CXwsIBXyyO_M3mYj25kA3ya9nhDa4Fw-Y7M=.a2776cde-7544-4972-89c0-d289838ad714@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
 <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
 <YoHw-NBBOF6dHnbNX2nlxarBy1jnHdHUhuSEZlcSp_k=.536fcce1-7010-461f-a934-52505f473170@github.com>
 <SDkQonj1CXwsIBXyyO_M3mYj25kA3ya9nhDa4Fw-Y7M=.a2776cde-7544-4972-89c0-d289838ad714@github.com>
Message-ID: <9qD9glLPCTy_6ium5mvzyjhZ56COlEOKz4AhzvGmhrg=.ff5d52e1-84a1-413c-aac0-873fdcbfa5ff@github.com>

On Tue, 13 May 2025 09:13:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/unix/native/libjava/ProcessImpl_md.c line 377:
>> 
>>> 375:       throwIOExceptionImpl(env, errnum, defaultDetail, "");
>>> 376:   }
>>> 377: }
>> 
>> Why only for POSIX_SPAWN? We use jspawnhelper also for fork/vfork+exec.
>
> Er? This is news to me. Where do you see this? I see we only pass the `helperpath` (carrying `jspawnhelper` path only to `POSIX_SPAWN` mode:
> 
> 
> static pid_t
> startChild(JNIEnv *env, jobject process, ChildStuff *c, const char *helperpath) {
>     switch (c->mode) {
> /* vfork(2) is deprecated on Darwin*/
>       #ifndef __APPLE__
>       case MODE_VFORK:
>         return vforkChild(c);
>       #endif
>       case MODE_FORK:
>         return forkChild(c);
>       case MODE_POSIX_SPAWN:
>         return spawnChild(env, process, c, helperpath);
>       default:
>         return -1;
>     }
> }

You are right and I am confused. I always assumed that the primary function of jspawnhelper was to make vfork safe. Historically, that was the typical reason for an intermediate exec() to a helper - basically, you first exec() the helper as quickly as possible to get your own process memory. Then you do all the things you need to do in preparation for the final exec(), then exec again.

I am surprised that this has worked with vfork() so flawlessly all this time. Maybe it didn't; maybe the libc's have all internally replaced vfork() with fork(), since fork() is fast enough nowadays.

I actually don't understand why the jspawnhelper is even needed for posix_spawn, since all the things one does in jspawnhelper can be done also via posix_spawn process attributes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2086739029

From stuefe at openjdk.org  Tue May 13 12:56:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 13 May 2025 12:56:54 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v5]
In-Reply-To: <bpJt9PjA94QvUxfVv-hO-UdDvEUG-VMeeRGFpQZQalM=.e9d2bb18-1d47-43eb-995c-42659ae4d5a9@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
 <bpJt9PjA94QvUxfVv-hO-UdDvEUG-VMeeRGFpQZQalM=.e9d2bb18-1d47-43eb-995c-42659ae4d5a9@github.com>
Message-ID: <ifFz_WAGDE1Ricmi8D4XH2bN6ZwjN20FbWgeqXVQqEA=.de030c83-fd4c-4aa5-9a7d-c147fc183ce6@github.com>

On Tue, 13 May 2025 10:30:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong.
>> 
>> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. 
>> 
>> I am very open to bike-shedding about the actual message :)
>> 
>> Additional testing:
>>  - [x] Ad-hoc experiments with breaking jspawnhelper
>>  - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Print error decoding
>  - Touch up formatting message
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Add bug ID
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Pull message into a field
>  - Test cases
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Initial fix
>    
>    Good spawnhelper failure message
>    
>    Trying tests
>    
>    Print helper message on all IOExceptions
>    
>    Final

Looks good to me now.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24149#pullrequestreview-2836654880

From stuefe at openjdk.org  Tue May 13 12:56:56 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 13 May 2025 12:56:56 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v4]
In-Reply-To: <GnxCynAEyPCc5KZC225vIZQKmpzTRhcbrAfbYDXuu8o=.40b03034-3777-4d62-b939-d4e27791a800@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
 <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
 <YoHw-NBBOF6dHnbNX2nlxarBy1jnHdHUhuSEZlcSp_k=.536fcce1-7010-461f-a934-52505f473170@github.com>
 <GnxCynAEyPCc5KZC225vIZQKmpzTRhcbrAfbYDXuu8o=.40b03034-3777-4d62-b939-d4e27791a800@github.com>
Message-ID: <nUC01DtECmpCcqHy1UvZ3c0uYFHDXVh_978TFAE_P3A=.fe4cd6d1-7865-4127-8052-fd65fafd8b49@github.com>

On Tue, 13 May 2025 10:26:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/unix/native/libjava/ProcessImpl_md.c line 346:
>> 
>>> 344:         if (ret != EINVAL)
>>> 345:             detail = tmpbuf;
>>> 346:     }
>> 
>> Pre-existing, possibly as follow-up: 
>> 
>> I wonder whether we can do more. I don't like how we either only print out the errno string, or only print out the "Default" detail (I don't like the "default" prefix since it's really useful context information about this errno). 
>> 
>> For a problem on this side, we mostly pass in errno, then swallow the "defaultdetail". E.g. for posix_spawn failure, we'd print e.g. "12:Out of memory\nPossible reasons: ... " (or whatever localized string strerror returns).
>> 
>> For errors that happen inside the jspawnhelper (see line 790ff where we pass 0 for the errno), we print out "0:Bad code from spawn helper\nPossible reasons: ... ", so we swallow the errno we got from the jspawnhelper.
>> 
>> Could we print out instead the default, then the errno string, then the Possible reasons text? E.g.
>> "posix_spawn failed (12:Out of memory)\nPossible reasons: ..."
>> or
>> "Bad code from spawn helper (12:Out of memory)\nPossible reasons: ..." 
>> 
>> There is an issue of errnum values from the far side possibly intersecting with valid errno. Could be solved simply by assigning negative values to ERR_MALLOC, ERR_PIPE and ERR_ARGS. I am not aware of any errno values being negative. The errno printing would need to recognise these three values in addition to errno values. We also could remove the +3 workaround in the test.
>> 
>> The only argument I see against is some vague form of backward compatibility, in case people get confused about the new information, or that existing tools parse this output.
>
> Yeah, I dislike `defaultDetail` naming and the fact we swallow it. I see good reason to print it unconditionally. I think we can do this with just a little code massaging. See new commit. It prints the message like:
> 
> 
> Recursively executing 'JspawnhelperProtocol simulateCrashInChild4'
> posix_spawn:0
> java.io.IOException: Cannot run program "pwd": Failed to exec spawn helper: pid: 1405770, exit code: 4, error: 0 (none) 
> Possible reasons:
>   - Spawn helper ran into JDK version mismatch
>   - Spawn helper ran into unexpected internal error
>   - Spawn helper was terminated by another process
> Possible solutions:
>   - Restart JVM, especially after in-place JDK updates
>   - Check system logs for JDK-related errors
>   - Re-install JDK to fix permission/versioning problems
>   - Switch to legacy launch mechanism with -Djdk.lang.Process.launchMechanism=VFORK
> 
> 	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110)
> 	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1044)
> 	at java.base/java.lang.Runtime.exec(Runtime.java:605)
> 	at java.base/java.lang.Runtime.exec(Runtime.java:470)
> 	at JspawnhelperProtocol.parentCode(JspawnhelperProtocol.java:58)
> 	at JspawnhelperProtocol.main(JspawnhelperProtocol.java:232)

I like this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2086751118

From stuefe at openjdk.org  Tue May 13 12:56:56 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 13 May 2025 12:56:56 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v4]
In-Reply-To: <9qD9glLPCTy_6ium5mvzyjhZ56COlEOKz4AhzvGmhrg=.ff5d52e1-84a1-413c-aac0-873fdcbfa5ff@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
 <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
 <YoHw-NBBOF6dHnbNX2nlxarBy1jnHdHUhuSEZlcSp_k=.536fcce1-7010-461f-a934-52505f473170@github.com>
 <SDkQonj1CXwsIBXyyO_M3mYj25kA3ya9nhDa4Fw-Y7M=.a2776cde-7544-4972-89c0-d289838ad714@github.com>
 <9qD9glLPCTy_6ium5mvzyjhZ56COlEOKz4AhzvGmhrg=.ff5d52e1-84a1-413c-aac0-873fdcbfa5ff@github.com>
Message-ID: <l8DneNJ4KUmd_8M5VhnbbMN27lVUao1mKrzZ28oeGGI=.acefca04-d2e0-465e-8168-5ccc2f16daca@github.com>

On Tue, 13 May 2025 12:47:39 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Er? This is news to me. Where do you see this? I see we only pass the `helperpath` (carrying `jspawnhelper` path only to `POSIX_SPAWN` mode:
>> 
>> 
>> static pid_t
>> startChild(JNIEnv *env, jobject process, ChildStuff *c, const char *helperpath) {
>>     switch (c->mode) {
>> /* vfork(2) is deprecated on Darwin*/
>>       #ifndef __APPLE__
>>       case MODE_VFORK:
>>         return vforkChild(c);
>>       #endif
>>       case MODE_FORK:
>>         return forkChild(c);
>>       case MODE_POSIX_SPAWN:
>>         return spawnChild(env, process, c, helperpath);
>>       default:
>>         return -1;
>>     }
>> }
>
> You are right and I am confused. I always assumed that the primary function of jspawnhelper was to make vfork safe. Historically, that was the typical reason for an intermediate exec() to a helper - basically, you first exec() the helper as quickly as possible to get your own process memory. Then you do all the things you need to do in preparation for the final exec(), then exec again.
> 
> I am surprised that this has worked with vfork() so flawlessly all this time. Maybe it didn't; maybe the libc's have all internally replaced vfork() with fork(), since fork() is fast enough nowadays.
> 
> I actually don't understand why the jspawnhelper is even needed for posix_spawn, since all the things one does in jspawnhelper can be done also via posix_spawn process attributes.

Hmm, glibc keeps it very vague in the vfork() manpage, stating that "On some implementations, vfork() is equivalent to fork()." AIX manpage says just "The vfork subroutine is supported as a compatibility interface for older Berkeley Software Distribution (BSD) system programs" which sounds to me its just an alias for fork(). MacOS has no vfork anymore.

So maybe Solaris was the last platform with a true vfork.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2086748837

From duke at openjdk.org  Tue May 13 12:59:58 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 13 May 2025 12:59:58 GMT
Subject: RFR: 8354138: LinkedBlockingDeque allows us to exceed size with
 addAll()
In-Reply-To: <HtBn3CW9qWjshxxqnpOLRVuWf87SxZWNLifJK-B1ASg=.3e88d405-a23c-4e2d-b49c-fd6e9a13f885@github.com>
References: <HtBn3CW9qWjshxxqnpOLRVuWf87SxZWNLifJK-B1ASg=.3e88d405-a23c-4e2d-b49c-fd6e9a13f885@github.com>
Message-ID: <jsOE3hprVaxXMeKIBlTeAv_ZKt7UZfdQ3Rx4u6SoSQw=.30ebb963-d05e-448d-9d0d-1b2c7a70a99b@github.com>

On Wed, 9 Apr 2025 06:24:30 GMT, kabutz <duke at openjdk.org> 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<Integer> 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<Integer> {
>         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<Integer> iterator() {
>             return new Iterator<Integer>() {
>                 private long count = 0;
> 
>                 public boolean hasNext() {
>                     return count < size;
>                 }
> 
>                 public Integer next() {
>                     if (!hasNext()) throw new NoSuchElementException();
>                     count++;
>                     return 42;
>   ...

These changes have been included in https://github.com/openjdk/jdk/pull/24925

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24538#issuecomment-2876405630

From duke at openjdk.org  Tue May 13 12:59:58 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 13 May 2025 12:59:58 GMT
Subject: Withdrawn: 8354138: LinkedBlockingDeque allows us to exceed size with
 addAll()
In-Reply-To: <HtBn3CW9qWjshxxqnpOLRVuWf87SxZWNLifJK-B1ASg=.3e88d405-a23c-4e2d-b49c-fd6e9a13f885@github.com>
References: <HtBn3CW9qWjshxxqnpOLRVuWf87SxZWNLifJK-B1ASg=.3e88d405-a23c-4e2d-b49c-fd6e9a13f885@github.com>
Message-ID: <6-uiOxLuI3xXGxOgHoN6TwdrQaOyaJqGeYPh1ljvbF0=.77bc6b9b-cdbb-4cf7-99c8-e48f3e7daef6@github.com>

On Wed, 9 Apr 2025 06:24:30 GMT, kabutz <duke at openjdk.org> 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<Integer> 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<Integer> {
>         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<Integer> iterator() {
>             return new Iterator<Integer>() {
>                 private long count = 0;
> 
>                 public boolean hasNext() {
>                     return count < size;
>                 }
> 
>                 public Integer next() {
>                     if (!hasNext()) throw new NoSuchElementException();
>                     count++;
>                     return 42;
>   ...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24538

From duke at openjdk.org  Tue May 13 13:01:21 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 13 May 2025 13:01:21 GMT
Subject: RFR: 8354076: LinkedBlockingDeque offer() creates nodes even if
 capacity has been reached
In-Reply-To: <B25P1OYOnE91pRMJ9q_3hr6B_UIFlgd11CdPrDYD83Q=.966b35db-55b1-4a54-9190-bbfcf3c00d8f@github.com>
References: <B25P1OYOnE91pRMJ9q_3hr6B_UIFlgd11CdPrDYD83Q=.966b35db-55b1-4a54-9190-bbfcf3c00d8f@github.com>
Message-ID: <sTV5-LcSM3BvRodSsBniOywwql9ge17AhaZ2N9zwgPc=.65d9e692-2f53-4659-b46f-8260eb62dfb6@github.com>

On Tue, 8 Apr 2025 18:39:30 GMT, kabutz <duke at openjdk.org> 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()

These changes have been included in https://github.com/openjdk/jdk/pull/24925

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24521#issuecomment-2876408149

From duke at openjdk.org  Tue May 13 13:01:10 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 13 May 2025 13:01:10 GMT
Subject: RFR: 8354060: LinkedBlockingDeque.clear() should preserve
 weakly-consistent iterators
In-Reply-To: <qVEdJCOrRQXV0cI6XCA6kXsNOg3qW9zEa0wasOMosNk=.fb2bcd9e-cedc-4062-a125-8140c6b1c2ad@github.com>
References: <qVEdJCOrRQXV0cI6XCA6kXsNOg3qW9zEa0wasOMosNk=.fb2bcd9e-cedc-4062-a125-8140c6b1c2ad@github.com>
Message-ID: <gubFc1JUh2vJ_jPxSemSdsASRnM4G7s92lihH_CrG1g=.860a95a4-fa39-4791-bc7e-026b51f04fbc@github.com>

On Mon, 7 Apr 2025 11:55:08 GMT, kabutz <duke at openjdk.org> wrote:

> 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.

These changes have been included in https://github.com/openjdk/jdk/pull/24925

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24488#issuecomment-2876408558

From duke at openjdk.org  Tue May 13 13:01:22 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 13 May 2025 13:01:22 GMT
Subject: Withdrawn: 8354076: LinkedBlockingDeque offer() creates nodes even if
 capacity has been reached
In-Reply-To: <B25P1OYOnE91pRMJ9q_3hr6B_UIFlgd11CdPrDYD83Q=.966b35db-55b1-4a54-9190-bbfcf3c00d8f@github.com>
References: <B25P1OYOnE91pRMJ9q_3hr6B_UIFlgd11CdPrDYD83Q=.966b35db-55b1-4a54-9190-bbfcf3c00d8f@github.com>
Message-ID: <cJeHqPxtgzeWiosznSsFgQYm4_DIFWXDQAQbn3RWPfM=.f134e36d-60c4-4778-b7b4-c7477d546b6d@github.com>

On Tue, 8 Apr 2025 18:39:30 GMT, kabutz <duke at openjdk.org> 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()

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24521

From duke at openjdk.org  Tue May 13 13:01:11 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 13 May 2025 13:01:11 GMT
Subject: Withdrawn: 8354060: LinkedBlockingDeque.clear() should preserve
 weakly-consistent iterators
In-Reply-To: <qVEdJCOrRQXV0cI6XCA6kXsNOg3qW9zEa0wasOMosNk=.fb2bcd9e-cedc-4062-a125-8140c6b1c2ad@github.com>
References: <qVEdJCOrRQXV0cI6XCA6kXsNOg3qW9zEa0wasOMosNk=.fb2bcd9e-cedc-4062-a125-8140c6b1c2ad@github.com>
Message-ID: <cHP7ZGGqm3YBeG_qlQAdJq7GaUQ0Yhc-6PiRIlvZjP8=.2a2d55a9-bf69-451a-aa21-dd2fb78cc360@github.com>

On Mon, 7 Apr 2025 11:55:08 GMT, kabutz <duke at openjdk.org> wrote:

> 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.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24488

From duke at openjdk.org  Tue May 13 13:02:16 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 13 May 2025 13:02:16 GMT
Subject: RFR: 8349543: LinkedBlockingDeque does not immediately throw
 InterrruptedException in put/take
In-Reply-To: <Da_VhZrKMVCSNPN6BSYHrYLsU3MnehmJZcI0ZJUzaJ8=.eb25a512-e279-47f4-ae14-11c965f204cd@github.com>
References: <Da_VhZrKMVCSNPN6BSYHrYLsU3MnehmJZcI0ZJUzaJ8=.eb25a512-e279-47f4-ae14-11c965f204cd@github.com>
Message-ID: <9zB863pIeHWzsHIMR9Yj_woTvMmW9f2Q0uFuEDofmhQ=.fcb3989b-a29c-4084-bde6-e5a841090c95@github.com>

On Wed, 5 Feb 2025 15:36:15 GMT, kabutz <duke at openjdk.org> wrote:

> The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down.

These changes have been included in https://github.com/openjdk/jdk/pull/24925

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23464#issuecomment-2876413837

From duke at openjdk.org  Tue May 13 13:03:42 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 13 May 2025 13:03:42 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double) [v2]
In-Reply-To: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
Message-ID: <w48C4y0RR5togk9taQZCJlUN7IazrPf6sISpGDaON9Q=.49005247-e8ee-486a-b394-b745bfe2ef46@github.com>

> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  fix code tag in javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25173/files
  - new: https://git.openjdk.org/jdk/pull/25173/files/569a6dfc..ba8d3933

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25173&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25173&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25173.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25173/head:pull/25173

PR: https://git.openjdk.org/jdk/pull/25173

From roger.riggs at oracle.com  Tue May 13 13:10:40 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 13 May 2025 09:10:40 -0400
Subject: RFC: 8356679: Using CharSequence::getChars internally
In-Reply-To: <f4330452-258c-42f8-a24b-9217da839892@headcrashing.eu>
References: <f4cf0270-eb00-4c52-99a4-8e8057bb2bc9@gmx.net>
 <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com>
 <f4330452-258c-42f8-a24b-9217da839892@headcrashing.eu>
Message-ID: <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com>

Hi Markus,

A main point was to avoid trying to do everything at once.
The PR comments become hard to follow and intermingled and it takes 
longer to get agreement because of the thrash in the PR.

Roger

On 5/13/25 5:05 AM, Markus KARG wrote:
> Thank you, Roger.
>
> Actually the method helps in the "toString()" variants, too, as in 
> some places we could *get rid* of "toString()" (which is more work 
> than "just" a buffer due to the added compression complexity).
>
> In fact, I already took the time to rewrite *all* of them while 
> waiting for the approval of this list posting. In *all* cases *less* 
> buffering / copying is needed, and *less* "toString()" conversion 
> (which is a copy under the hood) is needed. So if I would be allowed 
> to show the code as a PR, it would be much easier to explain and discuss.
>
> A PR is the best place to discuss "how to code would change". In the 
> worst case, let's drop it if we see that it is actually a bad thing.
>
> -Markus
>
>
> Am 12.05.2025 um 20:18 schrieb Roger Riggs:
>> Hi Markus,
>>
>> On the surface, its looks constructive.
>> I suspect that many of these cases will turn into discussions about 
>> the right/best/better way to buffer the characters.
>> The getChars method only helps when extracting to a char array, many 
>> of the current implementations create strings as the intermediary. 
>> The advantage of the 1 character at a time technique is not needing a 
>> (separated allocated) buffer.
>> Consider taking a few at a time before launching into the whole set.
>>
>> $.02, Roger
>>
>> On 5/11/25 2:45 AM, Markus KARG wrote:
>>> Dear Core Libs Team,
>>>
>>> I am hereby requesting comments on JDK-8356679.
>>>
>>> I would like to invest some time and set up a PR implementing Chen 
>>> Liangs's proposal laid out in 
>>> https://bugs.openjdk.org/browse/JDK-8356679. For your convenience, 
>>> the text of that JBS is copied below. According to the Developer's 
>>> Guide I do need to get broad agreement BEFORE filing a PR. 
>>> Therefore, I kindly ask everybody to briefly show consent, so I may 
>>> file a PR.
>>>
>>> Thanks
>>> -Markus
>>>
>>>
>>> Copy from https://bugs.openjdk.org/browse/JDK-8356679:
>>>
>>> Recently OpenJDK adopted the new method CharSequence::getChars(int, 
>>> int, char[], int) for inclusion in Java 25. As a bulk reader method, 
>>> it allows potentially improved efficiency over the previously 
>>> available char-by-char reader method CharSequence::charAt(int).
>>>
>>> Chen Liang suggested on March 23rd on the core-lib-dev mailing list 
>>> to use the new method within the internal source code of OpenJDK for 
>>> the implementation of Appendables (see 
>>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). 
>>> The idea behind this is that the implementations might be more 
>>> efficient then.
>>>
>>> A quick analysis of the OpenJDK source code identified (at least) 
>>> the following classes which could potentially run more efficient 
>>> when using CharSequence::getChars internally, thanks to bulk reading 
>>> and / or prevention of internal copies / toString() conversions:
>>> * java.io.Writer
>>> * java.io.StringWriter
>>> * java.io.PrintWriter
>>> * java.io.BufferedWriter
>>> * java.io.CharArrayWriter
>>> * java.io.FileWriter
>>> * java.io.OutputStreamWriter
>>> * sun.nio.cs.StreamEncoder
>>> * java.io.PrintStream
>>> * java.nio.CharBuffer
>>>
>>> In the sense of "eat your own dog food", it makes sense to implement 
>>> Chen's idea in (at least) those classes. Possibly more classes could 
>>> get identified when taking a deeper look. Besides the potential 
>>> efficiency improvements, it would be a good show case for the usage 
>>> of the new API.
>>>
>>> The risk of this change should be low, as test coverage exists, and 
>>> as the intended changes are solely internal to the implementation. 
>>> No API will get changed. In some cases the JavaDocs will get 
>>> slightly adapted where it currently exposes the actual 
>>> implementation (to not lie in future).
>>>
>>


From duke at openjdk.org  Tue May 13 13:19:59 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 13 May 2025 13:19:59 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <LyZhpoeP4NnTHa0mSzdcRfEdvrtb3nvJST8yCz62XDo=.327dd96c-ab3a-4251-a7bd-8a23b92b2731@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com>
 <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com>
 <YhkDQaU0FTyyP_42JTmUxM5x97rwSAHQbVYPJxRv3cI=.d70127c6-4f45-48b4-8b6c-eebad4084a34@github.com>
 <fT_4bHAK3fI6N5eRE7LgQ7FMt6o9C3WgTpfEh0ZbDkE=.579c1c92-0173-4f85-b7ff-83cbdf05b630@github.com>
 <LyZhpoeP4NnTHa0mSzdcRfEdvrtb3nvJST8yCz62XDo=.327dd96c-ab3a-4251-a7bd-8a23b92b2731@github.com>
Message-ID: <Zyz8nyCssvU32SJGYXRHwq6vbTUR1x5gBZmBnDYPC7Y=.97852347-7820-489c-a9b7-1d2448c5f4cc@github.com>

On Tue, 13 May 2025 12:44:38 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> About a month or so.

Perfect, thanks @viktorklang-ora. I've marked the other issues as closed - duplicates, and referenced this single umbrella PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2876484773

From vklang at openjdk.org  Tue May 13 13:27:55 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 13 May 2025 13:27:55 GMT
Subject: RFR: 8350765: Need to pin when accessing thread container from
 virtual thread [v2]
In-Reply-To: <TDzypb6IecvtvXcVDPFKqBMCbnzjgQalYHWorlmfcYk=.b30df142-447a-4361-8d11-b28b7668a826@github.com>
References: <G5nHVCpo-Kzs-63jq0uQXFpiXqObL8sapYh-Z8gA7rk=.4fe730d0-8571-4147-81b4-0b34f57ec54e@github.com>
 <TDzypb6IecvtvXcVDPFKqBMCbnzjgQalYHWorlmfcYk=.b30df142-447a-4361-8d11-b28b7668a826@github.com>
Message-ID: <DyXgVmj7vkfLWssCdS1SDaBRZ9Tw2sRS3B3CN4mwwlc=.4af6fee4-53be-4504-9e20-510d1bdcf5d9@github.com>

On Mon, 12 May 2025 14:01:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Data structures that are accessed by both virtual threads and their carriers require the virtual thread to pin the continuation to avoid potential deadlock. A deadlock can arise when a virtual thread is preempted, is selected and scheduled to be the next owner of the lock/resource, but can't execute because all carriers are blocking on the same lock/resource. There are a small number of places that need to pin. One that was missed is the the notification to the thread container when threads are started or terminate. This is not currently an issue at this time but it is a potential hazard for ongoing and future work that will add further scheduling points to the code.  Continuation.pin/unpin have intrinsics since JDK-8338745, and Continuation is initialized early in startup. Finally, the changes have been in the loom repo for several months with no issues.
>> 
>> Testing tier1-5, quick statup/footprint, noreg-hard
>
> Alan Bateman has updated the pull request with a new target base 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:
> 
>  - Fix/improve comment
>  - Merge branch 'master' into JDK-8350765
>  - Merge branch 'master' into JDK-8350765
>  - No need to used qualified name
>  - Merge branch 'master' into JDK-8350765
>  - Update
>  - Merge branch 'master' into JDK-8350765
>  - Add method to ContinuationSupport
>  - Missing /
>  - Initial commit

Nice work, Alan!

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23810#pullrequestreview-2836780689

From vklang at openjdk.org  Tue May 13 13:29:00 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 13 May 2025 13:29:00 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v13]
In-Reply-To: <OuorxBjLrAKkDp6t_zdsjDsGH33vTd7mOViD6fMjP5M=.e97b26c5-2bad-40de-abf8-8505c03c5286@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
 <OuorxBjLrAKkDp6t_zdsjDsGH33vTd7mOViD6fMjP5M=.e97b26c5-2bad-40de-abf8-8505c03c5286@github.com>
Message-ID: <tDc7h7hNfpYairL5YYmvIf0HJc_VVe6dI8VbKGIKyGQ=.aaf07dc6-721b-4687-864e-2c51da20538b@github.com>

On Sat, 10 May 2025 20:43:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:
> 
>  - Jaikiran comments, improve thread reference tracking, more documents
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - Update src/java.base/share/classes/java/lang/ClassValue.java
>    
>    Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - Reviews from viktor
>  - Rewrite impl to follow the new simplified spec
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - Try to simplify the model - use the finish of computeValue
>    
>  - Test updates - remove repetition, test case for no stale installation
>  - Fix incorrect promise removal when unnecessary and add regression test
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/60bb1184...e24a1fd7

src/java.base/share/classes/java/lang/ClassValue.java line 99:

> 97:      * that computed the value to associate.  A new invocation to {@code
> 98:      * computeValue}, which that {@code remove} call happens-before, happens to
> 99:      * re-establish this happens-before relationship.</li>

Suggestion:

     * computeValue}, which that {@code remove} call happens-before,
     * re-establishes this happens-before relationship.</li>

src/java.base/share/classes/java/lang/ClassValue.java line 126:

> 124:      * value if it exists.  Otherwise, this method tries to associate a value
> 125:      * from a {@link #computeValue computeValue} invocation until the associated
> 126:      * value exists, which may be from another thread.

Suggestion:

     * value exists, which could be associated by a competing thread.

src/java.base/share/classes/java/lang/ClassValue.java line 347:

> 345:         }
> 346: 
> 347:         // Arguments are nullable, intentionally to allow initial tokens

Suggestion:

        // Arguments are intentionally nullable, to allow initial tokens

src/java.base/share/classes/java/lang/ClassValue.java line 348:

> 346: 
> 347:         // Arguments are nullable, intentionally to allow initial tokens
> 348:         static boolean areCompatible(RemovalToken current, RemovalToken original) {

Are "equivalent"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086738186
PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086742731
PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086745684
PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086747420

From liach at openjdk.org  Tue May 13 13:34:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 May 2025 13:34:38 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v14]
In-Reply-To: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
Message-ID: <8C47-4udZPDRsG3vwfP03C3l2YOsBcUD3F_fTl1kqL0=.ead02b84-2cd3-4949-bb4d-1f4ed9cec366@github.com>

> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
> 
> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
> 
> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
> 
> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24043/files
  - new: https://git.openjdk.org/jdk/pull/24043/files/e24a1fd7..be5dd3cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=12-13

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24043/head:pull/24043

PR: https://git.openjdk.org/jdk/pull/24043

From liach at openjdk.org  Tue May 13 13:34:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 May 2025 13:34:41 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v13]
In-Reply-To: <tDc7h7hNfpYairL5YYmvIf0HJc_VVe6dI8VbKGIKyGQ=.aaf07dc6-721b-4687-864e-2c51da20538b@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
 <OuorxBjLrAKkDp6t_zdsjDsGH33vTd7mOViD6fMjP5M=.e97b26c5-2bad-40de-abf8-8505c03c5286@github.com>
 <tDc7h7hNfpYairL5YYmvIf0HJc_VVe6dI8VbKGIKyGQ=.aaf07dc6-721b-4687-864e-2c51da20538b@github.com>
Message-ID: <htPGqNybg7WI-VMfRCCd_3_0hrn1NySJ55dnWGO6Wes=.250f1241-a080-4490-8995-506a312dab5a@github.com>

On Tue, 13 May 2025 12:47:12 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:
>> 
>>  - Jaikiran comments, improve thread reference tracking, more documents
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>>  - Update src/java.base/share/classes/java/lang/ClassValue.java
>>    
>>    Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>>  - Reviews from viktor
>>  - Rewrite impl to follow the new simplified spec
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>>  - Try to simplify the model - use the finish of computeValue
>>    
>>  - Test updates - remove repetition, test case for no stale installation
>>  - Fix incorrect promise removal when unnecessary and add regression test
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/f1e84a54...e24a1fd7
>
> src/java.base/share/classes/java/lang/ClassValue.java line 99:
> 
>> 97:      * that computed the value to associate.  A new invocation to {@code
>> 98:      * computeValue}, which that {@code remove} call happens-before, happens to
>> 99:      * re-establish this happens-before relationship.</li>
> 
> Suggestion:
> 
>      * computeValue}, which that {@code remove} call happens-before,
>      * re-establishes this happens-before relationship.</li>

I think `can re-establish` or `will re-establish` is better just because this happens after the outcome. What do you think?

> src/java.base/share/classes/java/lang/ClassValue.java line 348:
> 
>> 346: 
>> 347:         // Arguments are nullable, intentionally to allow initial tokens
>> 348:         static boolean areCompatible(RemovalToken current, RemovalToken original) {
> 
> Are "equivalent"?

Not really: if you have an original token and a current token created during the computeValue of the original token, they are compatible but not really "equivalent" (i.e. the threadId case)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086833475
PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086837740

From liach at openjdk.org  Tue May 13 13:34:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 May 2025 13:34:41 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v13]
In-Reply-To: <htPGqNybg7WI-VMfRCCd_3_0hrn1NySJ55dnWGO6Wes=.250f1241-a080-4490-8995-506a312dab5a@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
 <OuorxBjLrAKkDp6t_zdsjDsGH33vTd7mOViD6fMjP5M=.e97b26c5-2bad-40de-abf8-8505c03c5286@github.com>
 <tDc7h7hNfpYairL5YYmvIf0HJc_VVe6dI8VbKGIKyGQ=.aaf07dc6-721b-4687-864e-2c51da20538b@github.com>
 <htPGqNybg7WI-VMfRCCd_3_0hrn1NySJ55dnWGO6Wes=.250f1241-a080-4490-8995-506a312dab5a@github.com>
Message-ID: <rb5H25l90KXXNLXrSSwG1LUKqqPAdmDcVcaqwGUg8Gk=.6cfff902-3ca8-4b76-86ad-ce27bddd0616@github.com>

On Tue, 13 May 2025 13:30:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ClassValue.java line 348:
>> 
>>> 346: 
>>> 347:         // Arguments are nullable, intentionally to allow initial tokens
>>> 348:         static boolean areCompatible(RemovalToken current, RemovalToken original) {
>> 
>> Are "equivalent"?
>
> Not really: if you have an original token and a current token created during the computeValue of the original token, they are compatible but not really "equivalent" (i.e. the threadId case)

Maybe `canAssociate`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086840404

From alanb at openjdk.org  Tue May 13 13:38:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 May 2025 13:38:56 GMT
Subject: Integrated: 8350765: Need to pin when accessing thread container from
 virtual thread
In-Reply-To: <G5nHVCpo-Kzs-63jq0uQXFpiXqObL8sapYh-Z8gA7rk=.4fe730d0-8571-4147-81b4-0b34f57ec54e@github.com>
References: <G5nHVCpo-Kzs-63jq0uQXFpiXqObL8sapYh-Z8gA7rk=.4fe730d0-8571-4147-81b4-0b34f57ec54e@github.com>
Message-ID: <t59tYaHnqBKXzJ5SuoP9Vz9SxDnmS3tJgf78MsNaR0E=.fe12cbad-786d-4212-bb00-9b19ff07ecc7@github.com>

On Wed, 26 Feb 2025 19:46:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Data structures that are accessed by both virtual threads and their carriers require the virtual thread to pin the continuation to avoid potential deadlock. A deadlock can arise when a virtual thread is preempted, is selected and scheduled to be the next owner of the lock/resource, but can't execute because all carriers are blocking on the same lock/resource. There are a small number of places that need to pin. One that was missed is the the notification to the thread container when threads are started or terminate. This is not currently an issue at this time but it is a potential hazard for ongoing and future work that will add further scheduling points to the code.  Continuation.pin/unpin have intrinsics since JDK-8338745, and Continuation is initialized early in startup. Finally, the changes have been in the loom repo for several months with no issues.
> 
> Testing tier1-5, quick statup/footprint, noreg-hard

This pull request has now been integrated.

Changeset: fa419489
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa419489d3769a989ee5bd948eeda0ed9be071e2
Stats:     94 lines in 6 files changed: 50 ins; 25 del; 19 mod

8350765: Need to pin when accessing thread container from virtual thread

Reviewed-by: vklang, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/23810

From pminborg at openjdk.org  Tue May 13 13:44:07 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 13 May 2025 13:44:07 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
 [v4]
In-Reply-To: <yJoCuLgZ3VRFyQKOS8HuV8xE3M80Ta5MwGwkYZVtFh8=.ccea0f91-038e-4fa0-a3f1-aa626a011b7a@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
 <yJoCuLgZ3VRFyQKOS8HuV8xE3M80Ta5MwGwkYZVtFh8=.ccea0f91-038e-4fa0-a3f1-aa626a011b7a@github.com>
Message-ID: <Zpdx5IsDUziHmzKLb04CkQzwy8mgqjJve5PYAl2E20o=.10a97ec4-9083-4b85-a916-04e7d8078bf4@github.com>

On Tue, 13 May 2025 07:57:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
>> 
>> Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example.
>> 
>> Unfortunately, this PR shows the total commit history for stable values.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

Thank you all reviewers for reviewing this PR!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25004#issuecomment-2876567924

From pminborg at openjdk.org  Tue May 13 13:44:08 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 13 May 2025 13:44:08 GMT
Subject: Integrated: 8356080: Address post-integration comments for Stable
 Values
In-Reply-To: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
Message-ID: <I0dSobmSbRW4vZvaUY36qRBu-VkhecuXQYL8FKOHxyw=.9fe6b6a8-9226-4559-8e93-c8c49ec03138@github.com>

On Fri, 2 May 2025 12:13:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
> 
> Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example.
> 
> Unfortunately, this PR shows the total commit history for stable values.

This pull request has now been integrated.

Changeset: 066477de
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/066477de80fc8719651b7b7bf2d02b1f58135f77
Stats:     437 lines in 14 files changed: 307 ins; 50 del; 80 mod

8356080: Address post-integration comments for Stable Values

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/25004

From jpai at openjdk.org  Tue May 13 13:52:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 May 2025 13:52:53 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: <uNGGjZ8MTJQ-0B1MaURdrJWut2muWY8PhM1cglEcoSU=.ead28184-1d04-4d79-acb7-c3a2ed1cad97@github.com>

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 167:

> 165:                     return null;
> 166:                 }
> 167:                 case String label when READ_WRITE.label.equals(label) -> {

I haven't yet fully caught up on the newer features of switch/case. Does this have any advantage as compared to the simpler:


case "readWrite" -> {
   return READ_WRITE;
}
case "readOnly" -> {
   return READ_ONLY;
}

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 174:

> 172:                 }
> 173:                 default -> {
> 174:                 }

Since we don't allow for any other value, I think moving the `throw new IllegalArgumentException` from outside of the switch into this `default` case might be suitable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2086881780
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2086877658

From liach at openjdk.org  Tue May 13 13:56:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 May 2025 13:56:37 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v15]
In-Reply-To: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
Message-ID: <yHqAaZikc8ZZAf9krV1KMzx_vVgUxkMVUmFVshIN6Uo=.2aa41d75-41d9-44cd-bef3-f598f62728f7@github.com>

> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
> 
> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
> 
> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
> 
> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  More suggestions from viktor

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24043/files
  - new: https://git.openjdk.org/jdk/pull/24043/files/be5dd3cc..08f78fc2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=13-14

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24043/head:pull/24043

PR: https://git.openjdk.org/jdk/pull/24043

From liach at openjdk.org  Tue May 13 13:56:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 May 2025 13:56:37 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v14]
In-Reply-To: <8C47-4udZPDRsG3vwfP03C3l2YOsBcUD3F_fTl1kqL0=.ead02b84-2cd3-4949-bb4d-1f4ed9cec366@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
 <8C47-4udZPDRsG3vwfP03C3l2YOsBcUD3F_fTl1kqL0=.ead02b84-2cd3-4949-bb4d-1f4ed9cec366@github.com>
Message-ID: <dAUCadKnS9avCMN8HkA2ugcN_3Iz-F7dYkyXHdDToCU=.0c0f71cb-de14-4211-9786-ca1254abc420@github.com>

On Tue, 13 May 2025 13:34:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

I have updated per suggestions; also reflected these minor corrections in the CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2876622878

From vklang at openjdk.org  Tue May 13 13:56:37 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 13 May 2025 13:56:37 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v13]
In-Reply-To: <htPGqNybg7WI-VMfRCCd_3_0hrn1NySJ55dnWGO6Wes=.250f1241-a080-4490-8995-506a312dab5a@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
 <OuorxBjLrAKkDp6t_zdsjDsGH33vTd7mOViD6fMjP5M=.e97b26c5-2bad-40de-abf8-8505c03c5286@github.com>
 <tDc7h7hNfpYairL5YYmvIf0HJc_VVe6dI8VbKGIKyGQ=.aaf07dc6-721b-4687-864e-2c51da20538b@github.com>
 <htPGqNybg7WI-VMfRCCd_3_0hrn1NySJ55dnWGO6Wes=.250f1241-a080-4490-8995-506a312dab5a@github.com>
Message-ID: <JvVaRYWCary96QejTOKYrPmf-nHTpT5jwB-IMhSlvLg=.01d1ccad-1386-4ddd-8728-63cf207fa1bf@github.com>

On Tue, 13 May 2025 13:28:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ClassValue.java line 99:
>> 
>>> 97:      * that computed the value to associate.  A new invocation to {@code
>>> 98:      * computeValue}, which that {@code remove} call happens-before, happens to
>>> 99:      * re-establish this happens-before relationship.</li>
>> 
>> Suggestion:
>> 
>>      * computeValue}, which that {@code remove} call happens-before,
>>      * re-establishes this happens-before relationship.</li>
>
> I think `can re-establish` or `will re-establish` is better just because this happens after the outcome. What do you think?

`will re-establish the happens-before relationship` sounds good

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086880480

From vklang at openjdk.org  Tue May 13 13:56:38 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 13 May 2025 13:56:38 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v13]
In-Reply-To: <rb5H25l90KXXNLXrSSwG1LUKqqPAdmDcVcaqwGUg8Gk=.6cfff902-3ca8-4b76-86ad-ce27bddd0616@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
 <OuorxBjLrAKkDp6t_zdsjDsGH33vTd7mOViD6fMjP5M=.e97b26c5-2bad-40de-abf8-8505c03c5286@github.com>
 <tDc7h7hNfpYairL5YYmvIf0HJc_VVe6dI8VbKGIKyGQ=.aaf07dc6-721b-4687-864e-2c51da20538b@github.com>
 <htPGqNybg7WI-VMfRCCd_3_0hrn1NySJ55dnWGO6Wes=.250f1241-a080-4490-8995-506a312dab5a@github.com>
 <rb5H25l90KXXNLXrSSwG1LUKqqPAdmDcVcaqwGUg8Gk=.6cfff902-3ca8-4b76-86ad-ce27bddd0616@github.com>
Message-ID: <N737YqmwR7_VlI3ypn9v4gP7MDaT4IU1msbEDfzaBjc=.4304e52c-8f0d-4413-97b2-3d35844128c6@github.com>

On Tue, 13 May 2025 13:31:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Not really: if you have an original token and a current token created during the computeValue of the original token, they are compatible but not really "equivalent" (i.e. the threadId case)
>
> Maybe `canAssociate`?

`allowsAssociation`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2086878283

From jpai at openjdk.org  Tue May 13 13:59:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 May 2025 13:59:52 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: <OUM38oaCUaIARxcaYgrAU4yKlhb3vDYlD5x1dHP4h5E=.f1ab1320-bb3b-43e1-814b-5493aeeb99c8@github.com>

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 160:

> 158: 
> 159:         // Parses the file system permission from an environmental parameter. While
> 160:         // the FileSystemAccessMode is private, we don't need to check if it was

The second sentence perhaps is a leftover? I don't see any `FileSystemAccessMode` type. I think it would be better to remove that second sentence altogether. The rest of the comment looks good and clearly states what this method does.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2086897450

From abarashev at openjdk.org  Tue May 13 14:03:57 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 13 May 2025 14:03:57 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v3]
In-Reply-To: <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>
 <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com>
Message-ID: <JGgkSA4koYf9fBlA0nf2qFXnw0AaPk7I0kiVpv6CPeI=.8e8221d1-5b21-4c8f-a821-253f3fe1c850@github.com>

On Tue, 13 May 2025 03:56:25 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> It is nice to refactor the common code for algorithm constraints checking into a new class, `X509KeyManagerConstraints.java`, used by both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a new system property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. Should the property be a switch for SunX509 KeyManager, not a general toggle for all KeyManager? Avoiding its misuse for `X509KeyManagerImpl` that may lead to disable the existing RFC compliant algorithm constraints checking? It might be preferable to keep the property logic in `SunX509KeyManagerImpl` (not in the common code).

@haimaychao Thanks for looking into it! Yes, it will disable constraints checking for both key managers and I did it this way on purpose. I think it will be simpler and less confusing to the end users. This system property is off by default and my assumption is that if end users want to disable KM algorithm constraints checking they would expect it's disabled system-wide.
Making this toggle SunX509-specific is a trivial change if we have a consensus on this.

@seanjmullan What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2876654496

From rgiulietti at openjdk.org  Tue May 13 14:08:02 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 13 May 2025 14:08:02 GMT
Subject: Integrated: 8355992: Add unsignedMultiplyExact and *powExact methods
 to Math and StrictMath
In-Reply-To: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
References: <j5zdQXMFHQyrbYaKJVMn_JR2DFVJbqpZs6lIyXSfll0=.f7da6ecc-f0b3-4785-ad36-0a96c1e396e8@github.com>
Message-ID: <3RupE3VvfgCe2Y10eyg2xF_YxKq0sXZ0EgCCh5yJ6Gs=.3a5500c0-c00a-405f-8040-8a6c40ccc90b@github.com>

On Fri, 2 May 2025 11:47:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Add `powExact()` and `unsignedPowExact()` methods that operate on integer values arguments.
> Further, add `unsignedMultiplyExact` methods as well.

This pull request has now been integrated.

Changeset: 64a858c7
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64a858c7b832447c3dcf4a39a2b0929bc4d70c39
Stats:     724 lines in 3 files changed: 724 ins; 0 del; 0 mod

8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/25003

From shade at openjdk.org  Tue May 13 14:09:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 May 2025 14:09:56 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v4]
In-Reply-To: <SUvlR-eiCgYDDjnCIx4mHwoIOmNr9li5YbcntC4Dfmg=.656ee733-7e2e-4ec0-bea6-42bf7d6b7204@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
 <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
 <SUvlR-eiCgYDDjnCIx4mHwoIOmNr9li5YbcntC4Dfmg=.656ee733-7e2e-4ec0-bea6-42bf7d6b7204@github.com>
Message-ID: <hPBnB0DIF1JNw_hTX62xiN-lSlsOqUzeAOEDaa8XofM=.58435a31-c771-4fe4-9da8-f0644a23c5aa@github.com>

On Wed, 30 Apr 2025 16:06:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Add bug ID
>>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>>  - Pull message into a field
>>  - Test cases
>>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>>  - Initial fix
>>    
>>    Good spawnhelper failure message
>>    
>>    Trying tests
>>    
>>    Print helper message on all IOExceptions
>>    
>>    Final
>
> Thanks for the bugid.

Thanks! @RogerRiggs, @simonis, @lutkerd -- are you good with new output message? The line here:


java.io.IOException: Cannot run program "pwd": Failed to exec spawn helper: pid: 1405770, exit code: 4, error: 0 (none) 
...


https://github.com/openjdk/jdk/pull/24149#issuecomment-2742889069

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24149#issuecomment-2876680588

From amaembo at gmail.com  Tue May 13 14:12:21 2025
From: amaembo at gmail.com (Tagir Valeev)
Date: Tue, 13 May 2025 16:12:21 +0200
Subject: Finding max or min of exactly two objects
Message-ID: <CAE+3fja-oo=Yxxs9gQ9cTnCStYOBtf1oey3Dn6F2dNjbfievCg@mail.gmail.com>

Hello!

Several times already when writing Java programs, I stumbled with a simple
task: given two objects with natural order, find the maximal of them. The
algorithm I need could be formulated like this:

    <T extends Comparable<T>> T max(T a, T b) {
        return a.compareTo(b) > 0 ? a : b;
    }

Writing manually compareTo >= 0 looks too verbose, not very readable and
error-prone: one has to mention both objects twice, and it's possible to
mix > with <. I can surely add a method mentioned above to a utility class
in my project and use it everywhere. However, I feel that it deserves a
place in the standard library.

The alternatives we have now:
BinaryOperator.maxBy(Comparator.<T>naturalOrder()).apply(a, b);
This speaks clearly about the intent (we'd like to get the maximum and we
write 'maxBy') but very wordy.

Stream.of(a, b).max(Comparator.naturalOrder()).get();
Also clear and a little bit shorter, but has an unnecessary Optional
in-between (we know that we have at least one element, so the result is
always present) and we have to mention the comparator. Finally, it might be
much less efficient than expected.

Probably we can add simple static methods `max` and `min` either to the
`Comparator` interface, or to `java.util.Objects`? Such methods would
complement methods from the `Math` class for numbers. In addition, having
default methods `max` and `min` in the `Comparator` interface would also be
nice:

String bigger = String.CASE_INSENSITIVE_ORDER.max("Hello", "world");

What do you think? Can we proceed with such an enhancement?

With best regards,
Tagir Valeev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250513/29e906dd/attachment.htm>

From heidinga at openjdk.org  Tue May 13 14:15:57 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 13 May 2025 14:15:57 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v7]
In-Reply-To: <qctRiRRA6GVy-SAwn4k2Gfo0jmlPbZn5w9QgKjWjmY4=.34fdf078-b7a5-40f0-88fa-503885ccba2f@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <qctRiRRA6GVy-SAwn4k2Gfo0jmlPbZn5w9QgKjWjmY4=.34fdf078-b7a5-40f0-88fa-503885ccba2f@github.com>
Message-ID: <lP5RGSqXIMjzTrGvkp0DFN7YIc8phaCSBlja9DtDEkE=.98e7333a-0821-4de7-b64c-6530bfc1f0d7@github.com>

On Tue, 13 May 2025 03:06:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>> 
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
>> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
>> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
>> 
>> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
>> 
>> Examples:
>> 
>> 
>> # Create an AOT cache with a single command:
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> Hello World
>> Temporary AOTConfiguration recorded: foo.aot.config
>> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
>> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
>> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
>> AOTCache creation is complete: foo.aot 10240000 bytes
>> 
>> # Create logging file for the AOT cache assembly phase
>> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> 
>> 
>> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added param to makefile function SetupAOT for choosing onestep vs twostep

src/java.base/share/man/java.md line 4073:

> 4071:     - `-XX:AOTMode=record` is specified, or
> 4072:     - `-XX:AOTCacheOutput` is specified, and `-XX:AOTMode=auto` is specified, or
> 4073:     - `-XX:AOTCacheOutput` is specified, and `-XX:AOTMode` is not specidied.

Suggestion:

    - `-XX:AOTCacheOutput` is specified, and `-XX:AOTMode` is not specified.

src/java.base/share/man/java.md line 4084:

> 4082: -   `record`: Execute the application in the Training phase.
> 4083:      At least one of `-XX:AOTConfiguration=`*configfile* and/or
> 4084:      `-XX:AOTCache=`*cachefile* must be specified.

Suggestion:

     `-XX:AOTCache=`*cachefile* or `-XX:AOTCacheOutput=`*cachefile* must be specified.


AOTCacheOutput is also a valid configuration for mode record, right?

src/java.base/share/man/java.md line 4087:

> 4085:      If `-XX:AOTConfiguration=`*configfile* is specified, the JVM gathers
> 4086:      statistical data and stores them into *configfile*.
> 4087:      If `-XX:AOTCache=`*cachefile* is specified, a second JVM process is launched

Suggestion:

     If `-XX:AOTCache=`*cachefile* or `-XX:AOTCacheOutput=`*cachefile* is specified, a second JVM process is launched

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2086925261
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2086929891
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2086934364

From aph at openjdk.org  Tue May 13 14:17:14 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 13 May 2025 14:17:14 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v4]
In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
Message-ID: <_YHxBGEeUL7hfvcstwV9F0BCAC-ijDjoI__DrDAQuqM=.5e56c31b-5cf1-447f-83cf-2166dccf7b0e@github.com>

> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
> 
> 
> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Cleanups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25147/files
  - new: https://git.openjdk.org/jdk/pull/25147/files/47179d57..23838f8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=02-03

  Stats: 6 lines in 1 file changed: 3 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25147/head:pull/25147

PR: https://git.openjdk.org/jdk/pull/25147

From duke at openjdk.org  Tue May 13 14:30:12 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 13 May 2025 14:30:12 GMT
Subject: RFR: 8077587: BigInteger Roots [v12]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <CrhSvk5x6gZb6iuJ85rtg1l2qKBvhFbz9I2PYEiEEHU=.545d40f5-e5d7-4fe2-b7c5-3cd1998286ef@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'nth-root-branch' of https://github.com/fabioromano1/jdk into nth-root-branch
 - Compute remainder in the final loop to do less iterations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/3d8562f1..0cfb4f65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=10-11

  Stats: 60 lines in 2 files changed: 17 ins; 13 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From brian.goetz at oracle.com  Tue May 13 14:30:33 2025
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 13 May 2025 10:30:33 -0400
Subject: Finding max or min of exactly two objects
In-Reply-To: <CAE+3fja-oo=Yxxs9gQ9cTnCStYOBtf1oey3Dn6F2dNjbfievCg@mail.gmail.com>
References: <CAE+3fja-oo=Yxxs9gQ9cTnCStYOBtf1oey3Dn6F2dNjbfievCg@mail.gmail.com>
Message-ID: <55572e2c-a66c-4b76-a65d-c8fdf544be2f@oracle.com>

When we did Lambda, we made a few mistakes in the category of adding 
default methods to some "highly abstract" types, such as 
Function::andThen.? You were there; these were well-intentioned, but we 
neglected to think sufficiently about the consequences for subclasses.? 
For example:

 ??? interface Function<T,U> {
 ??????? U apply(T t);

 ??????? <V> default Function<T, V> andThen(Function<U,V> g) { ... }
 ??? }

seems fine, but then when you extend it:

 ??? interface UnaryOperator<T> extends Function<T,T> {
 ??? }

you kind of lose, because you can't compose _unary operators_ using 
Function::compose.? And if you try to refine it:

 ??? interface UnaryOperator<T> extends Function<T,T> {
 ??????? default UnaryOperator<T> andThen(UnaryOperator<T> g) { ... }
 ??? }

you end up overloading, not overriding the method, in a way that clients 
cannot distinguish: `f.andThen(lambda)` will likely not be able to 
distinguish between the overloads, because they have the same shape.? 
Ooops.

So with that as background, I am very cautious to consider adding 
methods to Comparable, because it is a highly abstract type that was 
designed for extension, and the risk of the above kind of clash seems 
"not low".

Comparator seems less risky, because it is not designed to be extended 
by domain objects, but instead functions more like a type class in 
Haskell -- it is behavior _about_ a type, defined from the outside.? And 
Haskell would agree with you that this move is sensible; here's 
Haskell's `Ord` (like Comparator), which extends `Eq` (providing equality.)

class? (Eq a) => Ord a? where
 ??? compare????????????? :: a -> a -> Ordering
 ??? (<), (<=), (>), (>=) :: a -> a -> Bool
 ??? max, min???????????? :: a -> a -> a

 ??? compare x y = if x == y then EQ
 ????????????????? -- NB: must be '<=' not '<' to validate the
 ????????????????? -- above claim about the minimal things that
 ????????????????? -- can be defined for an instance of Ord:
 ????????????????? else if x <= y then LT
 ????????????????? else GT

 ??? x <= y = case compare x y of { GT -> False; _ -> True }
 ??? x >= y = y <= x
 ??? x > y = not (x <= y)
 ??? x < y = not (y <= x)


 ??????? -- These two default methods use '<=' rather than 'compare'
 ??????? -- because the latter is often more expensive
 ??? max x y = if x <= y then y else x
 ??? min x y = if x <= y then x else y
 ??? {-# MINIMAL compare | (<=) #-}

The `compare` method is like our Comparator method, just returning a 
three-valued enum rather than an int.? (Haskell has a cool feature here, 
where you can define all the methods in terms of others, and then you 
can override whichever ones make sense to break the cycles.? The MINIMAL 
annotation says "if you provide either compare or <=, you're good."? I 
wish we had this for interfaces with default methods.)? It then proceeds 
to derive `min` and `max` from `<=` (which might itself be derived from 
`compare`.)

OK, "comparative languages" lesson over, back to your point. There are 
two ways to get where you want: a static method that takes a comparator 
and the operands (`Comparator.max(c, a, b)`), or a default method on 
Comparator (`c.max(a, b)`).? (You say "add simple static methods ... to 
Comparator" but I think you mean to put the word `static` elsewhere in 
that sentence.)

I am receptive to the idea of extending Comparator here, but would want 
to think about it more to feel out potential mistakes like the `andThen` 
one above.? But your point is solid: a "comparator" is also a "maxxer" 
and a "minner" (neither of those are words, and if they were, are 
probably spelled wrong), and that is a natural place to locate such 
behavior.




On 5/13/2025 10:12 AM, Tagir Valeev wrote:
> Hello!
>
> Several times already when writing Java programs, I stumbled with a 
> simple task: given two objects with natural order, find the maximal of 
> them. The algorithm I need could be formulated like this:
>
> ? ? <T extends Comparable<T>> T max(T a, T b) {
> ? ? ? ? return a.compareTo(b) > 0 ? a : b;
> ? ? }
>
> Writing manually compareTo >= 0 looks too verbose, not very readable 
> and error-prone: one has to mention both objects twice, and it's 
> possible to mix > with <. I can surely add a method mentioned above to 
> a utility class in my project and use it everywhere. However, I feel 
> that it deserves a place in the standard library.
>
> The alternatives we have now:
> BinaryOperator.maxBy(Comparator.<T>naturalOrder()).apply(a, b);
> This speaks clearly about the intent (we'd like to get the maximum and 
> we write 'maxBy') but very wordy.
>
> Stream.of(a, b).max(Comparator.naturalOrder()).get();
> Also clear and a little bit shorter, but has an unnecessary Optional 
> in-between (we know that we have at least one element, so the result 
> is always present) and we have to mention the comparator. Finally, it 
> might be much less efficient than expected.
>
> Probably we can add simple static methods `max` and `min` either to 
> the `Comparator` interface, or to `java.util.Objects`? Such methods 
> would complement methods from the `Math` class for numbers. In 
> addition, having default methods `max` and `min` in the `Comparator` 
> interface would also be nice:
>
> String bigger = String.CASE_INSENSITIVE_ORDER.max("Hello", "world");
>
> What do you think? Can we proceed with such an enhancement?
>
> With best regards,
> Tagir Valeev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250513/bf4e7c6d/attachment-0001.htm>

From duke at openjdk.org  Tue May 13 14:45:07 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Tue, 13 May 2025 14:45:07 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
 [v4]
In-Reply-To: <yJoCuLgZ3VRFyQKOS8HuV8xE3M80Ta5MwGwkYZVtFh8=.ccea0f91-038e-4fa0-a3f1-aa626a011b7a@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
 <yJoCuLgZ3VRFyQKOS8HuV8xE3M80Ta5MwGwkYZVtFh8=.ccea0f91-038e-4fa0-a3f1-aa626a011b7a@github.com>
Message-ID: <2UtDeU1Gh1l-OfzmdnMo7_vjm6LMoZ6iQoPNIETn-Ag=.83b1fd1a-a7a4-4492-9cd5-bb6e3632a51d@github.com>

On Tue, 13 May 2025 07:57:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to address comments in the initial PR for Stable Values, which were deferred until after integration.
>> 
>> Most of the efforts in this PR are to retain "stability" as long as possible so that views of stable collections remain stable and do not evaluate on `toString()` for example.
>> 
>> Unfortunately, this PR shows the total commit history for stable values.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

src/java.base/share/classes/java/util/ImmutableCollections.java line 1732:

> 1730:                         && Objects.equals(getKey(), e.getKey())
> 1731:                         // Invoke `getValue()` as late as possible to avoid evaluation
> 1732:                         && Objects.equals(getValue(), e.getValue());

Suggestion:

                        && Objects.equals(e.getValue(), getValue());

You already integrated and it's probably not that important, but this would additionally avoid evaluation if `e.getValue()` throws.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2086998430

From liach at openjdk.org  Tue May 13 14:45:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 May 2025 14:45:07 GMT
Subject: RFR: 8356080: Address post-integration comments for Stable Values
 [v4]
In-Reply-To: <2UtDeU1Gh1l-OfzmdnMo7_vjm6LMoZ6iQoPNIETn-Ag=.83b1fd1a-a7a4-4492-9cd5-bb6e3632a51d@github.com>
References: <X-kLIO_faEUHIGR3jc5tcXm4-6c_vXSGZkTw9NAhxcQ=.95f40546-f8a5-47b2-a488-ef2bc7c75930@github.com>
 <yJoCuLgZ3VRFyQKOS8HuV8xE3M80Ta5MwGwkYZVtFh8=.ccea0f91-038e-4fa0-a3f1-aa626a011b7a@github.com>
 <2UtDeU1Gh1l-OfzmdnMo7_vjm6LMoZ6iQoPNIETn-Ag=.83b1fd1a-a7a4-4492-9cd5-bb6e3632a51d@github.com>
Message-ID: <4DT0NAevUHChM45tCJX8h7dPmCSc2a83OqH87bx3HAo=.96a4fbbf-33b0-467d-b70f-0f3fa577532b@github.com>

On Tue, 13 May 2025 14:39:36 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 1732:
> 
>> 1730:                         && Objects.equals(getKey(), e.getKey())
>> 1731:                         // Invoke `getValue()` as late as possible to avoid evaluation
>> 1732:                         && Objects.equals(getValue(), e.getValue());
> 
> Suggestion:
> 
>                         && Objects.equals(e.getValue(), getValue());
> 
> You already integrated and it's probably not that important, but this would additionally avoid evaluation if `e.getValue()` throws.

This is in the realms of microoptimization now...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25004#discussion_r2087007810

From duke at openjdk.org  Tue May 13 14:48:55 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Tue, 13 May 2025 14:48:55 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v3]
In-Reply-To: <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
Message-ID: <oMwFXneYTjswbqNbyMq16Cha8bJMXkrospBpxO3zTpw=.e9ed6489-55c3-4f20-aa08-65a9e2e40557@github.com>

On Fri, 2 May 2025 10:00:07 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor container runtime version code

The change looks good. There might be some issues with container engine version parsing.

I wrote 2 comments. but cold not post them. They are in "pending" state.
Not sure why. Should the comments be first reviewed by {Committers|Reviewers}?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2876826791

From rriggs at openjdk.org  Tue May 13 14:51:00 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 May 2025 14:51:00 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v18]
In-Reply-To: <ckd-UcxICCx3Zq-ehw1KBV7jQ3JfjX9jtZ0_DsxnlTE=.fb7f1026-cfa9-42a2-bf92-1622939a2b8d@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <ckd-UcxICCx3Zq-ehw1KBV7jQ3JfjX9jtZ0_DsxnlTE=.fb7f1026-cfa9-42a2-bf92-1622939a2b8d@github.com>
Message-ID: <i10_MJ6IYd8p7eIEGD0qyehXU2SEIQXDmPFIb9a1ZnQ=.08e73c04-9993-4b88-b54a-afe29f84a1c8@github.com>

On Mon, 12 May 2025 23:51:19 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
> 
>  - 8354724: Attempt to further improve verbiage
>  - Merge
>  - Update src/java.base/share/classes/java/io/Reader.java
>    
>    8354724: Apply suggested changes for readAllLines.
>    
>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>  - Update src/java.base/share/classes/java/io/Reader.java
>    
>    8354724: Apply suggested changes for readAllAsString.
>    
>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>  - 8354724: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test
>  - 8354724: Fix potential NPE in test
>  - 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test
>  - 8354724: Improve test per reviewer comments
>  - 8354724: Add missing toList(), tweak verbiage; update test
>  - 8354724: Add Reader.readAllLines; test not yet updated
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/dcf15854...1d811589

Looks good, I think this (with fix above for stream -> reader) is ready to create the CSR and get that review process moving.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2876832823

From rriggs at openjdk.org  Tue May 13 14:57:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 May 2025 14:57:54 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v5]
In-Reply-To: <bpJt9PjA94QvUxfVv-hO-UdDvEUG-VMeeRGFpQZQalM=.e9d2bb18-1d47-43eb-995c-42659ae4d5a9@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
 <bpJt9PjA94QvUxfVv-hO-UdDvEUG-VMeeRGFpQZQalM=.e9d2bb18-1d47-43eb-995c-42659ae4d5a9@github.com>
Message-ID: <yvHo6UGgK-MO8pAtkNq3HaOdAkmMactMFMoF19DgMpU=.23bb3a43-a584-4558-92c6-d2d8a3886ec5@github.com>

On Tue, 13 May 2025 10:30:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong.
>> 
>> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. 
>> 
>> I am very open to bike-shedding about the actual message :)
>> 
>> Additional testing:
>>  - [x] Ad-hoc experiments with breaking jspawnhelper
>>  - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Print error decoding
>  - Touch up formatting message
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Add bug ID
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Pull message into a field
>  - Test cases
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Initial fix
>    
>    Good spawnhelper failure message
>    
>    Trying tests
>    
>    Print helper message on all IOExceptions
>    
>    Final

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24149#pullrequestreview-2837127473

From simonis at openjdk.org  Tue May 13 14:57:54 2025
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 13 May 2025 14:57:54 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v5]
In-Reply-To: <bpJt9PjA94QvUxfVv-hO-UdDvEUG-VMeeRGFpQZQalM=.e9d2bb18-1d47-43eb-995c-42659ae4d5a9@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
 <bpJt9PjA94QvUxfVv-hO-UdDvEUG-VMeeRGFpQZQalM=.e9d2bb18-1d47-43eb-995c-42659ae4d5a9@github.com>
Message-ID: <0fWy_XJXD0_iSnux8cE6jWFf03Ukfs_FowPzvJWAzn8=.068f793e-aa66-4b2e-bd33-d7f020a50924@github.com>

On Tue, 13 May 2025 10:30:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong.
>> 
>> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. 
>> 
>> I am very open to bike-shedding about the actual message :)
>> 
>> Additional testing:
>>  - [x] Ad-hoc experiments with breaking jspawnhelper
>>  - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Print error decoding
>  - Touch up formatting message
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Add bug ID
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Pull message into a field
>  - Test cases
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Initial fix
>    
>    Good spawnhelper failure message
>    
>    Trying tests
>    
>    Print helper message on all IOExceptions
>    
>    Final

Still OK. Time to ship...

-------------

Marked as reviewed by simonis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24149#pullrequestreview-2837131004

From forax at univ-mlv.fr  Tue May 13 14:58:29 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 13 May 2025 16:58:29 +0200 (CEST)
Subject: Finding max or min of exactly two objects
In-Reply-To: <55572e2c-a66c-4b76-a65d-c8fdf544be2f@oracle.com>
References: <CAE+3fja-oo=Yxxs9gQ9cTnCStYOBtf1oey3Dn6F2dNjbfievCg@mail.gmail.com>
 <55572e2c-a66c-4b76-a65d-c8fdf544be2f@oracle.com>
Message-ID: <1307830774.264764550.1747148309305.JavaMail.zimbra@univ-eiffel.fr>

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Tagir Valeev" <amaembo at gmail.com>, "core-libs-dev"
> <core-libs-dev at openjdk.org>
> Sent: Tuesday, May 13, 2025 4:30:33 PM
> Subject: Re: Finding max or min of exactly two objects

> When we did Lambda, we made a few mistakes in the category of adding default
> methods to some "highly abstract" types, such as Function::andThen. You were
> there; these were well-intentioned, but we neglected to think sufficiently
> about the consequences for subclasses. For example:

> interface Function<T,U> {
> U apply(T t);

> <V> default Function<T, V> andThen(Function<U,V> g) { ... }
> }

> seems fine, but then when you extend it:

> interface UnaryOperator<T> extends Function<T,T> {
> }

> you kind of lose, because you can't compose _unary operators_ using
> Function::compose. And if you try to refine it:

> interface UnaryOperator<T> extends Function<T,T> {
> default UnaryOperator<T> andThen(UnaryOperator<T> g) { ... }
> }

> you end up overloading, not overriding the method, in a way that clients cannot
> distinguish: `f.andThen(lambda)` will likely not be able to distinguish between
> the overloads, because they have the same shape. Ooops.
It's not clear to me that the mistake was adding a default method but not using inheritance in between UnaryOperator and Function. 

A functional interface represents a structural type but by adding inheritance, we made it a weird mix. 

> So with that as background, I am very cautious to consider adding methods to
> Comparable, because it is a highly abstract type that was designed for
> extension, and the risk of the above kind of clash seems "not low".

> Comparator seems less risky, because it is not designed to be extended by domain
> objects, but instead functions more like a type class in Haskell -- it is
> behavior _about_ a type, defined from the outside. And Haskell would agree with
> you that this move is sensible; here's Haskell's `Ord` (like Comparator), which
> extends `Eq` (providing equality.)

> class (Eq a) => Ord a where
> compare :: a -> a -> Ordering
> (<), (<=), (>), (>=) :: a -> a -> Bool
> max, min :: a -> a -> a

> compare x y = if x == y then EQ
> -- NB: must be '<=' not '<' to validate the
> -- above claim about the minimal things that
> -- can be defined for an instance of Ord:
> else if x <= y then LT
> else GT

> x <= y = case compare x y of { GT -> False; _ -> True }
> x >= y = y <= x
> x > y = not (x <= y)
> x < y = not (y <= x)

> -- These two default methods use '<=' rather than 'compare'
> -- because the latter is often more expensive
> max x y = if x <= y then y else x
> min x y = if x <= y then x else y
> {-# MINIMAL compare | (<=) #-}

> The `compare` method is like our Comparator method, just returning a
> three-valued enum rather than an int. (Haskell has a cool feature here, where
> you can define all the methods in terms of others, and then you can override
> whichever ones make sense to break the cycles. The MINIMAL annotation says "if
> you provide either compare or <=, you're good." I wish we had this for
> interfaces with default methods.) It then proceeds to derive `min` and `max`
> from `<=` (which might itself be derived from `compare`.)

> OK, "comparative languages" lesson over, back to your point. There are two ways
> to get where you want: a static method that takes a comparator and the operands
> (`Comparator.max(c, a, b)`), or a default method on Comparator (`c.max(a, b)`).
> (You say "add simple static methods ... to Comparator" but I think you mean to
> put the word `static` elsewhere in that sentence.)

> I am receptive to the idea of extending Comparator here, but would want to think
> about it more to feel out potential mistakes like the `andThen` one above. But
> your point is solid: a "comparator" is also a "maxxer" and a "minner" (neither
> of those are words, and if they were, are probably spelled wrong), and that is
> a natural place to locate such behavior.
In terms of performance, unlike Kotlin where you can create an inline method, static methods that wrap an interface call sometimes behave funnily in Java because the profiling done by the VM is attached to a bytecode instruction and not to the call graph (or at least to the caller site). 

Sadly that means that Comparator.max(c a, b) can be significantly slower than c.compare(a, b). 

R?mi 

> On 5/13/2025 10:12 AM, Tagir Valeev wrote:

>> Hello!

>> Several times already when writing Java programs, I stumbled with a simple task:
>> given two objects with natural order, find the maximal of them. The algorithm I
>> need could be formulated like this:

>> <T extends Comparable<T>> T max(T a, T b) {
>> return a.compareTo(b) > 0 ? a : b;
>> }

>> Writing manually compareTo >= 0 looks too verbose, not very readable and
>> error-prone: one has to mention both objects twice, and it's possible to mix >
>> with <. I can surely add a method mentioned above to a utility class in my
>> project and use it everywhere. However, I feel that it deserves a place in the
>> standard library.

>> The alternatives we have now:
>> BinaryOperator.maxBy(Comparator.<T>naturalOrder()).apply(a, b);
>> This speaks clearly about the intent (we'd like to get the maximum and we write
>> 'maxBy') but very wordy.

>> Stream.of(a, b).max(Comparator.naturalOrder()).get();
>> Also clear and a little bit shorter, but has an unnecessary Optional in-between
>> (we know that we have at least one element, so the result is always present)
>> and we have to mention the comparator. Finally, it might be much less efficient
>> than expected.

>> Probably we can add simple static methods `max` and `min` either to the
>> `Comparator` interface, or to `java.util.Objects`? Such methods would
>> complement methods from the `Math` class for numbers. In addition, having
>> default methods `max` and `min` in the `Comparator` interface would also be
>> nice:

>> String bigger = String.CASE_INSENSITIVE_ORDER.max("Hello", "world");

>> What do you think? Can we proceed with such an enhancement?

>> With best regards,
>> Tagir Valeev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250513/481b0a5f/attachment-0001.htm>

From vklang at openjdk.org  Tue May 13 15:01:02 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 13 May 2025 15:01:02 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v15]
In-Reply-To: <yHqAaZikc8ZZAf9krV1KMzx_vVgUxkMVUmFVshIN6Uo=.2aa41d75-41d9-44cd-bef3-f598f62728f7@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
 <yHqAaZikc8ZZAf9krV1KMzx_vVgUxkMVUmFVshIN6Uo=.2aa41d75-41d9-44cd-bef3-f598f62728f7@github.com>
Message-ID: <1lbIVV3fiKrSnDK9EZSff2FCwFWA79ehFI8kk2vpycA=.9a0bc674-f178-42b7-9ffa-26797dbfc538@github.com>

On Tue, 13 May 2025 13:56:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More suggestions from viktor

Marked as reviewed by vklang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24043#pullrequestreview-2837139440

From shade at openjdk.org  Tue May 13 15:17:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 May 2025 15:17:53 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v5]
In-Reply-To: <bpJt9PjA94QvUxfVv-hO-UdDvEUG-VMeeRGFpQZQalM=.e9d2bb18-1d47-43eb-995c-42659ae4d5a9@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
 <bpJt9PjA94QvUxfVv-hO-UdDvEUG-VMeeRGFpQZQalM=.e9d2bb18-1d47-43eb-995c-42659ae4d5a9@github.com>
Message-ID: <tyv75gR7NrifIxGRa4Kj1aMnobBjMih8CJU7xStonrM=.5d7d20b3-86f9-4cae-97ad-fc21035e146c@github.com>

On Tue, 13 May 2025 10:30:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong.
>> 
>> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. 
>> 
>> I am very open to bike-shedding about the actual message :)
>> 
>> Additional testing:
>>  - [x] Ad-hoc experiments with breaking jspawnhelper
>>  - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Print error decoding
>  - Touch up formatting message
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Add bug ID
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Pull message into a field
>  - Test cases
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Initial fix
>    
>    Good spawnhelper failure message
>    
>    Trying tests
>    
>    Print helper message on all IOExceptions
>    
>    Final

Thanks. I am re-running testing, and will integrate once it turns back green.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24149#issuecomment-2876937488

From acobbs at openjdk.org  Tue May 13 15:22:27 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 13 May 2025 15:22:27 GMT
Subject: RFR: 8143850: Add indexed get() and set() methods to ArrayDeque
Message-ID: <FqQcbJZGky9kSxgufXkrarVqOWIddA41Y_1fN0ZOL4k=.246fb74c-ba6e-417c-adf3-cde5b8e785f9@github.com>

Because it is backed by an array, the `ArrayDeque` class has the ability to get and replace any element in the list (accessed by index) in constant time. However, this capability is not exposed in the API.

Please review this PR which adds the following two new methods to `ArrayDeque`:
* `public E get(int index)`
* `public E set(int index, E element)`

-------------

Commit messages:
 - Add placeholder @since Javadoc tags.
 - Use inline @return Javadoc tag per review suggestion.
 - Add indexed get() and set() methods to ArrayDeque.

Changes: https://git.openjdk.org/jdk/pull/25189/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25189&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8143850
  Stats: 146 lines in 2 files changed: 146 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25189.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25189/head:pull/25189

PR: https://git.openjdk.org/jdk/pull/25189

From duke at openjdk.org  Tue May 13 15:22:27 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 13 May 2025 15:22:27 GMT
Subject: RFR: 8143850: Add indexed get() and set() methods to ArrayDeque
In-Reply-To: <FqQcbJZGky9kSxgufXkrarVqOWIddA41Y_1fN0ZOL4k=.246fb74c-ba6e-417c-adf3-cde5b8e785f9@github.com>
References: <FqQcbJZGky9kSxgufXkrarVqOWIddA41Y_1fN0ZOL4k=.246fb74c-ba6e-417c-adf3-cde5b8e785f9@github.com>
Message-ID: <UPdRAx5FmdNzyhdzhReVKf0eiI4mEukYiS8FuAH9gaE=.bc60150a-b0a3-4135-870a-af76a52adec8@github.com>

On Mon, 12 May 2025 18:24:27 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Because it is backed by an array, the `ArrayDeque` class has the ability to get and replace any element in the list (accessed by index) in constant time. However, this capability is not exposed in the API.
> 
> Please review this PR which adds the following two new methods to `ArrayDeque`:
> * `public E get(int index)`
> * `public E set(int index, E element)`

src/java.base/share/classes/java/util/ArrayDeque.java line 360:

> 358:      *
> 359:      * @param index index of the element to return
> 360:      * @return the element at the specified position in this deque

This?can?use the?inline?form of?`@return`:
Suggestion:

     * {@return the element at the specified position in this deque}
     *
     * @param index index of the element to return

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25189#discussion_r2086299413

From acobbs at openjdk.org  Tue May 13 15:22:27 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 13 May 2025 15:22:27 GMT
Subject: RFR: 8143850: Add indexed get() and set() methods to ArrayDeque
In-Reply-To: <UPdRAx5FmdNzyhdzhReVKf0eiI4mEukYiS8FuAH9gaE=.bc60150a-b0a3-4135-870a-af76a52adec8@github.com>
References: <FqQcbJZGky9kSxgufXkrarVqOWIddA41Y_1fN0ZOL4k=.246fb74c-ba6e-417c-adf3-cde5b8e785f9@github.com>
 <UPdRAx5FmdNzyhdzhReVKf0eiI4mEukYiS8FuAH9gaE=.bc60150a-b0a3-4135-870a-af76a52adec8@github.com>
Message-ID: <IwkKNZRBalzbpEASRQ2g6PshOq1JIHm_fWxYVtvUroQ=.46c2c1ad-bfa3-4fcc-ade5-08997adf2ceb@github.com>

On Tue, 13 May 2025 08:58:28 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Because it is backed by an array, the `ArrayDeque` class has the ability to get and replace any element in the list (accessed by index) in constant time. However, this capability is not exposed in the API.
>> 
>> Please review this PR which adds the following two new methods to `ArrayDeque`:
>> * `public E get(int index)`
>> * `public E set(int index, E element)`
>
> src/java.base/share/classes/java/util/ArrayDeque.java line 360:
> 
>> 358:      *
>> 359:      * @param index index of the element to return
>> 360:      * @return the element at the specified position in this deque
> 
> This?can?use the?inline?form of?`@return`:
> Suggestion:
> 
>      * {@return the element at the specified position in this deque}
>      *
>      * @param index index of the element to return

Indeed - thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25189#discussion_r2086995656

From amaembo at gmail.com  Tue May 13 15:22:50 2025
From: amaembo at gmail.com (Tagir Valeev)
Date: Tue, 13 May 2025 17:22:50 +0200
Subject: Finding max or min of exactly two objects
In-Reply-To: <55572e2c-a66c-4b76-a65d-c8fdf544be2f@oracle.com>
References: <CAE+3fja-oo=Yxxs9gQ9cTnCStYOBtf1oey3Dn6F2dNjbfievCg@mail.gmail.com>
 <55572e2c-a66c-4b76-a65d-c8fdf544be2f@oracle.com>
Message-ID: <CAE+3fjbF2WswJvYB=qz0JkYkoskaViaPDbHTzJrvpyX3tC6APQ@mail.gmail.com>

Hello, Brian!

On Tue, May 13, 2025 at 4:30?PM Brian Goetz <brian.goetz at oracle.com> wrote:
> So with that as background, I am very cautious to consider adding methods to Comparable, because it is a highly abstract type that was designed for extension, and the risk of the above kind of clash seems "not low".

Sure, extending the Comparable interface is a no-go. Comparable
implementations in the wild are often big classes with different
semantics and a lot of functionality. This means that the chance of
signature clash is high, and even if not, the names like 'max' or
'min' may not be the best choice for the user object that happens to
implement Comparable.

> Comparator seems less risky, because it is not designed to be extended by domain objects, but instead functions more like a type class in Haskell -- it is behavior _about_ a type, defined from the outside.  And Haskell would agree with you that this move is sensible; here's Haskell's `Ord` (like Comparator), which extends `Eq` (providing equality.)

Exactly, Comparator is less risky. Usually, user-defined comparators
have nothing except a `compare` method or very few additional methods
related to comparison. The Comparator's primary job is to compare, and
finding the minimum or the maximum of two objects is pretty much
related to comparison. In contrast, the primary job of Comparable
objects is often something else, other than being compared, and
implementing comparable is just a convenience, which is rarely
necessary.

> OK, "comparative languages" lesson over, back to your point.  There are two ways to get where you want: a static method that takes a comparator and the operands (`Comparator.max(c, a, b)`), or a default method on Comparator (`c.max(a, b)`).  (You say "add simple static methods ... to Comparator" but I think you mean to put the word `static` elsewhere in that sentence.)

Well, probably I formulated it not so clearly. I'd like to have the
following additions:

public interface Comparator<T> {
...
    default T max(T a, T b) {
        return compare(a, b) > 0 ? a : b;
    }

    default T min(T a, T b) {
        return compare(a, b) > 0 ? b : a;
    }

    static <T extends Comparable<T>> T max(T a, T b) {
        return a.compareTo(b) > 0 ? a : b;
    }

    static <T extends Comparable<T>> T min(T a, T b) {
        return a.compareTo(b) > 0 ? b : a;
    }
}

The static methods are not exactly related to the Comparator
interface. That's why I'm somewhat dubious about the proper place for
them (probably j.u.Objects fits better). They are just convenient
shortcuts for Comparator.naturalOrder().max(...) and
Comparator.naturalOrder().min(...) (and having one indirection less,
which sometimes might be helpful for performance). We can omit static
methods, keeping only default ones, so users will need to write fully
Comparator.naturalOrder().max(...). This is still better than what we
have today, but I think that natural order is an important enough
concept to have dedicated methods for it.

Passing a comparator as an argument to a static method (like
Comparator.max(c, a, b)) is possible and somewhat in-line with
existing APIs like Collections.max(coll[, comp]). However, I feel that
adding default method is better.

With best regards,
Tagir Valeev


>
> I am receptive to the idea of extending Comparator here, but would want to think about it more to feel out potential mistakes like the `andThen` one above.  But your point is solid: a "comparator" is also a "maxxer" and a "minner" (neither of those are words, and if they were, are probably spelled wrong), and that is a natural place to locate such behavior.
>
>
>
>
> On 5/13/2025 10:12 AM, Tagir Valeev wrote:
>
> Hello!
>
> Several times already when writing Java programs, I stumbled with a simple task: given two objects with natural order, find the maximal of them. The algorithm I need could be formulated like this:
>
>     <T extends Comparable<T>> T max(T a, T b) {
>         return a.compareTo(b) > 0 ? a : b;
>     }
>
> Writing manually compareTo >= 0 looks too verbose, not very readable and error-prone: one has to mention both objects twice, and it's possible to mix > with <. I can surely add a method mentioned above to a utility class in my project and use it everywhere. However, I feel that it deserves a place in the standard library.
>
> The alternatives we have now:
> BinaryOperator.maxBy(Comparator.<T>naturalOrder()).apply(a, b);
> This speaks clearly about the intent (we'd like to get the maximum and we write 'maxBy') but very wordy.
>
> Stream.of(a, b).max(Comparator.naturalOrder()).get();
> Also clear and a little bit shorter, but has an unnecessary Optional in-between (we know that we have at least one element, so the result is always present) and we have to mention the comparator. Finally, it might be much less efficient than expected.
>
> Probably we can add simple static methods `max` and `min` either to the `Comparator` interface, or to `java.util.Objects`? Such methods would complement methods from the `Math` class for numbers. In addition, having default methods `max` and `min` in the `Comparator` interface would also be nice:
>
> String bigger = String.CASE_INSENSITIVE_ORDER.max("Hello", "world");
>
> What do you think? Can we proceed with such an enhancement?
>
> With best regards,
> Tagir Valeev
>
>

From bpb at openjdk.org  Tue May 13 15:33:43 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 May 2025 15:33:43 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v18]
In-Reply-To: <MgSf88SFgz_Xjk14lqVo8avX-OzNupRGIgFmX7bjhZw=.f244aef2-2eeb-4895-b6f2-3c718cc306f0@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <ckd-UcxICCx3Zq-ehw1KBV7jQ3JfjX9jtZ0_DsxnlTE=.fb7f1026-cfa9-42a2-bf92-1622939a2b8d@github.com>
 <MgSf88SFgz_Xjk14lqVo8avX-OzNupRGIgFmX7bjhZw=.f244aef2-2eeb-4895-b6f2-3c718cc306f0@github.com>
Message-ID: <wZgd7DyAvnbI8N2kQTcTnNeb9zueV2c8xQYX41TPj7U=.01109b82-71df-4539-b886-9b207d0597b2@github.com>

On Tue, 13 May 2025 10:55:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
>> 
>>  - 8354724: Attempt to further improve verbiage
>>  - Merge
>>  - Update src/java.base/share/classes/java/io/Reader.java
>>    
>>    8354724: Apply suggested changes for readAllLines.
>>    
>>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>>  - Update src/java.base/share/classes/java/io/Reader.java
>>    
>>    8354724: Apply suggested changes for readAllAsString.
>>    
>>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>>  - 8354724: Revert BufferedReader; simplify Reader changes removing overridable self-call; update test
>>  - 8354724: Fix potential NPE in test
>>  - 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test
>>  - 8354724: Improve test per reviewer comments
>>  - 8354724: Add missing toList(), tweak verbiage; update test
>>  - 8354724: Add Reader.readAllLines; test not yet updated
>>  - ... and 11 more: https://git.openjdk.org/jdk/compare/58731a34...1d811589
>
> src/java.base/share/classes/java/io/Reader.java line 430:
> 
>> 428:      * <p> The behavior for the case where the reader is
>> 429:      * <i>asynchronously closed</i>, or the thread interrupted during the
>> 430:      * read, is highly input stream specific, and therefore not specified.
> 
> The carry over of this paragraph needs to replace "input stream" with reader (same thing in the other method).

Yeah, I slipped up bringing the words over from `InputStream`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2087105321

From bpb at openjdk.org  Tue May 13 15:33:39 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 May 2025 15:33:39 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@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: "stream" -> "reader"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/1d811589..98387b0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=17-18

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From bpb at openjdk.org  Tue May 13 15:33:39 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 May 2025 15:33:39 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v18]
In-Reply-To: <i10_MJ6IYd8p7eIEGD0qyehXU2SEIQXDmPFIb9a1ZnQ=.08e73c04-9993-4b88-b54a-afe29f84a1c8@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <ckd-UcxICCx3Zq-ehw1KBV7jQ3JfjX9jtZ0_DsxnlTE=.fb7f1026-cfa9-42a2-bf92-1622939a2b8d@github.com>
 <i10_MJ6IYd8p7eIEGD0qyehXU2SEIQXDmPFIb9a1ZnQ=.08e73c04-9993-4b88-b54a-afe29f84a1c8@github.com>
Message-ID: <iKFy3-mSvyrUrKNxstB0fl8HPR3COZ5EiEVvFYWbllI=.7442052e-c75a-42cb-8826-76f3711929a9@github.com>

On Tue, 13 May 2025 14:47:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> I think this (with fix above for stream -> reader) is ready to create the CSR ...

Will do today. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2876983943

From bpb at openjdk.org  Tue May 13 15:33:43 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 May 2025 15:33:43 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v18]
In-Reply-To: <wZgd7DyAvnbI8N2kQTcTnNeb9zueV2c8xQYX41TPj7U=.01109b82-71df-4539-b886-9b207d0597b2@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <ckd-UcxICCx3Zq-ehw1KBV7jQ3JfjX9jtZ0_DsxnlTE=.fb7f1026-cfa9-42a2-bf92-1622939a2b8d@github.com>
 <MgSf88SFgz_Xjk14lqVo8avX-OzNupRGIgFmX7bjhZw=.f244aef2-2eeb-4895-b6f2-3c718cc306f0@github.com>
 <wZgd7DyAvnbI8N2kQTcTnNeb9zueV2c8xQYX41TPj7U=.01109b82-71df-4539-b886-9b207d0597b2@github.com>
Message-ID: <BV4fnHaT_6STvK0N46l5xRLjsSWRrciRKe4BwTNetg8=.a77610ad-ad68-4c5c-8d6a-37fb5b4082d6@github.com>

On Tue, 13 May 2025 15:25:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 430:
>> 
>>> 428:      * <p> The behavior for the case where the reader is
>>> 429:      * <i>asynchronously closed</i>, or the thread interrupted during the
>>> 430:      * read, is highly input stream specific, and therefore not specified.
>> 
>> The carry over of this paragraph needs to replace "input stream" with reader (same thing in the other method).
>
> Yeah, I slipped up bringing the words over from `InputStream`.

Fixed in 98387b0.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2087112048

From brian.goetz at oracle.com  Tue May 13 15:52:57 2025
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 13 May 2025 11:52:57 -0400
Subject: Finding max or min of exactly two objects
In-Reply-To: <CAE+3fjbF2WswJvYB=qz0JkYkoskaViaPDbHTzJrvpyX3tC6APQ@mail.gmail.com>
References: <CAE+3fja-oo=Yxxs9gQ9cTnCStYOBtf1oey3Dn6F2dNjbfievCg@mail.gmail.com>
 <55572e2c-a66c-4b76-a65d-c8fdf544be2f@oracle.com>
 <CAE+3fjbF2WswJvYB=qz0JkYkoskaViaPDbHTzJrvpyX3tC6APQ@mail.gmail.com>
Message-ID: <9d4e48a1-a079-4539-a0b9-c18a8afddc8b@oracle.com>

> Well, probably I formulated it not so clearly. I'd like to have the
> following additions:
>
> public interface Comparator<T> {
> ...
>      default T max(T a, T b) {
>          return compare(a, b) > 0 ? a : b;
>      }
>
>      default T min(T a, T b) {
>          return compare(a, b) > 0 ? b : a;
>      }
>
>      static <T extends Comparable<T>> T max(T a, T b) {
>          return a.compareTo(b) > 0 ? a : b;
>      }
>
>      static <T extends Comparable<T>> T min(T a, T b) {
>          return a.compareTo(b) > 0 ? b : a;
>      }
> }

Let's separate these.? I think the first two have a good claim to be in 
Comparator; I think the latter two probably live better in Comparable, 
which feels like a separate conversation (and maybe less important?)?? 
(And also, there's some overlap with some yet-uncollapsed stuff going on 
in Valhalla that I'd like to steer clear of.)





From alanb at openjdk.org  Tue May 13 15:53:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 May 2025 15:53:58 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v7]
In-Reply-To: <RAcEfEBZgn1o13wOeDQi9KG7s8koI8uizmFVGhqw0sk=.f65f7f8a-b8cf-4bbe-9dbd-8838e92453c6@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <RAcEfEBZgn1o13wOeDQi9KG7s8koI8uizmFVGhqw0sk=.f65f7f8a-b8cf-4bbe-9dbd-8838e92453c6@github.com>
Message-ID: <U599_ZS8FpDAEVeJ2lg1c6pQkoKnQ0ZlSbSoCMjDEnI=.79f4f6ff-306e-403f-ae49-10e71bd26855@github.com>

On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request with a new target base 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:
> 
>  - Merge remote-tracking branch 'upstream/master' into jla
>  - Improve `uncheckedGetBytesNoRepl` docs
>  - Apply suggestions from code review
>    
>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>  - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
>  - Fix `HexDigits` copyright year
>  - Fix copyright years
>  - Prefix touched methods with `unchecked`
>  - Fix typo in pre-existing JavaDoc
>  - Improve `JavaLangAccess` documentation

src/java.base/share/classes/java/lang/System.java line 2113:

> 2111: 
> 2112:             public int uncheckedCountPositives(byte[] bytes, int offset, int length) {
> 2113:                 return StringCoding.countPositives(bytes, offset, length);

The prefix means the method is uncheckedXXX when outside of java.lang, and XXX when in java.lang. Okay for this PR but I think we should follow-up and rename the methods in java.lang to uncheckedXXX, then introduce checked versions that do the bounds check.  In this case, we could have countPositives exposed via JLA, its implementation would do the bounds check before calling the unchecked version.  It would mean that "far away" callers in DIS, OIS, ZipCoder, ... would have a bounds check but it would make things easier to audit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2087154008

From naoto at openjdk.org  Tue May 13 16:23:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 May 2025 16:23:55 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v6]
In-Reply-To: <zE3BSueBiyvogX6S7fMMSUoe7bn5NTMf11_kH39xfLw=.5630b3f0-1178-4d54-a905-b02863ae8a85@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <VwNp5Cm91ConpVD6zzob2uwVNNf5GuUc7s6mVeefp0g=.13138944-a496-4487-b906-3eb4b69f28f7@github.com>
 <3ey9JGc8I3CPIi98S4kUZeKAVhmMw4nohRwU3-y9MBc=.a2fef848-06e1-4c4e-bfef-0e0a53bdc6f1@github.com>
 <zE3BSueBiyvogX6S7fMMSUoe7bn5NTMf11_kH39xfLw=.5630b3f0-1178-4d54-a905-b02863ae8a85@github.com>
Message-ID: <QIKLVuD1u4opO4fER0mSZLC5h4lF3xtrXbu4VO-eYqE=.195dcf4b-0265-43e1-b866-19f28800a625@github.com>

On Tue, 13 May 2025 12:34:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/InputStreamReader.java line 59:
>> 
>>> 57:  *     new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
>>> 58:  * }
>>> 59:  *
>> 
>> There are several places in the sources that still contain `new InputStreamReader(System.in)`. Shouldn't they be replaced with `new InputStreamReader(System.in, System.getProperty("stdin.encoding"))` too?)
>
> How did you search for those sources? I searched for literal `System.in` and my comments are the only ones I could find in the JDK.

There are several locations in the jdk source (I simply grep'ed for `new InputStreamReader(System.in)`). And yes, they will need to be replaced with the recommended usage. I will address them with a different JBS issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2087206716

From aph at openjdk.org  Tue May 13 16:27:41 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 13 May 2025 16:27:41 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v5]
In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
Message-ID: <u5HgKizXjbzUgzm2XE2RtY9iuEBohKqlrTruMDzKyQg=.ca3cddcf-909a-4f33-b082-dcf9eaba7ccb@github.com>

> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
> 
> 
> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op

Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:

 - Copyright
 - Remove AArch64 exception from native threshold

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25147/files
  - new: https://git.openjdk.org/jdk/pull/25147/files/23838f8b..87eadb40

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=03-04

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25147/head:pull/25147

PR: https://git.openjdk.org/jdk/pull/25147

From aph at openjdk.org  Tue May 13 16:27:41 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 13 May 2025 16:27:41 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v2]
In-Reply-To: <6iRBKELx-Xnkgfm4MbONISmz9D3SjO_38PlaQXijv7w=.d6cb630c-7e83-4695-9ccc-6cfa30da5e17@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
 <bnf8iIIZzedQLKLZSnqIeoVz_C-YTIEIVDKqCVFT_qY=.cdd3180a-7062-4a3d-882e-2e8de719d5ff@github.com>
 <xZsmD7wHsVKZ64HybXNJX5JDHHDASkPcv8mtkm331zU=.345ade62-4784-45a9-a79f-25ab0bc3a66c@github.com>
 <6iRBKELx-Xnkgfm4MbONISmz9D3SjO_38PlaQXijv7w=.d6cb630c-7e83-4695-9ccc-6cfa30da5e17@github.com>
Message-ID: <wye3Ap0WnqipYOTpDWWzSFv0CpkNDTy6IRxVPeKAFpk=.23d3d487-68ca-42fc-be82-0f27e4f2f901@github.com>

On Mon, 12 May 2025 09:39:48 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > Looking at the improvements made, I suggest we also change (in `SegmentBulkOperations`):
> > ```
> > private static final int NATIVE_THRESHOLD_FILL = powerOfPropertyOr("fill", Architecture.isAARCH64() ? 18 : 5); 
> > ```
> > to
> > ```
> >  private static final int NATIVE_THRESHOLD_FILL = powerOfPropertyOr("fill",  5);
> > ```
> 
> Possibly so, yes, but I'm still looking at the reasons for the differences.

OK, I've done that. Numbers below, and I think that makes the cut between Java code and the intrinsic at the right place.


Benchmark                           (aligned)  (size)  Mode  Cnt  Score   Error  Units
MemorySegmentFillUnsafe.panama           true       1  avgt   10  1.522 ? 0.004  ns/op
MemorySegmentFillUnsafe.panama           true       2  avgt   10  1.385 ? 0.003  ns/op
MemorySegmentFillUnsafe.panama           true       3  avgt   10  1.387 ? 0.003  ns/op
MemorySegmentFillUnsafe.panama           true       4  avgt   10  1.520 ? 0.004  ns/op
MemorySegmentFillUnsafe.panama           true       5  avgt   10  1.530 ? 0.007  ns/op
MemorySegmentFillUnsafe.panama           true       6  avgt   10  1.523 ? 0.003  ns/op
MemorySegmentFillUnsafe.panama           true       7  avgt   10  1.538 ? 0.010  ns/op
MemorySegmentFillUnsafe.panama           true       8  avgt   10  1.663 ? 0.014  ns/op
MemorySegmentFillUnsafe.panama           true      15  avgt   10  1.940 ? 0.005  ns/op
MemorySegmentFillUnsafe.panama           true      16  avgt   10  1.812 ? 0.007  ns/op
MemorySegmentFillUnsafe.panama           true      63  avgt   10  2.332 ? 0.005  ns/op
MemorySegmentFillUnsafe.panama           true      64  avgt   10  2.157 ? 0.009  ns/op
MemorySegmentFillUnsafe.panama           true     255  avgt   10  3.857 ? 0.057  ns/op
MemorySegmentFillUnsafe.panama           true     256  avgt   10  3.506 ? 0.015  ns/op
MemorySegmentFillUnsafe.panama          false       1  avgt   10  1.522 ? 0.005  ns/op
MemorySegmentFillUnsafe.panama          false       2  avgt   10  1.384 ? 0.004  ns/op
MemorySegmentFillUnsafe.panama          false       3  avgt   10  1.386 ? 0.004  ns/op
MemorySegmentFillUnsafe.panama          false       4  avgt   10  1.520 ? 0.004  ns/op
MemorySegmentFillUnsafe.panama          false       5  avgt   10  1.528 ? 0.009  ns/op
MemorySegmentFillUnsafe.panama          false       6  avgt   10  1.525 ? 0.004  ns/op
MemorySegmentFillUnsafe.panama          false       7  avgt   10  1.533 ? 0.003  ns/op
MemorySegmentFillUnsafe.panama          false       8  avgt   10  1.665 ? 0.004  ns/op
MemorySegmentFillUnsafe.panama          false      15  avgt   10  1.941 ? 0.004  ns/op
MemorySegmentFillUnsafe.panama          false      16  avgt   10  1.811 ? 0.008  ns/op
MemorySegmentFillUnsafe.panama          false      63  avgt   10  2.332 ? 0.006  ns/op
MemorySegmentFillUnsafe.panama          false      64  avgt   10  2.152 ? 0.005  ns/op
MemorySegmentFillUnsafe.panama          false     255  avgt   10  5.040 ? 0.041  ns/op
MemorySegmentFillUnsafe.panama          false     256  avgt   10  4.859 ? 0.040  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2877178492

From alanb at openjdk.org  Tue May 13 16:28:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 May 2025 16:28:01 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v8]
In-Reply-To: <fHBCE8kw7jUn9gc4R0o8v0PQbsCYWTvxkNJpGji7744=.a77cb139-35b4-492f-83a2-bb5a28eac32d@github.com>
References: <d-bbTH1lsG4Ev7_sNutKMbLBTXXyQ75ZQTbNvgJkqBQ=.06f597ba-1313-4bb4-9947-880e73acd5bf@github.com>
 <fHBCE8kw7jUn9gc4R0o8v0PQbsCYWTvxkNJpGji7744=.a77cb139-35b4-492f-83a2-bb5a28eac32d@github.com>
Message-ID: <LgEWnLQKbC5VzJp-Bg7muMPgTsRbnDWZ49qgVj_xphQ=.7b2d3e62-1597-4c59-b702-fa43a177db7f@github.com>

On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
>> 
>> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
>> 
>> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
>> 
>> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's review - update code comment in the test

The implementation changes look good and nice to get this one fixed.

I didn't spend time on the tests but I see others have reviewed in detail so you don't need me.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23986#pullrequestreview-2837419251

From jpai at openjdk.org  Tue May 13 16:28:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 May 2025 16:28:53 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: <ty23rwTu8HuiUpJIiK3JlOeGZcIl-5iJBQkeZYksrXs=.8a6ca6d0-948a-490e-a58d-0247c1024c5c@github.com>

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 208:

> 206:         boolean shouldCreate = isTrue(env, "create");
> 207:         if (shouldCreate && forceReadOnly) {
> 208:             throw new IllegalArgumentException(

Although `IllegalArgumentException` seems reasonable here, the current contract of this constructor is to throw `IOException` and that then gets propagated through the public `FileSystemProvider.newFileSystem(...)` API which is specified to throw `IOException`.

So we will either have to throw `IOException` here (preferable) or we have to catch `IllegalArgumentException` at the call sites of this constructor and then rethrow it as a `IOException`, to prevent the unspecified `IllegalArgumentException` propagating out of the `FileSystemProvider.newFileSystem(...)` API.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2087216326

From alanb at openjdk.org  Tue May 13 16:39:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 May 2025 16:39:51 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <ty23rwTu8HuiUpJIiK3JlOeGZcIl-5iJBQkeZYksrXs=.8a6ca6d0-948a-490e-a58d-0247c1024c5c@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <ty23rwTu8HuiUpJIiK3JlOeGZcIl-5iJBQkeZYksrXs=.8a6ca6d0-948a-490e-a58d-0247c1024c5c@github.com>
Message-ID: <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com>

On Tue, 13 May 2025 16:26:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 208:
> 
>> 206:         boolean shouldCreate = isTrue(env, "create");
>> 207:         if (shouldCreate && forceReadOnly) {
>> 208:             throw new IllegalArgumentException(
> 
> Although `IllegalArgumentException` seems reasonable here, the current contract of this constructor is to throw `IOException` and that then gets propagated through the public `FileSystemProvider.newFileSystem(...)` API which is specified to throw `IOException`.
> 
> So we will either have to throw `IOException` here (preferable) or we have to catch `IllegalArgumentException` at the call sites of this constructor and then rethrow it as a `IOException`, to prevent the unspecified `IllegalArgumentException` propagating out of the `FileSystemProvider.newFileSystem(...)` API.

I checked the overloads of newFileSystem that were added in JDK 13 and somehow the `@throws IllegalArgumentException` was missed. It's declared by the methods that take a URI + env but not methods that take a Path + env. We should fix that, then the IAE from the zip provider won't be a surprise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2087233643

From naoto at openjdk.org  Tue May 13 17:02:54 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 May 2025 17:02:54 GMT
Subject: RFR: 8352755: Misconceptions about j.text.DecimalFormat digits
 during parsing [v3]
In-Reply-To: <3SUlt-xiFDfPWHDJwbvMeUfONvc4zm5gwUlgiQGM8xg=.ae8b7ae7-37b4-4d67-b633-bfbb3565fd22@github.com>
References: <DbSlspa3gs2Bi6EzhpNX6NpcgO3kSp3SkJS39jKJXmI=.41a4afcc-f083-4332-ba05-3a2f4e2dc795@github.com>
 <3SUlt-xiFDfPWHDJwbvMeUfONvc4zm5gwUlgiQGM8xg=.ae8b7ae7-37b4-4d67-b633-bfbb3565fd22@github.com>
Message-ID: <U0ADt3Li6Zm2dDpsH7-X7ODlLKbJw7XnXYDAsmdwgMY=.775d325e-84ef-468f-b305-d25edd751bb9@github.com>

On Thu, 8 May 2025 18:07:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which clarifies the behavior for integer and fraction limits in NumberFormat and implementing classes. An associated CSR is filed.
>> 
>> There have been a few bugs submitted which indicate a misconception that these limits impact parsing. The actual behavior is that these limits only affect formatting. The specification is vague regarding this, and can be explicitly updated to eliminate confusion. As the implementing classes are updated to use `inheritDoc`, some shuffling around in the method specs are included in this change as well.
>> 
>> Alternatively I considered making this change as implementation specific to DecimalFormat and CompactNumberFormat only. (i.e. leave flexibility for other NumberFormat subclasses to define their own behavior on whether the limits affect parsing.) I am open to this option as well, but initially decided against it as 
>> 1) Unlike formatting, it seems like a rare use case that you would want to suppress the range of digits of accepted during parsing. `setParseIntegerOnly()` already provides functionality to toggle between integer and fraction parsing.
>> 2) The limits affecting formatting only has been the long-standing behavior for all the subclasses of NumberFormat provided by the OpenJDK reference implementation.
>
> Justin Lu has updated the pull request with a new target base 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:
> 
>  - CSR review - directed inheritDoc; make 'concrete subclass' wording normative
>  - Merge branch 'master' into JDK-8352755-limit-clarifications
>  - Merge branch 'master' into JDK-8352755-limit-clarifications
>  - Naoto's review: apiN -> implN. Rewording of maxintdig callout
>  - init

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24265#pullrequestreview-2837519548

From bchristi at openjdk.org  Tue May 13 17:07:58 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 13 May 2025 17:07:58 GMT
Subject: Integrated: 8356107: [java.lang] Use @requires tag instead of exiting
 based on os.name or separatorChar property
In-Reply-To: <tZiBKIvIBGsfgLaEtvf87nGGC4cdBrLkPYMNRlIHg1Q=.bcc1ff0b-ca04-4adc-9f61-9641c33f1807@github.com>
References: <tZiBKIvIBGsfgLaEtvf87nGGC4cdBrLkPYMNRlIHg1Q=.bcc1ff0b-ca04-4adc-9f61-9641c33f1807@github.com>
Message-ID: <a-ov7lotrAT__FUs5yu-8_J9YRnL4KgQ1KqAPup5JnI=.7a3d4b2a-a225-49c9-b162-52b1c38e1e6a@github.com>

On Fri, 9 May 2025 23:23:27 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> For `java.lang` tests, use the `@requires` facility in place of checking the `os.name` system property or `File.separatorChar`.
> 
> Automated test results are omitted as expected.

This pull request has now been integrated.

Changeset: d1543429
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d1543429ff29ca0d761b8473b3fb8621abcd226d
Stats:     82 lines in 4 files changed: 3 ins; 73 del; 6 mod

8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property

Reviewed-by: naoto, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/25163

From duke at openjdk.org  Tue May 13 17:26:08 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 13 May 2025 17:26:08 GMT
Subject: RFR: 8077587: BigInteger Roots [v13]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <PZsoG86C5XmLdnNgW4KoaT1pT60oOXgvWkmq_A-TfG0=.baf13edf-bdb3-44e3-a101-e2e3fddb2b85@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Code simplification

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/0cfb4f65..32a5e5ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=11-12

  Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From forax at openjdk.org  Tue May 13 17:39:55 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 13 May 2025 17:39:55 GMT
Subject: RFR: 8143850: Add indexed get() and set() methods to ArrayDeque
In-Reply-To: <FqQcbJZGky9kSxgufXkrarVqOWIddA41Y_1fN0ZOL4k=.246fb74c-ba6e-417c-adf3-cde5b8e785f9@github.com>
References: <FqQcbJZGky9kSxgufXkrarVqOWIddA41Y_1fN0ZOL4k=.246fb74c-ba6e-417c-adf3-cde5b8e785f9@github.com>
Message-ID: <oqf2paZERtnkegQfSVp1dKT6floxgUdxyoZMkyhYnaA=.9ada9fb1-e910-41c5-b64f-bca911ed40f9@github.com>

On Mon, 12 May 2025 18:24:27 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Because it is backed by an array, the `ArrayDeque` class has the ability to get and replace any element in the list (accessed by index) in constant time. However, this capability is not exposed in the API.
> 
> Please review this PR which adds the following two new methods to `ArrayDeque`:
> * `public E get(int index)`
> * `public E set(int index, E element)`

src/java.base/share/classes/java/util/ArrayDeque.java line 384:

> 382:     public E set(int index, E element) {
> 383:         if (element == null)
> 384:             throw new NullPointerException();

please add curly braces around `throw ...` as described in the style guide.

src/java.base/share/classes/java/util/ArrayDeque.java line 388:

> 386:     }
> 387: 
> 388:     private E getset(int index, E newValue) {

Please keep the implementation simple and avoid this kind of tricks, we are not sure in the future if E will be forever nullable so calling getset(index, null) may not be valid in the future.

test/jdk/java/util/ArrayDeque/IndexedAccess.java line 38:

> 36: 
> 37: public class IndexedAccess {
> 38: 

I think some tests are missing, if the ArrayDeque is empty, if the ArrayDeque is full, at least

test/jdk/java/util/ArrayDeque/IndexedAccess.java line 75:

> 73: 
> 74:         try {
> 75:             a.set(0, null);

assertThrow ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25189#discussion_r2087336980
PR Review Comment: https://git.openjdk.org/jdk/pull/25189#discussion_r2087335755
PR Review Comment: https://git.openjdk.org/jdk/pull/25189#discussion_r2087338994
PR Review Comment: https://git.openjdk.org/jdk/pull/25189#discussion_r2087337713

From duke at openjdk.org  Tue May 13 18:02:03 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 13 May 2025 18:02:03 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations
Message-ID: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>

Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

-------------

Commit messages:
 - More clear comment
 - An optimization
 - Code simplification
 - Code simplification
 - Avoiding redundant code
 - Code simplification
 - Code simplifications for BigIntegers' bit operations

Changes: https://git.openjdk.org/jdk/pull/25166/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356891
  Stats: 83 lines in 1 file changed: 14 ins; 36 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From rgiulietti at openjdk.org  Tue May 13 18:02:03 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 13 May 2025 18:02:03 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <lM1C7zULsNgBmap7oj64lN74xiUfC5rPWDmfkqy2A-g=.fef6f6c9-5c06-4e3e-9edd-4f77664a49fc@github.com>

On Sat, 10 May 2025 16:41:17 GMT, fabioromano1 <duke at openjdk.org> wrote:

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

@fabioromano1 While reviewers can of course file JBS issues on behalf of contributors, the recommende way is for the latter to file a [bug report](https://bugreport.java.com/bugreport/), as they know what they will work on better than anyone else.

Contributors that are [JDK Project](https://openjdk.org/census#jdk) [authors](https://openjdk.org/guide/#becoming-an-author) can file [here](https://bugs.openjdk.org/).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2872531149

From duke at openjdk.org  Tue May 13 18:02:04 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 13 May 2025 18:02:04 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations
In-Reply-To: <lM1C7zULsNgBmap7oj64lN74xiUfC5rPWDmfkqy2A-g=.fef6f6c9-5c06-4e3e-9edd-4f77664a49fc@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <lM1C7zULsNgBmap7oj64lN74xiUfC5rPWDmfkqy2A-g=.fef6f6c9-5c06-4e3e-9edd-4f77664a49fc@github.com>
Message-ID: <kC6Y6cB5Q02Yh0PIbSRd47rddN_NpAUEcrrFT5aywug=.7e06f401-1bcb-4103-9e20-8747dc0b4568@github.com>

On Mon, 12 May 2025 13:13:36 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.
>
> @fabioromano1 While reviewers can of course file JBS issues on behalf of contributors, the recommende way is for the latter to file a [bug report](https://bugreport.java.com/bugreport/), as they know what they will work on better than anyone else.
> 
> Contributors that are [JDK Project](https://openjdk.org/census#jdk) [authors](https://openjdk.org/guide/#becoming-an-author) can file [here](https://bugs.openjdk.org/).

@rgiulietti I've submitted a bug report for the PR right now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2872641531

From rgiulietti at openjdk.org  Tue May 13 18:02:04 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 13 May 2025 18:02:04 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations
In-Reply-To: <kC6Y6cB5Q02Yh0PIbSRd47rddN_NpAUEcrrFT5aywug=.7e06f401-1bcb-4103-9e20-8747dc0b4568@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <lM1C7zULsNgBmap7oj64lN74xiUfC5rPWDmfkqy2A-g=.fef6f6c9-5c06-4e3e-9edd-4f77664a49fc@github.com>
 <kC6Y6cB5Q02Yh0PIbSRd47rddN_NpAUEcrrFT5aywug=.7e06f401-1bcb-4103-9e20-8747dc0b4568@github.com>
Message-ID: <wngIOThuTW9zocePOuXhOTkQSJnQi8ZZCQPkUmqsYh4=.47c0eeda-ee35-4bfa-8f3c-956d3907bbf4@github.com>

On Mon, 12 May 2025 13:45:08 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> @fabioromano1 While reviewers can of course file JBS issues on behalf of contributors, the recommende way is for the latter to file a [bug report](https://bugreport.java.com/bugreport/), as they know what they will work on better than anyone else.
>> 
>> Contributors that are [JDK Project](https://openjdk.org/census#jdk) [authors](https://openjdk.org/guide/#becoming-an-author) can file [here](https://bugs.openjdk.org/).
>
> @rgiulietti I've submitted a bug report for the PR right now.

@fabioromano1 FYI, your bug report landed now as [JDK-8356891](https://bugs.openjdk.org/browse/JDK-8356891).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2877471956

From duke at openjdk.org  Tue May 13 18:02:04 2025
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 13 May 2025 18:02:04 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <NUbW6-6DpZzjcBr7p19C04Y5l8W3-aUBKVYroyY73XU=.9145946b-6f11-46c2-9f9f-6ade33b22e52@github.com>

On Sat, 10 May 2025 16:41:17 GMT, fabioromano1 <duke at openjdk.org> wrote:

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

src/java.base/share/classes/java/math/BigInteger.java line 2642:

> 2640:         }
> 2641:         // (this.abs().bitLength() - 1L) * exponent + 1L > Integer.MAX_VALUE
> 2642:         if (scaleFactor + bitsToShift - exponent >= Integer.MAX_VALUE) {

If this is overflow sensitive code, should this avoid adding on the left hand side?

Suggestion:

        if (scaleFactor - exponent >= Integer.MAX_VALUE - bitsToShift) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2083701393

From liach at openjdk.org  Tue May 13 18:02:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 May 2025 18:02:05 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations
In-Reply-To: <NUbW6-6DpZzjcBr7p19C04Y5l8W3-aUBKVYroyY73XU=.9145946b-6f11-46c2-9f9f-6ade33b22e52@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <NUbW6-6DpZzjcBr7p19C04Y5l8W3-aUBKVYroyY73XU=.9145946b-6f11-46c2-9f9f-6ade33b22e52@github.com>
Message-ID: <qOwahLcpkxHq24y_TR6V61hBqTCNFduj-QdKBYtgD74=.fcb14f16-5b85-465f-bf18-9e60f353a44b@github.com>

On Mon, 12 May 2025 01:46:25 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.
>
> src/java.base/share/classes/java/math/BigInteger.java line 2642:
> 
>> 2640:         }
>> 2641:         // (this.abs().bitLength() - 1L) * exponent + 1L > Integer.MAX_VALUE
>> 2642:         if (scaleFactor + bitsToShift - exponent >= Integer.MAX_VALUE) {
> 
> If this is overflow sensitive code, should this avoid adding on the left hand side?
> 
> Suggestion:
> 
>         if (scaleFactor - exponent >= Integer.MAX_VALUE - bitsToShift) {

I think we are fine here, `scaleFactor` is already `long`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2083704486

From duke at openjdk.org  Tue May 13 18:02:05 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 13 May 2025 18:02:05 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations
In-Reply-To: <qOwahLcpkxHq24y_TR6V61hBqTCNFduj-QdKBYtgD74=.fcb14f16-5b85-465f-bf18-9e60f353a44b@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <NUbW6-6DpZzjcBr7p19C04Y5l8W3-aUBKVYroyY73XU=.9145946b-6f11-46c2-9f9f-6ade33b22e52@github.com>
 <qOwahLcpkxHq24y_TR6V61hBqTCNFduj-QdKBYtgD74=.fcb14f16-5b85-465f-bf18-9e60f353a44b@github.com>
Message-ID: <Qg4Zjj8EZ6AzKiVuM0THYf02naWk1P2a8NtqXZUaqp0=.6e5c81c6-1733-47ee-9f8a-77736abc8b4f@github.com>

On Mon, 12 May 2025 01:52:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 2642:
>> 
>>> 2640:         }
>>> 2641:         // (this.abs().bitLength() - 1L) * exponent + 1L > Integer.MAX_VALUE
>>> 2642:         if (scaleFactor + bitsToShift - exponent >= Integer.MAX_VALUE) {
>> 
>> If this is overflow sensitive code, should this avoid adding on the left hand side?
>> 
>> Suggestion:
>> 
>>         if (scaleFactor - exponent >= Integer.MAX_VALUE - bitsToShift) {
>
> I think we are fine here, `scaleFactor` is already `long`

> If this is overflow sensitive code, should this avoid adding on the left hand side?

`scaleFactor` is a `long`, so `scaleFactor + bitsToShift - exponent == (bitLength() - 1L) * exponent`. Moreover, `scaleFactor + bitsToShift == (long) bitLength() * exponent`, so it does not oveflow a `long`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2084057073

From liach at openjdk.org  Tue May 13 18:02:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 May 2025 18:02:05 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <HgbqvcQuiAjrsYD6iDyUuJ7DrAGtpTKBm88c5vFZSb0=.a05c9795-5323-44ef-a721-e1ae0e342de3@github.com>

On Sat, 10 May 2025 16:41:17 GMT, fabioromano1 <duke at openjdk.org> wrote:

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

src/java.base/share/classes/java/math/BigInteger.java line 2828:

> 2826:      * assuming there are no leading zero ints.
> 2827:      */
> 2828:     private static int bitLength(int[] val, int len) {

This should really be refactored to an instance method `bitLengthUnsigned` or `magBitCount`: the `len` is always `val.length` and the `val` is always the `mag` array of some `BigInteger` from somewhere. Making this an instance method makes code cleaner and allows us to cache if we find this calculation expensive.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2083561722

From duke at openjdk.org  Tue May 13 18:02:05 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 13 May 2025 18:02:05 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations
In-Reply-To: <HgbqvcQuiAjrsYD6iDyUuJ7DrAGtpTKBm88c5vFZSb0=.a05c9795-5323-44ef-a721-e1ae0e342de3@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <HgbqvcQuiAjrsYD6iDyUuJ7DrAGtpTKBm88c5vFZSb0=.a05c9795-5323-44ef-a721-e1ae0e342de3@github.com>
Message-ID: <ehTprrFymDcl4Xph9H0wzy3gl3f67qnR-HpqInj84yo=.c1cc3379-0bc7-47ab-9e5f-2f078096eb24@github.com>

On Sun, 11 May 2025 16:00:55 GMT, Chen Liang <liach at openjdk.org> wrote:

> This should really be refactored to an instance method `bitLengthUnsigned` or `magBitCount`

I would prefer `magBitLength` as a name, since `bitCount` is usually referred to one's bit count. But before do this, I'd hear the opinion of @rgiulietti about that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2083563140

From duke at openjdk.org  Tue May 13 18:02:05 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 13 May 2025 18:02:05 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations
In-Reply-To: <ehTprrFymDcl4Xph9H0wzy3gl3f67qnR-HpqInj84yo=.c1cc3379-0bc7-47ab-9e5f-2f078096eb24@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <HgbqvcQuiAjrsYD6iDyUuJ7DrAGtpTKBm88c5vFZSb0=.a05c9795-5323-44ef-a721-e1ae0e342de3@github.com>
 <ehTprrFymDcl4Xph9H0wzy3gl3f67qnR-HpqInj84yo=.c1cc3379-0bc7-47ab-9e5f-2f078096eb24@github.com>
Message-ID: <dM4LA3Xlb3KQUUngxNlrQbOrfMpKC0IAJffIZIf1FW0=.295dffa4-da22-4d23-8dc2-3dc404ccaade@github.com>

On Sun, 11 May 2025 16:08:25 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 2828:
>> 
>>> 2826:      * assuming there are no leading zero ints.
>>> 2827:      */
>>> 2828:     private static int bitLength(int[] val, int len) {
>> 
>> This should really be refactored to an instance method `bitLengthUnsigned` or `magBitCount`: the `len` is always `val.length` and the `val` is always the `mag` array of some `BigInteger` from somewhere. Making this an instance method makes code cleaner and allows us to cache if we find this calculation expensive.
>
>> This should really be refactored to an instance method `bitLengthUnsigned` or `magBitCount`
> 
> I would prefer `magBitLength` as a name, since `bitCount` is usually referred to one's bit count. But before do this, I'd hear the opinion of @rgiulietti about that.

> Making this an instance method makes code cleaner and allows us to cache if we find this calculation expensive.

I recall that `bitLength` is already cached, so it would be preferable to replace `bitLength`'s cache with `magBitLength`'s cache if we want to do so.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2083564019

From duke at openjdk.org  Tue May 13 18:02:05 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 13 May 2025 18:02:05 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations
In-Reply-To: <dM4LA3Xlb3KQUUngxNlrQbOrfMpKC0IAJffIZIf1FW0=.295dffa4-da22-4d23-8dc2-3dc404ccaade@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <HgbqvcQuiAjrsYD6iDyUuJ7DrAGtpTKBm88c5vFZSb0=.a05c9795-5323-44ef-a721-e1ae0e342de3@github.com>
 <ehTprrFymDcl4Xph9H0wzy3gl3f67qnR-HpqInj84yo=.c1cc3379-0bc7-47ab-9e5f-2f078096eb24@github.com>
 <dM4LA3Xlb3KQUUngxNlrQbOrfMpKC0IAJffIZIf1FW0=.295dffa4-da22-4d23-8dc2-3dc404ccaade@github.com>
Message-ID: <ROlJ4Fb6FyRFkCZGCPdNEc6mlBhdUqULsL0TZLjb-f8=.832dc1ba-5269-48f1-9f4c-a4802dcc56d7@github.com>

On Sun, 11 May 2025 16:12:38 GMT, fabioromano1 <duke at openjdk.org> wrote:

>>> This should really be refactored to an instance method `bitLengthUnsigned` or `magBitCount`
>> 
>> I would prefer `magBitLength` as a name, since `bitCount` is usually referred to one's bit count. But before do this, I'd hear the opinion of @rgiulietti about that.
>
>> Making this an instance method makes code cleaner and allows us to cache if we find this calculation expensive.
> 
> I recall that `bitLength` is already cached, so it would be preferable to replace `bitLength`'s cache with `magBitLength`'s cache if we want to do so.

> the `len` is always `val.length` and the `val` is always the `mag` array of some `BigInteger` from somewhere.

Yes, but making it an instance method could be too narrowing, as sometimes in the code `int[]` array local variables are used in preference of `mag` instance fields.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2083567353

From almatvee at openjdk.org  Tue May 13 18:08:58 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 13 May 2025 18:08:58 GMT
Subject: Integrated: 8356819: [macos] MacSign should use "openssl" and
 "faketime" from Homebrew by default
In-Reply-To: <jEwKDDQdZMgD0e3COH80ToqMISmNetDLzavuybWGsbM=.f6c3dfbf-a6c1-4d92-b61e-0ca3a778b9b2@github.com>
References: <jEwKDDQdZMgD0e3COH80ToqMISmNetDLzavuybWGsbM=.f6c3dfbf-a6c1-4d92-b61e-0ca3a778b9b2@github.com>
Message-ID: <Ot3WgMqMfdbu7RnzRddF-r29HziQRKZu1DzWufiZUio=.15ad7dd2-4484-4941-8d4e-f946988ea823@github.com>

On Tue, 13 May 2025 00:30:08 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> `openssl` from macOS will ignore `faketime` and as result expired certificates will not be generated correctly. By default we should use these tools from Homebrew.

This pull request has now been integrated.

Changeset: 1569925a
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1569925af49552268c4847bd201fb95e0e3819b7
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/25196

From naoto at openjdk.org  Tue May 13 18:25:58 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 May 2025 18:25:58 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v6]
In-Reply-To: <QIKLVuD1u4opO4fER0mSZLC5h4lF3xtrXbu4VO-eYqE=.195dcf4b-0265-43e1-b866-19f28800a625@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <VwNp5Cm91ConpVD6zzob2uwVNNf5GuUc7s6mVeefp0g=.13138944-a496-4487-b906-3eb4b69f28f7@github.com>
 <3ey9JGc8I3CPIi98S4kUZeKAVhmMw4nohRwU3-y9MBc=.a2fef848-06e1-4c4e-bfef-0e0a53bdc6f1@github.com>
 <zE3BSueBiyvogX6S7fMMSUoe7bn5NTMf11_kH39xfLw=.5630b3f0-1178-4d54-a905-b02863ae8a85@github.com>
 <QIKLVuD1u4opO4fER0mSZLC5h4lF3xtrXbu4VO-eYqE=.195dcf4b-0265-43e1-b866-19f28800a625@github.com>
Message-ID: <GLBmhF5-k1_t0YotSBDHlkvJ-p73O9LPqFuUH7OPMrI=.6c3e9678-fe84-452e-b7cd-7417eaffa493@github.com>

On Tue, 13 May 2025 16:21:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> How did you search for those sources? I searched for literal `System.in` and my comments are the only ones I could find in the JDK.
>
> There are several locations in the jdk source (I simply grep'ed for `new InputStreamReader(System.in)`). And yes, they will need to be replaced with the recommended usage. I will address them with a different JBS issue.

Issue filed: https://bugs.openjdk.org/browse/JDK-8356893

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2087403916

From vyazici at openjdk.org  Tue May 13 19:14:52 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 13 May 2025 19:14:52 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v6]
In-Reply-To: <zE3BSueBiyvogX6S7fMMSUoe7bn5NTMf11_kH39xfLw=.5630b3f0-1178-4d54-a905-b02863ae8a85@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <VwNp5Cm91ConpVD6zzob2uwVNNf5GuUc7s6mVeefp0g=.13138944-a496-4487-b906-3eb4b69f28f7@github.com>
 <3ey9JGc8I3CPIi98S4kUZeKAVhmMw4nohRwU3-y9MBc=.a2fef848-06e1-4c4e-bfef-0e0a53bdc6f1@github.com>
 <zE3BSueBiyvogX6S7fMMSUoe7bn5NTMf11_kH39xfLw=.5630b3f0-1178-4d54-a905-b02863ae8a85@github.com>
Message-ID: <-VD4RPx9UU6KbJHprNmegMRJmsOsjlVTIRC4LqQa8m8=.10fa8ae0-dea8-43e4-91f8-8e0d6d380b06@github.com>

On Tue, 13 May 2025 12:34:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/InputStreamReader.java line 59:
>> 
>>> 57:  *     new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
>>> 58:  * }
>>> 59:  *
>> 
>> There are several places in the sources that still contain `new InputStreamReader(System.in)`. Shouldn't they be replaced with `new InputStreamReader(System.in, System.getProperty("stdin.encoding"))` too?)
>
> How did you search for those sources? I searched for literal `System.in` and my comments are the only ones I could find in the JDK.

@liach, regex already reveals some, after tweaking it enough to eliminate false positives. ?  `CTRL+Click`'ing on `InputStreamReader::new(InputStream)` gives an exhaustive list short enough to skim through.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25155#discussion_r2087471334

From archie.cobbs at gmail.com  Tue May 13 19:20:34 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 13 May 2025 14:20:34 -0500
Subject: Proposal: Add new methods get(int) and set(int, E) to ArrayDeque
In-Reply-To: <CANSoFxscr4w-1c5dG2GPHwDTcmMmnW7KZBH-RycYkMkhh0VDdA@mail.gmail.com>
References: <CANSoFxscr4w-1c5dG2GPHwDTcmMmnW7KZBH-RycYkMkhh0VDdA@mail.gmail.com>
Message-ID: <CANSoFxu=B066uYWXG4mDLtvVPKo_w_Eq+MVgNe3cf29b2M5t7A@mail.gmail.com>

On Mon, May 12, 2025 at 12:00?PM Archie Cobbs <archie.cobbs at gmail.com>
wrote:

> I would like to offer to do the following:
>
>    - Change the title of this bug from "retrofit ArrayDeque to implement
>    List" to "Add indexed get() and set() methods to ArrayDeque"
>
>
>    - Propose a corresponding PR and CSR to add get(int) and set(int, E)
>    methods to ArrayDeque
>
> But first I want to check with this list first to see if there are any
> objections?
>

After some discussion it seems the more complete solution might be better,
that is, giving ArrayDeque a true List view rather than just adding get()
and set(). Since ArrayDeque's current hashCode()/equals() is not compatible
with List, this would take the form of an asList() method, etc.

Any thoughts appreciated. In the meantime I'll explore what that might look
like.

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250513/80791091/attachment.htm>

From jrose at openjdk.org  Tue May 13 19:31:54 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 13 May 2025 19:31:54 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v2]
In-Reply-To: <Mmh5sRiZ99XISUdmNPsE0tQaghFoHEvPPL9UZM6QEEo=.37df736e-0640-42b7-bd81-75eb8a378690@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <l3xoBLwwsAQrpneEdTdtlnrC7dOit7jokk7wLettH14=.472e261e-894b-44d2-a8cb-c34df74aeb43@github.com>
 <vMVnGmw2Bg2qgbUiwI3yf2ky-L2DnIAOP6umt2Q2Tig=.04bb10da-692f-4be6-a0a1-ded8761d4b01@github.com>
 <Mmh5sRiZ99XISUdmNPsE0tQaghFoHEvPPL9UZM6QEEo=.37df736e-0640-42b7-bd81-75eb8a378690@github.com>
Message-ID: <DgkeSNw_XmUGUQkwMtSrdjXpkBG6ll7mHNPoHUCdHyM=.da6fc014-ae53-4d3a-a0fb-d4d6c1aa9995@github.com>

On Wed, 7 May 2025 11:17:19 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 302:
>> 
>>> 300:      * <b>WARNING: This method does not perform any bound checks.</b>
>>> 301:      */
>>> 302:     int countPositives(byte[] ba, int off, int len);
>> 
>> Maybe we should change countPositives to do a bounds check and have a private method in StringCoding be the `@IntrinsicCandidate`. This would make it easier to audit. Right now it's hard to audit because there are usages of JLA.countPositives in faraway classes. I'm not suggested we do this as part of this PR of course but it would mean the warning comment could be removed.
>
> Submitted [8356380](https://bugs.openjdk.org/browse/JDK-8356380) to address this.

See also pending PR https://github.com/openjdk/jdk/pull/24777

It documents the expectations of how an intrinsic method must be kept private.

An intrinsic is a private "back door" in the VM, and must not be accessed (except perhaps in carefully documented unusual circumstances) outside of its own source file.  There should be a non-private "front door" in the same source file which applies all relevant checks before calling the intrinsic.

Such checks need to be at least as strong as the built-in JVM range checks, null checks, and type checks that would be performed, if the intrinsic were implemented in 100% pure Java bytecodes.

In performance evaluations, such checks may appear to be redundant.  But they must not be removed.  Instead, whatever other checks are redundant with them (there must be some!) should be brought into the same C2 compilation task as the "front door" checks.  This requires making the two sets of checks (if there are two) look similar enough that C2 (or another JIT) can recognize their redundance.  Bringing the checks into the same task might require a ForceInline annotation (which is allowed only inside the JDK).  Recognizing the checks as redundant might require a C2 bug fix or RFE.

(The javadoc for IntrinsicCandidate says stuff like this.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2087493446

From vyazici at openjdk.org  Tue May 13 19:34:57 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 13 May 2025 19:34:57 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v7]
In-Reply-To: <U599_ZS8FpDAEVeJ2lg1c6pQkoKnQ0ZlSbSoCMjDEnI=.79f4f6ff-306e-403f-ae49-10e71bd26855@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <RAcEfEBZgn1o13wOeDQi9KG7s8koI8uizmFVGhqw0sk=.f65f7f8a-b8cf-4bbe-9dbd-8838e92453c6@github.com>
 <U599_ZS8FpDAEVeJ2lg1c6pQkoKnQ0ZlSbSoCMjDEnI=.79f4f6ff-306e-403f-ae49-10e71bd26855@github.com>
Message-ID: <XevRnHWfJdPw2FFGPEEvkb5FC4Ci36f-8_fkHeopd-k=.3c5efdd5-2cd8-49c7-bf05-30c75ebca87f@github.com>

On Tue, 13 May 2025 15:51:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request with a new target base 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:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into jla
>>  - Improve `uncheckedGetBytesNoRepl` docs
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>>  - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
>>  - Fix `HexDigits` copyright year
>>  - Fix copyright years
>>  - Prefix touched methods with `unchecked`
>>  - Fix typo in pre-existing JavaDoc
>>  - Improve `JavaLangAccess` documentation
>
> src/java.base/share/classes/java/lang/System.java line 2113:
> 
>> 2111: 
>> 2112:             public int uncheckedCountPositives(byte[] bytes, int offset, int length) {
>> 2113:                 return StringCoding.countPositives(bytes, offset, length);
> 
> The prefix means the method is uncheckedXXX when outside of java.lang, and XXX when in java.lang. Okay for this PR but I think we should follow-up and rename the methods in java.lang to uncheckedXXX, then introduce checked versions that do the bounds check.  In this case, we could have countPositives exposed via JLA, its implementation would do the bounds check before calling the unchecked version.  It would mean that "far away" callers in DIS, OIS, ZipCoder, ... would have a bounds check but it would make things easier to audit.

[8356380: Check bounds for JavaLangAccess::countPositives](https://bugs.openjdk.org/browse/JDK-8356380) will address this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2087497657

From vromero at openjdk.org  Tue May 13 19:36:11 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 13 May 2025 19:36:11 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v13]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <QvL1wMiufgj6kq6NBb2ciWTkVQ28MWWIWRmGE47mVHs=.08668b90-b5eb-4272-af23-5c501fccf079@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Merge branch 'master' into JDK-8354556
 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - additional changes from Archie
 - removing dead code
 - integrating code from Archie
 - fixing bugs, removing dead code
 - additional documentation changes and bug fixes
 - documentation and adding alias to lint categories
 - Merge branch 'master' into JDK-8354556
 - addressing review comment
 - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29

-------------

Changes: https://git.openjdk.org/jdk/pull/24746/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=12
  Stats: 661 lines in 32 files changed: 576 ins; 37 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

PR: https://git.openjdk.org/jdk/pull/24746

From vromero at openjdk.org  Tue May 13 20:00:00 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 13 May 2025 20:00:00 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v13]
In-Reply-To: <k0YoPCbK1q_hpxN0e023-_Nk5rpvRjywcuthI9uzAPg=.82a77a31-ff44-413c-8596-da9b2da03f19@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <k0YoPCbK1q_hpxN0e023-_Nk5rpvRjywcuthI9uzAPg=.82a77a31-ff44-413c-8596-da9b2da03f19@github.com>
Message-ID: <YfH-tAME9QF5hA05eO931sPuQhJT0QLvMPYvjfujUjc=.4eb8db38-c5ea-44d3-94d8-92f0b4248ee0@github.com>

On Fri, 18 Apr 2025 02:25:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
>> 
>>  - Merge branch 'master' into JDK-8354556
>>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>>    
>>    Co-authored-by: Chen Liang <liach at openjdk.org>
>>  - additional changes from Archie
>>  - removing dead code
>>  - integrating code from Archie
>>  - fixing bugs, removing dead code
>>  - additional documentation changes and bug fixes
>>  - documentation and adding alias to lint categories
>>  - Merge branch 'master' into JDK-8354556
>>  - addressing review comment
>>  - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29
>
> make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 1:
> 
>> 1: /*
> 
> Need to add handling of `RequiresIdentity` in `createAnnotation`

update on CreateSymbols, the complete implementation with the changes for CreateSymbols should be included in the PR for [1]. Which will be developed in parallel to this proposal

[1] https://bugs.openjdk.org/browse/JDK-8356894

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2087534670

From jlu at openjdk.org  Tue May 13 20:26:07 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 May 2025 20:26:07 GMT
Subject: Integrated: 8352755: Misconceptions about j.text.DecimalFormat digits
 during parsing
In-Reply-To: <DbSlspa3gs2Bi6EzhpNX6NpcgO3kSp3SkJS39jKJXmI=.41a4afcc-f083-4332-ba05-3a2f4e2dc795@github.com>
References: <DbSlspa3gs2Bi6EzhpNX6NpcgO3kSp3SkJS39jKJXmI=.41a4afcc-f083-4332-ba05-3a2f4e2dc795@github.com>
Message-ID: <4MLN-99QTiXJX6PfuB3dSq2eurz9SVkYh0HBM7R8zB0=.a4eec50f-e68d-4a4f-a57f-31e536f073de@github.com>

On Wed, 26 Mar 2025 20:31:07 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which clarifies the behavior for integer and fraction limits in NumberFormat and implementing classes. An associated CSR is filed.
> 
> There have been a few bugs submitted which indicate a misconception that these limits impact parsing. The actual behavior is that these limits only affect formatting. The specification is vague regarding this, and can be explicitly updated to eliminate confusion. As the implementing classes are updated to use `inheritDoc`, some shuffling around in the method specs are included in this change as well.
> 
> Alternatively I considered making this change as implementation specific to DecimalFormat and CompactNumberFormat only. (i.e. leave flexibility for other NumberFormat subclasses to define their own behavior on whether the limits affect parsing.) I am open to this option as well, but initially decided against it as 
> 1) Unlike formatting, it seems like a rare use case that you would want to suppress the range of digits of accepted during parsing. `setParseIntegerOnly()` already provides functionality to toggle between integer and fraction parsing.
> 2) The limits affecting formatting only has been the long-standing behavior for all the subclasses of NumberFormat provided by the OpenJDK reference implementation.

This pull request has now been integrated.

Changeset: e149bd3a
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e149bd3a0c387698fe7b2ff6c373944ded773b8b
Stats:     99 lines in 3 files changed: 9 ins; 20 del; 70 mod

8352755: Misconceptions about j.text.DecimalFormat digits during parsing

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/24265

From duke at openjdk.org  Tue May 13 21:09:31 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 13 May 2025 21:09:31 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v2]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <0qCm49dg55x2u_2FK4TFKtYsnH03F56rsFv82YzXqE0=.ecfd385a-a78d-4ef1-aed2-a4b8de0db116@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

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/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/b6e47807..56ba43fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From duke at openjdk.org  Tue May 13 21:17:06 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 13 May 2025 21:17:06 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v3]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <cUn44LAqXa34h5PM7qn6ppyc3JndzYbVB_Tf0QcR5_E=.ef5e189d-b34c-4813-be54-ccc44cf64438@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Same optimization of previous commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/56ba43fc..007d65cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From duke at openjdk.org  Tue May 13 21:24:08 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 13 May 2025 21:24:08 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v4]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <unfCvv2iS9xglcyjhWCVSGlQYD6AwuZMnuK9KlIWXEw=.3bc6df4b-1340-4fa4-b4b9-65d17a13dabb@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Update names

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/007d65cc..5ad26a14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From jiangli at openjdk.org  Tue May 13 21:33:03 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 13 May 2025 21:33:03 GMT
Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder on
 static-jdk
Message-ID: <E986980rvWra05uWXYMdT8N4i_0RGxNC_KubDF6tXAw=.a6ab5563-b75c-45b2-b367-31d001cc294e@github.com>

Please review this PR for skipping jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the context from https://bugs.openjdk.org/browse/JDK-8356904 description:

jdk/test/lib/process/TestNativeProcessBuilder.java (in lib-test/tier1) uses a native test launcher executable, exejvm-test-launcher, which has explicitly dependency on libjvm.so. The test fails on static-jdk. This is the same issue as [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276). With [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276), we decided to skip the affected hotspot tier1 tests on static-jdk. We should skip jdk/test/lib/process/TestNativeProcessBuilder.java on static-jdk as well. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK.

-------------

Commit messages:
 - Skip jdk/test/lib/process/TestNativeProcessBuilder.java on static-jdk.

Changes: https://git.openjdk.org/jdk/pull/25220/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25220&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356904
  Stats: 18 lines in 2 files changed: 18 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25220.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25220/head:pull/25220

PR: https://git.openjdk.org/jdk/pull/25220

From duke at openjdk.org  Tue May 13 22:38:53 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Tue, 13 May 2025 22:38:53 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v3]
In-Reply-To: <m-sqt9KlVF_WJ5Plh4_nJaia7LTBpzHkO8svt7mcisw=.2ffba1c6-a433-41e3-8a7f-b33ff874b472@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <H3vvJxVRsOzXpLIAnz2vc3wU_Umd9IoyI1cgqYT6mq0=.79b289da-60f2-4f62-99bd-227e03e9df2b@github.com>
 <m-sqt9KlVF_WJ5Plh4_nJaia7LTBpzHkO8svt7mcisw=.2ffba1c6-a433-41e3-8a7f-b33ff874b472@github.com>
Message-ID: <wSpmNko5KJYZII3Bck2H9E-H2QV04RRM85uRnxLdMuY=.815bb777-05ed-4581-b55a-8273ec1393c8@github.com>

On Wed, 7 May 2025 09:25:30 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add new set of cbrt micro-benchmarks
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp line 62:
> 
>> 60: {
>> 61:     0, 3220193280
>> 62: };
> 
> What is this constant?
> 
> Its value is 0xbff0400000000000, which is -ve bit set, bias (top bit of exponent) clear, but one of the bits in the fraction is set. So its value is -0x1.04p+0. As well as the exponent it also sets the 1 bit, just below the 5 most significant bits of the fraction. I guess this in effect rounds up the value that is added in the final rounding.
> 
> Is that right?

The idea is mainly that the _EXP_MSK2_ constant operates on the input to match up with it's corresponding entries in the lookup tables: _rcp_table_, _cbrt_table_, and _D_table_. The key part starts with computing the difference (_r = x - x'_) shown in line 260 below.
```c++
__ subsd(xmm1, xmm3);

Here _x_ is essentially the input fraction with all bits while _x'_ is the input fraction with _EXP_MSK2_ applied. This is then multiplied (_r = (x - x') * rcp_table(x')_) with the corresponding lookup table entry (_-1 / 1.b1 b2 b3 b4 b5 b6_ where _b6=1_) as shown in line 264 below.
```c++
__ mulsd(xmm1, xmm4);

This value then gets used by subsequent steps that involve entries from _cbrt_table_ and _D_table_. It won't necessarily round the final result up though as those effects will depend on what the input is. However, the polynomial coefficients will have a bigger impact on rounding. For a summary of the approximations, please refer to the algorithm description comment block near the beginning of the source file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2087726049

From liach at openjdk.org  Tue May 13 22:49:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 May 2025 22:49:54 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v6]
In-Reply-To: <VwNp5Cm91ConpVD6zzob2uwVNNf5GuUc7s6mVeefp0g=.13138944-a496-4487-b906-3eb4b69f28f7@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <VwNp5Cm91ConpVD6zzob2uwVNNf5GuUc7s6mVeefp0g=.13138944-a496-4487-b906-3eb4b69f28f7@github.com>
Message-ID: <TtMVyxEABTTi3BF0sY_0QjNwxg2Hw4e8xSkhQ1rzFD0=.3a6f941a-0c9d-46e2-8e9f-a64ca3af57f0@github.com>

On Tue, 13 May 2025 03:15:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed an erroneous curly brace

Let's address the other incorrect wrappings in a dedicated RFE.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25155#pullrequestreview-2838287193

From liach at openjdk.org  Wed May 14 00:05:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 May 2025 00:05:55 GMT
Subject: Integrated: 8356694: Removed unused subclass audits in
 ObjectInput/OutputStream
In-Reply-To: <Bpn80v8P8rOPoX9YaJwvzFPXMsPeP58D8BPoPOVtNIg=.f585f37b-1a6d-4eeb-a235-8b21c5add944@github.com>
References: <Bpn80v8P8rOPoX9YaJwvzFPXMsPeP58D8BPoPOVtNIg=.f585f37b-1a6d-4eeb-a235-8b21c5add944@github.com>
Message-ID: <TK866eVqhYyEd3BhKPk5_YvH1XX0C-wyR3g4iwXPpIU=.5719aef4-4511-4cc3-adf1-1b351437fd83@github.com>

On Mon, 12 May 2025 02:18:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> These two subclass audits in ObjectInputStream and ObjectOutputStream were only used when security managers are present, which is no longer the case in releases 24 and newer. Thus, we can remove these two redundant `ClassValue` and the computation methods safely.
> 
> Testing: java/io/Serializable and ObjectInput, jdk tier 1-3 in progress

This pull request has now been integrated.

Changeset: a96424b2
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a96424b24cc7734f04716a4459e5d5e0a5c73c0d
Stats:     71 lines in 2 files changed: 0 ins; 69 del; 2 mod

8356694: Removed unused subclass audits in ObjectInput/OutputStream

Reviewed-by: alanb, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/25174

From dholmes at openjdk.org  Wed May 14 00:34:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 May 2025 00:34:52 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v4]
In-Reply-To: <l8DneNJ4KUmd_8M5VhnbbMN27lVUao1mKrzZ28oeGGI=.acefca04-d2e0-465e-8168-5ccc2f16daca@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
 <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
 <YoHw-NBBOF6dHnbNX2nlxarBy1jnHdHUhuSEZlcSp_k=.536fcce1-7010-461f-a934-52505f473170@github.com>
 <SDkQonj1CXwsIBXyyO_M3mYj25kA3ya9nhDa4Fw-Y7M=.a2776cde-7544-4972-89c0-d289838ad714@github.com>
 <9qD9glLPCTy_6ium5mvzyjhZ56COlEOKz4AhzvGmhrg=.ff5d52e1-84a1-413c-aac0-873fdcbfa5ff@github.com>
 <l8DneNJ4KUmd_8M5VhnbbMN27lVUao1mKrzZ28oeGGI=.acefca04-d2e0-465e-8168-5ccc2f16daca@github.com>
Message-ID: <Z_KwF-bTUlOHcuVojdoqgIb0ItX8JJqvQhEwkoH2ShU=.dce96556-edde-4a47-a931-13b251369d32@github.com>

On Tue, 13 May 2025 12:51:56 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> You are right and I am confused. I always assumed that the primary function of jspawnhelper was to make vfork safe. Historically, that was the typical reason for an intermediate exec() to a helper - basically, you first exec() the helper as quickly as possible to get your own process memory. Then you do all the things you need to do in preparation for the final exec(), then exec again.
>> 
>> I am surprised that this has worked with vfork() so flawlessly all this time. Maybe it didn't; maybe the libc's have all internally replaced vfork() with fork(), since fork() is fast enough nowadays.
>> 
>> I actually don't understand why the jspawnhelper is even needed for posix_spawn, since all the things one does in jspawnhelper can be done also via posix_spawn process attributes.
>
> Hmm, glibc keeps it very vague in the vfork() manpage, stating that "On some implementations, vfork() is equivalent to fork()." AIX manpage says just "The vfork subroutine is supported as a compatibility interface for older Berkeley Software Distribution (BSD) system programs" which sounds to me its just an alias for fork(). MacOS has no vfork anymore.
> 
> So maybe Solaris was the last platform with a true vfork.

@tstuefe the helper was needed in part to enable a chdir between fork and exec - see this comment: https://bugs.openjdk.org/browse/JDK-5049299?focusedId=12148272&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12148272

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2087830040

From jpai at openjdk.org  Wed May 14 01:56:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 May 2025 01:56:00 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v8]
In-Reply-To: <fHBCE8kw7jUn9gc4R0o8v0PQbsCYWTvxkNJpGji7744=.a77cb139-35b4-492f-83a2-bb5a28eac32d@github.com>
References: <d-bbTH1lsG4Ev7_sNutKMbLBTXXyQ75ZQTbNvgJkqBQ=.06f597ba-1313-4bb4-9947-880e73acd5bf@github.com>
 <fHBCE8kw7jUn9gc4R0o8v0PQbsCYWTvxkNJpGji7744=.a77cb139-35b4-492f-83a2-bb5a28eac32d@github.com>
Message-ID: <x1ezfkElBob20kZS81uZao8QjMMH6MKPyLxBVRydL0s=.cb7d2529-a66f-4fe1-8bd2-791faea05c15@github.com>

On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
>> 
>> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
>> 
>> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
>> 
>> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's review - update code comment in the test

Thank you everyone for the reviews. tier1, tier2 and tier3 tests continue to pass with this change against latest master branch. I'll go ahead and integrate this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23986#issuecomment-2878393844

From jpai at openjdk.org  Wed May 14 01:56:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 May 2025 01:56:01 GMT
Subject: Integrated: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset
In-Reply-To: <d-bbTH1lsG4Ev7_sNutKMbLBTXXyQ75ZQTbNvgJkqBQ=.06f597ba-1313-4bb4-9947-880e73acd5bf@github.com>
References: <d-bbTH1lsG4Ev7_sNutKMbLBTXXyQ75ZQTbNvgJkqBQ=.06f597ba-1313-4bb4-9947-880e73acd5bf@github.com>
Message-ID: <tD5K8ffsinuAiFK8-5-wAWvnJbj1IHx_nP8DOnDQzF0=.ec2b9b19-2899-46e0-9b0d-aa939ff42944@github.com>

On Tue, 11 Mar 2025 14:23:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
> 
> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
> 
> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
> 
> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
> 
> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
> 
> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now maintained in the `ZipFile`,...

This pull request has now been integrated.

Changeset: 2c4e8d21
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2c4e8d211a030c85488e656a9a851d10dd0f9c11
Stats:     380 lines in 4 files changed: 323 ins; 14 del; 43 mod

8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset
8355975: ZipFile uses incorrect Charset if another instance for the same ZIP file was constructed with a different Charset

Co-authored-by: Eirik Bj?rsn?s <eirbjo at openjdk.org>
Reviewed-by: eirbjo, lancea, redestad, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/23986

From xgong at openjdk.org  Wed May 14 02:29:50 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 14 May 2025 02:29:50 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API
In-Reply-To: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
Message-ID: <2os9gEZk7LXqHQkJ-FTv_8jsGrT9Cy0lAVDYLPgHst0=.6ea1f0d0-67a3-4a6a-9b47-5cb753c3d668@github.com>

On Fri, 9 May 2025 07:35:41 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]).
> 
> Two key areas require improvement:
> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance.
> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types  increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance.
> 
> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures.
> 
> Main changes:
> 1. Java-side API refactoring:
>    - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on
>      architectures like AArch64.
> 2. C2 compiler IR refactoring:
>    - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types.
> 3. Backend changes:
>    - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level.
> 
> Performance:
> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below:
> 
> Benchmark                                                 Mode   Cnt Unit    SIZE    Before      After    Gain
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  64    53682.012   52650.325  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  256   14484.252   14255.156  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  1024   3664.900    3595.615  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  4096    908.312     935.269  1.02
> GatherOperationsBenchmark.micr...

Hi, could anyone please take a look at this PR? Thanks a lot in advance!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2878450580

From duke at openjdk.org  Wed May 14 02:44:14 2025
From: duke at openjdk.org (erifan)
Date: Wed, 14 May 2025 02:44:14 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v6]
In-Reply-To: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
Message-ID: <oDd6wkHsAQU3IUV3qCvjtqZ8BSHt7Qq2sx0Yy0Q8onc=.8e7db79c-15a5-4151-ac60-73f114433383@github.com>

> 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 10 additional commits since the last revision:

 - Refactor the JTReg tests for compare.xor(maskAll)
   
   Also made a bit change to support pattern `VectorMask.fromLong()`.
 - Merge branch 'master' into JDK-8354242
 - Refactor code
   
   Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
   optimization, making the code more modular.
 - Merge branch 'master' into JDK-8354242
 - Update the jtreg test
 - Merge branch 'master' into JDK-8354242
 - Addressed some review comments
   
   1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
   2. Improve code comments.
 - Merge branch 'master' into JDK-8354242
 - Merge branch 'master' into JDK-8354242
 - 8354242: VectorAPI: combine vector not operation with compare
   
   This patch optimizes the following patterns:
   For integer types:
   ```
   (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
       => (VectorMaskCmp src1 src2 ncond)
   (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
       => (VectorMaskCmp src1 src2 ncond)
   ```
   cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
   negative comparison of cond.
   
   For float and double types:
   ```
   (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
       => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
   (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
       => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
   ```
   cond can be eq or ne.
   
   Benchmarks on Nvidia Grace machine with 128-bit SVE2:
   With option `-XX:UseSVE=2`:
   ```
   Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
   testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
   testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
   testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
   testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
   testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
   testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
   testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
   testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
   testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
   testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
   testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
   testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
   testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
   testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
   testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
   testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
   testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
   testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
   testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
   testCompareLTMaskNotInt		ops/s	1672180.09	995.238142	2353757.863	853.774734	1.4
   testCompareLTMaskNotLong	ops/s	856502.2695	12276.82851	1177671.815	496.723302	1.37
   testCompareLTMaskNotShort	ops/s	3325798.025	2412.702501	4711554.181	1779.302112	1.41
   testCompareNEMaskNotByte	ops/s	7910002.518	2771.82477	10245315.33	16321.93935	1.29
   testCompareNEMaskNotDouble	ops/s	863754.6022	523.140788	1179133.982	476.572178	1.36
   testCompareNEMaskNotFloat	ops/s	1723321.883	2598.484803	2358492.186	877.1401	1.36
   testCompareNEMaskNotInt		ops/s	1670288.841	751.774826	2354158.125	835.720163	1.4
   testCompareNEMaskNotLong	ops/s	836327.6835	410.525466	1178178.825	308.757932	1.4
   testCompareNEMaskNotShort	ops/s	3327815.841	1511.978763	4711379.136	2336.505531	1.41
   testCompareUGEMaskNotByte	ops/s	7906699.024	3200.936474	10253843.74	15067.59401	1.29
   testCompareUGEMaskNotInt	ops/s	1674003.923	3287.191727	2353340.666	951.381021	1.4
   testCompareUGEMaskNotLong	ops/s	852424.5562	8920.408939	1177943.609	389.6621	1.38
   testCompareUGEMaskNotShort	ops/s	3327255.858	1584.885143	4711622.355	1247.215277	1.41
   testCompareUGTMaskNotByte	ops/s	7909249.189	4435.283667	10245541.34	10993.34739	1.29
   testCompareUGTMaskNotInt	ops/s	1693713.433	20650.00213	2353153.787	1055.343846	1.38
   testCompareUGTMaskNotLong	ops/s	851022.3395	7079.065268	1177910.677	538.604598	1.38
   testCompareUGTMaskNotShort	ops/s	3327236.988	1616.886789	4711209.865	3098.494145	1.41
   testCompareULEMaskNotByte	ops/s	7909350.825	3251.262342	10261449.03	7273.831341	1.29
   testCompareULEMaskNotInt	ops/s	1672350.925	1545.304304	2353231.755	914.231193	1.4
   testCompareULEMaskNotLong	ops/s	853349.4765	9804.906913	1177967.254	435.044367	1.38
   testCompareULEMaskNotShort	ops/s	3325757.891	1555.062257	4712873.187	1650.986905	1.41
   testCompareULTMaskNotByte	ops/s	7912218.621	2633.477744	10242095.98	21921.39902	1.29
   testCompareULTMaskNotInt	ops/s	1673994.849	2672.507666	2353449.22	946.105757	1.4
   testCompareULTMaskNotLong	ops/s	849032.5868	10406.06689	1177586.047	506.541456	1.38
   testCompareULTMaskNotShort	ops/s	3328062.026	1892.991844	4713247.216	1855.983724	1.41
   
   ```
   With option `-XX:UseSVE=0`:
   ```
   Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
   testCompareEQMaskNotByte	ops/s	7895961.919	72712.90804	7746493.731	71481.92938	0.98
   testCompareEQMaskNotDouble	ops/s	789811.0455	384.493088	766473.7994	2216.581793	0.97
   testCompareEQMaskNotFloat	ops/s	1806305.818	638.010451	1819616.613	3295.38958	1
   testCompareEQMaskNotInt		ops/s	1815820.144	1225.336135	1849538.401	766.29902	1.01
   testCompareEQMaskNotLong	ops/s	807336.492	335.451807	792732.9483	277.954432	0.98
   testCompareEQMaskNotShort	ops/s	4818266.38	1927.862665	4668903.001	1922.782715	0.96
   testCompareGEMaskNotByte	ops/s	7818439.678	75374.97739	16498003.98	41440.49653	2.11
   testCompareGEMaskNotInt		ops/s	1815159.05	1090.912209	2372095.779	1664.397112	1.3
   testCompareGEMaskNotLong	ops/s	804324.5575	2301.686878	927919.8507	371.766719	1.15
   testCompareGEMaskNotShort	ops/s	4818966.563	2443.643652	5385561.038	29558.37423	1.11
   testCompareGTMaskNotByte	ops/s	7893406.157	82687.74264	16470663.2	22165.55812	2.08
   testCompareGTMaskNotInt		ops/s	1815316.812	915.894106	2370447.198	655.016338	1.3
   testCompareGTMaskNotLong	ops/s	807019.456	526.525482	928079.0541	330.582693	1.15
   testCompareGTMaskNotShort	ops/s	4820552.881	1684.247747	5355902.93	5893.2915	1.11
   testCompareLEMaskNotByte	ops/s	7816263.323	79560.0015	16473621.19	56688.99585	2.1
   testCompareLEMaskNotInt		ops/s	1814915.724	926.998625	2368790.306	932.594778	1.3
   testCompareLEMaskNotLong	ops/s	806483.9	935.718082	928110.9074	407.096695	1.15
   testCompareLEMaskNotShort	ops/s	4813660.241	6817.870509	5357107.852	10061.47975	1.11
   testCompareLTMaskNotByte	ops/s	7838948.962	69136.4504	16424405.96	24464.75469	2.09
   testCompareLTMaskNotInt		ops/s	1815056.833	1187.6453	2369892.187	1103.819634	1.3
   testCompareLTMaskNotLong	ops/s	806602.1804	287.923365	928346.4118	617.682824	1.15
   testCompareLTMaskNotShort	ops/s	4817940.643	2767.1509	5372537.84	15397.47169	1.11
   testCompareNEMaskNotByte	ops/s	9078493.798	4630.339307	16484348.42	18925.88346	1.81
   testCompareNEMaskNotDouble	ops/s	661769.6272	398.712981	926763.5839	1808.843788	1.4
   testCompareNEMaskNotFloat	ops/s	1570527.252	563.642144	2312425.678	1815.844846	1.47
   testCompareNEMaskNotInt		ops/s	1619146.58	626.793854	2369711.543	942.330478	1.46
   testCompareNEMaskNotLong	ops/s	680201.5381	2252.836482	927808.6147	414.917863	1.36
   testCompareNEMaskNotShort	ops/s	3763508.054	3622.560798	5367808.015	8591.466599	1.42
   testCompareUGEMaskNotByte	ops/s	7886373.129	75917.74675	16480928.93	27524.31005	2.08
   testCompareUGEMaskNotInt	ops/s	1815636.832	750.036241	2369683.015	901.609404	1.3
   testCompareUGEMaskNotLong	ops/s	806862.5826	287.819616	928001.4394	361.063837	1.15
   testCompareUGEMaskNotShort	ops/s	4820581.361	2098.537435	5375854.248	25619.40165	1.11
   testCompareUGTMaskNotByte	ops/s	7891591.465	96614.93542	16410405.93	15012.37096	2.07
   testCompareUGTMaskNotInt	ops/s	1814871.179	662.825588	2371325.903	1170.491164	1.3
   testCompareUGTMaskNotLong	ops/s	804013.7658	2240.534209	928062.2169	531.306897	1.15
   testCompareUGTMaskNotShort	ops/s	4818150.337	3051.717685	5381449.337	21212.34187	1.11
   testCompareULEMaskNotByte	ops/s	7831540.628	81306.67253	16495250.78	38682.19675	2.1
   testCompareULEMaskNotInt	ops/s	1814484.14	687.860656	2369265.075	940.609586	1.3
   testCompareULEMaskNotLong	ops/s	807780.5749	769.876816	927538.0732	1278.267724	1.14
   testCompareULEMaskNotShort	ops/s	4817437.42	5141.336541	5356183.359	7015.608124	1.11
   testCompareULTMaskNotByte	ops/s	7849078.225	56753.59764	16395975.27	34043.67295	2.08
   testCompareULTMaskNotInt	ops/s	1814328.226	2697.219111	2370700.47	1991.841988	1.3
   testCompareULTMaskNotLong	ops/s	807166.8197	253.061506	927926.2803	252.933462	1.14
   testCompareULTMaskNotShort	ops/s	4821098.216	1625.959044	5348980.243	4100.768121	1.1
   ```
   
   Benchmarks on AMD EPYC 9124 16-Core Processor:
   With option `-XX:UseAVX=3`:
   ```
   Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
   testCompareEQMaskNotByte	ops/s	16607323.35	1233692.631	18381557.66	1163201.522	1.1
   testCompareEQMaskNotDouble	ops/s	2114285.245	58782.2534	2959946.353	43016.0445	1.39
   testCompareEQMaskNotFloat	ops/s	4480874.437	89975.29074	6960151.436	64799.143	1.55
   testCompareEQMaskNotInt		ops/s	4370906.91	51784.80889	6856955.043	313858.5504	1.56
   testCompareEQMaskNotLong	ops/s	2080065.895	26762.06732	2939142.143	67179.05314	1.41
   testCompareEQMaskNotShort	ops/s	7968282.563	210437.2781	12701214.56	473152.6407	1.59
   testCompareGEMaskNotByte	ops/s	18419141.89	473408.9451	19880059.68	321638.0397	1.07
   testCompareGEMaskNotInt		ops/s	4419015.62	77352.98633	7037639.227	151066.0383	1.59
   testCompareGEMaskNotLong	ops/s	2147982.48	49227.42782	3000275.928	39298.75344	1.39
   testCompareGEMaskNotShort	ops/s	8469039.613	17833.19707	12288229.49	244317.8812	1.45
   testCompareGTMaskNotByte	ops/s	18728997.5	468328.8358	20544730.05	392264.6466	1.09
   testCompareGTMaskNotInt		ops/s	4510009.705	78812.57357	7364629.942	70970.78473	1.63
   testCompareGTMaskNotLong	ops/s	2124104.969	40917.89257	2953536.279	35199.19687	1.39
   testCompareGTMaskNotShort	ops/s	8690557.621	311534.1159	12344017.51	457931.8741	1.42
   testCompareLEMaskNotByte	ops/s	17758400.53	478383.4945	19209183.26	1143297.241	1.08
   testCompareLEMaskNotInt		ops/s	4363664.862	43443.18063	7054093.064	78141.11476	1.61
   testCompareLEMaskNotLong	ops/s	2068632.213	29844.78023	2954766.412	50667.22502	1.42
   testCompareLEMaskNotShort	ops/s	8637608.548	183538.5511	12719010.27	473568.8825	1.47
   testCompareLTMaskNotByte	ops/s	14406138.95	423105.0163	17292417.96	371386.9689	1.2
   testCompareLTMaskNotInt		ops/s	4546707.266	131977.3144	7040483.394	213590.4657	1.54
   testCompareLTMaskNotLong	ops/s	2123277.356	47243.21499	2848720.442	58896.97045	1.34
   testCompareLTMaskNotShort	ops/s	7570169.363	649873.6295	11945383.75	988276.5955	1.57
   testCompareNEMaskNotByte	ops/s	18274529.55	683396.7384	19081938.8	1118739.778	1.04
   testCompareNEMaskNotDouble	ops/s	2112533.61	43295.50012	2912115.441	78189.51083	1.37
   testCompareNEMaskNotFloat	ops/s	4628683.814	93817.07362	6967208.729	145135.8544	1.5
   testCompareNEMaskNotInt		ops/s	4470900.214	75974.50842	7286913.662	116328.5277	1.62
   testCompareNEMaskNotLong	ops/s	2134091.061	46377.94061	2934667.477	81675.46021	1.37
   testCompareNEMaskNotShort	ops/s	8790384.287	396161.8599	13076858.35	286272.1155	1.48
   testCompareUGEMaskNotByte	ops/s	18009150.9	660803.8886	17551258.33	1667014.843	0.97
   testCompareUGEMaskNotInt	ops/s	4442928.74	83190.81019	6854088.277	329008.8901	1.54
   testCompareUGEMaskNotLong	ops/s	2088357.736	71696.24791	2973202.26	63278.78974	1.42
   testCompareUGEMaskNotShort	ops/s	8348624.02	116562.7876	12832250.78	546869.3006	1.53
   testCompareUGTMaskNotByte	ops/s	17871101.25	800199.6321	19902619.81	214003.3262	1.11
   testCompareUGTMaskNotInt	ops/s	4088304.421	137797.9723	7135454.33	124553.651	1.74
   testCompareUGTMaskNotLong	ops/s	2070610.42	19881.82182	2991536.365	36260.60767	1.44
   testCompareUGTMaskNotShort	ops/s	8637099.341	155822.1608	12756579.77	186068.199	1.47
   testCompareULEMaskNotByte	ops/s	17940901.36	1258029.364	18932484.94	694554.6305	1.05
   testCompareULEMaskNotInt	ops/s	4369177.511	74982.31936	6392773.082	550171.2266	1.46
   testCompareULEMaskNotLong	ops/s	2135905.761	43693.63178	2877579.631	41651.56289	1.34
   testCompareULEMaskNotShort	ops/s	8607710.544	132655.1676	12446370.04	441718.3035	1.44
   testCompareULTMaskNotByte	ops/s	17409912.23	1033204.537	20607479.99	362000.5056	1.18
   testCompareULTMaskNotInt	ops/s	4386455.9	119192.1635	6920123.264	186158.2845	1.57
   testCompareULTMaskNotLong	ops/s	2064995.149	38622.2734	2988343.589	39037.90006	1.44
   testCompareULTMaskNotShort	ops/s	8642182.752	230919.2442	13029582.09	437101.4923	1.5
   ```
   
   The small amount of performance degradation is due to test fluctuations.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24674/files
  - new: https://git.openjdk.org/jdk/pull/24674/files/001fac0f..f2f71e34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=04-05

  Stats: 20102 lines in 755 files changed: 11515 ins; 4932 del; 3655 mod
  Patch: https://git.openjdk.org/jdk/pull/24674.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24674/head:pull/24674

PR: https://git.openjdk.org/jdk/pull/24674

From duke at openjdk.org  Wed May 14 02:44:14 2025
From: duke at openjdk.org (erifan)
Date: Wed, 14 May 2025 02:44:14 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v5]
In-Reply-To: <uuIl_bBnVxLkKQ56E3xlJ9DefFBQKDYtoe-Gs4ZXYyo=.7cfbe1c9-8f0d-4432-a376-d81cc961dc4a@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <huhJ3Yq2fj9CJGBAqQFZxd8i0Wjnwad3moNHymXKyy8=.d64a2532-6bd5-4e58-84ee-18f682d7fe20@github.com>
 <ItOPWOS6VHofCe7QYcIqnq0yCi-dXfEri_45HgrjfYY=.285d15ff-5b15-4a21-8a7c-1e4cabcc33b2@github.com>
 <Jzqyfc2xxJRBY2ppai7XpFKaWS7y3CsnP4Y547KHq6o=.d482f244-a9dd-4ac4-a082-0b3180c1caad@github.com>
 <gs98vNywMgB3pEcq_Bfv_jhLBiH7KS_1NhHGprSCtLs=.cd43836c-5de3-4642-afa1-1a5a04f0b17b@github.com>
 <F6ofKcqVvH3NUwDokqmyIw823V1u6GGlAMdMCxJLtek=.433a6406-1ba0-4a58-b9a3-fde97d8f515d@github.com>
 <uuIl_bBnVxLkKQ56E3xlJ9DefFBQKDYtoe-Gs4ZXYyo=.7cfbe1c9-8f0d-4432-a376-d81cc961dc4a@github.com>
Message-ID: <JVN6rAkTsQ2php-xtio6lRuzhy0drs0zMtF57hCz9qk=.cd414366-e1a2-452d-9c19-705f791e26e8@github.com>

On Fri, 9 May 2025 09:37:22 GMT, erifan <duke at openjdk.org> wrote:

>> Yes, converting `VectorMask.fromLong(SPECIES, -1L)` to `MaskAll()` would be better, and that will benefit AArch64 as well, since `MaskAll()` is much more cheaper than `fromLong()` on AArch64. We can add such a transformation with another PR.
>
> Ok, I'll extend the test to xor(maskAll(true) in the next commit, thanks!

Done, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2087927027

From duke at openjdk.org  Wed May 14 02:44:16 2025
From: duke at openjdk.org (erifan)
Date: Wed, 14 May 2025 02:44:16 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v5]
In-Reply-To: <fbwQ9Crn9VaJSb7zFzT1aj_AVRojWMT7EStONFdUecs=.1cd10882-f5ee-488a-bb49-e21f2ba702e5@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <huhJ3Yq2fj9CJGBAqQFZxd8i0Wjnwad3moNHymXKyy8=.d64a2532-6bd5-4e58-84ee-18f682d7fe20@github.com>
 <fbwQ9Crn9VaJSb7zFzT1aj_AVRojWMT7EStONFdUecs=.1cd10882-f5ee-488a-bb49-e21f2ba702e5@github.com>
Message-ID: <NYcgZ2rke7cbt8HxA0ZlMMVcZ_h-SrVzkeFRC2MWS3U=.76e635bd-f41b-432d-bc0e-a47e8070b2ed@github.com>

On Wed, 7 May 2025 11:13:23 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Refactor code
>>    
>>    Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
>>    optimization, making the code more modular.
>>  - Merge branch 'master' into JDK-8354242
>>  - Update the jtreg test
>>  - Merge branch 'master' into JDK-8354242
>>  - Addressed some review comments
>>    
>>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>>    2. Improve code comments.
>>  - Merge branch 'master' into JDK-8354242
>>  - Merge branch 'master' into JDK-8354242
>>  - 8354242: VectorAPI: combine vector not operation with compare
>>    
>>    This patch optimizes the following patterns:
>>    For integer types:
>>    ```
>>    (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    ```
>>    cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>>    negative comparison of cond.
>>    
>>    For float and double types:
>>    ```
>>    (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    ```
>>    cond can be eq or ne.
>>    
>>    Benchmarks on Nvidia Grace machine with 128-bit SVE2:
>>    With option `-XX:UseSVE=2`:
>>    ```
>>    Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>>    testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>>    testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>>    testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>>    testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>>    testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>>    testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>>    testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>>    testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>>    testCompareGEMaskNotLong	ops/s	854496.156...
>
> test/micro/org/openjdk/bench/jdk/incubator/vector/MaskCompareNotBenchmark.java line 40:
> 
>> 38: @Fork(jvmArgs = { "--add-modules=jdk.incubator.vector" })
>> 39: public class MaskCompareNotBenchmark {
>> 40:     private static final int ARRAYLEN = 4096;
> 
> ARRAYLEN should be configurable @Param.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2087927310

From iklam at openjdk.org  Wed May 14 06:16:15 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 06:16:15 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v8]
In-Reply-To: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
Message-ID: <tjP4ZHZ79VRaDaKgsl38nBOBVrgjt1A0lQX4nndoTMg=.9698bf32-c090-47da-8b14-f3ad883c3e39@github.com>

> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
> 
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
> 
> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
> 
> Examples:
> 
> 
> # Create an AOT cache with a single command:
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> Hello World
> Temporary AOTConfiguration recorded: foo.aot.config
> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
> AOTCache creation is complete: foo.aot 10240000 bytes
> 
> # Create logging file for the AOT cache assembly phase
> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> 
> 
> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).

Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:

 - java.md updates from @rose00
 - Resolved differences with CSR JDK-8356010

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24942/files
  - new: https://git.openjdk.org/jdk/pull/24942/files/3cc2cb3a..cd7a5a6b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=06-07

  Stats: 748 lines in 9 files changed: 369 ins; 327 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/24942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942

PR: https://git.openjdk.org/jdk/pull/24942

From ihse at openjdk.org  Wed May 14 06:35:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 06:35:56 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <E8b4gHUmdOVT14qtrvzEySgduI7s9R9v8sv_dayKXF0=.1f5975b7-00b6-4566-bd41-a9a77f8a9d71@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
 <E8b4gHUmdOVT14qtrvzEySgduI7s9R9v8sv_dayKXF0=.1f5975b7-00b6-4566-bd41-a9a77f8a9d71@github.com>
Message-ID: <12he4bTHjyqUILsl4m4lQOE7_dSLFWMgcx7812qaoZY=.f0bc7143-3bc0-432f-8a51-2bacade3e9a6@github.com>

On Tue, 13 May 2025 00:10:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
>> 
>> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
>> 
>> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.
>
> src/demo/share/jfc/CodePointIM/README.html line 5:
> 
>> 3: <head>
>> 4:   <title>README - CodePointIM</title>
>> 5:   <meta http-equiv="content-type" content="text/html; charset=utf-8">
> 
> I believe this line is equivalent to simple `<meta charset="utf-8"/>` which is widely used in java.desktop's docs.

That seems reasonable, yes. However, I'd like to keep this change to the absolute minimum. Feel free to open a separate issue for fixing this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25148#discussion_r2088152886

From ihse at openjdk.org  Wed May 14 06:35:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 06:35:57 GMT
Subject: Integrated: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
Message-ID: <1uf8Qu09x2byR-S1kMvt4zMdBu_BKZHCvx13v-uaxYc=.9e974fe5-0125-4001-99f6-acbba3ea517d@github.com>

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A handful of html and xml files in the JDK source tree claims to have encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
> 
> While perhaps technically correct, this is misleading, and goes contrary to the efforts of turning the source code into UTF-8 proper.
> 
> I chose between marking them as "ASCII" and "UTF-8", but chose the latter, since otherwise if they ever were to be updated with a non-ASCII character, the value would have been unspecified, and after JDK-8301971, all files in the JDK repository will be interpreted as UTF-8.

This pull request has now been integrated.

Changeset: dd251599
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dd2515993bf76f424e4c56d529ae1541f55e3f8b
Stats:     794 lines in 53 files changed: 2 ins; 9 del; 783 mod

8356644: Update encoding declaration to UTF-8

Reviewed-by: prr, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/25148

From ihse at openjdk.org  Wed May 14 06:46:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 06:46:57 GMT
Subject: Integrated: 8354968: Replace unicode sequences in comment text with
 UTF-8 characters
In-Reply-To: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
Message-ID: <sgBPptQGphRdBvFWPXl8SJm3092mzM3MjrlJs3LVL3A=.df2ae687-a101-48de-a821-4f8973c7558a@github.com>

On Thu, 17 Apr 2025 14:42:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> 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.

This pull request has now been integrated.

Changeset: a3e094e1
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3e094e1a0716adf52dad6407eb7877682beec92
Stats:     158 lines in 153 files changed: 0 ins; 2 del; 156 mod

8354968: Replace unicode sequences in comment text with UTF-8 characters

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/24727

From serb at openjdk.org  Wed May 14 06:52:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 14 May 2025 06:52:55 GMT
Subject: RFR: 8356644: Update encoding declaration to UTF-8
In-Reply-To: <12he4bTHjyqUILsl4m4lQOE7_dSLFWMgcx7812qaoZY=.f0bc7143-3bc0-432f-8a51-2bacade3e9a6@github.com>
References: <8loaLnxoQ6Om5EqhX9_nORypM5UjgVz3DYJnMinZ77w=.bd323a79-0fd6-4b16-8edb-193fec7fbb13@github.com>
 <E8b4gHUmdOVT14qtrvzEySgduI7s9R9v8sv_dayKXF0=.1f5975b7-00b6-4566-bd41-a9a77f8a9d71@github.com>
 <12he4bTHjyqUILsl4m4lQOE7_dSLFWMgcx7812qaoZY=.f0bc7143-3bc0-432f-8a51-2bacade3e9a6@github.com>
Message-ID: <IpJv8SIJ2TSeGf31v4EPP7vbfL9injugtQRKbLZy1MM=.3980df30-43fb-48a2-a48b-4cafcf7352fd@github.com>

On Wed, 14 May 2025 06:32:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> That seems reasonable, yes. However, I'd like to keep this change to the absolute minimum. Feel free to open a separate issue for fixing this.

FIled: https://bugs.openjdk.org/browse/JDK-8356937

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25148#discussion_r2088181402

From jpai at openjdk.org  Wed May 14 06:53:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 May 2025 06:53:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <ty23rwTu8HuiUpJIiK3JlOeGZcIl-5iJBQkeZYksrXs=.8a6ca6d0-948a-490e-a58d-0247c1024c5c@github.com>
 <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com>
Message-ID: <iVQHJmAnBrzwZdYV5JaA9PYUWxDjeuzOVVmsaNkmAvo=.7a2a425e-ad43-4e47-98b5-e5f4d17271a2@github.com>

On Tue, 13 May 2025 16:37:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 208:
>> 
>>> 206:         boolean shouldCreate = isTrue(env, "create");
>>> 207:         if (shouldCreate && forceReadOnly) {
>>> 208:             throw new IllegalArgumentException(
>> 
>> Although `IllegalArgumentException` seems reasonable here, the current contract of this constructor is to throw `IOException` and that then gets propagated through the public `FileSystemProvider.newFileSystem(...)` API which is specified to throw `IOException`.
>> 
>> So we will either have to throw `IOException` here (preferable) or we have to catch `IllegalArgumentException` at the call sites of this constructor and then rethrow it as a `IOException`, to prevent the unspecified `IllegalArgumentException` propagating out of the `FileSystemProvider.newFileSystem(...)` API.
>
> I checked the overloads of newFileSystem that were added in JDK 13 and somehow the `@throws IllegalArgumentException` was missed. It's declared by the methods that take a URI + env but not methods that take a Path + env. We should fix that, then the IAE from the zip provider won't be a surprise.

I'll file an issue for this today, shortly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2088183284

From alanb at openjdk.org  Wed May 14 07:46:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 May 2025 07:46:50 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <iVQHJmAnBrzwZdYV5JaA9PYUWxDjeuzOVVmsaNkmAvo=.7a2a425e-ad43-4e47-98b5-e5f4d17271a2@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <ty23rwTu8HuiUpJIiK3JlOeGZcIl-5iJBQkeZYksrXs=.8a6ca6d0-948a-490e-a58d-0247c1024c5c@github.com>
 <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com>
 <iVQHJmAnBrzwZdYV5JaA9PYUWxDjeuzOVVmsaNkmAvo=.7a2a425e-ad43-4e47-98b5-e5f4d17271a2@github.com>
Message-ID: <EpDUWHEPGqADk8eO2Bt3uf_ql_gSlamnpeUoQhklvSU=.1b898f6e-65bf-424e-bc43-ef7782c4aeec@github.com>

On Wed, 14 May 2025 06:51:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I checked the overloads of newFileSystem that were added in JDK 13 and somehow the `@throws IllegalArgumentException` was missed. It's declared by the methods that take a URI + env but not methods that take a Path + env. We should fix that, then the IAE from the zip provider won't be a surprise.
>
> I'll file an issue for this today, shortly.

I created JDK-8356888 yesterday and [bplb](https://github.com/bplb) has picked it up already.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2088288990

From rgiulietti at openjdk.org  Wed May 14 08:04:00 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 14 May 2025 08:04:00 GMT
Subject: Integrated: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal
In-Reply-To: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
References: <sM9T9wdhQzQK0adjeCEH-nxJ4vrELLujczFbYrPfrkI=.4d60c92d-9b2a-4735-9650-a1b808d76417@github.com>
Message-ID: <nXCxC3wnb-nvUePHnuNAnzxbqWGa1SyV60aEbtbyFuQ=.bd5eb0e1-3b9a-46db-b390-c6905bd68ee9@github.com>

On Fri, 13 Dec 2024 15:04:12 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> See the JBS bug for some details.

This pull request has now been integrated.

Changeset: d1032d71
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d1032d71bfd50ebc4b328ce9b0cc81cbb80554b0
Stats:     1041 lines in 1 file changed: 352 ins; 461 del; 228 mod

8343829: Unify decimal and hexadecimal parsing in FloatingDecimal

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/22737

From tpushkin at openjdk.org  Wed May 14 08:18:39 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 14 May 2025 08:18:39 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v12]
In-Reply-To: <AdBmCAbqhjQEP05JBlXhp21hKuxn7SAb7h0Y3Wvollk=.21c0e6fe-097e-41e4-afa3-45b108112a28@github.com>
References: <AdBmCAbqhjQEP05JBlXhp21hKuxn7SAb7h0Y3Wvollk=.21c0e6fe-097e-41e4-afa3-45b108112a28@github.com>
Message-ID: <JoyEhrXuHQMMjc5wSmogN0045YycfgZbi1YkpP3Ef8g=.ba201c18-7077-451a-b4b9-adafa9278b7f@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:

  Make supertype obstruction check easier to understand

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24223/files
  - new: https://git.openjdk.org/jdk/pull/24223/files/915987b0..a3b7dd96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=10-11

  Stats: 16 lines in 3 files changed: 3 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 shade at openjdk.org  Wed May 14 09:08:59 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 May 2025 09:08:59 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v5]
In-Reply-To: <bpJt9PjA94QvUxfVv-hO-UdDvEUG-VMeeRGFpQZQalM=.e9d2bb18-1d47-43eb-995c-42659ae4d5a9@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
 <bpJt9PjA94QvUxfVv-hO-UdDvEUG-VMeeRGFpQZQalM=.e9d2bb18-1d47-43eb-995c-42659ae4d5a9@github.com>
Message-ID: <tSrdDriAIWpN0U0EOTmFNJadfSP8lvx6QfgZg4M0XRU=.7f0659b9-73be-466d-b2bf-9038faf88917@github.com>

On Tue, 13 May 2025 10:30:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong.
>> 
>> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. 
>> 
>> I am very open to bike-shedding about the actual message :)
>> 
>> Additional testing:
>>  - [x] Ad-hoc experiments with breaking jspawnhelper
>>  - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Print error decoding
>  - Touch up formatting message
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Add bug ID
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Pull message into a field
>  - Test cases
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Initial fix
>    
>    Good spawnhelper failure message
>    
>    Trying tests
>    
>    Print helper message on all IOExceptions
>    
>    Final

Testing is green, I am integrating. Thanks all!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24149#issuecomment-2879409486

From shade at openjdk.org  Wed May 14 09:09:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 May 2025 09:09:00 GMT
Subject: Integrated: 8352533: Report useful IOExceptions when jspawnhelper
 fails
In-Reply-To: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
Message-ID: <WedMBx9m0dWsJT9m1EgR03aKAcFmUOsgonyjzfmIuag=.fc8b139a-8f3c-4613-9421-ac683454483f@github.com>

On Fri, 21 Mar 2025 10:00:26 GMT, Aleksey Shipilev <shade at openjdk.org> 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`

This pull request has now been integrated.

Changeset: 5c73dfc2
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5c73dfc28cbd6801ac85c6685fb8c77aad3ab0b7
Stats:     100 lines in 3 files changed: 74 ins; 0 del; 26 mod

8352533: Report useful IOExceptions when jspawnhelper fails

Reviewed-by: simonis, rriggs, stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/24149

From schernyshev at openjdk.org  Wed May 14 09:31:53 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 14 May 2025 09:31:53 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v3]
In-Reply-To: <oMwFXneYTjswbqNbyMq16Cha8bJMXkrospBpxO3zTpw=.e9ed6489-55c3-4f20-aa08-65a9e2e40557@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
 <oMwFXneYTjswbqNbyMq16Cha8bJMXkrospBpxO3zTpw=.e9ed6489-55c3-4f20-aa08-65a9e2e40557@github.com>
Message-ID: <etY25QNWmOPz3ovbQ_tS9CzfvusgoUpZIREMBTfV7Ow=.b37b286a-3e18-4dea-8bf3-eaabcf21791a@github.com>

On Tue, 13 May 2025 14:46:00 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> I wrote 2 comments. but cold not post them. They are in "pending" state. Not sure why. Should the comments be first reviewed by {Committers|Reviewers}?

please go to `Files changed` panel and press Review Changes -> Submit review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2879489346

From schernyshev at openjdk.org  Wed May 14 09:44:52 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 14 May 2025 09:44:52 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v3]
In-Reply-To: <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
Message-ID: <7ZM5FpCXNDfRwU9qCLOnve_LH-Yboa2cNjkfgWBS2OU=.30453fda-38e2-4c9c-bb37-fe1330b21a80@github.com>

On Fri, 2 May 2025 10:00:07 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor container runtime version code

test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 166:

> 164:             return null;
> 165:         }
> 166:     }

Do you still need this method?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2088524580

From tpushkin at openjdk.org  Wed May 14 10:14:54 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 14 May 2025 10:14:54 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v12]
In-Reply-To: <JoyEhrXuHQMMjc5wSmogN0045YycfgZbi1YkpP3Ef8g=.ba201c18-7077-451a-b4b9-adafa9278b7f@github.com>
References: <AdBmCAbqhjQEP05JBlXhp21hKuxn7SAb7h0Y3Wvollk=.21c0e6fe-097e-41e4-afa3-45b108112a28@github.com>
 <JoyEhrXuHQMMjc5wSmogN0045YycfgZbi1YkpP3Ef8g=.ba201c18-7077-451a-b4b9-adafa9278b7f@github.com>
Message-ID: <L4npkz6cTV-OUUj1e25EnSPHrjgAPyo3mDSg00QjAO4=.7d008865-5ab6-4d8c-bb8f-8e7613f4e12a@github.com>

On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin <tpushkin at openjdk.org> 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:
> 
>   Make supertype obstruction check easier to understand

Sorry, had to pause working on this for some time because of other stuff.

I believe I have addressed all the existing comments now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2879622953

From rgiulietti at openjdk.org  Wed May 14 10:18:54 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 14 May 2025 10:18:54 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double) [v2]
In-Reply-To: <w48C4y0RR5togk9taQZCJlUN7IazrPf6sISpGDaON9Q=.49005247-e8ee-486a-b394-b745bfe2ef46@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
 <w48C4y0RR5togk9taQZCJlUN7IazrPf6sISpGDaON9Q=.49005247-e8ee-486a-b394-b745bfe2ef46@github.com>
Message-ID: <vgz0KQQNAF6ghUSislytUThBmK5EbuCq55h6_DHBJEs=.3bf90a16-a918-4cb5-b28d-e385857aa356@github.com>

On Tue, 13 May 2025 13:03:42 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix code tag in javadoc

src/java.base/share/classes/java/math/BigDecimal.java line 1408:

> 1406:         }
> 1407: 
> 1408:         return valueOf(s, fmt.getScale(), fmt.getPrecision());

I'd prefer to have a `getExp()` rather than `getScale()` in `FormattedFPDecimal`.

src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 100:

> 98:                 // Keep digits to left of decimal, plus leave a
> 99:                 // trailing zero
> 100:                     (expR + 1) + 1;

I think that the comment is sufficiently clear to be able to replace `(expR + 1) + 1` with `expR + 2`

src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 106:

> 104:                 // there is a single digit
> 105:                     2;
> 106:         };

Can we have a chain of `if`s or conditional expressions (`? :`)?

src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 129:

> 127: 
> 128:         return fd;
> 129:     }

Please be consistent with the usage of `final` for local vars in the context of a single method.

src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 147:

> 145:     public int getScale() {
> 146:         return -e;
> 147:     }

I'd prefer to have a `getExp()` rather than `getScale()` here, as everything here uses an exponent rather than a scale.
Then there's no need for the JavaDoc comment.

test/jdk/java/math/BigDecimal/ValueOfDouble.java line 41:

> 39: 
> 40: public class ValueOfDouble {
> 41:     private static final String DIGITS = "1234567899123456789"; // Enough digits to fill a long

Suggestion:

    private static final String DIGITS = "1234567000003456789"; // Enough digits to fill a long

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2088553632
PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2088558336
PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2088561193
PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2088593281
PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2088563587
PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2088576102

From aph at openjdk.org  Wed May 14 10:47:40 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 14 May 2025 10:47:40 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v6]
In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
Message-ID: <pLVddIXTpvroWRu-iYVzlqCAzvwmXViE7LuVZ4fSx0U=.d0c8dcef-740f-4113-aef3-194ebd2b78bf@github.com>

> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
> 
> 
> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op

Andrew Haley has updated the pull request incrementally with three additional commits since the last revision:

 - AvoidUnalignedAccesses
 - Temp
 - The cherry on the cake

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25147/files
  - new: https://git.openjdk.org/jdk/pull/25147/files/87eadb40..e5771988

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=04-05

  Stats: 20 lines in 1 file changed: 17 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25147/head:pull/25147

PR: https://git.openjdk.org/jdk/pull/25147

From markus at headcrashing.eu  Wed May 14 10:48:30 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Wed, 14 May 2025 12:48:30 +0200
Subject: RFC: 8356679: Using CharSequence::getChars internally
In-Reply-To: <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com>
References: <f4cf0270-eb00-4c52-99a4-8e8057bb2bc9@gmx.net>
 <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com>
 <f4330452-258c-42f8-a24b-9217da839892@headcrashing.eu>
 <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com>
Message-ID: <b43e53d6-eb0b-4074-80e4-ca7bc0bf64f0@headcrashing.eu>

Many of the modified classes derive from a common super class and share 
one needed common change (which is one of the points which are easy to 
see once you see all of those classes in a single PR, but hard to 
explain in plaint-text pre-PR mailing list threads), so at least those 
need to be discussed *together*. But to spare JBS and PRs, I can open 
the PR with just the first set of changes, and once we agree that this 
set is fine, I can push the next commit *in the same PR*. Otherwise we 
would need endless JBS, mailing list threads, and PRs, just to fixe a 
dozen internal code lines.

Having said that, does the current state of this thread count as 
"reached common agreement to file a PR" or do I still have to wait until 
more people chime in?

-Markus


Am 13.05.2025 um 15:10 schrieb Roger Riggs:
> Hi Markus,
>
> A main point was to avoid trying to do everything at once.
> The PR comments become hard to follow and intermingled and it takes 
> longer to get agreement because of the thrash in the PR.
>
> Roger
>
> On 5/13/25 5:05 AM, Markus KARG wrote:
>> Thank you, Roger.
>>
>> Actually the method helps in the "toString()" variants, too, as in 
>> some places we could *get rid* of "toString()" (which is more work 
>> than "just" a buffer due to the added compression complexity).
>>
>> In fact, I already took the time to rewrite *all* of them while 
>> waiting for the approval of this list posting. In *all* cases *less* 
>> buffering / copying is needed, and *less* "toString()" conversion 
>> (which is a copy under the hood) is needed. So if I would be allowed 
>> to show the code as a PR, it would be much easier to explain and 
>> discuss.
>>
>> A PR is the best place to discuss "how to code would change". In the 
>> worst case, let's drop it if we see that it is actually a bad thing.
>>
>> -Markus
>>
>>
>> Am 12.05.2025 um 20:18 schrieb Roger Riggs:
>>> Hi Markus,
>>>
>>> On the surface, its looks constructive.
>>> I suspect that many of these cases will turn into discussions about 
>>> the right/best/better way to buffer the characters.
>>> The getChars method only helps when extracting to a char array, many 
>>> of the current implementations create strings as the intermediary. 
>>> The advantage of the 1 character at a time technique is not needing 
>>> a (separated allocated) buffer.
>>> Consider taking a few at a time before launching into the whole set.
>>>
>>> $.02, Roger
>>>
>>> On 5/11/25 2:45 AM, Markus KARG wrote:
>>>> Dear Core Libs Team,
>>>>
>>>> I am hereby requesting comments on JDK-8356679.
>>>>
>>>> I would like to invest some time and set up a PR implementing Chen 
>>>> Liangs's proposal laid out in 
>>>> https://bugs.openjdk.org/browse/JDK-8356679. For your convenience, 
>>>> the text of that JBS is copied below. According to the Developer's 
>>>> Guide I do need to get broad agreement BEFORE filing a PR. 
>>>> Therefore, I kindly ask everybody to briefly show consent, so I may 
>>>> file a PR.
>>>>
>>>> Thanks
>>>> -Markus
>>>>
>>>>
>>>> Copy from https://bugs.openjdk.org/browse/JDK-8356679:
>>>>
>>>> Recently OpenJDK adopted the new method CharSequence::getChars(int, 
>>>> int, char[], int) for inclusion in Java 25. As a bulk reader 
>>>> method, it allows potentially improved efficiency over the 
>>>> previously available char-by-char reader method 
>>>> CharSequence::charAt(int).
>>>>
>>>> Chen Liang suggested on March 23rd on the core-lib-dev mailing list 
>>>> to use the new method within the internal source code of OpenJDK 
>>>> for the implementation of Appendables (see 
>>>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). 
>>>> The idea behind this is that the implementations might be more 
>>>> efficient then.
>>>>
>>>> A quick analysis of the OpenJDK source code identified (at least) 
>>>> the following classes which could potentially run more efficient 
>>>> when using CharSequence::getChars internally, thanks to bulk 
>>>> reading and / or prevention of internal copies / toString() 
>>>> conversions:
>>>> * java.io.Writer
>>>> * java.io.StringWriter
>>>> * java.io.PrintWriter
>>>> * java.io.BufferedWriter
>>>> * java.io.CharArrayWriter
>>>> * java.io.FileWriter
>>>> * java.io.OutputStreamWriter
>>>> * sun.nio.cs.StreamEncoder
>>>> * java.io.PrintStream
>>>> * java.nio.CharBuffer
>>>>
>>>> In the sense of "eat your own dog food", it makes sense to 
>>>> implement Chen's idea in (at least) those classes. Possibly more 
>>>> classes could get identified when taking a deeper look. Besides the 
>>>> potential efficiency improvements, it would be a good show case for 
>>>> the usage of the new API.
>>>>
>>>> The risk of this change should be low, as test coverage exists, and 
>>>> as the intended changes are solely internal to the implementation. 
>>>> No API will get changed. In some cases the JavaDocs will get 
>>>> slightly adapted where it currently exposes the actual 
>>>> implementation (to not lie in future).
>>>>
>>>
>

From jwaters at openjdk.org  Wed May 14 11:31:59 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 14 May 2025 11:31:59 GMT
Subject: RFR: 8342869: Errors related to unused code on Windows after
 8339120 in awt
In-Reply-To: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
References: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
Message-ID: <TYyWRtItPA-JDmdNEBW-CTWNBBWkzBEMEM4C3My2itg=.394e7d00-b43f-4dad-a092-55ae432a171c@github.com>

On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters <jwaters at openjdk.org> 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/...

Keep open

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21655#issuecomment-2879835298

From jpai at openjdk.org  Wed May 14 13:08:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 May 2025 13:08:58 GMT
Subject: RFR: 8341184: Clean up the interaction between the launcher native
 code and the LauncherHelper [v16]
In-Reply-To: <JHBC_-2uIDzTy40hi2OfmFH2-eh_XXtZrgpgiQIxd3U=.5e271baf-04ca-4eaf-b51c-c85b9248fd40@github.com>
References: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
 <JHBC_-2uIDzTy40hi2OfmFH2-eh_XXtZrgpgiQIxd3U=.5e271baf-04ca-4eaf-b51c-c85b9248fd40@github.com>
Message-ID: <hEWaagWgY5YG5vOge1l5JunU2YBkOaAb76D-VFsJgig=.61ba3a16-d6df-47a7-b15e-af3f11f9a33c@github.com>

On Mon, 24 Feb 2025 09:46:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change, which simplifies the interaction between the `java` launcher's native code with the `sun.launcher.LauncherHelper`? 
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8341184, this proposed change reduces the back and forth between the launcher's native code and the `LauncherHelper` class. This also removes the additional reflective lookups from the native code after the main class and main method have been determined by the `LauncherHelper`. 
>> 
>> Although this is a clean up of the code, the changes in the `LauncherHelper` to return a `MainEntry` have been done in a way to facilitate additional upcoming changes in this area, which propose to get rid of the JAR manifest parsing from the launcher's native code.
>> 
>> No new tests have been added. Existing tests in tier1, tier2 and tier3 continue to pass.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/e410af00...d1ac5174

I will move this to draft for now and will come back to this in the next release.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21256#issuecomment-2880182423

From syan at openjdk.org  Wed May 14 13:24:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 14 May 2025 13:24:54 GMT
Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder
 on static-jdk
In-Reply-To: <E986980rvWra05uWXYMdT8N4i_0RGxNC_KubDF6tXAw=.a6ab5563-b75c-45b2-b367-31d001cc294e@github.com>
References: <E986980rvWra05uWXYMdT8N4i_0RGxNC_KubDF6tXAw=.a6ab5563-b75c-45b2-b367-31d001cc294e@github.com>
Message-ID: <3RWZl77waTqYm1lm8ImxBegeni5IcB3jD0cUUiJvWJw=.11c71454-89b8-46ec-8aee-e484de538480@github.com>

On Tue, 13 May 2025 21:28:00 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR for skipping jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the context from https://bugs.openjdk.org/browse/JDK-8356904 description:
> 
> jdk/test/lib/process/TestNativeProcessBuilder.java (in lib-test/tier1) uses a native test launcher executable, exejvm-test-launcher, which has explicitly dependency on libjvm.so. The test fails on static-jdk. This is the same issue as [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276). With [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276), we decided to skip the affected hotspot tier1 tests on static-jdk. We should skip jdk/test/lib/process/TestNativeProcessBuilder.java on static-jdk as well. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK.

Changes requested by syan (Committer).

test/lib-test/TEST.ROOT line 31:

> 29: keys=randomness
> 30: 
> 31: # Minimum jtreg version

Shoule we update the copyright year for file TestNativeProcessBuilder.java

-------------

PR Review: https://git.openjdk.org/jdk/pull/25220#pullrequestreview-2840171571
PR Review Comment: https://git.openjdk.org/jdk/pull/25220#discussion_r2088931079

From duke at openjdk.org  Wed May 14 13:35:54 2025
From: duke at openjdk.org (Johannes Graham)
Date: Wed, 14 May 2025 13:35:54 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double) [v2]
In-Reply-To: <vgz0KQQNAF6ghUSislytUThBmK5EbuCq55h6_DHBJEs=.3bf90a16-a918-4cb5-b28d-e385857aa356@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
 <w48C4y0RR5togk9taQZCJlUN7IazrPf6sISpGDaON9Q=.49005247-e8ee-486a-b394-b745bfe2ef46@github.com>
 <vgz0KQQNAF6ghUSislytUThBmK5EbuCq55h6_DHBJEs=.3bf90a16-a918-4cb5-b28d-e385857aa356@github.com>
Message-ID: <KAVvFhI3UOqxT9D4842QwbjSnVTssVXZwTRVpXjeUuA=.7bc1a61c-1d33-430b-ac73-bb0075fcb4e2@github.com>

On Wed, 14 May 2025 09:55:35 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix code tag in javadoc
>
> src/java.base/share/classes/java/math/BigDecimal.java line 1408:
> 
>> 1406:         }
>> 1407: 
>> 1408:         return valueOf(s, fmt.getScale(), fmt.getPrecision());
> 
> I'd prefer to have a `getExp()` rather than `getScale()` in `FormattedFPDecimal`.

I was looking for a way clearly distinguish?it from getExponentRounded. Will go with getExp, since it makes more sense in the scope of that class.

> test/jdk/java/math/BigDecimal/ValueOfDouble.java line 41:
> 
>> 39: 
>> 40: public class ValueOfDouble {
>> 41:     private static final String DIGITS = "1234567899123456789"; // Enough digits to fill a long
> 
> Suggestion:
> 
>     private static final String DIGITS = "1234567000003456789"; // Enough digits to fill a long

What is the significance of the positioning of the zeros? I wasn't really attaching any significance to the digit values other than making it easy to count how many there were.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2088959379
PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2088963691

From duke at openjdk.org  Wed May 14 13:47:11 2025
From: duke at openjdk.org (Johannes Graham)
Date: Wed, 14 May 2025 13:47:11 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double) [v3]
In-Reply-To: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
Message-ID: <Qtr1w3cS5nW0ibDsssMUHDDKza0YANuSSO-tDZchpPY=.3f487e3c-4221-470b-a3a3-d06f36859bcc@github.com>

> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  address review suggestions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25173/files
  - new: https://git.openjdk.org/jdk/pull/25173/files/ba8d3933..e7d2d14b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25173&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25173&range=01-02

  Stats: 26 lines in 3 files changed: 2 ins; 12 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/25173.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25173/head:pull/25173

PR: https://git.openjdk.org/jdk/pull/25173

From pminborg at openjdk.org  Wed May 14 13:48:54 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 14 May 2025 13:48:54 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v6]
In-Reply-To: <pLVddIXTpvroWRu-iYVzlqCAzvwmXViE7LuVZ4fSx0U=.d0c8dcef-740f-4113-aef3-194ebd2b78bf@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
 <pLVddIXTpvroWRu-iYVzlqCAzvwmXViE7LuVZ4fSx0U=.d0c8dcef-740f-4113-aef3-194ebd2b78bf@github.com>
Message-ID: <Madyk99dkJ5YdCVlsll2t3jnD8hCi6IH9YfXdmCVfUo=.99f8f6db-0ece-46ab-b0e1-5abd5a41394e@github.com>

On Wed, 14 May 2025 10:47:40 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
>> 
>> 
>> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
>> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
>> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
>> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
>> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op
>
> Andrew Haley has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - AvoidUnalignedAccesses
>  - Temp
>  - The cherry on the cake

The changes in `SegmentBulkOperations` look good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2880312073

From roger.riggs at oracle.com  Wed May 14 13:57:29 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 14 May 2025 09:57:29 -0400
Subject: RFC: 8356679: Using CharSequence::getChars internally
In-Reply-To: <b43e53d6-eb0b-4074-80e4-ca7bc0bf64f0@headcrashing.eu>
References: <f4cf0270-eb00-4c52-99a4-8e8057bb2bc9@gmx.net>
 <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com>
 <f4330452-258c-42f8-a24b-9217da839892@headcrashing.eu>
 <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com>
 <b43e53d6-eb0b-4074-80e4-ca7bc0bf64f0@headcrashing.eu>
Message-ID: <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com>

Hi Markus,

Starting out with the common case is a good idea for the first PR.

I much prefer a PR with a single goal and that comes to a conclusion and 
does not add new features or changes after the PR is submitted.
I tend to lose interest in PRs with lots of churn, it means I have to 
re-review the bulk of it when there is a change and may wait days to let 
it settle down before coming back to it.

I tend to think the PR was not really ready to be reviewed if simple 
issues and corrections have to be made frequently.
Do your own checking for typos and copyrights and simple refactoring 
before opening the PR.
Quality before quantity or speed.

I'm fine with separate Jira issues that clearly delineate a specific 
scope and goal.

The title of this issue (8356679) doesn't identify the real goal.
It seems to be to improve performance or memory usage, not just to use a 
new API.

These are my personal opinions about contributions and process.

Regards, Roger


On 5/14/25 6:48 AM, Markus KARG wrote:
> Many of the modified classes derive from a common super class and 
> share one needed common change (which is one of the points which are 
> easy to see once you see all of those classes in a single PR, but hard 
> to explain in plaint-text pre-PR mailing list threads), so at least 
> those need to be discussed *together*. But to spare JBS and PRs, I can 
> open the PR with just the first set of changes, and once we agree that 
> this set is fine, I can push the next commit *in the same PR*. 
> Otherwise we would need endless JBS, mailing list threads, and PRs, 
> just to fixe a dozen internal code lines.
>
> Having said that, does the current state of this thread count as 
> "reached common agreement to file a PR" or do I still have to wait 
> until more people chime in?
>
> -Markus
>
>
> Am 13.05.2025 um 15:10 schrieb Roger Riggs:
>> Hi Markus,
>>
>> A main point was to avoid trying to do everything at once.
>> The PR comments become hard to follow and intermingled and it takes 
>> longer to get agreement because of the thrash in the PR.
>>
>> Roger
>>
>> On 5/13/25 5:05 AM, Markus KARG wrote:
>>> Thank you, Roger.
>>>
>>> Actually the method helps in the "toString()" variants, too, as in 
>>> some places we could *get rid* of "toString()" (which is more work 
>>> than "just" a buffer due to the added compression complexity).
>>>
>>> In fact, I already took the time to rewrite *all* of them while 
>>> waiting for the approval of this list posting. In *all* cases *less* 
>>> buffering / copying is needed, and *less* "toString()" conversion 
>>> (which is a copy under the hood) is needed. So if I would be allowed 
>>> to show the code as a PR, it would be much easier to explain and 
>>> discuss.
>>>
>>> A PR is the best place to discuss "how to code would change". In the 
>>> worst case, let's drop it if we see that it is actually a bad thing.
>>>
>>> -Markus
>>>
>>>
>>> Am 12.05.2025 um 20:18 schrieb Roger Riggs:
>>>> Hi Markus,
>>>>
>>>> On the surface, its looks constructive.
>>>> I suspect that many of these cases will turn into discussions about 
>>>> the right/best/better way to buffer the characters.
>>>> The getChars method only helps when extracting to a char array, 
>>>> many of the current implementations create strings as the 
>>>> intermediary. The advantage of the 1 character at a time technique 
>>>> is not needing a (separated allocated) buffer.
>>>> Consider taking a few at a time before launching into the whole set.
>>>>
>>>> $.02, Roger
>>>>
>>>> On 5/11/25 2:45 AM, Markus KARG wrote:
>>>>> Dear Core Libs Team,
>>>>>
>>>>> I am hereby requesting comments on JDK-8356679.
>>>>>
>>>>> I would like to invest some time and set up a PR implementing Chen 
>>>>> Liangs's proposal laid out in 
>>>>> https://bugs.openjdk.org/browse/JDK-8356679. For your convenience, 
>>>>> the text of that JBS is copied below. According to the Developer's 
>>>>> Guide I do need to get broad agreement BEFORE filing a PR. 
>>>>> Therefore, I kindly ask everybody to briefly show consent, so I 
>>>>> may file a PR.
>>>>>
>>>>> Thanks
>>>>> -Markus
>>>>>
>>>>>
>>>>> Copy from https://bugs.openjdk.org/browse/JDK-8356679:
>>>>>
>>>>> Recently OpenJDK adopted the new method 
>>>>> CharSequence::getChars(int, int, char[], int) for inclusion in 
>>>>> Java 25. As a bulk reader method, it allows potentially improved 
>>>>> efficiency over the previously available char-by-char reader 
>>>>> method CharSequence::charAt(int).
>>>>>
>>>>> Chen Liang suggested on March 23rd on the core-lib-dev mailing 
>>>>> list to use the new method within the internal source code of 
>>>>> OpenJDK for the implementation of Appendables (see 
>>>>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). 
>>>>> The idea behind this is that the implementations might be more 
>>>>> efficient then.
>>>>>
>>>>> A quick analysis of the OpenJDK source code identified (at least) 
>>>>> the following classes which could potentially run more efficient 
>>>>> when using CharSequence::getChars internally, thanks to bulk 
>>>>> reading and / or prevention of internal copies / toString() 
>>>>> conversions:
>>>>> * java.io.Writer
>>>>> * java.io.StringWriter
>>>>> * java.io.PrintWriter
>>>>> * java.io.BufferedWriter
>>>>> * java.io.CharArrayWriter
>>>>> * java.io.FileWriter
>>>>> * java.io.OutputStreamWriter
>>>>> * sun.nio.cs.StreamEncoder
>>>>> * java.io.PrintStream
>>>>> * java.nio.CharBuffer
>>>>>
>>>>> In the sense of "eat your own dog food", it makes sense to 
>>>>> implement Chen's idea in (at least) those classes. Possibly more 
>>>>> classes could get identified when taking a deeper look. Besides 
>>>>> the potential efficiency improvements, it would be a good show 
>>>>> case for the usage of the new API.
>>>>>
>>>>> The risk of this change should be low, as test coverage exists, 
>>>>> and as the intended changes are solely internal to the 
>>>>> implementation. No API will get changed. In some cases the 
>>>>> JavaDocs will get slightly adapted where it currently exposes the 
>>>>> actual implementation (to not lie in future).
>>>>>
>>>>
>>


From ihse at openjdk.org  Wed May 14 14:28:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 14:28:10 GMT
Subject: RFR: 8356977: UTF-8 cleanups
Message-ID: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>

I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

-------------

Commit messages:
 - Replace uncessary unicode characters with ASCII in instructions, and fix typo
 - Seems like typos in the comments
 - Fix unicode sequences in comments (previously missed)

Changes: https://git.openjdk.org/jdk/pull/25228/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25228&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356977
  Stats: 21 lines in 16 files changed: 0 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/25228.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25228/head:pull/25228

PR: https://git.openjdk.org/jdk/pull/25228

From ihse at openjdk.org  Wed May 14 14:34:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 14:34:37 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to UTF-8
Message-ID: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>

After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

-------------

Commit messages:
 - 8356978: Convert unicode sequences in Java source code to UTF-8

Changes: https://git.openjdk.org/jdk/pull/25229/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25229&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356978
  Stats: 9616 lines in 90 files changed: 0 ins; 0 del; 9616 mod
  Patch: https://git.openjdk.org/jdk/pull/25229.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25229/head:pull/25229

PR: https://git.openjdk.org/jdk/pull/25229

From duke at openjdk.org  Wed May 14 14:39:37 2025
From: duke at openjdk.org (Johannes Graham)
Date: Wed, 14 May 2025 14:39:37 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double) [v4]
In-Reply-To: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
Message-ID: <8zqr6fizVQmLTiJiKm1Qt5dwE6wtPxXNpqIonMWwtuA=.bc2f8ec3-7fab-49f5-95ab-d6f15812c842@github.com>

> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.

Johannes Graham has updated the pull request incrementally with three additional commits since the last revision:

 - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java
   
   Align better with spec
   
   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
 - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java
   
   Better alignment with spec
   
   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
 - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java
   
   Add another final
   
   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25173/files
  - new: https://git.openjdk.org/jdk/pull/25173/files/e7d2d14b..0cc32fc0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25173&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25173&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25173.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25173/head:pull/25173

PR: https://git.openjdk.org/jdk/pull/25173

From rgiulietti at openjdk.org  Wed May 14 14:39:37 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 14 May 2025 14:39:37 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double) [v3]
In-Reply-To: <Qtr1w3cS5nW0ibDsssMUHDDKza0YANuSSO-tDZchpPY=.3f487e3c-4221-470b-a3a3-d06f36859bcc@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
 <Qtr1w3cS5nW0ibDsssMUHDDKza0YANuSSO-tDZchpPY=.3f487e3c-4221-470b-a3a3-d06f36859bcc@github.com>
Message-ID: <fHBe8inLV29Ymd28OEsq4VDiQw2VkkmTym6HoWOddAo=.654178d3-e488-4c08-9b29-d981cdb23e78@github.com>

On Wed, 14 May 2025 13:47:11 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review suggestions

src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 94:

> 92:         final int targetPrec =
> 93:                 // No extra trailing digit needed
> 94:                 (-3 <= expR && expR <= -1) ? 1

Suggestion:

                (-3 <= expR && expR < 0) ? 1

Fully equivalent, but matches the `Double.toString(double)` spec more closely.

src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 97:

> 95: 
> 96:                 // Keep digits to left of decimal, plus leave a trailing zero
> 97:                 : (0 <= expR && expR <= 6) ? expR + 2 :

Suggestion:

                : (0 <= expR && expR < 7) ? expR + 2 :

Fully equivalent, but matches the `Double.toString(double)` spec more closely.

src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 109:

> 107:         if (prec < targetPrec) {
> 108:             // Add zeros needed to reach target precision
> 109:             int addZeros = targetPrec - prec;

Suggestion:

            final int addZeros = targetPrec - prec;

Just to be consistent with the usage of `final` in this method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2089090546
PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2089090644
PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2089092505

From rgiulietti at openjdk.org  Wed May 14 14:39:38 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 14 May 2025 14:39:38 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double) [v2]
In-Reply-To: <KAVvFhI3UOqxT9D4842QwbjSnVTssVXZwTRVpXjeUuA=.7bc1a61c-1d33-430b-ac73-bb0075fcb4e2@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
 <w48C4y0RR5togk9taQZCJlUN7IazrPf6sISpGDaON9Q=.49005247-e8ee-486a-b394-b745bfe2ef46@github.com>
 <vgz0KQQNAF6ghUSislytUThBmK5EbuCq55h6_DHBJEs=.3bf90a16-a918-4cb5-b28d-e385857aa356@github.com>
 <KAVvFhI3UOqxT9D4842QwbjSnVTssVXZwTRVpXjeUuA=.7bc1a61c-1d33-430b-ac73-bb0075fcb4e2@github.com>
Message-ID: <rtU19I8mvvFpc__efGV5aenVkpOZxmGcl9WyQURiepI=.d91b2e0d-c512-4b84-9927-43549d9385da@github.com>

On Wed, 14 May 2025 13:33:32 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> test/jdk/java/math/BigDecimal/ValueOfDouble.java line 41:
>> 
>>> 39: 
>>> 40: public class ValueOfDouble {
>>> 41:     private static final String DIGITS = "1234567899123456789"; // Enough digits to fill a long
>> 
>> Suggestion:
>> 
>>     private static final String DIGITS = "1234567000003456789"; // Enough digits to fill a long
>
> What is the significance of the positioning of the zeros? I wasn't really attaching any significance to the digit values other than making it easy to count how many there were. The zeros would combine with the exponent to miss some values for precision. I had also experimented with using 100...001, but it made for messier code. Going with your suggestion to start with.

The test copies a prefix, so we want to make sure that trailing zeros are processed correctly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25173#discussion_r2089099807

From rgiulietti at openjdk.org  Wed May 14 14:43:54 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 14 May 2025 14:43:54 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double)
In-Reply-To: <5qPlXTcqytoUz9n4SVAymurrnPSztCLg-CWWEOnsa98=.d2163abb-e96b-43c1-b821-547fe01d56dd@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
 <5qPlXTcqytoUz9n4SVAymurrnPSztCLg-CWWEOnsa98=.d2163abb-e96b-43c1-b821-547fe01d56dd@github.com>
Message-ID: <WGI1CzkmtVrSvxKF71ZZ461Ia2dZs3B04mQhXI2yqxI=.dd0e1eda-a045-4f8f-8a2d-b1018cac3868@github.com>

On Sun, 11 May 2025 16:32:02 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.
>
> On Aarch64 M4:
> 
> Benchmark                                Mode  Cnt   Score   Error  Units
> + BigDecimals.testValueOfWithDouble        avgt   15   9.913 ? 0.080  ns/op
> - BigDecimals.testValueOfWithDoubleString  avgt   15  65.846 ? 0.801  ns/op

Thanks @j3graham for this nice enhancement!

Before approval, let's give another 24 hours for people around the globe to have a chance for further comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25173#issuecomment-2880505868

From mhaessig at openjdk.org  Wed May 14 14:45:04 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Wed, 14 May 2025 14:45:04 GMT
Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id
 contains "-J"
Message-ID: <GJ80lme__hVwt5Y2yGHqCmxZta8fpTLGorMjYRkWjbo=.a7053f26-d608-4f29-978f-80364a8bafda@github.com>

When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at:

https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134

This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure.

-------------

Commit messages:
 - Add output to ease debugging, if the test fails
 - Fix test by searching for the beginning of a word

Changes: https://git.openjdk.org/jdk/pull/25230/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25230&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356974
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25230.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25230/head:pull/25230

PR: https://git.openjdk.org/jdk/pull/25230

From ihse at openjdk.org  Wed May 14 15:16:18 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 15:16:18 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
Message-ID: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>

Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences.

I have checked:
* U+00A0 NO-BREAK SPACE (NBSP)
* U+202F NARROW NO-BREAK SPACE (NNBSP)
* U+2007 FIGURE SPACE
* U+2060 WORD JOINER

In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences.

-------------

Commit messages:
 - Use sequences for valid nbsp usage
 - Remove mistaken nbsp

Changes: https://git.openjdk.org/jdk/pull/25234/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25234&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356980
  Stats: 36 lines in 8 files changed: 0 ins; 2 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/25234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25234/head:pull/25234

PR: https://git.openjdk.org/jdk/pull/25234

From adinn at openjdk.org  Wed May 14 15:38:58 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 14 May 2025 15:38:58 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v6]
In-Reply-To: <pLVddIXTpvroWRu-iYVzlqCAzvwmXViE7LuVZ4fSx0U=.d0c8dcef-740f-4113-aef3-194ebd2b78bf@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
 <pLVddIXTpvroWRu-iYVzlqCAzvwmXViE7LuVZ4fSx0U=.d0c8dcef-740f-4113-aef3-194ebd2b78bf@github.com>
Message-ID: <BJ48hkafKoSbonxesNQ-wKfLj6iIjxo0omp22ws8LMI=.9968a1e7-5893-47e6-a6d5-5684e1ba52e2@github.com>

On Wed, 14 May 2025 10:47:40 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
>> 
>> 
>> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
>> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
>> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
>> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
>> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op
>
> Andrew Haley has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - AvoidUnalignedAccesses
>  - Temp
>  - The cherry on the cake

Looks good to me.

-------------

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25147#pullrequestreview-2840674777

From jiangli at openjdk.org  Wed May 14 15:44:08 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 14 May 2025 15:44:08 GMT
Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder
 on static-jdk [v2]
In-Reply-To: <E986980rvWra05uWXYMdT8N4i_0RGxNC_KubDF6tXAw=.a6ab5563-b75c-45b2-b367-31d001cc294e@github.com>
References: <E986980rvWra05uWXYMdT8N4i_0RGxNC_KubDF6tXAw=.a6ab5563-b75c-45b2-b367-31d001cc294e@github.com>
Message-ID: <akvr3HuFyZubFssoMOl6_c7wwbKgTxXAEUJfgvnnkGs=.ba807f25-823c-48f3-8831-71067ac1cc31@github.com>

> Please review this PR for skipping jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the context from https://bugs.openjdk.org/browse/JDK-8356904 description:
> 
> jdk/test/lib/process/TestNativeProcessBuilder.java (in lib-test/tier1) uses a native test launcher executable, exejvm-test-launcher, which has explicitly dependency on libjvm.so. The test fails on static-jdk. This is the same issue as [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276). With [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276), we decided to skip the affected hotspot tier1 tests on static-jdk. We should skip jdk/test/lib/process/TestNativeProcessBuilder.java on static-jdk as well. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year in test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25220/files
  - new: https://git.openjdk.org/jdk/pull/25220/files/838a20d5..6037babe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25220&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25220&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25220.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25220/head:pull/25220

PR: https://git.openjdk.org/jdk/pull/25220

From jiangli at openjdk.org  Wed May 14 15:44:08 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 14 May 2025 15:44:08 GMT
Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder
 on static-jdk [v2]
In-Reply-To: <3RWZl77waTqYm1lm8ImxBegeni5IcB3jD0cUUiJvWJw=.11c71454-89b8-46ec-8aee-e484de538480@github.com>
References: <E986980rvWra05uWXYMdT8N4i_0RGxNC_KubDF6tXAw=.a6ab5563-b75c-45b2-b367-31d001cc294e@github.com>
 <3RWZl77waTqYm1lm8ImxBegeni5IcB3jD0cUUiJvWJw=.11c71454-89b8-46ec-8aee-e484de538480@github.com>
Message-ID: <Q7POLV448YdVXmt3fxXbEJYy4n4kOCmSX8sBK82QzDk=.55b98afc-d86d-4bf7-ac21-24515eecf317@github.com>

On Wed, 14 May 2025 13:21:37 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year in test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java.
>
> test/lib-test/TEST.ROOT line 31:
> 
>> 29: keys=randomness
>> 30: 
>> 31: # Minimum jtreg version
> 
> Shoule we update the copyright year for file TestNativeProcessBuilder.java

Done. Thanks for reminding.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25220#discussion_r2089240624

From kvn at openjdk.org  Wed May 14 16:08:55 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 14 May 2025 16:08:55 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v8]
In-Reply-To: <tjP4ZHZ79VRaDaKgsl38nBOBVrgjt1A0lQX4nndoTMg=.9698bf32-c090-47da-8b14-f3ad883c3e39@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <tjP4ZHZ79VRaDaKgsl38nBOBVrgjt1A0lQX4nndoTMg=.9698bf32-c090-47da-8b14-f3ad883c3e39@github.com>
Message-ID: <2gn7SekvlmULcWgKYlo53IKbh8NdBpV0JfGTMc7SsHY=.02f6f7f2-3e30-4e8a-8d14-f187cc2d3c11@github.com>

On Wed, 14 May 2025 06:16:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>> 
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
>> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
>> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
>> 
>> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
>> 
>> Examples:
>> 
>> 
>> # Create an AOT cache with a single command:
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> Hello World
>> Temporary AOTConfiguration recorded: foo.aot.config
>> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
>> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
>> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
>> AOTCache creation is complete: foo.aot 10240000 bytes
>> 
>> # Create logging file for the AOT cache assembly phase
>> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> 
>> 
>> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - java.md updates from @rose00
>  - Resolved differences with CSR JDK-8356010

Few comments.

src/hotspot/share/cds/cds_globals.hpp line 123:

> 121:   product(ccstr, AOTCacheOutput, nullptr,                                   \
> 122:           "Write AOT cache into this file (overrides AOTCache when "        \
> 123:           "writing)")                                                       \

This looks not complete description. And "override AOTCache .." is confusing.

src/hotspot/share/cds/metaspaceShared.cpp line 1150:

> 1148:   print_java_launcher(&ss);
> 1149:   const char* cmd = ss.freeze();
> 1150:   tty->print_cr("Launching child process %s to assemble AOT cache %s using configuration %s", cmd, AOTCacheOutput, AOTConfiguration);

I noticed that AOT produces outputs on TTY like this unconditionally. I think it is fine for development but for production we should use UL I think.
Was this discussed?

src/hotspot/share/runtime/arguments.cpp line 3060:

> 3058: }
> 3059: 
> 3060: static JavaVMOption* get_last_aotmode_arg(const JavaVMInitArgs* args) {

I don't like that we pollute `Arguments` code with AOT specific flags processing.
Can we move this into `CDSConfig`? Both these 2 new methods.

But I will agree if you want to keep it here. It is not critical.

src/java.base/share/man/java.md line 4141:

> 4139:        mode should be used only as a "fail-fast" debugging aid to check if your command-line
> 4140:        options are compatible with the AOT cache. An alternative is to run your application with
> 4141:        `-XX:AOTMode=auto -Xlog:cds,aot` to see if the AOT cache can be used or not.

`-Xlog:aot`

test/hotspot/jtreg/runtime/cds/appcds/aotFlags/AOTFlags.java line 166:

> 164:             "-XX:-AOTClassLinking",
> 165:             "-XX:AOTConfiguration=" + aotConfigFile,
> 166:             "-Xlog:cds=debug",

`-Xlog:aot`
I assume JDK-8356595: "Convert -Xlog:cds to -Xlog:aot " will be pushed first.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2840679467
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089234532
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089261456
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089267274
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089274796
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089279429

From acobbs at openjdk.org  Wed May 14 16:18:58 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 14 May 2025 16:18:58 GMT
Subject: RFR: 8143850: Add indexed get() and set() methods to ArrayDeque
In-Reply-To: <FqQcbJZGky9kSxgufXkrarVqOWIddA41Y_1fN0ZOL4k=.246fb74c-ba6e-417c-adf3-cde5b8e785f9@github.com>
References: <FqQcbJZGky9kSxgufXkrarVqOWIddA41Y_1fN0ZOL4k=.246fb74c-ba6e-417c-adf3-cde5b8e785f9@github.com>
Message-ID: <63QyI-7zKduRVpGwW8IODYko4U9EzuTtFOYeeJEAo5E=.1c242db8-e2af-4e6a-9793-168ece2f7c4a@github.com>

On Mon, 12 May 2025 18:24:27 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Because it is backed by an array, the `ArrayDeque` class has the ability to get and replace any element in the list (accessed by index) in constant time. However, this capability is not exposed in the API.
> 
> Please review this PR which adds the following two new methods to `ArrayDeque`:
> * `public E get(int index)`
> * `public E set(int index, E element)`

Closing this PR for now while we decide what is the best approach.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25189#issuecomment-2880816417

From acobbs at openjdk.org  Wed May 14 16:18:58 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 14 May 2025 16:18:58 GMT
Subject: Withdrawn: 8143850: Add indexed get() and set() methods to ArrayDeque
In-Reply-To: <FqQcbJZGky9kSxgufXkrarVqOWIddA41Y_1fN0ZOL4k=.246fb74c-ba6e-417c-adf3-cde5b8e785f9@github.com>
References: <FqQcbJZGky9kSxgufXkrarVqOWIddA41Y_1fN0ZOL4k=.246fb74c-ba6e-417c-adf3-cde5b8e785f9@github.com>
Message-ID: <S4pLKt5pFt8pjQdTDW59KDgNducmaAHxnGl30ePnD34=.7d1dd210-e4b4-4310-b992-a527d746447f@github.com>

On Mon, 12 May 2025 18:24:27 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Because it is backed by an array, the `ArrayDeque` class has the ability to get and replace any element in the list (accessed by index) in constant time. However, this capability is not exposed in the API.
> 
> Please review this PR which adds the following two new methods to `ArrayDeque`:
> * `public E get(int index)`
> * `public E set(int index, E element)`

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25189

From henryjen at openjdk.org  Wed May 14 16:42:56 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 14 May 2025 16:42:56 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v6]
In-Reply-To: <kqx3sTJHVWdZpzTKzo7Ak7bYnBJqbLD1hkkJtK4okwg=.e26d85ff-7ea4-40e1-8593-dd424a0739de@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <Uvb8haTDHaSUlFccwMonvOOpnMogpbjr2KpffroxpmQ=.0e863939-4729-4ab6-9d67-f276570e9084@github.com>
 <kqx3sTJHVWdZpzTKzo7Ak7bYnBJqbLD1hkkJtK4okwg=.e26d85ff-7ea4-40e1-8593-dd424a0739de@github.com>
Message-ID: <BCRh35_h9tPnYU1KvHxTj7VpT4k7hfA9gTA9VdTfrrk=.5d8804f5-acfd-4e6c-b65a-cd8dbbfe5208@github.com>

On Wed, 7 May 2025 17:41:07 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore Validator access level
>
> test/jdk/tools/jar/ValidatorTest.java line 145:
> 
>> 143:         var template = out.toByteArray();
>> 144:         // ISO_8859_1 to keep the 8-bit value
>> 145:         var s = new String(template, StandardCharsets.ISO_8859_1);
> 
> Ok, but the zip is being created using UTF_8....

UTF-8 messed up the index, we don't want any conversion to happen.
Warning: Entry META-INFMAANIFEST.MF in local file header is not in central directory
Warning: Entry META-INF/BANIFEST.MF in local file header is not in central directory
Warning: Entry METAMINF/AANIFEST.MF in central directory is not in local file header
Warning: Entry METAMINF/BANIFEST.MF in central directory is not in local file header

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2089340789

From lancea at openjdk.org  Wed May 14 16:46:00 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 May 2025 16:46:00 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: <JoYBy9mw1zJ99-VgFw2GN7T5x1nSptIDqBlRx4HxEqY=.7f36a29c-292e-488f-a9d3-1a4fb0abe19b@github.com>

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

Thank. you David for your work here

A few comments on a quick pass in addition to those from Alan & Jai

The copyright will also need to be updated

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 95:

> 93: 
> 94:     private static final Set<PosixFilePermission> DEFAULT_PERMISSIONS =
> 95:         PosixFilePermissions.fromString("rwxrwxrwx");

I am not convinced this needs to be changed as it becomes a  personal style preference

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 113:

> 111:     final ZipCoder zc;
> 112:     private final ZipPath rootdir;
> 113:     // Start readOnly (safe mode) and maybe reset at end of initialization.

maybe -> may be

test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 219:

> 217:             assertFalse(fs.isReadOnly());
> 218:             if (!"Default version".equals(Files.readString(fs.getPath("file.txt"), UTF_8))) {
> 219:                 throw new RuntimeException("unexpected file content");

could also consider

fail("unexpected file content");

test/jdk/jdk/nio/zipfs/TestPosix.java line 434:

> 432:         createTestZipFile(ZIP_FILE, ENV_DEFAULT).close();
> 433:         // check entries on zipfs with default options
> 434:         try (FileSystem zip = FileSystems.newFileSystem(ZIP_FILE, ENV_DEFAULT)) {

This tests an empty Map and should still be a test as it is different from ENV_READ_ONLY

-------------

PR Review: https://git.openjdk.org/jdk/pull/25178#pullrequestreview-2840686940
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2089239326
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2089240538
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2089339910
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2089344316

From prr at openjdk.org  Wed May 14 17:01:55 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 14 May 2025 17:01:55 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
Message-ID: <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>

On Wed, 14 May 2025 15:11:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences.
> 
> I have checked:
> * U+00A0 NO-BREAK SPACE (NBSP)
> * U+202F NARROW NO-BREAK SPACE (NNBSP)
> * U+2007 FIGURE SPACE
> * U+2060 WORD JOINER
> 
> In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences.

src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties line 39:

> 37: GTKColorChooserPanel.hue.textAndMnemonic=&Teinte :
> 38: 
> 39: GTKColorChooserPanel.red.textAndMnemonic=Roug&e\u00a0:

So, this exactly reverses what was done in the fix for https://bugs.openjdk.org/browse/JDK-8301991
But I think you know that ..  since you commented on the PR

The fix was done by @justin-curtis-lu and reviewed by
@naotoj so I think I'd like to get their opinion on this

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2089371921

From smarks at openjdk.org  Wed May 14 17:03:56 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 14 May 2025 17:03:56 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
Message-ID: <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com>

On Tue, 13 May 2025 15:33:39 GMT, Brian Burkhalter <bpb at openjdk.org> 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: "stream" -> "reader"

src/java.base/share/classes/java/io/Reader.java line 403:

> 401:         char[] str = new char[TRANSFER_BUFFER_SIZE];
> 402:         int n;
> 403:         while ((n = read(str)) != -1) {

I'd suggest changing this call to `this.read(str, 0, str.length)` so that all concrete implementations in this class call only the abstract three-arg read() method. Using `this` is optional but it emphasizes that this is a self-call. (It's done in only one other place in this file already.)

Also, the variable name `str` is confusing since this isn't a String. I'd suggest `cbuf` instead as that name is used for char arrays elsewhere.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089375168

From lancea at openjdk.org  Wed May 14 17:06:55 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 May 2025 17:06:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
Message-ID: <Nl4NgrazqDls5EPFcVWIcNlBc1rFTf1hUKKuN5LNNtw=.7a53e187-1027-4376-9400-371c67515542@github.com>

On Mon, 12 May 2025 10:16:33 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment based on current behaviour.

test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 207:

> 205:                         Map.of("create", true, "accessMode", "badValue")));
> 206:     }
> 207: 

You could simplify the above tests using a DataProvider similar to

@DataProvider(name = "zipfsMap")
protected Object[][] zipfsMap() {
    return new Object[][]{
            {Map.of(), NoSuchFileException.class},
            {Map.of("accessMode", "readOnly"), NoSuchFileException.class},
            {Map.of("accessMode", "readWrite"),  NoSuchFileException.class},
            {Map.of("create", true, "accessMode", "readOnly"),  IllegalArgumentException.class},
            {Map.of("create", true, "accessMode", "badValue"),  IllegalArgumentException.class},
    };
@Test(dataProvider = "zipfsMap?)
public void testZipFSCreationException(Map<String, String> env, Class<T> exception) throws Exception {
       assertThrows(exception, () -> FileSystems.newFileSystem(noSuchZip, env));
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2089378491

From jlu at openjdk.org  Wed May 14 17:21:54 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 14 May 2025 17:21:54 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
Message-ID: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>

On Wed, 14 May 2025 16:59:23 GMT, Phil Race <prr at openjdk.org> wrote:

>> Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences.
>> 
>> I have checked:
>> * U+00A0 NO-BREAK SPACE (NBSP)
>> * U+202F NARROW NO-BREAK SPACE (NNBSP)
>> * U+2007 FIGURE SPACE
>> * U+2060 WORD JOINER
>> 
>> In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences.
>
> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties line 39:
> 
>> 37: GTKColorChooserPanel.hue.textAndMnemonic=&Teinte :
>> 38: 
>> 39: GTKColorChooserPanel.red.textAndMnemonic=Roug&e\u00a0:
> 
> So, this exactly reverses what was done in the fix for https://bugs.openjdk.org/browse/JDK-8301991
> But I think you know that ..  since you commented on the PR
> 
> The fix was done by @justin-curtis-lu and reviewed by
> @naotoj so I think I'd like to get their opinion on this

For the l10n files, they are synced by the translation team and we don't edit them. IMO, I think it's fine leaving those ones as is. Especially because language rules can cause different spacing and punctuation characters, so generally we don't ensure translations are equivalent to the original file's value in that regard. (So viewing them as a Unicode escape sequence vs UTF-8 literal may not bring much benefit.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2089399946

From duke at openjdk.org  Wed May 14 17:27:57 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 14 May 2025 17:27:57 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com>
Message-ID: <3dImE74ioqCoWHkOx_sQIbUIAFM5Y9WX920wkyMkZ9c=.af17f449-9ecf-4d0f-84ef-8d9068af0ab3@github.com>

On Wed, 14 May 2025 17:01:30 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354724: "stream" -> "reader"
>
> src/java.base/share/classes/java/io/Reader.java line 403:
> 
>> 401:         char[] str = new char[TRANSFER_BUFFER_SIZE];
>> 402:         int n;
>> 403:         while ((n = read(str)) != -1) {
> 
> I'd suggest changing this call to `this.read(str, 0, str.length)` so that all concrete implementations in this class call only the abstract three-arg read() method. Using `this` is optional but it emphasizes that this is a self-call. (It's done in only one other place in this file already.)
> 
> Also, the variable name `str` is confusing since this isn't a String. I'd suggest `cbuf` instead as that name is used for char arrays elsewhere.

I think `read(str)` is to be preferred over `read(str, 0, str.length()` as it allows implementations to provide optimized implementations. What the caller of the new methods wants to achieve is getting everything in the best possible way, which is, in the most optimized way. If we go around high-level methods, we should have a good reason for!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089409620

From lancea at openjdk.org  Wed May 14 17:29:52 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 May 2025 17:29:52 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v6]
In-Reply-To: <BCRh35_h9tPnYU1KvHxTj7VpT4k7hfA9gTA9VdTfrrk=.5d8804f5-acfd-4e6c-b65a-cd8dbbfe5208@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <Uvb8haTDHaSUlFccwMonvOOpnMogpbjr2KpffroxpmQ=.0e863939-4729-4ab6-9d67-f276570e9084@github.com>
 <kqx3sTJHVWdZpzTKzo7Ak7bYnBJqbLD1hkkJtK4okwg=.e26d85ff-7ea4-40e1-8593-dd424a0739de@github.com>
 <BCRh35_h9tPnYU1KvHxTj7VpT4k7hfA9gTA9VdTfrrk=.5d8804f5-acfd-4e6c-b65a-cd8dbbfe5208@github.com>
Message-ID: <0880cZA9IZKMn3ctbmhkEYw_1TkFjQ6hnDQhXVq7e7E=.43ea3a53-dc89-47c6-9710-2a99d7cbf598@github.com>

On Wed, 14 May 2025 16:39:54 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> UTF-8 messed up the index, we don't want any conversion to happen. Warning: Entry META-INFMAANIFEST.MF in local file header is not in central directory Warning: Entry META-INF/BANIFEST.MF in local file header is not in central directory Warning: Entry METAMINF/AANIFEST.MF in central directory is not in local file header Warning: Entry METAMINF/BANIFEST.MF in central directory is not in local file header

Without looking into this in finer detail I am not sure what the issue is and is why the other tests typically use the actual offset to modify.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2089413418

From naoto at openjdk.org  Wed May 14 17:36:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 May 2025 17:36:51 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
Message-ID: <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>

On Wed, 14 May 2025 17:18:35 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties line 39:
>> 
>>> 37: GTKColorChooserPanel.hue.textAndMnemonic=&Teinte :
>>> 38: 
>>> 39: GTKColorChooserPanel.red.textAndMnemonic=Roug&e\u00a0:
>> 
>> So, this exactly reverses what was done in the fix for https://bugs.openjdk.org/browse/JDK-8301991
>> But I think you know that ..  since you commented on the PR
>> 
>> The fix was done by @justin-curtis-lu and reviewed by
>> @naotoj so I think I'd like to get their opinion on this
>
> For the l10n files, they are synced by the translation team and we don't edit them. IMO, I think it's fine leaving those ones as is. Especially because language rules can cause different spacing and punctuation characters, so generally we don't ensure translations are equivalent to the original file's value in that regard. (So viewing them as a Unicode escape sequence vs UTF-8 literal may not bring much benefit.)

I believe it is OK to leave these as UTF-8 native characters, as these files are l10n resource bundles. If we wanted to replace those look-alike spaces to unicode escapes, other characters may also need the same treatment, such as hyphen-minus, quotations, etc. In fact there are lot more look alikes defined in the unicode consortium (https://www.unicode.org/Public/security/latest/confusables.txt), and I don't think we would want to convert them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2089424644

From naoto at openjdk.org  Wed May 14 17:45:02 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 May 2025 17:45:02 GMT
Subject: RFR: 8356420: Provide examples on wrapping System.in [v6]
In-Reply-To: <VwNp5Cm91ConpVD6zzob2uwVNNf5GuUc7s6mVeefp0g=.13138944-a496-4487-b906-3eb4b69f28f7@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
 <VwNp5Cm91ConpVD6zzob2uwVNNf5GuUc7s6mVeefp0g=.13138944-a496-4487-b906-3eb4b69f28f7@github.com>
Message-ID: <g7Lv_Aol6NuEvmMt1WcjtcByjwU1G53k-1us0bvCfvQ=.98fab594-9b89-47e9-8a6c-de84b3def36f@github.com>

On Tue, 13 May 2025 03:15:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed an erroneous curly brace

Thank you for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25155#issuecomment-2881038072

From naoto at openjdk.org  Wed May 14 17:45:03 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 May 2025 17:45:03 GMT
Subject: Integrated: 8356420: Provide examples on wrapping System.in
In-Reply-To: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
References: <BXxZgq9LT33iWI61ljBbUXX2OOU7nPQCmcHBb4b9uLE=.21a38f77-a2ab-4c52-bbdc-50dcc09410a8@github.com>
Message-ID: <7aaSHikGxSrfTrOoJIKavSuV-UgqpfKvrmlKUQSmuVU=.2d692e84-3434-449a-90c6-3287ba343351@github.com>

On Fri, 9 May 2025 19:53:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> With the introduction of `stdin.encoding` ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance for users to decode `System.in` would be desirable. Adding examples in the field description would help.

This pull request has now been integrated.

Changeset: 7c8e273f
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7c8e273fde644bbc2def4a1134a82b8eb8d33d53
Stats:     41 lines in 4 files changed: 32 ins; 0 del; 9 mod

8356420: Provide examples on wrapping System.in

Reviewed-by: liach, smarks, alanb, bpb, iris

-------------

PR: https://git.openjdk.org/jdk/pull/25155

From bpb at openjdk.org  Wed May 14 17:45:41 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 May 2025 17:45:41 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v20]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: <RvZzQ1eiZbXNAWtMyLzXALYjTHUE77x_S2TSf6pLKrs=.e13dfebf-6b80-4da1-ba36-2612c670fa25@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 readAllCharsAsString as suggested; move test to proper location

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/98387b0d..3cbaede9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=18-19

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From duke at openjdk.org  Wed May 14 17:45:41 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 14 May 2025 17:45:41 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
Message-ID: <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>

On Tue, 13 May 2025 15:33:39 GMT, Brian Burkhalter <bpb at openjdk.org> 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: "stream" -> "reader"

src/java.base/share/classes/java/io/Reader.java line 205:

> 203:             public String readAllAsString() throws IOException {
> 204:                 ensureOpen();
> 205:                 String result = cs.toString().substring(next);

For sake of efficiency can we please *first* limit and copy *last*? If `cs` refers to a huge object and `next` is just few bytes before `length()`, it makes no sense to copy the huge memory block just to return one or two characters finally. ? 

`result = cs.subSequence(next, cs.length()).toString()`?

src/java.base/share/classes/java/io/Reader.java line 500:

> 498:      * @since 25
> 499:      */
> 500:     public String readAllAsString() throws IOException {

Still thinking that declaring `CharSequence` instead of `String` would be beneficial. In case a `Reader` implementation reads from I/O, the implementation could so return a block of native memory without turning it into a Java `String` just for sake of fulfilling the API. In case of servers for example, the information often is passed-through from one I/O source to another I/O sink *unmodified*, which means, the `String` then is turned into *a new* native memory block again; double native memory used *plus* on-heap memory used, without any benefit. Can we please provide I/O APIs which do *not* enforce duplicate copying to and from `String` in such scenarios? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089421861
PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089436642

From bpb at openjdk.org  Wed May 14 17:45:41 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 May 2025 17:45:41 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <3dImE74ioqCoWHkOx_sQIbUIAFM5Y9WX920wkyMkZ9c=.af17f449-9ecf-4d0f-84ef-8d9068af0ab3@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com>
 <3dImE74ioqCoWHkOx_sQIbUIAFM5Y9WX920wkyMkZ9c=.af17f449-9ecf-4d0f-84ef-8d9068af0ab3@github.com>
Message-ID: <4T4npViSWy-EFy6758EMIx2cRHmYONULq2v1Dhjb4JU=.60d1efd4-c310-4176-9107-bb4e3c7030e0@github.com>

On Wed, 14 May 2025 17:25:00 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 403:
>> 
>>> 401:         char[] str = new char[TRANSFER_BUFFER_SIZE];
>>> 402:         int n;
>>> 403:         while ((n = read(str)) != -1) {
>> 
>> I'd suggest changing this call to `this.read(str, 0, str.length)` so that all concrete implementations in this class call only the abstract three-arg read() method. Using `this` is optional but it emphasizes that this is a self-call. (It's done in only one other place in this file already.)
>> 
>> Also, the variable name `str` is confusing since this isn't a String. I'd suggest `cbuf` instead as that name is used for char arrays elsewhere.
>
> I think `read(str)` is to be preferred over `read(str, 0, str.length()` as it allows implementations to provide optimized implementations. What the caller of the new methods wants to achieve is getting everything in the best possible way, which is, in the most optimized way. If we go around high-level methods, we should have a good reason for!

All other self-calls to a `read` method are to the three-arg abstract method:

$ grep read( src/java.base/share/classes/java/io/Reader.java | grep -v public | grep -v *
            nread = this.read(cbuf, off, rem);
            nread = read(cbuf, 0, len);
        if (read(cb, 0, 1) == -1)
        return read(cbuf, 0, cbuf.length);
        while ((nread = read(cbuf, 0, cbuf.length)) != -1) {
                int nc = read(skipBuffer, 0, (int)Math.min(r, nn));
        while ((nRead = read(buffer, 0, TRANSFER_BUFFER_SIZE)) >= 0) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089432945

From bpb at openjdk.org  Wed May 14 17:45:41 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 May 2025 17:45:41 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <4T4npViSWy-EFy6758EMIx2cRHmYONULq2v1Dhjb4JU=.60d1efd4-c310-4176-9107-bb4e3c7030e0@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com>
 <3dImE74ioqCoWHkOx_sQIbUIAFM5Y9WX920wkyMkZ9c=.af17f449-9ecf-4d0f-84ef-8d9068af0ab3@github.com>
 <4T4npViSWy-EFy6758EMIx2cRHmYONULq2v1Dhjb4JU=.60d1efd4-c310-4176-9107-bb4e3c7030e0@github.com>
Message-ID: <3kJUC9n4dQcRHW1etWe0x3k_yP_B4thpst8cG9JrMZQ=.672d3b67-7237-48e5-98fa-057852c23ca4@github.com>

On Wed, 14 May 2025 17:39:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I think `read(str)` is to be preferred over `read(str, 0, str.length()` as it allows implementations to provide optimized implementations. What the caller of the new methods wants to achieve is getting everything in the best possible way, which is, in the most optimized way. If we go around high-level methods, we should have a good reason for!
>
> All other self-calls to a `read` method are to the three-arg abstract method:
> 
> $ grep read( src/java.base/share/classes/java/io/Reader.java | grep -v public | grep -v *
>             nread = this.read(cbuf, off, rem);
>             nread = read(cbuf, 0, len);
>         if (read(cb, 0, 1) == -1)
>         return read(cbuf, 0, cbuf.length);
>         while ((nread = read(cbuf, 0, cbuf.length)) != -1) {
>                 int nc = read(skipBuffer, 0, (int)Math.min(r, nn));
>         while ((nRead = read(buffer, 0, TRANSFER_BUFFER_SIZE)) >= 0) {

> so that all concrete implementations in this class call only the abstract three-arg read() method

Done in 3cbaede and also `str` -> `cbuf`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089436030

From smarks at openjdk.org  Wed May 14 17:45:41 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 14 May 2025 17:45:41 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <3kJUC9n4dQcRHW1etWe0x3k_yP_B4thpst8cG9JrMZQ=.672d3b67-7237-48e5-98fa-057852c23ca4@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com>
 <3dImE74ioqCoWHkOx_sQIbUIAFM5Y9WX920wkyMkZ9c=.af17f449-9ecf-4d0f-84ef-8d9068af0ab3@github.com>
 <4T4npViSWy-EFy6758EMIx2cRHmYONULq2v1Dhjb4JU=.60d1efd4-c310-4176-9107-bb4e3c7030e0@github.com>
 <3kJUC9n4dQcRHW1etWe0x3k_yP_B4thpst8cG9JrMZQ=.672d3b67-7237-48e5-98fa-057852c23ca4@github.com>
Message-ID: <a6uoLPrncSxGv6y3P60m2o3ZT0POmwRr7z8nTjD_Q68=.d4ac9503-b29e-4aec-a75d-f0c031166721@github.com>

On Wed, 14 May 2025 17:40:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> All other self-calls to a `read` method are to the three-arg abstract method:
>> 
>> $ grep read( src/java.base/share/classes/java/io/Reader.java | grep -v public | grep -v *
>>             nread = this.read(cbuf, off, rem);
>>             nread = read(cbuf, 0, len);
>>         if (read(cb, 0, 1) == -1)
>>         return read(cbuf, 0, cbuf.length);
>>         while ((nread = read(cbuf, 0, cbuf.length)) != -1) {
>>                 int nc = read(skipBuffer, 0, (int)Math.min(r, nn));
>>         while ((nRead = read(buffer, 0, TRANSFER_BUFFER_SIZE)) >= 0) {
>
>> so that all concrete implementations in this class call only the abstract three-arg read() method
> 
> Done in 3cbaede and also `str` -> `cbuf`.

The code should use the three-arg read() call in order to limit self-calls, in order to avoid the fragile base class problem. At some point we might want to add implSpec tags to specify this. See my previous comments relate to this topic: 

https://github.com/openjdk/jdk/pull/24728#issuecomment-2848332415

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089439008

From duke at openjdk.org  Wed May 14 17:47:36 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 14 May 2025 17:47:36 GMT
Subject: RFR: 8077587: BigInteger Roots [v14]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <z6BGJ_MXtgs0mpc3dFXInN-1T81fNcGPoFBoHGmitCk=.3b0d7a3d-3d28-4370-93ab-9532be68a029@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Use type long for bitLength instead of int

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/32a5e5ec..c8e1b815

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=12-13

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From duke at openjdk.org  Wed May 14 17:59:55 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 14 May 2025 17:59:55 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <a6uoLPrncSxGv6y3P60m2o3ZT0POmwRr7z8nTjD_Q68=.d4ac9503-b29e-4aec-a75d-f0c031166721@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com>
 <3dImE74ioqCoWHkOx_sQIbUIAFM5Y9WX920wkyMkZ9c=.af17f449-9ecf-4d0f-84ef-8d9068af0ab3@github.com>
 <4T4npViSWy-EFy6758EMIx2cRHmYONULq2v1Dhjb4JU=.60d1efd4-c310-4176-9107-bb4e3c7030e0@github.com>
 <3kJUC9n4dQcRHW1etWe0x3k_yP_B4thpst8cG9JrMZQ=.672d3b67-7237-48e5-98fa-057852c23ca4@github.com>
 <a6uoLPrncSxGv6y3P60m2o3ZT0POmwRr7z8nTjD_Q68=.d4ac9503-b29e-4aec-a75d-f0c031166721@github.com>
Message-ID: <L6ovQHi9B7L8OYP83pDLW1MzNOXhZYABPEQpfwUOyf4=.97b4752b-13f5-40fc-a8d9-447380be2fbb@github.com>

On Wed, 14 May 2025 17:42:33 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>>> so that all concrete implementations in this class call only the abstract three-arg read() method
>> 
>> Done in 3cbaede and also `str` -> `cbuf`.
>
> The code should use the three-arg read() call in order to limit self-calls, in order to avoid the fragile base class problem. At some point we might want to add implSpec tags to specify this. See my previous comments relate to this topic: 
> 
> https://github.com/openjdk/jdk/pull/24728#issuecomment-2848332415

I know that comment already, but IMHO we can simply use `@implSpec` to unambiguously make clear that this method invokes `read(char[])` to allow optimized implementations, and it *might* in turn invoke `read(char[],int,int)`, but this is *not guaranteed*. A class is only fragile as long as we do not *document* what it will do.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089456975

From liach at openjdk.org  Wed May 14 17:59:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 May 2025 17:59:57 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
Message-ID: <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>

On Wed, 14 May 2025 17:41:12 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354724: "stream" -> "reader"
>
> src/java.base/share/classes/java/io/Reader.java line 500:
> 
>> 498:      * @since 25
>> 499:      */
>> 500:     public String readAllAsString() throws IOException {
> 
> Still thinking that declaring `CharSequence` instead of `String` would be beneficial. In case a `Reader` implementation reads from I/O, the implementation could so return a block of native memory without turning it into a Java `String` just for sake of fulfilling the API. In case of servers for example, the information often is passed-through from one I/O source to another I/O sink *unmodified*, which means, the `String` then is turned into *a new* native memory block again; double native memory used *plus* on-heap memory used, without any benefit. Can we please provide I/O APIs which do *not* enforce duplicate copying to and from `String` in such scenarios? ?

I think this is just a convenience API. A CharSequence-returning API would suit better if it supports arbitrarily long lengths (assuming such a length is in the range of int), while String has implementation limits on lengths and is allowed to fail for this API with OOME. If we make this a CharSequence-returning API that fails with OOME for String implementation limits, I don't think this will please anybody.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089454629

From duke at openjdk.org  Wed May 14 17:59:57 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 14 May 2025 17:59:57 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <nCFdoAHy2RkNENhaRhdaMDbO3iiAuV-AsirMDJoS0Dc=.0177c4cd-1e71-494f-8956-13edc7eb0551@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
 <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>
 <nCFdoAHy2RkNENhaRhdaMDbO3iiAuV-AsirMDJoS0Dc=.0177c4cd-1e71-494f-8956-13edc7eb0551@github.com>
Message-ID: <BctFVukNg2CVXVsPVF96howIOf-A8N_G-AIClpaqmgE=.53d54891-c098-4922-81c7-ddd0818c647d@github.com>

On Wed, 14 May 2025 17:56:04 GMT, Markus KARG <duke at openjdk.org> wrote:

>> I think this is just a convenience API. A CharSequence-returning API would suit better if it supports arbitrarily long lengths (assuming such a length is in the range of int), while String has implementation limits on lengths and is allowed to fail for this API with OOME. If we make this a CharSequence-returning API that fails with OOME for String implementation limits, I don't think this will please anybody.
>
> As being a server developer for decades I need to say that I would love to have this not for convenience but for the performance reasons explained above, and that `int` length is perfect to speed up 99,9% of all cases. So we should not forget about `CharSequence` hastily.

BTW, it will not fail with OOME, but it should throw IOE in that case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089464567

From duke at openjdk.org  Wed May 14 17:59:57 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 14 May 2025 17:59:57 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
 <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>
Message-ID: <nCFdoAHy2RkNENhaRhdaMDbO3iiAuV-AsirMDJoS0Dc=.0177c4cd-1e71-494f-8956-13edc7eb0551@github.com>

On Wed, 14 May 2025 17:52:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 500:
>> 
>>> 498:      * @since 25
>>> 499:      */
>>> 500:     public String readAllAsString() throws IOException {
>> 
>> Still thinking that declaring `CharSequence` instead of `String` would be beneficial. In case a `Reader` implementation reads from I/O, the implementation could so return a block of native memory without turning it into a Java `String` just for sake of fulfilling the API. In case of servers for example, the information often is passed-through from one I/O source to another I/O sink *unmodified*, which means, the `String` then is turned into *a new* native memory block again; double native memory used *plus* on-heap memory used, without any benefit. Can we please provide I/O APIs which do *not* enforce duplicate copying to and from `String` in such scenarios? ?
>
> I think this is just a convenience API. A CharSequence-returning API would suit better if it supports arbitrarily long lengths (assuming such a length is in the range of int), while String has implementation limits on lengths and is allowed to fail for this API with OOME. If we make this a CharSequence-returning API that fails with OOME for String implementation limits, I don't think this will please anybody.

As being a server developer for decades I need to say that I would love to have this not for convenience but for the performance reasons explained above, and that `int` length is perfect to speed up 99,9% of all cases. So we should not forget about `CharSequence` hastily.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089463475

From duke at openjdk.org  Wed May 14 17:59:58 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 14 May 2025 17:59:58 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <BctFVukNg2CVXVsPVF96howIOf-A8N_G-AIClpaqmgE=.53d54891-c098-4922-81c7-ddd0818c647d@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
 <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>
 <nCFdoAHy2RkNENhaRhdaMDbO3iiAuV-AsirMDJoS0Dc=.0177c4cd-1e71-494f-8956-13edc7eb0551@github.com>
 <BctFVukNg2CVXVsPVF96howIOf-A8N_G-AIClpaqmgE=.53d54891-c098-4922-81c7-ddd0818c647d@github.com>
Message-ID: <apAsxR7rrX0ofU-2q3GVqq_uWkKTD8u4sw7zKeYCT2k=.c4f73ab2-cc66-4f98-b668-de356b788849@github.com>

On Wed, 14 May 2025 17:56:44 GMT, Markus KARG <duke at openjdk.org> wrote:

>> As being a server developer for decades I need to say that I would love to have this not for convenience but for the performance reasons explained above, and that `int` length is perfect to speed up 99,9% of all cases. So we should not forget about `CharSequence` hastily.
>
> BTW, it will not fail with OOME, but it should throw IOE in that case.

BTW, it will *already* throw OOME as-is, *because* it returns a `String` even if the Reader is attached to an infinite source.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089465925

From rgiulietti at openjdk.org  Wed May 14 18:02:55 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 14 May 2025 18:02:55 GMT
Subject: RFR: 8077587: BigInteger Roots [v6]
In-Reply-To: <q09MluNDbj5IA54dR3dZB-BhWUGHK4WYcGXUr7GKcdY=.317f0eb7-df16-4488-8f82-d6b3655ebd96@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <Yx-DylQSsz_gUYUWsEq0VOZyZjkXc-3gxPe2l2HYpT8=.a9c3746b-6383-4450-83bf-9b4b5590178d@github.com>
 <PQSVjWwisaYeX5N1GVyas9W91tGjlgOP7y34TRkpae8=.771ec10c-9571-4a8f-b5bd-fcf0ff6fe77f@github.com>
 <q09MluNDbj5IA54dR3dZB-BhWUGHK4WYcGXUr7GKcdY=.317f0eb7-df16-4488-8f82-d6b3655ebd96@github.com>
Message-ID: <pQffjbocEkk3cAApZQPIImhyOVQmlUAZEctyA8yhx4I=.400242f1-d3d6-41b3-a81d-64bedddb8b3f@github.com>

On Mon, 12 May 2025 19:23:16 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> @fabioromano1 Is [this proof](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf) still relevant?
>
> @rgiulietti No, the proof of the recurrence used is the one by Zimmermann linked in the code.

@fabioromano1 I guess this work will be the basis for a future work on `BigDecimal` _n_-th root?

Otherwise, there needs to be some evidence for useful use cases of _general interest_ to justify adding _n_-th root to `BigInteger`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2881083945

From jlahoda at openjdk.org  Wed May 14 18:04:59 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 14 May 2025 18:04:59 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v13]
In-Reply-To: <QvL1wMiufgj6kq6NBb2ciWTkVQ28MWWIWRmGE47mVHs=.08668b90-b5eb-4272-af23-5c501fccf079@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <QvL1wMiufgj6kq6NBb2ciWTkVQ28MWWIWRmGE47mVHs=.08668b90-b5eb-4272-af23-5c501fccf079@github.com>
Message-ID: <xge1nQel0cyouOx5KB7Jd7zJXhx2Krb83VG3LY-bqJ0=.f2cfce9b-91a0-43ec-b343-7775b9637f60@github.com>

On Tue, 13 May 2025 19:36:11 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - Merge branch 'master' into JDK-8354556
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - additional changes from Archie
>  - removing dead code
>  - integrating code from Archie
>  - fixing bugs, removing dead code
>  - additional documentation changes and bug fixes
>  - documentation and adding alias to lint categories
>  - Merge branch 'master' into JDK-8354556
>  - addressing review comment
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5673:

> 5671:     void checkRequiresIdentity(JCTree tree, Lint lint) {
> 5672:         switch (tree) {
> 5673:             case JCClassDecl classDecl : {

Nit - unless fall-through is needed (it does not seem to be, on the first sight), I would suggest to use `->` instead of `:`, esp. given the cases use blocks anyway.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2089472496

From duke at openjdk.org  Wed May 14 18:07:08 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 14 May 2025 18:07:08 GMT
Subject: RFR: 8077587: BigInteger Roots [v15]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <NepVSdYvhMG501_Fjefgk_ezwqK3FT2rOfIfcKiQ8O4=.1b994e30-acd2-488c-b876-ed7b95d3c4bb@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Use type long for bitLength instead of int"
  
  This reverts commit c8e1b8159206d9fb5532df7ccdf98abcab888f2c.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/c8e1b815..aeef24cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=13-14

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From bpb at openjdk.org  Wed May 14 18:12:09 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 May 2025 18:12:09 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v21]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: <0fljO6e1_nDkzQ1pvry3e3BFquvkZZoSCbiPwmA9Mb0=.8b4a100e-4e8e-486a-8d81-9bd5c37909bd@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: Improve readAllAsString method of Reader returned by Reader.of

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/3cbaede9..04d89963

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=19-20

  Stats: 4 lines in 1 file changed: 3 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 bpb at openjdk.org  Wed May 14 18:12:10 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 May 2025 18:12:10 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
Message-ID: <3Lc4lOREDpDdcpbi31DimAW5jVTbTrT5SGst7I9ghOE=.800191fe-0613-4109-99e9-a8df32773534@github.com>

On Wed, 14 May 2025 17:32:50 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354724: "stream" -> "reader"
>
> src/java.base/share/classes/java/io/Reader.java line 205:
> 
>> 203:             public String readAllAsString() throws IOException {
>> 204:                 ensureOpen();
>> 205:                 String result = cs.toString().substring(next);
> 
> For sake of efficiency can we please *first* limit and copy *last*? If `cs` refers to a huge object and `next` is just few bytes before `length()`, it makes no sense to copy the huge memory block just to return one or two characters finally. ? 
> 
> `result = cs.subSequence(next, cs.length()).toString()`?

Improved in [04d8996](https://github.com/openjdk/jdk/pull/24728/commits/04d899631eb87dc475c7daf08f0ae7af47bcdac1).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089483768

From duke at openjdk.org  Wed May 14 18:12:10 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Wed, 14 May 2025 18:12:10 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <apAsxR7rrX0ofU-2q3GVqq_uWkKTD8u4sw7zKeYCT2k=.c4f73ab2-cc66-4f98-b668-de356b788849@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
 <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>
 <nCFdoAHy2RkNENhaRhdaMDbO3iiAuV-AsirMDJoS0Dc=.0177c4cd-1e71-494f-8956-13edc7eb0551@github.com>
 <BctFVukNg2CVXVsPVF96howIOf-A8N_G-AIClpaqmgE=.53d54891-c098-4922-81c7-ddd0818c647d@github.com>
 <apAsxR7rrX0ofU-2q3GVqq_uWkKTD8u4sw7zKeYCT2k=.c4f73ab2-cc66-4f98-b668-de356b788849@github.com>
Message-ID: <f9my7Gq_OjkXWTBa2L2h1EFIgMpA5PuFf5xndOfcwlM=.e87667ba-d5eb-48aa-be35-05d52ac81212@github.com>

On Wed, 14 May 2025 17:57:36 GMT, Markus KARG <duke at openjdk.org> wrote:

>> BTW, it will not fail with OOME, but it should throw IOE in that case.
>
> BTW, it will *already* throw OOME as-is, *because* it returns a `String` even if the Reader is attached to an infinite source.

Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089484458

From abarashev at openjdk.org  Wed May 14 18:16:13 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 14 May 2025 18:16:13 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>

> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
> 
> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Make the test run on TLSv1.3

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/5c137c14..451e1efd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=02-03

  Stats: 25 lines in 2 files changed: 5 ins; 7 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

PR: https://git.openjdk.org/jdk/pull/25016

From bpb at openjdk.org  Wed May 14 18:16:22 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 May 2025 18:16:22 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@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: Replace getChars in previous commit with subSequence

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/04d89963..1afba6e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=20-21

  Stats: 3 lines in 1 file changed: 0 ins; 2 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  Wed May 14 18:16:58 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 14 May 2025 18:16:58 GMT
Subject: RFR: 8077587: BigInteger Roots [v6]
In-Reply-To: <pQffjbocEkk3cAApZQPIImhyOVQmlUAZEctyA8yhx4I=.400242f1-d3d6-41b3-a81d-64bedddb8b3f@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <Yx-DylQSsz_gUYUWsEq0VOZyZjkXc-3gxPe2l2HYpT8=.a9c3746b-6383-4450-83bf-9b4b5590178d@github.com>
 <PQSVjWwisaYeX5N1GVyas9W91tGjlgOP7y34TRkpae8=.771ec10c-9571-4a8f-b5bd-fcf0ff6fe77f@github.com>
 <q09MluNDbj5IA54dR3dZB-BhWUGHK4WYcGXUr7GKcdY=.317f0eb7-df16-4488-8f82-d6b3655ebd96@github.com>
 <pQffjbocEkk3cAApZQPIImhyOVQmlUAZEctyA8yhx4I=.400242f1-d3d6-41b3-a81d-64bedddb8b3f@github.com>
Message-ID: <t_9i3MckcjJVtUDJkVjnm3uf19_37eAlmJemU8mo5Kc=.c0dd2938-6cbd-487e-bb46-fa90bfabfb3b@github.com>

On Wed, 14 May 2025 17:59:59 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> I guess this work will be the basis for a future work on `BigDecimal` _n_-th root?

@rgiulietti Yes, it is. Some use cases could be primality testing, like AKS, where part of the algorithm detect composite numbers by checking whether an integer is an exact power or not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2881114961

From rriggs at openjdk.org  Wed May 14 18:18:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 14 May 2025 18:18:56 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <f9my7Gq_OjkXWTBa2L2h1EFIgMpA5PuFf5xndOfcwlM=.e87667ba-d5eb-48aa-be35-05d52ac81212@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
 <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>
 <nCFdoAHy2RkNENhaRhdaMDbO3iiAuV-AsirMDJoS0Dc=.0177c4cd-1e71-494f-8956-13edc7eb0551@github.com>
 <BctFVukNg2CVXVsPVF96howIOf-A8N_G-AIClpaqmgE=.53d54891-c098-4922-81c7-ddd0818c647d@github.com>
 <apAsxR7rrX0ofU-2q3GVqq_uWkKTD8u4sw7zKeYCT2k=.c4f73ab2-cc66-4f98-b668-de356b788849@github.com>
 <f9my7Gq_OjkXWTBa2L2h1EFIgMpA5PuFf5xndOfcwlM=.e87667ba-d5eb-48aa-be35-05d52ac81212@github.com>
Message-ID: <Y2P9dJdshrswViDiOGTS14EdODFTMxF7Z1fyDuiQdsA=.d182371a-d1ad-482f-8ff1-d01d06737a32@github.com>

On Wed, 14 May 2025 18:09:26 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> BTW, it will *already* throw OOME as-is, *because* it returns a `String` even if the Reader is attached to an infinite source.
>
> Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence...

The result should be immutable and CharSequence does not provide that. 
The contents should not be modifiable after the method returns.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089494174

From rgiulietti at openjdk.org  Wed May 14 18:29:54 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 14 May 2025 18:29:54 GMT
Subject: RFR: 8077587: BigInteger Roots [v15]
In-Reply-To: <NepVSdYvhMG501_Fjefgk_ezwqK3FT2rOfIfcKiQ8O4=.1b994e30-acd2-488c-b876-ed7b95d3c4bb@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <NepVSdYvhMG501_Fjefgk_ezwqK3FT2rOfIfcKiQ8O4=.1b994e30-acd2-488c-b876-ed7b95d3c4bb@github.com>
Message-ID: <7dIq2RDp9DpQMkuQAGKFJAFt9DFQbhsoCuMyoZVA_eI=.24fb96f4-54d4-4493-9078-75ffebf88cc4@github.com>

On Wed, 14 May 2025 18:07:08 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Use type long for bitLength instead of int"
>   
>   This reverts commit c8e1b8159206d9fb5532df7ccdf98abcab888f2c.

I doubt that the AKS primality test is of any practical relevance, although it's a _great_ theoretical achievement.

So if you plan to add a _n_-th root to `BigDecimal` in a followup PR, then please keep going on this one.
Otherwise, I can't see a strong need for a `BigInteger` _n_-th root in the platform, although I might be wrong.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2881151030

From duke at openjdk.org  Wed May 14 18:34:58 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 14 May 2025 18:34:58 GMT
Subject: RFR: 8077587: BigInteger Roots [v15]
In-Reply-To: <7dIq2RDp9DpQMkuQAGKFJAFt9DFQbhsoCuMyoZVA_eI=.24fb96f4-54d4-4493-9078-75ffebf88cc4@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <NepVSdYvhMG501_Fjefgk_ezwqK3FT2rOfIfcKiQ8O4=.1b994e30-acd2-488c-b876-ed7b95d3c4bb@github.com>
 <7dIq2RDp9DpQMkuQAGKFJAFt9DFQbhsoCuMyoZVA_eI=.24fb96f4-54d4-4493-9078-75ffebf88cc4@github.com>
Message-ID: <EQ9vfsZ8DPoHPItJPx8DYENaylQLEAFnFnAgHMBNEbo=.696a802d-86ae-4046-b44c-5ac42456382b@github.com>

On Wed, 14 May 2025 18:27:28 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> I doubt that the AKS primality test is of any practical relevance, although it's a _great_ theoretical achievement.

Yes, indeed it was just an example, but the exact power detection can be used also as a test apart from the entire AKS algorithm.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2881163762

From rgiulietti at openjdk.org  Wed May 14 18:51:53 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 14 May 2025 18:51:53 GMT
Subject: RFR: 8077587: BigInteger Roots [v15]
In-Reply-To: <NepVSdYvhMG501_Fjefgk_ezwqK3FT2rOfIfcKiQ8O4=.1b994e30-acd2-488c-b876-ed7b95d3c4bb@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <NepVSdYvhMG501_Fjefgk_ezwqK3FT2rOfIfcKiQ8O4=.1b994e30-acd2-488c-b876-ed7b95d3c4bb@github.com>
Message-ID: <V4he0DJLrCSGDVnq5JmOWXh4OcEIwlUUH7R-vLno3VA=.3ba1b7e6-237d-48bf-9d2d-88b0bf830083@github.com>

On Wed, 14 May 2025 18:07:08 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Use type long for bitLength instead of int"
>   
>   This reverts commit c8e1b8159206d9fb5532df7ccdf98abcab888f2c.

The [Rampdown Phase One](https://openjdk.org/projects/jdk/25/) for JDK 25 is about 3 weeks from now.

I think it's a bit too late for API additions to be approved in due time. And even if we could rush this work for 25, it makes little sense to have this in 25 and the future one in 26. IMO, they should be released together. So this and the followup PR for `BigDecimal` will probably be integrated only in 26.

In other words, take your time ;-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2881206033

From duke at openjdk.org  Wed May 14 18:54:52 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 14 May 2025 18:54:52 GMT
Subject: RFR: 8077587: BigInteger Roots [v15]
In-Reply-To: <V4he0DJLrCSGDVnq5JmOWXh4OcEIwlUUH7R-vLno3VA=.3ba1b7e6-237d-48bf-9d2d-88b0bf830083@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <NepVSdYvhMG501_Fjefgk_ezwqK3FT2rOfIfcKiQ8O4=.1b994e30-acd2-488c-b876-ed7b95d3c4bb@github.com>
 <V4he0DJLrCSGDVnq5JmOWXh4OcEIwlUUH7R-vLno3VA=.3ba1b7e6-237d-48bf-9d2d-88b0bf830083@github.com>
Message-ID: <vsjmEu5ruA3NIuq4VbLz2AHkCjUxqaBW_ly7X2JxBEg=.83c91b0e-38d8-4333-879b-e9590aa7dc81@github.com>

On Wed, 14 May 2025 18:48:50 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "Use type long for bitLength instead of int"
>>   
>>   This reverts commit c8e1b8159206d9fb5532df7ccdf98abcab888f2c.
>
> The [Rampdown Phase One](https://openjdk.org/projects/jdk/25/) for JDK 25 is about 3 weeks from now.
> 
> I think it's a bit too late for API additions to be approved in due time. And even if we could rush this work for 25, it makes little sense to have this in 25 and the future one in 26. IMO, they should be released together. So this and the followup PR for `BigDecimal` will probably be integrated only in 26.
> 
> In other words, take your time ;-)

@rgiulietti Anyway, I think the code has reached a stable version, so it is ready for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2881215213

From jlahoda at openjdk.org  Wed May 14 19:18:03 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 14 May 2025 19:18:03 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v13]
In-Reply-To: <QvL1wMiufgj6kq6NBb2ciWTkVQ28MWWIWRmGE47mVHs=.08668b90-b5eb-4272-af23-5c501fccf079@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <QvL1wMiufgj6kq6NBb2ciWTkVQ28MWWIWRmGE47mVHs=.08668b90-b5eb-4272-af23-5c501fccf079@github.com>
Message-ID: <LH5l3EylBKng_NqAM062OyAsMoB62Pc3LMFhNlV1y00=.3ceab033-5328-40bb-8bdd-ac7c6dcb055d@github.com>

On Tue, 13 May 2025 19:36:11 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - Merge branch 'master' into JDK-8354556
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - additional changes from Archie
>  - removing dead code
>  - integrating code from Archie
>  - fixing bugs, removing dead code
>  - additional documentation changes and bug fixes
>  - documentation and adding alias to lint categories
>  - Merge branch 'master' into JDK-8354556
>  - addressing review comment
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29

javac changes look overall good to me. One question and some comments for consideration inline.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 2673:

> 2671:             result = check(tree, capturedRes, KindSelector.VAL, resultInfo);
> 2672:         }
> 2673:         if (env.info.lint.isEnabled(LintCategory.IDENTITY)) {

This is the only place where there's a check whether the lint is enabled before the call to `checkRequiresIdentity`. Is there a reason for that?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5671:

> 5669:     }
> 5670: 
> 5671:     void checkRequiresIdentity(JCTree tree, Lint lint) {

For consideration: as far as I can see, we have a sharp(er) type when we call `checkRequiresIdentity`, but we give up the type, and re-instante it here using the pattern matching switch. I wonder if it would be more elegant (and hopefully not really too much longer) if the `checkRequiresIdentity` method would have multiple overloads, with the sharp(er) types, like `JCClassDecl`/`JCVariableDecl`, etc.

Or is there a reason to given up the sharp(er) type and re-create it using the switch?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5823:

> 5821:                 SymbolMetadata sm = t.tsym.getMetadata();
> 5822:                 if (sm != null && !t.getTypeArguments().isEmpty()) {
> 5823:                     for (Attribute.TypeCompound ta: sm.getTypeAttributes().stream()

The code here, and the code in `checkIfTypeParamsRequiresIdentity` look similar a lot (although they manipulate `List<Type>` and `List<JCExpression>`, of course. I wonder if there's a chance to share the code, at least partially.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24746#pullrequestreview-2841121286
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2089504249
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2089507277
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2089509893

From duke at openjdk.org  Wed May 14 19:40:56 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 14 May 2025 19:40:56 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <Y2P9dJdshrswViDiOGTS14EdODFTMxF7Z1fyDuiQdsA=.d182371a-d1ad-482f-8ff1-d01d06737a32@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
 <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>
 <nCFdoAHy2RkNENhaRhdaMDbO3iiAuV-AsirMDJoS0Dc=.0177c4cd-1e71-494f-8956-13edc7eb0551@github.com>
 <BctFVukNg2CVXVsPVF96howIOf-A8N_G-AIClpaqmgE=.53d54891-c098-4922-81c7-ddd0818c647d@github.com>
 <apAsxR7rrX0ofU-2q3GVqq_uWkKTD8u4sw7zKeYCT2k=.c4f73ab2-cc66-4f98-b668-de356b788849@github.com>
 <f9my7Gq_OjkXWTBa2L2h1EFIgMpA5PuFf5xndOfcwlM=.e87667ba-d5eb-48aa-be35-05d52ac81212@github.com>
 <Y2P9dJdshrswViDiOGTS14EdODFTMxF7Z1fyDuiQdsA=.d182371a-d1ad-482f-8ff1-d01d06737a32@github.com>
Message-ID: <g1GHppLlTaHjuFACIi8dgMvNZfQA81ctofGglGZXAXk=.73477b96-4dd8-45ca-9bae-f3a15d8ce8c1@github.com>

On Wed, 14 May 2025 18:16:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence...
>
> The result should be immutable and CharSequence does not provide that. 
> The contents should not be modifiable after the method returns.

A "pure" `CharSequence` *is* immutable, as it does not have mutation methods. Also, why *should* the result be immutable? If someone wants to return a `StringBuilder` for example (for whatever intent), why shouldn't he allowed to do that? In fact, it would be beneficial to return a `StringBuilder` in some cases, as it is more efficient to modify (*iff* wanted) than a `String`. It should be up to the caller and the provider of the implementation to decide about immutability; this is not the API's discretion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089617093

From acobbs at openjdk.org  Wed May 14 19:43:20 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 14 May 2025 19:43:20 GMT
Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for()
 loops
Message-ID: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>

Please review this small performance tweak `ArrayDeque`.

`ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead.

-------------

Commit messages:
 - Use Arrays.fill() instead of for() loops to null out array elements.

Changes: https://git.openjdk.org/jdk/pull/25237/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25237&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356993
  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25237.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25237/head:pull/25237

PR: https://git.openjdk.org/jdk/pull/25237

From duke at openjdk.org  Wed May 14 19:44:00 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 14 May 2025 19:44:00 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <g1GHppLlTaHjuFACIi8dgMvNZfQA81ctofGglGZXAXk=.73477b96-4dd8-45ca-9bae-f3a15d8ce8c1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
 <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>
 <nCFdoAHy2RkNENhaRhdaMDbO3iiAuV-AsirMDJoS0Dc=.0177c4cd-1e71-494f-8956-13edc7eb0551@github.com>
 <BctFVukNg2CVXVsPVF96howIOf-A8N_G-AIClpaqmgE=.53d54891-c098-4922-81c7-ddd0818c647d@github.com>
 <apAsxR7rrX0ofU-2q3GVqq_uWkKTD8u4sw7zKeYCT2k=.c4f73ab2-cc66-4f98-b668-de356b788849@github.com>
 <f9my7Gq_OjkXWTBa2L2h1EFIgMpA5PuFf5xndOfcwlM=.e87667ba-d5eb-48aa-be35-05d52ac81212@github.com>
 <Y2P9dJdshrswViDiOGTS14EdODFTMxF7Z1fyDuiQdsA=.d182371a-d1ad-482f-8ff1-d01d06737a32@github.com>
 <g1GHppLlTaHjuFACIi8dgMvNZfQA81ctofGglGZXAXk=.73477b96-4dd8-45ca-9bae-f3a15d8ce8c1@github.com>
Message-ID: <cnVCW6f3cE8qRMTn_8PMfPX8NPB8WhEcTJbjp_Zz3MY=.a4fe61f7-1a2a-4528-91a9-fde9cae8acfa@github.com>

On Wed, 14 May 2025 19:37:57 GMT, Markus KARG <duke at openjdk.org> wrote:

>> The result should be immutable and CharSequence does not provide that. 
>> The contents should not be modifiable after the method returns.
>
> A "pure" `CharSequence` *is* immutable, as it does not have mutation methods. Also, why *should* the result be immutable? If someone wants to return a `StringBuilder` for example (for whatever intent), why shouldn't he allowed to do that? In fact, it would be beneficial to return a `StringBuilder` in some cases, as it is more efficient to modify (*iff* wanted) than a `String`. It should be up to the caller and the provider of the implementation to decide about immutability; this is not the API's discretion.

> Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence...

The most simple example is a file server. Incidential fact, just today I wrote a function that simply passes JSON documents received in a REST call forward to another server using another REST call (without parsing it). The document is not changed. It is *inefficient* to force it into a `String` temporarily. This is not untypical, such use cases exists often in server computing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089622286

From duke at openjdk.org  Wed May 14 19:47:56 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 14 May 2025 19:47:56 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
Message-ID: <x1nMqw3J0aQoPyMt3WZ8YPnPFEwAebt_cnGtQYSXNSs=.6ae13f2a-5eeb-410d-9971-958526a8f16e@github.com>

On Wed, 14 May 2025 18:16:22 GMT, Brian Burkhalter <bpb at openjdk.org> 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: Replace getChars in previous commit with subSequence

src/java.base/share/classes/java/io/Reader.java line 206:

> 204:                 ensureOpen();
> 205:                 int len = cs.length();
> 206:                 String result = cs.subSequence(next, len).toString();

Are you sure that `subSequence` is more efficient that `getChars`? Otherwise I do not see why replacing it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089627037

From liach at openjdk.org  Wed May 14 20:03:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 May 2025 20:03:55 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <x1nMqw3J0aQoPyMt3WZ8YPnPFEwAebt_cnGtQYSXNSs=.6ae13f2a-5eeb-410d-9971-958526a8f16e@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <x1nMqw3J0aQoPyMt3WZ8YPnPFEwAebt_cnGtQYSXNSs=.6ae13f2a-5eeb-410d-9971-958526a8f16e@github.com>
Message-ID: <BErvDbjWrXY7YGuIyQwR22cHeUP4knxU8MU4tw6AMN4=.c6b174ea-abdb-4b11-b6f9-0d97a03dc6ff@github.com>

On Wed, 14 May 2025 19:44:56 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354724: Replace getChars in previous commit with subSequence
>
> src/java.base/share/classes/java/io/Reader.java line 206:
> 
>> 204:                 ensureOpen();
>> 205:                 int len = cs.length();
>> 206:                 String result = cs.subSequence(next, len).toString();
> 
> Are you sure that `subSequence` is more efficient that `getChars`? Otherwise I do not see why replacing it.

I think this may be a good way to reduce redundant allocation if the CharSequence's subsequence is a simple view (frequently the case for user ones) or a String (for StringBuilder, String)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089650320

From amaembo at gmail.com  Wed May 14 20:15:00 2025
From: amaembo at gmail.com (Tagir Valeev)
Date: Wed, 14 May 2025 22:15:00 +0200
Subject: Finding max or min of exactly two objects
In-Reply-To: <9d4e48a1-a079-4539-a0b9-c18a8afddc8b@oracle.com>
References: <CAE+3fja-oo=Yxxs9gQ9cTnCStYOBtf1oey3Dn6F2dNjbfievCg@mail.gmail.com>
 <55572e2c-a66c-4b76-a65d-c8fdf544be2f@oracle.com>
 <CAE+3fjbF2WswJvYB=qz0JkYkoskaViaPDbHTzJrvpyX3tC6APQ@mail.gmail.com>
 <9d4e48a1-a079-4539-a0b9-c18a8afddc8b@oracle.com>
Message-ID: <CAE+3fjbuqm77Z2r8JQDWKhLFKjfVp-dP2msmha3TFb51pFbhyw@mail.gmail.com>

Hello!

On Tue, May 13, 2025 at 5:53?PM Brian Goetz <brian.goetz at oracle.com> wrote:
> Let's separate these.  I think the first two have a good claim to be in
> Comparator; I think the latter two probably live better in Comparable,
> which feels like a separate conversation (and maybe less important?)
> (And also, there's some overlap with some yet-uncollapsed stuff going on
> in Valhalla that I'd like to steer clear of.)

Agreed, let's concentrate on default methods first and see how it
goes. I've created
https://bugs.openjdk.org/browse/JDK-8356995
I've also found an older (declined) feature request
https://bugs.openjdk.org/browse/JDK-4254492

With best regards,
Tagir Valeev

From bpb at openjdk.org  Wed May 14 20:16:56 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 May 2025 20:16:56 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <BErvDbjWrXY7YGuIyQwR22cHeUP4knxU8MU4tw6AMN4=.c6b174ea-abdb-4b11-b6f9-0d97a03dc6ff@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <x1nMqw3J0aQoPyMt3WZ8YPnPFEwAebt_cnGtQYSXNSs=.6ae13f2a-5eeb-410d-9971-958526a8f16e@github.com>
 <BErvDbjWrXY7YGuIyQwR22cHeUP4knxU8MU4tw6AMN4=.c6b174ea-abdb-4b11-b6f9-0d97a03dc6ff@github.com>
Message-ID: <Swr1GEuPbIhL4A273oZfYFmAlwYw3lPF2vaWhTzt4aE=.401b5bda-92db-4361-a581-579756ecf562@github.com>

On Wed, 14 May 2025 20:00:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 206:
>> 
>>> 204:                 ensureOpen();
>>> 205:                 int len = cs.length();
>>> 206:                 String result = cs.subSequence(next, len).toString();
>> 
>> Are you sure that `subSequence` is more efficient that `getChars`? Otherwise I do not see why replacing it.
>
> I think this may be a good way to reduce redundant allocation if the CharSequence's subsequence is a simple view (frequently the case for user ones) or a String (for StringBuilder, String)

I have no idea whether `subSequence` is more performant than `getChars` but it seems cleaner. In any case, at this point we are concerned primarily with the APIs getting into JDK 25. We can improve performance after that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089672134

From rriggs at openjdk.org  Wed May 14 20:24:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 14 May 2025 20:24:55 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <cnVCW6f3cE8qRMTn_8PMfPX8NPB8WhEcTJbjp_Zz3MY=.a4fe61f7-1a2a-4528-91a9-fde9cae8acfa@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
 <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>
 <nCFdoAHy2RkNENhaRhdaMDbO3iiAuV-AsirMDJoS0Dc=.0177c4cd-1e71-494f-8956-13edc7eb0551@github.com>
 <BctFVukNg2CVXVsPVF96howIOf-A8N_G-AIClpaqmgE=.53d54891-c098-4922-81c7-ddd0818c647d@github.com>
 <apAsxR7rrX0ofU-2q3GVqq_uWkKTD8u4sw7zKeYCT2k=.c4f73ab2-cc66-4f98-b668-de356b788849@github.com>
 <f9my7Gq_OjkXWTBa2L2h1EFIgMpA5PuFf5xndOfcwlM=.e87667ba-d5eb-48aa-be35-05d52ac81212@github.com>
 <Y2P9dJdshrswViDiOGTS14EdODFTMxF7Z1fyDuiQdsA=.d182371a-d1ad-482f-8ff1-d01d06737a32@github.com>
 <g1GHppLlTaHjuFACIi8dgMvNZfQA81ctofGglGZXAXk=.73477b96-4dd8-45ca-9bae-f3a15d8ce8c1@github.com>
 <cnVCW6f3cE8qRMTn_8PMfPX8NPB8WhEcTJb
 jp_Zz3MY=.a4fe61f7-1a2a-4528-91a9-fde9cae8acfa@github.com>
Message-ID: <jOzAzf7qiUGaR4AcVxkVruHyXr7-SLNU2pRV_z8iojk=.0c07b2ec-c8e7-4170-84e8-d1baed0afde0@github.com>

On Wed, 14 May 2025 19:41:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> A "pure" `CharSequence` *is* immutable, as it does not have mutation methods. Also, why *should* the result be immutable? If someone wants to return a `StringBuilder` for example (for whatever intent), why shouldn't he allowed to do that? In fact, it would be beneficial to return a `StringBuilder` in some cases, as it is more efficient to modify (*iff* wanted) than a `String`. It should be up to the caller and the provider of the implementation to decide about immutability; this is not the API's discretion.
>
>> Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence...
> 
> The most simple example is a file server. Incidential fact, just today I wrote a function that simply passes JSON documents received in a REST call forward to another server using another REST call (without parsing it). The document is not changed. It is *inefficient* to force it into a `String` temporarily. This is not untypical, such use cases exists often in server computing.

There's nothing in the CharSequence interface that requires or indicates that the implementation is or is not immutable. Interfaces only have loosely defined contracts, only the signature of the methods, the caller can not hold any more expectations about the semantics of the implementation.
Immutable objects are among the best tools we have for making reliable software. 
The caller does not have to have a deep knowledge of the implementation to get predictable results.
For most OpenJDK public APIs, the objective is to have well defined semantics with no implementation surprises.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089682813

From duke at openjdk.org  Wed May 14 20:34:58 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 14 May 2025 20:34:58 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <Swr1GEuPbIhL4A273oZfYFmAlwYw3lPF2vaWhTzt4aE=.401b5bda-92db-4361-a581-579756ecf562@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <x1nMqw3J0aQoPyMt3WZ8YPnPFEwAebt_cnGtQYSXNSs=.6ae13f2a-5eeb-410d-9971-958526a8f16e@github.com>
 <BErvDbjWrXY7YGuIyQwR22cHeUP4knxU8MU4tw6AMN4=.c6b174ea-abdb-4b11-b6f9-0d97a03dc6ff@github.com>
 <Swr1GEuPbIhL4A273oZfYFmAlwYw3lPF2vaWhTzt4aE=.401b5bda-92db-4361-a581-579756ecf562@github.com>
Message-ID: <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com>

On Wed, 14 May 2025 20:14:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I think this may be a good way to reduce redundant allocation if the CharSequence's subsequence is a simple view (frequently the case for user ones) or a String (for StringBuilder, String)
>
> I have no idea whether `subSequence` is more performant than `getChars` but it seems cleaner. In any case, at this point we are concerned primarily with the APIs getting into JDK 25. We can improve performance after that.

Actually I am working on exact these optimizations right now and do not like the idea that I have to file another JBS and PR just for a single code line. As `subSequence` typically *does* a copy (to not hold the original full text in-memory for the lifetime of a possibly single-character sub sequence), unless otherwise proven, `getChars` will always be faster. Having said that, I need to say, that I do not second what Chen said. In reality I have never seen "simple views", in particular not "frequently".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089697023

From duke at openjdk.org  Wed May 14 20:39:55 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 14 May 2025 20:39:55 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <x1nMqw3J0aQoPyMt3WZ8YPnPFEwAebt_cnGtQYSXNSs=.6ae13f2a-5eeb-410d-9971-958526a8f16e@github.com>
 <BErvDbjWrXY7YGuIyQwR22cHeUP4knxU8MU4tw6AMN4=.c6b174ea-abdb-4b11-b6f9-0d97a03dc6ff@github.com>
 <Swr1GEuPbIhL4A273oZfYFmAlwYw3lPF2vaWhTzt4aE=.401b5bda-92db-4361-a581-579756ecf562@github.com>
 <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com>
Message-ID: <RbqVx9l3PqI3nGa04lI8LZc8q4RyriZK8KP0-sqL098=.257abdaf-af46-4148-b925-42eebb1a3666@github.com>

On Wed, 14 May 2025 20:32:38 GMT, Markus KARG <duke at openjdk.org> wrote:

>> I have no idea whether `subSequence` is more performant than `getChars` but it seems cleaner. In any case, at this point we are concerned primarily with the APIs getting into JDK 25. We can improve performance after that.
>
> Actually I am working on exact these optimizations right now and do not like the idea that I have to file another JBS and PR just for a single code line. As `subSequence` typically *does* a copy (to not hold the original full text in-memory for the lifetime of a possibly single-character sub sequence), unless otherwise proven, `getChars` will always be faster. Having said that, I need to say, that I do not second what Chen said. In reality I have never seen "simple views", in particular not "frequently".

BTW, paraphrasing Stuart here: "We want to reduce self-calls". `subSequence` is a self-call, *as we do not know* how it behaves in the actual implementation. For `getChars` we can be sure that it has no overridable side effects.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089706589

From duke at openjdk.org  Wed May 14 20:54:57 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 14 May 2025 20:54:57 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <jOzAzf7qiUGaR4AcVxkVruHyXr7-SLNU2pRV_z8iojk=.0c07b2ec-c8e7-4170-84e8-d1baed0afde0@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
 <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>
 <nCFdoAHy2RkNENhaRhdaMDbO3iiAuV-AsirMDJoS0Dc=.0177c4cd-1e71-494f-8956-13edc7eb0551@github.com>
 <BctFVukNg2CVXVsPVF96howIOf-A8N_G-AIClpaqmgE=.53d54891-c098-4922-81c7-ddd0818c647d@github.com>
 <apAsxR7rrX0ofU-2q3GVqq_uWkKTD8u4sw7zKeYCT2k=.c4f73ab2-cc66-4f98-b668-de356b788849@github.com>
 <f9my7Gq_OjkXWTBa2L2h1EFIgMpA5PuFf5xndOfcwlM=.e87667ba-d5eb-48aa-be35-05d52ac81212@github.com>
 <Y2P9dJdshrswViDiOGTS14EdODFTMxF7Z1fyDuiQdsA=.d182371a-d1ad-482f-8ff1-d01d06737a32@github.com>
 <g1GHppLlTaHjuFACIi8dgMvNZfQA81ctofGglGZXAXk=.73477b96-4dd8-45ca-9bae-f3a15d8ce8c1@github.com>
 <cnVCW6f3cE8qRMTn_8PMfPX8NPB8WhEcTJb
 jp_Zz3MY=.a4fe61f7-1a2a-4528-91a9-fde9cae8acfa@github.com>
 <jOzAzf7qiUGaR4AcVxkVruHyXr7-SLNU2pRV_z8iojk=.0c07b2ec-c8e7-4170-84e8-d1baed0afde0@github.com>
Message-ID: <F6Kjz5iF9Y5R0V8LuRCuX_JtmI6Ohtzksy96kGzDUY8=.a461b9e5-02dd-4226-aced-cf4f910b01b0@github.com>

On Wed, 14 May 2025 20:22:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence...
>> 
>> The most simple example is a file server. Incidential fact, just today I wrote a function that simply passes JSON documents received in a REST call forward to another server using another REST call (without parsing it). The document is not changed. It is *inefficient* to force it into a `String` temporarily. This is not untypical, such use cases exists often in server computing.
>
> There's nothing in the CharSequence interface that requires or indicates that the implementation is or is not immutable. Interfaces only have loosely defined contracts, only the signature of the methods, the caller can not hold any more expectations about the semantics of the implementation.
> Immutable objects are among the best tools we have for making reliable software. 
> The caller does not have to have a deep knowledge of the implementation to get predictable results.
> For most OpenJDK public APIs, the objective is to have well defined semantics with no implementation surprises.

Granted in general, but again, it is not the job of *this particular API* to forbid mutation *iff* the caller and / or producer of the object see a good reason for that. This completely overdesigns the target of *this* API. Callers are no dummies, they can read JavaDocs, and they can `.toString()` on their own *iff* needed. Actually, in 30 years I never heard a Java Programmer say "oops, I did not expect `CharSequence` to mutate". With that attitude we could simply deprecate `CharSequence` for removal...!

BTW, how will you mutate a `CharSequence` if you don't know its actual implementation? Try-and-error? ? Or with "immutable" do you mean *constant* objects (i. e. *the producer* will not modify it after creation)?

It is a *good* thing not to know what you have in your hands, as you *do not start* making assumptions (like "it is immutable"). I am fond of getting *away* from those restricted semantics, towards a cleaner "do not assume, do not trust" policy.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089733821

From rriggs at openjdk.org  Wed May 14 21:01:05 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 14 May 2025 21:01:05 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <RbqVx9l3PqI3nGa04lI8LZc8q4RyriZK8KP0-sqL098=.257abdaf-af46-4148-b925-42eebb1a3666@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <x1nMqw3J0aQoPyMt3WZ8YPnPFEwAebt_cnGtQYSXNSs=.6ae13f2a-5eeb-410d-9971-958526a8f16e@github.com>
 <BErvDbjWrXY7YGuIyQwR22cHeUP4knxU8MU4tw6AMN4=.c6b174ea-abdb-4b11-b6f9-0d97a03dc6ff@github.com>
 <Swr1GEuPbIhL4A273oZfYFmAlwYw3lPF2vaWhTzt4aE=.401b5bda-92db-4361-a581-579756ecf562@github.com>
 <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com>
 <RbqVx9l3PqI3nGa04lI8LZc8q4RyriZK8KP0-sqL098=.257abdaf-af46-4148-b925-42eebb1a3666@github.com>
Message-ID: <6pcsLU3w7BQmpUbZ-p53iZsOK3kVckilpiHzyOu2VK8=.10d95ba6-1259-4e90-a994-407f9c247a67@github.com>

On Wed, 14 May 2025 20:36:47 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Actually I am working on exact these optimizations right now and do not like the idea that I have to file another JBS and PR just for a single code line. As `subSequence` typically *does* a copy (to not hold the original full text in-memory for the lifetime of a possibly single-character sub sequence), unless otherwise proven, `getChars` will always be faster. Having said that, I need to say, that I do not second what Chen said. In reality I have never seen "simple views", in particular not "frequently".
>
> BTW, paraphrasing Stuart here: "We want to reduce self-calls". `subSequence` is a self-call, *as we do not know* how it behaves in the actual implementation. For `getChars` we can be sure that it has no overridable side effects.

Both `subSequence` and `getChars` are implemented by the CharSequence.
They have the same level of trustworthiness about their implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089744639

From duke at openjdk.org  Wed May 14 21:05:06 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 14 May 2025 21:05:06 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <6pcsLU3w7BQmpUbZ-p53iZsOK3kVckilpiHzyOu2VK8=.10d95ba6-1259-4e90-a994-407f9c247a67@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <x1nMqw3J0aQoPyMt3WZ8YPnPFEwAebt_cnGtQYSXNSs=.6ae13f2a-5eeb-410d-9971-958526a8f16e@github.com>
 <BErvDbjWrXY7YGuIyQwR22cHeUP4knxU8MU4tw6AMN4=.c6b174ea-abdb-4b11-b6f9-0d97a03dc6ff@github.com>
 <Swr1GEuPbIhL4A273oZfYFmAlwYw3lPF2vaWhTzt4aE=.401b5bda-92db-4361-a581-579756ecf562@github.com>
 <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com>
 <RbqVx9l3PqI3nGa04lI8LZc8q4RyriZK8KP0-sqL098=.257abdaf-af46-4148-b925-42eebb1a3666@github.com>
 <6pcsLU3w7BQmpUbZ-p53iZsOK3kVckilpiHzyOu2VK8=.10d95ba6-1259-4e90-a994-407f9c247a67@github.com>
Message-ID: <-alnojXx7gvsHuZyAugz_zk_1bf_QT0PfSZMdvP_Xt8=.0791cdf3-f466-4dd0-b672-5a0f619d14d7@github.com>

On Wed, 14 May 2025 20:58:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> BTW, paraphrasing Stuart here: "We want to reduce self-calls". `subSequence` is a self-call, *as we do not know* how it behaves in the actual implementation. For `getChars` we can be sure that it has no overridable side effects.
>
> Both `subSequence` and `getChars` are implemented by the CharSequence.
> They have the same level of trustworthiness about their implementation.

I meant that the implementation of `subSequence` *might or might not* perform copy (so we need to tell the javaDoc reader), while `getChar` *clearly* performs a copy as part of it design. So `subSequence` can be surprising as this discussion proofs, while `getChars` will not. That was Stuart's point with `read`, and that was your point with `CharSequence`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089749078

From peter.levart at gmail.com  Wed May 14 21:07:16 2025
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 14 May 2025 23:07:16 +0200
Subject: Finding max or min of exactly two objects
In-Reply-To: <CAE+3fjbuqm77Z2r8JQDWKhLFKjfVp-dP2msmha3TFb51pFbhyw@mail.gmail.com>
References: <CAE+3fja-oo=Yxxs9gQ9cTnCStYOBtf1oey3Dn6F2dNjbfievCg@mail.gmail.com>
 <55572e2c-a66c-4b76-a65d-c8fdf544be2f@oracle.com>
 <CAE+3fjbF2WswJvYB=qz0JkYkoskaViaPDbHTzJrvpyX3tC6APQ@mail.gmail.com>
 <9d4e48a1-a079-4539-a0b9-c18a8afddc8b@oracle.com>
 <CAE+3fjbuqm77Z2r8JQDWKhLFKjfVp-dP2msmha3TFb51pFbhyw@mail.gmail.com>
Message-ID: <61697f55-1e38-487a-aa75-395acc36f6bd@gmail.com>

Hi,

I don't know if anyone still uses this, but some ideas are worth 
considering:

https://github.com/google/guava/blob/master/guava/src/com/google/common/collect/Ordering.java

This is a Comparator implementation that also defines min and max. As 
generic methods.


So if I have:

Comparator<CharSequence> cmp = ...

var greatest = cmp.max("foo", "bar");

...what type will greatest be?

Regards, Peter

On 5/14/25 10:15 PM, Tagir Valeev wrote:

> Hello!
>
> On Tue, May 13, 2025 at 5:53?PM Brian Goetz <brian.goetz at oracle.com> wrote:
>> Let's separate these.  I think the first two have a good claim to be in
>> Comparator; I think the latter two probably live better in Comparable,
>> which feels like a separate conversation (and maybe less important?)
>> (And also, there's some overlap with some yet-uncollapsed stuff going on
>> in Valhalla that I'd like to steer clear of.)
> Agreed, let's concentrate on default methods first and see how it
> goes. I've created
> https://bugs.openjdk.org/browse/JDK-8356995
> I've also found an older (declined) feature request
> https://bugs.openjdk.org/browse/JDK-4254492
>
> With best regards,
> Tagir Valeev

From iklam at openjdk.org  Wed May 14 21:38:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 21:38:01 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v12]
In-Reply-To: <JoyEhrXuHQMMjc5wSmogN0045YycfgZbi1YkpP3Ef8g=.ba201c18-7077-451a-b4b9-adafa9278b7f@github.com>
References: <AdBmCAbqhjQEP05JBlXhp21hKuxn7SAb7h0Y3Wvollk=.21c0e6fe-097e-41e4-afa3-45b108112a28@github.com>
 <JoyEhrXuHQMMjc5wSmogN0045YycfgZbi1YkpP3Ef8g=.ba201c18-7077-451a-b4b9-adafa9278b7f@github.com>
Message-ID: <13z4Kl2z8Qz0d0NKNyx7gqZiQmfzBFcM6duqVyy2v5A=.877f712a-ad71-4d85-92f6-28c678425d22@github.com>

On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin <tpushkin at openjdk.org> 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:
> 
>   Make supertype obstruction check easier to understand

LGTM.

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24223#pullrequestreview-2841568752

From iklam at openjdk.org  Wed May 14 21:38:02 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 May 2025 21:38:02 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v12]
In-Reply-To: <L4npkz6cTV-OUUj1e25EnSPHrjgAPyo3mDSg00QjAO4=.7d008865-5ab6-4d8c-bb8f-8e7613f4e12a@github.com>
References: <AdBmCAbqhjQEP05JBlXhp21hKuxn7SAb7h0Y3Wvollk=.21c0e6fe-097e-41e4-afa3-45b108112a28@github.com>
 <JoyEhrXuHQMMjc5wSmogN0045YycfgZbi1YkpP3Ef8g=.ba201c18-7077-451a-b4b9-adafa9278b7f@github.com>
 <L4npkz6cTV-OUUj1e25EnSPHrjgAPyo3mDSg00QjAO4=.7d008865-5ab6-4d8c-bb8f-8e7613f4e12a@github.com>
Message-ID: <fMabtbxSUMvGpY3AfGH9-B1ODe5bQqRThoVQRF8Jsdk=.a888152a-b84b-4a66-b938-828962ba1413@github.com>

On Wed, 14 May 2025 10:12:11 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> Sorry, had to pause working on this for some time because of other stuff.
> 
> I believe I have addressed all the existing comments now.

Thanks for making the changes.  Once this PR has 2 reviews and is final, I will run some tests in our test pipeline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2881638567

From smarks at openjdk.org  Wed May 14 22:21:54 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 14 May 2025 22:21:54 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <-alnojXx7gvsHuZyAugz_zk_1bf_QT0PfSZMdvP_Xt8=.0791cdf3-f466-4dd0-b672-5a0f619d14d7@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <x1nMqw3J0aQoPyMt3WZ8YPnPFEwAebt_cnGtQYSXNSs=.6ae13f2a-5eeb-410d-9971-958526a8f16e@github.com>
 <BErvDbjWrXY7YGuIyQwR22cHeUP4knxU8MU4tw6AMN4=.c6b174ea-abdb-4b11-b6f9-0d97a03dc6ff@github.com>
 <Swr1GEuPbIhL4A273oZfYFmAlwYw3lPF2vaWhTzt4aE=.401b5bda-92db-4361-a581-579756ecf562@github.com>
 <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com>
 <RbqVx9l3PqI3nGa04lI8LZc8q4RyriZK8KP0-sqL098=.257abdaf-af46-4148-b925-42eebb1a3666@github.com>
 <6pcsLU3w7BQmpUbZ-p53iZsOK3kVckilpiHzyOu2VK8=.10d95ba6-1259-4e90-a994-407f9c247a67@github.com>
 <-alnojXx7gvsHuZyAugz_zk_1bf_QT0PfSZMdvP_Xt8=.0791cdf3-f466-4dd0-b672-5a0f619d14d7@github.com>
Message-ID: <dJ6QbcWd3g7UZrHLzDKDZpsg1JGl5przqySy6chS8xM=.8f09904b-0f74-42d9-9562-47fcb73f5dc7@github.com>

On Wed, 14 May 2025 21:02:20 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Both `subSequence` and `getChars` are implemented by the CharSequence.
>> They have the same level of trustworthiness about their implementation.
>
> I meant that the implementation of `subSequence` *might or might not* perform copy (so we need to tell the javaDoc reader), while `getChar` *clearly* performs a copy as part of it design. So `subSequence` can be surprising as this discussion proofs, while `getChars` will not. That was Stuart's point with `read`, and that was your point with `CharSequence`.

@mkarg Please don't invoke my name to try to buttress your arguments. The calls the Reader.of() instance makes on its backing CharSequence is a different kind of issue from what promises or guarantees the concrete methods of the Reader class makes to its subclasses.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089846252

From mseledtsov at openjdk.org  Wed May 14 22:25:52 2025
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Wed, 14 May 2025 22:25:52 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v3]
In-Reply-To: <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
Message-ID: <X5GZQz6cnSG4peWbvJD2SmRERl3-FH7u-7nNZCQ8pNU=.fc95cd20-5565-4242-a8fa-38fdbf382af0@github.com>

On Fri, 2 May 2025 10:00:07 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor container runtime version code

Overall change looks good to me.
Looks like this method is not in use anymore (as also noted by [sercher]), consider deleting it:
private static String getDockerVersionStr() {

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2881725481

From smarks at openjdk.org  Wed May 14 22:34:53 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 14 May 2025 22:34:53 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <L6ovQHi9B7L8OYP83pDLW1MzNOXhZYABPEQpfwUOyf4=.97b4752b-13f5-40fc-a8d9-447380be2fbb@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com>
 <3dImE74ioqCoWHkOx_sQIbUIAFM5Y9WX920wkyMkZ9c=.af17f449-9ecf-4d0f-84ef-8d9068af0ab3@github.com>
 <4T4npViSWy-EFy6758EMIx2cRHmYONULq2v1Dhjb4JU=.60d1efd4-c310-4176-9107-bb4e3c7030e0@github.com>
 <3kJUC9n4dQcRHW1etWe0x3k_yP_B4thpst8cG9JrMZQ=.672d3b67-7237-48e5-98fa-057852c23ca4@github.com>
 <a6uoLPrncSxGv6y3P60m2o3ZT0POmwRr7z8nTjD_Q68=.d4ac9503-b29e-4aec-a75d-f0c031166721@github.com>
 <L6ovQHi9B7L8OYP83pDLW1MzNOXhZYABPEQpfwUOyf4=.97b4752b-13f5-40fc-a8d9-447380be2fbb@github.com>
Message-ID: <i7pO5k_0Njw2C9CrXbas_r1BOvQCBE0hb_h2D5aPi-k=.e9a8c89e-be40-44d6-845d-777be038d193@github.com>

On Wed, 14 May 2025 17:53:48 GMT, Markus KARG <duke at openjdk.org> wrote:

>> The code should use the three-arg read() call in order to limit self-calls, in order to avoid the fragile base class problem. At some point we might want to add implSpec tags to specify this. See my previous comments relate to this topic: 
>> 
>> https://github.com/openjdk/jdk/pull/24728#issuecomment-2848332415
>
> I know that comment already, but IMHO we can simply use `@implSpec` to unambiguously make clear that this method invokes `read(char[])` to allow optimized implementations, and it *might* in turn invoke `read(char[],int,int)`, but this is *not guaranteed*. A class is only fragile as long as we do not *document* what it will do.

I doubt a subclass could make an optimization to the one-arg read() that it couldn't also make with the three-arg read(). Since the subclass is required to implement the three-arg read(), there's no benefit in specifying that this method call the one-arg read() instead of the three-arg read().

However, requiring this implementation to call the one-arg read() method is detrimental, because it precludes future optimizations that we might want to make to this method, which might want to use the more flexible three-arg read() method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089856314

From mseledtsov at openjdk.org  Wed May 14 22:44:51 2025
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Wed, 14 May 2025 22:44:51 GMT
Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with
 exitValue = 1 [v2]
In-Reply-To: <BirOeZpJHWOKWkrxpjqmg383z27oi9s7YG6n4xIWr1U=.1a3420ac-cc51-4330-8b51-bb57515693e6@github.com>
References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
 <BirOeZpJHWOKWkrxpjqmg383z27oi9s7YG6n4xIWr1U=.1a3420ac-cc51-4330-8b51-bb57515693e6@github.com>
Message-ID: <uztJg3CEB4-0fGIpOWnNrhxPbaN70HwKdzf91__Gh50=.03f3aa6f-9e6f-454b-bb53-498566fab560@github.com>

On Tue, 13 May 2025 04:06:34 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TestDockerMemoryMetricsSubgroup.java
>   
>   remove extra space

Change looks good to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24930#issuecomment-2881756560

From ccheung at openjdk.org  Wed May 14 23:29:58 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 14 May 2025 23:29:58 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v12]
In-Reply-To: <JoyEhrXuHQMMjc5wSmogN0045YycfgZbi1YkpP3Ef8g=.ba201c18-7077-451a-b4b9-adafa9278b7f@github.com>
References: <AdBmCAbqhjQEP05JBlXhp21hKuxn7SAb7h0Y3Wvollk=.21c0e6fe-097e-41e4-afa3-45b108112a28@github.com>
 <JoyEhrXuHQMMjc5wSmogN0045YycfgZbi1YkpP3Ef8g=.ba201c18-7077-451a-b4b9-adafa9278b7f@github.com>
Message-ID: <HBuJ3pRxdpm54mt5kheLug_AD0y7e8Vszi3VjQBLI5I=.c2a5e6dc-ffb7-4987-ac05-d045264c6459@github.com>

On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin <tpushkin at openjdk.org> 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:
> 
>   Make supertype obstruction check easier to understand

Looks good. Thanks!

-------------

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24223#pullrequestreview-2841729544

From mseledtsov at openjdk.org  Wed May 14 23:49:50 2025
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Wed, 14 May 2025 23:49:50 GMT
Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with
 exitValue = 1 [v2]
In-Reply-To: <BirOeZpJHWOKWkrxpjqmg383z27oi9s7YG6n4xIWr1U=.1a3420ac-cc51-4330-8b51-bb57515693e6@github.com>
References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
 <BirOeZpJHWOKWkrxpjqmg383z27oi9s7YG6n4xIWr1U=.1a3420ac-cc51-4330-8b51-bb57515693e6@github.com>
Message-ID: <TFX75qyR9yjawIUggVopRB-Bt0Y86x58bSY1Djp280M=.50962f9d-78a9-44b8-98c7-a86804209dc3@github.com>

On Tue, 13 May 2025 04:06:34 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TestDockerMemoryMetricsSubgroup.java
>   
>   remove extra space

Marked as reviewed by mseledtsov (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24930#pullrequestreview-2841749929

From bchristi at openjdk.org  Wed May 14 23:56:05 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 14 May 2025 23:56:05 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
Message-ID: <iGlPHf8dSXOGgy-Qby4L6bwR_ZfAMVEETLqpnPVN3NQ=.64a2d77a-fb3b-4ee9-89f3-298610dba273@github.com>

Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with Cleaner.

(The [first PR](https://github.com/openjdk/jdk/pull/8311) for this fix started some substantial discussions, leading to, among other things, the [8314480](https://bugs.openjdk.org/browse/JDK-8314480) `java.lang.ref` memory ordering spec update.)

In standard fashion, pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved into a _Context_ object. From there, the change is fairly mechanical.

Details of note:

1. Some operations need to change the state values (the `update()` method is probably the most interesting). Use of `reachabilityFence()` ensures memory visibility on the Cleaner thread (per the aforementioned spec update).
2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's state.

The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. It confirms that the use of Cleaner does not keep an `LdapSearchEnumeration` object reachable. The other `AbstractLdapNamingEnumeration` subclasses (`LdapNamingEnumeration` and `LdapBindingEnumeration`) can be expected to behave the same.

Thanks.

-------------

Commit messages:
 - small comment update
 - simplify test
 - update test to use WhiteBox, and use volatile read for enumCount
 - improve test to give cleaning action a chance to run
 - remove unneeded fullFence()s, fix copyright years, update some comments
 - more hasMoreReferrals() merge error fixing
 - fix hasMoreReferrals() merge error
 - update EnumCtx comment
 - remove fullFence() calls, fix reachabilityFence() arguments, remove some unneeded comments
 - simplify some comments
 - ... and 19 more: https://git.openjdk.org/jdk/compare/b6b5ac1e...e36cf5db

Changes: https://git.openjdk.org/jdk/pull/25242/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25242&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8283660
  Stats: 718 lines in 7 files changed: 391 ins; 90 del; 237 mod
  Patch: https://git.openjdk.org/jdk/pull/25242.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25242/head:pull/25242

PR: https://git.openjdk.org/jdk/pull/25242

From ccheung at openjdk.org  Thu May 15 00:16:32 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 15 May 2025 00:16:32 GMT
Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking [v2]
In-Reply-To: <aEW-5oqTUQgD8pJhkNbGxP_mUen4ld5hYVD_MRKvydE=.7b6900ba-ee3e-4d7a-a1fd-26d4510ffe8e@github.com>
References: <aEW-5oqTUQgD8pJhkNbGxP_mUen4ld5hYVD_MRKvydE=.7b6900ba-ee3e-4d7a-a1fd-26d4510ffe8e@github.com>
Message-ID: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com>

> This fix adds the `--add-reads` support for CDS and AOTClassLinking.
> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled:
> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro`
> During runtime, the archived full module graph will be disabled:
> `[0.021s][info][cds       ] full module graph: disabled`
> 
> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime.
> 
> Testing: tiers 1 - 4.

Calvin Cheung has updated the pull request with a new target base 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:

 - @iklam comment
 - Merge branch 'master' into 8354083-add-reads
 - fix trailing whitespace
 - 8354083: Support --add-reads with -XX:+AOTClassLinking

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25109/files
  - new: https://git.openjdk.org/jdk/pull/25109/files/562fc591..327dc2d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25109&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25109&range=00-01

  Stats: 18384 lines in 682 files changed: 11198 ins; 4135 del; 3051 mod
  Patch: https://git.openjdk.org/jdk/pull/25109.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25109/head:pull/25109

PR: https://git.openjdk.org/jdk/pull/25109

From ccheung at openjdk.org  Thu May 15 00:21:52 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 15 May 2025 00:21:52 GMT
Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking [v2]
In-Reply-To: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com>
References: <aEW-5oqTUQgD8pJhkNbGxP_mUen4ld5hYVD_MRKvydE=.7b6900ba-ee3e-4d7a-a1fd-26d4510ffe8e@github.com>
 <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com>
Message-ID: <rACr1R3_n6RpxH3al3F1NF4vVhhfNWrk0IWjTbRm7CM=.19dae566-0408-4ca6-8695-16513804fe38@github.com>

On Thu, 15 May 2025 00:16:32 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This fix adds the `--add-reads` support for CDS and AOTClassLinking.
>> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled:
>> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro`
>> During runtime, the archived full module graph will be disabled:
>> `[0.021s][info][cds       ] full module graph: disabled`
>> 
>> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime.
>> 
>> Testing: tiers 1 - 4.
>
> Calvin Cheung has updated the pull request with a new target base 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:
> 
>  - @iklam comment
>  - Merge branch 'master' into 8354083-add-reads
>  - fix trailing whitespace
>  - 8354083: Support --add-reads with -XX:+AOTClassLinking

I have moved the three tests (AddExports.java, AddOpens.java, AddReads.java) to the `runtime/cds/appcds/aotClassLinking` directory. The AddOpens.java and AddReads.java were rewritten to make use of the `SimpleCDSAppTester` and `CDSAppTester` classes. The `TEST.groups` needs some adjustments as a result of the tests relocation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25109#issuecomment-2881879075

From serb at openjdk.org  Thu May 15 02:27:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 15 May 2025 02:27:50 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
Message-ID: <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>

On Wed, 14 May 2025 17:34:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> For the l10n files, they are synced by the translation team and we don't edit them. IMO, I think it's fine leaving those ones as is. Especially because language rules can cause different spacing and punctuation characters, so generally we don't ensure translations are equivalent to the original file's value in that regard. (So viewing them as a Unicode escape sequence vs UTF-8 literal may not bring much benefit.)
>
> I believe it is OK to leave these as UTF-8 native characters, as these files are l10n resource bundles. If we wanted to replace those look-alike spaces to unicode escapes, other characters may also need the same treatment, such as hyphen-minus, quotations, etc. In fact there are lot more look alikes defined in the unicode consortium (https://www.unicode.org/Public/security/latest/confusables.txt), and I don't think we would want to convert them.

maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090083320

From naoto at openjdk.org  Thu May 15 03:20:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 May 2025 03:20:51 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
Message-ID: <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>

On Thu, 15 May 2025 02:25:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I believe it is OK to leave these as UTF-8 native characters, as these files are l10n resource bundles. If we wanted to replace those look-alike spaces to unicode escapes, other characters may also need the same treatment, such as hyphen-minus, quotations, etc. In fact there are lot more look alikes defined in the unicode consortium (https://www.unicode.org/Public/security/latest/confusables.txt), and I don't think we would want to convert them.
>
> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?

Maybe, but sometimes it is intentional. CLDR has once switched normal spaces to NBSP/NNBSP for certain locales (https://unicode-org.atlassian.net/browse/CLDR-14032). And we cannot tell if it is intentional or not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090140891

From iklam at openjdk.org  Thu May 15 03:23:40 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 15 May 2025 03:23:40 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v9]
In-Reply-To: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
Message-ID: <NjDSKx8H8J7YgaFo-vFE3viHTuRYRdFnH6TP8NCtk9c=.822fc1df-dba7-4209-9be5-ccab4ad9ae95@github.com>

> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
> 
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
> 
> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
> 
> Examples:
> 
> 
> # Create an AOT cache with a single command:
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> Hello World
> Temporary AOTConfiguration recorded: foo.aot.config
> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
> AOTCache creation is complete: foo.aot 10240000 bytes
> 
> # Create logging file for the AOT cache assembly phase
> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> 
> 
> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - @vnkozlov comments
 - added info about JTREG/AOT_JDK testing
 - fixed whitespace
 - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
 - java.md updates from @rose00
 - Resolved differences with CSR JDK-8356010
 - Added param to makefile function SetupAOT for choosing onestep vs twostep
 - Allow one-step training even when -XX:AOTMode=auto is specified
 - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
 - Update java man page
 - ... and 12 more: https://git.openjdk.org/jdk/compare/5e50a584...7f4c0e8b

-------------

Changes: https://git.openjdk.org/jdk/pull/24942/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=08
  Stats: 2082 lines in 24 files changed: 1558 ins; 459 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/24942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942

PR: https://git.openjdk.org/jdk/pull/24942

From iklam at openjdk.org  Thu May 15 03:23:40 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 15 May 2025 03:23:40 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v8]
In-Reply-To: <2gn7SekvlmULcWgKYlo53IKbh8NdBpV0JfGTMc7SsHY=.02f6f7f2-3e30-4e8a-8d14-f187cc2d3c11@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <tjP4ZHZ79VRaDaKgsl38nBOBVrgjt1A0lQX4nndoTMg=.9698bf32-c090-47da-8b14-f3ad883c3e39@github.com>
 <2gn7SekvlmULcWgKYlo53IKbh8NdBpV0JfGTMc7SsHY=.02f6f7f2-3e30-4e8a-8d14-f187cc2d3c11@github.com>
Message-ID: <iA19L2tvhAKPA9M9XAoNHAgN3T7s6W958JiBWY_iO4c=.471d37f9-b260-42fc-b682-216bb2a25d39@github.com>

On Wed, 14 May 2025 15:38:06 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - java.md updates from @rose00
>>  - Resolved differences with CSR JDK-8356010
>
> src/hotspot/share/cds/cds_globals.hpp line 123:
> 
>> 121:   product(ccstr, AOTCacheOutput, nullptr,                                   \
>> 122:           "Write AOT cache into this file (overrides AOTCache when "        \
>> 123:           "writing)")                                                       \
> 
> This looks not complete description. And "override AOTCache .." is confusing.

I changed it to "Specifies the file name for writing the AOT cache". Since the behavior is complex, I don't know how much detail I should put here.

> src/hotspot/share/cds/metaspaceShared.cpp line 1150:
> 
>> 1148:   print_java_launcher(&ss);
>> 1149:   const char* cmd = ss.freeze();
>> 1150:   tty->print_cr("Launching child process %s to assemble AOT cache %s using configuration %s", cmd, AOTCacheOutput, AOTConfiguration);
> 
> I noticed that AOT produces outputs on TTY like this unconditionally. I think it is fine for development but for production we should use UL I think.
> Was this discussed?

Currently we print things that are important to the user. The other examples are:


$ java -XX:AOTMode=record ....
AOTConfiguration recorded: hw.aotconfig

$ java -XX:AOTMode=create ....
Reading AOTConfiguration hw.aotconfig and writing AOTCache hw.aot
AOTCache creation is complete: hw.aot 10498048 bytes


I think AOT is still a new feature so a small number of TTY prints would be helpful. If people complain about the verbosity we can change them to UL logs.

> src/hotspot/share/runtime/arguments.cpp line 3060:
> 
>> 3058: }
>> 3059: 
>> 3060: static JavaVMOption* get_last_aotmode_arg(const JavaVMInitArgs* args) {
> 
> I don't like that we pollute `Arguments` code with AOT specific flags processing.
> Can we move this into `CDSConfig`? Both these 2 new methods.
> 
> But I will agree if you want to keep it here. It is not critical.

These two functions are for parsing `JDK_AOT_VM_OPTIONS`, so I think they belong to arguments.cpp. cdsConfig.cpp is a consumer of the options parsed by arguments.cpp.

> src/java.base/share/man/java.md line 4141:
> 
>> 4139:        mode should be used only as a "fail-fast" debugging aid to check if your command-line
>> 4140:        options are compatible with the AOT cache. An alternative is to run your application with
>> 4141:        `-XX:AOTMode=auto -Xlog:cds,aot` to see if the AOT cache can be used or not.
> 
> `-Xlog:aot`

`-Xlog:cds,aot` is correct for the current state of this PR. I'll change it after JDK-8356595 is integrated into the mainline.

> test/hotspot/jtreg/runtime/cds/appcds/aotFlags/AOTFlags.java line 166:
> 
>> 164:             "-XX:-AOTClassLinking",
>> 165:             "-XX:AOTConfiguration=" + aotConfigFile,
>> 166:             "-Xlog:cds=debug",
> 
> `-Xlog:aot`
> I assume JDK-8356595: "Convert -Xlog:cds to -Xlog:aot " will be pushed first.

`-Xlog:cds=debug` is correct for the current state of this PR (otherwise the test will fail). I'll change it after JDK-8356595 is integrated into the mainline.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133925
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133649
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133612
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133585
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133557

From kvn at openjdk.org  Thu May 15 03:36:55 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 15 May 2025 03:36:55 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v8]
In-Reply-To: <iA19L2tvhAKPA9M9XAoNHAgN3T7s6W958JiBWY_iO4c=.471d37f9-b260-42fc-b682-216bb2a25d39@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <tjP4ZHZ79VRaDaKgsl38nBOBVrgjt1A0lQX4nndoTMg=.9698bf32-c090-47da-8b14-f3ad883c3e39@github.com>
 <2gn7SekvlmULcWgKYlo53IKbh8NdBpV0JfGTMc7SsHY=.02f6f7f2-3e30-4e8a-8d14-f187cc2d3c11@github.com>
 <iA19L2tvhAKPA9M9XAoNHAgN3T7s6W958JiBWY_iO4c=.471d37f9-b260-42fc-b682-216bb2a25d39@github.com>
Message-ID: <iHbqJy4HOQcKR3Q305to2IqLbFCyADBZGKQh2nM-wHs=.b98ef8c0-37f4-4e3c-8e49-4274b217e774@github.com>

On Thu, 15 May 2025 03:15:23 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 3060:
>> 
>>> 3058: }
>>> 3059: 
>>> 3060: static JavaVMOption* get_last_aotmode_arg(const JavaVMInitArgs* args) {
>> 
>> I don't like that we pollute `Arguments` code with AOT specific flags processing.
>> Can we move this into `CDSConfig`? Both these 2 new methods.
>> 
>> But I will agree if you want to keep it here. It is not critical.
>
> These two functions are for parsing `JDK_AOT_VM_OPTIONS`, so I think they belong to arguments.cpp. cdsConfig.cpp is a consumer of the options parsed by arguments.cpp.

okay

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090168858

From kvn at openjdk.org  Thu May 15 03:40:55 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 15 May 2025 03:40:55 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v9]
In-Reply-To: <NjDSKx8H8J7YgaFo-vFE3viHTuRYRdFnH6TP8NCtk9c=.822fc1df-dba7-4209-9be5-ccab4ad9ae95@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <NjDSKx8H8J7YgaFo-vFE3viHTuRYRdFnH6TP8NCtk9c=.822fc1df-dba7-4209-9be5-ccab4ad9ae95@github.com>
Message-ID: <rtYPtCxA67PpCHYAIoHhNNhlxuzt8P_FdMZeuLXiKLk=.b87f82a6-8786-4043-b81a-2dc1bf521bfe@github.com>

On Thu, 15 May 2025 03:23:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>> 
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
>> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
>> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
>> 
>> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
>> 
>> Examples:
>> 
>> 
>> # Create an AOT cache with a single command:
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> Hello World
>> Temporary AOTConfiguration recorded: foo.aot.config
>> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
>> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
>> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
>> AOTCache creation is complete: foo.aot 10240000 bytes
>> 
>> # Create logging file for the AOT cache assembly phase
>> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> 
>> 
>> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - @vnkozlov comments
>  - added info about JTREG/AOT_JDK testing
>  - fixed whitespace
>  - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
>  - java.md updates from @rose00
>  - Resolved differences with CSR JDK-8356010
>  - Added param to makefile function SetupAOT for choosing onestep vs twostep
>  - Allow one-step training even when -XX:AOTMode=auto is specified
>  - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
>  - Update java man page
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/5e50a584...7f4c0e8b

Looks good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2842120535

From iklam at openjdk.org  Thu May 15 04:20:51 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 15 May 2025 04:20:51 GMT
Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking [v2]
In-Reply-To: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com>
References: <aEW-5oqTUQgD8pJhkNbGxP_mUen4ld5hYVD_MRKvydE=.7b6900ba-ee3e-4d7a-a1fd-26d4510ffe8e@github.com>
 <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com>
Message-ID: <SAThr4t4FsWJ2RgDnAF8U8uc6CFovxbBh4lFAQaexAo=.3679f6d8-0729-4718-b2ed-0bcbaebcb07e@github.com>

On Thu, 15 May 2025 00:16:32 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This fix adds the `--add-reads` support for CDS and AOTClassLinking.
>> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled:
>> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro`
>> During runtime, the archived full module graph will be disabled:
>> `[0.021s][info][cds       ] full module graph: disabled`
>> 
>> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime.
>> 
>> Testing: tiers 1 - 4.
>
> Calvin Cheung has updated the pull request with a new target base 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:
> 
>  - @iklam comment
>  - Merge branch 'master' into 8354083-add-reads
>  - fix trailing whitespace
>  - 8354083: Support --add-reads with -XX:+AOTClassLinking

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25109#pullrequestreview-2842162246

From duke at openjdk.org  Thu May 15 05:55:54 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 15 May 2025 05:55:54 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <dJ6QbcWd3g7UZrHLzDKDZpsg1JGl5przqySy6chS8xM=.8f09904b-0f74-42d9-9562-47fcb73f5dc7@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <x1nMqw3J0aQoPyMt3WZ8YPnPFEwAebt_cnGtQYSXNSs=.6ae13f2a-5eeb-410d-9971-958526a8f16e@github.com>
 <BErvDbjWrXY7YGuIyQwR22cHeUP4knxU8MU4tw6AMN4=.c6b174ea-abdb-4b11-b6f9-0d97a03dc6ff@github.com>
 <Swr1GEuPbIhL4A273oZfYFmAlwYw3lPF2vaWhTzt4aE=.401b5bda-92db-4361-a581-579756ecf562@github.com>
 <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com>
 <RbqVx9l3PqI3nGa04lI8LZc8q4RyriZK8KP0-sqL098=.257abdaf-af46-4148-b925-42eebb1a3666@github.com>
 <6pcsLU3w7BQmpUbZ-p53iZsOK3kVckilpiHzyOu2VK8=.10d95ba6-1259-4e90-a994-407f9c247a67@github.com>
 <-alnojXx7gvsHuZyAugz_zk_1bf_QT0PfSZMdvP_Xt8=.0791cdf3-f466-4dd0-b672-5a0f619d14d7@github.com>
 <dJ6QbcWd3g7UZrHLzDKDZpsg1JGl5przqySy6chS8xM=.8f09904b-0f74-42d9-9562-47fcb73f5dc7@github.com>
Message-ID: <dwtS71dqeIYLsEVqpFl0-AMfQRX35vq0zgpBrzDfkw4=.0af8ec7d-614e-4098-adaa-c1ab56d1f035@github.com>

On Wed, 14 May 2025 22:19:39 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> I meant that the implementation of `subSequence` *might or might not* perform copy (so we need to tell the javaDoc reader), while `getChar` *clearly* performs a copy as part of it design. So `subSequence` can be surprising as this discussion proofs, while `getChars` will not. That was Stuart's point with `read`, and that was your point with `CharSequence`.
>
> @mkarg Please don't invoke my name to try to buttress your arguments. The calls the Reader.of() instance makes on its backing CharSequence is a different kind of issue from what promises or guarantees the concrete methods of the Reader class makes to its subclasses.

@stuart-marks Sorry, didn't want to pull you in here, that's why I said, I am just *paraphrasing*.

That is correct, it is a different case, but the *final effect* for the caller is the same: If he needs to now whether a copy is made *or not*, he needs to have JavaDocs telling him *how* the new method works inside (whether it calls `subSequence` or whether it calls `getChars`). Otherwise he might make false assumptions about the result.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090314165

From duke at openjdk.org  Thu May 15 06:07:55 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 15 May 2025 06:07:55 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <i7pO5k_0Njw2C9CrXbas_r1BOvQCBE0hb_h2D5aPi-k=.e9a8c89e-be40-44d6-845d-777be038d193@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <3_OKKbE_5VGTF91MWcFdjTmSn-z7PDaRqL7gcma8Zcs=.ae5b7b11-3a37-46a6-9754-073440f3012e@github.com>
 <3dImE74ioqCoWHkOx_sQIbUIAFM5Y9WX920wkyMkZ9c=.af17f449-9ecf-4d0f-84ef-8d9068af0ab3@github.com>
 <4T4npViSWy-EFy6758EMIx2cRHmYONULq2v1Dhjb4JU=.60d1efd4-c310-4176-9107-bb4e3c7030e0@github.com>
 <3kJUC9n4dQcRHW1etWe0x3k_yP_B4thpst8cG9JrMZQ=.672d3b67-7237-48e5-98fa-057852c23ca4@github.com>
 <a6uoLPrncSxGv6y3P60m2o3ZT0POmwRr7z8nTjD_Q68=.d4ac9503-b29e-4aec-a75d-f0c031166721@github.com>
 <L6ovQHi9B7L8OYP83pDLW1MzNOXhZYABPEQpfwUOyf4=.97b4752b-13f5-40fc-a8d9-447380be2fbb@github.com>
 <i7pO5k_0Njw2C9CrXbas_r1BOvQCBE0hb_h2D5aPi-k=.e9a8c89e-be40-44d6-845d-777be038d193@github.com>
Message-ID: <oYRZmWjz6O4lFgZk5f7pA-XZmC697GW5eMHqCN4T5hk=.036724d3-323c-40a4-b2ad-4632070164e8@github.com>

On Wed, 14 May 2025 22:31:46 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> I know that comment already, but IMHO we can simply use `@implSpec` to unambiguously make clear that this method invokes `read(char[])` to allow optimized implementations, and it *might* in turn invoke `read(char[],int,int)`, but this is *not guaranteed*. A class is only fragile as long as we do not *document* what it will do.
>
> I doubt a subclass could make an optimization to the one-arg read() that it couldn't also make with the three-arg read(). Since the subclass is required to implement the three-arg read(), there's no benefit in specifying that this method call the one-arg read() instead of the three-arg read().
> 
> However, requiring this implementation to call the one-arg read() method is detrimental, because it precludes future optimizations that we might want to make to this method, which might want to use the more flexible three-arg read() method.

Well, I did not say that the specific `CharSequence` *could not* have optimized both methods, I just said *it might be* like that (for whatever reason). ? 

I do not see a difference in the positive or negative outcomes whatever method we choose. The one method we call will benefit from its optimization, the one that we do not pick will miss the support for its optimization. I can't see what you like to optimize in future that is only possible with the three-arg parameters but would not be possible with the one-arg parameter. Do you have an example for this future optimization (note that the outcome shall and will ever be the *full* result due to the nature of this particular new method)? ? 

If there is broad agreement that `Reader` implementation should *not* put optimizations *only* in the single-arg method but always should optimize the three-arg method too, we should definitively mention this decision in `Reader`'s Javadocs so implementors do know. Currently we only say that it would be *enough* to implement the three-arg method, which has a different semantic and urgence for the reader.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090346089

From alanb at openjdk.org  Thu May 15 06:09:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 May 2025 06:09:51 GMT
Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for()
 loops
In-Reply-To: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
References: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
Message-ID: <Rv2vKh5toqVwWE2NVPuVJDXP3zyokifv9JMMmEy3p38=.81fc91b9-205b-43b9-be1c-9222db3dbffb@github.com>

On Wed, 14 May 2025 19:37:37 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this small performance tweak `ArrayDeque`.
> 
> `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead.

Are you planning to add some JMH benchmarks to go with this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25237#issuecomment-2882668954

From duke at openjdk.org  Thu May 15 06:29:54 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 15 May 2025 06:29:54 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <F6Kjz5iF9Y5R0V8LuRCuX_JtmI6Ohtzksy96kGzDUY8=.a461b9e5-02dd-4226-aced-cf4f910b01b0@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
 <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>
 <nCFdoAHy2RkNENhaRhdaMDbO3iiAuV-AsirMDJoS0Dc=.0177c4cd-1e71-494f-8956-13edc7eb0551@github.com>
 <BctFVukNg2CVXVsPVF96howIOf-A8N_G-AIClpaqmgE=.53d54891-c098-4922-81c7-ddd0818c647d@github.com>
 <apAsxR7rrX0ofU-2q3GVqq_uWkKTD8u4sw7zKeYCT2k=.c4f73ab2-cc66-4f98-b668-de356b788849@github.com>
 <f9my7Gq_OjkXWTBa2L2h1EFIgMpA5PuFf5xndOfcwlM=.e87667ba-d5eb-48aa-be35-05d52ac81212@github.com>
 <Y2P9dJdshrswViDiOGTS14EdODFTMxF7Z1fyDuiQdsA=.d182371a-d1ad-482f-8ff1-d01d06737a32@github.com>
 <g1GHppLlTaHjuFACIi8dgMvNZfQA81ctofGglGZXAXk=.73477b96-4dd8-45ca-9bae-f3a15d8ce8c1@github.com>
 <cnVCW6f3cE8qRMTn_8PMfPX8NPB8WhEcTJb
 jp_Zz3MY=.a4fe61f7-1a2a-4528-91a9-fde9cae8acfa@github.com>
 <jOzAzf7qiUGaR4AcVxkVruHyXr7-SLNU2pRV_z8iojk=.0c07b2ec-c8e7-4170-84e8-d1baed0afde0@github.com>
 <F6Kjz5iF9Y5R0V8LuRCuX_JtmI6Ohtzksy96kGzDUY8=.a461b9e5-02dd-4226-aced-cf4f910b01b0@github.com>
Message-ID: <PIGolcNUOTm_uea2SMpu6zMF_8imtmuC_RiCTCTPIvU=.0845a60f-3eab-43cd-8956-9d10fbd5c439@github.com>

On Wed, 14 May 2025 20:52:00 GMT, Markus KARG <duke at openjdk.org> wrote:

>> There's nothing in the CharSequence interface that requires or indicates that the implementation is or is not immutable. Interfaces only have loosely defined contracts, only the signature of the methods, the caller can not hold any more expectations about the semantics of the implementation.
>> Immutable objects are among the best tools we have for making reliable software. 
>> The caller does not have to have a deep knowledge of the implementation to get predictable results.
>> For most OpenJDK public APIs, the objective is to have well defined semantics with no implementation surprises.
>
> Granted in general, but again, it is not the job of *this particular API* to forbid mutation *iff* the caller and / or producer of the object see a good reason for that. This completely overdesigns the target of *this* API. Callers are no dummies, they can read JavaDocs, and they can `.toString()` on their own *iff* needed. Actually, in 30 years I never heard a Java Programmer say "oops, I did not expect `CharSequence` to mutate". With that attitude we could simply deprecate `CharSequence` for removal...!
> 
> BTW, how will you mutate a `CharSequence` if you don't know its actual implementation? Try-and-error? ? Or with "immutable" do you mean *constant* objects (i. e. *the producer* will not modify it after creation)?
> 
> It is a *good* thing not to know what you have in your hands, as you *do not start* making assumptions (like "it is immutable"). I am fond of getting *away* from those restricted semantics, towards a cleaner "do not assume, do not trust" policy.

> > Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence...
> 
> The most simple example is a file server. Incidential fact, just today I wrote a function that simply passes JSON documents received in a REST call forward to another server using another REST call (without parsing it). The document is not changed. It is _inefficient_ to force it into a `String` temporarily. This is not untypical, such use cases exists often in server computing.

Seems to me that in your example `Reader.transferTo(Writer)` would be the better choice instead of reading everything into a String or CharSequence and writing it to the next sink.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090374558

From tpushkin at openjdk.org  Thu May 15 06:45:54 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 15 May 2025 06:45:54 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v12]
In-Reply-To: <JoyEhrXuHQMMjc5wSmogN0045YycfgZbi1YkpP3Ef8g=.ba201c18-7077-451a-b4b9-adafa9278b7f@github.com>
References: <AdBmCAbqhjQEP05JBlXhp21hKuxn7SAb7h0Y3Wvollk=.21c0e6fe-097e-41e4-afa3-45b108112a28@github.com>
 <JoyEhrXuHQMMjc5wSmogN0045YycfgZbi1YkpP3Ef8g=.ba201c18-7077-451a-b4b9-adafa9278b7f@github.com>
Message-ID: <bEQtifJcCFbP1nMQbwzSCcKwFdByXELAfoG0hD3Al-M=.191b1d1d-08cd-42a2-b633-f17e65851674@github.com>

On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin <tpushkin at openjdk.org> 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:
> 
>   Make supertype obstruction check easier to understand

Thank you!

> Once this PR has 2 reviews and is final, I will run some tests in our test pipeline.

@iklam It is final, please run the tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2882738562

From peter.levart at gmail.com  Thu May 15 07:01:42 2025
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 15 May 2025 09:01:42 +0200
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: <CANSoFxs181gROMY90tYy5mg2rWzwFrJZX=tH2WRtX=Cy6bUiZw@mail.gmail.com>
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 <d9fdd1b1-67e5-45d7-b7a6-a07ed771bba3@oracle.com>
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 <A8899F82-5CB0-44B8-AF34-6D3EF5A77CC3@oracle.com>
 <a5120cdf1d5946c9add0a1c615f6440c@amazon.com>
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 <aa7fabbb-94e3-4510-b20c-b1ed7518858a@oracle.com>
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
 <CABe8uE0W81CY7Acas0fm9ZMpMW4R+oPbhkwpdDW9TEXhSEJf-g@mail.gmail.com>
 <CANSoFxuJZZtd0PCTmCz4CJDg0kAHU0Ldj19E0VRtmOiqVHkVFQ@mail.gmail.com>
 <e132ab48b8df4246b9a8c91a8c1ec0ff@amazon.com>
 <4741eceb3beb40c2bc82613c67836d66@amazon.com>
 <CANSoFxsZ0AV96KggvSCOW4T80B55HrdBWOP67PQKpgbMpszcsw@mail.gmail.com>
 <CANSoFxu75tpy_kq9T-a3fDz5dZ-k+qhtJO8LoYxxWRO-SRXE6A@mail.gmail.com>
 <95335d21438d4826a87db616b65d9ec9@amazon.com>
 <CANSoFxs181gROMY90tYy5mg2rWzwFrJZX=tH2WRtX=Cy6bUiZw@mail.gmail.com>
Message-ID: <7dbee86b-b80e-4827-aaa9-603d5e6d3402@gmail.com>


On 4/11/25 6:19 PM, Archie Cobbs wrote:
> 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.


You can have power-of-two exponentially growing segments and still 
access individual elements by index in constant time (although you don't 
need this if you are just doing the ByteArrayOutputStream implementation).


For example, let the array of segments:

byte[][] segments;


start with 0th segment of length 1 byte, then 2, 4, 8, 16, ...


To access the i-th byte you would do:

 ??? byte getByte(int i) {
 ??????? int segmentIndex = 31 - Integer.numberOfLeadingZeros(i + 1);
 ??????? int byteIndex = i + 1 - (1 << segmentIndex);
 ??????? return segments[segmentIndex][byteIndex];
 ??? }


This can be adapted to situations where the 0th segment starts not with 
1 byte length but with any 2^N length. For example, 8:

 ??? byte getByte(int i) {
 ??????? int segmentIndex = 31 - Integer.numberOfTrailingZeros(8) - 
Integer.numberOfLeadingZeros(i + 8);
 ??????? int byteIndex = i + 8 - (8 << segmentIndex);
 ??????? return segments[segmentIndex][byteIndex];
 ??? }


What I'm trying to say is that constant segment length might not be the 
best choice if you consider the range of possible ByteArray (BAOS) final 
lengths. If you choose too small, the number of segments will be too 
large, so you end up with multiple resizing(s) of the array of segments 
then - the problem you are trying to solve would still be there, 
although divided by the segment size. If you choose to big, the up-front 
allocation overhead for small ByteArray(s) (BAOSes) would be too large.

With power-of-two exponentially growing segments you get an allocation 
overhead below 2x the needed final length and no redundant copying 
(apart from final copy to the result if you need such result as byte[]).


Regards, Peter



From tschatzl at openjdk.org  Thu May 15 08:18:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 15 May 2025 08:18:47 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v38]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <oGs-LCsoAXaXs1T2ikN-Oaf8FM9M7mnBI3BYb-P2vE0=.427e8a5a-c47d-4956-a423-8fd03d6778bd@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 54 commits:

 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review: remove sweep_epoch
 - Merge branch 'master' into card-table-as-dcq-merge
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review (part 2 - yield duration changes)
 - * ayang review (part 1)
 - * indentation fix
 - * remove support for 32 bit x86 in the barrier generation code, following latest changes from @shade
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * fixes after merge related to 32 bit x86 removal
 - ... and 44 more: https://git.openjdk.org/jdk/compare/5e50a584...1def83af

-------------

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=37
  Stats: 7088 lines in 111 files changed: 2568 ins; 3599 del; 921 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From ihse at openjdk.org  Thu May 15 09:19:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 May 2025 09:19:53 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
 <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
Message-ID: <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>

On Thu, 15 May 2025 03:18:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?
>
> Maybe, but sometimes it is intentional. CLDR has once switched normal spaces to NBSP/NNBSP for certain locales (https://unicode-org.atlassian.net/browse/CLDR-14032). And we cannot tell if it is intentional or not.

> So, this exactly reverses what was done in the fix for JDK-8301991

No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences.

This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space.

Technically, it might be that some of these lines in the properties files are reversals of JDK-8301991, but that's just basically coincidence.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090692617

From ihse at openjdk.org  Thu May 15 09:19:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 May 2025 09:19:53 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
 <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
 <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>
Message-ID: <bffWy8H4d6xnje0Gz_jIyv5jPBMuqp7S-iBFZTioTng=.7ee33246-76c2-470f-b608-894b5ba93988@github.com>

On Thu, 15 May 2025 09:16:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Maybe, but sometimes it is intentional. CLDR has once switched normal spaces to NBSP/NNBSP for certain locales (https://unicode-org.atlassian.net/browse/CLDR-14032). And we cannot tell if it is intentional or not.
>
>> So, this exactly reverses what was done in the fix for JDK-8301991
> 
> No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences.
> 
> This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space.
> 
> Technically, it might be that some of these lines in the properties files are reversals of JDK-8301991, but that's just basically coincidence.

> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?

That seems unlikely. The pattern is used consistently in the French translations, where `Foo:` in the original is replaced with `Foo :` with a non-breaking space. I guess it is a French orthographic rule to have a space before the colon, and I understand why it really must be non-breaking in that case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090695445

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <ExI4OcZ4H03w2Kmpe35WuEynczPvNAcXjCFY4cd6ldg=.1be29db4-e6a7-4376-93d9-94c05587c721@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

After an offline discussion, we agreed to wait a bit with this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2883137218

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 GMT
Subject: Withdrawn: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <LrGk5ztc6aRY4EQjv-mVBVaNIVBhvjY-SQD1ZkUD5d4=.dba136cb-acc9-4d18-9112-41f62464a65f@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25122

From alanb at openjdk.org  Thu May 15 09:42:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 May 2025 09:42:52 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v3]
In-Reply-To: <V_z1LM8NiXvm2IaCKIJHcr-WrAVCc7KVB7eYUjGSszU=.dd1c921c-a20b-471b-8e5f-be63360be0d8@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <V_z1LM8NiXvm2IaCKIJHcr-WrAVCc7KVB7eYUjGSszU=.dd1c921c-a20b-471b-8e5f-be63360be0d8@github.com>
Message-ID: <sPv6ygOuT7BHCC2wPxSsWszSgeVESvExGcpkXEZPEQs=.a55943ac-25ab-44f0-90d0-1df05d6464a6@github.com>

On Fri, 2 May 2025 18:19:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set

test/jdk/java/io/File/DeleteReadOnly.java line 61:

> 59:     @Test
> 60:     @Order(1)
> 61:     @EnabledOnOs({OS.AIX, OS.LINUX, OS.MAC})

Have you look at creating a simpler test that doesn't use Order. If you drop DIR and FILE then each test could create the file or directory as needed so there wouldn't be any dependency on order.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2090748506

From pminborg at openjdk.org  Thu May 15 09:54:29 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 15 May 2025 09:54:29 GMT
Subject: RFR: 8356706: Foreign tests timeout after passing on linux-x64-zero
Message-ID: <MNGWhQ48W8sGWxAwqdTwi85G1dtJnK7963u6gVEdUA8=.544a4427-811e-4020-bdb4-724529545773@github.com>

This PR improves the robustness of tests on slow machines such as "zero" variants. The timeout was increased to 10 minutes for both tests. There are many combinations in `TestAccessModes`, so the test takes some time even on a fast machine. In `StdLibTest`, there are numerous native calls, and these can be much slower on "zero" machines. In the latter test class, I made some attempts to improve performance. On my M1 machine, the test was about 10% faster with the changes (but I only did one run, so this might be in the error margin).

-------------

Commit messages:
 - Improve robustness of tests on slow machines

Changes: https://git.openjdk.org/jdk/pull/25248/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25248&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356706
  Stats: 32 lines in 2 files changed: 0 ins; 0 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/25248.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25248/head:pull/25248

PR: https://git.openjdk.org/jdk/pull/25248

From pminborg at openjdk.org  Thu May 15 09:54:29 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 15 May 2025 09:54:29 GMT
Subject: RFR: 8356706: Foreign tests timeout after passing on
 linux-x64-zero
In-Reply-To: <MNGWhQ48W8sGWxAwqdTwi85G1dtJnK7963u6gVEdUA8=.544a4427-811e-4020-bdb4-724529545773@github.com>
References: <MNGWhQ48W8sGWxAwqdTwi85G1dtJnK7963u6gVEdUA8=.544a4427-811e-4020-bdb4-724529545773@github.com>
Message-ID: <D6_Do_rfrEhun3ibckokmoukaZFDyxZW0fv2_w-7_3k=.5e9a48ce-673a-49fc-955a-e9ff259177b9@github.com>

On Thu, 15 May 2025 09:49:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR improves the robustness of tests on slow machines such as "zero" variants. The timeout was increased to 10 minutes for both tests. There are many combinations in `TestAccessModes`, so the test takes some time even on a fast machine. In `StdLibTest`, there are numerous native calls, and these can be much slower on "zero" machines. In the latter test class, I made some attempts to improve performance. On my M1 machine, the test was about 10% faster with the changes (but I only did one run, so this might be in the error margin).

test/jdk/java/foreign/StdLibTest.java line 56:

> 54:     static final Linker abi = Linker.nativeLinker();
> 55: 
> 56:     private static final StdLibHelper STD_LIB_HELPER = new StdLibHelper();

The `STD_LIB_HELPER` is now a constant.

test/jdk/java/foreign/StdLibTest.java line 145:

> 143:     static final class StdLibHelper {
> 144: 
> 145:         static final MethodHandle strcat = abi.downcallHandle(abi.defaultLookup().findOrThrow("strcat"),

Drive-by cleanup to blessed order.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25248#discussion_r2090771644
PR Review Comment: https://git.openjdk.org/jdk/pull/25248#discussion_r2090769634

From duke at openjdk.org  Thu May 15 09:57:18 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Thu, 15 May 2025 09:57:18 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v4]
In-Reply-To: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
Message-ID: <TZPHV4bpAY92nfYXr_Ffve-u3NmzB8MYf5tsw8rCp9Q=.b5d77705-1e1c-4c81-a251-022f27ae5e5d@github.com>

> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails

PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused method getDockerVersionStr

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24948/files
  - new: https://git.openjdk.org/jdk/pull/24948/files/3b18431d..61ca55ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=02-03

  Stats: 17 lines in 1 file changed: 0 ins; 17 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24948.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24948/head:pull/24948

PR: https://git.openjdk.org/jdk/pull/24948

From duke at openjdk.org  Thu May 15 09:57:19 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Thu, 15 May 2025 09:57:19 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v3]
In-Reply-To: <7ZM5FpCXNDfRwU9qCLOnve_LH-Yboa2cNjkfgWBS2OU=.30453fda-38e2-4c9c-bb37-fe1330b21a80@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
 <7ZM5FpCXNDfRwU9qCLOnve_LH-Yboa2cNjkfgWBS2OU=.30453fda-38e2-4c9c-bb37-fe1330b21a80@github.com>
Message-ID: <2ipbr_eKTB9-n_iHSSim1CqnM4thc3Yv6s5XuAvAKQE=.6a26fe01-853e-41fc-9090-182560004dd2@github.com>

On Wed, 14 May 2025 09:41:58 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor container runtime version code
>
> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 166:
> 
>> 164:             return null;
>> 165:         }
>> 166:     }
> 
> Do you still need this method?

Removed the method

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2090785990

From pminborg at openjdk.org  Thu May 15 10:01:57 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 15 May 2025 10:01:57 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v7]
In-Reply-To: <RAcEfEBZgn1o13wOeDQi9KG7s8koI8uizmFVGhqw0sk=.f65f7f8a-b8cf-4bbe-9dbd-8838e92453c6@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <RAcEfEBZgn1o13wOeDQi9KG7s8koI8uizmFVGhqw0sk=.f65f7f8a-b8cf-4bbe-9dbd-8838e92453c6@github.com>
Message-ID: <G5f3tD-CAhWOqRlFW77HIiuNd-CgcIUdiumJV1wuhwQ=.bb8510e6-3f0a-4d6c-8201-e064b638f592@github.com>

On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request with a new target base 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:
> 
>  - Merge remote-tracking branch 'upstream/master' into jla
>  - Improve `uncheckedGetBytesNoRepl` docs
>  - Apply suggestions from code review
>    
>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>  - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
>  - Fix `HexDigits` copyright year
>  - Fix copyright years
>  - Prefix touched methods with `unchecked`
>  - Fix typo in pre-existing JavaDoc
>  - Improve `JavaLangAccess` documentation

So, I think we are ready to go with the latest version.

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2843068669

From duke at openjdk.org  Thu May 15 10:03:11 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Thu, 15 May 2025 10:03:11 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v3]
In-Reply-To: <oMwFXneYTjswbqNbyMq16Cha8bJMXkrospBpxO3zTpw=.e9ed6489-55c3-4f20-aa08-65a9e2e40557@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <yJ64fGLegHJdHkks5n1gSozvZ_fLnMkLl6SN7MC2Kzo=.17a3b8c2-108a-416e-aa33-9e10e34b989e@github.com>
 <oMwFXneYTjswbqNbyMq16Cha8bJMXkrospBpxO3zTpw=.e9ed6489-55c3-4f20-aa08-65a9e2e40557@github.com>
Message-ID: <1elyKkFE2sZemPibqVeEswvApPKGWXVqeEMHc4rJpds=.9fff5366-2c8c-48b1-9523-a51b7f4a52ad@github.com>

On Tue, 13 May 2025 14:46:00 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

>> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor container runtime version code
>
> The change looks good. There might be some issues with container engine version parsing.
> 
> I wrote 2 comments. but cold not post them. They are in "pending" state.
> Not sure why. Should the comments be first reviewed by {Committers|Reviewers}?

@Domest0s I have tested against both docker and podman version and it was able to parse
for eg `docker version 20.10.0` and `podman version 4.9.4-rhel`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2883250455

From alanb at openjdk.org  Thu May 15 10:02:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 May 2025 10:02:54 GMT
Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking [v2]
In-Reply-To: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com>
References: <aEW-5oqTUQgD8pJhkNbGxP_mUen4ld5hYVD_MRKvydE=.7b6900ba-ee3e-4d7a-a1fd-26d4510ffe8e@github.com>
 <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com>
Message-ID: <vyKKAEDmsosz05IpVaGghCDXF7_An1oG-JCx9X6HTcc=.e8b00827-da0f-43b3-a093-b7d37fd11ba0@github.com>

On Thu, 15 May 2025 00:16:32 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This fix adds the `--add-reads` support for CDS and AOTClassLinking.
>> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled:
>> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro`
>> During runtime, the archived full module graph will be disabled:
>> `[0.021s][info][cds       ] full module graph: disabled`
>> 
>> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime.
>> 
>> Testing: tiers 1 - 4.
>
> Calvin Cheung has updated the pull request with a new target base 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:
> 
>  - @iklam comment
>  - Merge branch 'master' into 8354083-add-reads
>  - fix trailing whitespace
>  - 8354083: Support --add-reads with -XX:+AOTClassLinking

Update to allow --add-reads is okay, no comments from me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25109#issuecomment-2883257946

From duke at openjdk.org  Thu May 15 10:03:11 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Thu, 15 May 2025 10:03:11 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v5]
In-Reply-To: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
Message-ID: <U7dpc8IRZHFCXm8OJTMkrmNNuVbEXCzwWctZxiMj1gU=.b66cd9dd-74ad-4c65-9c5d-1a915d43fada@github.com>

> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails

PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24948/files
  - new: https://git.openjdk.org/jdk/pull/24948/files/61ca55ee..b3ccffd7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24948.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24948/head:pull/24948

PR: https://git.openjdk.org/jdk/pull/24948

From duke at openjdk.org  Thu May 15 10:25:57 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 15 May 2025 10:25:57 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <PIGolcNUOTm_uea2SMpu6zMF_8imtmuC_RiCTCTPIvU=.0845a60f-3eab-43cd-8956-9d10fbd5c439@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
 <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>
 <nCFdoAHy2RkNENhaRhdaMDbO3iiAuV-AsirMDJoS0Dc=.0177c4cd-1e71-494f-8956-13edc7eb0551@github.com>
 <BctFVukNg2CVXVsPVF96howIOf-A8N_G-AIClpaqmgE=.53d54891-c098-4922-81c7-ddd0818c647d@github.com>
 <apAsxR7rrX0ofU-2q3GVqq_uWkKTD8u4sw7zKeYCT2k=.c4f73ab2-cc66-4f98-b668-de356b788849@github.com>
 <f9my7Gq_OjkXWTBa2L2h1EFIgMpA5PuFf5xndOfcwlM=.e87667ba-d5eb-48aa-be35-05d52ac81212@github.com>
 <Y2P9dJdshrswViDiOGTS14EdODFTMxF7Z1fyDuiQdsA=.d182371a-d1ad-482f-8ff1-d01d06737a32@github.com>
 <g1GHppLlTaHjuFACIi8dgMvNZfQA81ctofGglGZXAXk=.73477b96-4dd8-45ca-9bae-f3a15d8ce8c1@github.com>
 <cnVCW6f3cE8qRMTn_8PMfPX8NPB8WhEcTJb
 jp_Zz3MY=.a4fe61f7-1a2a-4528-91a9-fde9cae8acfa@github.com>
 <jOzAzf7qiUGaR4AcVxkVruHyXr7-SLNU2pRV_z8iojk=.0c07b2ec-c8e7-4170-84e8-d1baed0afde0@github.com>
 <F6Kjz5iF9Y5R0V8LuRCuX_JtmI6Ohtzksy96kGzDUY8=.a461b9e5-02dd-4226-aced-cf4f910b01b0@github.com>
 <PIGolcNUOTm_uea2SMpu6zMF_8imtmuC_RiCTCTPIvU=.0845a60f-3eab-43cd-8956-9d10fbd5c439@github.com>
Message-ID: <5ue1HrdcMPaWc9wOSsLvvQaf6n8bWRrBP9CN7jeueF4=.7ff273a1-2a42-4fea-9e44-ba18d895aef7@github.com>

On Thu, 15 May 2025 06:27:36 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> Granted in general, but again, it is not the job of *this particular API* to forbid mutation *iff* the caller and / or producer of the object see a good reason for that. This completely overdesigns the target of *this* API. Callers are no dummies, they can read JavaDocs, and they can `.toString()` on their own *iff* needed. Actually, in 30 years I never heard a Java Programmer say "oops, I did not expect `CharSequence` to mutate". With that attitude we could simply deprecate `CharSequence` for removal...!
>> 
>> BTW, how will you mutate a `CharSequence` if you don't know its actual implementation? Try-and-error? ? Or with "immutable" do you mean *constant* objects (i. e. *the producer* will not modify it after creation)?
>> 
>> It is a *good* thing not to know what you have in your hands, as you *do not start* making assumptions (like "it is immutable"). I am fond of getting *away* from those restricted semantics, towards a cleaner "do not assume, do not trust" policy.
>
>> > Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence...
>> 
>> The most simple example is a file server. Incidential fact, just today I wrote a function that simply passes JSON documents received in a REST call forward to another server using another REST call (without parsing it). The document is not changed. It is _inefficient_ to force it into a `String` temporarily. This is not untypical, such use cases exists often in server computing.
> 
> Seems to me that in your example `Reader.transferTo(Writer)` would be the better choice instead of reading everything into a String or CharSequence and writing it to the next sink.

If the source is a `Reader` **and** target is a `Writer`, yes. But what if it is a native piece of hardware, like an IoT device, which produces / consumes `CharSequence`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090841625

From duke at openjdk.org  Thu May 15 10:25:58 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 15 May 2025 10:25:58 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <5ue1HrdcMPaWc9wOSsLvvQaf6n8bWRrBP9CN7jeueF4=.7ff273a1-2a42-4fea-9e44-ba18d895aef7@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
 <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>
 <nCFdoAHy2RkNENhaRhdaMDbO3iiAuV-AsirMDJoS0Dc=.0177c4cd-1e71-494f-8956-13edc7eb0551@github.com>
 <BctFVukNg2CVXVsPVF96howIOf-A8N_G-AIClpaqmgE=.53d54891-c098-4922-81c7-ddd0818c647d@github.com>
 <apAsxR7rrX0ofU-2q3GVqq_uWkKTD8u4sw7zKeYCT2k=.c4f73ab2-cc66-4f98-b668-de356b788849@github.com>
 <f9my7Gq_OjkXWTBa2L2h1EFIgMpA5PuFf5xndOfcwlM=.e87667ba-d5eb-48aa-be35-05d52ac81212@github.com>
 <Y2P9dJdshrswViDiOGTS14EdODFTMxF7Z1fyDuiQdsA=.d182371a-d1ad-482f-8ff1-d01d06737a32@github.com>
 <g1GHppLlTaHjuFACIi8dgMvNZfQA81ctofGglGZXAXk=.73477b96-4dd8-45ca-9bae-f3a15d8ce8c1@github.com>
 <cnVCW6f3cE8qRMTn_8PMfPX8NPB8WhEcTJb
 jp_Zz3MY=.a4fe61f7-1a2a-4528-91a9-fde9cae8acfa@github.com>
 <jOzAzf7qiUGaR4AcVxkVruHyXr7-SLNU2pRV_z8iojk=.0c07b2ec-c8e7-4170-84e8-d1baed0afde0@github.com>
 <F6Kjz5iF9Y5R0V8LuRCuX_JtmI6Ohtzksy96kGzDUY8=.a461b9e5-02dd-4226-aced-cf4f910b01b0@github.com>
 <PIGolcNUOTm_uea2SMpu6zMF_8imtmuC_RiCTCTPIvU=.0845a60f-3eab-43cd-8956-9d10fbd5c439@github.com>
 <5ue1HrdcMPaWc9wOSsLvvQaf6n8bWRrBP9CN7jeueF4=.7ff273a1-2a42-4fea-9e44-ba18d895aef7@github.com>
Message-ID: <Z0MNw-9D1C8zjcbDe12HXswjvK6a9snK72C3GsTlEKc=.621ac45f-e0c1-4cc7-9bf7-e9f574f9e726@github.com>

On Thu, 15 May 2025 10:21:26 GMT, Markus KARG <duke at openjdk.org> wrote:

>>> > Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence...
>>> 
>>> The most simple example is a file server. Incidential fact, just today I wrote a function that simply passes JSON documents received in a REST call forward to another server using another REST call (without parsing it). The document is not changed. It is _inefficient_ to force it into a `String` temporarily. This is not untypical, such use cases exists often in server computing.
>> 
>> Seems to me that in your example `Reader.transferTo(Writer)` would be the better choice instead of reading everything into a String or CharSequence and writing it to the next sink.
>
> If the source is a `Reader` **and** target is a `Writer`, yes. But what if it is a native piece of hardware, like an IoT device, which produces / consumes `CharSequence`?

Also, in JAX-RS for example, you cannot make use of `transferTo` as what you get is a heap object, and what you must forward also is a heap object.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090844002

From duke at openjdk.org  Thu May 15 10:55:54 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 15 May 2025 10:55:54 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <Z0MNw-9D1C8zjcbDe12HXswjvK6a9snK72C3GsTlEKc=.621ac45f-e0c1-4cc7-9bf7-e9f574f9e726@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
 <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>
 <nCFdoAHy2RkNENhaRhdaMDbO3iiAuV-AsirMDJoS0Dc=.0177c4cd-1e71-494f-8956-13edc7eb0551@github.com>
 <BctFVukNg2CVXVsPVF96howIOf-A8N_G-AIClpaqmgE=.53d54891-c098-4922-81c7-ddd0818c647d@github.com>
 <apAsxR7rrX0ofU-2q3GVqq_uWkKTD8u4sw7zKeYCT2k=.c4f73ab2-cc66-4f98-b668-de356b788849@github.com>
 <f9my7Gq_OjkXWTBa2L2h1EFIgMpA5PuFf5xndOfcwlM=.e87667ba-d5eb-48aa-be35-05d52ac81212@github.com>
 <Y2P9dJdshrswViDiOGTS14EdODFTMxF7Z1fyDuiQdsA=.d182371a-d1ad-482f-8ff1-d01d06737a32@github.com>
 <g1GHppLlTaHjuFACIi8dgMvNZfQA81ctofGglGZXAXk=.73477b96-4dd8-45ca-9bae-f3a15d8ce8c1@github.com>
 <cnVCW6f3cE8qRMTn_8PMfPX8NPB8WhEcTJb
 jp_Zz3MY=.a4fe61f7-1a2a-4528-91a9-fde9cae8acfa@github.com>
 <jOzAzf7qiUGaR4AcVxkVruHyXr7-SLNU2pRV_z8iojk=.0c07b2ec-c8e7-4170-84e8-d1baed0afde0@github.com>
 <F6Kjz5iF9Y5R0V8LuRCuX_JtmI6Ohtzksy96kGzDUY8=.a461b9e5-02dd-4226-aced-cf4f910b01b0@github.com>
 <PIGolcNUOTm_uea2SMpu6zMF_8imtmuC_RiCTCTPIvU=.0845a60f-3eab-43cd-8956-9d10fbd5c439@github.com>
 <5ue1HrdcMPaWc9wOSsLvvQaf6n8bWRrBP9CN7jeueF4=.7ff273a1-2a42-4fea-9e44-ba18d895aef7@github.com>
 <Z0MNw-9D1C8zjcbDe12HXswjvK6a9snK72C3GsTlEKc=.621ac45f-e0c1-4cc7-9bf7-e9f574f9e726@github.com>
Message-ID: <aJ9fvCIO__WTmGt8g47BHC5UYpVQhvTVLVuP1RGOjR4=.f4fd111a-bfc3-4295-9f9f-41c9bdf56613@github.com>

On Thu, 15 May 2025 10:22:51 GMT, Markus KARG <duke at openjdk.org> wrote:

>> If the source is a `Reader` **and** target is a `Writer`, yes. But what if it is a native piece of hardware, like an IoT device, which produces / consumes `CharSequence`?
>
> Also, in JAX-RS for example, you cannot make use of `transferTo` as what you get is a heap object, and what you must forward also is a heap object.

Thanks for the examples. Imho I think that performance sensitive, specialised code can invest some lines to put together the best solution for the context whereas the majority of code can simply use a convenient `reader.readAllAsString()` instead of `reader.readAllAsCharSequence().toString()` which is borderline to parody.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090896148

From duke at openjdk.org  Thu May 15 11:03:58 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 15 May 2025 11:03:58 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <aJ9fvCIO__WTmGt8g47BHC5UYpVQhvTVLVuP1RGOjR4=.f4fd111a-bfc3-4295-9f9f-41c9bdf56613@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
 <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>
 <nCFdoAHy2RkNENhaRhdaMDbO3iiAuV-AsirMDJoS0Dc=.0177c4cd-1e71-494f-8956-13edc7eb0551@github.com>
 <BctFVukNg2CVXVsPVF96howIOf-A8N_G-AIClpaqmgE=.53d54891-c098-4922-81c7-ddd0818c647d@github.com>
 <apAsxR7rrX0ofU-2q3GVqq_uWkKTD8u4sw7zKeYCT2k=.c4f73ab2-cc66-4f98-b668-de356b788849@github.com>
 <f9my7Gq_OjkXWTBa2L2h1EFIgMpA5PuFf5xndOfcwlM=.e87667ba-d5eb-48aa-be35-05d52ac81212@github.com>
 <Y2P9dJdshrswViDiOGTS14EdODFTMxF7Z1fyDuiQdsA=.d182371a-d1ad-482f-8ff1-d01d06737a32@github.com>
 <g1GHppLlTaHjuFACIi8dgMvNZfQA81ctofGglGZXAXk=.73477b96-4dd8-45ca-9bae-f3a15d8ce8c1@github.com>
 <cnVCW6f3cE8qRMTn_8PMfPX8NPB8WhEcTJb
 jp_Zz3MY=.a4fe61f7-1a2a-4528-91a9-fde9cae8acfa@github.com>
 <jOzAzf7qiUGaR4AcVxkVruHyXr7-SLNU2pRV_z8iojk=.0c07b2ec-c8e7-4170-84e8-d1baed0afde0@github.com>
 <F6Kjz5iF9Y5R0V8LuRCuX_JtmI6Ohtzksy96kGzDUY8=.a461b9e5-02dd-4226-aced-cf4f910b01b0@github.com>
 <PIGolcNUOTm_uea2SMpu6zMF_8imtmuC_RiCTCTPIvU=.0845a60f-3eab-43cd-8956-9d10fbd5c439@github.com>
 <5ue1HrdcMPaWc9wOSsLvvQaf6n8bWRrBP9CN7jeueF4=.7ff273a1-2a42-4fea-9e44-ba18d895aef7@github.com>
 <Z0MNw-9D1C8zjcbDe12HXswjvK6a9snK72C3GsTlEKc=.621ac45f-e0c1-4cc7-9bf7-e9f574f9e726@github.com>
 <aJ9fvCIO__WTmGt8g47BHC5UYpVQhvTVLVuP1RGOjR4=.f4fd111a-bfc3-4295-9f9f-41c9bdf56613@github.com>
Message-ID: <hGdOD6yiBZLJlqN471s_uxxFaCMnNI_U8mjqEgs3SW8=.ae5e1e63-6618-46f3-a659-020d3b10be3a@github.com>

On Thu, 15 May 2025 10:53:27 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> Also, in JAX-RS for example, you cannot make use of `transferTo` as what you get is a heap object, and what you must forward also is a heap object.
>
> Thanks for the examples. Imho I think that performance sensitive, specialised code can invest some lines to put together the best solution for the context whereas the majority of code can simply use a convenient `reader.readAllAsString()` instead of `reader.readAllAsCharSequence().toString()` which is borderline to parody.

It is **impossible** to "invest some lines" to solve this in JAX-RS, and JAX-RS as a standard technology on tens of thousands of servers. Enforcing `String` prevents these useful optimizations, but brings *no actual benefit*, as *only few* callers actually care for *constant* objects, but would be satisfied with `CharSequence`'s lack of mutation methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090910821

From duke at openjdk.org  Thu May 15 11:13:58 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 15 May 2025 11:13:58 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v3]
In-Reply-To: <sPv6ygOuT7BHCC2wPxSsWszSgeVESvExGcpkXEZPEQs=.a55943ac-25ab-44f0-90d0-1df05d6464a6@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <V_z1LM8NiXvm2IaCKIJHcr-WrAVCc7KVB7eYUjGSszU=.dd1c921c-a20b-471b-8e5f-be63360be0d8@github.com>
 <sPv6ygOuT7BHCC2wPxSsWszSgeVESvExGcpkXEZPEQs=.a55943ac-25ab-44f0-90d0-1df05d6464a6@github.com>
Message-ID: <OJQxoHNIASZTDHsE3TnHQ-Zhq7CV2aOIGKOqJ7Uu9mI=.18338d40-bfbf-4815-8d08-2895576e6f67@github.com>

On Thu, 15 May 2025 09:40:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set
>
> test/jdk/java/io/File/DeleteReadOnly.java line 61:
> 
>> 59:     @Test
>> 60:     @Order(1)
>> 61:     @EnabledOnOs({OS.AIX, OS.LINUX, OS.MAC})
> 
> Have you look at creating a simpler test that doesn't use Order. If you drop DIR and FILE then each test could create the file or directory as needed so there wouldn't be any dependency on order.

If each test method creates needed files and sub directories, then It could be useful to let JUnit create and inject a temporary root directory:

@org.junit.jupiter.api.io.TempDir
private static File testDir;

JUnit will automatically delete it with all content after the test methods have run. (But this can fail if readonly files are encountered).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2090925493

From pminborg at openjdk.org  Thu May 15 12:19:53 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 15 May 2025 12:19:53 GMT
Subject: RFR: 8351230: Collections.synchronizedList returns a list that is
 not thread-safe [v2]
In-Reply-To: <DRxCjR218Sb5Px9jomhYtD8HV-g71CqeJ0Pei-xYsBk=.def444b8-bf73-44f4-85d0-3750774b9be6@github.com>
References: <HtBkFlpJ7N3BjMiDZcA2LgM0YOEkd4L1_6XKIPJwwew=.6325e6ba-153e-43c6-9de6-ab00c1e972ed@github.com>
 <DRxCjR218Sb5Px9jomhYtD8HV-g71CqeJ0Pei-xYsBk=.def444b8-bf73-44f4-85d0-3750774b9be6@github.com>
Message-ID: <gd0qhk7C0xp6JN808P3nHA3bCi2eNE3Xj7Nb3_HZEd4=.8c45c363-3ca8-409a-8773-2a9dccbb0063@github.com>

On Mon, 5 May 2025 23:36:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper:
>> 
>> - overrides and adds locking to SequencedCollection methods;
>> - performs instance management of reversed synchronized views;
>> - adds test for race conditions and functional tests of synchronized wrappers.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reversed view of SynchronizedRandomAccessList should also be RandomAccess.
>   Add tests to ensure RandomAccess is preserved when reversing.

src/java.base/share/classes/java/util/Collections.java line 2782:

> 2780:             synchronized (mutex) {list.sort(c);}
> 2781:         }
> 2782:         public void addFirst(E element) {

Are these overloads strictly needed as the `default` implementations will delegate to `get` and `set`, which, in turn, are thread safe?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24990#discussion_r2091040080

From rgiulietti at openjdk.org  Thu May 15 12:35:51 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 15 May 2025 12:35:51 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <bffWy8H4d6xnje0Gz_jIyv5jPBMuqp7S-iBFZTioTng=.7ee33246-76c2-470f-b608-894b5ba93988@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
 <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
 <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>
 <bffWy8H4d6xnje0Gz_jIyv5jPBMuqp7S-iBFZTioTng=.7ee33246-76c2-470f-b608-894b5ba93988@github.com>
Message-ID: <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com>

On Thu, 15 May 2025 09:17:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> So, this exactly reverses what was done in the fix for JDK-8301991
>> 
>> No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences.
>> 
>> This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space.
>> 
>> Technically, it might be that some of these lines in the properties files are reversals of JDK-8301991, but that's just basically coincidence.
>
>> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?
> 
> That seems unlikely. The pattern is used consistently in the French translations, where `Foo:` in the original is replaced with `Foo :` with a non-breaking space. I guess it is a French orthographic rule to have a space before the colon, and I understand why it really must be non-breaking in that case.

FYI, the style guide for France [recommends](https://fr.wikipedia.org/wiki/Espace_ins%C3%A9cable#En_France):

- U+202F (Narrow No-Break Space NNBSP) preceding semicolon, question mark, and exclamation mark.
- U+00A0 (No-Break Space NBSP) preceding colon.

Similar conventions are used in other French speaking countries.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2091068610

From erikj at openjdk.org  Thu May 15 13:06:59 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 15 May 2025 13:06:59 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v9]
In-Reply-To: <NjDSKx8H8J7YgaFo-vFE3viHTuRYRdFnH6TP8NCtk9c=.822fc1df-dba7-4209-9be5-ccab4ad9ae95@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <NjDSKx8H8J7YgaFo-vFE3viHTuRYRdFnH6TP8NCtk9c=.822fc1df-dba7-4209-9be5-ccab4ad9ae95@github.com>
Message-ID: <pd-H1cW6VcRXOGwAx5PuOU7r3gUwkij-4FBh1Sm9g-g=.e3aa016c-07b2-4cf0-8464-27fffbf85667@github.com>

On Thu, 15 May 2025 03:23:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>> 
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
>> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
>> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
>> 
>> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
>> 
>> Examples:
>> 
>> 
>> # Create an AOT cache with a single command:
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> Hello World
>> Temporary AOTConfiguration recorded: foo.aot.config
>> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
>> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create
>> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
>> AOTCache creation is complete: foo.aot 10240000 bytes
>> 
>> # Create logging file for the AOT cache assembly phase
>> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> 
>> 
>> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - @vnkozlov comments
>  - added info about JTREG/AOT_JDK testing
>  - fixed whitespace
>  - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
>  - java.md updates from @rose00
>  - Resolved differences with CSR JDK-8356010
>  - Added param to makefile function SetupAOT for choosing onestep vs twostep
>  - Allow one-step training even when -XX:AOTMode=auto is specified
>  - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
>  - Update java man page
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/5e50a584...7f4c0e8b

doc/testing.md line 619:

> 617: run existing jtreg test cases in a special "AOT_JDK" mode. Example:
> 618: 
> 619: 

Is this extra newline intentional?

doc/testing.md line 629:

> 627: these classes (such as pre-linked lambda expressions, execution profiles, and pre-generated native code)
> 628: are stored into an AOT cache file, which will be used by all the JVMs launched by the selected jtreg
> 629: test cases.

Some of these lines are >80 chars. Can you try to format line lengths in this file to stay under where reasonably feasible? It's ok if long markups such as links go over, just try to keep the normal text adhering to this.

doc/testing.md line 640:

> 638: Also, test cases that were written specifically to test AOT, such as the tests
> 639: under [test/hotspot/jtreg/runtime/cds](../test/hotspot/jtreg/runtime/cds/), cannot
> 640: be execute with the AOT_JDK mode.

Suggestion:

be executed with the AOT_JDK mode.

doc/testing.md line 642:

> 640: be execute with the AOT_JDK mode.
> 641: 
> 642: Valid values for `AOT_JDK` are `one_step` and `two_step`. These control how

Looks like the values are `onestep` and `twostep` in the makefile.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2091117516
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2091125422
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2091121317
PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2091122470

From rgiulietti at openjdk.org  Thu May 15 13:38:06 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 15 May 2025 13:38:06 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v4]
In-Reply-To: <unfCvv2iS9xglcyjhWCVSGlQYD6AwuZMnuK9KlIWXEw=.3bc6df4b-1340-4fa4-b4b9-65d17a13dabb@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <unfCvv2iS9xglcyjhWCVSGlQYD6AwuZMnuK9KlIWXEw=.3bc6df4b-1340-4fa4-b4b9-65d17a13dabb@github.com>
Message-ID: <p9uRw4vt00bAjzP6msteSvD53uRKDke9JdrLS8sjr10=.288901db-e947-4c68-ac27-b402d27e49a4@github.com>

On Tue, 13 May 2025 21:24:08 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update names

Since you are at it, I'd suggest changing `javaIncrement` to be `static` (no need to change access).

Also, if you find remnants of C-style array notation, like `int newMag[]`, it would be nice to have them as `int[] newMag`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2883843995

From duke at openjdk.org  Thu May 15 13:43:53 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 15 May 2025 13:43:53 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v4]
In-Reply-To: <p9uRw4vt00bAjzP6msteSvD53uRKDke9JdrLS8sjr10=.288901db-e947-4c68-ac27-b402d27e49a4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <unfCvv2iS9xglcyjhWCVSGlQYD6AwuZMnuK9KlIWXEw=.3bc6df4b-1340-4fa4-b4b9-65d17a13dabb@github.com>
 <p9uRw4vt00bAjzP6msteSvD53uRKDke9JdrLS8sjr10=.288901db-e947-4c68-ac27-b402d27e49a4@github.com>
Message-ID: <Zi7XHaQGX1mxomET5_xjvKf6GJ8IEvPEs9Y-9EZX1y4=.bb280667-68f4-44b6-b138-a893f468b617@github.com>

On Thu, 15 May 2025 13:35:29 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update names
>
> Since you are at it, I'd suggest changing `javaIncrement` to be `static` (no need to change access).
> 
> Also, if you find remnants of C-style array notation, like `int newMag[]`, it would be nice to have them as `int[] newMag`.

@rgiulietti And what about the [suggestion](https://github.com/openjdk/jdk/pull/25166#discussion_r2083561722) of @liach?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2883862016

From rgiulietti at openjdk.org  Thu May 15 13:53:51 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 15 May 2025 13:53:51 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v4]
In-Reply-To: <unfCvv2iS9xglcyjhWCVSGlQYD6AwuZMnuK9KlIWXEw=.3bc6df4b-1340-4fa4-b4b9-65d17a13dabb@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <unfCvv2iS9xglcyjhWCVSGlQYD6AwuZMnuK9KlIWXEw=.3bc6df4b-1340-4fa4-b4b9-65d17a13dabb@github.com>
Message-ID: <bFoyUQURp78_Yg2PfWG9R4skDUWo6Oujpc4iCp8hUN4=.62635bad-6293-4a7b-be88-cc757cb16b8a@github.com>

On Tue, 13 May 2025 21:24:08 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update names

I agree renaming it `magBitLength` and having just the `int[]` as parameter.
It cannot be made an instance method, though. There's one usage which needs a static invocation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2883894295

From vyazici at openjdk.org  Thu May 15 14:01:57 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 15 May 2025 14:01:57 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v7]
In-Reply-To: <RAcEfEBZgn1o13wOeDQi9KG7s8koI8uizmFVGhqw0sk=.f65f7f8a-b8cf-4bbe-9dbd-8838e92453c6@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <RAcEfEBZgn1o13wOeDQi9KG7s8koI8uizmFVGhqw0sk=.f65f7f8a-b8cf-4bbe-9dbd-8838e92453c6@github.com>
Message-ID: <6NeDdpJHPkF7E3zioEtxyeVC1fX4FT2w38VbpJg5BUA=.6c1d39fd-a07b-49b0-8303-36f65aec17f3@github.com>

On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request with a new target base 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:
> 
>  - Merge remote-tracking branch 'upstream/master' into jla
>  - Improve `uncheckedGetBytesNoRepl` docs
>  - Apply suggestions from code review
>    
>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>  - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
>  - Fix `HexDigits` copyright year
>  - Fix copyright years
>  - Prefix touched methods with `unchecked`
>  - Fix typo in pre-existing JavaDoc
>  - Improve `JavaLangAccess` documentation

Green `tier1,2` results are attached to ticket.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24982#issuecomment-2883918329

From duke at openjdk.org  Thu May 15 14:01:58 2025
From: duke at openjdk.org (duke)
Date: Thu, 15 May 2025 14:01:58 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v7]
In-Reply-To: <RAcEfEBZgn1o13wOeDQi9KG7s8koI8uizmFVGhqw0sk=.f65f7f8a-b8cf-4bbe-9dbd-8838e92453c6@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <RAcEfEBZgn1o13wOeDQi9KG7s8koI8uizmFVGhqw0sk=.f65f7f8a-b8cf-4bbe-9dbd-8838e92453c6@github.com>
Message-ID: <Xp1TwgmS81WpMbGxWutS0XxW6v752DFqXhNGYQyhmUs=.732d0fec-2063-4d13-8d4d-7ffca9f21e63@github.com>

On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request with a new target base 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:
> 
>  - Merge remote-tracking branch 'upstream/master' into jla
>  - Improve `uncheckedGetBytesNoRepl` docs
>  - Apply suggestions from code review
>    
>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>  - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
>  - Fix `HexDigits` copyright year
>  - Fix copyright years
>  - Prefix touched methods with `unchecked`
>  - Fix typo in pre-existing JavaDoc
>  - Improve `JavaLangAccess` documentation

@vy 
Your change (at version 0e06ce1d028ce2fef5705e59d9245fcaa93abcd9) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24982#issuecomment-2883921694

From archie.cobbs at gmail.com  Thu May 15 14:04:22 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 15 May 2025 09:04:22 -0500
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: <7dbee86b-b80e-4827-aaa9-603d5e6d3402@gmail.com>
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 <d9fdd1b1-67e5-45d7-b7a6-a07ed771bba3@oracle.com>
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 <A8899F82-5CB0-44B8-AF34-6D3EF5A77CC3@oracle.com>
 <a5120cdf1d5946c9add0a1c615f6440c@amazon.com>
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 <aa7fabbb-94e3-4510-b20c-b1ed7518858a@oracle.com>
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
 <CABe8uE0W81CY7Acas0fm9ZMpMW4R+oPbhkwpdDW9TEXhSEJf-g@mail.gmail.com>
 <CANSoFxuJZZtd0PCTmCz4CJDg0kAHU0Ldj19E0VRtmOiqVHkVFQ@mail.gmail.com>
 <e132ab48b8df4246b9a8c91a8c1ec0ff@amazon.com>
 <4741eceb3beb40c2bc82613c67836d66@amazon.com>
 <CANSoFxsZ0AV96KggvSCOW4T80B55HrdBWOP67PQKpgbMpszcsw@mail.gmail.com>
 <CANSoFxu75tpy_kq9T-a3fDz5dZ-k+qhtJO8LoYxxWRO-SRXE6A@mail.gmail.com>
 <95335d21438d4826a87db616b65d9ec9@amazon.com>
 <CANSoFxs181gROMY90tYy5mg2rWzwFrJZX=tH2WRtX=Cy6bUiZw@mail.gmail.com>
 <7dbee86b-b80e-4827-aaa9-603d5e6d3402@gmail.com>
Message-ID: <CANSoFxu71=LHLmKcdrwkGagEmbm=1ngZZG5QqP63AGKfLtsMGQ@mail.gmail.com>

On Thu, May 15, 2025 at 2:02?AM Peter Levart <peter.levart at gmail.com> wrote:

> On 4/11/25 6:19 PM, Archie Cobbs wrote:
> > 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.
>
> You can have power-of-two exponentially growing segments and still
> access individual elements by index in constant time...


Good point! There are more clever ways to size the chunks that still retain
constant time access.

What I would love to see someday is all of this kind of cleverness baked
into a standard set of "ArrayBuilder" classes, so we can then declare
victory for cleverness and never have to worry about the fastest way to
buffer data into memory again. Then we could focus our optimization efforts
just on those classes, and the users of those classes all over the JDK
(e.g., ArrayList, StringBuilder, whatever) would automatically benefit.

This might be a pipe dream. At least, it brings up an interesting question
re: how you would design such a thing... e.g., how would you parameterize
it? E.g., Initial chunk size, maximum chunk size, growth rate exponent,
etc. Or could it be truly adaptive (one (initial) size fits all)? Etc.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250515/fbf879f6/attachment.htm>

From duke at openjdk.org  Thu May 15 14:05:01 2025
From: duke at openjdk.org (Abhishek N)
Date: Thu, 15 May 2025 14:05:01 GMT
Subject: RFR: 8355393: Create a Test case to have special cases coverage
 for currency.getInstance() [v2]
In-Reply-To: <ajlqyimXKCirhh8qg0TP5wCaW-yoHzXpPD3zqsyvBmw=.d88ad90e-d619-422a-93f6-45c8218a50d3@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
 <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>
 <ajlqyimXKCirhh8qg0TP5wCaW-yoHzXpPD3zqsyvBmw=.d88ad90e-d619-422a-93f6-45c8218a50d3@github.com>
Message-ID: <mqVsj8OZBBanAsq-CwEPC1avTw4wHw70WZVuy8qTb-A=.9a71bab3-af6d-4b08-8185-adf78504c046@github.com>

On Mon, 12 May 2025 23:24:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Abhishek N has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   correcting jtreg header order, add meaningful comments for each test methods and properties file
>
> Hi @abhn-git, I think it would be beneficial if we first addressed the concerns raised before continuing work on this PR. [JDK-8355393](https://bugs.openjdk.org/browse/JDK-8355393) assigned to you and [JDK-8355045](https://bugs.openjdk.org/browse/JDK-8355045) assigned to @weibxiao  appear to be duplicates.

Hi @justin-curtis-lu @weibxiao 

The main cause for failure in https://bugs.openjdk.org/browse/JDK-8353433  is that "currency cut-over date functionality was broken for the Currency.getInstance(String currencyCode, int defaultFractionDigits, int numericCode)" call and the currency 8u code threw illegalArguementException for new Currency after cut-over time was passed by System.

Example: 
"CW=ANG;2025-04-01-04-00-00;XCG"
-> After System time passed 1st April 2025 4:00 am, Currency.getInstance(XCG) -> throw illegalArguementException

Please note the issue could not be caught earlier and was caught only after System time passed the cut over time. 

So to prevent such miss in future, we have to write tests to check that after System time has passed cut over time the expected new currency instance is returned by both Currency.getInstance methods.

This can be achieved by two ways 
1. To mock System time to be after cut over time and see if Currency.getInstance is working as expected.
2. **To perform Currency overriding mechanism via the system property, where a modified currencies.properties file is set and it has entries for currencies whose cut over time is passed. And we write tests to verify both Currency.getInstance() methods and it has to return values as required.**

The test written in this PR does option 2

Example: In our modified currencies.properties file we have below entry

SX=ANG,532,2,2025-04-22T00:00:00

So, the test code ensures that since System time is past the cut over time the Currency.getInstance(new Locale("SX")) and Currency.getInstance("ANG") should return values as expected (expected values are in CurrencyList.txt).

And if new currencies are added in future with cut over timeconditions it should work properly once the System time passes cut over time ,provided our test in above PR is Passing.


The test written in this PR does option 2. and works fine for all the release.

@justin-curtis-lu @weibxiao please let me know if there are any issues with this test fix.

thank you

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2883930487

From duke at openjdk.org  Thu May 15 14:05:01 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 15 May 2025 14:05:01 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v4]
In-Reply-To: <bFoyUQURp78_Yg2PfWG9R4skDUWo6Oujpc4iCp8hUN4=.62635bad-6293-4a7b-be88-cc757cb16b8a@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <unfCvv2iS9xglcyjhWCVSGlQYD6AwuZMnuK9KlIWXEw=.3bc6df4b-1340-4fa4-b4b9-65d17a13dabb@github.com>
 <bFoyUQURp78_Yg2PfWG9R4skDUWo6Oujpc4iCp8hUN4=.62635bad-6293-4a7b-be88-cc757cb16b8a@github.com>
Message-ID: <d_loI6Pb62ryM970hGwkZ-r5eMBgPNHdDWE9ABbbG3c=.ac98bd2e-f580-499c-988d-927c2e587a9a@github.com>

On Thu, 15 May 2025 13:51:29 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> It cannot be made an instance method, though. There's one usage which needs a static invocation.

@rgiulietti If you are referring to [this invocation](https://github.com/fabioromano1/jdk/blob/5ad26a14049e1765d9ef46f307d723dd4b315382/src/java.base/share/classes/java/math/BigInteger.java#L3126), the local variable `exp` is just an alias of `y.mag`, so it can be made an instance invocation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2883932854

From rgiulietti at openjdk.org  Thu May 15 14:07:56 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 15 May 2025 14:07:56 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v4]
In-Reply-To: <unfCvv2iS9xglcyjhWCVSGlQYD6AwuZMnuK9KlIWXEw=.3bc6df4b-1340-4fa4-b4b9-65d17a13dabb@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <unfCvv2iS9xglcyjhWCVSGlQYD6AwuZMnuK9KlIWXEw=.3bc6df4b-1340-4fa4-b4b9-65d17a13dabb@github.com>
Message-ID: <MUcYSp7t__UHjexBDACaXkJ-4fuPudjtiNJUsyis1Uo=.0b265be6-b3a9-4523-8371-542d051db125@github.com>

On Tue, 13 May 2025 21:24:08 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update names

Right.
Let's go with an instance method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2883943091

From duke at openjdk.org  Thu May 15 14:08:04 2025
From: duke at openjdk.org (duke)
Date: Thu, 15 May 2025 14:08:04 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v12]
In-Reply-To: <JoyEhrXuHQMMjc5wSmogN0045YycfgZbi1YkpP3Ef8g=.ba201c18-7077-451a-b4b9-adafa9278b7f@github.com>
References: <AdBmCAbqhjQEP05JBlXhp21hKuxn7SAb7h0Y3Wvollk=.21c0e6fe-097e-41e4-afa3-45b108112a28@github.com>
 <JoyEhrXuHQMMjc5wSmogN0045YycfgZbi1YkpP3Ef8g=.ba201c18-7077-451a-b4b9-adafa9278b7f@github.com>
Message-ID: <SavlOMppOMYs4CMnstZ6dcSAcOttn6ZLJCGdq_vzNds=.95a468bd-edac-4bd9-8002-bceda7b48c45@github.com>

On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin <tpushkin at openjdk.org> 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:
> 
>   Make supertype obstruction check easier to understand

@TimPushkin 
Your change (at version a3b7dd962a0b5ee32395c2b08232bf1cbd0ef0f9) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2883940576

From acobbs at openjdk.org  Thu May 15 14:14:59 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 15 May 2025 14:14:59 GMT
Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for()
 loops
In-Reply-To: <Rv2vKh5toqVwWE2NVPuVJDXP3zyokifv9JMMmEy3p38=.81fc91b9-205b-43b9-be1c-9222db3dbffb@github.com>
References: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
 <Rv2vKh5toqVwWE2NVPuVJDXP3zyokifv9JMMmEy3p38=.81fc91b9-205b-43b9-be1c-9222db3dbffb@github.com>
Message-ID: <OpINNnfz4n5Sh5xbPeW4fAteATLqRA7uD7TWCXUadwE=.5fa00ef7-eee5-4bd7-93a8-400fd93cf0e9@github.com>

On Thu, 15 May 2025 06:07:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Are you planning to add some JMH benchmarks to go with this?

I wasn't planning to, but I'm inferring from your question that you'd prefer to see one.

Which also makes me curious. I'd be shocked if this were slower, but even if not, I wonder how much faster it would be.

I will work on creating one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25237#issuecomment-2883965303

From duke at openjdk.org  Thu May 15 14:15:29 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 15 May 2025 14:15:29 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v5]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <pR2aBm-06HDOLA0zIBfRbzu0VH_2EwYD_DhhnnOeK-U=.e4bf5cdf-247b-4bae-a581-ec95b7577cba@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Make javaIncrement(int[]) static

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/5ad26a14..d0df9eb2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From rriggs at openjdk.org  Thu May 15 14:48:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 15 May 2025 14:48:54 GMT
Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for()
 loops
In-Reply-To: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
References: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
Message-ID: <YXiO88GrbzDU0vf0uZFgJjS_SMhUWSxJMp_W96lj2Qk=.fb4a3bf0-2490-4f88-89cb-cbcc779d0d3e@github.com>

On Wed, 14 May 2025 19:37:37 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this small performance tweak `ArrayDeque`.
> 
> `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead.

I'm curious to know whether C2 turns the loop into a vectorized operation.  The Arrays.fill might be more expressive, but not necessarily faster.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25237#issuecomment-2884095477

From liach at openjdk.org  Thu May 15 14:57:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 15 May 2025 14:57:05 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v7]
In-Reply-To: <RAcEfEBZgn1o13wOeDQi9KG7s8koI8uizmFVGhqw0sk=.f65f7f8a-b8cf-4bbe-9dbd-8838e92453c6@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
 <RAcEfEBZgn1o13wOeDQi9KG7s8koI8uizmFVGhqw0sk=.f65f7f8a-b8cf-4bbe-9dbd-8838e92453c6@github.com>
Message-ID: <QYcJs7Z_IIvZH5zn8awJYON4RsXYclB4RheOt-F4jqA=.16477fc7-9179-4022-9e40-c037518c8b9b@github.com>

On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request with a new target base 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:
> 
>  - Merge remote-tracking branch 'upstream/master' into jla
>  - Improve `uncheckedGetBytesNoRepl` docs
>  - Apply suggestions from code review
>    
>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>  - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
>  - Fix `HexDigits` copyright year
>  - Fix copyright years
>  - Prefix touched methods with `unchecked`
>  - Fix typo in pre-existing JavaDoc
>  - Improve `JavaLangAccess` documentation

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24982#issuecomment-2884130126

From vyazici at openjdk.org  Thu May 15 14:57:05 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 15 May 2025 14:57:05 GMT
Subject: Integrated: 8353197: Document preconditions for JavaLangAccess methods
In-Reply-To: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
References: <YB3HxIxNat9UEmDDd-t_TSjb0K7Qf18BwhCkjqhZtEk=.302f943a-9b51-42ad-b95d-29a5eb392a9e@github.com>
Message-ID: <83yYC2PGBDztvGXa1rA5Jrt561lI1FiaEBk3EaauueM=.a287f882-4ec9-47b0-9e08-67b29982dbb8@github.com>

On Thu, 1 May 2025 05:33:29 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.

This pull request has now been integrated.

Changeset: 8fcfddb2
Author:    Volkan Yazici <vyazici at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8fcfddb2d202cdb61941efdb3fec5807fee98c33
Stats:     124 lines in 22 files changed: 23 ins; 3 del; 98 mod

8353197: Document preconditions for JavaLangAccess methods

Reviewed-by: pminborg, liach

-------------

PR: https://git.openjdk.org/jdk/pull/24982

From duke at openjdk.org  Thu May 15 15:37:39 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 15 May 2025 15:37:39 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v6]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <Fe1FcysTPgZYA1aEUGFHRfBxnQ_QkYXJ-4it0QscrS8=.7c1fa510-c570-481c-aa40-5cca05667f34@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  make magBitLength() an instance method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/d0df9eb2..642461fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=04-05

  Stats: 36 lines in 1 file changed: 7 ins; 10 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From mseledtsov at openjdk.org  Thu May 15 15:48:52 2025
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Thu, 15 May 2025 15:48:52 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v5]
In-Reply-To: <U7dpc8IRZHFCXm8OJTMkrmNNuVbEXCzwWctZxiMj1gU=.b66cd9dd-74ad-4c65-9c5d-1a915d43fada@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <U7dpc8IRZHFCXm8OJTMkrmNNuVbEXCzwWctZxiMj1gU=.b66cd9dd-74ad-4c65-9c5d-1a915d43fada@github.com>
Message-ID: <tHaAkBxd-wA6r3knfmJK7GBq4azS5MjY8-AWl8ALNBU=.ed8f12f6-7b33-47b1-88e9-7ab98b20ba7c@github.com>

On Thu, 15 May 2025 10:03:11 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused import

Marked as reviewed by mseledtsov (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24948#pullrequestreview-2844233145

From aph at openjdk.org  Thu May 15 15:52:14 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 15 May 2025 15:52:14 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v7]
In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
Message-ID: <Pk1doAjksx6zaLX38rimtFplr0OvzUbOpU6SHBVWVP0=.73c0601b-6888-4abb-bb2a-d8c3226badaa@github.com>

> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
> 
> 
> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Delete unused label

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25147/files
  - new: https://git.openjdk.org/jdk/pull/25147/files/e5771988..da574ccb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=05-06

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25147/head:pull/25147

PR: https://git.openjdk.org/jdk/pull/25147

From aph at openjdk.org  Thu May 15 15:52:14 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 15 May 2025 15:52:14 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v6]
In-Reply-To: <BJ48hkafKoSbonxesNQ-wKfLj6iIjxo0omp22ws8LMI=.9968a1e7-5893-47e6-a6d5-5684e1ba52e2@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
 <pLVddIXTpvroWRu-iYVzlqCAzvwmXViE7LuVZ4fSx0U=.d0c8dcef-740f-4113-aef3-194ebd2b78bf@github.com>
 <BJ48hkafKoSbonxesNQ-wKfLj6iIjxo0omp22ws8LMI=.9968a1e7-5893-47e6-a6d5-5684e1ba52e2@github.com>
Message-ID: <TBfS3Xd2SJoxOyv5kSILVzxyT1EZyQ6PX-_2K1OlDVU=.9ca3a268-54cf-47e8-9e18-206ee2f1eda3@github.com>

On Wed, 14 May 2025 15:36:32 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Looks good to me.

Sorry, please approve again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2884310593

From bpb at openjdk.org  Thu May 15 15:54:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 15 May 2025 15:54:53 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v3]
In-Reply-To: <OJQxoHNIASZTDHsE3TnHQ-Zhq7CV2aOIGKOqJ7Uu9mI=.18338d40-bfbf-4815-8d08-2895576e6f67@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <V_z1LM8NiXvm2IaCKIJHcr-WrAVCc7KVB7eYUjGSszU=.dd1c921c-a20b-471b-8e5f-be63360be0d8@github.com>
 <sPv6ygOuT7BHCC2wPxSsWszSgeVESvExGcpkXEZPEQs=.a55943ac-25ab-44f0-90d0-1df05d6464a6@github.com>
 <OJQxoHNIASZTDHsE3TnHQ-Zhq7CV2aOIGKOqJ7Uu9mI=.18338d40-bfbf-4815-8d08-2895576e6f67@github.com>
Message-ID: <92OaTIqTXS4w5ePqmjBG7ONU82fcDYGCw5jSmt8M-eI=.0b055f31-0e97-41f4-b0dd-2a473f9ee2b0@github.com>

On Thu, 15 May 2025 11:11:06 GMT, Johannes D?bler <duke at openjdk.org> wrote:

> [I]t could be useful to let JUnit create and inject a temporary root directory [...]

I am not sure about this. The temporary file path created by JUnit, on macOS at least, is in a different directory hierarchy (`/var/...`) from the jtreg work directory (`/tmp/...`) so jtreg's own cleanup phase might not remove files if there are any straggling.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2091502403

From aph at openjdk.org  Thu May 15 16:03:44 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 15 May 2025 16:03:44 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v8]
In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
Message-ID: <PmF5hPmcrk43l3WpNEGxcCyu9zm-mamNvVod4TUMMZk=.223a6c62-a53f-4094-8f3b-2a094dc3425a@github.com>

> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
> 
> 
> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Copyright format correction

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25147/files
  - new: https://git.openjdk.org/jdk/pull/25147/files/da574ccb..283b900e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25147&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25147/head:pull/25147

PR: https://git.openjdk.org/jdk/pull/25147

From rgiulietti at openjdk.org  Thu May 15 16:24:54 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 15 May 2025 16:24:54 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double) [v4]
In-Reply-To: <8zqr6fizVQmLTiJiKm1Qt5dwE6wtPxXNpqIonMWwtuA=.bc2f8ec3-7fab-49f5-95ab-d6f15812c842@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
 <8zqr6fizVQmLTiJiKm1Qt5dwE6wtPxXNpqIonMWwtuA=.bc2f8ec3-7fab-49f5-95ab-d6f15812c842@github.com>
Message-ID: <SGW1VPQDvy3EqArKaQjaenBEesiUTPGiqAMYyToVqf0=.0d79dd46-8a80-4ee9-bf31-f378070646db@github.com>

On Wed, 14 May 2025 14:39:37 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.
>
> Johannes Graham has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java
>    
>    Align better with spec
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java
>    
>    Better alignment with spec
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java
>    
>    Add another final
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>

Marked as reviewed by rgiulietti (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25173#pullrequestreview-2844337861

From duke at openjdk.org  Thu May 15 16:27:53 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 15 May 2025 16:27:53 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double)
In-Reply-To: <GiGj_Q_kQHbDHfmlgJDxdADvEwJZ_t2lMkZAUKfu2LY=.1df90c7f-7b47-41f1-987c-5db459204d4c@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
 <GiGj_Q_kQHbDHfmlgJDxdADvEwJZ_t2lMkZAUKfu2LY=.1df90c7f-7b47-41f1-987c-5db459204d4c@github.com>
Message-ID: <TPjoy6D5oMMEbd2AUPXX6L972t_pgeULwOzLXTr-oZI=.54323b5d-c53f-4944-9d74-5a099ebbbaef@github.com>

On Mon, 12 May 2025 02:06:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.
>
> Sorry, didn't see your core-libs-dev mail. Created an issue for you at https://bugs.openjdk.org/browse/JDK-8356709

Thank you @liach @rgiulietti and @jddarcy

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25173#issuecomment-2884410316

From duke at openjdk.org  Thu May 15 16:27:54 2025
From: duke at openjdk.org (duke)
Date: Thu, 15 May 2025 16:27:54 GMT
Subject: RFR: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double) [v4]
In-Reply-To: <8zqr6fizVQmLTiJiKm1Qt5dwE6wtPxXNpqIonMWwtuA=.bc2f8ec3-7fab-49f5-95ab-d6f15812c842@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
 <8zqr6fizVQmLTiJiKm1Qt5dwE6wtPxXNpqIonMWwtuA=.bc2f8ec3-7fab-49f5-95ab-d6f15812c842@github.com>
Message-ID: <cEd0ZxmeE9m1c0KAIX92m16q47vJX63HiZMoAzzo-WE=.c4f2dd86-5a79-4f2b-a0aa-b3637215f7d8@github.com>

On Wed, 14 May 2025 14:39:37 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.
>
> Johannes Graham has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java
>    
>    Align better with spec
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java
>    
>    Better alignment with spec
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - Update src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java
>    
>    Add another final
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>

@j3graham 
Your change (at version 0cc32fc02afc461ae3a161011e32c339b4e44241) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25173#issuecomment-2884411223

From lmesnik at openjdk.org  Thu May 15 16:29:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 15 May 2025 16:29:13 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v5]
In-Reply-To: <U7dpc8IRZHFCXm8OJTMkrmNNuVbEXCzwWctZxiMj1gU=.b66cd9dd-74ad-4c65-9c5d-1a915d43fada@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <U7dpc8IRZHFCXm8OJTMkrmNNuVbEXCzwWctZxiMj1gU=.b66cd9dd-74ad-4c65-9c5d-1a915d43fada@github.com>
Message-ID: <F-9h51qLUK9yyhVSh34kmS777BKVrfRJnrotkrFDhv0=.e78360fa-0fb3-4814-bbfd-2b54dfff0503@github.com>

On Thu, 15 May 2025 10:03:11 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused import

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 73:

> 71:             return;
> 72:         }
> 73:         if (IS_DOCKER && ContainerRuntimeVersionTestUtils.DOCKER_VERSION_20_10_0.compareTo(ContainerRuntimeVersionTestUtils.getContainerRuntimeVersion()) > 0) {

Better to replace this with 
`isContainerVersionSupported()`
...
and implement all logic in the the ContainerRuntimeVersionTestUtils

test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 38:

> 36:     private final int micro;
> 37:     private static final ContainerRuntimeVersionTestUtils DEFAULT = new ContainerRuntimeVersionTestUtils(0, 0, 0);
> 38:     public static final ContainerRuntimeVersionTestUtils DOCKER_VERSION_20_10_0 = new ContainerRuntimeVersionTestUtils(20, 10, 0);

Please add comment about meaning of the version or even better rename 
DOCKER_MINIMAL_SUPPORTED_VERSION = ....

test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 53:

> 51:         } else if (this.major < other.major) {
> 52:             return -1;
> 53:         } else { // equal major

no need to add `else {` here

test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 58:

> 56:             } else if (this.minor < other.minor) {
> 57:                 return -1;
> 58:             } else { // equal majors and minors

no need to add `else {` here

test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 81:

> 79:         } catch (Exception e) {
> 80:             System.out.println("Failed to parse container runtime version: " + version);
> 81:             return DEFAULT;

Any reason to don't fail here?

test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 94:

> 92:         } catch (Exception e) {
> 93:             System.out.println(Container.ENGINE_COMMAND + " --version command failed. Returning null");
> 94:             return null;

Any reason to don't fail here?

-------------

PR Review: https://git.openjdk.org/jdk/pull/24948#pullrequestreview-2844326936
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091561369
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091564985
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091555059
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091555200
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091567641
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091566692

From duke at openjdk.org  Thu May 15 16:37:05 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 15 May 2025 16:37:05 GMT
Subject: Integrated: 8356709: Avoid redundant String formatting in
 BigDecimal.valueOf(double)
In-Reply-To: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
References: <dFYTos9TLp_iQotJG5FHakZk5G6yiRd-ArJPeMip2VY=.c85d72a7-2591-4726-94b3-0718230e6c9f@github.com>
Message-ID: <LJNDrTf_9cn4_lkQcv_M6A4wuAgdz-EPvrjR_-wS0I8=.d1ad57b2-56f5-432b-9d76-376e2cb41f19@github.com>

On Sun, 11 May 2025 16:22:11 GMT, Johannes Graham <duke at openjdk.org> wrote:

> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of converting to decimal string and then parsing it. This results in an approximate 6x improvement for me.

This pull request has now been integrated.

Changeset: 1e61352b
Author:    Johannes Graham <j3graham at gmail.com>
Committer: Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e61352b54e1ac85fbc6b54a7a29e8782dd42d2c
Stats:     178 lines in 4 files changed: 169 ins; 1 del; 8 mod

8356709: Avoid redundant String formatting in BigDecimal.valueOf(double)

Reviewed-by: rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/25173

From stuefe at openjdk.org  Thu May 15 16:40:57 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 15 May 2025 16:40:57 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v4]
In-Reply-To: <Z_KwF-bTUlOHcuVojdoqgIb0ItX8JJqvQhEwkoH2ShU=.dce96556-edde-4a47-a931-13b251369d32@github.com>
References: <QFQbE9Prk6RCHyldCEPpN4V4r3syE-uwP12mOK5WFXE=.6e6f4145-58cf-4eed-b251-a771fefdae24@github.com>
 <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
 <YoHw-NBBOF6dHnbNX2nlxarBy1jnHdHUhuSEZlcSp_k=.536fcce1-7010-461f-a934-52505f473170@github.com>
 <SDkQonj1CXwsIBXyyO_M3mYj25kA3ya9nhDa4Fw-Y7M=.a2776cde-7544-4972-89c0-d289838ad714@github.com>
 <9qD9glLPCTy_6ium5mvzyjhZ56COlEOKz4AhzvGmhrg=.ff5d52e1-84a1-413c-aac0-873fdcbfa5ff@github.com>
 <l8DneNJ4KUmd_8M5VhnbbMN27lVUao1mKrzZ28oeGGI=.acefca04-d2e0-465e-8168-5ccc2f16daca@github.com>
 <Z_KwF-bTUlOHcuVojdoqgIb0ItX8JJqvQhEwkoH2ShU=.dce96556-edde-4a47-a931-13b251369d32@github.com>
Message-ID: <iF63egS9i8293ZLebDU23CbMjwAgeZm3QGjh5cLPf6o=.0669d796-98ce-4d02-b238-379662b16044@github.com>

On Wed, 14 May 2025 00:32:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hmm, glibc keeps it very vague in the vfork() manpage, stating that "On some implementations, vfork() is equivalent to fork()." AIX manpage says just "The vfork subroutine is supported as a compatibility interface for older Berkeley Software Distribution (BSD) system programs" which sounds to me its just an alias for fork(). MacOS has no vfork anymore.
>> 
>> So maybe Solaris was the last platform with a true vfork.
>
> @tstuefe the helper was needed in part to enable a chdir between fork and exec - see this comment: https://bugs.openjdk.org/browse/JDK-5049299?focusedId=12148272&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12148272

@dholmes-ora My memory was failing me again. Looks like I had found all of this out already, and tested real scenarios where the child process after vfork accidentally damages the parent process: https://mail.openjdk.org/pipermail/core-libs-dev/2018-September/055333.html . 

Back then I also proposed to use the jspawnhelper to isolate this problem, but we went with David Loyd's proposal of adding posix_spawn, and later we switched over to posix_spawn by default. The only remaining question is what to do with the still unsafe vfork mode. I will send a mail to core-libs and feel out the room.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2091589002

From jlahoda at openjdk.org  Thu May 15 16:48:35 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 15 May 2025 16:48:35 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly
Message-ID: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>

A consider class like this:


public class TwoMains {
    private static void main(String... args) {}
    static void main() {
        System.out.println("Should be called, but is not.");
    }
}


The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.

Something similar happens if the return type is not `void`.

This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.

It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).

-------------

Commit messages:
 - 8357016: Candidate main methods not computed properly

Changes: https://git.openjdk.org/jdk/pull/25256/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357016
  Stats: 129 lines in 8 files changed: 103 ins; 10 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25256/head:pull/25256

PR: https://git.openjdk.org/jdk/pull/25256

From swen at openjdk.org  Thu May 15 16:51:17 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 15 May 2025 16:51:17 GMT
Subject: RFR: 8357063: Document preconditions for DecimalDigits methods
Message-ID: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>

Similar to PR #24982 
Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks.

-------------

Commit messages:
 - Document preconditions for DecimalDigits methods

Changes: https://git.openjdk.org/jdk/pull/25246/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25246&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357063
  Stats: 53 lines in 7 files changed: 0 ins; 0 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/25246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25246/head:pull/25246

PR: https://git.openjdk.org/jdk/pull/25246

From thomas.stuefe at gmail.com  Thu May 15 16:52:34 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 15 May 2025 18:52:34 +0200
Subject: ProcessImpl: Can we obsolete the vfork mode?
Message-ID: <CAA-vtUz19h6x4noK3zKgzjp8_Tm49bbKRsBQKz96w8N+aTs-vw@mail.gmail.com>

Hi,

I am currently working on child process issues and again noticed how
inherently dangerous the vfork mode is.

The child process can damage or kill the parent process if bad things
happen in the time window between vfork and exec, when we prepare the
target binary execution. For a non-exclusive list of things that can go
wrong please see my old mail from 2018 here:

https://mail.openjdk.org/pipermail/core-libs-dev/2018-September/055333.html

These errors are vicious too, since they would rarely be attributable to
vfork; they would probably look like random crashes or libc problems.

Back in 2018, I proposed an exec-twice technique whereby one execs a helper
binary first to isolate the child process preparations; then do the final
exec of the target binary. That is safe, fast, and it works. We can still
do this. Would be wven simpler to implement now: we have the jspawnhelper
and can just reuse that for vfork.

However,  we also could just get rid of vfork. That would simplify things
alot. We have moved to posix_spawn-by-default with JDK 13 in 2019 (
https://bugs.openjdk.org/browse/JDK-8213192). That is a long time ago;
probably long enough to ween all customers off vfork use.

What do people think?

Thanks, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250515/2c53bfd0/attachment.htm>

From jiangli at openjdk.org  Thu May 15 17:17:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 15 May 2025 17:17:55 GMT
Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder
 on static-jdk [v2]
In-Reply-To: <3RWZl77waTqYm1lm8ImxBegeni5IcB3jD0cUUiJvWJw=.11c71454-89b8-46ec-8aee-e484de538480@github.com>
References: <E986980rvWra05uWXYMdT8N4i_0RGxNC_KubDF6tXAw=.a6ab5563-b75c-45b2-b367-31d001cc294e@github.com>
 <3RWZl77waTqYm1lm8ImxBegeni5IcB3jD0cUUiJvWJw=.11c71454-89b8-46ec-8aee-e484de538480@github.com>
Message-ID: <ayYWJF-nXUjwIXdCqQnKuPC4DDaRRiYp6ud9PpXoxeY=.a21e6eee-bf39-4670-b10d-ca4a5fe9b320@github.com>

On Wed, 14 May 2025 13:21:37 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year in test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java.
>
> test/lib-test/TEST.ROOT line 31:
> 
>> 29: keys=randomness
>> 30: 
>> 31: # Minimum jtreg version
> 
> Shoule we update the copyright year for file TestNativeProcessBuilder.java

@sendaoYan Please let me know if you have any additional review comments, thanks.

Also looking for a 'R'eviewer for reviewing. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25220#discussion_r2091647230

From duke at openjdk.org  Thu May 15 17:18:56 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:18:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <oa3a1r5ufXR_UsMRudd9pdfEVwTDNWT04sNBcnxX-cs=.4639f165-00f3-4f4d-a3dc-465ef7935d83@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <oa3a1r5ufXR_UsMRudd9pdfEVwTDNWT04sNBcnxX-cs=.4639f165-00f3-4f4d-a3dc-465ef7935d83@github.com>
Message-ID: <cCHkv7ojCXnFYl_ygCTwFU-nFl6Zk2dYBC-jBQIpm7Q=.3e8686ca-ea7a-433c-8d39-3a5dfa8da68a@github.com>

On Tue, 13 May 2025 12:32:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 147:
> 
>> 145:     // this could exist somewhere common, but if it's definitely never going to
>> 146:     // be shared, it could be made public here.
>> 147:     private enum AccessMode {
> 
> Hello David, I think having it `private` is fine and in fact more appropriate. I would suggest removing the comment though.

Done. And if it's not getting made visible (i.e. values are always strings) I can simplify things too.

> src/jdk.zipfs/share/classes/module-info.java line 277:
> 
>> 275:  *   <td>
>> 276:  *       A value defining the desired read/write access mode of the file system
>> 277:  *       (either <em>read-write</em> or <em>read-only</em>).
> 
> This line is slightly confusing. Initially I thought `read-write` and `read-only` are the actual values that this environment property will accept. But further review suggests that the actual literals supported are `readOnly` and `readWrite` and this line here I think is trying to explain the supported semantics of the file system.
> 
> Perhaps we could reword this to something like:
> 
>>
>> A value defining the desired access mode of the file system. A ZIP file system can be created to allow for read-write access or read-only access.

Yeah, I tried to distinguish the accessMode flags (for which there are 3 states, ro, rw, n/a) and the final state of the file system from fs.isReadOnly(). Hence using `<em>...</em>` for whenever the actually resulting state is mentioned. I guess it wasn't clear enough.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091645807
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091649006

From duke at openjdk.org  Thu May 15 17:26:53 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:26:53 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <uNGGjZ8MTJQ-0B1MaURdrJWut2muWY8PhM1cglEcoSU=.ead28184-1d04-4d79-acb7-c3a2ed1cad97@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <uNGGjZ8MTJQ-0B1MaURdrJWut2muWY8PhM1cglEcoSU=.ead28184-1d04-4d79-acb7-c3a2ed1cad97@github.com>
Message-ID: <pkhOSD20l2kjwLUCiFLkB-EfGKzL2Ekko4b5zJju4uI=.95fde100-cf2d-4b89-a804-182040a4ce51@github.com>

On Tue, 13 May 2025 13:48:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 174:
> 
>> 172:                 }
>> 173:                 default -> {
>> 174:                 }
> 
> Since we don't allow for any other value, I think moving the `throw new IllegalArgumentException` from outside of the switch into this `default` case might be suitable.

I rewrote to avoid the switch now there's no way it needs to cope with being the enum value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091660167

From duke at openjdk.org  Thu May 15 17:32:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:32:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <OUM38oaCUaIARxcaYgrAU4yKlhb3vDYlD5x1dHP4h5E=.f1ab1320-bb3b-43e1-814b-5493aeeb99c8@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <OUM38oaCUaIARxcaYgrAU4yKlhb3vDYlD5x1dHP4h5E=.f1ab1320-bb3b-43e1-814b-5493aeeb99c8@github.com>
Message-ID: <zGh_FEPRnTiW34WQMTQfBNXsGT957vTaMn40uP3vtdk=.f6f73eab-2c69-483b-827b-c15a692bd3a2@github.com>

On Tue, 13 May 2025 13:56:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 160:
> 
>> 158: 
>> 159:         // Parses the file system permission from an environmental parameter. While
>> 160:         // the FileSystemAccessMode is private, we don't need to check if it was
> 
> The second sentence perhaps is a leftover? I don't see any `FileSystemAccessMode` type. I think it would be better to remove that second sentence altogether. The rest of the comment looks good and clearly states what this method does.

Done.

> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 167:
> 
>> 165:                     return null;
>> 166:                 }
>> 167:                 case String label when READ_WRITE.label.equals(label) -> {
> 
> I haven't yet fully caught up on the newer features of switch/case. Does this have any advantage as compared to the simpler:
> 
> 
> case "readWrite" -> {
>    return READ_WRITE;
> }
> case "readOnly" -> {
>    return READ_ONLY;
> }

Or just an if :)

The reason for the new style was the "need" for the "String label when" qualifier, which I don't actually need because String.equals(xx) copes with being given non-strings fine. You can't use the syntax you suggested in the new switch since "value" isn't a String.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091667975
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091665729

From duke at openjdk.org  Thu May 15 17:32:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:32:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <EpDUWHEPGqADk8eO2Bt3uf_ql_gSlamnpeUoQhklvSU=.1b898f6e-65bf-424e-bc43-ef7782c4aeec@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <ty23rwTu8HuiUpJIiK3JlOeGZcIl-5iJBQkeZYksrXs=.8a6ca6d0-948a-490e-a58d-0247c1024c5c@github.com>
 <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com>
 <iVQHJmAnBrzwZdYV5JaA9PYUWxDjeuzOVVmsaNkmAvo=.7a2a425e-ad43-4e47-98b5-e5f4d17271a2@github.com>
 <EpDUWHEPGqADk8eO2Bt3uf_ql_gSlamnpeUoQhklvSU=.1b898f6e-65bf-424e-bc43-ef7782c4aeec@github.com>
Message-ID: <bz5DgXhhVcRog6RgWZmxEBOs39TmFkpdqrwZw_uobV8=.3155f133-e1c2-42f2-a0e4-63b2266eae8c@github.com>

On Wed, 14 May 2025 07:43:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I'll file an issue for this today, shortly.
>
> I created JDK-8356888 yesterday and [bplb](https://github.com/bplb) has picked it up already.

So does this mean the code is good as-is now?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091670125

From duke at openjdk.org  Thu May 15 17:39:56 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:39:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <JoYBy9mw1zJ99-VgFw2GN7T5x1nSptIDqBlRx4HxEqY=.7f36a29c-292e-488f-a9d3-1a4fb0abe19b@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <JoYBy9mw1zJ99-VgFw2GN7T5x1nSptIDqBlRx4HxEqY=.7f36a29c-292e-488f-a9d3-1a4fb0abe19b@github.com>
Message-ID: <_fOwfCN-skLDUctxfNIhNVFJB6Q6-RWR7ohRsKi0Yck=.5f156736-e8df-4735-b8b6-fc2cb96ad6d0@github.com>

On Wed, 14 May 2025 15:40:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 95:
> 
>> 93: 
>> 94:     private static final Set<PosixFilePermission> DEFAULT_PERMISSIONS =
>> 95:         PosixFilePermissions.fromString("rwxrwxrwx");
> 
> I am not convinced this needs to be changed as it becomes a  personal style preference

Possibly not, but it is only used in one place, and anyone reading the code now has the comment saying "If not specified in env, it will return 777." three lines away from the code that uses "rwxrwxrwx" instead of nearly 300.

Plus, there isn't now a *mutable* static final constant which could be accidentally leaked and mutated in the future.

Yes, it's personal preference to a degree, but I feel this is a small, but non-zero, improvement in maintainability, and I would ask someone to do this if I were reviewing a change which added this to the code.

> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 113:
> 
>> 111:     final ZipCoder zc;
>> 112:     private final ZipPath rootdir;
>> 113:     // Start readOnly (safe mode) and maybe reset at end of initialization.
> 
> maybe -> may be

Both work. It "may be reset", but also "maybe we will reset it". I reworded slightly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091678054
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091679779

From adinn at openjdk.org  Thu May 15 17:41:52 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 15 May 2025 17:41:52 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v8]
In-Reply-To: <PmF5hPmcrk43l3WpNEGxcCyu9zm-mamNvVod4TUMMZk=.223a6c62-a53f-4094-8f3b-2a094dc3425a@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
 <PmF5hPmcrk43l3WpNEGxcCyu9zm-mamNvVod4TUMMZk=.223a6c62-a53f-4094-8f3b-2a094dc3425a@github.com>
Message-ID: <eU_YZzOK203dKb-IdoHh2_-fJF-HNokZ_END3V2WoBc=.cb88d743-1ccf-4699-bf18-42fd3b6d869c@github.com>

On Thu, 15 May 2025 16:03:44 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
>> 
>> 
>> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
>> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
>> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
>> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
>> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright format correction

Still good

-------------

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25147#pullrequestreview-2844529876

From duke at openjdk.org  Thu May 15 17:42:52 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:42:52 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <JoYBy9mw1zJ99-VgFw2GN7T5x1nSptIDqBlRx4HxEqY=.7f36a29c-292e-488f-a9d3-1a4fb0abe19b@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <JoYBy9mw1zJ99-VgFw2GN7T5x1nSptIDqBlRx4HxEqY=.7f36a29c-292e-488f-a9d3-1a4fb0abe19b@github.com>
Message-ID: <kL8FvQvJ1iYWAIHHX0uZBcR55mZ_o3RIG3yNqdrVPhI=.fc1c7ea6-9679-4a84-babd-bb1230e33ef9@github.com>

On Wed, 14 May 2025 16:39:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 219:
> 
>> 217:             assertFalse(fs.isReadOnly());
>> 218:             if (!"Default version".equals(Files.readString(fs.getPath("file.txt"), UTF_8))) {
>> 219:                 throw new RuntimeException("unexpected file content");
> 
> could also consider
> 
> fail("unexpected file content");

Oh thanks for spotting!
That's a hangover from when it was in the old-style test class (ZipFSTester or whatever it's called).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091684373

From jpai at openjdk.org  Thu May 15 17:45:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 May 2025 17:45:53 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <bz5DgXhhVcRog6RgWZmxEBOs39TmFkpdqrwZw_uobV8=.3155f133-e1c2-42f2-a0e4-63b2266eae8c@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <ty23rwTu8HuiUpJIiK3JlOeGZcIl-5iJBQkeZYksrXs=.8a6ca6d0-948a-490e-a58d-0247c1024c5c@github.com>
 <8chcE0sE3uQQ3EwTu-v1lBuF6CzmBEX4oug--33-lrg=.552d10b8-bb76-4ef4-b48d-d3763407f08e@github.com>
 <iVQHJmAnBrzwZdYV5JaA9PYUWxDjeuzOVVmsaNkmAvo=.7a2a425e-ad43-4e47-98b5-e5f4d17271a2@github.com>
 <EpDUWHEPGqADk8eO2Bt3uf_ql_gSlamnpeUoQhklvSU=.1b898f6e-65bf-424e-bc43-ef7782c4aeec@github.com>
 <bz5DgXhhVcRog6RgWZmxEBOs39TmFkpdqrwZw_uobV8=.3155f133-e1c2-42f2-a0e4-63b2266eae8c@github.com>
Message-ID: <HgY5MiNZoA5im6Mt-BnqWJpxw3KQaZXlXliOFSkDjX8=.c58ca8b8-299b-46de-8372-aea37870bf4a@github.com>

On Thu, 15 May 2025 17:30:35 GMT, David Beaumont <duke at openjdk.org> wrote:

>> I created JDK-8356888 yesterday and [bplb](https://github.com/bplb) has picked it up already.
>
> So does this mean the code is good as-is now?

Hello David, yes it's fine to throw `IllegalArgumentException` from here. The specification of `FileSystemProvider.newFileSystem(...)` APIs will be updated in a separate PR to specify the `IllegalArgumentException` that gets thrown. With that, the zipfs provider implementation will conform to the specification and applications are then expected to deal with the `IllegalArgumentException` caused by an incorrect environment property value that was passed during the filesystem construction.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091688623

From acobbs at openjdk.org  Thu May 15 17:46:39 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 15 May 2025 17:46:39 GMT
Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for()
 loops [v2]
In-Reply-To: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
References: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
Message-ID: <QDGpIFsaeEpCn0XuI90jBWR5p_g9x2k7hwTXrQenYF8=.3046ec01-4595-447e-aa27-f91cdf772c18@github.com>

> Please review this small performance tweak `ArrayDeque`.
> 
> `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Add benchmark for ArrayDeque.clear().

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25237/files
  - new: https://git.openjdk.org/jdk/pull/25237/files/84fb0903..1b8fb830

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25237&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25237&range=00-01

  Stats: 69 lines in 1 file changed: 69 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25237.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25237/head:pull/25237

PR: https://git.openjdk.org/jdk/pull/25237

From acobbs at openjdk.org  Thu May 15 17:48:50 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 15 May 2025 17:48:50 GMT
Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for()
 loops
In-Reply-To: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
References: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
Message-ID: <5ftJn6TBx1Ig47gp6OywxkkcOM_jepkpJzmILDnf8dE=.d6fdb8b8-94c0-44fe-80b4-cc047acbc9b9@github.com>

On Wed, 14 May 2025 19:37:37 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this small performance tweak `ArrayDeque`.
> 
> `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead.

I added a benchmark to the PR (hopefully I did that right).

It shows a _decrease_ in performance. I have no idea why. I did this on my laptop so who knows, but if the effect is real then it kind of raises a lot of larger questions.

jdk-25+22-94-g0318e49500e (master):
Benchmark                                       Mode  Cnt   Score   Error  Units
ArrayDeque.ClearBenchmarkTestJMH.fillAndClear  thrpt   50  37.064 ? 0.225  ops/s

jdk-25+22-95-g84fb0903be0 (JDK-8356993):
Benchmark                                       Mode  Cnt   Score   Error  Units
ArrayDeque.ClearBenchmarkTestJMH.fillAndClear  thrpt   50  35.528 ? 0.180  ops/s

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25237#issuecomment-2884609647

From forax at openjdk.org  Thu May 15 17:53:00 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 15 May 2025 17:53:00 GMT
Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for()
 loops [v2]
In-Reply-To: <QDGpIFsaeEpCn0XuI90jBWR5p_g9x2k7hwTXrQenYF8=.3046ec01-4595-447e-aa27-f91cdf772c18@github.com>
References: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
 <QDGpIFsaeEpCn0XuI90jBWR5p_g9x2k7hwTXrQenYF8=.3046ec01-4595-447e-aa27-f91cdf772c18@github.com>
Message-ID: <V9DW51euF7pI5k0v5tCstnD97OCFbFKhBTbr1LyEwfg=.3a1851e7-0989-4713-9fd8-dd11762c58a0@github.com>

On Thu, 15 May 2025 17:46:39 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this small performance tweak `ArrayDeque`.
>> 
>> `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark for ArrayDeque.clear().

test/jdk/java/util/ArrayDeque/ClearBenchmarkTestJMH.java line 64:

> 62:     @Measurement(iterations = 10)
> 63:     @Warmup(iterations = 3)
> 64:     public void fillAndClear() {

I think you need to return the collection or send it to a BlackHole

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25237#discussion_r2091698886

From duke at openjdk.org  Thu May 15 17:54:51 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:54:51 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <QET6mMWDxaRvVJMd0EUzmC4hh32F06SPU4-yt0o9bp8=.4f4b0493-c0e3-463c-b882-5e5f3aa1744e@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <a_t_Ftohx-cl2pt1hLnu5WeC6mavdNK4ZUPVsufsX1s=.0a08bd89-3320-4031-99b8-9aad787f59f0@github.com>
 <jpu6AaHhiBzIuwqmpMUdjutvU63uE-rKM2EKcWfXhuQ=.859ef831-0603-47ff-8373-66ae4fc0f6fe@github.com>
 <QET6mMWDxaRvVJMd0EUzmC4hh32F06SPU4-yt0o9bp8=.4f4b0493-c0e3-463c-b882-5e5f3aa1744e@github.com>
Message-ID: <RORFHkhfBleRcG9CPamPUC9zHJQblHnpvV8vgrKg5KI=.61fadc3b-d00c-492b-909e-4353bab8863f@github.com>

On Tue, 13 May 2025 06:12:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Is this comment just agreeing with the proposed behaviour stated here?
>> 
>> At the moment the code prohibits "read-only && create". It's an illegal argument exception (see tests).
>> 
>> The only allowed access mode options with "create" are "readWrite" or <no-option>, and in both cases you get back a ZipFileSystem for which "isReadOnly()" is false. We'd already agreed that any explicit access mode needs to always be honoured.
>
> I agree that read-only && create is a combination to be rejected.  My comment is about the update to the description of the "create" option. It's the first row in the table and the changes suggests that it is forcing the file system to be read-write. I think the wording for the "readOnly" option is sufficient, meaning just one place to document the conflict between these two options.

Restored the original comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091701008

From duke at openjdk.org  Thu May 15 17:54:53 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:54:53 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <t3kMzppof8NK7ouOx3QdU32-Jf2v0IWXs70l1k58OVw=.be19d6b2-67a8-4495-bc39-3458f9afec82@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <a_t_Ftohx-cl2pt1hLnu5WeC6mavdNK4ZUPVsufsX1s=.0a08bd89-3320-4031-99b8-9aad787f59f0@github.com>
 <t3kMzppof8NK7ouOx3QdU32-Jf2v0IWXs70l1k58OVw=.be19d6b2-67a8-4495-bc39-3458f9afec82@github.com>
Message-ID: <JU1HN4PEY2YYxKgvHM8oqSU0Ql2v5DxXc2fZheVN1vs=.e1f1bc9d-999f-4cbc-b31d-bdb2b080f515@github.com>

On Mon, 12 May 2025 20:12:53 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/jdk.zipfs/share/classes/module-info.java line 281:
>> 
>>> 279:  *       Even if a zip file system is writable ({@code fs.isReadOnly() == false}),
>>> 280:  *       this says nothing about whether individual files can be created or
>>> 281:  *       modified, simply that it might be possible.
>> 
>> Initially I thought this was to allow for POSIX file permissions but not sure after reading it a second time. Can you say if this is what you mean?
>
> Hmm, you're right, it's not totally clear. It's trying to draw the same sort of distinction that you have with mounted file systems, in which the mode that something is mounted in doesn't override any underlying read-only state.
> 
> For example you can still open a ZipFileSystem for a ZIP file which is on a remote drive, where the permissions show the underlying file as "writable", but an attempt to modify the contents would still fail.
> 
> The POSIX stuff is mentioned at the end, and while it's related, it's not quite the same point.

After thinking about it, I removed the sentence it only applied in edge cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091701964

From duke at openjdk.org  Thu May 15 17:54:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 17:54:54 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <Nl4NgrazqDls5EPFcVWIcNlBc1rFTf1hUKKuN5LNNtw=.7a53e187-1027-4376-9400-371c67515542@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <Nl4NgrazqDls5EPFcVWIcNlBc1rFTf1hUKKuN5LNNtw=.7a53e187-1027-4376-9400-371c67515542@github.com>
Message-ID: <aX_5rtAHjJvS-fN6bBDv6Q79Buj4yE6IavmNRV7AEuQ=.b78bd5d6-427d-4968-8f4a-a113ef08e1c7@github.com>

On Wed, 14 May 2025 17:04:01 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment based on current behaviour.
>
> test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 207:
> 
>> 205:                         Map.of("create", true, "accessMode", "badValue")));
>> 206:     }
>> 207: 
> 
> You could simplify the above tests using a DataProvider similar to
> 
> @DataProvider(name = "zipfsMap")
> protected Object[][] zipfsMap() {
>     return new Object[][]{
>             {Map.of(), NoSuchFileException.class},
>             {Map.of("accessMode", "readOnly"), NoSuchFileException.class},
>             {Map.of("accessMode", "readWrite"),  NoSuchFileException.class},
>             {Map.of("create", true, "accessMode", "readOnly"),  IllegalArgumentException.class},
>             {Map.of("create", true, "accessMode", "badValue"),  IllegalArgumentException.class},
>     };
> @Test(dataProvider = "zipfsMap?)
> public void testZipFSCreationException(Map<String, String> env, Class<T> exception) throws Exception {
>        assertThrows(exception, () -> FileSystems.newFileSystem(noSuchZip, env));
> }

Done. Thanks for giving the example, it really helped.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2091698261

From acobbs at openjdk.org  Thu May 15 17:58:52 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 15 May 2025 17:58:52 GMT
Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for()
 loops [v2]
In-Reply-To: <V9DW51euF7pI5k0v5tCstnD97OCFbFKhBTbr1LyEwfg=.3a1851e7-0989-4713-9fd8-dd11762c58a0@github.com>
References: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
 <QDGpIFsaeEpCn0XuI90jBWR5p_g9x2k7hwTXrQenYF8=.3046ec01-4595-447e-aa27-f91cdf772c18@github.com>
 <V9DW51euF7pI5k0v5tCstnD97OCFbFKhBTbr1LyEwfg=.3a1851e7-0989-4713-9fd8-dd11762c58a0@github.com>
Message-ID: <6k-WHkPVd9uICwzgHwamZ5druA-G3bDhqDxftcNCW3k=.159479ca-dd16-45c6-b632-a20ebdb976e1@github.com>

On Thu, 15 May 2025 17:50:30 GMT, R?mi Forax <forax at openjdk.org> wrote:

> I think you need to return the collection or send it to a BlackHole

I'm fairly new to the benchmark game so I would not be surprised if this is broken.

Previously I was adding them to a list but that caused OOMs.

Can you clarify what you mean? By 'return' do you just mean returning the deque from the method? Also I don't konw what a BlackHole is.

Apologies for not knowing what I'm doing here. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25237#discussion_r2091707587

From alan.bateman at oracle.com  Thu May 15 18:00:06 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Thu, 15 May 2025 19:00:06 +0100
Subject: ProcessImpl: Can we obsolete the vfork mode?
In-Reply-To: <CAA-vtUz19h6x4noK3zKgzjp8_Tm49bbKRsBQKz96w8N+aTs-vw@mail.gmail.com>
References: <CAA-vtUz19h6x4noK3zKgzjp8_Tm49bbKRsBQKz96w8N+aTs-vw@mail.gmail.com>
Message-ID: <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com>



On 15/05/2025 17:52, Thomas St?fe wrote:
> :
>
> However,? we also could just get rid of vfork. That would simplify 
> things alot. We have moved to posix_spawn-by-default with JDK 13 in 
> 2019 (https://bugs.openjdk.org/browse/JDK-8213192). That is a long 
> time ago; probably long enough to ween all customers off vfork use.
>
> What do people think?
>

I haven't see any complaints or JBS issues since the change in JDK 13.? 
It's possible that there deployments running with 
jdk.lang.Process.launchMechanism set to vfork but my guess is that this 
configuration knob isn't widely known. If there are deployments doing 
this then there must be some reason, and I think we would have heard 
about it via a JBS issue by now.

I checked the JDK release notes.? The property was documented in the JDK 
12 release notes. The release note in JDK 13 about the move to 
posix_spawn didn't name the property to go back to vfork.

So my initial reaction is that removing vfork would not be disruptive.

-Alan



From rgiulietti at openjdk.org  Thu May 15 18:14:53 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 15 May 2025 18:14:53 GMT
Subject: RFR: 8357063: Document preconditions for DecimalDigits methods
In-Reply-To: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
References: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
Message-ID: <OwISXF46tqe1eMQsQvcMbcyEWYXnKwOQsZ5UPQ4VXR8=.bf0d2ecf-da85-4786-a45b-3dcfdfc49163@github.com>

On Thu, 15 May 2025 06:24:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to PR #24982 
> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks.

@wenshao I understand this is a kind of followup of #24982, but why this title? It seems just renaming some methods with more speaking names.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25246#issuecomment-2884680422

From duke at openjdk.org  Thu May 15 18:16:59 2025
From: duke at openjdk.org (duke)
Date: Thu, 15 May 2025 18:16:59 GMT
Subject: Withdrawn: 8352489: Relax jspawnhelper version checks to informative
In-Reply-To: <SBjA8ATc2Gb9PLrqYV0htmHNeREAoCehfNpt8Y7bqns=.5d949a37-c84f-4795-a870-579b2e88ce06@github.com>
References: <SBjA8ATc2Gb9PLrqYV0htmHNeREAoCehfNpt8Y7bqns=.5d949a37-c84f-4795-a870-579b2e88ce06@github.com>
Message-ID: <m34DFf0glI1DDXzFqh6iqJZYZ_7v-Nox6Fbb18CqFYI=.f8914b61-dbc6-4257-9209-8e86391b1d04@github.com>

On Thu, 20 Mar 2025 09:52:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for rationale. 
> 
> This goal for this improvement is to be easily backportable, so we can catch up with update releases. As such, it does a few borderline-trivial changes, and _does not_ change the jspawnhelper protocol. So the overwrite of `jspawnhelper` with this new version would be "compatible" in a very weak sense of the word.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/lang/ProcessBuilder`

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24127

From duke at openjdk.org  Thu May 15 18:27:35 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 15 May 2025 18:27:35 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
Message-ID: <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Changes based on review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/9b356a24..2326999b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=02-03

  Stats: 66 lines in 3 files changed: 6 ins; 30 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

PR: https://git.openjdk.org/jdk/pull/25178

From naoto at openjdk.org  Thu May 15 18:32:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 May 2025 18:32:53 GMT
Subject: RFR: 8356977: UTF-8 cleanups
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>

On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

test/jdk/sun/text/resources/LocaleDataTest.java line 106:

> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
> 106:  *        LocaleNames/fr_FR/US=?tats-Unis

This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2091757029

From rgiulietti at openjdk.org  Thu May 15 18:35:51 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 15 May 2025 18:35:51 GMT
Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for()
 loops [v2]
In-Reply-To: <6k-WHkPVd9uICwzgHwamZ5druA-G3bDhqDxftcNCW3k=.159479ca-dd16-45c6-b632-a20ebdb976e1@github.com>
References: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
 <QDGpIFsaeEpCn0XuI90jBWR5p_g9x2k7hwTXrQenYF8=.3046ec01-4595-447e-aa27-f91cdf772c18@github.com>
 <V9DW51euF7pI5k0v5tCstnD97OCFbFKhBTbr1LyEwfg=.3a1851e7-0989-4713-9fd8-dd11762c58a0@github.com>
 <6k-WHkPVd9uICwzgHwamZ5druA-G3bDhqDxftcNCW3k=.159479ca-dd16-45c6-b632-a20ebdb976e1@github.com>
Message-ID: <o7svSLRwXMVkdAZsGhQ_SVRO0f1C1_D3YaPGcanrfd0=.e9cc8a13-45b4-4977-90fe-ae0d8b4b9161@github.com>

On Thu, 15 May 2025 17:56:10 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> test/jdk/java/util/ArrayDeque/ClearBenchmarkTestJMH.java line 64:
>> 
>>> 62:     @Measurement(iterations = 10)
>>> 63:     @Warmup(iterations = 3)
>>> 64:     public void fillAndClear() {
>> 
>> I think you need to return the collection or send it to a BlackHole
>
>> I think you need to return the collection or send it to a BlackHole
> 
> I'm fairly new to the benchmark game so I would not be surprised if this is broken.
> 
> Previously I was adding them to a list but that caused OOMs.
> 
> Can you clarify what you mean? By 'return' do you just mean returning the deque from the method? Also I don't konw what a BlackHole is.
> 
> Apologies for not knowing what I'm doing here. Thanks.

Here are many [exmaples](https://github.com/openjdk/jmh/tree/master/jmh-samples/src/main/java/org/openjdk/jmh/samples) on how to correctly use JMH.

A [blackhole](https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_09_Blackholes.java) prevents the compiler to optimize away your code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25237#discussion_r2091761040

From henryjen at openjdk.org  Thu May 15 18:37:08 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 15 May 2025 18:37:08 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v7]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <TkWSwAgnlTdNgnVJ7YlPdbepHsy-LP71I1LgS14Zm4E=.fd310021-74d0-4c57-99c9-1c13f6c8f38d@github.com>

> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Move all validation into EntryValidator, update the document

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/e0eff6ef..1150fb50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=05-06

  Stats: 212 lines in 4 files changed: 105 ins; 22 del; 85 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 jlu at openjdk.org  Thu May 15 18:52:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 May 2025 18:52:53 GMT
Subject: RFR: 8355393: Create a Test case to have special cases coverage
 for currency.getInstance() [v2]
In-Reply-To: <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
 <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>
Message-ID: <ONvSFsC7l-ZLsR9BBNbqiQoF2O-EFDd1JPa6jJn5Hgc=.074c130b-9585-47af-b589-b0970792ef39@github.com>

On Sun, 11 May 2025 08:42:41 GMT, Abhishek N <duke at openjdk.org> wrote:

>> Create a Test case to have special cases coverage for currency.getInstance().
>> 
>> The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API.
>> 
>> test results:
>> 
>> jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java
>> Directory "JTwork" not found: creating
>> Directory "JTreport" not found: creating
>> Test results: passed: 1
>> Report written to JTreport\html\report.html
>> Results written to JTwork
>
> Abhishek N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correcting jtreg header order, add meaningful comments for each test methods and properties file

This test is not effectively testing standard ISO 4217 future transition currencies. For example, with your patch, if I supply the following changes to the ISO 4217 currency data:
(i.e. Make country `LK` have a transition currency of `XCH` in July)


--- a/src/java.base/share/data/currency/CurrencyData.properties
+++ b/src/java.base/share/data/currency/CurrencyData.properties
@@ -55,7 +55,7 @@ all=ADP020-AED784-AFA004-AFN971-ALL008-AMD051-ANG532-AOA973-ARS032-ATS040-AUD036
   SRD968-SRG740-SSP728-STD678-STN930-SVC222-SYP760-SZL748-THB764-TJS972-TMM795-TMT934-TND788-TOP776-\
   TPE626-TRL792-TRY949-TTD780-TWD901-TZS834-UAH980-UGX800-USD840-USN997-USS998-UYI940-\
   UYU858-UZS860-VEB862-VED926-VEF937-VES928-VND704-VUV548-WST882-XAF950-XAG961-XAU959-XBA955-\
-  XBB956-XBC957-XBD958-XCD951-XCG532-XDR960-XFO000-XFU000-XOF952-XPD964-XPF953-\
+  XBB956-XBC957-XBD958-XCD951-XCG532-XCH533-XDR960-XFO000-XFU000-XOF952-XPD964-XPF953-\
   XPT962-XSU994-XTS963-XUA965-XXX999-YER886-YUM891-ZAR710-ZMK894-ZMW967-ZWD716-ZWG924-\
   ZWL932-ZWN942-ZWR935
 
@@ -502,7 +502,7 @@ GS=GBP
 # SPAIN
 ES=EUR
 # SRI LANKA
-LK=LKR
+LK=LKR;2025-07-01-04-00-00;XCH


and break some functionality related to _future/special_ currencies in `Currency.getInstance(String)`,
(Similar to 8, prior to the fix backported)


--- a/src/java.base/share/classes/java/util/Currency.java
+++ b/src/java.base/share/classes/java/util/Currency.java
@@ -326,13 +326,6 @@ private static Currency getInstance(String currencyCode, int defaultFractionDigi
                 defaultFractionDigits = (tableEntry & SIMPLE_CASE_COUNTRY_DEFAULT_DIGITS_MASK) >> SIMPLE_CASE_COUNTRY_DEFAULT_DIGITS_SHIFT;
                 numericCode = (tableEntry & NUMERIC_CODE_MASK) >> NUMERIC_CODE_SHIFT;
                 found = true;
-            } else { //special case
-                int[] fractionAndNumericCode = SpecialCaseEntry.findEntry(currencyCode);
-                if (fractionAndNumericCode != null) {
-                    defaultFractionDigits = fractionAndNumericCode[0];
-                    numericCode = fractionAndNumericCode[1];
-                    found = true;
-                }
             }


With the above changes, we would expect this test to fail, since `getInstance("XCH")` should throw an exception. However, your test still passes. What this patch is doing is selectively testing a handful of Currencies with the system property override. This is not sufficient to ensure test coverage for testing a standard ISO 4217 transition currency after the transition date has passed. As mentioned above, the system property override does not mock a standard ISO 4217 transition currency, (they have different functionality).

Also as @weibxiao has mentioned, we already have such a test in mainline. Additional testing would be required as backports for LTS releases only.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2884773970

From vromero at openjdk.org  Thu May 15 19:07:37 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 19:07:37 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v14]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <H5OXqp27HjDZFSKaU6jlJkyXyQnW8dhIEz0p7OK4ok8=.f9ee1992-29d7-47a4-be14-41f35c840d1d@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  update warning message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/22acaf29..bdbcd332

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=12-13

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

PR: https://git.openjdk.org/jdk/pull/24746

From alanb at openjdk.org  Thu May 15 19:12:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 May 2025 19:12:52 GMT
Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking [v2]
In-Reply-To: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com>
References: <aEW-5oqTUQgD8pJhkNbGxP_mUen4ld5hYVD_MRKvydE=.7b6900ba-ee3e-4d7a-a1fd-26d4510ffe8e@github.com>
 <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com>
Message-ID: <71l9wpZh5nV-zhaS25IHhhovPGu1FqOAHBI8QUmUZhI=.f1a0620c-322a-4933-9438-ddfe1c0caa99@github.com>

On Thu, 15 May 2025 00:16:32 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This fix adds the `--add-reads` support for CDS and AOTClassLinking.
>> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled:
>> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro`
>> During runtime, the archived full module graph will be disabled:
>> `[0.021s][info][cds       ] full module graph: disabled`
>> 
>> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime.
>> 
>> Testing: tiers 1 - 4.
>
> Calvin Cheung has updated the pull request with a new target base 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:
> 
>  - @iklam comment
>  - Merge branch 'master' into 8354083-add-reads
>  - fix trailing whitespace
>  - 8354083: Support --add-reads with -XX:+AOTClassLinking

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25109#pullrequestreview-2844740491

From mullan at openjdk.org  Thu May 15 19:31:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 15 May 2025 19:31:54 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v3]
In-Reply-To: <JGgkSA4koYf9fBlA0nf2qFXnw0AaPk7I0kiVpv6CPeI=.8e8221d1-5b21-4c8f-a821-253f3fe1c850@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>
 <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com>
 <JGgkSA4koYf9fBlA0nf2qFXnw0AaPk7I0kiVpv6CPeI=.8e8221d1-5b21-4c8f-a821-253f3fe1c850@github.com>
Message-ID: <Y5H3B2fG0QzzWergfvrhg7SRHQLEHj0DODFDaU1hnPQ=.10f836b6-63be-45ec-bf44-dd02108feb22@github.com>

On Tue, 13 May 2025 14:01:10 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> > It is nice to refactor the common code for algorithm constraints checking into a new class, `X509KeyManagerConstraints.java`, used by both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a new system property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. Should the property be a switch for SunX509 KeyManager, not a general toggle for all KeyManager? Avoiding its misuse for `X509KeyManagerImpl` that may lead to disable the existing RFC compliant algorithm constraints checking? It might be preferable to keep the property logic in `SunX509KeyManagerImpl` (not in the common code).
> 
> @haimaychao Thanks for looking into it! Yes, it will disable constraints checking for both key managers and I did it this way on purpose. I think it will be simpler and less confusing to the end users. This system property is off by default and my assumption is that if end users want to disable KM algorithm constraints checking they would expect it to be disabled system-wide. Making this toggle SunX509-specific is a trivial change if we have a consensus on this.
> 
> @seanjmullan What do you think?

Need to think about it some more, but I am kind of leaning towards it only affecting SunX509. The main benefit of the property is to workaround any compatibility issues where current code is not ready for the change. Any application already using the PKIX TrustManager already has this checking enabled/enforced.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2884859280

From vromero at openjdk.org  Thu May 15 19:32:59 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 19:32:59 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v13]
In-Reply-To: <LH5l3EylBKng_NqAM062OyAsMoB62Pc3LMFhNlV1y00=.3ceab033-5328-40bb-8bdd-ac7c6dcb055d@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <QvL1wMiufgj6kq6NBb2ciWTkVQ28MWWIWRmGE47mVHs=.08668b90-b5eb-4272-af23-5c501fccf079@github.com>
 <LH5l3EylBKng_NqAM062OyAsMoB62Pc3LMFhNlV1y00=.3ceab033-5328-40bb-8bdd-ac7c6dcb055d@github.com>
Message-ID: <2oFLdya1PI3WV3lloInRQG1oHs3k2gNhmZjv-V-OLrg=.8e5773fa-4993-4ef1-9e78-7899fa86fd4c@github.com>

On Wed, 14 May 2025 18:23:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
>> 
>>  - Merge branch 'master' into JDK-8354556
>>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>>    
>>    Co-authored-by: Chen Liang <liach at openjdk.org>
>>  - additional changes from Archie
>>  - removing dead code
>>  - integrating code from Archie
>>  - fixing bugs, removing dead code
>>  - additional documentation changes and bug fixes
>>  - documentation and adding alias to lint categories
>>  - Merge branch 'master' into JDK-8354556
>>  - addressing review comment
>>  - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 2673:
> 
>> 2671:             result = check(tree, capturedRes, KindSelector.VAL, resultInfo);
>> 2672:         }
>> 2673:         if (env.info.lint.isEnabled(LintCategory.IDENTITY)) {
> 
> This is the only place where there's a check whether the lint is enabled before the call to `checkRequiresIdentity`. Is there a reason for that?

left over of the initial approach I guess. I will remove it

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2091837488

From naoto at openjdk.org  Thu May 15 19:36:02 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 May 2025 19:36:02 GMT
Subject: RFR: 8357075: Remove leftover COMPAT locale data tests
Message-ID: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>

Removing now-defunct COMPAT locale provider tests.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/25257/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25257&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357075
  Stats: 8496 lines in 2 files changed: 0 ins; 8484 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/25257.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25257/head:pull/25257

PR: https://git.openjdk.org/jdk/pull/25257

From vromero at openjdk.org  Thu May 15 19:48:55 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 19:48:55 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v13]
In-Reply-To: <LH5l3EylBKng_NqAM062OyAsMoB62Pc3LMFhNlV1y00=.3ceab033-5328-40bb-8bdd-ac7c6dcb055d@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <QvL1wMiufgj6kq6NBb2ciWTkVQ28MWWIWRmGE47mVHs=.08668b90-b5eb-4272-af23-5c501fccf079@github.com>
 <LH5l3EylBKng_NqAM062OyAsMoB62Pc3LMFhNlV1y00=.3ceab033-5328-40bb-8bdd-ac7c6dcb055d@github.com>
Message-ID: <rrqDosHsQmnGjNyIRZ9_outXOjA5w1HmytH-BsXiXNc=.4f3b990b-b100-4145-a414-6d48e3d815e9@github.com>

On Wed, 14 May 2025 18:25:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
>> 
>>  - Merge branch 'master' into JDK-8354556
>>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>>    
>>    Co-authored-by: Chen Liang <liach at openjdk.org>
>>  - additional changes from Archie
>>  - removing dead code
>>  - integrating code from Archie
>>  - fixing bugs, removing dead code
>>  - additional documentation changes and bug fixes
>>  - documentation and adding alias to lint categories
>>  - Merge branch 'master' into JDK-8354556
>>  - addressing review comment
>>  - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5671:
> 
>> 5669:     }
>> 5670: 
>> 5671:     void checkRequiresIdentity(JCTree tree, Lint lint) {
> 
> For consideration: as far as I can see, we have a sharp(er) type when we call `checkRequiresIdentity`, but we give up the type, and re-instante it here using the pattern matching switch. I wonder if it would be more elegant (and hopefully not really too much longer) if the `checkRequiresIdentity` method would have multiple overloads, with the sharp(er) types, like `JCClassDecl`/`JCVariableDecl`, etc.
> 
> Or is there a reason to given up the sharp(er) type and re-create it using the switch?

I guess the motivation was to have all this related code in one place, if this code is split into several overloaded methods then I guess an entity, a class, should probably be defined to contain all this code. Dunno I guess the current solution seemed more self-contained to me

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2091858747

From duke at openjdk.org  Thu May 15 19:55:53 2025
From: duke at openjdk.org (ExE Boss)
Date: Thu, 15 May 2025 19:55:53 GMT
Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for()
 loops [v2]
In-Reply-To: <QDGpIFsaeEpCn0XuI90jBWR5p_g9x2k7hwTXrQenYF8=.3046ec01-4595-447e-aa27-f91cdf772c18@github.com>
References: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
 <QDGpIFsaeEpCn0XuI90jBWR5p_g9x2k7hwTXrQenYF8=.3046ec01-4595-447e-aa27-f91cdf772c18@github.com>
Message-ID: <-e84j1Q5W39W8HRZmgrMWo-S9hyrLhZneLYeU81CoHc=.0d9bc5bc-1a9d-4079-af7e-12ab21c5ba1c@github.com>

On Thu, 15 May 2025 17:46:39 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this small performance tweak `ArrayDeque`.
>> 
>> `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark for ArrayDeque.clear().

Note?that `Arrays.fill(?)` is?simply a?`for(?)`?loop with?an?additional range?check and?is?potentially subject to?profile?pollution due?to?[JDK?8015417]:
<https://github.com/openjdk/jdk/blob/c59debb3844d009ac501a48c31822a07f00521e9/src/java.base/share/classes/java/util/Arrays.java#L3449-L3453>

[JDK?8015417]: https://bugs.openjdk.org/browse/JDK-8015417

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25237#issuecomment-2884908080

From acobbs at openjdk.org  Thu May 15 20:07:53 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 15 May 2025 20:07:53 GMT
Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for()
 loops [v2]
In-Reply-To: <-e84j1Q5W39W8HRZmgrMWo-S9hyrLhZneLYeU81CoHc=.0d9bc5bc-1a9d-4079-af7e-12ab21c5ba1c@github.com>
References: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
 <QDGpIFsaeEpCn0XuI90jBWR5p_g9x2k7hwTXrQenYF8=.3046ec01-4595-447e-aa27-f91cdf772c18@github.com>
 <-e84j1Q5W39W8HRZmgrMWo-S9hyrLhZneLYeU81CoHc=.0d9bc5bc-1a9d-4079-af7e-12ab21c5ba1c@github.com>
Message-ID: <p0VoqgCJoaa-e9zPGolSfeSgN5cWez1IDOIAgmBdZt4=.3f82a36a-1aba-45c2-898d-ce52718356bc@github.com>

On Thu, 15 May 2025 19:53:03 GMT, ExE Boss <duke at openjdk.org> wrote:

> Note that `Arrays.fill(?)` is simply a `for(?)` loop with an additional range check

Interesting... I was assuming that most of the "bulk" methods in `Arrays` were being hand-optimized with special hardware magic (e.g., vector instructions), and that the opportunity to do this was part of the motivation for adding them in the first place.

If C2 is already able to automatically optimize this into the maximum possible hardware performance, then great! But is that actually the case?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25237#issuecomment-2884933648

From joehw at openjdk.org  Thu May 15 20:26:53 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 15 May 2025 20:26:53 GMT
Subject: RFR: 8357075: Remove leftover COMPAT locale data tests
In-Reply-To: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
References: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
Message-ID: <KJ0LC4zodUVloa_jyF-gsdHZFA3B5V8WLyyxBYFnd2s=.b6efe6ee-d9f1-435e-9103-455a11cb7d86@github.com>

On Thu, 15 May 2025 19:31:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing now-defunct COMPAT locale provider tests.

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25257#pullrequestreview-2844891980

From vromero at openjdk.org  Thu May 15 20:29:16 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 20:29:16 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v15]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <nIpblBXs9ugE3vM9aB_41A8cFunwwSZvGdLrZfXVETU=.0b7c960b-1048-4d6a-aaa7-45b195df88b4@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/bdbcd332..6c8d2b1d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=13-14

  Stats: 21 lines in 2 files changed: 1 ins; 12 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

PR: https://git.openjdk.org/jdk/pull/24746

From paul.sandoz at oracle.com  Thu May 15 20:30:42 2025
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 15 May 2025 20:30:42 +0000
Subject: Towards a JSON API for the JDK
Message-ID: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>

Hi,

We would like to share with you our thoughts and plans towards a JSON API for the JDK.
Please see the document below. 

-

We have had the pleasure of using a clone of this API in some experiments we are conducting with
ONNX and code reflection [1]. Using the API we were able to quickly write code to ingest and convert
a JSON document representing ONNX operation schema into instances of records modeling the schema
(see here [2]). 

The overall out-of-box experience with such a minimal "batteries included? API has so far been positive.

Thanks,
Paul.

[1] https://openjdk.org/projects/babylon/
[2] https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87

# Towards a JSON API for the JDK

One of the most common requests for the JDK is an API for parsing and generating
JSON. While JSON originated as a text-based serialization format for JSON
objects ("JSON" stands for "JavaScript Object Notation"), because of its simple
and flexible syntax, it eventually found use outside the JavaScript ecosystem as
a general data interchange format, such as framework configuration files and web
service requests/response formats.

While the JDK cannot, and should not, provide libraries for every conceivable
file format or protocol, the JDK philosophy is one of "batteries included",
which is to say we should be able to write basic programs that use common
protocols such as HTTP, without having to appeal to third party libraries.
The Java ecosystem already has plenty of JSON libraries, so inclusion in
the JDK is largely meant to be a convenience, rather than needing to be the "one
true" JSON library to meet the needs of all users. Users with specific needs
are always free to select one of the existing third-party libraries.

## Goals and requirements

Our primary goal is that the library be simple to use for parsing, traversing,
and generating conformant JSON documents. Advanced features, such as data
binding or path-based traversal should be possible to implement as layered
features, but for simplicity are not included in the core API. We adopt a goal
that the performance should be "good enough", but where performance
considerations conflict with simplicity and usability, we will choose in favor
of the latter.

## API design approach

The description of JSON at `https:://json.org` describes a JSON document using
the familiar "railroad diagram":
![image](https://www.json.org/img/value.png)

This diagram describes an algebraic data type (a sum of products), which we
model directly with a set of Java interfaces:

```
interface JsonValue { }
interface JsonArray extends JsonValue { List<JsonValue> values(); }
interface JsonObject extends JsonValue { Map<String, JsonValue> members(); }
interface JsonNumber extends JsonValue { Number toNumber(); }
interface JsonString extends JsonValue { String value(); }
interface JsonBoolean extends JsonValue  { boolean value(); }
interface JsonNull extends JsonValue { }
```

These interfaces have (hidden) companion implementation classes that admit
greater flexibility of implementation than modeling them directly with records would permit.
Further, these interfaces are unsealed. We compromise on the sealed sum of products to enable
alternative implementations, for example to support alternative formats that
encode the same information in a JSON document but in a more efficient form than
text.

The API has static methods for parsing strings into a `JsonValue`, conversion to
and from purely untyped representations (lists and maps), and factory methods
for building JSON documents. We apply composition consistently, e.g, a
JsonString has a string, a JsonObject has a map of string to JsonValue, as
opposed to extension for structural JSON values.

It turns out that this simple API is almost all we need for traversal. It gives
us an immutable representation of a document, and we can use pattern matching to
answer the myriad questions that will come up (Does this object have key X? Does
it map to a number? Is that number representable as an integer?) when going
from an untyped format like JSON to a more strongly typed domain model.
Given a simple document like:

```
    {
        "name": "John?,
        "age": 30
    }
```

we can parse and traverse the document as follows:

```
JsonValue doc = Json.parse(inputString);
if (doc instanceof JsonObject o
    && o.members().get("name") instanceof JsonString s
    && s.value() instanceof String name
    && o.members().get("age") instanceof JsonNumber n
    && n.toNumber() instanceof Long l && l instanceof int age) {
            // use "name" and "age"
        }
```

Later, when the language acquires the ability to expose deconstruction patterns
for arbitrary interfaces (similar to today's record patterns, see
https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns),
this will be simplifiable to:

```
JsonValue doc = Json.parse(inputString);
if (doc instanceof JsonObject(var members)
    && members.get("name") instanceof JsonString(String name)
    && members.get("age") instanceof JsonNumber(int age)) {
            // use "name" and "age"
        }
```

So, overtime, as more pattern matching features are introduced we anticipate
improved use of the API. This is a primary reason why the API is so minimal.
Convenience methods we add today, such as a method that accesses a JSON
object component as say a JSON string or throws an exception, will become
redundant in the future.

## JSON numbers

The specification of JSON number makes no explicit distinction between integral
and decimal numbers, nor specifies limits on the size of those numbers.
This is a common source of interoperability issues when consuming JSON
documents. Generally users cannot always but often do assume JSON numbers are
parsable, without loss of precision, to IEEE double-precision floating point
numbers or 32-bit signed integers.

In this respect the API provides three means to operate on the JSON number,
giving the user full control:

1. Underlying string representation can be obtained, if preserving syntactic
   details such as leading or trailing zeros is important.
2. The string representation can be parsed to an instance of `BigDecimal`, using
   `toBigDecimal` if preserving decimal numbers is important.
3. The string representation can be parsed into an instance of `Long`, `Double`,
   `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this method
   depends on how the representation can be parsed, possibly losing precision,
   choosing a suitably convenient numeric type that can then be pattern
   matched on.

Primitive pattern matching will help as will further pattern matching features
enabling the user to partially match.

## Prototype implementation

The prototype implementation is currently located into the JDK sandbox
repository
under the `json` branch, see
here https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json
The prototype API javadoc generated from the repository is also available at
https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html

### Testing and conformance

The prototype implementation passes all conformance test cases but two, available
on https://github.com/nst/JSONTestSuite. The two exceptions are the ones which the
prototype specifically prohibits, i.e, duplicated names in JSON objects
(https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35).

### Performance

Our main focus so far has been on the API design and a functional implementation. 
Hence, there has been less focus on performance even though we know there are a
number of performance enhancements we can make eventually.
We are reasonably happy with the current performance. The
implementation performs well when compared to other JSON implementations
parsing from string instances and traversing documents.

An example of where we may choose simplicity and usability over performance
is the rejection of JSON documents containing objects that in turn contain members
with duplicate names. That may increase the cost of parsing, but simplifies the user
experience for the majority of cases since if we reasonably assume JsonObjects are
map-like, what should the user do with such members, pick one the last one? merge
the values? or reject?

## A JSON JEP?

We plan to draft JEP when we are ready. Attentive readers will observe that
a JEP already exists, JEP 198: Light-Weight JSON API (https://openjdk.org/jeps/198). We will
either update this JEP, or withdraw it and draft a new one.

From wxiao at openjdk.org  Thu May 15 20:32:54 2025
From: wxiao at openjdk.org (Weibing Xiao)
Date: Thu, 15 May 2025 20:32:54 GMT
Subject: RFR: 8355393: Create a Test case to have special cases coverage
 for currency.getInstance() [v2]
In-Reply-To: <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
 <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>
Message-ID: <JB5V1JU7fMCb2rEeu8_X_n_BmZq4iP5zxBUdAk0xZGM=.f8a7e52f-37f3-4c94-9ace-9d5a8c887372@github.com>

On Sun, 11 May 2025 08:42:41 GMT, Abhishek N <duke at openjdk.org> wrote:

>> Create a Test case to have special cases coverage for currency.getInstance().
>> 
>> The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API.
>> 
>> test results:
>> 
>> jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java
>> Directory "JTwork" not found: creating
>> Directory "JTreport" not found: creating
>> Test results: passed: 1
>> Report written to JTreport\html\report.html
>> Results written to JTwork
>
> Abhishek N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correcting jtreg header order, add meaningful comments for each test methods and properties file

The test case, by using example data "CW=ANG;2099-04-01-04-00-00;XCG",  when

Currency.getInstance ("XCG) is called; instead failing, it will work by overwriting System::currentTimeMillis. This call will return any future time. This will allow the currency XG to be a valid currency. It verifies the future currency at current time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2884983555

From liach at openjdk.org  Thu May 15 20:35:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 15 May 2025 20:35:04 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v15]
In-Reply-To: <yHqAaZikc8ZZAf9krV1KMzx_vVgUxkMVUmFVshIN6Uo=.2aa41d75-41d9-44cd-bef3-f598f62728f7@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
 <yHqAaZikc8ZZAf9krV1KMzx_vVgUxkMVUmFVshIN6Uo=.2aa41d75-41d9-44cd-bef3-f598f62728f7@github.com>
Message-ID: <jcqrCy_KKsS8wyrnIDsMc0Hdl3SjjVSslNzA10xuij4=.8100e26f-b5e0-4436-bb3e-d1889f9ca195@github.com>

On Tue, 13 May 2025 13:56:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More suggestions from viktor

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2884986670

From liach at openjdk.org  Thu May 15 20:35:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 15 May 2025 20:35:05 GMT
Subject: Integrated: 8351996: Behavioral updates for ClassValue::remove
In-Reply-To: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
References: <c8-s5uvZgRCjIQ3FmRuxte-lWLvWLHSpeVwrYXEUqLA=.9354127f-6fd6-40a8-80f9-488bb7387792@github.com>
Message-ID: <Yqne2fG0b660o9tcU4iybptsU-F4TkvKW_wgR0G5Jp0=.bd2b5205-d0c8-4cb5-a5ee-d377eae09dfc@github.com>

On Fri, 14 Mar 2025 00:01:21 GMT, Chen Liang <liach at openjdk.org> wrote:

> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
> 
> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
> 
> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
> 
> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.

This pull request has now been integrated.

Changeset: 9223ed78
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9223ed788a53820dcc1e285a6e0df0c97b05fb09
Stats:     646 lines in 2 files changed: 387 ins; 137 del; 122 mod

8351996: Behavioral updates for ClassValue::remove

Co-authored-by: John R Rose <jrose at openjdk.org>
Reviewed-by: vklang, jrose

-------------

PR: https://git.openjdk.org/jdk/pull/24043

From bpb at openjdk.org  Thu May 15 20:36:59 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 15 May 2025 20:36:59 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <dwtS71dqeIYLsEVqpFl0-AMfQRX35vq0zgpBrzDfkw4=.0af8ec7d-614e-4098-adaa-c1ab56d1f035@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <x1nMqw3J0aQoPyMt3WZ8YPnPFEwAebt_cnGtQYSXNSs=.6ae13f2a-5eeb-410d-9971-958526a8f16e@github.com>
 <BErvDbjWrXY7YGuIyQwR22cHeUP4knxU8MU4tw6AMN4=.c6b174ea-abdb-4b11-b6f9-0d97a03dc6ff@github.com>
 <Swr1GEuPbIhL4A273oZfYFmAlwYw3lPF2vaWhTzt4aE=.401b5bda-92db-4361-a581-579756ecf562@github.com>
 <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com>
 <RbqVx9l3PqI3nGa04lI8LZc8q4RyriZK8KP0-sqL098=.257abdaf-af46-4148-b925-42eebb1a3666@github.com>
 <6pcsLU3w7BQmpUbZ-p53iZsOK3kVckilpiHzyOu2VK8=.10d95ba6-1259-4e90-a994-407f9c247a67@github.com>
 <-alnojXx7gvsHuZyAugz_zk_1bf_QT0PfSZMdvP_Xt8=.0791cdf3-f466-4dd0-b672-5a0f619d14d7@github.com>
 <dJ6QbcWd3g7UZrHLzDKDZpsg1JGl5przqySy6chS8xM=.8f09904b-0f74-42d9-9562-47fcb73f5dc7@github.com>
 <dwtS71dqeIYLsEVqpFl0-AMfQRX35vq0zgp
 BrzDfkw4=.0af8ec7d-614e-4098-adaa-c1ab56d1f035@github.com>
Message-ID: <uvpXW26IrXksJTYg12DdLAF7i1SNHG3zlIdWKcyVEHc=.cf20aaec-bbec-40ea-8b07-086e38303553@github.com>

On Thu, 15 May 2025 05:53:44 GMT, Markus KARG <duke at openjdk.org> wrote:

>> @mkarg Please don't invoke my name to try to buttress your arguments. The calls the Reader.of() instance makes on its backing CharSequence is a different kind of issue from what promises or guarantees the concrete methods of the Reader class makes to its subclasses.
>
> @stuart-marks Sorry, didn't want to pull you in here, that's why I said, I am just *paraphrasing*.
> 
> That is correct, it is a different case, but the *final effect* for the caller is the same: If he needs to now whether a copy is made *or not*, he needs to have JavaDocs telling him *how* the new method works inside (whether it calls `subSequence` or whether it calls `getChars`). Otherwise he might make false assumptions about the result.

This API is concerned with the "what" and not so much the "how."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2091919761

From jlu at openjdk.org  Thu May 15 20:43:54 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 May 2025 20:43:54 GMT
Subject: RFR: 8357075: Remove leftover COMPAT locale data tests
In-Reply-To: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
References: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
Message-ID: <E7eVjxlD6oxLH4PqRD9PHqi8b4noyT9PVAbH3wz1D3w=.a3a1f619-48c6-42db-a380-c0c7367ae0ad@github.com>

On Thu, 15 May 2025 19:31:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing now-defunct COMPAT locale provider tests.

Nice cleanup; lgtm

test/jdk/sun/text/resources/LocaleDataTest.java line 178:

> 176: public class LocaleDataTest
> 177: {
> 178:     static final String TEXT_RESOURCES_PACKAGE ="sun.text.resources.cldr";

Suggestion:

    static final String TEXT_RESOURCES_PACKAGE = "sun.text.resources.cldr";

test/jdk/sun/text/resources/LocaleDataTest.java line 179:

> 177: {
> 178:     static final String TEXT_RESOURCES_PACKAGE ="sun.text.resources.cldr";
> 179:     static final String UTIL_RESOURCES_PACKAGE ="sun.util.resources.cldr";

Suggestion:

    static final String UTIL_RESOURCES_PACKAGE = "sun.util.resources.cldr";

test/jdk/sun/text/resources/LocaleDataTest.java line 180:

> 178:     static final String TEXT_RESOURCES_PACKAGE ="sun.text.resources.cldr";
> 179:     static final String UTIL_RESOURCES_PACKAGE ="sun.util.resources.cldr";
> 180:     static final String DEFAULT_DATAFILE ="LocaleData.cldr";

Suggestion:

    static final String DEFAULT_DATAFILE = "LocaleData.cldr";

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25257#pullrequestreview-2844921929
PR Review Comment: https://git.openjdk.org/jdk/pull/25257#discussion_r2091926227
PR Review Comment: https://git.openjdk.org/jdk/pull/25257#discussion_r2091926415
PR Review Comment: https://git.openjdk.org/jdk/pull/25257#discussion_r2091926586

From naoto at openjdk.org  Thu May 15 20:53:10 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 May 2025 20:53:10 GMT
Subject: RFR: 8357075: Remove leftover COMPAT locale data tests [v2]
In-Reply-To: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
References: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
Message-ID: <ybUfk4KD0jMOEn3ki-VKlALRXABRpZfCFR6mCUp1EqQ=.4a2e12dc-ab43-4fde-b9a8-9682e3fb4f66@github.com>

> Removing now-defunct COMPAT locale provider tests.

Naoto Sato has updated the pull request incrementally with three additional commits since the last revision:

 - Update test/jdk/sun/text/resources/LocaleDataTest.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>
 - Update test/jdk/sun/text/resources/LocaleDataTest.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>
 - Update test/jdk/sun/text/resources/LocaleDataTest.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25257/files
  - new: https://git.openjdk.org/jdk/pull/25257/files/5112a966..b9cf8d18

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25257&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25257&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25257.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25257/head:pull/25257

PR: https://git.openjdk.org/jdk/pull/25257

From naoto at openjdk.org  Thu May 15 20:53:10 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 May 2025 20:53:10 GMT
Subject: RFR: 8357075: Remove leftover COMPAT locale data tests [v2]
In-Reply-To: <E7eVjxlD6oxLH4PqRD9PHqi8b4noyT9PVAbH3wz1D3w=.a3a1f619-48c6-42db-a380-c0c7367ae0ad@github.com>
References: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
 <E7eVjxlD6oxLH4PqRD9PHqi8b4noyT9PVAbH3wz1D3w=.a3a1f619-48c6-42db-a380-c0c7367ae0ad@github.com>
Message-ID: <8X53b-CEba172PLu24gc0HukUUfBc5egPMqMGiKnXmA=.8a512b9c-4684-4181-985e-e2fe178b5c09@github.com>

On Thu, 15 May 2025 20:39:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>>    
>>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>>    
>>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>>    
>>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>
> test/jdk/sun/text/resources/LocaleDataTest.java line 178:
> 
>> 176: public class LocaleDataTest
>> 177: {
>> 178:     static final String TEXT_RESOURCES_PACKAGE ="sun.text.resources.cldr";
> 
> Suggestion:
> 
>     static final String TEXT_RESOURCES_PACKAGE = "sun.text.resources.cldr";

Thanks. Committed with others

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25257#discussion_r2091940230

From acobbs at openjdk.org  Thu May 15 21:04:40 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 15 May 2025 21:04:40 GMT
Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for()
 loops [v3]
In-Reply-To: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
References: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
Message-ID: <hPAjrTbUUlkLrYiL8CJkkIrz5df8oSS5dy0pKmVFkAI=.63747977-f94b-4b46-a561-4a8faee89f4b@github.com>

> Please review this small performance tweak `ArrayDeque`.
> 
> `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Blackhole ArrayDeque to ensure it's not ignored by the compiler.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25237/files
  - new: https://git.openjdk.org/jdk/pull/25237/files/1b8fb830..9f0c5fe1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25237&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25237&range=01-02

  Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25237.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25237/head:pull/25237

PR: https://git.openjdk.org/jdk/pull/25237

From acobbs at openjdk.org  Thu May 15 21:04:40 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 15 May 2025 21:04:40 GMT
Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for()
 loops [v2]
In-Reply-To: <o7svSLRwXMVkdAZsGhQ_SVRO0f1C1_D3YaPGcanrfd0=.e9cc8a13-45b4-4977-90fe-ae0d8b4b9161@github.com>
References: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
 <QDGpIFsaeEpCn0XuI90jBWR5p_g9x2k7hwTXrQenYF8=.3046ec01-4595-447e-aa27-f91cdf772c18@github.com>
 <V9DW51euF7pI5k0v5tCstnD97OCFbFKhBTbr1LyEwfg=.3a1851e7-0989-4713-9fd8-dd11762c58a0@github.com>
 <6k-WHkPVd9uICwzgHwamZ5druA-G3bDhqDxftcNCW3k=.159479ca-dd16-45c6-b632-a20ebdb976e1@github.com>
 <o7svSLRwXMVkdAZsGhQ_SVRO0f1C1_D3YaPGcanrfd0=.e9cc8a13-45b4-4977-90fe-ae0d8b4b9161@github.com>
Message-ID: <_3B3G3M1DvwY5x6FZYu--qj9acrcToP-oIPp1zFpaUQ=.74790f82-8962-484d-9732-db06680e2442@github.com>

On Thu, 15 May 2025 18:33:22 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Here are many [exmaples](https://github.com/openjdk/jmh/tree/master/jmh-samples/src/main/java/org/openjdk/jmh/samples) on how to correctly use JMH.
> 
> A [blackhole](https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_09_Blackholes.java) prevents the compiler to optimize away your code.

Thanks for the tip. FWIW after doing that the numbers came out about the same - which is not surprising given that `Arrays.fill()` is just the same `for()` loop...


#2 - After adding Blackhole

jdk-25+22-94-g0318e49500e (master):
Benchmark                                       Mode  Cnt   Score   Error  Units
ArrayDeque.ClearBenchmarkTestJMH.fillAndClear  thrpt   50  35.663 ? 0.163  ops/s

jdk-25+22-97-g9f0c5fe1f90 (JDK-8356993):
Benchmark                                       Mode  Cnt   Score   Error  Units
ArrayDeque.ClearBenchmarkTestJMH.fillAndClear  thrpt   50  35.112 ? 0.501  ops/s

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25237#discussion_r2091954179

From ccheung at openjdk.org  Thu May 15 21:17:03 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 15 May 2025 21:17:03 GMT
Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking
In-Reply-To: <s0fCcdSLPUVuyT_5NPbWJpRzqZX2FVH_fzYiHruYowY=.3b318ba9-d027-4ae8-8dab-976f50c87ce2@github.com>
References: <aEW-5oqTUQgD8pJhkNbGxP_mUen4ld5hYVD_MRKvydE=.7b6900ba-ee3e-4d7a-a1fd-26d4510ffe8e@github.com>
 <s0fCcdSLPUVuyT_5NPbWJpRzqZX2FVH_fzYiHruYowY=.3b318ba9-d027-4ae8-8dab-976f50c87ce2@github.com>
Message-ID: <oq6JUK5YqxTV11jc5cgXN51nmPfR2FxSBt2JiimNc9U=.0d9bce11-abc9-4556-9936-ef9114cf904b@github.com>

On Thu, 8 May 2025 03:22:32 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This fix adds the `--add-reads` support for CDS and AOTClassLinking.
>> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled:
>> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro`
>> During runtime, the archived full module graph will be disabled:
>> `[0.021s][info][cds       ] full module graph: disabled`
>> 
>> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime.
>> 
>> Testing: tiers 1 - 4.
>
> I think we need a test to validate that the `--add-reads` flag actually works. I wrote such a test when I implemented `--add-exports`: see [runtime/cds/appcds/jigsaw/modulepath/AddExports.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/AddExports.java)
> 
> I think we need a similar test for `--add-opens` as well.
> 
> Since the main reason for supporting `--add-{expors,opens,reads}` is for user of AOT class linking, I would suggest moving the above AddExports.java test to 
> 
> - runtime/cds/appcds/aotClassLinking/modules/AddExports.java
> 
> And then add AddReads.java and AddOpens.java there as well.
> 
> The reason for putting the tests inside aotClassLinking is that they will be excluded from the `hotspot_appcds_dynamic` and `hotspot_aot_classlinking` test groups, so you don't need to add special case code to handle those two test groups.

Thanks @iklam @AlanBateman for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25109#issuecomment-2885067118

From ccheung at openjdk.org  Thu May 15 21:17:04 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 15 May 2025 21:17:04 GMT
Subject: Integrated: 8354083: Support --add-reads with -XX:+AOTClassLinking
In-Reply-To: <aEW-5oqTUQgD8pJhkNbGxP_mUen4ld5hYVD_MRKvydE=.7b6900ba-ee3e-4d7a-a1fd-26d4510ffe8e@github.com>
References: <aEW-5oqTUQgD8pJhkNbGxP_mUen4ld5hYVD_MRKvydE=.7b6900ba-ee3e-4d7a-a1fd-26d4510ffe8e@github.com>
Message-ID: <hhkxrNDGu6bNXIkk1wkSv01NaaFXV8I9KmqnvJxlN7w=.092c0176-37ce-46a0-90bd-273882d7f4d1@github.com>

On Thu, 8 May 2025 00:19:17 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This fix adds the `--add-reads` support for CDS and AOTClassLinking.
> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled:
> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro`
> During runtime, the archived full module graph will be disabled:
> `[0.021s][info][cds       ] full module graph: disabled`
> 
> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime.
> 
> Testing: tiers 1 - 4.

This pull request has now been integrated.

Changeset: efdbb6af
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/efdbb6afce4116140c066641128264ab42697912
Stats:     723 lines in 9 files changed: 443 ins; 277 del; 3 mod

8354083: Support --add-reads with -XX:+AOTClassLinking

Reviewed-by: iklam, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25109

From forax at univ-mlv.fr  Thu May 15 21:27:57 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 15 May 2025 23:27:57 +0200 (CEST)
Subject: Towards a JSON API for the JDK
In-Reply-To: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
Message-ID: <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>

Hi Paul,
yes, not having a simple JSON API in Java is an issue for beginners.

It's not clear to me why JsonArray (for example) has to be an interface instead of a record ?

I understand why Json.parse() only works on String and char[] but the API make it too easy to have many performance issues.
I think you need versions using a Reader and a Path.
Bonus point, if there is a method walk() that also returns a JsonValue but the List/Map inside JsonArray/JsonObject are populated lazily.

Minor point: Json.toDisplayString() should takes a second parameters indicating the number of spaces used for the indentation (like JSON.stringify in JS).

regards,
R?mi

----- Original Message -----
> From: "Paul Sandoz" <paul.sandoz at oracle.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Thursday, May 15, 2025 10:30:42 PM
> Subject: Towards a JSON API for the JDK

> Hi,
> 
> We would like to share with you our thoughts and plans towards a JSON API for
> the JDK.
> Please see the document below.
> 
> -
> 
> We have had the pleasure of using a clone of this API in some experiments we are
> conducting with
> ONNX and code reflection [1]. Using the API we were able to quickly write code
> to ingest and convert
> a JSON document representing ONNX operation schema into instances of records
> modeling the schema
> (see here [2]).
> 
> The overall out-of-box experience with such a minimal "batteries included? API
> has so far been positive.
> 
> Thanks,
> Paul.
> 
> [1] https://openjdk.org/projects/babylon/
> [2]
> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87
> 
> # Towards a JSON API for the JDK
> 
> One of the most common requests for the JDK is an API for parsing and generating
> JSON. While JSON originated as a text-based serialization format for JSON
> objects ("JSON" stands for "JavaScript Object Notation"), because of its simple
> and flexible syntax, it eventually found use outside the JavaScript ecosystem as
> a general data interchange format, such as framework configuration files and web
> service requests/response formats.
> 
> While the JDK cannot, and should not, provide libraries for every conceivable
> file format or protocol, the JDK philosophy is one of "batteries included",
> which is to say we should be able to write basic programs that use common
> protocols such as HTTP, without having to appeal to third party libraries.
> The Java ecosystem already has plenty of JSON libraries, so inclusion in
> the JDK is largely meant to be a convenience, rather than needing to be the "one
> true" JSON library to meet the needs of all users. Users with specific needs
> are always free to select one of the existing third-party libraries.
> 
> ## Goals and requirements
> 
> Our primary goal is that the library be simple to use for parsing, traversing,
> and generating conformant JSON documents. Advanced features, such as data
> binding or path-based traversal should be possible to implement as layered
> features, but for simplicity are not included in the core API. We adopt a goal
> that the performance should be "good enough", but where performance
> considerations conflict with simplicity and usability, we will choose in favor
> of the latter.
> 
> ## API design approach
> 
> The description of JSON at `https:://json.org` describes a JSON document using
> the familiar "railroad diagram":
> ![image](https://www.json.org/img/value.png)
> 
> This diagram describes an algebraic data type (a sum of products), which we
> model directly with a set of Java interfaces:
> 
> ```
> interface JsonValue { }
> interface JsonArray extends JsonValue { List<JsonValue> values(); }
> interface JsonObject extends JsonValue { Map<String, JsonValue> members(); }
> interface JsonNumber extends JsonValue { Number toNumber(); }
> interface JsonString extends JsonValue { String value(); }
> interface JsonBoolean extends JsonValue  { boolean value(); }
> interface JsonNull extends JsonValue { }
> ```
> 
> These interfaces have (hidden) companion implementation classes that admit
> greater flexibility of implementation than modeling them directly with records
> would permit.
> Further, these interfaces are unsealed. We compromise on the sealed sum of
> products to enable
> alternative implementations, for example to support alternative formats that
> encode the same information in a JSON document but in a more efficient form than
> text.
> 
> The API has static methods for parsing strings into a `JsonValue`, conversion to
> and from purely untyped representations (lists and maps), and factory methods
> for building JSON documents. We apply composition consistently, e.g, a
> JsonString has a string, a JsonObject has a map of string to JsonValue, as
> opposed to extension for structural JSON values.
> 
> It turns out that this simple API is almost all we need for traversal. It gives
> us an immutable representation of a document, and we can use pattern matching to
> answer the myriad questions that will come up (Does this object have key X? Does
> it map to a number? Is that number representable as an integer?) when going
> from an untyped format like JSON to a more strongly typed domain model.
> Given a simple document like:
> 
> ```
>    {
>        "name": "John?,
>        "age": 30
>    }
> ```
> 
> we can parse and traverse the document as follows:
> 
> ```
> JsonValue doc = Json.parse(inputString);
> if (doc instanceof JsonObject o
>    && o.members().get("name") instanceof JsonString s
>    && s.value() instanceof String name
>    && o.members().get("age") instanceof JsonNumber n
>    && n.toNumber() instanceof Long l && l instanceof int age) {
>            // use "name" and "age"
>        }
> ```
> 
> Later, when the language acquires the ability to expose deconstruction patterns
> for arbitrary interfaces (similar to today's record patterns, see
> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns),
> this will be simplifiable to:
> 
> ```
> JsonValue doc = Json.parse(inputString);
> if (doc instanceof JsonObject(var members)
>    && members.get("name") instanceof JsonString(String name)
>    && members.get("age") instanceof JsonNumber(int age)) {
>            // use "name" and "age"
>        }
> ```
> 
> So, overtime, as more pattern matching features are introduced we anticipate
> improved use of the API. This is a primary reason why the API is so minimal.
> Convenience methods we add today, such as a method that accesses a JSON
> object component as say a JSON string or throws an exception, will become
> redundant in the future.
> 
> ## JSON numbers
> 
> The specification of JSON number makes no explicit distinction between integral
> and decimal numbers, nor specifies limits on the size of those numbers.
> This is a common source of interoperability issues when consuming JSON
> documents. Generally users cannot always but often do assume JSON numbers are
> parsable, without loss of precision, to IEEE double-precision floating point
> numbers or 32-bit signed integers.
> 
> In this respect the API provides three means to operate on the JSON number,
> giving the user full control:
> 
> 1. Underlying string representation can be obtained, if preserving syntactic
>   details such as leading or trailing zeros is important.
> 2. The string representation can be parsed to an instance of `BigDecimal`, using
>   `toBigDecimal` if preserving decimal numbers is important.
> 3. The string representation can be parsed into an instance of `Long`, `Double`,
>   `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this method
>   depends on how the representation can be parsed, possibly losing precision,
>   choosing a suitably convenient numeric type that can then be pattern
>   matched on.
> 
> Primitive pattern matching will help as will further pattern matching features
> enabling the user to partially match.
> 
> ## Prototype implementation
> 
> The prototype implementation is currently located into the JDK sandbox
> repository
> under the `json` branch, see
> here
> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json
> The prototype API javadoc generated from the repository is also available at
> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html
> 
> ### Testing and conformance
> 
> The prototype implementation passes all conformance test cases but two,
> available
> on https://github.com/nst/JSONTestSuite. The two exceptions are the ones which
> the
> prototype specifically prohibits, i.e, duplicated names in JSON objects
> (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35).
> 
> ### Performance
> 
> Our main focus so far has been on the API design and a functional
> implementation.
> Hence, there has been less focus on performance even though we know there are a
> number of performance enhancements we can make eventually.
> We are reasonably happy with the current performance. The
> implementation performs well when compared to other JSON implementations
> parsing from string instances and traversing documents.
> 
> An example of where we may choose simplicity and usability over performance
> is the rejection of JSON documents containing objects that in turn contain
> members
> with duplicate names. That may increase the cost of parsing, but simplifies the
> user
> experience for the majority of cases since if we reasonably assume JsonObjects
> are
> map-like, what should the user do with such members, pick one the last one?
> merge
> the values? or reject?
> 
> ## A JSON JEP?
> 
> We plan to draft JEP when we are ready. Attentive readers will observe that
> a JEP already exists, JEP 198: Light-Weight JSON API
> (https://openjdk.org/jeps/198). We will
> either update this JEP, or withdraw it and draft a new one.

From duke at openjdk.org  Thu May 15 21:37:52 2025
From: duke at openjdk.org (Hendrik Schick)
Date: Thu, 15 May 2025 21:37:52 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
In-Reply-To: <iGlPHf8dSXOGgy-Qby4L6bwR_ZfAMVEETLqpnPVN3NQ=.64a2d77a-fb3b-4ee9-89f3-298610dba273@github.com>
References: <iGlPHf8dSXOGgy-Qby4L6bwR_ZfAMVEETLqpnPVN3NQ=.64a2d77a-fb3b-4ee9-89f3-298610dba273@github.com>
Message-ID: <V22a-lYtaRcOepGVzFuYSRjgUqWRopud0sIxYGkjUi4=.7f4b1bb5-be6d-4ba5-b29e-3cc91d187b09@github.com>

On Wed, 14 May 2025 23:51:36 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with Cleaner.
> 
> (The [first PR](https://github.com/openjdk/jdk/pull/8311) for this fix started some substantial discussions, leading to, among other things, the [8314480](https://bugs.openjdk.org/browse/JDK-8314480) `java.lang.ref` memory ordering spec update.)
> 
> In standard fashion, pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved into a _Context_ object. From there, the change is fairly mechanical.
> 
> Details of note:
> 
> 1. Some operations need to change the state values (the `update()` method is probably the most interesting). Use of `reachabilityFence()` ensures memory visibility on the Cleaner thread (per the aforementioned spec update).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's state.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. It confirms that the use of Cleaner does not keep an `LdapSearchEnumeration` object reachable. The other `AbstractLdapNamingEnumeration` subclasses (`LdapNamingEnumeration` and `LdapBindingEnumeration`) can be expected to behave the same.
> 
> Thanks.
> 
> **Edit: (Re)viewers: due to there being a lot of indentation changes, you might consider enabling the "Hide whitespace" option on the "Files changed" tab. To my eye, it gives a better view of the changes.**

test/jdk/com/sun/jndi/ldap/CleanerTests/LdapEnumeration.ldap line 2:

> 1: #
> 2: # Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.

Suggestion:

# Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

(?)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25242#discussion_r2091992166

From henryjen at openjdk.org  Thu May 15 21:57:17 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 15 May 2025 21:57:17 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v8]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <MuvMoKXj9GSHjncG8_kd0Cv4yXEjch_eLzTYSt-bCzI=.94cabdc7-f6d5-4cfa-a7d6-4ed88ad35506@github.com>

> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Adjust message based on review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/1150fb50..1bc1f8cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=06-07

  Stats: 10 lines in 2 files changed: 3 ins; 1 del; 6 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 swen at openjdk.org  Thu May 15 22:01:51 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 15 May 2025 22:01:51 GMT
Subject: RFR: 8357063: Document preconditions for DecimalDigits methods
In-Reply-To: <OwISXF46tqe1eMQsQvcMbcyEWYXnKwOQsZ5UPQ4VXR8=.bf0d2ecf-da85-4786-a45b-3dcfdfc49163@github.com>
References: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
 <OwISXF46tqe1eMQsQvcMbcyEWYXnKwOQsZ5UPQ4VXR8=.bf0d2ecf-da85-4786-a45b-3dcfdfc49163@github.com>
Message-ID: <dO6z5aspAbYYUUyuJYeD2B7Ym0hnQ2ButEyVkGQMCtg=.4161a028-d220-4c9c-87f6-592e48025996@github.com>

On Thu, 15 May 2025 18:12:28 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> @wenshao I understand this is a kind of followup of #24982, but why this title? It seems just renaming some methods with more speaking names.

Yes, it is just a renaming of some methods, the title is followup #24982, does the same thing, so uses the same title

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25246#issuecomment-2885146769

From henryjen at openjdk.org  Thu May 15 22:03:52 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 15 May 2025 22:03:52 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v6]
In-Reply-To: <eF015vnVzEp-5sqCQ9q6hmfE_AVQbCmJkNcoSG7BTrc=.9a91c482-3db5-4db9-9e28-eec44cdefe3c@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <Uvb8haTDHaSUlFccwMonvOOpnMogpbjr2KpffroxpmQ=.0e863939-4729-4ab6-9d67-f276570e9084@github.com>
 <kqx3sTJHVWdZpzTKzo7Ak7bYnBJqbLD1hkkJtK4okwg=.e26d85ff-7ea4-40e1-8593-dd424a0739de@github.com>
 <eF015vnVzEp-5sqCQ9q6hmfE_AVQbCmJkNcoSG7BTrc=.9a91c482-3db5-4db9-9e28-eec44cdefe3c@github.com>
Message-ID: <oLzSUYfFRmJx5u0PQ_sCrNQ_GcCMcWAL4oTYTBgYKUE=.195065c9-9241-441f-b338-cb106238c9a4@github.com>

On Wed, 7 May 2025 18:00:23 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 127:
>> 
>>> 125: 
>>> 126:         public DedupEntryNames(boolean isCEN) {
>>> 127:             this.isCEN = isCEN;
>> 
>> Might be clearer if this was an enum vs boolean?
>
> I feel the same way but wondering if that's an overkill.

Refactored to consolidate validation on entries into a standalone EntryValidator. Hope that's easier to understand.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2092018706

From henryjen at openjdk.org  Thu May 15 22:03:54 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 15 May 2025 22:03:54 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v6]
In-Reply-To: <kqx3sTJHVWdZpzTKzo7Ak7bYnBJqbLD1hkkJtK4okwg=.e26d85ff-7ea4-40e1-8593-dd424a0739de@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <Uvb8haTDHaSUlFccwMonvOOpnMogpbjr2KpffroxpmQ=.0e863939-4729-4ab6-9d67-f276570e9084@github.com>
 <kqx3sTJHVWdZpzTKzo7Ak7bYnBJqbLD1hkkJtK4okwg=.e26d85ff-7ea4-40e1-8593-dd424a0739de@github.com>
Message-ID: <L1vMczkBh8bC7NSDRxKyHFZCD_OpI7IzEo6gZz_9VZ4=.f3489630-fdf3-460f-b5f8-84ca8ebf4210@github.com>

On Wed, 7 May 2025 17:28:34 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore Validator access level
>
> test/jdk/tools/jar/ValidatorTest.java line 232:
> 
>> 230:             var err = e.getMessage();
>> 231:             System.out.println(err);
>> 232:             Assertions.assertTrue(err.contains("Warning: 2 copies of META-INF/MANIFEST.MF is detected in local file header"));
> 
> Given you are importing Assertions, you should be able to just use `assertTrue`

I didn't use static import. Since that seems to be preferred, I changed to do static imports.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2092017390

From rgiulietti at openjdk.org  Thu May 15 22:05:56 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 15 May 2025 22:05:56 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v6]
In-Reply-To: <Fe1FcysTPgZYA1aEUGFHRfBxnQ_QkYXJ-4it0QscrS8=.7c1fa510-c570-481c-aa40-5cca05667f34@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <Fe1FcysTPgZYA1aEUGFHRfBxnQ_QkYXJ-4it0QscrS8=.7c1fa510-c570-481c-aa40-5cca05667f34@github.com>
Message-ID: <hoQilPfsm719vv9gOH4kkZVdLoTONdoWfOA0XK1FPHg=.bef64c99-7b68-40a7-b570-68700336de11@github.com>

On Thu, 15 May 2025 15:37:39 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make magBitLength() an instance method

There are problems with the `test/jdk/java/math/BigInteger` tests. Can you please crosscheck?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2885152927

From bpb at openjdk.org  Thu May 15 22:09:55 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 15 May 2025 22:09:55 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <hGdOD6yiBZLJlqN471s_uxxFaCMnNI_U8mjqEgs3SW8=.ae5e1e63-6618-46f3-a659-020d3b10be3a@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
 <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>
 <nCFdoAHy2RkNENhaRhdaMDbO3iiAuV-AsirMDJoS0Dc=.0177c4cd-1e71-494f-8956-13edc7eb0551@github.com>
 <BctFVukNg2CVXVsPVF96howIOf-A8N_G-AIClpaqmgE=.53d54891-c098-4922-81c7-ddd0818c647d@github.com>
 <apAsxR7rrX0ofU-2q3GVqq_uWkKTD8u4sw7zKeYCT2k=.c4f73ab2-cc66-4f98-b668-de356b788849@github.com>
 <f9my7Gq_OjkXWTBa2L2h1EFIgMpA5PuFf5xndOfcwlM=.e87667ba-d5eb-48aa-be35-05d52ac81212@github.com>
 <Y2P9dJdshrswViDiOGTS14EdODFTMxF7Z1fyDuiQdsA=.d182371a-d1ad-482f-8ff1-d01d06737a32@github.com>
 <g1GHppLlTaHjuFACIi8dgMvNZfQA81ctofGglGZXAXk=.73477b96-4dd8-45ca-9bae-f3a15d8ce8c1@github.com>
 <cnVCW6f3cE8qRMTn_8PMfPX8NPB8WhEcTJb
 jp_Zz3MY=.a4fe61f7-1a2a-4528-91a9-fde9cae8acfa@github.com>
 <jOzAzf7qiUGaR4AcVxkVruHyXr7-SLNU2pRV_z8iojk=.0c07b2ec-c8e7-4170-84e8-d1baed0afde0@github.com>
 <F6Kjz5iF9Y5R0V8LuRCuX_JtmI6Ohtzksy96kGzDUY8=.a461b9e5-02dd-4226-aced-cf4f910b01b0@github.com>
 <PIGolcNUOTm_uea2SMpu6zMF_8imtmuC_RiCTCTPIvU=.0845a60f-3eab-43cd-8956-9d10fbd5c439@github.com>
 <5ue1HrdcMPaWc9wOSsLvvQaf6n8bWRrBP9CN7jeueF4=.7ff273a1-2a42-4fea-9e44-ba18d895aef7@github.com>
 <Z0MNw-9D1C8zjcbDe12HXswjvK6a9snK72C3GsTlEKc=.621ac45f-e0c1-4cc7-9bf7-e9f574f9e726@github.com>
 <aJ9fvCIO__WTmGt8g47BHC5UYpVQhvTVLVuP1RGOjR4=.f4fd111a-bfc3-4295-9f9f-41c9bdf56613@github.com>
 <hGdOD6yiBZLJlqN471s_uxxFaCMnNI_U8mjqEgs3SW8=.ae5e1e63-6618-46f3-a659-020d3b10be3a@github.com>
Message-ID: <6R_dYDxxb9DRXAYBzENkNbRAn4rzQvNJmhd5KQPRj_g=.306a738b-b82b-4da4-a762-b7bd0cbe2f47@github.com>

On Thu, 15 May 2025 11:01:36 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Thanks for the examples. Imho I think that performance sensitive, specialised code can invest some lines to put together the best solution for the context whereas the majority of code can simply use a convenient `reader.readAllAsString()` instead of `reader.readAllAsCharSequence().toString()` which is borderline to parody.
>
> It is **impossible** to "invest some lines" to solve this in JAX-RS, and JAX-RS as a standard technology on tens of thousands of servers. Enforcing `String` prevents these useful optimizations, but brings *no actual benefit*, as *only few* callers actually care for *constant* objects, but would be satisfied with `CharSequence`'s lack of mutation methods.

> Also, in JAX-RS for example, you cannot make use of `transferTo` as what you get is a heap object, and what you must forward also is a heap object.

What relation does such a "heap object" have to character streams?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2092023770

From vromero at openjdk.org  Thu May 15 22:32:12 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 22:32:12 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v16]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <GzzgfleafLsCdPZxFZ05PIGjejVSBNdfn-OU4eJMBBA=.60c11dfc-876e-4719-8e57-659ca5554cfe@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/6c8d2b1d..def2505f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=14-15

  Stats: 18 lines in 1 file changed: 1 ins; 4 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

PR: https://git.openjdk.org/jdk/pull/24746

From vromero at openjdk.org  Thu May 15 22:36:58 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 22:36:58 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v13]
In-Reply-To: <LH5l3EylBKng_NqAM062OyAsMoB62Pc3LMFhNlV1y00=.3ceab033-5328-40bb-8bdd-ac7c6dcb055d@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <QvL1wMiufgj6kq6NBb2ciWTkVQ28MWWIWRmGE47mVHs=.08668b90-b5eb-4272-af23-5c501fccf079@github.com>
 <LH5l3EylBKng_NqAM062OyAsMoB62Pc3LMFhNlV1y00=.3ceab033-5328-40bb-8bdd-ac7c6dcb055d@github.com>
Message-ID: <juZlcfGRQPU29v_XUPougKrcEsvn2UhhbqVM6lpSS3k=.2f580724-0899-4445-ad02-92dc844ed500@github.com>

On Wed, 14 May 2025 18:27:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
>> 
>>  - Merge branch 'master' into JDK-8354556
>>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>>    
>>    Co-authored-by: Chen Liang <liach at openjdk.org>
>>  - additional changes from Archie
>>  - removing dead code
>>  - integrating code from Archie
>>  - fixing bugs, removing dead code
>>  - additional documentation changes and bug fixes
>>  - documentation and adding alias to lint categories
>>  - Merge branch 'master' into JDK-8354556
>>  - addressing review comment
>>  - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5823:
> 
>> 5821:                 SymbolMetadata sm = t.tsym.getMetadata();
>> 5822:                 if (sm != null && !t.getTypeArguments().isEmpty()) {
>> 5823:                     for (Attribute.TypeCompound ta: sm.getTypeAttributes().stream()
> 
> The code here, and the code in `checkIfTypeParamsRequiresIdentity` look similar a lot (although they manipulate `List<Type>` and `List<JCExpression>`, of course. I wonder if there's a chance to share the code, at least partially.

I have rewritten both using streams, technically we could still reuse some code but not a big deal, dunno

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2092053355

From bpb at openjdk.org  Thu May 15 22:42:15 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 15 May 2025 22:42:15 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v4]
In-Reply-To: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
Message-ID: <66pv5IvWk1pnQbXk3swAPR46Zfxt7L7VXPMIod0X3tk=.38446b76-4ef7-4702-929a-fabf3497080b@github.com>

> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired.

Brian Burkhalter has updated the pull request with a new target base 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:

 - 8355954: Simplify test
 - Merge
 - 8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set
 - 8355954: Address comments on naming in the PR
 - 8355954: File.delete removes read-only files (win)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24977/files
  - new: https://git.openjdk.org/jdk/pull/24977/files/0fef4782..352c54dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=02-03

  Stats: 53700 lines in 1729 files changed: 33644 ins; 11237 del; 8819 mod
  Patch: https://git.openjdk.org/jdk/pull/24977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24977/head:pull/24977

PR: https://git.openjdk.org/jdk/pull/24977

From swen at openjdk.org  Thu May 15 22:46:54 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 15 May 2025 22:46:54 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v6]
In-Reply-To: <Fe1FcysTPgZYA1aEUGFHRfBxnQ_QkYXJ-4it0QscrS8=.7c1fa510-c570-481c-aa40-5cca05667f34@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <Fe1FcysTPgZYA1aEUGFHRfBxnQ_QkYXJ-4it0QscrS8=.7c1fa510-c570-481c-aa40-5cca05667f34@github.com>
Message-ID: <nzlgNFOS19-pWtj6EjtduLAMgwO1vXjn81Fi9gCBws0=.02b124e4-a9e2-48db-994d-42bfbc62cdbc@github.com>

On Thu, 15 May 2025 15:37:39 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make magBitLength() an instance method

src/java.base/share/classes/java/math/BigInteger.java line 3860:

> 3858:                 && Integer.lowestOneBit(mag[0]) == mag[0]
> 3859:                 && numberOfTrailingZeroInts() == mag.length - 1
> 3860:             ? magBitLength() - 1 : magBitLength();

Suggestion:

        int[] mag = this.mag;
        return magBitLength() 
                - (signum < 0
                   // Check if magnitude is a power of two
                   && Integer.lowestOneBit(mag[0]) == mag[0]
                   && numberOfTrailingZeroInts() == mag.length - 1
                   ? 1 : 0);


In this way, codeSize will drop from 52 to 45

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2092060927

From ethan at mccue.dev  Thu May 15 23:44:52 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Fri, 16 May 2025 01:44:52 +0200
Subject: Towards a JSON API for the JDK
In-Reply-To: <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CA+NR86gt3GNjDPS2m-2wha5AwgumMvBRxKw+bwgTCNQ1xCiDfg@mail.gmail.com>

I present for your consideration the library I made when spiraling about
this problem space a few years ago

https://github.com/bowbahdoe/json

https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html

Notably missing during the design process here were patterns, hence the
JsonDecoder design. I haven't been able to evaluate how patterns affect
that on account of them not being out.

I will more thoroughly peruse the draft of java.util.json at a later date,
but my initial observations/comments:

* I am not sure having JsonValue be distinct from Json has value.
* toUntyped feels a little strange to me - the only type information
presumably lost is the sealed-ness of the hierarchy. The interplay between
that and toNumber is also a little unnerving.
* One notion that I found helpful was that a class could be "json
encodable," meaning there is a method to call to obtain a canonical json
representation.

record Person(String name) implements JsonEncodable {
    @Override
    public Json toJson() {
        return Json.objectBuilder()
            .put("namen", name)
            .build();
    }
}

Which helper methods like Json#of(List<? extends JsonEncodable>) could make
use of. Json itself (JsonValue in your prototype) could then have a vacuous
implementation.

* Terminology wise - I went with reading/writing for the actual
parsing/generation of json and encoding/decoding for the mapping of those
representations to/from specific classes. The merits are not top of mind,
just noting the difference. read/write vs parse/toString+toDisplayString
* One thing I did was make the helper methods in Json null tolerant and the
ones in the specific subtypes like JsonString not. This was because from
what I saw of usages of javax.json/jakarta.json that nullability was a
footgun and correcting for it required changes to code structure (breaking
up builder chains with if (x != null) checks)
* The functionality you want from JsonNumber could be achieved by making it
just extend Number (
https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/JsonNumber.java)
instead of a bespoke toNumber. You need the extra methods to go to big
decimal and co, but it's just an extension to the behavior of Number at
that point.
* JsonObject and JsonArray could implement Map<String, Json> and List<Json>
respectively. This lowers the need for toUntyped() - since presumably one
of the use cases for that is turning the json tree into something that more
generic map/list traversal code can handle. It also complicates any lazy
loading somewhat.
* Assuming patterns can be placed on interfaces, you might want to consider
something similar to JsonDecoder, but with a pattern instead of a method
that throws an exception.

// Where here fromJson would box up the logic for testing and extracting
from each element in the array.
List<Person> people = array(json, Person::fromJson);

* I don't think there is sufficient cause for anything to be non-sealed at
this point.
* JsonBoolean and JsonNull do not have reasonable alternative
implementations - as far as I can imagine, maybe i'm wrong - so maybe those
can just be final classes?
* If you seal up the whole hierarchy then its pretty trivial to make it
serializable (
https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/serialization/JsonSerializationProxy.java
)




On Thu, May 15, 2025 at 11:29?PM Remi Forax <forax at univ-mlv.fr> wrote:

> Hi Paul,
> yes, not having a simple JSON API in Java is an issue for beginners.
>
> It's not clear to me why JsonArray (for example) has to be an interface
> instead of a record ?
>
> I understand why Json.parse() only works on String and char[] but the API
> make it too easy to have many performance issues.
> I think you need versions using a Reader and a Path.
> Bonus point, if there is a method walk() that also returns a JsonValue but
> the List/Map inside JsonArray/JsonObject are populated lazily.
>
> Minor point: Json.toDisplayString() should takes a second parameters
> indicating the number of spaces used for the indentation (like
> JSON.stringify in JS).
>
> regards,
> R?mi
>
> ----- Original Message -----
> > From: "Paul Sandoz" <paul.sandoz at oracle.com>
> > To: "core-libs-dev" <core-libs-dev at openjdk.org>
> > Sent: Thursday, May 15, 2025 10:30:42 PM
> > Subject: Towards a JSON API for the JDK
>
> > Hi,
> >
> > We would like to share with you our thoughts and plans towards a JSON
> API for
> > the JDK.
> > Please see the document below.
> >
> > -
> >
> > We have had the pleasure of using a clone of this API in some
> experiments we are
> > conducting with
> > ONNX and code reflection [1]. Using the API we were able to quickly
> write code
> > to ingest and convert
> > a JSON document representing ONNX operation schema into instances of
> records
> > modeling the schema
> > (see here [2]).
> >
> > The overall out-of-box experience with such a minimal "batteries
> included? API
> > has so far been positive.
> >
> > Thanks,
> > Paul.
> >
> > [1] https://openjdk.org/projects/babylon/
> > [2]
> >
> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87
> >
> > # Towards a JSON API for the JDK
> >
> > One of the most common requests for the JDK is an API for parsing and
> generating
> > JSON. While JSON originated as a text-based serialization format for JSON
> > objects ("JSON" stands for "JavaScript Object Notation"), because of its
> simple
> > and flexible syntax, it eventually found use outside the JavaScript
> ecosystem as
> > a general data interchange format, such as framework configuration files
> and web
> > service requests/response formats.
> >
> > While the JDK cannot, and should not, provide libraries for every
> conceivable
> > file format or protocol, the JDK philosophy is one of "batteries
> included",
> > which is to say we should be able to write basic programs that use common
> > protocols such as HTTP, without having to appeal to third party
> libraries.
> > The Java ecosystem already has plenty of JSON libraries, so inclusion in
> > the JDK is largely meant to be a convenience, rather than needing to be
> the "one
> > true" JSON library to meet the needs of all users. Users with specific
> needs
> > are always free to select one of the existing third-party libraries.
> >
> > ## Goals and requirements
> >
> > Our primary goal is that the library be simple to use for parsing,
> traversing,
> > and generating conformant JSON documents. Advanced features, such as data
> > binding or path-based traversal should be possible to implement as
> layered
> > features, but for simplicity are not included in the core API. We adopt
> a goal
> > that the performance should be "good enough", but where performance
> > considerations conflict with simplicity and usability, we will choose in
> favor
> > of the latter.
> >
> > ## API design approach
> >
> > The description of JSON at `https:://json.org` describes a JSON
> document using
> > the familiar "railroad diagram":
> > ![image](https://www.json.org/img/value.png)
> >
> > This diagram describes an algebraic data type (a sum of products), which
> we
> > model directly with a set of Java interfaces:
> >
> > ```
> > interface JsonValue { }
> > interface JsonArray extends JsonValue { List<JsonValue> values(); }
> > interface JsonObject extends JsonValue { Map<String, JsonValue>
> members(); }
> > interface JsonNumber extends JsonValue { Number toNumber(); }
> > interface JsonString extends JsonValue { String value(); }
> > interface JsonBoolean extends JsonValue  { boolean value(); }
> > interface JsonNull extends JsonValue { }
> > ```
> >
> > These interfaces have (hidden) companion implementation classes that
> admit
> > greater flexibility of implementation than modeling them directly with
> records
> > would permit.
> > Further, these interfaces are unsealed. We compromise on the sealed sum
> of
> > products to enable
> > alternative implementations, for example to support alternative formats
> that
> > encode the same information in a JSON document but in a more efficient
> form than
> > text.
> >
> > The API has static methods for parsing strings into a `JsonValue`,
> conversion to
> > and from purely untyped representations (lists and maps), and factory
> methods
> > for building JSON documents. We apply composition consistently, e.g, a
> > JsonString has a string, a JsonObject has a map of string to JsonValue,
> as
> > opposed to extension for structural JSON values.
> >
> > It turns out that this simple API is almost all we need for traversal.
> It gives
> > us an immutable representation of a document, and we can use pattern
> matching to
> > answer the myriad questions that will come up (Does this object have key
> X? Does
> > it map to a number? Is that number representable as an integer?) when
> going
> > from an untyped format like JSON to a more strongly typed domain model.
> > Given a simple document like:
> >
> > ```
> >    {
> >        "name": "John?,
> >        "age": 30
> >    }
> > ```
> >
> > we can parse and traverse the document as follows:
> >
> > ```
> > JsonValue doc = Json.parse(inputString);
> > if (doc instanceof JsonObject o
> >    && o.members().get("name") instanceof JsonString s
> >    && s.value() instanceof String name
> >    && o.members().get("age") instanceof JsonNumber n
> >    && n.toNumber() instanceof Long l && l instanceof int age) {
> >            // use "name" and "age"
> >        }
> > ```
> >
> > Later, when the language acquires the ability to expose deconstruction
> patterns
> > for arbitrary interfaces (similar to today's record patterns, see
> >
> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns
> ),
> > this will be simplifiable to:
> >
> > ```
> > JsonValue doc = Json.parse(inputString);
> > if (doc instanceof JsonObject(var members)
> >    && members.get("name") instanceof JsonString(String name)
> >    && members.get("age") instanceof JsonNumber(int age)) {
> >            // use "name" and "age"
> >        }
> > ```
> >
> > So, overtime, as more pattern matching features are introduced we
> anticipate
> > improved use of the API. This is a primary reason why the API is so
> minimal.
> > Convenience methods we add today, such as a method that accesses a JSON
> > object component as say a JSON string or throws an exception, will become
> > redundant in the future.
> >
> > ## JSON numbers
> >
> > The specification of JSON number makes no explicit distinction between
> integral
> > and decimal numbers, nor specifies limits on the size of those numbers.
> > This is a common source of interoperability issues when consuming JSON
> > documents. Generally users cannot always but often do assume JSON
> numbers are
> > parsable, without loss of precision, to IEEE double-precision floating
> point
> > numbers or 32-bit signed integers.
> >
> > In this respect the API provides three means to operate on the JSON
> number,
> > giving the user full control:
> >
> > 1. Underlying string representation can be obtained, if preserving
> syntactic
> >   details such as leading or trailing zeros is important.
> > 2. The string representation can be parsed to an instance of
> `BigDecimal`, using
> >   `toBigDecimal` if preserving decimal numbers is important.
> > 3. The string representation can be parsed into an instance of `Long`,
> `Double`,
> >   `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this
> method
> >   depends on how the representation can be parsed, possibly losing
> precision,
> >   choosing a suitably convenient numeric type that can then be pattern
> >   matched on.
> >
> > Primitive pattern matching will help as will further pattern matching
> features
> > enabling the user to partially match.
> >
> > ## Prototype implementation
> >
> > The prototype implementation is currently located into the JDK sandbox
> > repository
> > under the `json` branch, see
> > here
> >
> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json
> > The prototype API javadoc generated from the repository is also
> available at
> >
> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html
> >
> > ### Testing and conformance
> >
> > The prototype implementation passes all conformance test cases but two,
> > available
> > on https://github.com/nst/JSONTestSuite. The two exceptions are the
> ones which
> > the
> > prototype specifically prohibits, i.e, duplicated names in JSON objects
> > (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35
> ).
> >
> > ### Performance
> >
> > Our main focus so far has been on the API design and a functional
> > implementation.
> > Hence, there has been less focus on performance even though we know
> there are a
> > number of performance enhancements we can make eventually.
> > We are reasonably happy with the current performance. The
> > implementation performs well when compared to other JSON implementations
> > parsing from string instances and traversing documents.
> >
> > An example of where we may choose simplicity and usability over
> performance
> > is the rejection of JSON documents containing objects that in turn
> contain
> > members
> > with duplicate names. That may increase the cost of parsing, but
> simplifies the
> > user
> > experience for the majority of cases since if we reasonably assume
> JsonObjects
> > are
> > map-like, what should the user do with such members, pick one the last
> one?
> > merge
> > the values? or reject?
> >
> > ## A JSON JEP?
> >
> > We plan to draft JEP when we are ready. Attentive readers will observe
> that
> > a JEP already exists, JEP 198: Light-Weight JSON API
> > (https://openjdk.org/jeps/198). We will
> > either update this JEP, or withdraw it and draft a new one.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250516/e0cf80a2/attachment-0001.htm>

From valeriep at openjdk.org  Thu May 15 23:52:53 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 15 May 2025 23:52:53 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v7]
In-Reply-To: <vNY7UaUfDQbUMHYep-RikluWmdvHfsH6s8bev3nvhMM=.f7dc3bc4-041a-4854-a9f0-20c5dc82f2da@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <vNY7UaUfDQbUMHYep-RikluWmdvHfsH6s8bev3nvhMM=.f7dc3bc4-041a-4854-a9f0-20c5dc82f2da@github.com>
Message-ID: <zo2M5TJ2zl-9cJjI0_7LX7M-D52GImRSwfepZ2nfciU=.2e16dbda-06fa-425d-a0d0-9952babdb9e9@github.com>

On Fri, 9 May 2025 20:05:10 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Finalize the KDF API.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   new algorithms in SunJCE

Updates look good. Thanks~

-------------

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24520#pullrequestreview-2845203782

From swen at openjdk.org  Thu May 15 23:57:31 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 15 May 2025 23:57:31 GMT
Subject: RFR: 8357081: Removed unused methods of HexDigits
Message-ID: <NmneRyd1Xg5PGjAiG1Pgq5dqkWMiE23LRjALLutkoyA=.912425d2-b549-40f7-bea2-46f2f869fa30@github.com>

In HexDigits, getCharsLatin1 and getCharsUTF16 are no longer used, so remove these methods

-------------

Commit messages:
 - remove unused code

Changes: https://git.openjdk.org/jdk/pull/25258/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25258&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357081
  Stats: 69 lines in 1 file changed: 0 ins; 69 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25258/head:pull/25258

PR: https://git.openjdk.org/jdk/pull/25258

From bchristi at openjdk.org  Thu May 15 23:59:41 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 15 May 2025 23:59:41 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v2]
In-Reply-To: <iGlPHf8dSXOGgy-Qby4L6bwR_ZfAMVEETLqpnPVN3NQ=.64a2d77a-fb3b-4ee9-89f3-298610dba273@github.com>
References: <iGlPHf8dSXOGgy-Qby4L6bwR_ZfAMVEETLqpnPVN3NQ=.64a2d77a-fb3b-4ee9-89f3-298610dba273@github.com>
Message-ID: <8r28eulzOwmt6cxFjNPLg5zujXD1o1CEiPUqP4dHxvM=.3b8e608a-b97c-4ebd-8094-6e2e6d8f33e1@github.com>

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with Cleaner.
> 
> (The [first PR](https://github.com/openjdk/jdk/pull/8311) for this fix started some substantial discussions, leading to, among other things, the [8314480](https://bugs.openjdk.org/browse/JDK-8314480) `java.lang.ref` memory ordering spec update.)
> 
> In standard fashion, pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved into a _Context_ object. From there, the change is fairly mechanical.
> 
> Details of note:
> 
> 1. Some operations need to change the state values (the `update()` method is probably the most interesting). Use of `reachabilityFence()` ensures memory visibility on the Cleaner thread (per the aforementioned spec update).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's state.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. It confirms that the use of Cleaner does not keep an `LdapSearchEnumeration` object reachable. The other `AbstractLdapNamingEnumeration` subclasses (`LdapNamingEnumeration` and `LdapBindingEnumeration`) can be expected to behave the same.
> 
> Thanks.
> 
> **Edit: (Re)viewers: due to there being a lot of indentation changes, you might consider enabling the "Hide whitespace" option on the "Files changed" tab. To my eye, it gives a better view of the changes.**

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  update copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25242/files
  - new: https://git.openjdk.org/jdk/pull/25242/files/e36cf5db..c3a94433

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25242&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25242&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25242.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25242/head:pull/25242

PR: https://git.openjdk.org/jdk/pull/25242

From bchristi at openjdk.org  Thu May 15 23:59:41 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 15 May 2025 23:59:41 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v2]
In-Reply-To: <V22a-lYtaRcOepGVzFuYSRjgUqWRopud0sIxYGkjUi4=.7f4b1bb5-be6d-4ba5-b29e-3cc91d187b09@github.com>
References: <iGlPHf8dSXOGgy-Qby4L6bwR_ZfAMVEETLqpnPVN3NQ=.64a2d77a-fb3b-4ee9-89f3-298610dba273@github.com>
 <V22a-lYtaRcOepGVzFuYSRjgUqWRopud0sIxYGkjUi4=.7f4b1bb5-be6d-4ba5-b29e-3cc91d187b09@github.com>
Message-ID: <-pQm_zdR4S8AnRj6ROFJxxTi1n6jTW1OlPTenwnuPm4=.50de719e-8fbc-46b8-b27f-e967e3ad8ee6@github.com>

On Thu, 15 May 2025 21:35:14 GMT, Hendrik Schick <duke at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright
>
> test/jdk/com/sun/jndi/ldap/CleanerTests/LdapEnumeration.ldap line 2:
> 
>> 1: #
>> 2: # Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Suggestion:
> 
> # Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
> 
> (?)

Copyright updated, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25242#discussion_r2092116149

From almatvee at openjdk.org  Fri May 16 01:53:01 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 16 May 2025 01:53:01 GMT
Subject: RFR: 8333664: Decouple command line parsing and package building
 in jpackage [v4]
In-Reply-To: <_IWCckFl77gXXM8TOCh1GlDTBrqrHTvJjNvvcaGt3-A=.7f61f15f-a5bf-4182-b609-1f3d6e199d89@github.com>
References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>
 <_IWCckFl77gXXM8TOCh1GlDTBrqrHTvJjNvvcaGt3-A=.7f61f15f-a5bf-4182-b609-1f3d6e199d89@github.com>
Message-ID: <4GqhkY0xKEKx5h6p3aLH-1ooMcWVmWZksJyKsAdBdec=.41398343-bbf0-4e1a-b25e-378a359439f0@github.com>

On Sat, 10 May 2025 19:02:45 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Refactor jpackage to separate the configuration and execution phases.
>> At the configuration phase, jpackage parses command-line arguments and validates them.
>> At the execution phase, jpackage builds a bundle based on data collected at the configuration phase.
>> 
>> There was no clear separation between these phases. Both used the same data type (`Map<String, Object>`), making it hard to understand and use properly.
>> 
>> This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling.
>> 
>> The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map<String, Object>` "params".
>> 
>> Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers.
>> 
>> jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html
>> 
>> **Functional changes**
>> jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below.
>> 
>>  - Minimize copying of the source app image when doing native packaging.
>> 
>> Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations.
>> 
>> - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles.
>> 
>> post- and pre- install PKG scripts for SimplePackageTest package before and after the change:
>> <table>
>> <thead>
>> <tr>
>> <th>Scr...
>
> Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 512 commits:
> 
>  - Add ConfigFilesStasher that allows to save contents of jpackage build directories in external directory; Add clean_stashed_files.sh
>  - Merge branch 'master' into JDK-8333664
>  - Remove redundant StandardBundlerParam.createResource()
>  - Adapt JDK-8352480 fix
>  - Merge branch 'master' into JDK-8333664
>  - Fix javadoc
>  - Merge branch 'master' into JDK-8333664
>  - 8333568: Test that jpackage doesn't modify R/O files/directories
>    
>    Reviewed-by: almatvee
>  - 8356562: SigningAppImageTwoStepsTest test fails
>    
>    Reviewed-by: almatvee
>  - Remove clean_stashed_files.sh
>  - ... and 502 more: https://git.openjdk.org/jdk/compare/43696030...011eb710

Looks good with minor comments.

src/jdk.jpackage/linux/classes/jdk/jpackage/internal/DesktopIntegration.java line 337:

> 335:      */
> 336:     private InstallableFile createDesktopFile(String fileName) {
> 337:         var srcPath = pkg.asPackageApplicationLayout().orElseThrow().resolveAt(env.appImageDir()).destktopIntegrationDirectory().resolve(fileName);

`destktop` -> `desktop`

src/jdk.jpackage/linux/classes/jdk/jpackage/internal/DesktopIntegration.java line 477:

> 475:             return Optional.of(fa)
> 476:                     .flatMap(FileAssociation::icon)
> 477:                     .map(DesktopIntegration::getSquareSizeOfImage)

`getSquareSizeOfImage` will return 0, if exception is thrown for invalid image. Should it return -1 or should we only accept icons if `getIconSize() > 0`?

src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageDesc.java line 33:

> 31: import jdk.jpackage.internal.model.ApplicationLayout;
> 32: 
> 33: record AppImageDesc(AppImageLayout appImageLyout, Path path) {

`appImageLyout` -> `appImageLayout`

src/jdk.jpackage/share/classes/jdk/jpackage/internal/BuildEnvBuilder.java line 51:

> 49:         } else if (!Files.isDirectory(root)) {
> 50:             throw exceptionBuilder.create();
> 51:         } else {

Maybe rewrite to:

if (!Files.isDirectory(root)) {
    throw exceptionBuilder.create();
} else if (Files.exists(root)) {
...
}

src/jdk.jpackage/share/classes/jdk/jpackage/internal/PackageBuilder.java line 65:

> 63:                         installDirName = Optional.empty();
> 64:                     }
> 65:                     case MAC_DMG,MAC_PKG -> {

`MAC_DMG,MAC_PKG` -> `MAC_DMG, MAC_PKG`

src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/package-info.java line 34:

> 32:  * All methods of all interfaces and classes in this package return non-null values unless stated otherwise.
> 33:  */
> 34: package jdk.jpackage.internal.model;

Missing new line.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/CompositeProxy.java line 200:

> 198:      *     static final CompositeProxyTunnel INSTANCE = new CompositeProxyTunnel();
> 199:      * }
> 200:      * }

Extra `}`

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixAppImageFragmentBuilder.java line 940:

> 938:             var launchers = Optional.ofNullable(pkg.app().launchers()).map(
> 939:                     List::stream).orElseGet(Stream::of);
> 940:             return  launchers.map(launcher -> {

Extra space.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19668#pullrequestreview-2835056108
PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2085771680
PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2085785398
PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2089916849
PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2089955028
PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2090064291
PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2090100387
PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2092111270
PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2092154401

From duke at openjdk.org  Fri May 16 01:56:12 2025
From: duke at openjdk.org (ExE Boss)
Date: Fri, 16 May 2025 01:56:12 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v25]
In-Reply-To: <JyUc5SImg9QKVkHLM--Ot6izXoJC9G1KSLIXrMTHhzw=.f9178ce3-baa7-4abd-83d0-43af63ac02d8@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <JyUc5SImg9QKVkHLM--Ot6izXoJC9G1KSLIXrMTHhzw=.f9178ce3-baa7-4abd-83d0-43af63ac02d8@github.com>
Message-ID: <91AvxL2hdhCWd8lxr02P06XS4HxDNH_xXF7aOU1CX54=.2a8da24d-e3c5-4aae-9d91-b2656d50ac4f@github.com>

On Wed, 19 Jun 2024 09:08:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removed empty line
>  - problem-listed runtime/ClassInitErrors/TestStackOverflowDuringInit.java

Changes requested by ExE-Boss at github.com (no known OpenJDK username).

src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 562:

> 560:     private static byte[] generateCodeBytesForLFs(String className, String[] names, LambdaForm[] forms) {
> 561:         return ClassFile.of().build(ClassDesc.ofInternalName(className), clb -> {
> 562:             clb.withFlags(ACC_PRIVATE | ACC_FINAL | ACC_SUPER)

`ACC_PRIVATE` is?not a?valid access?flag for?a?class, those?only?allow public or?package?access[^1]:
Suggestion:

            clb.withFlags(ACC_FINAL | ACC_SUPER)


[^1]: See?**JVMS** [Table?4.1?B](https://docs.oracle.com/javase/specs/jvms/se24/html/jvms-4.html#jvms-4.1-200-E.1)

-------------

PR Review: https://git.openjdk.org/jdk/pull/17108#pullrequestreview-2845315645
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r2092193712

From liach at openjdk.org  Fri May 16 02:05:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 16 May 2025 02:05:11 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v25]
In-Reply-To: <91AvxL2hdhCWd8lxr02P06XS4HxDNH_xXF7aOU1CX54=.2a8da24d-e3c5-4aae-9d91-b2656d50ac4f@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <JyUc5SImg9QKVkHLM--Ot6izXoJC9G1KSLIXrMTHhzw=.f9178ce3-baa7-4abd-83d0-43af63ac02d8@github.com>
 <91AvxL2hdhCWd8lxr02P06XS4HxDNH_xXF7aOU1CX54=.2a8da24d-e3c5-4aae-9d91-b2656d50ac4f@github.com>
Message-ID: <AgutOt6JO3oOkfa_sU1J9WFn7N_IVU61xXGOPYpq8cQ=.acfd7793-9abd-49b7-bdd0-528872d1cb53@github.com>

On Fri, 16 May 2025 01:50:06 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - removed empty line
>>  - problem-listed runtime/ClassInitErrors/TestStackOverflowDuringInit.java
>
> src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 562:
> 
>> 560:     private static byte[] generateCodeBytesForLFs(String className, String[] names, LambdaForm[] forms) {
>> 561:         return ClassFile.of().build(ClassDesc.ofInternalName(className), clb -> {
>> 562:             clb.withFlags(ACC_PRIVATE | ACC_FINAL | ACC_SUPER)
> 
> `ACC_PRIVATE` is?not a?valid access?flag for?a?class, those?only?allow public or?package?access[^1]:
> Suggestion:
> 
>             clb.withFlags(ACC_FINAL | ACC_SUPER)
> 
> 
> [^1]: See?**JVMS** [Table?4.1?B](https://docs.oracle.com/javase/specs/jvms/se24/html/jvms-4.html#jvms-4.1-200-E.1)

It has been there and also for injected invoker template. Can be safely ignored.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r2092203326

From thomas.stuefe at gmail.com  Fri May 16 04:10:31 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 16 May 2025 06:10:31 +0200
Subject: ProcessImpl: Can we obsolete the vfork mode?
In-Reply-To: <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com>
References: <CAA-vtUz19h6x4noK3zKgzjp8_Tm49bbKRsBQKz96w8N+aTs-vw@mail.gmail.com>
 <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com>
Message-ID: <CAA-vtUz0PWXCs7aJO8V8ncRgUe2wKm7PBqCtt3=qj3nxy8AyKg@mail.gmail.com>

On Thu, May 15, 2025 at 8:00?PM Alan Bateman <alan.bateman at oracle.com>
wrote:

>
>
> On 15/05/2025 17:52, Thomas St?fe wrote:
> > :
> >
> > However,  we also could just get rid of vfork. That would simplify
> > things alot. We have moved to posix_spawn-by-default with JDK 13 in
> > 2019 (https://bugs.openjdk.org/browse/JDK-8213192). That is a long
> > time ago; probably long enough to ween all customers off vfork use.
> >
> > What do people think?
> >
>
> I haven't see any complaints or JBS issues since the change in JDK 13.
> It's possible that there deployments running with
> jdk.lang.Process.launchMechanism set to vfork but my guess is that this
> configuration knob isn't widely known. If there are deployments doing
> this then there must be some reason, and I think we would have heard
> about it via a JBS issue by now.
>
> I checked the JDK release notes.  The property was documented in the JDK
> 12 release notes. The release note in JDK 13 about the move to
> posix_spawn didn't name the property to go back to vfork.
>
> So my initial reaction is that removing vfork would not be disruptive.
>
> -Alan
>
>
>
Thank you, Alan. I will prepare a patch and a CSR.

/Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250516/c8208131/attachment.htm>

From iklam at openjdk.org  Fri May 16 04:38:55 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 16 May 2025 04:38:55 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v12]
In-Reply-To: <JoyEhrXuHQMMjc5wSmogN0045YycfgZbi1YkpP3Ef8g=.ba201c18-7077-451a-b4b9-adafa9278b7f@github.com>
References: <AdBmCAbqhjQEP05JBlXhp21hKuxn7SAb7h0Y3Wvollk=.21c0e6fe-097e-41e4-afa3-45b108112a28@github.com>
 <JoyEhrXuHQMMjc5wSmogN0045YycfgZbi1YkpP3Ef8g=.ba201c18-7077-451a-b4b9-adafa9278b7f@github.com>
Message-ID: <VeowcKjPehD-MM_LI6EQ_38QtlUIIrI-kcSPj9KM2s4=.abb9678e-6507-4f1d-86b6-8fa464803316@github.com>

On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin <tpushkin at openjdk.org> 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:
> 
>   Make supertype obstruction check easier to understand

I have merged your PR with the latest repo and running tiers 1-4 in our CI. Waiting for the results now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2885610681

From alanb at openjdk.org  Fri May 16 05:36:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 May 2025 05:36:53 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
Message-ID: <TIyKoUhUEzKutdfkt1jIoGZPNfB7WMlkGeYEsqT8n40=.9fca5d23-4be4-45f9-8848-6ca45e9e4208@github.com>

On Thu, 15 May 2025 18:27:35 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes based on review feedback.

src/jdk.zipfs/share/classes/module-info.java line 299:

> 297:  *           <li>
> 298:  *               Any other values will cause an {@code IllegalArgumentException}
> 299:  *               to be thrown.

The wording looks great. Just one thing with the "causes an IAE to be thrown" where I think it can be expanded to say that it causes IAE to be thrown when attempting to create the ZIP file system. The existing compressMethod property has word for this too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2092352639

From alan.bateman at oracle.com  Fri May 16 05:56:03 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Fri, 16 May 2025 06:56:03 +0100
Subject: ProcessImpl: Can we obsolete the vfork mode?
In-Reply-To: <CAA-vtUz0PWXCs7aJO8V8ncRgUe2wKm7PBqCtt3=qj3nxy8AyKg@mail.gmail.com>
References: <CAA-vtUz19h6x4noK3zKgzjp8_Tm49bbKRsBQKz96w8N+aTs-vw@mail.gmail.com>
 <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com>
 <CAA-vtUz0PWXCs7aJO8V8ncRgUe2wKm7PBqCtt3=qj3nxy8AyKg@mail.gmail.com>
Message-ID: <8c291ee4-f1c0-487e-9dca-e43567cd6466@oracle.com>

On 16/05/2025 05:10, Thomas St?fe wrote:
>
>
>
> Thank you, Alan. I will prepare a patch and a CSR.
>
Okay, and maybe something for early in JDK 26 to avoid touching this 
area close to the fork for JDK 25 RDP1.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250516/f3653d61/attachment-0001.htm>

From alanb at openjdk.org  Fri May 16 06:19:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 May 2025 06:19:54 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v4]
In-Reply-To: <66pv5IvWk1pnQbXk3swAPR46Zfxt7L7VXPMIod0X3tk=.38446b76-4ef7-4702-929a-fabf3497080b@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <66pv5IvWk1pnQbXk3swAPR46Zfxt7L7VXPMIod0X3tk=.38446b76-4ef7-4702-929a-fabf3497080b@github.com>
Message-ID: <rwXcUZ5-L8SUGT-ZQ-cU9JFRM9Wy6cBFPco-VMQuCP8=.10dadf56-a1f2-4159-a7b9-de5752700098@github.com>

On Thu, 15 May 2025 22:42:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired.
>
> Brian Burkhalter has updated the pull request with a new target base 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:
> 
>  - 8355954: Simplify test
>  - Merge
>  - 8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set
>  - 8355954: Address comments on naming in the PR
>  - 8355954: File.delete removes read-only files (win)

test/jdk/java/io/File/DeleteReadOnly.java line 47:

> 45: 
> 46:     private static final File DIR = new File(".", "dir");
> 47:     private static final File FILE = new File(DIR, "file");

If one of the tests fails then it will impact the test(s) that execute later. It might be better to just isolate them. deleteReadOnlyDirectory creates a directory that is used solely for that test, and deleteReadOnlyRegularFile creates a file that is used solely for that test.

test/jdk/java/io/File/DeleteReadOnly.java line 62:

> 60: 
> 61:         boolean deleted = FILE.delete();
> 62:         boolean shouldBeDeleted = !Platform.isWindows() || DELETE_READ_ONLY;

The behavior and system property is Windows specific and might make things simpler to make it a Windows only test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2092398839
PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2092395664

From bpb at openjdk.org  Fri May 16 06:31:00 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 16 May 2025 06:31:00 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v4]
In-Reply-To: <rwXcUZ5-L8SUGT-ZQ-cU9JFRM9Wy6cBFPco-VMQuCP8=.10dadf56-a1f2-4159-a7b9-de5752700098@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <66pv5IvWk1pnQbXk3swAPR46Zfxt7L7VXPMIod0X3tk=.38446b76-4ef7-4702-929a-fabf3497080b@github.com>
 <rwXcUZ5-L8SUGT-ZQ-cU9JFRM9Wy6cBFPco-VMQuCP8=.10dadf56-a1f2-4159-a7b9-de5752700098@github.com>
Message-ID: <fFsRN-Y7HUvOXQsgT7uYAysTLWM5pIrUFqPIaj3R3OM=.34bb0412-a4c1-4a43-b7e3-c11c818bd20a@github.com>

On Fri, 16 May 2025 06:17:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base 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:
>> 
>>  - 8355954: Simplify test
>>  - Merge
>>  - 8355954: Fix HashedPasswordFileTest failure due to obsolete read-only attribute being set
>>  - 8355954: Address comments on naming in the PR
>>  - 8355954: File.delete removes read-only files (win)
>
> test/jdk/java/io/File/DeleteReadOnly.java line 47:
> 
>> 45: 
>> 46:     private static final File DIR = new File(".", "dir");
>> 47:     private static final File FILE = new File(DIR, "file");
> 
> If one of the tests fails then it will impact the test(s) that execute later. It might be better to just isolate them. deleteReadOnlyDirectory creates a directory that is used solely for that test, and deleteReadOnlyRegularFile creates a file that is used solely for that test.

Agreed. That actually happened when negative testing against code without the fix.

> test/jdk/java/io/File/DeleteReadOnly.java line 62:
> 
>> 60: 
>> 61:         boolean deleted = FILE.delete();
>> 62:         boolean shouldBeDeleted = !Platform.isWindows() || DELETE_READ_ONLY;
> 
> The behavior and system property is Windows specific and might make things simpler to make it a Windows only test.

I guess collapsing the tests made them more ambiguous. Will fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2092413253
PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2092412505

From ssarathi at openjdk.org  Fri May 16 07:09:26 2025
From: ssarathi at openjdk.org (Sorna Sarathi N)
Date: Fri, 16 May 2025 07:09:26 GMT
Subject: RFR: 8357106: Add missing classpath exception copyright headers
Message-ID: <Wu-CDJPi0tLHx96hLhkRaoryY4QpEKuK7eU80IBdzKA=.52bb83ef-1016-4764-aac8-232d2f66d167@github.com>

This PR adds missing classpath exception

-------------

Commit messages:
 - Adds missing classpath exception

Changes: https://git.openjdk.org/jdk/pull/25261/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25261&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357106
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25261/head:pull/25261

PR: https://git.openjdk.org/jdk/pull/25261

From thomas.stuefe at gmail.com  Fri May 16 07:26:12 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 16 May 2025 09:26:12 +0200
Subject: ProcessImpl: Can we obsolete the vfork mode?
In-Reply-To: <8c291ee4-f1c0-487e-9dca-e43567cd6466@oracle.com>
References: <CAA-vtUz19h6x4noK3zKgzjp8_Tm49bbKRsBQKz96w8N+aTs-vw@mail.gmail.com>
 <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com>
 <CAA-vtUz0PWXCs7aJO8V8ncRgUe2wKm7PBqCtt3=qj3nxy8AyKg@mail.gmail.com>
 <8c291ee4-f1c0-487e-9dca-e43567cd6466@oracle.com>
Message-ID: <CAA-vtUwsqPZWSoR8a2376GnCYjE_PQeGu1bDjex0b5zzcuurrg@mail.gmail.com>

Okay, moved the release version to 26.

Could one of you (you or @Roger Riggs <roger.riggs at oracle.com> ) review the
CSR if you have the cycles to spare?

https://bugs.openjdk.org/browse/JDK-8357090

Thanks!

On Fri, May 16, 2025 at 7:56?AM Alan Bateman <alan.bateman at oracle.com>
wrote:

> On 16/05/2025 05:10, Thomas St?fe wrote:
>
>
>
>>
> Thank you, Alan. I will prepare a patch and a CSR.
>
> Okay, and maybe something for early in JDK 26 to avoid touching this area
> close to the fork for JDK 25 RDP1.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250516/9624df2d/attachment-0001.htm>

From stuefe at openjdk.org  Fri May 16 07:28:29 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 16 May 2025 07:28:29 GMT
Subject: RFR: 8357089: Remove VFORK launch mechanism from Process
 implementation (linux)
Message-ID: <ai9TtPMOdbPnuc90ciCMD-0p1rO7Bu8gwFF-HrsQ1Zo=.f1a209d7-2aae-49ea-b058-73a1b27ad752@github.com>

See  the companion CSR (https://bugs.openjdk.org/browse/JDK-8357090) for the ratio behind this removal.

Patch

- removes all code handling the VFORK mode.
- removes or rewrites comments explaining use of vfork by the JVM.
- we now print out an error message to stderr if the user still specifies `-Djdk.lang.Process.launchMechanism=vfork`.

-------------

Commit messages:
 - add warning message if user specifies VFORK
 - start

Changes: https://git.openjdk.org/jdk/pull/25260/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25260&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357089
  Stats: 106 lines in 4 files changed: 0 ins; 84 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/25260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25260/head:pull/25260

PR: https://git.openjdk.org/jdk/pull/25260

From duke at openjdk.org  Fri May 16 07:44:00 2025
From: duke at openjdk.org (erifan)
Date: Fri, 16 May 2025 07:44:00 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v6]
In-Reply-To: <oDd6wkHsAQU3IUV3qCvjtqZ8BSHt7Qq2sx0Yy0Q8onc=.8e7db79c-15a5-4151-ac60-73f114433383@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <oDd6wkHsAQU3IUV3qCvjtqZ8BSHt7Qq2sx0Yy0Q8onc=.8e7db79c-15a5-4151-ac60-73f114433383@github.com>
Message-ID: <9f_-MMP_SSYInzCTUc5scRzKOKN1jj4VcnGEYWoOF14=.2eca7e44-d1df-4e57-a513-d8ddaddc9ea2@github.com>

On Wed, 14 May 2025 02:44:14 GMT, erifan <duke at openjdk.org> wrote:

>> This patch optimizes the following patterns:
>> For integer types:
>> 
>> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> 
>> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond.
>> 
>> For float and double types:
>> 
>> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> 
>> cond can be eq or ne.
>> 
>> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`:
>> 
>> Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>> testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>> testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>> testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>> testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>> testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>> testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>> testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>> testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>> testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
>> testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
>> testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
>> testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
>> testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
>> testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
>> testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
>> testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
>> testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
>> testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
>> testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
>> testCompareLTMaskNotInt		ops/s	16721...
>
> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Refactor the JTReg tests for compare.xor(maskAll)
>    
>    Also made a bit change to support pattern `VectorMask.fromLong()`.
>  - Merge branch 'master' into JDK-8354242
>  - Refactor code
>    
>    Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
>    optimization, making the code more modular.
>  - Merge branch 'master' into JDK-8354242
>  - Update the jtreg test
>  - Merge branch 'master' into JDK-8354242
>  - Addressed some review comments
>    
>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>    2. Improve code comments.
>  - Merge branch 'master' into JDK-8354242
>  - Merge branch 'master' into JDK-8354242
>  - 8354242: VectorAPI: combine vector not operation with compare
>    
>    This patch optimizes the following patterns:
>    For integer types:
>    ```
>    (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>        => (VectorMaskCmp src1 src2 ncond)
>    (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>        => (VectorMaskCmp src1 src2 ncond)
>    ```
>    cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>    negative comparison of cond.
>    
>    For float and double types:
>    ```
>    (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>    (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>    ```
>    cond can be eq or ne.
>    
>    Benchmarks on Nvidia Grace machine with 128-bit SVE2:
>    With option `-XX:UseSVE=2`:
>    ```
>    Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>    testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>    testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>    testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>    testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>    testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>    testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>    testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>    testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855...

Hi, I have updated the code and I'll file the patch to convert `VectorMask.fromLong(SPECIES, -1)` to `maskAll()` soon, I'll cover this test case in that patch. Would you please help review the patch again, thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-2885913474

From rgiulietti at openjdk.org  Fri May 16 07:46:51 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 16 May 2025 07:46:51 GMT
Subject: RFR: 8357063: Document preconditions for DecimalDigits methods
In-Reply-To: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
References: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
Message-ID: <idtXRenPP3PDFo2CC2bNml2pxw5raBXT4760Ju5kno8=.bbb9b860-0665-492e-aafe-64e479a7e9dc@github.com>

On Thu, 15 May 2025 06:24:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to PR #24982 
> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks.

The renaming is nice and useful.
But #24982, in addition to renaming, emphasizes the expectations about correct usage with bold WARNINGs in the JavaDoc. That's the "document preconditions" in the title.
Adding similar warnings in the JavaDoc, rather than in plain comments in the methods, would be clearer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25246#issuecomment-2885920485

From vyazici at openjdk.org  Fri May 16 08:01:22 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 16 May 2025 08:01:22 GMT
Subject: RFR: 8357063: Document preconditions for DecimalDigits methods
In-Reply-To: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
References: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
Message-ID: <woFI5uvhq1XUYlh73R9J8RwhvA047ybC6FkBaAOTxY4=.0f25822d-9bee-4d3b-bc6b-9ef68f087efd@github.com>

On Thu, 15 May 2025 06:24:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to PR #24982 
> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks.

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 297:

> 295:      */
> 296:     public static int uncheckedGetCharsUTF16(long i, int index, byte[] buf) {
> 297:         // Used by trusted callers.  Assumes all necessary bounds checks have been done by the caller.

Regarding all methods that are prefixed with `unsynchronized` in this PR, IMHO:

1. Precondition warnings should better be moved to the JavaDoc (ala #24982)
2. We shall also consider implementing these preconditions using `assert` statements

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2092539634

From jpai at openjdk.org  Fri May 16 08:04:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 08:04:00 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
Message-ID: <XhhlO7kp9gHxAH8FtiI7By4_KixYmqbDr6kKCbTmtXE=.afcdff58-ff7f-4ae8-9e2a-fb7153732125@github.com>

On Wed, 14 May 2025 18:16:22 GMT, Brian Burkhalter <bpb at openjdk.org> 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: Replace getChars in previous commit with subSequence

src/java.base/share/classes/java/io/Reader.java line 478:

> 476:      *
> 477:      * <p> If an I/O error occurs reading from the stream, then it
> 478:      * may do so after some, but not all, characters have been read.

Hello Brian, I read this sentence a couple of times but it wasn't clear to me what this meant. I am guessing that we want to state that if an I/O error occurs when some (but not all?) characters have been read then the stream may be in an inconsistent state? Should we reword this paragraph?

I suspect that sentence was motivated from similar existing text in `Files.readString(...)` and there too I find it confusing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2092538195

From stuefe at openjdk.org  Fri May 16 08:42:50 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 16 May 2025 08:42:50 GMT
Subject: RFR: 8357089: Remove VFORK launch mechanism from Process
 implementation (linux)
In-Reply-To: <ai9TtPMOdbPnuc90ciCMD-0p1rO7Bu8gwFF-HrsQ1Zo=.f1a209d7-2aae-49ea-b058-73a1b27ad752@github.com>
References: <ai9TtPMOdbPnuc90ciCMD-0p1rO7Bu8gwFF-HrsQ1Zo=.f1a209d7-2aae-49ea-b058-73a1b27ad752@github.com>
Message-ID: <YfYNx9BKV1ricYrdsAqZ2TnjZ6TkEopiqvV2U7TD8v4=.cf23e916-cc12-4233-be91-4e7ed9fdb76e@github.com>

On Fri, 16 May 2025 06:14:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Not for JDK 25
> 
> See  the companion CSR (https://bugs.openjdk.org/browse/JDK-8357090) for the ratio behind this removal.
> 
> Patch
> 
> - removes all code handling the VFORK mode.
> - removes or rewrites comments explaining use of vfork by the JVM.
> - we now print out an error message to stderr if the user still specifies `-Djdk.lang.Process.launchMechanism=vfork`.

I will delay this push for early JDK 26; hence back to draft state.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25260#issuecomment-2886046022

From jpai at openjdk.org  Fri May 16 09:26:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 09:26:57 GMT
Subject: RFR: 8351230: Collections.synchronizedList returns a list that is
 not thread-safe [v2]
In-Reply-To: <DRxCjR218Sb5Px9jomhYtD8HV-g71CqeJ0Pei-xYsBk=.def444b8-bf73-44f4-85d0-3750774b9be6@github.com>
References: <HtBkFlpJ7N3BjMiDZcA2LgM0YOEkd4L1_6XKIPJwwew=.6325e6ba-153e-43c6-9de6-ab00c1e972ed@github.com>
 <DRxCjR218Sb5Px9jomhYtD8HV-g71CqeJ0Pei-xYsBk=.def444b8-bf73-44f4-85d0-3750774b9be6@github.com>
Message-ID: <3-h5cco6E3PRpslFiqAR913I_lJ8_c0tMHhREoHCkps=.a9ba0091-c77d-4dda-b7d0-53e83ac57ca3@github.com>

On Mon, 5 May 2025 23:36:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper:
>> 
>> - overrides and adds locking to SequencedCollection methods;
>> - performs instance management of reversed synchronized views;
>> - adds test for race conditions and functional tests of synchronized wrappers.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reversed view of SynchronizedRandomAccessList should also be RandomAccess.
>   Add tests to ensure RandomAccess is preserved when reversing.

test/jdk/java/util/Collections/SyncListBash.java line 31:

> 29:  * @run     main SyncListBash f
> 30:  * @run     main SyncListBash r
> 31:  * @summary Test that List's new SequencedCollection methods are properly

Nit - jtreg recommends `@summary` to be after `@bug` https://openjdk.org/jtreg/tag-spec.html#ORDER. It would be good to follow that for this new test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24990#discussion_r2092688878

From aph at openjdk.org  Fri May 16 09:31:03 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 16 May 2025 09:31:03 GMT
Subject: Integrated: 8354674: AArch64: Intrinsify Unsafe::setMemory
In-Reply-To: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
Message-ID: <fBKWmv2Z7tHWyC5ym3EfTwcs29cAaSizZC_2kkZz1EA=.86f7fe5d-71e7-4466-826c-096e1062b2a4@github.com>

On Fri, 9 May 2025 14:11:27 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
> 
> 
> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op

This pull request has now been integrated.

Changeset: a6ebcf61
Author:    Andrew Haley <aph at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6ebcf61eb522a1bcfc9f2169d42974af3883b00
Stats:     127 lines in 3 files changed: 122 ins; 0 del; 5 mod

8354674: AArch64: Intrinsify Unsafe::setMemory

Reviewed-by: adinn

-------------

PR: https://git.openjdk.org/jdk/pull/25147

From jpai at openjdk.org  Fri May 16 09:37:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 09:37:56 GMT
Subject: RFR: 8351230: Collections.synchronizedList returns a list that is
 not thread-safe [v2]
In-Reply-To: <DRxCjR218Sb5Px9jomhYtD8HV-g71CqeJ0Pei-xYsBk=.def444b8-bf73-44f4-85d0-3750774b9be6@github.com>
References: <HtBkFlpJ7N3BjMiDZcA2LgM0YOEkd4L1_6XKIPJwwew=.6325e6ba-153e-43c6-9de6-ab00c1e972ed@github.com>
 <DRxCjR218Sb5Px9jomhYtD8HV-g71CqeJ0Pei-xYsBk=.def444b8-bf73-44f4-85d0-3750774b9be6@github.com>
Message-ID: <x4r57ei11TThLagk8xKyEK6xilXgESS2jodjEs8LFmk=.39695f1d-a46b-4e12-9966-651b1838e392@github.com>

On Mon, 5 May 2025 23:36:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper:
>> 
>> - overrides and adds locking to SequencedCollection methods;
>> - performs instance management of reversed synchronized views;
>> - adds test for race conditions and functional tests of synchronized wrappers.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reversed view of SynchronizedRandomAccessList should also be RandomAccess.
>   Add tests to ensure RandomAccess is preserved when reversing.

The fix and tests look good to me. I just have a nit that I've included as a review comment for the new test.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24990#pullrequestreview-2846098206

From swen at openjdk.org  Fri May 16 09:45:43 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 16 May 2025 09:45:43 GMT
Subject: RFR: 8357063: Document preconditions for DecimalDigits methods
 [v2]
In-Reply-To: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
References: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
Message-ID: <liYvUMvisU5SEUT-YCTjE-qbXxJeQsa_c_bM7CYWs8w=.a3b52c8a-cd3a-46ee-b3b2-7488d2b78e40@github.com>

> Similar to PR #24982 
> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - assert
 - document add warnings

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25246/files
  - new: https://git.openjdk.org/jdk/pull/25246/files/66f71c58..ddb44aa8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25246&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25246&range=00-01

  Stats: 29 lines in 1 file changed: 24 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25246/head:pull/25246

PR: https://git.openjdk.org/jdk/pull/25246

From jpai at openjdk.org  Fri May 16 10:09:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 10:09:53 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly
In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
Message-ID: <TDnYscB6gOFFKO8pUp31ZPWiasbGcz0cVvYYysQXKAk=.55a15b59-f9ab-43b8-a461-6b4366bbf312@github.com>

On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> A consider class like this:
> 
> 
> public class TwoMains {
>     private static void main(String... args) {}
>     static void main() {
>         System.out.println("Should be called, but is not.");
>     }
> }
> 
> 
> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
> 
> Something similar happens if the return type is not `void`.
> 
> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
> 
> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).

test/jdk/tools/launcher/Arrrghs.java line 607:

> 605:         //private method with parameter, usable method without parameter:
> 606:         createJar(new File("some.jar"), new File("Foo"),
> 607:             "private static void main(String[] args){}",

Perhaps we should even include a instance method `private void main(String[] args) {}` to cover that case?

test/jdk/tools/launcher/Arrrghs.java line 635:

> 633:         tr.contains("Error: abstract class Foo can not instantiated");
> 634:         if (!tr.testStatus)
> 635:             System.out.println(tr);

Hello Jan, I think this is pre-existing, but it looks like we don't fail the test even when `tr.testStatus` indicates a failure? We seem to only write out to `System.out` and return from the test method. Am I misreading the test code?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092758973
PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092755321

From duke at openjdk.org  Fri May 16 10:12:59 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 16 May 2025 10:12:59 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v6]
In-Reply-To: <hoQilPfsm719vv9gOH4kkZVdLoTONdoWfOA0XK1FPHg=.bef64c99-7b68-40a7-b570-68700336de11@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <Fe1FcysTPgZYA1aEUGFHRfBxnQ_QkYXJ-4it0QscrS8=.7c1fa510-c570-481c-aa40-5cca05667f34@github.com>
 <hoQilPfsm719vv9gOH4kkZVdLoTONdoWfOA0XK1FPHg=.bef64c99-7b68-40a7-b570-68700336de11@github.com>
Message-ID: <_7_Cbd9Yq1qPpOWvVIz7ROCzvrHwHPmDjbCS_wBtGUo=.badca150-12bb-4b98-b795-31699efcc947@github.com>

On Thu, 15 May 2025 22:03:40 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you please crosscheck?

@rgiulietti  It seems there is a slowdown in the creation of large pseudoprimes, maybe due to `BitSieve` methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2886284468

From jpai at openjdk.org  Fri May 16 10:13:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 10:13:52 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly
In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
Message-ID: <hJqy2FbAjXy8-R6F7mr_oqWJegUxCnp6OB0wBHzboNk=.115deed6-416b-40f1-916b-1d4fb4e34147@github.com>

On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> A consider class like this:
> 
> 
> public class TwoMains {
>     private static void main(String... args) {}
>     static void main() {
>         System.out.println("Should be called, but is not.");
>     }
> }
> 
> 
> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
> 
> Something similar happens if the return type is not `void`.
> 
> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
> 
> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 283:

> 281:     make inner class static or move inner class out to separate source file
> 282: java.launcher.cls.error8=\
> 283:     Error: abstract class {0} can not instantiated\n\

Nit - should this use a comma instead of the newline?

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher.properties line 113:

> 111: # 0: string
> 112: launcher.err.cant.find.main.method=\
> 113:     can''t find main(String[]) or main() method in class: {0}

Out of curiosity, why the double single quotes? I see it being used in other messages in this file as well, so it doesn't seem to be a typo.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092763055
PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092765139

From jpai at openjdk.org  Fri May 16 10:30:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 10:30:51 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly
In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
Message-ID: <aewAlr-bFrHqF9zqYnR_I488muadvF8en4O9uTyK4Tc=.40e070fd-ca25-4ff1-aa30-410bec2ac981@github.com>

On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> A consider class like this:
> 
> 
> public class TwoMains {
>     private static void main(String... args) {}
>     static void main() {
>         System.out.println("Should be called, but is not.");
>     }
> }
> 
> 
> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
> 
> Something similar happens if the return type is not `void`.
> 
> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
> 
> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).

test/langtools/tools/javac/launcher/SourceLauncherTest.java line 794:

> 792:                           """
> 793:                           public class WrongMainPrivate {
> 794:                               private static void main(String[] args) {}

Same comment as in the other place, perhaps we should include a `private void main(String[] args) {}` too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092789314

From thartmann at openjdk.org  Fri May 16 10:35:09 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 16 May 2025 10:35:09 GMT
Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id
 contains "-J"
In-Reply-To: <GJ80lme__hVwt5Y2yGHqCmxZta8fpTLGorMjYRkWjbo=.a7053f26-d608-4f29-978f-80364a8bafda@github.com>
References: <GJ80lme__hVwt5Y2yGHqCmxZta8fpTLGorMjYRkWjbo=.a7053f26-d608-4f29-978f-80364a8bafda@github.com>
Message-ID: <xZawqS7gFTffNqreyVL0Ziu_EQWI6ujMN7FBFQldpQ4=.503471e6-f3c7-4ef9-a9c1-616feed7df6c@github.com>

On Wed, 14 May 2025 14:40:41 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at:
> 
> https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134
> 
> This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure.
> 
> Testing:
>  - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332)
>  - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing

Looks good to me but someone from core-libs should have a look as well.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25230#pullrequestreview-2846233046

From azeller at openjdk.org  Fri May 16 10:38:07 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Fri, 16 May 2025 10:38:07 GMT
Subject: RFR: 8357052: java/io/File/GetXSpace.java prints wrong values in
 exception
Message-ID: <uKC3cFU14_1fPbsr9tamorif3MftHeN-Sfbz2483uik=.b18e053d-9be9-4b94-8a5f-cbed7f2e032a@github.com>

When the test java/io/File/GetXSpace.java fails, because the usable space is greater than the free space, the values in the exception are not the correct ones.

-------------

Commit messages:
 - Use correct variables.

Changes: https://git.openjdk.org/jdk/pull/25250/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25250&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357052
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25250.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25250/head:pull/25250

PR: https://git.openjdk.org/jdk/pull/25250

From duke at openjdk.org  Fri May 16 10:41:34 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 16 May 2025 10:41:34 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v7]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <JG3ynu5RaFFEN2y253FUinP5Iuf43kI-dPFR2Cirgbc=.adcee9b5-d97c-403b-949d-91ba1649ec99@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Correct bug in shiftRight

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/642461fe..a434bfc5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From dfuchs at openjdk.org  Fri May 16 10:45:06 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 16 May 2025 10:45:06 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v5]
In-Reply-To: <l0kZnNDdN-TbltTkaEW4yohiocDPHWvIJu34Nl8em8g=.02e58472-5252-414f-bfa6-9c06af35d5b6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <l0kZnNDdN-TbltTkaEW4yohiocDPHWvIJu34Nl8em8g=.02e58472-5252-414f-bfa6-9c06af35d5b6@github.com>
Message-ID: <t01ZejGn4WMUYiK_2xMiWTgI-gtY6BOEsix4cOxKESA=.4ae87c30-da46-4e5c-9094-b676d4c38f4b@github.com>

On Fri, 9 May 2025 14:39:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 422 commits:
> 
>  - merge latest changes from master branch
>  - Undo whitespace change
>  - Remove unnecessary import
>  - Merge remote-tracking branch 'origin/master' into http3
>  - Fix test license
>  - Remove leftover file (test was moved to parent directory)
>  - Remove unnecessary import
>  - Update throws clauses
>  - Merge remote-tracking branch 'origin/master' into http3
>  - 8354275: Add HTTP/3 tests to `EmptyAuthenticate`
>  - ... and 412 more: https://git.openjdk.org/jdk/compare/568dcc15...8c27f53c

I spotted some inacuracy in QuicEndpoint. I will take care of these.

src/java.net.http/share/classes/jdk/internal/net/http/Http3ClientImpl.java line 158:

> 156:                     quicIdleMillis = h3Millis + 60000; // a minute more than h3 timeout
> 157:                 }
> 158:                 transportParameters.setIntParameter(max_idle_timeout, quicIdleMillis);

I understand we don't want the QUIC Idle Timeout to kill idle connections before the HTTP/3 idle timeout has expired. But on the other hand, we should not let the HTTP/3 idle timeout set a quic idle timeout that is less than the default quic  timeout.
We should take into account the value of the default quic timeout that we use in QuicConnectionImpl here.

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 737:

> 735:         // channel, and a single selector thread, so we can do
> 736:         // the reading directly in the selector thread and offload
> 737:         // the parsing (the readLoop) to the executor.

This comment is outdated. We actually stop reading from the channel when the amount of data buffered exceeds a high watermark threshold.

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 822:

> 820:                     if (this.buffered.get() >= MAX_BUFFERED_HIGH) {
> 821:                         pauseReading();
> 822:                         readLoopScheduler.runOrSchedule(executor);

This line should not be needed: we should already have kicked the read loop at line 797.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-2846207620
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2092779174
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2092786818
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2092805633

From jlahoda at openjdk.org  Fri May 16 11:06:53 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 16 May 2025 11:06:53 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly
In-Reply-To: <hJqy2FbAjXy8-R6F7mr_oqWJegUxCnp6OB0wBHzboNk=.115deed6-416b-40f1-916b-1d4fb4e34147@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
 <hJqy2FbAjXy8-R6F7mr_oqWJegUxCnp6OB0wBHzboNk=.115deed6-416b-40f1-916b-1d4fb4e34147@github.com>
Message-ID: <YN0gc3xdaXnc_7NgHqn1sKRyLAdN2aXxdPVt9Ed2H1U=.d1c8df2a-6945-4e77-a3b5-a21c7ec506bf@github.com>

On Fri, 16 May 2025 10:10:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> A consider class like this:
>> 
>> 
>> public class TwoMains {
>>     private static void main(String... args) {}
>>     static void main() {
>>         System.out.println("Should be called, but is not.");
>>     }
>> }
>> 
>> 
>> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
>> 
>> Something similar happens if the return type is not `void`.
>> 
>> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
>> 
>> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).
>
> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 283:
> 
>> 281:     make inner class static or move inner class out to separate source file
>> 282: java.launcher.cls.error8=\
>> 283:     Error: abstract class {0} can not instantiated\n\
> 
> Nit - should this use a comma instead of the newline?

The other errors here provide some advice on the second line, so I kept that pattern for this error as well. So, the newline is intentional.

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher.properties line 113:
> 
>> 111: # 0: string
>> 112: launcher.err.cant.find.main.method=\
>> 113:     can''t find main(String[]) or main() method in class: {0}
> 
> Out of curiosity, why the double single quotes? I see it being used in other messages in this file as well, so it doesn't seem to be a typo.

Pieces of text in `MessageFormat` can be quoted using `'...'`. So, a single `'` does not work, as that is considered to be part of quoting. Using `''` escapes that behavior.

> test/jdk/tools/launcher/Arrrghs.java line 635:
> 
>> 633:         tr.contains("Error: abstract class Foo can not instantiated");
>> 634:         if (!tr.testStatus)
>> 635:             System.out.println(tr);
> 
> Hello Jan, I think this is pre-existing, but it looks like we don't fail the test even when `tr.testStatus` indicates a failure? We seem to only write out to `System.out` and return from the test method. Am I misreading the test code?

`tr.contains` marks the test as failing, and eventually `TestHelper.main` will fail the test. It is probably not how I would write the test from scratch, but re-writing an already existing test also does not seem like a good option.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092836696
PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092838074
PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092835532

From duke at openjdk.org  Fri May 16 11:10:12 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 16 May 2025 11:10:12 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v8]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <Al3Piz6jgHq6TSsjiGH5pHsMSo94in2GW61MZ5ZW8Xc=.5696e283-7f95-4fa5-a900-ff679735ac18@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

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/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/a434bfc5..b151b7e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From jlahoda at openjdk.org  Fri May 16 11:12:08 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 16 May 2025 11:12:08 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v2]
In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
Message-ID: <rTt0ecK6pxNZcmf7a3YChhle3BxeLN-yVbUhnCo0FBc=.f438c5d5-0a35-453a-a755-b3c6aaee816e@github.com>

> A consider class like this:
> 
> 
> public class TwoMains {
>     private static void main(String... args) {}
>     static void main() {
>         System.out.println("Should be called, but is not.");
>     }
> }
> 
> 
> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
> 
> Something similar happens if the return type is not `void`.
> 
> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
> 
> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Adding tests as suggested.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25256/files
  - new: https://git.openjdk.org/jdk/pull/25256/files/1c6a0123..a351686d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=00-01

  Stats: 48 lines in 2 files changed: 48 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25256/head:pull/25256

PR: https://git.openjdk.org/jdk/pull/25256

From jlahoda at openjdk.org  Fri May 16 11:12:08 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 16 May 2025 11:12:08 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v2]
In-Reply-To: <TDnYscB6gOFFKO8pUp31ZPWiasbGcz0cVvYYysQXKAk=.55a15b59-f9ab-43b8-a461-6b4366bbf312@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
 <TDnYscB6gOFFKO8pUp31ZPWiasbGcz0cVvYYysQXKAk=.55a15b59-f9ab-43b8-a461-6b4366bbf312@github.com>
Message-ID: <pYZwwmT0oFAXEanS5DthzeFMbzfVTDfDQ2lXA3JfD24=.e06e6c93-942c-41c0-9545-bf23cdbd0ab4@github.com>

On Fri, 16 May 2025 10:07:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding tests as suggested.
>
> test/jdk/tools/launcher/Arrrghs.java line 607:
> 
>> 605:         //private method with parameter, usable method without parameter:
>> 606:         createJar(new File("some.jar"), new File("Foo"),
>> 607:             "private static void main(String[] args){}",
> 
> Perhaps we should even include a instance method `private void main(String[] args) {}` to cover that case?

Done:
https://github.com/openjdk/jdk/pull/25256/commits/a351686d1aeb7a82f52141558ca7d2590cb7689f

> test/langtools/tools/javac/launcher/SourceLauncherTest.java line 794:
> 
>> 792:                           """
>> 793:                           public class WrongMainPrivate {
>> 794:                               private static void main(String[] args) {}
> 
> Same comment as in the other place, perhaps we should include a `private void main(String[] args) {}` too?

Done:
https://github.com/openjdk/jdk/pull/25256/commits/a351686d1aeb7a82f52141558ca7d2590cb7689f

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092844131
PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092844245

From vromero at openjdk.org  Fri May 16 11:25:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 16 May 2025 11:25:51 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v2]
In-Reply-To: <rTt0ecK6pxNZcmf7a3YChhle3BxeLN-yVbUhnCo0FBc=.f438c5d5-0a35-453a-a755-b3c6aaee816e@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
 <rTt0ecK6pxNZcmf7a3YChhle3BxeLN-yVbUhnCo0FBc=.f438c5d5-0a35-453a-a755-b3c6aaee816e@github.com>
Message-ID: <b8hyBRPvKNMvtLjUIWu1gU-KQEQ2dEqeT6e6KOUegAY=.bfe57d94-4f49-4215-8f1c-5e73db77eea0@github.com>

On Fri, 16 May 2025 11:12:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A consider class like this:
>> 
>> 
>> public class TwoMains {
>>     private static void main(String... args) {}
>>     static void main() {
>>         System.out.println("Should be called, but is not.");
>>     }
>> }
>> 
>> 
>> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
>> 
>> Something similar happens if the return type is not `void`.
>> 
>> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
>> 
>> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding tests as suggested.

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 283:

> 281:     make inner class static or move inner class out to separate source file
> 282: java.launcher.cls.error8=\
> 283:     Error: abstract class {0} can not instantiated\n\

typo: can not `be` instantiated

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092862512

From michaelm at openjdk.org  Fri May 16 11:42:08 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 16 May 2025 11:42:08 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v10]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <bi8YKmS-MSABbDfusziw4Ig1gJNUdNlVmm6qT-hf4Y0=.5c7261b0-834d-41b0-b1d4-428e5741b24a@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 26 commits:

 - reduced number of new categories
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Review update
 - review update
 - Merge branch 'master' into 8348986-exceptions
 - update to minimise code changes
 - Merge branch 'master' into 8348986-exceptions
 - ... and 16 more: https://git.openjdk.org/jdk/compare/64a858c7...3b7861b0

-------------

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=09
  Stats: 912 lines in 42 files changed: 681 ins; 101 del; 130 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  Fri May 16 11:47:53 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 16 May 2025 11:47:53 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v6]
In-Reply-To: <Fe1FcysTPgZYA1aEUGFHRfBxnQ_QkYXJ-4it0QscrS8=.7c1fa510-c570-481c-aa40-5cca05667f34@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <Fe1FcysTPgZYA1aEUGFHRfBxnQ_QkYXJ-4it0QscrS8=.7c1fa510-c570-481c-aa40-5cca05667f34@github.com>
Message-ID: <scRiTX00IPmuMt7xdToJ3DvhTBRlH_tphbPCSBKdiF0=.0ccfb166-8fb8-4225-9192-eed1d6a78df7@github.com>

On Thu, 15 May 2025 15:37:39 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make magBitLength() an instance method

src/java.base/share/classes/java/math/BigInteger.java line 3619:

> 3617:             int nzInts = numberOfTrailingZeroInts();
> 3618:             if (nInts > nzInts || nInts == nzInts
> 3619:                     && nBits > Integer.numberOfTrailingZeros(magLen - 1 - nzInts)) {

@rgiulietti The bug was there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2092889185

From rgiulietti at openjdk.org  Fri May 16 11:47:54 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 16 May 2025 11:47:54 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v6]
In-Reply-To: <scRiTX00IPmuMt7xdToJ3DvhTBRlH_tphbPCSBKdiF0=.0ccfb166-8fb8-4225-9192-eed1d6a78df7@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <Fe1FcysTPgZYA1aEUGFHRfBxnQ_QkYXJ-4it0QscrS8=.7c1fa510-c570-481c-aa40-5cca05667f34@github.com>
 <scRiTX00IPmuMt7xdToJ3DvhTBRlH_tphbPCSBKdiF0=.0ccfb166-8fb8-4225-9192-eed1d6a78df7@github.com>
Message-ID: <2xr3DFqEpcV-QgHdDujdEGf_GB3d2lGYAoMBtFrX4g0=.adcda9e7-bc7c-49fc-b486-89659dd2f346@github.com>

On Fri, 16 May 2025 11:43:18 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make magBitLength() an instance method
>
> src/java.base/share/classes/java/math/BigInteger.java line 3619:
> 
>> 3617:             int nzInts = numberOfTrailingZeroInts();
>> 3618:             if (nInts > nzInts || nInts == nzInts
>> 3619:                     && nBits > Integer.numberOfTrailingZeros(magLen - 1 - nzInts)) {
> 
> @rgiulietti The bug was there.

OK, good.
We try to make sure that pushed commits pass all the relevant tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2092892266

From jpai at openjdk.org  Fri May 16 11:49:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 11:49:53 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v2]
In-Reply-To: <YN0gc3xdaXnc_7NgHqn1sKRyLAdN2aXxdPVt9Ed2H1U=.d1c8df2a-6945-4e77-a3b5-a21c7ec506bf@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
 <hJqy2FbAjXy8-R6F7mr_oqWJegUxCnp6OB0wBHzboNk=.115deed6-416b-40f1-916b-1d4fb4e34147@github.com>
 <YN0gc3xdaXnc_7NgHqn1sKRyLAdN2aXxdPVt9Ed2H1U=.d1c8df2a-6945-4e77-a3b5-a21c7ec506bf@github.com>
Message-ID: <igmV2WJXemU2ROiGOAOkG3yXafMBVXiLfBxNS_0qf3M=.826f52fd-76af-4d08-a511-2050206bbca5@github.com>

On Fri, 16 May 2025 11:02:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 283:
>> 
>>> 281:     make inner class static or move inner class out to separate source file
>>> 282: java.launcher.cls.error8=\
>>> 283:     Error: abstract class {0} can not instantiated\n\
>> 
>> Nit - should this use a comma instead of the newline?
>
> The other errors here provide some advice on the second line, so I kept that pattern for this error as well. So, the newline is intentional.

Sounds fine to me then.

>> test/jdk/tools/launcher/Arrrghs.java line 635:
>> 
>>> 633:         tr.contains("Error: abstract class Foo can not instantiated");
>>> 634:         if (!tr.testStatus)
>>> 635:             System.out.println(tr);
>> 
>> Hello Jan, I think this is pre-existing, but it looks like we don't fail the test even when `tr.testStatus` indicates a failure? We seem to only write out to `System.out` and return from the test method. Am I misreading the test code?
>
> `tr.contains` marks the test as failing, and eventually `TestHelper.main` will fail the test. It is probably not how I would write the test from scratch, but re-writing an already existing test also does not seem like a good option.

Thank you for that. I didn't even realize that this was a "main()" test. I saw that there was a `@Test` annotation on these test methods and assumed it was either a testng or junit test. Turns out it's just another internal annotation of the `TestHelper`.

> It is probably not how I would write the test from scratch, but re-writing an already existing test also does not seem like a good option.

What you have in the current PR is fine with me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092893716
PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092892219

From jlahoda at openjdk.org  Fri May 16 11:54:07 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 16 May 2025 11:54:07 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v3]
In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
Message-ID: <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com>

> A consider class like this:
> 
> 
> public class TwoMains {
>     private static void main(String... args) {}
>     static void main() {
>         System.out.println("Should be called, but is not.");
>     }
> }
> 
> 
> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
> 
> Something similar happens if the return type is not `void`.
> 
> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
> 
> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Review comment: correcting typo.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25256/files
  - new: https://git.openjdk.org/jdk/pull/25256/files/a351686d..f63dab37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25256/head:pull/25256

PR: https://git.openjdk.org/jdk/pull/25256

From jpai at openjdk.org  Fri May 16 11:54:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 11:54:07 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v2]
In-Reply-To: <rTt0ecK6pxNZcmf7a3YChhle3BxeLN-yVbUhnCo0FBc=.f438c5d5-0a35-453a-a755-b3c6aaee816e@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
 <rTt0ecK6pxNZcmf7a3YChhle3BxeLN-yVbUhnCo0FBc=.f438c5d5-0a35-453a-a755-b3c6aaee816e@github.com>
Message-ID: <u1KsiUhF-HbE9f08k6sIR6VDeZljwZh5zBuxAvaegt4=.8c10bcf0-6db2-47d6-9a26-985cd03a887c@github.com>

On Fri, 16 May 2025 11:12:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A consider class like this:
>> 
>> 
>> public class TwoMains {
>>     private static void main(String... args) {}
>>     static void main() {
>>         System.out.println("Should be called, but is not.");
>>     }
>> }
>> 
>> 
>> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
>> 
>> Something similar happens if the return type is not `void`.
>> 
>> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
>> 
>> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding tests as suggested.

I went through the JLS updates linked in the CSR for JEP 512 https://bugs.openjdk.org/browse/JDK-8353437. The proposed changes in this PR looks good to me. The additional test coverage being added is good too.

I am not completely sure if the `Arrrghs.java` test and the `test/jdk/tools/launcher/InstanceMainTest.java` test fully cover all the scenarios of the new rules of determining a main method, but that's something that can be looked into as a separate activity.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25256#issuecomment-2886504200

From jpai at openjdk.org  Fri May 16 11:57:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 11:57:53 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v3]
In-Reply-To: <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
 <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com>
Message-ID: <jM9RsiOyq8lwFahgViitmHLH0icIvCbQ1n_divFPcYI=.70711efb-97cf-4284-96cc-a4e0bd98d4e0@github.com>

On Fri, 16 May 2025 11:54:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A consider class like this:
>> 
>> 
>> public class TwoMains {
>>     private static void main(String... args) {}
>>     static void main() {
>>         System.out.println("Should be called, but is not.");
>>     }
>> }
>> 
>> 
>> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
>> 
>> Something similar happens if the return type is not `void`.
>> 
>> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
>> 
>> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment: correcting typo.

test/jdk/tools/launcher/Arrrghs.java line 649:

> 647:                 """);
> 648:         tr = doExec(javaCmd, "-jar", "some.jar");
> 649:         tr.contains("Error: abstract class Foo can not instantiated");

After the latest typo fix, this check would also need an update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092905785

From vromero at openjdk.org  Fri May 16 12:01:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 16 May 2025 12:01:51 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v3]
In-Reply-To: <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
 <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com>
Message-ID: <9nkgB8f4tHZhM5HWcaivVzI7ibIZ0DfWlwRykr_uYrY=.8a0198cb-f35f-42ed-948d-2110a4694ef1@github.com>

On Fri, 16 May 2025 11:54:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A consider class like this:
>> 
>> 
>> public class TwoMains {
>>     private static void main(String... args) {}
>>     static void main() {
>>         System.out.println("Should be called, but is not.");
>>     }
>> }
>> 
>> 
>> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
>> 
>> Something similar happens if the return type is not `void`.
>> 
>> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
>> 
>> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment: correcting typo.

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25256#pullrequestreview-2846416794

From forax at univ-mlv.fr  Fri May 16 12:26:54 2025
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 16 May 2025 14:26:54 +0200 (CEST)
Subject: Towards a JSON API for the JDK
In-Reply-To: <CA+NR86gt3GNjDPS2m-2wha5AwgumMvBRxKw+bwgTCNQ1xCiDfg@mail.gmail.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gt3GNjDPS2m-2wha5AwgumMvBRxKw+bwgTCNQ1xCiDfg@mail.gmail.com>
Message-ID: <1353089152.267509212.1747398414378.JavaMail.zimbra@univ-eiffel.fr>

> From: "Ethan McCue" <ethan at mccue.dev>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Paul Sandoz" <paul.sandoz at oracle.com>, "core-libs-dev"
> <core-libs-dev at openjdk.org>
> Sent: Friday, May 16, 2025 1:44:52 AM
> Subject: Re: Towards a JSON API for the JDK

> I present for your consideration the library I made when spiraling about this
> problem space a few years ago

> [ https://github.com/bowbahdoe/json | https://github.com/bowbahdoe/json ]

> [
> https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html
> |
> https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html
> ]

> Notably missing during the design process here were patterns, hence the
> JsonDecoder design. I haven't been able to evaluate how patterns affect that on
> account of them not being out.

> I will more thoroughly peruse the draft of java.util.json at a later date, but
> my initial observations/comments:

> * I am not sure having JsonValue be distinct from Json has value.
> * toUntyped feels a little strange to me - the only type information presumably
> lost is the sealed-ness of the hierarchy. The interplay between that and
> toNumber is also a little unnerving.
> * One notion that I found helpful was that a class could be "json encodable,"
> meaning there is a method to call to obtain a canonical json representation.

> record Person(String name) implements JsonEncodable {
> @Override
> public Json toJson() {
> return Json.objectBuilder()
> .put("namen", name)
> .build();
> }
> }

> Which helper methods like Json#of(List<? extends JsonEncodable>) could make use
> of. Json itself ( JsonValue in your prototype) could then have a vacuous
> implementation.

> * Terminology wise - I went with reading/writing for the actual
> parsing/generation of json and encoding/decoding for the mapping of those
> representations to/from specific classes. The merits are not top of mind, just
> noting the difference. read/write vs parse/toString+toDisplayString
> * One thing I did was make the helper methods in Json null tolerant and the ones
> in the specific subtypes like JsonString not. This was because from what I saw
> of usages of javax.json/jakarta.json that nullability was a footgun and
> correcting for it required changes to code structure (breaking up builder
> chains with if (x != null) checks)
> * The functionality you want from JsonNumber could be achieved by making it just
> extend Number ( [
> https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/JsonNumber.java
> |
> https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/JsonNumber.java
> ] ) instead of a bespoke toNumber . You need the extra methods to go to big
> decimal and co, but it's just an extension to the behavior of Number at that
> point.
> * JsonObject and JsonArray could implement Map<String, Json> and List<Json>
> respectively. This lowers the need for toUntyped() - since presumably one of
> the use cases for that is turning the json tree into something that more
> generic map/list traversal code can handle. It also complicates any lazy
> loading somewhat.
> * Assuming patterns can be placed on interfaces, you might want to consider
> something similar to JsonDecoder , but with a pattern instead of a method that
> throws an exception.

> // Where here fromJson would box up the logic for testing and extracting from
> each element in the array.
> List<Person> people = array(json, Person::fromJson);

> * I don't think there is sufficient cause for anything to be non-sealed at this
> point.
> * JsonBoolean and JsonNull do not have reasonable alternative implementations -
> as far as I can imagine, maybe i'm wrong - so maybe those can just be final
> classes?
> * If you seal up the whole hierarchy then its pretty trivial to make it
> serializable ( [
> https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/serialization/JsonSerializationProxy.java
> |
> https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/serialization/JsonSerializationProxy.java
> ] )

Hello, 
I think your library is more high-level than java.util.json. 
Moreover, Paul proposes a design closer to DOP (Data Oriented Programming) than OOP. 

JsonNumber should not extend Number, JsonObject and JsonArray should not implements Map and List, the idea is to use delegation instead. 
(BTW extending Number will become an issue in the future if the VM tries to flatten filed typed with a value capable abstract class like Number) 

JSON is fundamentally untyped and recursive, but also describe data structures, for me, the proposed API exposes that structure (the subtypes of JsonValue) and make it easy to move from a JSON text to Java objects or vice-versa. 
The java.util.json API is very simple, 
- Json.fromUntyped() see a Java object to a structured JSON value (a JsonValue), 
- Json.toUntyped() unwrap a structured JSON value to extract the underlying Java object. 
- Json.parse() from String to a structured JSON value 
- Json.toDisplayString() (i would prefer "prettyString") goes from a structured JSON value to a pretty string. 

Having a JsonEncoder and JsonDecoder, JsonDecodable, etc is more high level than what is proposed here, so you can write objects like JsonEncoder/Decoder on top of it. 
Your example of JsonEncodable can be re-written to use the java.util.json API like this 

record Person(String name) implements JsonEncodable { 
@Override 
public JsonValue toJson() { 
return Json.fromUntyped(Map.of("name", name)); 
} 
} 

Compared to your code, java.util.json uses immutable data structures instead of a mutable builder (and yes, you lose the order, until SequenceMap.of() exists). 

regards, 
R?mi 

> On Thu, May 15, 2025 at 11:29 PM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> Hi Paul,
>> yes, not having a simple JSON API in Java is an issue for beginners.

>> It's not clear to me why JsonArray (for example) has to be an interface instead
>> of a record ?

>> I understand why Json.parse() only works on String and char[] but the API make
>> it too easy to have many performance issues.
>> I think you need versions using a Reader and a Path.
>> Bonus point, if there is a method walk() that also returns a JsonValue but the
>> List/Map inside JsonArray/JsonObject are populated lazily.

>> Minor point: Json.toDisplayString() should takes a second parameters indicating
>> the number of spaces used for the indentation (like JSON.stringify in JS).

>> regards,
>> R?mi

>> ----- Original Message -----
>>> From: "Paul Sandoz" < [ mailto:paul.sandoz at oracle.com | paul.sandoz at oracle.com ]
>> > >
>>> To: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.org |
>> > core-libs-dev at openjdk.org ] >
>> > Sent: Thursday, May 15, 2025 10:30:42 PM
>> > Subject: Towards a JSON API for the JDK

>> > Hi,

>> > We would like to share with you our thoughts and plans towards a JSON API for
>> > the JDK.
>> > Please see the document below.

>> > -

>> > We have had the pleasure of using a clone of this API in some experiments we are
>> > conducting with
>> > ONNX and code reflection [1]. Using the API we were able to quickly write code
>> > to ingest and convert
>> > a JSON document representing ONNX operation schema into instances of records
>> > modeling the schema
>> > (see here [2]).

>> > The overall out-of-box experience with such a minimal "batteries included? API
>> > has so far been positive.

>> > Thanks,
>> > Paul.

>>> [1] [ https://openjdk.org/projects/babylon/ |
>> > https://openjdk.org/projects/babylon/ ]
>> > [2]
>>> [
>>> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87
>>> |
>>> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87
>> > ]

>> > # Towards a JSON API for the JDK

>> > One of the most common requests for the JDK is an API for parsing and generating
>> > JSON. While JSON originated as a text-based serialization format for JSON
>> > objects ("JSON" stands for "JavaScript Object Notation"), because of its simple
>> > and flexible syntax, it eventually found use outside the JavaScript ecosystem as
>> > a general data interchange format, such as framework configuration files and web
>> > service requests/response formats.

>> > While the JDK cannot, and should not, provide libraries for every conceivable
>> > file format or protocol, the JDK philosophy is one of "batteries included",
>> > which is to say we should be able to write basic programs that use common
>> > protocols such as HTTP, without having to appeal to third party libraries.
>> > The Java ecosystem already has plenty of JSON libraries, so inclusion in
>> > the JDK is largely meant to be a convenience, rather than needing to be the "one
>> > true" JSON library to meet the needs of all users. Users with specific needs
>> > are always free to select one of the existing third-party libraries.

>> > ## Goals and requirements

>> > Our primary goal is that the library be simple to use for parsing, traversing,
>> > and generating conformant JSON documents. Advanced features, such as data
>> > binding or path-based traversal should be possible to implement as layered
>> > features, but for simplicity are not included in the core API. We adopt a goal
>> > that the performance should be "good enough", but where performance
>> > considerations conflict with simplicity and usability, we will choose in favor
>> > of the latter.

>> > ## API design approach

>>> The description of JSON at `https::// [ http://json.org/ | json.org ] `
>> > describes a JSON document using
>> > the familiar "railroad diagram":
>>> ![image]( [ https://www.json.org/img/value.png |
>> > https://www.json.org/img/value.png ] )

>> > This diagram describes an algebraic data type (a sum of products), which we
>> > model directly with a set of Java interfaces:

>> > ```
>> > interface JsonValue { }
>> > interface JsonArray extends JsonValue { List<JsonValue> values(); }
>> > interface JsonObject extends JsonValue { Map<String, JsonValue> members(); }
>> > interface JsonNumber extends JsonValue { Number toNumber(); }
>> > interface JsonString extends JsonValue { String value(); }
>> > interface JsonBoolean extends JsonValue { boolean value(); }
>> > interface JsonNull extends JsonValue { }
>> > ```

>> > These interfaces have (hidden) companion implementation classes that admit
>> > greater flexibility of implementation than modeling them directly with records
>> > would permit.
>> > Further, these interfaces are unsealed. We compromise on the sealed sum of
>> > products to enable
>> > alternative implementations, for example to support alternative formats that
>> > encode the same information in a JSON document but in a more efficient form than
>> > text.

>> > The API has static methods for parsing strings into a `JsonValue`, conversion to
>> > and from purely untyped representations (lists and maps), and factory methods
>> > for building JSON documents. We apply composition consistently, e.g, a
>> > JsonString has a string, a JsonObject has a map of string to JsonValue, as
>> > opposed to extension for structural JSON values.

>> > It turns out that this simple API is almost all we need for traversal. It gives
>> > us an immutable representation of a document, and we can use pattern matching to
>> > answer the myriad questions that will come up (Does this object have key X? Does
>> > it map to a number? Is that number representable as an integer?) when going
>> > from an untyped format like JSON to a more strongly typed domain model.
>> > Given a simple document like:

>> > ```
>> > {
>> > "name": "John?,
>> > "age": 30
>> > }
>> > ```

>> > we can parse and traverse the document as follows:

>> > ```
>> > JsonValue doc = Json.parse(inputString);
>> > if (doc instanceof JsonObject o
>> > && o.members().get("name") instanceof JsonString s
>> > && s.value() instanceof String name
>> > && o.members().get("age") instanceof JsonNumber n
>> > && n.toNumber() instanceof Long l && l instanceof int age) {
>> > // use "name" and "age"
>> > }
>> > ```

>> > Later, when the language acquires the ability to expose deconstruction patterns
>> > for arbitrary interfaces (similar to today's record patterns, see
>>> [
>>> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns
>>> |
>>> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns
>> > ] ),
>> > this will be simplifiable to:

>> > ```
>> > JsonValue doc = Json.parse(inputString);
>> > if (doc instanceof JsonObject(var members)
>> > && members.get("name") instanceof JsonString(String name)
>> > && members.get("age") instanceof JsonNumber(int age)) {
>> > // use "name" and "age"
>> > }
>> > ```

>> > So, overtime, as more pattern matching features are introduced we anticipate
>> > improved use of the API. This is a primary reason why the API is so minimal.
>> > Convenience methods we add today, such as a method that accesses a JSON
>> > object component as say a JSON string or throws an exception, will become
>> > redundant in the future.

>> > ## JSON numbers

>> > The specification of JSON number makes no explicit distinction between integral
>> > and decimal numbers, nor specifies limits on the size of those numbers.
>> > This is a common source of interoperability issues when consuming JSON
>> > documents. Generally users cannot always but often do assume JSON numbers are
>> > parsable, without loss of precision, to IEEE double-precision floating point
>> > numbers or 32-bit signed integers.

>> > In this respect the API provides three means to operate on the JSON number,
>> > giving the user full control:

>> > 1. Underlying string representation can be obtained, if preserving syntactic
>> > details such as leading or trailing zeros is important.
>> > 2. The string representation can be parsed to an instance of `BigDecimal`, using
>> > `toBigDecimal` if preserving decimal numbers is important.
>> > 3. The string representation can be parsed into an instance of `Long`, `Double`,
>> > `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this method
>> > depends on how the representation can be parsed, possibly losing precision,
>> > choosing a suitably convenient numeric type that can then be pattern
>> > matched on.

>> > Primitive pattern matching will help as will further pattern matching features
>> > enabling the user to partially match.

>> > ## Prototype implementation

>> > The prototype implementation is currently located into the JDK sandbox
>> > repository
>> > under the `json` branch, see
>> > here
>>> [
>>> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json
>>> |
>>> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json
>> > ]
>> > The prototype API javadoc generated from the repository is also available at
>>> [
>>> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html
>>> |
>>> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html
>> > ]

>> > ### Testing and conformance

>> > The prototype implementation passes all conformance test cases but two,
>> > available
>>> on [ https://github.com/nst/JSONTestSuite | https://github.com/nst/JSONTestSuite
>> > ] . The two exceptions are the ones which
>> > the
>> > prototype specifically prohibits, i.e, duplicated names in JSON objects
>>> ( [ https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35 |
>> > https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35 ] ).

>> > ### Performance

>> > Our main focus so far has been on the API design and a functional
>> > implementation.
>> > Hence, there has been less focus on performance even though we know there are a
>> > number of performance enhancements we can make eventually.
>> > We are reasonably happy with the current performance. The
>> > implementation performs well when compared to other JSON implementations
>> > parsing from string instances and traversing documents.

>> > An example of where we may choose simplicity and usability over performance
>> > is the rejection of JSON documents containing objects that in turn contain
>> > members
>> > with duplicate names. That may increase the cost of parsing, but simplifies the
>> > user
>> > experience for the majority of cases since if we reasonably assume JsonObjects
>> > are
>> > map-like, what should the user do with such members, pick one the last one?
>> > merge
>> > the values? or reject?

>> > ## A JSON JEP?

>> > We plan to draft JEP when we are ready. Attentive readers will observe that
>> > a JEP already exists, JEP 198: Light-Weight JSON API
>> > ( [ https://openjdk.org/jeps/198 | https://openjdk.org/jeps/198 ] ). We will
>> > either update this JEP, or withdraw it and draft a new one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250516/e08f6de7/attachment-0001.htm>

From weijun at openjdk.org  Fri May 16 12:28:06 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 May 2025 12:28:06 GMT
Subject: Integrated: 8353888: Implement JEP 510: Key Derivation Function API
In-Reply-To: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
Message-ID: <kEmA_BJnB48AKgosw0ulkfICLsoRKDa43FMGBL-yblo=.fd4af403-2e59-4b95-b474-1867199e78ec@github.com>

On Tue, 8 Apr 2025 18:14:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Finalize the KDF API.

This pull request has now been integrated.

Changeset: 079fccfa
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/079fccfa9a03b890e698c52c689dea0f19f8fbee
Stats:     209 lines in 18 files changed: 160 ins; 29 del; 20 mod

8353888: Implement JEP 510: Key Derivation Function API

Reviewed-by: valeriep, mullan, liach

-------------

PR: https://git.openjdk.org/jdk/pull/24520

From brian.goetz at oracle.com  Fri May 16 12:53:18 2025
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 16 May 2025 08:53:18 -0400
Subject: Towards a JSON API for the JDK
In-Reply-To: <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <f3cc90ef-25f3-41e3-a82b-0bac063c5733@oracle.com>



On 5/15/2025 5:27 PM, Remi Forax wrote:
> It's not clear to me why JsonArray (for example) has to be an interface instead of a record ?

Oh, you know the answer to this.? A record limits us to a single 
implementation with a rigid representation.? Behind an interface, we can 
hide lazy parsing and inflation, wrapping other representations to 
reduce copies, etc.



From lbruun at apache.org  Fri May 16 13:02:28 2025
From: lbruun at apache.org (Lars Bruun-Hansen)
Date: Fri, 16 May 2025 15:02:28 +0200
Subject: Towards a JSON API for the JDK
In-Reply-To: <CA+NR86gt3GNjDPS2m-2wha5AwgumMvBRxKw+bwgTCNQ1xCiDfg@mail.gmail.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gt3GNjDPS2m-2wha5AwgumMvBRxKw+bwgTCNQ1xCiDfg@mail.gmail.com>
Message-ID: <b0e7ff8e-f6dc-48b1-ad0f-5de52d8191b3@apache.org>


Great work.


I feel the elephant in the room needs to addressed: JSON comments. I
haven't tested the proposed lib but I cannot see it mentioned so I'm
assuming that comments are not supported.

For better or worse, the use of jsonc (JSON with comments) is everywhere
in some ecosystems. Unsurprisingly this happens often when JSON is used
as a config file format. Looking at you, Microsoft.

It would be nice if the JDK's build-in JSON parser at least recognized this.

I'm well aware that comments are frowned upon in JSON and not part of
neither the spec at www.json.org nor the RFC-8259.

Yet, I advocate the JDK JSON library should optionally allow comments to
be ignored when PARSING. This should be an opt-in feature that would
technically treat comments as whitespace during the parsing process.

This would also be in line with what many other parsers do. For example,
Jackson has "ALLOW_COMMENTS" feature [1]. Also, by comparison, the
build-in parser in the .NET world, known as System.Text.Json, also
supports this [2].



The "discoverer" of JSON, Douglas Crowford, had this to say [3] on the
topic:


[QUOTE]

I removed comments from JSON because I saw people were using them to
hold parsing directives, a practice which would have destroyed
interoperability. I know that the lack of comments makes some people
sad, but it shouldn't.

Suppose you are using JSON to keep configuration files, which you would
like to annotate. Go ahead and insert all the comments you like. Then
pipe it through JSMin before handing it to your JSON parser.

?[/QUOTE]


By not having the ability to ignore comments when parsing we would
effectively force users to use another parser first or a minifier. I
doubt beginners would appreciate that.


BTW: The test suite already has tests for comments.


/Lars


[1]:
https://www.javadoc.io/static/com.fasterxml.jackson.core/jackson-core/2.19.0/com/fasterxml/jackson/core/JsonParser.Feature.html#ALLOW_COMMENTS

[2]:
https://learn.microsoft.com/en-us/dotnet/api/system.text.json.jsonreaderoptions?view=net-9.0#properties

[3]: https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr




On 16/05/2025 01.44, Ethan McCue wrote:
> I present for your consideration the library I made when spiraling
> about this problem space a few years ago
>
> https://github.com/bowbahdoe/json
>
> https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html
>
> Notably missing during the design process here were patterns, hence
> the JsonDecoder design. I haven't been able to evaluate how patterns
> affect that on account of them not being out.
>
> I will more thoroughly peruse the draft of java.util.json at a later
> date, but my initial observations/comments:
>
> * I am not sure having JsonValue be distinct from Json has value.
> * toUntyped feels a little strange to me - the only type information
> presumably lost is the sealed-ness of the hierarchy. The interplay
> between that and toNumber is also a little unnerving.
> * One notion that I found helpful was that a class could be "json
> encodable," meaning there is a method to call to obtain a canonical
> json representation.
>
> record Person(String name) implements JsonEncodable {
> ? ??@Override
> ? ? public Json toJson() {
> ? ? ? ? return Json.objectBuilder()
> ? ? ? ? ? ? .put("namen", name)
> ? ? ? ? ? ? .build();
> ? ? }
> }
>
> Which helper methods like Json#of(List<? extends JsonEncodable>)?could
> make use of. Json?itself (JsonValue?in your prototype) could then have
> a vacuous implementation.
>
> * Terminology wise - I went with reading/writing for the actual
> parsing/generation of json and encoding/decoding for the mapping of
> those representations to/from specific classes. The merits are not top
> of mind, just noting the difference. read/write vs
> parse/toString+toDisplayString
> * One thing I did was make the helper methods in Json?null tolerant
> and the ones in the specific subtypes like JsonString?not. This was
> because from what I saw of usages of javax.json/jakarta.json that
> nullability was a footgun and correcting for?it required changes to
> code structure (breaking up builder chains with if (x != null)?checks)
> * The functionality you want from JsonNumber could be achieved by
> making it just extend Number
> (https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/JsonNumber.java)
> instead of a bespoke toNumber. You need the extra methods to go to big
> decimal and co, but it's just an extension to the behavior of Number
> at that point.
> * JsonObject and JsonArray could implement Map<String, Json> and
> List<Json> respectively. This lowers the need for toUntyped() - since
> presumably one of the use cases for that is turning the json tree into
> something that more generic map/list traversal code can handle. It
> also complicates any lazy loading somewhat.
> * Assuming patterns can be placed on interfaces, you might want to
> consider something similar to?JsonDecoder, but with a pattern instead
> of a method that throws an exception.
>
> // Where here fromJson would box up the logic for testing and
> extracting from each element in the array.
> List<Person> people = array(json, Person::fromJson);
>
> * I don't think there is sufficient cause for anything to be
> non-sealed at this point.
> * JsonBoolean and JsonNull do not have reasonable alternative
> implementations - as far as I can imagine, maybe i'm wrong - so maybe
> those can just be final classes?
> * If you seal up the whole hierarchy then its pretty trivial to make
> it serializable
> (https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/serialization/JsonSerializationProxy.java)
>
>
>
>
> On Thu, May 15, 2025 at 11:29?PM Remi Forax <forax at univ-mlv.fr> wrote:
>
>     Hi Paul,
>     yes, not having a simple JSON API in Java is an issue for beginners.
>
>     It's not clear to me why JsonArray (for example) has to be an
>     interface instead of a record ?
>
>     I understand why Json.parse() only works on String and char[] but
>     the API make it too easy to have many performance issues.
>     I think you need versions using a Reader and a Path.
>     Bonus point, if there is a method walk() that also returns a
>     JsonValue but the List/Map inside JsonArray/JsonObject are
>     populated lazily.
>
>     Minor point: Json.toDisplayString() should takes a second
>     parameters indicating the number of spaces used for the
>     indentation (like JSON.stringify in JS).
>
>     regards,
>     R?mi
>
>     ----- Original Message -----
>     > From: "Paul Sandoz" <paul.sandoz at oracle.com>
>     > To: "core-libs-dev" <core-libs-dev at openjdk.org>
>     > Sent: Thursday, May 15, 2025 10:30:42 PM
>     > Subject: Towards a JSON API for the JDK
>
>     > Hi,
>     >
>     > We would like to share with you our thoughts and plans towards a
>     JSON API for
>     > the JDK.
>     > Please see the document below.
>     >
>     > -
>     >
>     > We have had the pleasure of using a clone of this API in some
>     experiments we are
>     > conducting with
>     > ONNX and code reflection [1]. Using the API we were able to
>     quickly write code
>     > to ingest and convert
>     > a JSON document representing ONNX operation schema into
>     instances of records
>     > modeling the schema
>     > (see here [2]).
>     >
>     > The overall out-of-box experience with such a minimal "batteries
>     included? API
>     > has so far been positive.
>     >
>     > Thanks,
>     > Paul.
>     >
>     > [1] https://openjdk.org/projects/babylon/
>     > [2]
>     >
>     https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87
>     >
>     > # Towards a JSON API for the JDK
>     >
>     > One of the most common requests for the JDK is an API for
>     parsing and generating
>     > JSON. While JSON originated as a text-based serialization format
>     for JSON
>     > objects ("JSON" stands for "JavaScript Object Notation"),
>     because of its simple
>     > and flexible syntax, it eventually found use outside the
>     JavaScript ecosystem as
>     > a general data interchange format, such as framework
>     configuration files and web
>     > service requests/response formats.
>     >
>     > While the JDK cannot, and should not, provide libraries for
>     every conceivable
>     > file format or protocol, the JDK philosophy is one of "batteries
>     included",
>     > which is to say we should be able to write basic programs that
>     use common
>     > protocols such as HTTP, without having to appeal to third party
>     libraries.
>     > The Java ecosystem already has plenty of JSON libraries, so
>     inclusion in
>     > the JDK is largely meant to be a convenience, rather than
>     needing to be the "one
>     > true" JSON library to meet the needs of all users. Users with
>     specific needs
>     > are always free to select one of the existing third-party libraries.
>     >
>     > ## Goals and requirements
>     >
>     > Our primary goal is that the library be simple to use for
>     parsing, traversing,
>     > and generating conformant JSON documents. Advanced features,
>     such as data
>     > binding or path-based traversal should be possible to implement
>     as layered
>     > features, but for simplicity are not included in the core API.
>     We adopt a goal
>     > that the performance should be "good enough", but where performance
>     > considerations conflict with simplicity and usability, we will
>     choose in favor
>     > of the latter.
>     >
>     > ## API design approach
>     >
>     > The description of JSON at `https:://json.org <http://json.org>`
>     describes a JSON document using
>     > the familiar "railroad diagram":
>     > ![image](https://www.json.org/img/value.png)
>     >
>     > This diagram describes an algebraic data type (a sum of
>     products), which we
>     > model directly with a set of Java interfaces:
>     >
>     > ```
>     > interface JsonValue { }
>     > interface JsonArray extends JsonValue { List<JsonValue> values(); }
>     > interface JsonObject extends JsonValue { Map<String, JsonValue>
>     members(); }
>     > interface JsonNumber extends JsonValue { Number toNumber(); }
>     > interface JsonString extends JsonValue { String value(); }
>     > interface JsonBoolean extends JsonValue? { boolean value(); }
>     > interface JsonNull extends JsonValue { }
>     > ```
>     >
>     > These interfaces have (hidden) companion implementation classes
>     that admit
>     > greater flexibility of implementation than modeling them
>     directly with records
>     > would permit.
>     > Further, these interfaces are unsealed. We compromise on the
>     sealed sum of
>     > products to enable
>     > alternative implementations, for example to support alternative
>     formats that
>     > encode the same information in a JSON document but in a more
>     efficient form than
>     > text.
>     >
>     > The API has static methods for parsing strings into a
>     `JsonValue`, conversion to
>     > and from purely untyped representations (lists and maps), and
>     factory methods
>     > for building JSON documents. We apply composition consistently,
>     e.g, a
>     > JsonString has a string, a JsonObject has a map of string to
>     JsonValue, as
>     > opposed to extension for structural JSON values.
>     >
>     > It turns out that this simple API is almost all we need for
>     traversal. It gives
>     > us an immutable representation of a document, and we can use
>     pattern matching to
>     > answer the myriad questions that will come up (Does this object
>     have key X? Does
>     > it map to a number? Is that number representable as an integer?)
>     when going
>     > from an untyped format like JSON to a more strongly typed domain
>     model.
>     > Given a simple document like:
>     >
>     > ```
>     >? ? {
>     >? ? ? ? "name": "John?,
>     >? ? ? ? "age": 30
>     >? ? }
>     > ```
>     >
>     > we can parse and traverse the document as follows:
>     >
>     > ```
>     > JsonValue doc = Json.parse(inputString);
>     > if (doc instanceof JsonObject o
>     >? ? && o.members().get("name") instanceof JsonString s
>     >? ? && s.value() instanceof String name
>     >? ? && o.members().get("age") instanceof JsonNumber n
>     >? ? && n.toNumber() instanceof Long l && l instanceof int age) {
>     >? ? ? ? ? ? // use "name" and "age"
>     >? ? ? ? }
>     > ```
>     >
>     > Later, when the language acquires the ability to expose
>     deconstruction patterns
>     > for arbitrary interfaces (similar to today's record patterns, see
>     >
>     https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns),
>     > this will be simplifiable to:
>     >
>     > ```
>     > JsonValue doc = Json.parse(inputString);
>     > if (doc instanceof JsonObject(var members)
>     >? ? && members.get("name") instanceof JsonString(String name)
>     >? ? && members.get("age") instanceof JsonNumber(int age)) {
>     >? ? ? ? ? ? // use "name" and "age"
>     >? ? ? ? }
>     > ```
>     >
>     > So, overtime, as more pattern matching features are introduced
>     we anticipate
>     > improved use of the API. This is a primary reason why the API is
>     so minimal.
>     > Convenience methods we add today, such as a method that accesses
>     a JSON
>     > object component as say a JSON string or throws an exception,
>     will become
>     > redundant in the future.
>     >
>     > ## JSON numbers
>     >
>     > The specification of JSON number makes no explicit distinction
>     between integral
>     > and decimal numbers, nor specifies limits on the size of those
>     numbers.
>     > This is a common source of interoperability issues when
>     consuming JSON
>     > documents. Generally users cannot always but often do assume
>     JSON numbers are
>     > parsable, without loss of precision, to IEEE double-precision
>     floating point
>     > numbers or 32-bit signed integers.
>     >
>     > In this respect the API provides three means to operate on the
>     JSON number,
>     > giving the user full control:
>     >
>     > 1. Underlying string representation can be obtained, if
>     preserving syntactic
>     >? ?details such as leading or trailing zeros is important.
>     > 2. The string representation can be parsed to an instance of
>     `BigDecimal`, using
>     >? ?`toBigDecimal` if preserving decimal numbers is important.
>     > 3. The string representation can be parsed into an instance of
>     `Long`, `Double`,
>     >? ?`BigInteger`, or `BigDecimal`, using `toNumber`. The result of
>     this method
>     >? ?depends on how the representation can be parsed, possibly
>     losing precision,
>     >? ?choosing a suitably convenient numeric type that can then be
>     pattern
>     >? ?matched on.
>     >
>     > Primitive pattern matching will help as will further pattern
>     matching features
>     > enabling the user to partially match.
>     >
>     > ## Prototype implementation
>     >
>     > The prototype implementation is currently located into the JDK
>     sandbox
>     > repository
>     > under the `json` branch, see
>     > here
>     >
>     https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json
>     > The prototype API javadoc generated from the repository is also
>     available at
>     >
>     https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html
>     >
>     > ### Testing and conformance
>     >
>     > The prototype implementation passes all conformance test cases
>     but two,
>     > available
>     > on https://github.com/nst/JSONTestSuite. The two exceptions are
>     the ones which
>     > the
>     > prototype specifically prohibits, i.e, duplicated names in JSON
>     objects
>     >
>     (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35).
>     >
>     > ### Performance
>     >
>     > Our main focus so far has been on the API design and a functional
>     > implementation.
>     > Hence, there has been less focus on performance even though we
>     know there are a
>     > number of performance enhancements we can make eventually.
>     > We are reasonably happy with the current performance. The
>     > implementation performs well when compared to other JSON
>     implementations
>     > parsing from string instances and traversing documents.
>     >
>     > An example of where we may choose simplicity and usability over
>     performance
>     > is the rejection of JSON documents containing objects that in
>     turn contain
>     > members
>     > with duplicate names. That may increase the cost of parsing, but
>     simplifies the
>     > user
>     > experience for the majority of cases since if we reasonably
>     assume JsonObjects
>     > are
>     > map-like, what should the user do with such members, pick one
>     the last one?
>     > merge
>     > the values? or reject?
>     >
>     > ## A JSON JEP?
>     >
>     > We plan to draft JEP when we are ready. Attentive readers will
>     observe that
>     > a JEP already exists, JEP 198: Light-Weight JSON API
>     > (https://openjdk.org/jeps/198). We will
>     > either update this JEP, or withdraw it and draft a new one.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250516/23f74fe7/attachment-0001.htm>

From brian.goetz at oracle.com  Fri May 16 13:17:16 2025
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 16 May 2025 09:17:16 -0400
Subject: Towards a JSON API for the JDK
In-Reply-To: <b0e7ff8e-f6dc-48b1-ad0f-5de52d8191b3@apache.org>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gt3GNjDPS2m-2wha5AwgumMvBRxKw+bwgTCNQ1xCiDfg@mail.gmail.com>
 <b0e7ff8e-f6dc-48b1-ad0f-5de52d8191b3@apache.org>
Message-ID: <a5db35c2-800d-4b4a-99f4-91a47008aaac@oracle.com>

At first, we were hopeful that we could jump right to JSON5, which 
appears at first glance to be a strictly lexical, more permissive 
grammar for JSON (supporting comments, trailing commas, more flexible 
quoting, white space, etc.)? If that were actually true, this would have 
been a slam dunk, since all these lexical niceties don't have an impact 
on the parsed results.? And JSON5 has been gaining some traction, so it 
probably could have been a justifiable move to jump right to that.

But then we discovered that JSON5 also sneaks in some semantics, by also 
supporting the exotic numeric values (NaN, infinities, signed zero), 
which now has consequences for "what is a number", the numeric 
representation, the API for unpacking numeric values, etc. (Having 
multiple parsers is one thing; having multiple parsers that produce 
different semantics is entirely another.)? And inventing a new "JSON5 
but not quite" subset would be doing no one any favors.

Jsonc seems to be entirely a MS-ecosystem thing; it does not have broad 
enough traction to be the "one grammar" we accept.? So pure JSON, as 
specification-challenged as it is, is the logical, though sad, 
conclusion (for now.)



On 5/16/2025 9:02 AM, Lars Bruun-Hansen wrote:
>
>
> Great work.
>
>
> I feel the elephant in the room needs to addressed: JSON comments. I 
> haven't tested the proposed lib but I cannot see it mentioned so I'm 
> assuming that comments are not supported.
>
> For better or worse, the use of jsonc (JSON with comments) is 
> everywhere in some ecosystems. Unsurprisingly this happens often when 
> JSON is used as a config file format. Looking at you, Microsoft.
>
> It would be nice if the JDK's build-in JSON parser at least recognized 
> this.
>
> I'm well aware that comments are frowned upon in JSON and not part of 
> neither the spec at www.json.org nor the RFC-8259.
>
> Yet, I advocate the JDK JSON library should optionally allow comments 
> to be ignored when PARSING. This should be an opt-in feature that 
> would technically treat comments as whitespace during the parsing process.
>
> This would also be in line with what many other parsers do. For 
> example, Jackson has "ALLOW_COMMENTS" feature [1]. Also, by 
> comparison, the build-in parser in the .NET world, known as 
> System.Text.Json, also supports this [2].
>
>
>
> The "discoverer" of JSON, Douglas Crowford, had this to say [3] on the 
> topic:
>
>
> [QUOTE]
>
> I removed comments from JSON because I saw people were using them to 
> hold parsing directives, a practice which would have destroyed 
> interoperability. I know that the lack of comments makes some people 
> sad, but it shouldn't.
>
> Suppose you are using JSON to keep configuration files, which you 
> would like to annotate. Go ahead and insert all the comments you like. 
> Then pipe it through JSMin before handing it to your JSON parser.
>
> ?[/QUOTE]
>
>
> By not having the ability to ignore comments when parsing we would 
> effectively force users to use another parser first or a minifier. I 
> doubt beginners would appreciate that.
>
>
> BTW: The test suite already has tests for comments.
>
>
> /Lars
>
>
> [1]: 
> https://www.javadoc.io/static/com.fasterxml.jackson.core/jackson-core/2.19.0/com/fasterxml/jackson/core/JsonParser.Feature.html#ALLOW_COMMENTS
>
> [2]: 
> https://learn.microsoft.com/en-us/dotnet/api/system.text.json.jsonreaderoptions?view=net-9.0#properties
>
> [3]: https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr
>
>
>
>
> On 16/05/2025 01.44, Ethan McCue wrote:
>> I present for your consideration the library I made when spiraling 
>> about this problem space a few years ago
>>
>> https://github.com/bowbahdoe/json
>>
>> https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html
>>
>> Notably missing during the design process here were patterns, hence 
>> the JsonDecoder design. I haven't been able to evaluate how patterns 
>> affect that on account of them not being out.
>>
>> I will more thoroughly peruse the draft of java.util.json at a later 
>> date, but my initial observations/comments:
>>
>> * I am not sure having JsonValue be distinct from Json has value.
>> * toUntyped feels a little strange to me - the only type information 
>> presumably lost is the sealed-ness of the hierarchy. The interplay 
>> between that and toNumber is also a little unnerving.
>> * One notion that I found helpful was that a class could be "json 
>> encodable," meaning there is a method to call to obtain a canonical 
>> json representation.
>>
>> record Person(String name) implements JsonEncodable {
>> @Override
>> ? ? public Json toJson() {
>> ? ? ? ? return Json.objectBuilder()
>> ? ? ? ? ? ? .put("namen", name)
>> ? ? ? ? ? ? .build();
>> ? ? }
>> }
>>
>> Which helper methods like Json#of(List<? extends 
>> JsonEncodable>)?could make use of. Json?itself (JsonValue?in your 
>> prototype) could then have a vacuous implementation.
>>
>> * Terminology wise - I went with reading/writing for the actual 
>> parsing/generation of json and encoding/decoding for the mapping of 
>> those representations to/from specific classes. The merits are not 
>> top of mind, just noting the difference. read/write vs 
>> parse/toString+toDisplayString
>> * One thing I did was make the helper methods in Json?null tolerant 
>> and the ones in the specific subtypes like JsonString?not. This was 
>> because from what I saw of usages of javax.json/jakarta.json that 
>> nullability was a footgun and correcting for?it required changes to 
>> code structure (breaking up builder chains with if (x != null)?checks)
>> * The functionality you want from JsonNumber could be achieved by 
>> making it just extend Number 
>> (https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/JsonNumber.java) 
>> instead of a bespoke toNumber. You need the extra methods to go to 
>> big decimal and co, but it's just an extension to the behavior of 
>> Number at that point.
>> * JsonObject and JsonArray could implement Map<String, Json> and 
>> List<Json> respectively. This lowers the need for toUntyped() - since 
>> presumably one of the use cases for that is turning the json tree 
>> into something that more generic map/list traversal code can handle. 
>> It also complicates any lazy loading somewhat.
>> * Assuming patterns can be placed on interfaces, you might want to 
>> consider something similar to JsonDecoder, but with a pattern instead 
>> of a method that throws an exception.
>>
>> // Where here fromJson would box up the logic for testing and 
>> extracting from each element in the array.
>> List<Person> people = array(json, Person::fromJson);
>>
>> * I don't think there is sufficient cause for anything to be 
>> non-sealed at this point.
>> * JsonBoolean and JsonNull do not have reasonable alternative 
>> implementations - as far as I can imagine, maybe i'm wrong - so maybe 
>> those can just be final classes?
>> * If you seal up the whole hierarchy then its pretty trivial to make 
>> it serializable 
>> (https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/serialization/JsonSerializationProxy.java)
>>
>>
>>
>>
>> On Thu, May 15, 2025 at 11:29?PM Remi Forax <forax at univ-mlv.fr> wrote:
>>
>>     Hi Paul,
>>     yes, not having a simple JSON API in Java is an issue for beginners.
>>
>>     It's not clear to me why JsonArray (for example) has to be an
>>     interface instead of a record ?
>>
>>     I understand why Json.parse() only works on String and char[] but
>>     the API make it too easy to have many performance issues.
>>     I think you need versions using a Reader and a Path.
>>     Bonus point, if there is a method walk() that also returns a
>>     JsonValue but the List/Map inside JsonArray/JsonObject are
>>     populated lazily.
>>
>>     Minor point: Json.toDisplayString() should takes a second
>>     parameters indicating the number of spaces used for the
>>     indentation (like JSON.stringify in JS).
>>
>>     regards,
>>     R?mi
>>
>>     ----- Original Message -----
>>     > From: "Paul Sandoz" <paul.sandoz at oracle.com>
>>     > To: "core-libs-dev" <core-libs-dev at openjdk.org>
>>     > Sent: Thursday, May 15, 2025 10:30:42 PM
>>     > Subject: Towards a JSON API for the JDK
>>
>>     > Hi,
>>     >
>>     > We would like to share with you our thoughts and plans towards
>>     a JSON API for
>>     > the JDK.
>>     > Please see the document below.
>>     >
>>     > -
>>     >
>>     > We have had the pleasure of using a clone of this API in some
>>     experiments we are
>>     > conducting with
>>     > ONNX and code reflection [1]. Using the API we were able to
>>     quickly write code
>>     > to ingest and convert
>>     > a JSON document representing ONNX operation schema into
>>     instances of records
>>     > modeling the schema
>>     > (see here [2]).
>>     >
>>     > The overall out-of-box experience with such a minimal
>>     "batteries included? API
>>     > has so far been positive.
>>     >
>>     > Thanks,
>>     > Paul.
>>     >
>>     > [1] https://openjdk.org/projects/babylon/
>>     > [2]
>>     >
>>     https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87
>>     >
>>     > # Towards a JSON API for the JDK
>>     >
>>     > One of the most common requests for the JDK is an API for
>>     parsing and generating
>>     > JSON. While JSON originated as a text-based serialization
>>     format for JSON
>>     > objects ("JSON" stands for "JavaScript Object Notation"),
>>     because of its simple
>>     > and flexible syntax, it eventually found use outside the
>>     JavaScript ecosystem as
>>     > a general data interchange format, such as framework
>>     configuration files and web
>>     > service requests/response formats.
>>     >
>>     > While the JDK cannot, and should not, provide libraries for
>>     every conceivable
>>     > file format or protocol, the JDK philosophy is one of
>>     "batteries included",
>>     > which is to say we should be able to write basic programs that
>>     use common
>>     > protocols such as HTTP, without having to appeal to third party
>>     libraries.
>>     > The Java ecosystem already has plenty of JSON libraries, so
>>     inclusion in
>>     > the JDK is largely meant to be a convenience, rather than
>>     needing to be the "one
>>     > true" JSON library to meet the needs of all users. Users with
>>     specific needs
>>     > are always free to select one of the existing third-party
>>     libraries.
>>     >
>>     > ## Goals and requirements
>>     >
>>     > Our primary goal is that the library be simple to use for
>>     parsing, traversing,
>>     > and generating conformant JSON documents. Advanced features,
>>     such as data
>>     > binding or path-based traversal should be possible to implement
>>     as layered
>>     > features, but for simplicity are not included in the core API.
>>     We adopt a goal
>>     > that the performance should be "good enough", but where performance
>>     > considerations conflict with simplicity and usability, we will
>>     choose in favor
>>     > of the latter.
>>     >
>>     > ## API design approach
>>     >
>>     > The description of JSON at `https:://json.org
>>     <http://json.org>` describes a JSON document using
>>     > the familiar "railroad diagram":
>>     > ![image](https://www.json.org/img/value.png)
>>     >
>>     > This diagram describes an algebraic data type (a sum of
>>     products), which we
>>     > model directly with a set of Java interfaces:
>>     >
>>     > ```
>>     > interface JsonValue { }
>>     > interface JsonArray extends JsonValue { List<JsonValue> values(); }
>>     > interface JsonObject extends JsonValue { Map<String, JsonValue>
>>     members(); }
>>     > interface JsonNumber extends JsonValue { Number toNumber(); }
>>     > interface JsonString extends JsonValue { String value(); }
>>     > interface JsonBoolean extends JsonValue? { boolean value(); }
>>     > interface JsonNull extends JsonValue { }
>>     > ```
>>     >
>>     > These interfaces have (hidden) companion implementation classes
>>     that admit
>>     > greater flexibility of implementation than modeling them
>>     directly with records
>>     > would permit.
>>     > Further, these interfaces are unsealed. We compromise on the
>>     sealed sum of
>>     > products to enable
>>     > alternative implementations, for example to support alternative
>>     formats that
>>     > encode the same information in a JSON document but in a more
>>     efficient form than
>>     > text.
>>     >
>>     > The API has static methods for parsing strings into a
>>     `JsonValue`, conversion to
>>     > and from purely untyped representations (lists and maps), and
>>     factory methods
>>     > for building JSON documents. We apply composition consistently,
>>     e.g, a
>>     > JsonString has a string, a JsonObject has a map of string to
>>     JsonValue, as
>>     > opposed to extension for structural JSON values.
>>     >
>>     > It turns out that this simple API is almost all we need for
>>     traversal. It gives
>>     > us an immutable representation of a document, and we can use
>>     pattern matching to
>>     > answer the myriad questions that will come up (Does this object
>>     have key X? Does
>>     > it map to a number? Is that number representable as an
>>     integer?) when going
>>     > from an untyped format like JSON to a more strongly typed
>>     domain model.
>>     > Given a simple document like:
>>     >
>>     > ```
>>     >? ? {
>>     >? ? ? ? "name": "John?,
>>     >? ? ? ? "age": 30
>>     >? ? }
>>     > ```
>>     >
>>     > we can parse and traverse the document as follows:
>>     >
>>     > ```
>>     > JsonValue doc = Json.parse(inputString);
>>     > if (doc instanceof JsonObject o
>>     >? ? && o.members().get("name") instanceof JsonString s
>>     >? ? && s.value() instanceof String name
>>     >? ? && o.members().get("age") instanceof JsonNumber n
>>     >? ? && n.toNumber() instanceof Long l && l instanceof int age) {
>>     >? ? ? ? ? ? // use "name" and "age"
>>     >? ? ? ? }
>>     > ```
>>     >
>>     > Later, when the language acquires the ability to expose
>>     deconstruction patterns
>>     > for arbitrary interfaces (similar to today's record patterns, see
>>     >
>>     https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns),
>>     > this will be simplifiable to:
>>     >
>>     > ```
>>     > JsonValue doc = Json.parse(inputString);
>>     > if (doc instanceof JsonObject(var members)
>>     >? ? && members.get("name") instanceof JsonString(String name)
>>     >? ? && members.get("age") instanceof JsonNumber(int age)) {
>>     >? ? ? ? ? ? // use "name" and "age"
>>     >? ? ? ? }
>>     > ```
>>     >
>>     > So, overtime, as more pattern matching features are introduced
>>     we anticipate
>>     > improved use of the API. This is a primary reason why the API
>>     is so minimal.
>>     > Convenience methods we add today, such as a method that
>>     accesses a JSON
>>     > object component as say a JSON string or throws an exception,
>>     will become
>>     > redundant in the future.
>>     >
>>     > ## JSON numbers
>>     >
>>     > The specification of JSON number makes no explicit distinction
>>     between integral
>>     > and decimal numbers, nor specifies limits on the size of those
>>     numbers.
>>     > This is a common source of interoperability issues when
>>     consuming JSON
>>     > documents. Generally users cannot always but often do assume
>>     JSON numbers are
>>     > parsable, without loss of precision, to IEEE double-precision
>>     floating point
>>     > numbers or 32-bit signed integers.
>>     >
>>     > In this respect the API provides three means to operate on the
>>     JSON number,
>>     > giving the user full control:
>>     >
>>     > 1. Underlying string representation can be obtained, if
>>     preserving syntactic
>>     >? ?details such as leading or trailing zeros is important.
>>     > 2. The string representation can be parsed to an instance of
>>     `BigDecimal`, using
>>     >? ?`toBigDecimal` if preserving decimal numbers is important.
>>     > 3. The string representation can be parsed into an instance of
>>     `Long`, `Double`,
>>     >? ?`BigInteger`, or `BigDecimal`, using `toNumber`. The result
>>     of this method
>>     >? ?depends on how the representation can be parsed, possibly
>>     losing precision,
>>     >? ?choosing a suitably convenient numeric type that can then be
>>     pattern
>>     >? ?matched on.
>>     >
>>     > Primitive pattern matching will help as will further pattern
>>     matching features
>>     > enabling the user to partially match.
>>     >
>>     > ## Prototype implementation
>>     >
>>     > The prototype implementation is currently located into the JDK
>>     sandbox
>>     > repository
>>     > under the `json` branch, see
>>     > here
>>     >
>>     https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json
>>     > The prototype API javadoc generated from the repository is also
>>     available at
>>     >
>>     https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html
>>     >
>>     > ### Testing and conformance
>>     >
>>     > The prototype implementation passes all conformance test cases
>>     but two,
>>     > available
>>     > on https://github.com/nst/JSONTestSuite. The two exceptions are
>>     the ones which
>>     > the
>>     > prototype specifically prohibits, i.e, duplicated names in JSON
>>     objects
>>     >
>>     (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35).
>>     >
>>     > ### Performance
>>     >
>>     > Our main focus so far has been on the API design and a functional
>>     > implementation.
>>     > Hence, there has been less focus on performance even though we
>>     know there are a
>>     > number of performance enhancements we can make eventually.
>>     > We are reasonably happy with the current performance. The
>>     > implementation performs well when compared to other JSON
>>     implementations
>>     > parsing from string instances and traversing documents.
>>     >
>>     > An example of where we may choose simplicity and usability over
>>     performance
>>     > is the rejection of JSON documents containing objects that in
>>     turn contain
>>     > members
>>     > with duplicate names. That may increase the cost of parsing,
>>     but simplifies the
>>     > user
>>     > experience for the majority of cases since if we reasonably
>>     assume JsonObjects
>>     > are
>>     > map-like, what should the user do with such members, pick one
>>     the last one?
>>     > merge
>>     > the values? or reject?
>>     >
>>     > ## A JSON JEP?
>>     >
>>     > We plan to draft JEP when we are ready. Attentive readers will
>>     observe that
>>     > a JEP already exists, JEP 198: Light-Weight JSON API
>>     > (https://openjdk.org/jeps/198). We will
>>     > either update this JEP, or withdraw it and draft a new one.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250516/17b7442f/attachment-0001.htm>

From vyazici at openjdk.org  Fri May 16 13:29:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 16 May 2025 13:29:55 GMT
Subject: RFR: 8357063: Document preconditions for DecimalDigits methods
 [v2]
In-Reply-To: <liYvUMvisU5SEUT-YCTjE-qbXxJeQsa_c_bM7CYWs8w=.a3b52c8a-cd3a-46ee-b3b2-7488d2b78e40@github.com>
References: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
 <liYvUMvisU5SEUT-YCTjE-qbXxJeQsa_c_bM7CYWs8w=.a3b52c8a-cd3a-46ee-b3b2-7488d2b78e40@github.com>
Message-ID: <vLdUctCUVo1VtgIUZQiTwIKpsEjoB-zxviAlt-QV8Fg=.7db2e621-139d-4734-b4ec-ef6eab6176e0@github.com>

On Fri, 16 May 2025 09:45:43 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Similar to PR #24982 
>> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - assert
>  - document add warnings

@wenshao, thanks for the kind effort ? dropped suggestions to match the messages with the ones in JLA.

I prefer *all*<sup>1</sup> `public`, `unchecked`-prefixed `DecimalDigits` methods to start with a sufficient `assert` preamble, to fail as early as possible. Though I don't want to create redundant extra work, hence double checking: @jaikiran, @minborg, @liach, WDYT?

<sup>1</sup> Currently, only two `private` methods are introduced `assert`s, which are fine.

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 147:

> 145:      * integer.
> 146:      * <p>
> 147:      * <b>WARNING: Used by trusted callers.  Assumes all necessary bounds checks have been done by the caller. </b>

Suggestion:

     * <b>WARNING: This method does not perform any bound checks. </b>

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 198:

> 196:      * long.
> 197:      * <p>
> 198:      * <b>WARNING: Used by trusted callers.  Assumes all necessary bounds checks have been done by the caller. </b>

Suggestion:

     * <b>WARNING: This method does not perform any bound checks. </b>

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 251:

> 249:      * UTF-16 coder.
> 250:      * <p>
> 251:      * <b>WARNING: Used by trusted callers.  Assumes all necessary bounds checks have been done by the caller. </b>

Suggestion:

     * <b>WARNING: This method does not perform any bound checks.</b>

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 294:

> 292:      * UTF-16 coder.
> 293:      * <p>
> 294:      * <b>WARNING: Used by trusted callers.  Assumes all necessary bounds checks have been done by the caller. </b>

Suggestion:

     * <b>WARNING: This method does not perform any bound checks.</b>

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 409:

> 407:      * only least significant 16 bits of {@code v} are used.
> 408:      * <p>
> 409:      * <b>WARNING: Used by trusted callers.  Assumes all necessary bounds checks have been done by the caller. </b>

Suggestion:

     * <b>WARNING: This method does not perform any bound checks.</b>

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 440:

> 438:      * <p>
> 439:      * <b>WARNING: Used by trusted callers.  Assumes all necessary bounds checks have been done by the caller. </b>
> 440:      */

No need for this level of verbosity for private methods.

Suggestion:

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 449:

> 447:      * <p>
> 448:      * <b>WARNING: Used by trusted callers.  Assumes all necessary bounds checks have been done by the caller. </b>
> 449:      */

No need for this level of verbosity for private methods.

Suggestion:

-------------

PR Review: https://git.openjdk.org/jdk/pull/25246#pullrequestreview-2846561005
PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2093002611
PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2093005955
PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2093006521
PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2093007264
PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2093009890
PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2093014576
PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2093015088

From duke at openjdk.org  Fri May 16 13:32:54 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 16 May 2025 13:32:54 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v6]
In-Reply-To: <nzlgNFOS19-pWtj6EjtduLAMgwO1vXjn81Fi9gCBws0=.02b124e4-a9e2-48db-994d-42bfbc62cdbc@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <Fe1FcysTPgZYA1aEUGFHRfBxnQ_QkYXJ-4it0QscrS8=.7c1fa510-c570-481c-aa40-5cca05667f34@github.com>
 <nzlgNFOS19-pWtj6EjtduLAMgwO1vXjn81Fi9gCBws0=.02b124e4-a9e2-48db-994d-42bfbc62cdbc@github.com>
Message-ID: <P445HUqyZZyqKYkHTKNeVzJEGAt4ZpUXcfNUqdsgD3o=.0eb60b30-7d94-42a8-b7d9-22678e86b66a@github.com>

On Thu, 15 May 2025 22:43:54 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make magBitLength() an instance method
>
> src/java.base/share/classes/java/math/BigInteger.java line 3860:
> 
>> 3858:                 && Integer.lowestOneBit(mag[0]) == mag[0]
>> 3859:                 && numberOfTrailingZeroInts() == mag.length - 1
>> 3860:             ? magBitLength() - 1 : magBitLength();
> 
> Suggestion:
> 
>         int[] mag = this.mag;
>         return magBitLength() 
>                 - (signum < 0
>                    // Check if magnitude is a power of two
>                    && Integer.lowestOneBit(mag[0]) == mag[0]
>                    && numberOfTrailingZeroInts() == mag.length - 1
>                    ? 1 : 0);
> 
> 
> In this way, codeSize will drop from 52 to 45

What is the usefulness of doing `int[] mag = this.mag;` at line 3856?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2093057326

From iklam at openjdk.org  Fri May 16 13:55:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 16 May 2025 13:55:01 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v12]
In-Reply-To: <JoyEhrXuHQMMjc5wSmogN0045YycfgZbi1YkpP3Ef8g=.ba201c18-7077-451a-b4b9-adafa9278b7f@github.com>
References: <AdBmCAbqhjQEP05JBlXhp21hKuxn7SAb7h0Y3Wvollk=.21c0e6fe-097e-41e4-afa3-45b108112a28@github.com>
 <JoyEhrXuHQMMjc5wSmogN0045YycfgZbi1YkpP3Ef8g=.ba201c18-7077-451a-b4b9-adafa9278b7f@github.com>
Message-ID: <UEYTpkFeTUy8gfbtpFoJdeYxcoN85gsKeMuJaqOuUyY=.6e3c4e03-8e6b-4f44-8c1b-252ddcba722b@github.com>

On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin <tpushkin at openjdk.org> 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:
> 
>   Make supertype obstruction check easier to understand

Tests passed.
Thank you @TimPushkin for contributing this fix to OpenJDK!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2886788769

From tpushkin at openjdk.org  Fri May 16 13:55:02 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 16 May 2025 13:55:02 GMT
Subject: Integrated: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive
In-Reply-To: <AdBmCAbqhjQEP05JBlXhp21hKuxn7SAb7h0Y3Wvollk=.21c0e6fe-097e-41e4-afa3-45b108112a28@github.com>
References: <AdBmCAbqhjQEP05JBlXhp21hKuxn7SAb7h0Y3Wvollk=.21c0e6fe-097e-41e4-afa3-45b108112a28@github.com>
Message-ID: <02V6k1T_kM2Aq8FAjh_iNUBd0XOytqkaR1Bk_g38iNc=.6abbc194-f49d-42de-9c96-3baf2857429f@github.com>

On Tue, 25 Mar 2025 11:08:24 GMT, Timofei Pushkin <tpushkin at openjdk.org> 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.

This pull request has now been integrated.

Changeset: 46a12e78
Author:    Timofei Pushkin <tpushkin at openjdk.org>
Committer: Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46a12e781edcbe9da7bd39eb9e101fc680053cef
Stats:     671 lines in 13 files changed: 486 ins; 122 del; 63 mod

8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive

Reviewed-by: iklam, ccheung

-------------

PR: https://git.openjdk.org/jdk/pull/24223

From rotanolexandr842 at gmail.com  Fri May 16 14:06:06 2025
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Fri, 16 May 2025 17:06:06 +0300
Subject: Towards a JSON API for the JDK
In-Reply-To: <a5db35c2-800d-4b4a-99f4-91a47008aaac@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gt3GNjDPS2m-2wha5AwgumMvBRxKw+bwgTCNQ1xCiDfg@mail.gmail.com>
 <b0e7ff8e-f6dc-48b1-ad0f-5de52d8191b3@apache.org>
 <a5db35c2-800d-4b4a-99f4-91a47008aaac@oracle.com>
Message-ID: <CAL5bRt9S310+_mHJ+vXC0Hapg6xqbc9UnwgRSGsbjY_tbchziA@mail.gmail.com>

I would like to add JSON comments from my perspective.

I had a requirement of working with JSON in java multiple times during
working on the university assignments recently. Since those are small,
often one-time-open projects, I did not want (or, often, it was forbidden
by assignment) to pull in whole jackson with modules and staff, along with
gradle and rocket launchers, so i had to work out my own small parser
for the JSON, since this is a pretty trivial task in its core. I want to
note that none of the times I had the necessity to write comments in the
JSON or parse input with them.That is why I think that for the cases when
you would use raw jdk JSON API, comments in the JSON are extremely exotic.

On the other hand, If you are working on the full-blown enterprise-grade
project, and want the JSON to facilitate your configs, then use yaml you
will most likely already have your JSON parser with comments support
included by your framework, whether it is jackson, gson or something else.

I think the key point here is that jdk JSON API, as it seems to me, does
not aim to obsolete any of the existing (de)serialization libraries, and is
rather intended to be the core, backbone of those, along with the direct
JSON support for the simplest cases, much like virtually no one uses
security mechanisms of the JDK directly instead of relying on
libraries/frameworks aka spring security. I think voice on whether to add
some non-standard syntax support for JSON here belongs to maintainers of
such libraries. To me, at least, it seems like this libs will be able to
use this API with some required preprocessing done on the raw strings
before, via regex or any other more performant/comfortable method

Best regards

On Fri, May 16, 2025 at 4:17?PM Brian Goetz <brian.goetz at oracle.com> wrote:

> At first, we were hopeful that we could jump right to JSON5, which appears
> at first glance to be a strictly lexical, more permissive grammar for JSON
> (supporting comments, trailing commas, more flexible quoting, white space,
> etc.)  If that were actually true, this would have been a slam dunk, since
> all these lexical niceties don't have an impact on the parsed results.  And
> JSON5 has been gaining some traction, so it probably could have been a
> justifiable move to jump right to that.
>
> But then we discovered that JSON5 also sneaks in some semantics, by also
> supporting the exotic numeric values (NaN, infinities, signed zero), which
> now has consequences for "what is a number", the numeric representation,
> the API for unpacking numeric values, etc.  (Having multiple parsers is one
> thing; having multiple parsers that produce different semantics is entirely
> another.)  And inventing a new "JSON5 but not quite" subset would be doing
> no one any favors.
>
> Jsonc seems to be entirely a MS-ecosystem thing; it does not have broad
> enough traction to be the "one grammar" we accept.  So pure JSON, as
> specification-challenged as it is, is the logical, though sad, conclusion
> (for now.)
>
>
>
> On 5/16/2025 9:02 AM, Lars Bruun-Hansen wrote:
>
>
> Great work.
>
>
> I feel the elephant in the room needs to addressed: JSON comments. I
> haven't tested the proposed lib but I cannot see it mentioned so I'm
> assuming that comments are not supported.
>
> For better or worse, the use of jsonc (JSON with comments) is everywhere
> in some ecosystems. Unsurprisingly this happens often when JSON is used as
> a config file format. Looking at you, Microsoft.
>
> It would be nice if the JDK's build-in JSON parser at least recognized
> this.
>
> I'm well aware that comments are frowned upon in JSON and not part of
> neither the spec at www.json.org nor the RFC-8259.
>
> Yet, I advocate the JDK JSON library should optionally allow comments to
> be ignored when PARSING. This should be an opt-in feature that would
> technically treat comments as whitespace during the parsing process.
>
> This would also be in line with what many other parsers do. For example,
> Jackson has "ALLOW_COMMENTS" feature [1]. Also, by comparison, the build-in
> parser in the .NET world, known as System.Text.Json, also supports this
> [2].
>
>
>
> The "discoverer" of JSON, Douglas Crowford, had this to say [3] on the
> topic:
>
>
> [QUOTE]
>
> I removed comments from JSON because I saw people were using them to hold
> parsing directives, a practice which would have destroyed interoperability.
> I know that the lack of comments makes some people sad, but it shouldn't.
>
> Suppose you are using JSON to keep configuration files, which you would
> like to annotate. Go ahead and insert all the comments you like. Then pipe
> it through JSMin before handing it to your JSON parser.
>
>  [/QUOTE]
>
>
> By not having the ability to ignore comments when parsing we would
> effectively force users to use another parser first or a minifier. I doubt
> beginners would appreciate that.
>
>
> BTW: The test suite already has tests for comments.
>
>
> /Lars
>
>
> [1]:
> https://www.javadoc.io/static/com.fasterxml.jackson.core/jackson-core/2.19.0/com/fasterxml/jackson/core/JsonParser.Feature.html#ALLOW_COMMENTS
>
> [2]:
> https://learn.microsoft.com/en-us/dotnet/api/system.text.json.jsonreaderoptions?view=net-9.0#properties
>
> [3]: https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr
>
>
>
>
> On 16/05/2025 01.44, Ethan McCue wrote:
>
> I present for your consideration the library I made when spiraling about
> this problem space a few years ago
>
> https://github.com/bowbahdoe/json
>
>
> https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html
>
> Notably missing during the design process here were patterns, hence the
> JsonDecoder design. I haven't been able to evaluate how patterns affect
> that on account of them not being out.
>
> I will more thoroughly peruse the draft of java.util.json at a later date,
> but my initial observations/comments:
>
> * I am not sure having JsonValue be distinct from Json has value.
> * toUntyped feels a little strange to me - the only type information
> presumably lost is the sealed-ness of the hierarchy. The interplay between
> that and toNumber is also a little unnerving.
> * One notion that I found helpful was that a class could be "json
> encodable," meaning there is a method to call to obtain a canonical json
> representation.
>
> record Person(String name) implements JsonEncodable {
>     @Override
>     public Json toJson() {
>         return Json.objectBuilder()
>             .put("namen", name)
>             .build();
>     }
> }
>
> Which helper methods like Json#of(List<? extends JsonEncodable>) could
> make use of. Json itself (JsonValue in your prototype) could then have a
> vacuous implementation.
>
> * Terminology wise - I went with reading/writing for the actual
> parsing/generation of json and encoding/decoding for the mapping of those
> representations to/from specific classes. The merits are not top of mind,
> just noting the difference. read/write vs parse/toString+toDisplayString
> * One thing I did was make the helper methods in Json null tolerant and
> the ones in the specific subtypes like JsonString not. This was because
> from what I saw of usages of javax.json/jakarta.json that nullability was a
> footgun and correcting for it required changes to code structure (breaking
> up builder chains with if (x != null) checks)
> * The functionality you want from JsonNumber could be achieved by making
> it just extend Number (
> https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/JsonNumber.java)
> instead of a bespoke toNumber. You need the extra methods to go to big
> decimal and co, but it's just an extension to the behavior of Number at
> that point.
> * JsonObject and JsonArray could implement Map<String, Json> and
> List<Json> respectively. This lowers the need for toUntyped() - since
> presumably one of the use cases for that is turning the json tree into
> something that more generic map/list traversal code can handle. It also
> complicates any lazy loading somewhat.
> * Assuming patterns can be placed on interfaces, you might want to
> consider something similar to JsonDecoder, but with a pattern instead of
> a method that throws an exception.
>
> // Where here fromJson would box up the logic for testing and extracting
> from each element in the array.
> List<Person> people = array(json, Person::fromJson);
>
> * I don't think there is sufficient cause for anything to be non-sealed at
> this point.
> * JsonBoolean and JsonNull do not have reasonable alternative
> implementations - as far as I can imagine, maybe i'm wrong - so maybe those
> can just be final classes?
> * If you seal up the whole hierarchy then its pretty trivial to make it
> serializable (
> https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/serialization/JsonSerializationProxy.java
> )
>
>
>
>
> On Thu, May 15, 2025 at 11:29?PM Remi Forax <forax at univ-mlv.fr> wrote:
>
>> Hi Paul,
>> yes, not having a simple JSON API in Java is an issue for beginners.
>>
>> It's not clear to me why JsonArray (for example) has to be an interface
>> instead of a record ?
>>
>> I understand why Json.parse() only works on String and char[] but the API
>> make it too easy to have many performance issues.
>> I think you need versions using a Reader and a Path.
>> Bonus point, if there is a method walk() that also returns a JsonValue
>> but the List/Map inside JsonArray/JsonObject are populated lazily.
>>
>> Minor point: Json.toDisplayString() should takes a second parameters
>> indicating the number of spaces used for the indentation (like
>> JSON.stringify in JS).
>>
>> regards,
>> R?mi
>>
>> ----- Original Message -----
>> > From: "Paul Sandoz" <paul.sandoz at oracle.com>
>> > To: "core-libs-dev" <core-libs-dev at openjdk.org>
>> > Sent: Thursday, May 15, 2025 10:30:42 PM
>> > Subject: Towards a JSON API for the JDK
>>
>> > Hi,
>> >
>> > We would like to share with you our thoughts and plans towards a JSON
>> API for
>> > the JDK.
>> > Please see the document below.
>> >
>> > -
>> >
>> > We have had the pleasure of using a clone of this API in some
>> experiments we are
>> > conducting with
>> > ONNX and code reflection [1]. Using the API we were able to quickly
>> write code
>> > to ingest and convert
>> > a JSON document representing ONNX operation schema into instances of
>> records
>> > modeling the schema
>> > (see here [2]).
>> >
>> > The overall out-of-box experience with such a minimal "batteries
>> included? API
>> > has so far been positive.
>> >
>> > Thanks,
>> > Paul.
>> >
>> > [1] https://openjdk.org/projects/babylon/
>> > [2]
>> >
>> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87
>> >
>> > # Towards a JSON API for the JDK
>> >
>> > One of the most common requests for the JDK is an API for parsing and
>> generating
>> > JSON. While JSON originated as a text-based serialization format for
>> JSON
>> > objects ("JSON" stands for "JavaScript Object Notation"), because of
>> its simple
>> > and flexible syntax, it eventually found use outside the JavaScript
>> ecosystem as
>> > a general data interchange format, such as framework configuration
>> files and web
>> > service requests/response formats.
>> >
>> > While the JDK cannot, and should not, provide libraries for every
>> conceivable
>> > file format or protocol, the JDK philosophy is one of "batteries
>> included",
>> > which is to say we should be able to write basic programs that use
>> common
>> > protocols such as HTTP, without having to appeal to third party
>> libraries.
>> > The Java ecosystem already has plenty of JSON libraries, so inclusion in
>> > the JDK is largely meant to be a convenience, rather than needing to be
>> the "one
>> > true" JSON library to meet the needs of all users. Users with specific
>> needs
>> > are always free to select one of the existing third-party libraries.
>> >
>> > ## Goals and requirements
>> >
>> > Our primary goal is that the library be simple to use for parsing,
>> traversing,
>> > and generating conformant JSON documents. Advanced features, such as
>> data
>> > binding or path-based traversal should be possible to implement as
>> layered
>> > features, but for simplicity are not included in the core API. We adopt
>> a goal
>> > that the performance should be "good enough", but where performance
>> > considerations conflict with simplicity and usability, we will choose
>> in favor
>> > of the latter.
>> >
>> > ## API design approach
>> >
>> > The description of JSON at `https:://json.org` describes a JSON
>> document using
>> > the familiar "railroad diagram":
>> > ![image](https://www.json.org/img/value.png)
>> >
>> > This diagram describes an algebraic data type (a sum of products),
>> which we
>> > model directly with a set of Java interfaces:
>> >
>> > ```
>> > interface JsonValue { }
>> > interface JsonArray extends JsonValue { List<JsonValue> values(); }
>> > interface JsonObject extends JsonValue { Map<String, JsonValue>
>> members(); }
>> > interface JsonNumber extends JsonValue { Number toNumber(); }
>> > interface JsonString extends JsonValue { String value(); }
>> > interface JsonBoolean extends JsonValue  { boolean value(); }
>> > interface JsonNull extends JsonValue { }
>> > ```
>> >
>> > These interfaces have (hidden) companion implementation classes that
>> admit
>> > greater flexibility of implementation than modeling them directly with
>> records
>> > would permit.
>> > Further, these interfaces are unsealed. We compromise on the sealed sum
>> of
>> > products to enable
>> > alternative implementations, for example to support alternative formats
>> that
>> > encode the same information in a JSON document but in a more efficient
>> form than
>> > text.
>> >
>> > The API has static methods for parsing strings into a `JsonValue`,
>> conversion to
>> > and from purely untyped representations (lists and maps), and factory
>> methods
>> > for building JSON documents. We apply composition consistently, e.g, a
>> > JsonString has a string, a JsonObject has a map of string to JsonValue,
>> as
>> > opposed to extension for structural JSON values.
>> >
>> > It turns out that this simple API is almost all we need for traversal.
>> It gives
>> > us an immutable representation of a document, and we can use pattern
>> matching to
>> > answer the myriad questions that will come up (Does this object have
>> key X? Does
>> > it map to a number? Is that number representable as an integer?) when
>> going
>> > from an untyped format like JSON to a more strongly typed domain model.
>> > Given a simple document like:
>> >
>> > ```
>> >    {
>> >        "name": "John?,
>> >        "age": 30
>> >    }
>> > ```
>> >
>> > we can parse and traverse the document as follows:
>> >
>> > ```
>> > JsonValue doc = Json.parse(inputString);
>> > if (doc instanceof JsonObject o
>> >    && o.members().get("name") instanceof JsonString s
>> >    && s.value() instanceof String name
>> >    && o.members().get("age") instanceof JsonNumber n
>> >    && n.toNumber() instanceof Long l && l instanceof int age) {
>> >            // use "name" and "age"
>> >        }
>> > ```
>> >
>> > Later, when the language acquires the ability to expose deconstruction
>> patterns
>> > for arbitrary interfaces (similar to today's record patterns, see
>> >
>> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns
>> ),
>> > this will be simplifiable to:
>> >
>> > ```
>> > JsonValue doc = Json.parse(inputString);
>> > if (doc instanceof JsonObject(var members)
>> >    && members.get("name") instanceof JsonString(String name)
>> >    && members.get("age") instanceof JsonNumber(int age)) {
>> >            // use "name" and "age"
>> >        }
>> > ```
>> >
>> > So, overtime, as more pattern matching features are introduced we
>> anticipate
>> > improved use of the API. This is a primary reason why the API is so
>> minimal.
>> > Convenience methods we add today, such as a method that accesses a JSON
>> > object component as say a JSON string or throws an exception, will
>> become
>> > redundant in the future.
>> >
>> > ## JSON numbers
>> >
>> > The specification of JSON number makes no explicit distinction between
>> integral
>> > and decimal numbers, nor specifies limits on the size of those numbers.
>> > This is a common source of interoperability issues when consuming JSON
>> > documents. Generally users cannot always but often do assume JSON
>> numbers are
>> > parsable, without loss of precision, to IEEE double-precision floating
>> point
>> > numbers or 32-bit signed integers.
>> >
>> > In this respect the API provides three means to operate on the JSON
>> number,
>> > giving the user full control:
>> >
>> > 1. Underlying string representation can be obtained, if preserving
>> syntactic
>> >   details such as leading or trailing zeros is important.
>> > 2. The string representation can be parsed to an instance of
>> `BigDecimal`, using
>> >   `toBigDecimal` if preserving decimal numbers is important.
>> > 3. The string representation can be parsed into an instance of `Long`,
>> `Double`,
>> >   `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this
>> method
>> >   depends on how the representation can be parsed, possibly losing
>> precision,
>> >   choosing a suitably convenient numeric type that can then be pattern
>> >   matched on.
>> >
>> > Primitive pattern matching will help as will further pattern matching
>> features
>> > enabling the user to partially match.
>> >
>> > ## Prototype implementation
>> >
>> > The prototype implementation is currently located into the JDK sandbox
>> > repository
>> > under the `json` branch, see
>> > here
>> >
>> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json
>> > The prototype API javadoc generated from the repository is also
>> available at
>> >
>> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html
>> >
>> > ### Testing and conformance
>> >
>> > The prototype implementation passes all conformance test cases but two,
>> > available
>> > on https://github.com/nst/JSONTestSuite. The two exceptions are the
>> ones which
>> > the
>> > prototype specifically prohibits, i.e, duplicated names in JSON objects
>> > (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35
>> ).
>> >
>> > ### Performance
>> >
>> > Our main focus so far has been on the API design and a functional
>> > implementation.
>> > Hence, there has been less focus on performance even though we know
>> there are a
>> > number of performance enhancements we can make eventually.
>> > We are reasonably happy with the current performance. The
>> > implementation performs well when compared to other JSON implementations
>> > parsing from string instances and traversing documents.
>> >
>> > An example of where we may choose simplicity and usability over
>> performance
>> > is the rejection of JSON documents containing objects that in turn
>> contain
>> > members
>> > with duplicate names. That may increase the cost of parsing, but
>> simplifies the
>> > user
>> > experience for the majority of cases since if we reasonably assume
>> JsonObjects
>> > are
>> > map-like, what should the user do with such members, pick one the last
>> one?
>> > merge
>> > the values? or reject?
>> >
>> > ## A JSON JEP?
>> >
>> > We plan to draft JEP when we are ready. Attentive readers will observe
>> that
>> > a JEP already exists, JEP 198: Light-Weight JSON API
>> > (https://openjdk.org/jeps/198). We will
>> > either update this JEP, or withdraw it and draft a new one.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250516/0c95b7e8/attachment-0001.htm>

From liach at openjdk.org  Fri May 16 14:13:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 16 May 2025 14:13:51 GMT
Subject: RFR: 8357063: Document preconditions for DecimalDigits methods
 [v2]
In-Reply-To: <liYvUMvisU5SEUT-YCTjE-qbXxJeQsa_c_bM7CYWs8w=.a3b52c8a-cd3a-46ee-b3b2-7488d2b78e40@github.com>
References: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
 <liYvUMvisU5SEUT-YCTjE-qbXxJeQsa_c_bM7CYWs8w=.a3b52c8a-cd3a-46ee-b3b2-7488d2b78e40@github.com>
Message-ID: <MbHRXyxnGE-vnJhRa0QOJzYlD_cg33tMZsh2Zw4s9kc=.6daccbe3-1a65-4058-b7d2-ddbcb324136e@github.com>

On Fri, 16 May 2025 09:45:43 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Similar to PR #24982 
>> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - assert
>  - document add warnings

Re assert preamble for public methods: Unfortunately this is not possible. The algorithm requires the chars to be written on demand, and it is very costly to precompute the length, aside from the fact that you can easily mess up on precomputation. The uncheckedness is from the 2 private methods, so I think safeguarding the 2 private methods with assertions is sufficient.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25246#issuecomment-2886837958

From abarashev at openjdk.org  Fri May 16 14:18:04 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 16 May 2025 14:18:04 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v5]
In-Reply-To: <l0kZnNDdN-TbltTkaEW4yohiocDPHWvIJu34Nl8em8g=.02e58472-5252-414f-bfa6-9c06af35d5b6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <l0kZnNDdN-TbltTkaEW4yohiocDPHWvIJu34Nl8em8g=.02e58472-5252-414f-bfa6-9c06af35d5b6@github.com>
Message-ID: <EMJKUCvmH5GGspaxvi-i63I23SvZnC0kK0SBI00Q4Zo=.e5d81154-b673-4b8f-8f4d-3df12dd16829@github.com>

On Fri, 9 May 2025 14:39:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 422 commits:
> 
>  - merge latest changes from master branch
>  - Undo whitespace change
>  - Remove unnecessary import
>  - Merge remote-tracking branch 'origin/master' into http3
>  - Fix test license
>  - Remove leftover file (test was moved to parent directory)
>  - Remove unnecessary import
>  - Update throws clauses
>  - Merge remote-tracking branch 'origin/master' into http3
>  - 8354275: Add HTTP/3 tests to `EmptyAuthenticate`
>  - ... and 412 more: https://git.openjdk.org/jdk/compare/568dcc15...8c27f53c

@seanjmullan @djelinski We should probably re-evaluate the priority of `TLS Certificate Compression` JEP:
https://bugs.openjdk.org/browse/JDK-8281710

Certificate compression seems to be [particularly important for QUIC performance](https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study), the work has been started already in #7599

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24751#issuecomment-2886849963

From jpai at openjdk.org  Fri May 16 14:25:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 14:25:59 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
Message-ID: <PnCfACKzgUPJFmIl1jOToEJHjKVfNvQq8ZDYu9mgB4s=.48fc1387-134d-42a6-ae86-8a08e398a906@github.com>

On Thu, 15 May 2025 18:27:35 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes based on review feedback.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 114:

> 112:     private final ZipPath rootdir;
> 113:     // Starts in readOnly (safe mode), but might be reset at the end of initialization.
> 114:     private boolean readOnly = true;

If `readOnly` gets used by some code when a `ZipFileSystem` instance is being constructed (which is why I believe this can't be a `final` field), then I think we should not change this value to `true`. In other words, would this change now have a chance of introducing a `ReadOnlyFileSystemException` when constructing the `ZipFileSystem` whereas before it wouldn't?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093154523

From lbruun at apache.org  Fri May 16 14:28:38 2025
From: lbruun at apache.org (Lars Bruun-Hansen)
Date: Fri, 16 May 2025 16:28:38 +0200
Subject: Towards a JSON API for the JDK
In-Reply-To: <a5db35c2-800d-4b4a-99f4-91a47008aaac@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gt3GNjDPS2m-2wha5AwgumMvBRxKw+bwgTCNQ1xCiDfg@mail.gmail.com>
 <b0e7ff8e-f6dc-48b1-ad0f-5de52d8191b3@apache.org>
 <a5db35c2-800d-4b4a-99f4-91a47008aaac@oracle.com>
Message-ID: <2bae7231-7d5d-47d0-8eea-1ef1b4030b6b@apache.org>


Ahh, as expected some great thoughts have gone into this. :-)

Allowing the ignore of comments when parsing is not "inventing a new
format", IMO. More so because the RFC allows it (section 9) and because
it would be strictly opt-in. So the parser can still be said to be
strictly RFC-8259 while optionally supporting such feature. I'm
speculating the authors of the RFC has thought of it as a form a
pre-processing when they used the word "extension" and that is indeed a
good way to think about it.

In any case my goal was purely comments in the JSON, not about allowing
other forms of leniency, like trailing commas, flexible quotes, etc. I
feel those are in another category and not something that should (ever)
be supported. I can see why someone might ask for that if comments where
allowed to be ignored by the lib. The argument about slippery slope can
be made. I just fear that newbies will try to build their own
pre-processor, using regexp or whatever .. and get it wrong.

I agree with you that JSON5 sneaks in too many odd things.

Keep up the good work.

/Lars


On 16/05/2025 15.17, Brian Goetz wrote:
> At first, we were hopeful that we could jump right to JSON5, which
> appears at first glance to be a strictly lexical, more permissive
> grammar for JSON (supporting comments, trailing commas, more flexible
> quoting, white space, etc.)? If that were actually true, this would
> have been a slam dunk, since all these lexical niceties don't have an
> impact on the parsed results.? And JSON5 has been gaining some
> traction, so it probably could have been a justifiable move to jump
> right to that.?
>
> But then we discovered that JSON5 also sneaks in some semantics, by
> also supporting the exotic numeric values (NaN, infinities, signed
> zero), which now has consequences for "what is a number", the numeric
> representation, the API for unpacking numeric values, etc.? (Having
> multiple parsers is one thing; having multiple parsers that produce
> different semantics is entirely another.)? And inventing a new "JSON5
> but not quite" subset would be doing no one any favors.?
>
> Jsonc seems to be entirely a MS-ecosystem thing; it does not have
> broad enough traction to be the "one grammar" we accept.? So pure
> JSON, as specification-challenged as it is, is the logical, though
> sad, conclusion (for now.)
>
>
>
> On 5/16/2025 9:02 AM, Lars Bruun-Hansen wrote:
>>
>>
>> Great work.
>>
>>
>> I feel the elephant in the room needs to addressed: JSON comments. I
>> haven't tested the proposed lib but I cannot see it mentioned so I'm
>> assuming that comments are not supported.
>>
>> For better or worse, the use of jsonc (JSON with comments) is
>> everywhere in some ecosystems. Unsurprisingly this happens often when
>> JSON is used as a config file format. Looking at you, Microsoft.
>>
>> It would be nice if the JDK's build-in JSON parser at least
>> recognized this.
>>
>> I'm well aware that comments are frowned upon in JSON and not part of
>> neither the spec at www.json.org nor the RFC-8259.
>>
>> Yet, I advocate the JDK JSON library should optionally allow comments
>> to be ignored when PARSING. This should be an opt-in feature that
>> would technically treat comments as whitespace during the parsing
>> process.
>>
>> This would also be in line with what many other parsers do. For
>> example, Jackson has "ALLOW_COMMENTS" feature [1]. Also, by
>> comparison, the build-in parser in the .NET world, known as
>> System.Text.Json, also supports this [2].
>>
>>
>>
>> The "discoverer" of JSON, Douglas Crowford, had this to say [3] on
>> the topic:
>>
>>
>> [QUOTE]
>>
>> I removed comments from JSON because I saw people were using them to
>> hold parsing directives, a practice which would have destroyed
>> interoperability. I know that the lack of comments makes some people
>> sad, but it shouldn't.
>>
>> Suppose you are using JSON to keep configuration files, which you
>> would like to annotate. Go ahead and insert all the comments you
>> like. Then pipe it through JSMin before handing it to your JSON parser.
>>
>> ?[/QUOTE]
>>
>>
>> By not having the ability to ignore comments when parsing we would
>> effectively force users to use another parser first or a minifier. I
>> doubt beginners would appreciate that.
>>
>>
>> BTW: The test suite already has tests for comments.
>>
>>
>> /Lars
>>
>>
>> [1]:
>> https://www.javadoc.io/static/com.fasterxml.jackson.core/jackson-core/2.19.0/com/fasterxml/jackson/core/JsonParser.Feature.html#ALLOW_COMMENTS
>>
>> [2]:
>> https://learn.microsoft.com/en-us/dotnet/api/system.text.json.jsonreaderoptions?view=net-9.0#properties
>>
>> [3]: https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr
>>
>>
>>
>>
>> On 16/05/2025 01.44, Ethan McCue wrote:
>>> I present for your consideration the library I made when spiraling
>>> about this problem space a few years ago
>>>
>>> https://github.com/bowbahdoe/json
>>>
>>> https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html
>>>
>>> Notably missing during the design process here were patterns, hence
>>> the JsonDecoder design. I haven't been able to evaluate how patterns
>>> affect that on account of them not being out.
>>>
>>> I will more thoroughly peruse the draft of java.util.json at a later
>>> date, but my initial observations/comments:
>>>
>>> * I am not sure having JsonValue be distinct from Json has value.
>>> * toUntyped feels a little strange to me - the only type information
>>> presumably lost is the sealed-ness of the hierarchy. The interplay
>>> between that and toNumber is also a little unnerving.
>>> * One notion that I found helpful was that a class could be "json
>>> encodable," meaning there is a method to call to obtain a canonical
>>> json representation.
>>>
>>> record Person(String name) implements JsonEncodable {
>>> ? ??@Override
>>> ? ? public Json toJson() {
>>> ? ? ? ? return Json.objectBuilder()
>>> ? ? ? ? ? ? .put("namen", name)
>>> ? ? ? ? ? ? .build();
>>> ? ? }
>>> }
>>>
>>> Which helper methods like Json#of(List<? extends
>>> JsonEncodable>)?could make use of. Json?itself (JsonValue?in your
>>> prototype) could then have a vacuous implementation.
>>>
>>> * Terminology wise - I went with reading/writing for the actual
>>> parsing/generation of json and encoding/decoding for the mapping of
>>> those representations to/from specific classes. The merits are not
>>> top of mind, just noting the difference. read/write vs
>>> parse/toString+toDisplayString
>>> * One thing I did was make the helper methods in Json?null tolerant
>>> and the ones in the specific subtypes like JsonString?not. This was
>>> because from what I saw of usages of javax.json/jakarta.json that
>>> nullability was a footgun and correcting for?it required changes to
>>> code structure (breaking up builder chains with if (x != null)?checks)
>>> * The functionality you want from JsonNumber could be achieved by
>>> making it just extend Number
>>> (https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/JsonNumber.java)
>>> instead of a bespoke toNumber. You need the extra methods to go to
>>> big decimal and co, but it's just an extension to the behavior of
>>> Number at that point.
>>> * JsonObject and JsonArray could implement Map<String, Json> and
>>> List<Json> respectively. This lowers the need for toUntyped() -
>>> since presumably one of the use cases for that is turning the json
>>> tree into something that more generic map/list traversal code can
>>> handle. It also complicates any lazy loading somewhat.
>>> * Assuming patterns can be placed on interfaces, you might want to
>>> consider something similar to?JsonDecoder, but with a pattern
>>> instead of a method that throws an exception.
>>>
>>> // Where here fromJson would box up the logic for testing and
>>> extracting from each element in the array.
>>> List<Person> people = array(json, Person::fromJson);
>>>
>>> * I don't think there is sufficient cause for anything to be
>>> non-sealed at this point.
>>> * JsonBoolean and JsonNull do not have reasonable alternative
>>> implementations - as far as I can imagine, maybe i'm wrong - so
>>> maybe those can just be final classes?
>>> * If you seal up the whole hierarchy then its pretty trivial to make
>>> it serializable
>>> (https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/serialization/JsonSerializationProxy.java)
>>>
>>>
>>>
>>>
>>> On Thu, May 15, 2025 at 11:29?PM Remi Forax <forax at univ-mlv.fr> wrote:
>>>
>>>     Hi Paul,
>>>     yes, not having a simple JSON API in Java is an issue for beginners.
>>>
>>>     It's not clear to me why JsonArray (for example) has to be an
>>>     interface instead of a record ?
>>>
>>>     I understand why Json.parse() only works on String and char[]
>>>     but the API make it too easy to have many performance issues.
>>>     I think you need versions using a Reader and a Path.
>>>     Bonus point, if there is a method walk() that also returns a
>>>     JsonValue but the List/Map inside JsonArray/JsonObject are
>>>     populated lazily.
>>>
>>>     Minor point: Json.toDisplayString() should takes a second
>>>     parameters indicating the number of spaces used for the
>>>     indentation (like JSON.stringify in JS).
>>>
>>>     regards,
>>>     R?mi
>>>
>>>     ----- Original Message -----
>>>     > From: "Paul Sandoz" <paul.sandoz at oracle.com>
>>>     > To: "core-libs-dev" <core-libs-dev at openjdk.org>
>>>     > Sent: Thursday, May 15, 2025 10:30:42 PM
>>>     > Subject: Towards a JSON API for the JDK
>>>
>>>     > Hi,
>>>     >
>>>     > We would like to share with you our thoughts and plans towards
>>>     a JSON API for
>>>     > the JDK.
>>>     > Please see the document below.
>>>     >
>>>     > -
>>>     >
>>>     > We have had the pleasure of using a clone of this API in some
>>>     experiments we are
>>>     > conducting with
>>>     > ONNX and code reflection [1]. Using the API we were able to
>>>     quickly write code
>>>     > to ingest and convert
>>>     > a JSON document representing ONNX operation schema into
>>>     instances of records
>>>     > modeling the schema
>>>     > (see here [2]).
>>>     >
>>>     > The overall out-of-box experience with such a minimal
>>>     "batteries included? API
>>>     > has so far been positive.
>>>     >
>>>     > Thanks,
>>>     > Paul.
>>>     >
>>>     > [1] https://openjdk.org/projects/babylon/
>>>     > [2]
>>>     >
>>>     https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87
>>>     >
>>>     > # Towards a JSON API for the JDK
>>>     >
>>>     > One of the most common requests for the JDK is an API for
>>>     parsing and generating
>>>     > JSON. While JSON originated as a text-based serialization
>>>     format for JSON
>>>     > objects ("JSON" stands for "JavaScript Object Notation"),
>>>     because of its simple
>>>     > and flexible syntax, it eventually found use outside the
>>>     JavaScript ecosystem as
>>>     > a general data interchange format, such as framework
>>>     configuration files and web
>>>     > service requests/response formats.
>>>     >
>>>     > While the JDK cannot, and should not, provide libraries for
>>>     every conceivable
>>>     > file format or protocol, the JDK philosophy is one of
>>>     "batteries included",
>>>     > which is to say we should be able to write basic programs that
>>>     use common
>>>     > protocols such as HTTP, without having to appeal to third
>>>     party libraries.
>>>     > The Java ecosystem already has plenty of JSON libraries, so
>>>     inclusion in
>>>     > the JDK is largely meant to be a convenience, rather than
>>>     needing to be the "one
>>>     > true" JSON library to meet the needs of all users. Users with
>>>     specific needs
>>>     > are always free to select one of the existing third-party
>>>     libraries.
>>>     >
>>>     > ## Goals and requirements
>>>     >
>>>     > Our primary goal is that the library be simple to use for
>>>     parsing, traversing,
>>>     > and generating conformant JSON documents. Advanced features,
>>>     such as data
>>>     > binding or path-based traversal should be possible to
>>>     implement as layered
>>>     > features, but for simplicity are not included in the core API.
>>>     We adopt a goal
>>>     > that the performance should be "good enough", but where
>>>     performance
>>>     > considerations conflict with simplicity and usability, we will
>>>     choose in favor
>>>     > of the latter.
>>>     >
>>>     > ## API design approach
>>>     >
>>>     > The description of JSON at `https:://json.org
>>>     <http://json.org>` describes a JSON document using
>>>     > the familiar "railroad diagram":
>>>     > ![image](https://www.json.org/img/value.png)
>>>     >
>>>     > This diagram describes an algebraic data type (a sum of
>>>     products), which we
>>>     > model directly with a set of Java interfaces:
>>>     >
>>>     > ```
>>>     > interface JsonValue { }
>>>     > interface JsonArray extends JsonValue { List<JsonValue>
>>>     values(); }
>>>     > interface JsonObject extends JsonValue { Map<String,
>>>     JsonValue> members(); }
>>>     > interface JsonNumber extends JsonValue { Number toNumber(); }
>>>     > interface JsonString extends JsonValue { String value(); }
>>>     > interface JsonBoolean extends JsonValue? { boolean value(); }
>>>     > interface JsonNull extends JsonValue { }
>>>     > ```
>>>     >
>>>     > These interfaces have (hidden) companion implementation
>>>     classes that admit
>>>     > greater flexibility of implementation than modeling them
>>>     directly with records
>>>     > would permit.
>>>     > Further, these interfaces are unsealed. We compromise on the
>>>     sealed sum of
>>>     > products to enable
>>>     > alternative implementations, for example to support
>>>     alternative formats that
>>>     > encode the same information in a JSON document but in a more
>>>     efficient form than
>>>     > text.
>>>     >
>>>     > The API has static methods for parsing strings into a
>>>     `JsonValue`, conversion to
>>>     > and from purely untyped representations (lists and maps), and
>>>     factory methods
>>>     > for building JSON documents. We apply composition
>>>     consistently, e.g, a
>>>     > JsonString has a string, a JsonObject has a map of string to
>>>     JsonValue, as
>>>     > opposed to extension for structural JSON values.
>>>     >
>>>     > It turns out that this simple API is almost all we need for
>>>     traversal. It gives
>>>     > us an immutable representation of a document, and we can use
>>>     pattern matching to
>>>     > answer the myriad questions that will come up (Does this
>>>     object have key X? Does
>>>     > it map to a number? Is that number representable as an
>>>     integer?) when going
>>>     > from an untyped format like JSON to a more strongly typed
>>>     domain model.
>>>     > Given a simple document like:
>>>     >
>>>     > ```
>>>     >? ? {
>>>     >? ? ? ? "name": "John?,
>>>     >? ? ? ? "age": 30
>>>     >? ? }
>>>     > ```
>>>     >
>>>     > we can parse and traverse the document as follows:
>>>     >
>>>     > ```
>>>     > JsonValue doc = Json.parse(inputString);
>>>     > if (doc instanceof JsonObject o
>>>     >? ? && o.members().get("name") instanceof JsonString s
>>>     >? ? && s.value() instanceof String name
>>>     >? ? && o.members().get("age") instanceof JsonNumber n
>>>     >? ? && n.toNumber() instanceof Long l && l instanceof int age) {
>>>     >? ? ? ? ? ? // use "name" and "age"
>>>     >? ? ? ? }
>>>     > ```
>>>     >
>>>     > Later, when the language acquires the ability to expose
>>>     deconstruction patterns
>>>     > for arbitrary interfaces (similar to today's record patterns, see
>>>     >
>>>     https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns),
>>>     > this will be simplifiable to:
>>>     >
>>>     > ```
>>>     > JsonValue doc = Json.parse(inputString);
>>>     > if (doc instanceof JsonObject(var members)
>>>     >? ? && members.get("name") instanceof JsonString(String name)
>>>     >? ? && members.get("age") instanceof JsonNumber(int age)) {
>>>     >? ? ? ? ? ? // use "name" and "age"
>>>     >? ? ? ? }
>>>     > ```
>>>     >
>>>     > So, overtime, as more pattern matching features are introduced
>>>     we anticipate
>>>     > improved use of the API. This is a primary reason why the API
>>>     is so minimal.
>>>     > Convenience methods we add today, such as a method that
>>>     accesses a JSON
>>>     > object component as say a JSON string or throws an exception,
>>>     will become
>>>     > redundant in the future.
>>>     >
>>>     > ## JSON numbers
>>>     >
>>>     > The specification of JSON number makes no explicit distinction
>>>     between integral
>>>     > and decimal numbers, nor specifies limits on the size of those
>>>     numbers.
>>>     > This is a common source of interoperability issues when
>>>     consuming JSON
>>>     > documents. Generally users cannot always but often do assume
>>>     JSON numbers are
>>>     > parsable, without loss of precision, to IEEE double-precision
>>>     floating point
>>>     > numbers or 32-bit signed integers.
>>>     >
>>>     > In this respect the API provides three means to operate on the
>>>     JSON number,
>>>     > giving the user full control:
>>>     >
>>>     > 1. Underlying string representation can be obtained, if
>>>     preserving syntactic
>>>     >? ?details such as leading or trailing zeros is important.
>>>     > 2. The string representation can be parsed to an instance of
>>>     `BigDecimal`, using
>>>     >? ?`toBigDecimal` if preserving decimal numbers is important.
>>>     > 3. The string representation can be parsed into an instance of
>>>     `Long`, `Double`,
>>>     >? ?`BigInteger`, or `BigDecimal`, using `toNumber`. The result
>>>     of this method
>>>     >? ?depends on how the representation can be parsed, possibly
>>>     losing precision,
>>>     >? ?choosing a suitably convenient numeric type that can then be
>>>     pattern
>>>     >? ?matched on.
>>>     >
>>>     > Primitive pattern matching will help as will further pattern
>>>     matching features
>>>     > enabling the user to partially match.
>>>     >
>>>     > ## Prototype implementation
>>>     >
>>>     > The prototype implementation is currently located into the JDK
>>>     sandbox
>>>     > repository
>>>     > under the `json` branch, see
>>>     > here
>>>     >
>>>     https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json
>>>     > The prototype API javadoc generated from the repository is
>>>     also available at
>>>     >
>>>     https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html
>>>     >
>>>     > ### Testing and conformance
>>>     >
>>>     > The prototype implementation passes all conformance test cases
>>>     but two,
>>>     > available
>>>     > on https://github.com/nst/JSONTestSuite. The two exceptions
>>>     are the ones which
>>>     > the
>>>     > prototype specifically prohibits, i.e, duplicated names in
>>>     JSON objects
>>>     >
>>>     (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35).
>>>     >
>>>     > ### Performance
>>>     >
>>>     > Our main focus so far has been on the API design and a functional
>>>     > implementation.
>>>     > Hence, there has been less focus on performance even though we
>>>     know there are a
>>>     > number of performance enhancements we can make eventually.
>>>     > We are reasonably happy with the current performance. The
>>>     > implementation performs well when compared to other JSON
>>>     implementations
>>>     > parsing from string instances and traversing documents.
>>>     >
>>>     > An example of where we may choose simplicity and usability
>>>     over performance
>>>     > is the rejection of JSON documents containing objects that in
>>>     turn contain
>>>     > members
>>>     > with duplicate names. That may increase the cost of parsing,
>>>     but simplifies the
>>>     > user
>>>     > experience for the majority of cases since if we reasonably
>>>     assume JsonObjects
>>>     > are
>>>     > map-like, what should the user do with such members, pick one
>>>     the last one?
>>>     > merge
>>>     > the values? or reject?
>>>     >
>>>     > ## A JSON JEP?
>>>     >
>>>     > We plan to draft JEP when we are ready. Attentive readers will
>>>     observe that
>>>     > a JEP already exists, JEP 198: Light-Weight JSON API
>>>     > (https://openjdk.org/jeps/198). We will
>>>     > either update this JEP, or withdraw it and draft a new one.
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250516/44f686fe/attachment-0001.htm>

From jpai at openjdk.org  Fri May 16 14:32:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 14:32:53 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
Message-ID: <j5vOlgg8d8NGtb-dbaiHUrwth3sCi-Z8tpGsqq1PnGY=.6e3719fd-a7a9-49ea-802c-7fccc764615f@github.com>

On Thu, 15 May 2025 18:27:35 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes based on review feedback.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 230:

> 228:         // It requires 'entryLookup' and 'readOnly' to have safe defaults (which
> 229:         // is why they are the only non-final fields), and it requires that the
> 230:         // inode map has been initialized.

It's good to note that `determineReleaseVersion(...)` (and `createVersionedLinks(...)`) access instance fields of the `ZipFileSystem` being constructed. I think the comment however could be brief and should leave out the details about safe defaults.

Perhaps something like:

> determineReleaseVersion() and createVersionedLinks() access instance fields while 'this' ZipFileSystem instance is being constructed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093167748

From forax at univ-mlv.fr  Fri May 16 14:35:09 2025
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 16 May 2025 16:35:09 +0200 (CEST)
Subject: Towards a JSON API for the JDK
In-Reply-To: <f3cc90ef-25f3-41e3-a82b-0bac063c5733@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <f3cc90ef-25f3-41e3-a82b-0bac063c5733@oracle.com>
Message-ID: <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "Paul Sandoz" <paul.sandoz at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Friday, May 16, 2025 2:53:18 PM
> Subject: Re: Towards a JSON API for the JDK

> On 5/15/2025 5:27 PM, Remi Forax wrote:
>> It's not clear to me why JsonArray (for example) has to be an interface instead
>> of a record ?
> 
> Oh, you know the answer to this.? A record limits us to a single
> implementation with a rigid representation.? Behind an interface, we can
> hide lazy parsing and inflation, wrapping other representations to
> reduce copies, etc.

First, let me refine the question.
There are only 4 kinds of JSON values that benefit from having different representations, object, array, string and number.
For object and array, both takes an interface as parameter (Map or List) so JsonArray and JSonObject do not need to be themselves interfaces.

So the only values where it may be worth to be modeled using an interface are JsonString and JsonNumber, because as you said, you can do "lazy" parsing.

But delaying the parsing of the content has the side effect that even if Json.parse() did not throw an exception, it does not mean that the JSON text is valid, an exception may be thrown later.

Now, for me, this library is more about being simple and safe than fast.
If you agree with that, delaying the parsing is not a good idea, thus JSON values should be modeled using records and not interfaces.

regards,
R?mi








From jpai at openjdk.org  Fri May 16 14:39:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 14:39:54 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
Message-ID: <rRYz0yPs9wwv_PRvxm3CnB5Ky_zD2ZfKgLKg72tDcC0=.7b8377a8-685a-4c5b-a77c-846d3c71b0d1@github.com>

On Thu, 15 May 2025 18:27:35 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes based on review feedback.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 241:

> 239:         this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath);
> 240:         if (readOnly && accessMode == AccessMode.READ_WRITE) {
> 241:             String reason = Files.isWritable(zfpath)

Nit - this additional call to Files.isWritable(...) can be avoided if we store the value of the previous call (a couple of lines above). I realize that the previous `Files.isWritable` is stashed at the end of the `||` conditionals to prevent it from being invoked in certain situations.

So maybe a better change would be something like:


String reason = multiReleaseVersion.isPresent()
   ? "A multi-release JAR file opened with a specified version is not writable"
   : "The underlying ZIP file is not writable";


which would then avoid any additional calls to `Files.isWritable`.

But I think this point may not be relevant for the reason I note below as a separate comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093180117

From jpai at openjdk.org  Fri May 16 14:46:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 14:46:53 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
Message-ID: <mSHpenSvqLpwnq9i_DIwwb1dk_Y2rXUAYDfPoiMZ0pw=.4af97224-05d0-4f57-92f9-9c1e84f350a1@github.com>

On Thu, 15 May 2025 18:27:35 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes based on review feedback.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 245:

> 243:                     : "The underlying ZIP file is not writable";
> 244:             throw new IOException(
> 245:                     "A writable ZIP file system could not be opened for: " + zfpath + "\n" + reason);

The JDK coding guidelines recommend excluding file paths from exception messages. So in this case the `zfpath` should be left out from the exception message. Additionally, I haven't seen us using newline characters in exception messages that we construct in the JDK code. So I think we should leave that out too. 

Given this, I think it might be simpler to just change this `if` block to something like:



if (...) {
    String reason = multiReleaseVersion.isPresent()
        ? "the multi-release JAR file is not writable"
        : "the ZIP file is not writable";

    throw new IOException(reason);
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093192898

From lancea at openjdk.org  Fri May 16 15:44:55 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 May 2025 15:44:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <Oy0qyz1t7uiPneV1X2Na2hoQEknB3zxsIGFVoKvlm1o=.4919bdb1-b994-4afe-8fa4-200118e117bd@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <Oy0qyz1t7uiPneV1X2Na2hoQEknB3zxsIGFVoKvlm1o=.4919bdb1-b994-4afe-8fa4-200118e117bd@github.com>
Message-ID: <ThoC8WQ91e8pQYP5dgeTipJhNUR2ScoPqp10NFoK_2U=.696fe9d5-a1a1-45fa-b263-994d7e5a7226@github.com>

On Mon, 12 May 2025 09:49:12 GMT, David Beaumont <duke at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes based on review feedback.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 221:
> 
>> 219:         }
>> 220:         // sm and existence check
>> 221:         zfpath.getFileSystem().provider().checkAccess(zfpath, java.nio.file.AccessMode.READ);
> 
> Type name clash with existing AccessMode class. Since new enum is private, happy to rename.

So perhaps change the name of the newly added enum

> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 259:
> 
>> 257: 
>> 258:         // Pass "this" as a parameter after everything else is set up.
>> 259:         this.rootdir = new ZipPath(this, new byte[]{'/'});
> 
> This could probably be set above release version etc. but it's a choice of either:
> 1. waiting until everything is set up before passing "this"
> 2. letting an incomplete "this" instance get passed to another class (possible escape risk?)
> 
> Though in this case the "incompleteness" is limited to it not being set up for multi-jar reading yet, which absolutely shouldn't affect the root path. It feels safer to me to leave it to the end, or perhaps we should dig in to ZipPath, figure out what it really wants here, and just call a different constructor?

I think it was fine where it was originally given how rootdir is used

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093248468
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093276490

From lancea at openjdk.org  Fri May 16 15:44:56 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 May 2025 15:44:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <j5vOlgg8d8NGtb-dbaiHUrwth3sCi-Z8tpGsqq1PnGY=.6e3719fd-a7a9-49ea-802c-7fccc764615f@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
 <j5vOlgg8d8NGtb-dbaiHUrwth3sCi-Z8tpGsqq1PnGY=.6e3719fd-a7a9-49ea-802c-7fccc764615f@github.com>
Message-ID: <vDLKjPD5jCjmX48TWotMkgG33gtJslCXYZruYYYK9Ek=.90d99b76-fd7c-4692-9cf2-5d911e464831@github.com>

On Fri, 16 May 2025 14:30:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes based on review feedback.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 230:
> 
>> 228:         // It requires 'entryLookup' and 'readOnly' to have safe defaults (which
>> 229:         // is why they are the only non-final fields), and it requires that the
>> 230:         // inode map has been initialized.
> 
> It's good to note that `determineReleaseVersion(...)` (and `createVersionedLinks(...)`) access instance fields of the `ZipFileSystem` being constructed. I think the comment however could be brief and should leave out the details about safe defaults.
> 
> Perhaps something like:
> 
>> determineReleaseVersion() and createVersionedLinks() access instance fields while 'this' ZipFileSystem instance is being constructed.

Not sure I see a need for the last sentence regarding the inode map having to be initialized in addition to Jai's comments above

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093251313

From lancea at openjdk.org  Fri May 16 15:44:57 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 May 2025 15:44:57 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <TIyKoUhUEzKutdfkt1jIoGZPNfB7WMlkGeYEsqT8n40=.9fca5d23-4be4-45f9-8848-6ca45e9e4208@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
 <TIyKoUhUEzKutdfkt1jIoGZPNfB7WMlkGeYEsqT8n40=.9fca5d23-4be4-45f9-8848-6ca45e9e4208@github.com>
Message-ID: <Hshk19tLkpqUY-Lc0apS8ul2aOVtYQ3CmRkCTeoAuLc=.98aec5fc-c8b0-459b-bb63-8439f8652717@github.com>

On Fri, 16 May 2025 05:34:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes based on review feedback.
>
> src/jdk.zipfs/share/classes/module-info.java line 299:
> 
>> 297:  *           <li>
>> 298:  *               Any other values will cause an {@code IllegalArgumentException}
>> 299:  *               to be thrown.
> 
> The wording looks great. Just one thing with the "causes an IAE to be thrown" where I think it can be expanded to say that it causes IAE to be thrown when attempting to create the ZIP file system. The existing compressMethod property has word for this too.

The IAE message would be best to standardize around the wording that the compressMethod property uses (same for releaseVersion while we are at it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093281557

From duke at openjdk.org  Fri May 16 16:02:56 2025
From: duke at openjdk.org (Markus KARG)
Date: Fri, 16 May 2025 16:02:56 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v19]
In-Reply-To: <6R_dYDxxb9DRXAYBzENkNbRAn4rzQvNJmhd5KQPRj_g=.306a738b-b82b-4da4-a762-b7bd0cbe2f47@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <41bsHXJPPNYpg8t9guo5GYqdngKCpCGJV6cWbHDhA8E=.42eff3e8-3130-4904-99c8-c0228c046ea5@github.com>
 <8uTL_si__LdXJxkTn5nVWpdJR1AdPrT3H7U4orBS0Go=.7503416d-874f-4f8b-9a08-c95af58c782a@github.com>
 <s4RKXSP5YjlmX4vZ9Jg00cd-iqSM2AfMzM6TJyj5944=.7fbecab4-4d43-4528-a53a-27ac6c8400ef@github.com>
 <nCFdoAHy2RkNENhaRhdaMDbO3iiAuV-AsirMDJoS0Dc=.0177c4cd-1e71-494f-8956-13edc7eb0551@github.com>
 <BctFVukNg2CVXVsPVF96howIOf-A8N_G-AIClpaqmgE=.53d54891-c098-4922-81c7-ddd0818c647d@github.com>
 <apAsxR7rrX0ofU-2q3GVqq_uWkKTD8u4sw7zKeYCT2k=.c4f73ab2-cc66-4f98-b668-de356b788849@github.com>
 <f9my7Gq_OjkXWTBa2L2h1EFIgMpA5PuFf5xndOfcwlM=.e87667ba-d5eb-48aa-be35-05d52ac81212@github.com>
 <Y2P9dJdshrswViDiOGTS14EdODFTMxF7Z1fyDuiQdsA=.d182371a-d1ad-482f-8ff1-d01d06737a32@github.com>
 <g1GHppLlTaHjuFACIi8dgMvNZfQA81ctofGglGZXAXk=.73477b96-4dd8-45ca-9bae-f3a15d8ce8c1@github.com>
 <cnVCW6f3cE8qRMTn_8PMfPX8NPB8WhEcTJb
 jp_Zz3MY=.a4fe61f7-1a2a-4528-91a9-fde9cae8acfa@github.com>
 <jOzAzf7qiUGaR4AcVxkVruHyXr7-SLNU2pRV_z8iojk=.0c07b2ec-c8e7-4170-84e8-d1baed0afde0@github.com>
 <F6Kjz5iF9Y5R0V8LuRCuX_JtmI6Ohtzksy96kGzDUY8=.a461b9e5-02dd-4226-aced-cf4f910b01b0@github.com>
 <PIGolcNUOTm_uea2SMpu6zMF_8imtmuC_RiCTCTPIvU=.0845a60f-3eab-43cd-8956-9d10fbd5c439@github.com>
 <5ue1HrdcMPaWc9wOSsLvvQaf6n8bWRrBP9CN7jeueF4=.7ff273a1-2a42-4fea-9e44-ba18d895aef7@github.com>
 <Z0MNw-9D1C8zjcbDe12HXswjvK6a9snK72C3GsTlEKc=.621ac45f-e0c1-4cc7-9bf7-e9f574f9e726@github.com>
 <aJ9fvCIO__WTmGt8g47BHC5UYpVQhvTVLVuP1RGOjR4=.f4fd111a-bfc3-4295-9f9f-41c9bdf56613@github.com>
 <hGdOD6yiBZLJlqN471s_uxxFaCMnNI_U8mjqEgs3SW8=.ae5e1e63-6618-46f3-a659-020d3b10be3a@github.com>
 <6R_dYDxxb9DRXAYBzENkNbRAn4rzQvNJmhd5KQPRj_g=.306a738b-b82b-4da4-a762-b7bd0cbe2f47@github.com>
Message-ID: <K11o5EmC_unIgPZxIVHg3EXnAUNlkpu7FNH9FSo-sdM=.16b3f07a-05c7-4e94-89b9-893a98ab3ff4@github.com>

On Thu, 15 May 2025 22:07:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> It is **impossible** to "invest some lines" to solve this in JAX-RS, and JAX-RS as a standard technology on tens of thousands of servers. Enforcing `String` prevents these useful optimizations, but brings *no actual benefit*, as *only few* callers actually care for *constant* objects, but would be satisfied with `CharSequence`'s lack of mutation methods.
>
>> Also, in JAX-RS for example, you cannot make use of `transferTo` as what you get is a heap object, and what you must forward also is a heap object.
> 
> What relation does such a "heap object" have to character streams?

With "heap object" I meant something that is kept on the Java heap, like a `CharSequence` or `String`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2093313964

From swen at openjdk.org  Fri May 16 16:04:32 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 16 May 2025 16:04:32 GMT
Subject: RFR: 8357063: Document preconditions for DecimalDigits methods
 [v3]
In-Reply-To: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
References: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
Message-ID: <1sSVnfBoVGJLOlNuWRG0xGA0MQtRvG6y4b2u7A3XYps=.10d86316-f649-406b-974a-e65a04534ea5@github.com>

> Similar to PR #24982 
> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks.

Shaojin Wen has updated the pull request incrementally with seven additional commits since the last revision:

 - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25246/files
  - new: https://git.openjdk.org/jdk/pull/25246/files/ddb44aa8..bcb9af27

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25246&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25246&range=01-02

  Stats: 13 lines in 1 file changed: 0 ins; 8 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25246/head:pull/25246

PR: https://git.openjdk.org/jdk/pull/25246

From swen at openjdk.org  Fri May 16 16:10:29 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 16 May 2025 16:10:29 GMT
Subject: RFR: 8357063: Document preconditions for DecimalDigits methods
 [v4]
In-Reply-To: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
References: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
Message-ID: <pFjJy7Omzm3w-dzls5Ja0EkyCVbs0fd9MNJS_-excic=.6ffd8c75-350f-4ccc-b067-dd7ee3a38e43@github.com>

> Similar to PR #24982 
> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  warning

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25246/files
  - new: https://git.openjdk.org/jdk/pull/25246/files/bcb9af27..da865e42

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25246&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25246&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25246/head:pull/25246

PR: https://git.openjdk.org/jdk/pull/25246

From bpb at openjdk.org  Fri May 16 16:13:34 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 16 May 2025 16:13:34 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v5]
In-Reply-To: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
Message-ID: <FJ4EdTBJgwisKfyPXq57WUxg7Feh8t_CvVzsyJRP1kg=.f728b74e-002e-4ed8-b090-a2392bc3c6bd@github.com>

> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8355954: Split deleteReadOnlyRegularFile into Unix and Windows versions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24977/files
  - new: https://git.openjdk.org/jdk/pull/24977/files/352c54dd..fa2273ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=03-04

  Stats: 32 lines in 1 file changed: 14 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/24977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24977/head:pull/24977

PR: https://git.openjdk.org/jdk/pull/24977

From joe.darcy at oracle.com  Fri May 16 16:20:23 2025
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Fri, 16 May 2025 09:20:23 -0700
Subject: ProcessImpl: Can we obsolete the vfork mode?
In-Reply-To: <CAA-vtUwsqPZWSoR8a2376GnCYjE_PQeGu1bDjex0b5zzcuurrg@mail.gmail.com>
References: <CAA-vtUz19h6x4noK3zKgzjp8_Tm49bbKRsBQKz96w8N+aTs-vw@mail.gmail.com>
 <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com>
 <CAA-vtUz0PWXCs7aJO8V8ncRgUe2wKm7PBqCtt3=qj3nxy8AyKg@mail.gmail.com>
 <8c291ee4-f1c0-487e-9dca-e43567cd6466@oracle.com>
 <CAA-vtUwsqPZWSoR8a2376GnCYjE_PQeGu1bDjex0b5zzcuurrg@mail.gmail.com>
Message-ID: <d871711d-a1cc-4058-9a83-3b2617296eef@oracle.com>

I concur that this work is better down early in JDK 26.

Thanks,

-Joe

On 5/16/2025 12:26 AM, Thomas St?fe wrote:
> Okay, moved the release version to 26.
>
> Could one of you (you or @Roger Riggs <mailto:roger.riggs at oracle.com> 
> ) review the CSR if you have the cycles to spare?
>
> https://bugs.openjdk.org/browse/JDK-8357090
>
> Thanks!
>
> On Fri, May 16, 2025 at 7:56?AM Alan Bateman <alan.bateman at oracle.com> 
> wrote:
>
>     On 16/05/2025 05:10, Thomas St?fe wrote:
>>
>>
>>
>>     Thank you, Alan. I will prepare a patch and a CSR.
>>
>     Okay, and maybe something for early in JDK 26 to avoid touching
>     this area close to the fork for JDK 25 RDP1.
>
>     -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250516/0e26b344/attachment-0001.htm>

From bpb at openjdk.org  Fri May 16 16:26:50 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 16 May 2025 16:26:50 GMT
Subject: RFR: 8357052: java/io/File/GetXSpace.java prints wrong values in
 exception
In-Reply-To: <uKC3cFU14_1fPbsr9tamorif3MftHeN-Sfbz2483uik=.b18e053d-9be9-4b94-8a5f-cbed7f2e032a@github.com>
References: <uKC3cFU14_1fPbsr9tamorif3MftHeN-Sfbz2483uik=.b18e053d-9be9-4b94-8a5f-cbed7f2e032a@github.com>
Message-ID: <ung43tSIoor3ie4eLQEvGFVHdp9eDy7FhV3T3nJ8EZM=.aee4de52-7168-4ed9-b0d3-d8ed34381877@github.com>

On Thu, 15 May 2025 13:49:14 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> When the test java/io/File/GetXSpace.java fails, because the usable space is greater than the free space, the values in the exception are not the correct ones.

Looks correct.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25250#pullrequestreview-2847102959

From naoto.sato at oracle.com  Fri May 16 16:35:50 2025
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 16 May 2025 09:35:50 -0700
Subject: Towards a JSON API for the JDK
In-Reply-To: <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <f041b91c-07b9-4a68-8fc1-f96cec165ae1@oracle.com>

Hi R?mi,

On 5/15/25 2:27 PM, Remi Forax wrote:
> Hi Paul,
> yes, not having a simple JSON API in Java is an issue for beginners.
> 
> It's not clear to me why JsonArray (for example) has to be an interface instead of a record ?
> 
> I understand why Json.parse() only works on String and char[] but the API make it too easy to have many performance issues.
> I think you need versions using a Reader and a Path.
> Bonus point, if there is a method walk() that also returns a JsonValue but the List/Map inside JsonArray/JsonObject are populated lazily.
> 
> Minor point: Json.toDisplayString() should takes a second parameters indicating the number of spaces used for the indentation (like JSON.stringify in JS).

That would be better. Will implement it soon.

Naoto

> 
> regards,
> R?mi
> 
> ----- Original Message -----
>> From: "Paul Sandoz" <paul.sandoz at oracle.com>
>> To: "core-libs-dev" <core-libs-dev at openjdk.org>
>> Sent: Thursday, May 15, 2025 10:30:42 PM
>> Subject: Towards a JSON API for the JDK
> 
>> Hi,
>>
>> We would like to share with you our thoughts and plans towards a JSON API for
>> the JDK.
>> Please see the document below.
>>
>> -
>>
>> We have had the pleasure of using a clone of this API in some experiments we are
>> conducting with
>> ONNX and code reflection [1]. Using the API we were able to quickly write code
>> to ingest and convert
>> a JSON document representing ONNX operation schema into instances of records
>> modeling the schema
>> (see here [2]).
>>
>> The overall out-of-box experience with such a minimal "batteries included? API
>> has so far been positive.
>>
>> Thanks,
>> Paul.
>>
>> [1] https://openjdk.org/projects/babylon/
>> [2]
>> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87
>>
>> # Towards a JSON API for the JDK
>>
>> One of the most common requests for the JDK is an API for parsing and generating
>> JSON. While JSON originated as a text-based serialization format for JSON
>> objects ("JSON" stands for "JavaScript Object Notation"), because of its simple
>> and flexible syntax, it eventually found use outside the JavaScript ecosystem as
>> a general data interchange format, such as framework configuration files and web
>> service requests/response formats.
>>
>> While the JDK cannot, and should not, provide libraries for every conceivable
>> file format or protocol, the JDK philosophy is one of "batteries included",
>> which is to say we should be able to write basic programs that use common
>> protocols such as HTTP, without having to appeal to third party libraries.
>> The Java ecosystem already has plenty of JSON libraries, so inclusion in
>> the JDK is largely meant to be a convenience, rather than needing to be the "one
>> true" JSON library to meet the needs of all users. Users with specific needs
>> are always free to select one of the existing third-party libraries.
>>
>> ## Goals and requirements
>>
>> Our primary goal is that the library be simple to use for parsing, traversing,
>> and generating conformant JSON documents. Advanced features, such as data
>> binding or path-based traversal should be possible to implement as layered
>> features, but for simplicity are not included in the core API. We adopt a goal
>> that the performance should be "good enough", but where performance
>> considerations conflict with simplicity and usability, we will choose in favor
>> of the latter.
>>
>> ## API design approach
>>
>> The description of JSON at `https:://json.org` describes a JSON document using
>> the familiar "railroad diagram":
>> ![image](https://www.json.org/img/value.png)
>>
>> This diagram describes an algebraic data type (a sum of products), which we
>> model directly with a set of Java interfaces:
>>
>> ```
>> interface JsonValue { }
>> interface JsonArray extends JsonValue { List<JsonValue> values(); }
>> interface JsonObject extends JsonValue { Map<String, JsonValue> members(); }
>> interface JsonNumber extends JsonValue { Number toNumber(); }
>> interface JsonString extends JsonValue { String value(); }
>> interface JsonBoolean extends JsonValue  { boolean value(); }
>> interface JsonNull extends JsonValue { }
>> ```
>>
>> These interfaces have (hidden) companion implementation classes that admit
>> greater flexibility of implementation than modeling them directly with records
>> would permit.
>> Further, these interfaces are unsealed. We compromise on the sealed sum of
>> products to enable
>> alternative implementations, for example to support alternative formats that
>> encode the same information in a JSON document but in a more efficient form than
>> text.
>>
>> The API has static methods for parsing strings into a `JsonValue`, conversion to
>> and from purely untyped representations (lists and maps), and factory methods
>> for building JSON documents. We apply composition consistently, e.g, a
>> JsonString has a string, a JsonObject has a map of string to JsonValue, as
>> opposed to extension for structural JSON values.
>>
>> It turns out that this simple API is almost all we need for traversal. It gives
>> us an immutable representation of a document, and we can use pattern matching to
>> answer the myriad questions that will come up (Does this object have key X? Does
>> it map to a number? Is that number representable as an integer?) when going
>> from an untyped format like JSON to a more strongly typed domain model.
>> Given a simple document like:
>>
>> ```
>>     {
>>         "name": "John?,
>>         "age": 30
>>     }
>> ```
>>
>> we can parse and traverse the document as follows:
>>
>> ```
>> JsonValue doc = Json.parse(inputString);
>> if (doc instanceof JsonObject o
>>     && o.members().get("name") instanceof JsonString s
>>     && s.value() instanceof String name
>>     && o.members().get("age") instanceof JsonNumber n
>>     && n.toNumber() instanceof Long l && l instanceof int age) {
>>             // use "name" and "age"
>>         }
>> ```
>>
>> Later, when the language acquires the ability to expose deconstruction patterns
>> for arbitrary interfaces (similar to today's record patterns, see
>> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns),
>> this will be simplifiable to:
>>
>> ```
>> JsonValue doc = Json.parse(inputString);
>> if (doc instanceof JsonObject(var members)
>>     && members.get("name") instanceof JsonString(String name)
>>     && members.get("age") instanceof JsonNumber(int age)) {
>>             // use "name" and "age"
>>         }
>> ```
>>
>> So, overtime, as more pattern matching features are introduced we anticipate
>> improved use of the API. This is a primary reason why the API is so minimal.
>> Convenience methods we add today, such as a method that accesses a JSON
>> object component as say a JSON string or throws an exception, will become
>> redundant in the future.
>>
>> ## JSON numbers
>>
>> The specification of JSON number makes no explicit distinction between integral
>> and decimal numbers, nor specifies limits on the size of those numbers.
>> This is a common source of interoperability issues when consuming JSON
>> documents. Generally users cannot always but often do assume JSON numbers are
>> parsable, without loss of precision, to IEEE double-precision floating point
>> numbers or 32-bit signed integers.
>>
>> In this respect the API provides three means to operate on the JSON number,
>> giving the user full control:
>>
>> 1. Underlying string representation can be obtained, if preserving syntactic
>>    details such as leading or trailing zeros is important.
>> 2. The string representation can be parsed to an instance of `BigDecimal`, using
>>    `toBigDecimal` if preserving decimal numbers is important.
>> 3. The string representation can be parsed into an instance of `Long`, `Double`,
>>    `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this method
>>    depends on how the representation can be parsed, possibly losing precision,
>>    choosing a suitably convenient numeric type that can then be pattern
>>    matched on.
>>
>> Primitive pattern matching will help as will further pattern matching features
>> enabling the user to partially match.
>>
>> ## Prototype implementation
>>
>> The prototype implementation is currently located into the JDK sandbox
>> repository
>> under the `json` branch, see
>> here
>> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json
>> The prototype API javadoc generated from the repository is also available at
>> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html
>>
>> ### Testing and conformance
>>
>> The prototype implementation passes all conformance test cases but two,
>> available
>> on https://github.com/nst/JSONTestSuite. The two exceptions are the ones which
>> the
>> prototype specifically prohibits, i.e, duplicated names in JSON objects
>> (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35).
>>
>> ### Performance
>>
>> Our main focus so far has been on the API design and a functional
>> implementation.
>> Hence, there has been less focus on performance even though we know there are a
>> number of performance enhancements we can make eventually.
>> We are reasonably happy with the current performance. The
>> implementation performs well when compared to other JSON implementations
>> parsing from string instances and traversing documents.
>>
>> An example of where we may choose simplicity and usability over performance
>> is the rejection of JSON documents containing objects that in turn contain
>> members
>> with duplicate names. That may increase the cost of parsing, but simplifies the
>> user
>> experience for the majority of cases since if we reasonably assume JsonObjects
>> are
>> map-like, what should the user do with such members, pick one the last one?
>> merge
>> the values? or reject?
>>
>> ## A JSON JEP?
>>
>> We plan to draft JEP when we are ready. Attentive readers will observe that
>> a JEP already exists, JEP 198: Light-Weight JSON API
>> (https://openjdk.org/jeps/198). We will
>> either update this JEP, or withdraw it and draft a new one.


From joehw at openjdk.org  Fri May 16 16:42:53 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 16 May 2025 16:42:53 GMT
Subject: RFR: 8357075: Remove leftover COMPAT locale data tests [v2]
In-Reply-To: <ybUfk4KD0jMOEn3ki-VKlALRXABRpZfCFR6mCUp1EqQ=.4a2e12dc-ab43-4fde-b9a8-9682e3fb4f66@github.com>
References: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
 <ybUfk4KD0jMOEn3ki-VKlALRXABRpZfCFR6mCUp1EqQ=.4a2e12dc-ab43-4fde-b9a8-9682e3fb4f66@github.com>
Message-ID: <3tVtRDVNeYwN4Hf6OB-3gYM44GrqPAxWfWfptNQolnM=.dcf79f5b-a7c9-43bd-8af4-c542caed0a33@github.com>

On Thu, 15 May 2025 20:53:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing now-defunct COMPAT locale provider tests.
>
> Naoto Sato has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25257#pullrequestreview-2847142525

From liach at openjdk.org  Fri May 16 16:44:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 16 May 2025 16:44:53 GMT
Subject: RFR: 8357063: Document preconditions for DecimalDigits methods
 [v4]
In-Reply-To: <pFjJy7Omzm3w-dzls5Ja0EkyCVbs0fd9MNJS_-excic=.6ffd8c75-350f-4ccc-b067-dd7ee3a38e43@github.com>
References: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
 <pFjJy7Omzm3w-dzls5Ja0EkyCVbs0fd9MNJS_-excic=.6ffd8c75-350f-4ccc-b067-dd7ee3a38e43@github.com>
Message-ID: <0xb967N0tNnJUqohfrI-zu-jmZsdxfoUIahEwTOBUgo=.0f88e5e6-c938-4086-a28a-5da6f7d8d148@github.com>

On Fri, 16 May 2025 16:10:29 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Similar to PR #24982 
>> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   warning

This version looks good to me. Please wait for a second confirmation. (Allowing authors like @vy to review too)

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25246#pullrequestreview-2847147545

From markus at headcrashing.eu  Fri May 16 16:52:36 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Fri, 16 May 2025 18:52:36 +0200
Subject: Towards a JSON API for the JDK
In-Reply-To: <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <3db12996-16dd-49fc-a874-1cf2122f1a0d@headcrashing.eu>

As the API intentionally uses interfaces to open the ability to optimize 
the implementation, it would be also just straightforward to not limit 
the text source to the explicit class String. When instead allowing the 
general interface CharSequence, *any* kind of text source can be parsed, 
for example, an off-heap located direct CharBuffer, without the need to 
explicitly copy its content into a temporary in-memory String 
representation, upfront to parsing. More flexible, more speed, less 
memory, less GC. :-)

Am 15.05.2025 um 23:27 schrieb Remi Forax:
> Hi Paul,
> yes, not having a simple JSON API in Java is an issue for beginners.
>
> It's not clear to me why JsonArray (for example) has to be an interface instead of a record ?
>
> I understand why Json.parse() only works on String and char[] but the API make it too easy to have many performance issues.
> I think you need versions using a Reader and a Path.
> Bonus point, if there is a method walk() that also returns a JsonValue but the List/Map inside JsonArray/JsonObject are populated lazily.
>
> Minor point: Json.toDisplayString() should takes a second parameters indicating the number of spaces used for the indentation (like JSON.stringify in JS).
>
> regards,
> R?mi
>
> ----- Original Message -----
>> From: "Paul Sandoz" <paul.sandoz at oracle.com>
>> To: "core-libs-dev" <core-libs-dev at openjdk.org>
>> Sent: Thursday, May 15, 2025 10:30:42 PM
>> Subject: Towards a JSON API for the JDK
>> Hi,
>>
>> We would like to share with you our thoughts and plans towards a JSON API for
>> the JDK.
>> Please see the document below.
>>
>> -
>>
>> We have had the pleasure of using a clone of this API in some experiments we are
>> conducting with
>> ONNX and code reflection [1]. Using the API we were able to quickly write code
>> to ingest and convert
>> a JSON document representing ONNX operation schema into instances of records
>> modeling the schema
>> (see here [2]).
>>
>> The overall out-of-box experience with such a minimal "batteries included? API
>> has so far been positive.
>>
>> Thanks,
>> Paul.
>>
>> [1] https://openjdk.org/projects/babylon/
>> [2]
>> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87
>>
>> # Towards a JSON API for the JDK
>>
>> One of the most common requests for the JDK is an API for parsing and generating
>> JSON. While JSON originated as a text-based serialization format for JSON
>> objects ("JSON" stands for "JavaScript Object Notation"), because of its simple
>> and flexible syntax, it eventually found use outside the JavaScript ecosystem as
>> a general data interchange format, such as framework configuration files and web
>> service requests/response formats.
>>
>> While the JDK cannot, and should not, provide libraries for every conceivable
>> file format or protocol, the JDK philosophy is one of "batteries included",
>> which is to say we should be able to write basic programs that use common
>> protocols such as HTTP, without having to appeal to third party libraries.
>> The Java ecosystem already has plenty of JSON libraries, so inclusion in
>> the JDK is largely meant to be a convenience, rather than needing to be the "one
>> true" JSON library to meet the needs of all users. Users with specific needs
>> are always free to select one of the existing third-party libraries.
>>
>> ## Goals and requirements
>>
>> Our primary goal is that the library be simple to use for parsing, traversing,
>> and generating conformant JSON documents. Advanced features, such as data
>> binding or path-based traversal should be possible to implement as layered
>> features, but for simplicity are not included in the core API. We adopt a goal
>> that the performance should be "good enough", but where performance
>> considerations conflict with simplicity and usability, we will choose in favor
>> of the latter.
>>
>> ## API design approach
>>
>> The description of JSON at `https:://json.org` describes a JSON document using
>> the familiar "railroad diagram":
>> ![image](https://www.json.org/img/value.png)
>>
>> This diagram describes an algebraic data type (a sum of products), which we
>> model directly with a set of Java interfaces:
>>
>> ```
>> interface JsonValue { }
>> interface JsonArray extends JsonValue { List<JsonValue> values(); }
>> interface JsonObject extends JsonValue { Map<String, JsonValue> members(); }
>> interface JsonNumber extends JsonValue { Number toNumber(); }
>> interface JsonString extends JsonValue { String value(); }
>> interface JsonBoolean extends JsonValue  { boolean value(); }
>> interface JsonNull extends JsonValue { }
>> ```
>>
>> These interfaces have (hidden) companion implementation classes that admit
>> greater flexibility of implementation than modeling them directly with records
>> would permit.
>> Further, these interfaces are unsealed. We compromise on the sealed sum of
>> products to enable
>> alternative implementations, for example to support alternative formats that
>> encode the same information in a JSON document but in a more efficient form than
>> text.
>>
>> The API has static methods for parsing strings into a `JsonValue`, conversion to
>> and from purely untyped representations (lists and maps), and factory methods
>> for building JSON documents. We apply composition consistently, e.g, a
>> JsonString has a string, a JsonObject has a map of string to JsonValue, as
>> opposed to extension for structural JSON values.
>>
>> It turns out that this simple API is almost all we need for traversal. It gives
>> us an immutable representation of a document, and we can use pattern matching to
>> answer the myriad questions that will come up (Does this object have key X? Does
>> it map to a number? Is that number representable as an integer?) when going
>> from an untyped format like JSON to a more strongly typed domain model.
>> Given a simple document like:
>>
>> ```
>>     {
>>         "name": "John?,
>>         "age": 30
>>     }
>> ```
>>
>> we can parse and traverse the document as follows:
>>
>> ```
>> JsonValue doc = Json.parse(inputString);
>> if (doc instanceof JsonObject o
>>     && o.members().get("name") instanceof JsonString s
>>     && s.value() instanceof String name
>>     && o.members().get("age") instanceof JsonNumber n
>>     && n.toNumber() instanceof Long l && l instanceof int age) {
>>             // use "name" and "age"
>>         }
>> ```
>>
>> Later, when the language acquires the ability to expose deconstruction patterns
>> for arbitrary interfaces (similar to today's record patterns, see
>> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns),
>> this will be simplifiable to:
>>
>> ```
>> JsonValue doc = Json.parse(inputString);
>> if (doc instanceof JsonObject(var members)
>>     && members.get("name") instanceof JsonString(String name)
>>     && members.get("age") instanceof JsonNumber(int age)) {
>>             // use "name" and "age"
>>         }
>> ```
>>
>> So, overtime, as more pattern matching features are introduced we anticipate
>> improved use of the API. This is a primary reason why the API is so minimal.
>> Convenience methods we add today, such as a method that accesses a JSON
>> object component as say a JSON string or throws an exception, will become
>> redundant in the future.
>>
>> ## JSON numbers
>>
>> The specification of JSON number makes no explicit distinction between integral
>> and decimal numbers, nor specifies limits on the size of those numbers.
>> This is a common source of interoperability issues when consuming JSON
>> documents. Generally users cannot always but often do assume JSON numbers are
>> parsable, without loss of precision, to IEEE double-precision floating point
>> numbers or 32-bit signed integers.
>>
>> In this respect the API provides three means to operate on the JSON number,
>> giving the user full control:
>>
>> 1. Underlying string representation can be obtained, if preserving syntactic
>>    details such as leading or trailing zeros is important.
>> 2. The string representation can be parsed to an instance of `BigDecimal`, using
>>    `toBigDecimal` if preserving decimal numbers is important.
>> 3. The string representation can be parsed into an instance of `Long`, `Double`,
>>    `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this method
>>    depends on how the representation can be parsed, possibly losing precision,
>>    choosing a suitably convenient numeric type that can then be pattern
>>    matched on.
>>
>> Primitive pattern matching will help as will further pattern matching features
>> enabling the user to partially match.
>>
>> ## Prototype implementation
>>
>> The prototype implementation is currently located into the JDK sandbox
>> repository
>> under the `json` branch, see
>> here
>> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json
>> The prototype API javadoc generated from the repository is also available at
>> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html
>>
>> ### Testing and conformance
>>
>> The prototype implementation passes all conformance test cases but two,
>> available
>> on https://github.com/nst/JSONTestSuite. The two exceptions are the ones which
>> the
>> prototype specifically prohibits, i.e, duplicated names in JSON objects
>> (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35).
>>
>> ### Performance
>>
>> Our main focus so far has been on the API design and a functional
>> implementation.
>> Hence, there has been less focus on performance even though we know there are a
>> number of performance enhancements we can make eventually.
>> We are reasonably happy with the current performance. The
>> implementation performs well when compared to other JSON implementations
>> parsing from string instances and traversing documents.
>>
>> An example of where we may choose simplicity and usability over performance
>> is the rejection of JSON documents containing objects that in turn contain
>> members
>> with duplicate names. That may increase the cost of parsing, but simplifies the
>> user
>> experience for the majority of cases since if we reasonably assume JsonObjects
>> are
>> map-like, what should the user do with such members, pick one the last one?
>> merge
>> the values? or reject?
>>
>> ## A JSON JEP?
>>
>> We plan to draft JEP when we are ready. Attentive readers will observe that
>> a JEP already exists, JEP 198: Light-Weight JSON API
>> (https://openjdk.org/jeps/198). We will
>> either update this JEP, or withdraw it and draft a new one.

From thomas.stuefe at gmail.com  Fri May 16 16:59:47 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 16 May 2025 18:59:47 +0200
Subject: ProcessImpl: Can we obsolete the vfork mode?
In-Reply-To: <d871711d-a1cc-4058-9a83-3b2617296eef@oracle.com>
References: <CAA-vtUz19h6x4noK3zKgzjp8_Tm49bbKRsBQKz96w8N+aTs-vw@mail.gmail.com>
 <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com>
 <CAA-vtUz0PWXCs7aJO8V8ncRgUe2wKm7PBqCtt3=qj3nxy8AyKg@mail.gmail.com>
 <8c291ee4-f1c0-487e-9dca-e43567cd6466@oracle.com>
 <CAA-vtUwsqPZWSoR8a2376GnCYjE_PQeGu1bDjex0b5zzcuurrg@mail.gmail.com>
 <d871711d-a1cc-4058-9a83-3b2617296eef@oracle.com>
Message-ID: <CAA-vtUxQT5pbQ+gzAeu9t5BRJ2KRWLmGGrHKFSLmxv8wZkjzOA@mail.gmail.com>

I am fine with waiting past 25, though the continued existence of this mode
makes me apprehensive. Back at SAP I have seen real customer issues from
these kind of problems, and we only catched those out of accident.

A separate deprecation for JDK 25 may be a good first step (a warning, but
continued acceptance, of the VFORK mode)

On Fri, May 16, 2025 at 6:20?PM Joseph D. Darcy <joe.darcy at oracle.com>
wrote:

> I concur that this work is better down early in JDK 26.
>
> Thanks,
>
> -Joe
>
> On 5/16/2025 12:26 AM, Thomas St?fe wrote:
>
> Okay, moved the release version to 26.
>
> Could one of you (you or @Roger Riggs <roger.riggs at oracle.com> ) review
> the CSR if you have the cycles to spare?
>
> https://bugs.openjdk.org/browse/JDK-8357090
>
> Thanks!
>
> On Fri, May 16, 2025 at 7:56?AM Alan Bateman <alan.bateman at oracle.com>
> wrote:
>
>> On 16/05/2025 05:10, Thomas St?fe wrote:
>>
>>
>>
>>>
>> Thank you, Alan. I will prepare a patch and a CSR.
>>
>> Okay, and maybe something for early in JDK 26 to avoid touching this area
>> close to the fork for JDK 25 RDP1.
>>
>> -Alan
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250516/2500b460/attachment.htm>

From bpb at openjdk.org  Fri May 16 17:25:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 16 May 2025 17:25:54 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v4]
In-Reply-To: <fFsRN-Y7HUvOXQsgT7uYAysTLWM5pIrUFqPIaj3R3OM=.34bb0412-a4c1-4a43-b7e3-c11c818bd20a@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <66pv5IvWk1pnQbXk3swAPR46Zfxt7L7VXPMIod0X3tk=.38446b76-4ef7-4702-929a-fabf3497080b@github.com>
 <rwXcUZ5-L8SUGT-ZQ-cU9JFRM9Wy6cBFPco-VMQuCP8=.10dadf56-a1f2-4159-a7b9-de5752700098@github.com>
 <fFsRN-Y7HUvOXQsgT7uYAysTLWM5pIrUFqPIaj3R3OM=.34bb0412-a4c1-4a43-b7e3-c11c818bd20a@github.com>
Message-ID: <QWT_v0Htu4AsLaRGJNbLfDpDiY6KyOn6AnVrYOIf45c=.2eb58ec4-f58f-4f74-a768-618b8cea7a64@github.com>

On Fri, 16 May 2025 06:28:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/io/File/DeleteReadOnly.java line 47:
>> 
>>> 45: 
>>> 46:     private static final File DIR = new File(".", "dir");
>>> 47:     private static final File FILE = new File(DIR, "file");
>> 
>> If one of the tests fails then it will impact the test(s) that execute later. It might be better to just isolate them. deleteReadOnlyDirectory creates a directory that is used solely for that test, and deleteReadOnlyRegularFile creates a file that is used solely for that test.
>
> Agreed. That actually happened when negative testing against code without the fix.

Made directory and file creation local to each test in [fa2273e](https://github.com/openjdk/jdk/pull/24977/commits/fa2273eded040a22c1e32ba8870571d3a7daf427).

>> test/jdk/java/io/File/DeleteReadOnly.java line 62:
>> 
>>> 60: 
>>> 61:         boolean deleted = FILE.delete();
>>> 62:         boolean shouldBeDeleted = !Platform.isWindows() || DELETE_READ_ONLY;
>> 
>> The behavior and system property is Windows specific and might make things simpler to make it a Windows only test.
>
> I guess collapsing the tests made them more ambiguous. Will fix.

Split the test method in half for Unix and Windows in [fa2273e](https://github.com/openjdk/jdk/pull/24977/commits/fa2273eded040a22c1e32ba8870571d3a7daf427).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2093430454
PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2093429650

From raffaello.giulietti at oracle.com  Fri May 16 17:26:04 2025
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Fri, 16 May 2025 19:26:04 +0200
Subject: Towards a JSON API for the JDK
In-Reply-To: <3db12996-16dd-49fc-a874-1cf2122f1a0d@headcrashing.eu>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <3db12996-16dd-49fc-a874-1cf2122f1a0d@headcrashing.eu>
Message-ID: <0e959a40-9471-477a-9635-19324d14a0fa@oracle.com>

Since the parser is specified to be lazy, the backing store needs to be 
immutable.


On 2025-05-16 18:52, Markus KARG wrote:
> When instead allowing the 
> general interface CharSequence, *any* kind of text source can be parsed, 
> for example, an off-heap located direct CharBuffer, without the need to 
> explicitly copy its content into a temporary in-memory String 
> representation, upfront to parsing. More flexible, more speed, less 
> memory, less GC. :-)
> 

From iris at openjdk.org  Fri May 16 17:28:51 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 16 May 2025 17:28:51 GMT
Subject: RFR: 8357075: Remove leftover COMPAT locale data tests [v2]
In-Reply-To: <ybUfk4KD0jMOEn3ki-VKlALRXABRpZfCFR6mCUp1EqQ=.4a2e12dc-ab43-4fde-b9a8-9682e3fb4f66@github.com>
References: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
 <ybUfk4KD0jMOEn3ki-VKlALRXABRpZfCFR6mCUp1EqQ=.4a2e12dc-ab43-4fde-b9a8-9682e3fb4f66@github.com>
Message-ID: <6MMtxe9V1vRVN-dAVHwMveNro15HG5zvy7cFyYI4yJM=.68ed2245-db5f-4ddf-b8eb-d26840e2def1@github.com>

On Thu, 15 May 2025 20:53:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing now-defunct COMPAT locale provider tests.
>
> Naoto Sato has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25257#pullrequestreview-2847242934

From bpb at openjdk.org  Fri May 16 17:42:09 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 16 May 2025 17:42:09 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v6]
In-Reply-To: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
Message-ID: <7yNAdBKQFZ1NMDokRoeb3Iw_0bWvV-chWnYGufjI9R8=.e6192d07-2a05-4d0a-bcac-6017dcf8de30@github.com>

> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8355954: Delete deleteReadOnlyFile method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24977/files
  - new: https://git.openjdk.org/jdk/pull/24977/files/fa2273ed..9fa45418

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=04-05

  Stats: 7 lines in 1 file changed: 1 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24977/head:pull/24977

PR: https://git.openjdk.org/jdk/pull/24977

From djgredler at gmail.com  Fri May 16 17:42:41 2025
From: djgredler at gmail.com (Daniel Gredler)
Date: Fri, 16 May 2025 19:42:41 +0200
Subject: Towards a JSON API for the JDK
In-Reply-To: <0e959a40-9471-477a-9635-19324d14a0fa@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <3db12996-16dd-49fc-a874-1cf2122f1a0d@headcrashing.eu>
 <0e959a40-9471-477a-9635-19324d14a0fa@oracle.com>
Message-ID: <CAPA+ug5Hi2iX-kqu3EPEOasp8jy4xS0prehV-6xp34CjFFcp9w@mail.gmail.com>

Thanks for the sneak peek.

I'd suggest adding a security section to the JEP, when the time comes. Most
input to this JSON parsing API will probably be untrusted, and this is an
area where "last mover advantage" can be helpful. As a user, the
progression I've seen in other JSON parsers was a first wave of
"serialization gadget" exploits providing RCE, followed by a wave of
denial-of-service vulnerabilities. As a user, I'd love to know that these
issues have all been considered up front:

- Serialization gadgets (no object mapping, so not an issue?)
- Sane limits (and maybe configurability) for:
  - Max object / array nesting depth
  - Max key (field name) length
  - Max value length (strings)
  - Max value length (numbers)
  - Max overall document size (maybe less of a problem if there are no
Json.parse() methods for streams or files?)

If you want to avoid the configurability aspect, it should be possible to
find defaults which are relatively safe and do not impact 99% of users
(e.g. who realistically uses JSON nested over 1k levels deep?).



On Fri, May 16, 2025 at 7:26?PM Raffaello Giulietti <
raffaello.giulietti at oracle.com> wrote:

> Since the parser is specified to be lazy, the backing store needs to be
> immutable.
>
>
> On 2025-05-16 18:52, Markus KARG wrote:
> > When instead allowing the
> > general interface CharSequence, *any* kind of text source can be parsed,
> > for example, an off-heap located direct CharBuffer, without the need to
> > explicitly copy its content into a temporary in-memory String
> > representation, upfront to parsing. More flexible, more speed, less
> > memory, less GC. :-)
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250516/ccb84f14/attachment.htm>

From brian.goetz at oracle.com  Fri May 16 17:46:09 2025
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 16 May 2025 13:46:09 -0400
Subject: Towards a JSON API for the JDK
In-Reply-To: <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <f3cc90ef-25f3-41e3-a82b-0bac063c5733@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>

If you read the implementation, you'll see that significant laziness is 
indeed possible for JsonObject and JsonArray, even while doing eager 
validation.? (Of course, one can shift the balance to achieve various 
other tradeoffs.)

On 5/16/2025 10:35 AM, forax at univ-mlv.fr wrote:
> ----- Original Message -----
>> From: "Brian Goetz"<brian.goetz at oracle.com>
>> To: "Remi Forax"<forax at univ-mlv.fr>, "Paul Sandoz"<paul.sandoz at oracle.com>
>> Cc: "core-libs-dev"<core-libs-dev at openjdk.org>
>> Sent: Friday, May 16, 2025 2:53:18 PM
>> Subject: Re: Towards a JSON API for the JDK
>> On 5/15/2025 5:27 PM, Remi Forax wrote:
>>> It's not clear to me why JsonArray (for example) has to be an interface instead
>>> of a record ?
>> Oh, you know the answer to this.? A record limits us to a single
>> implementation with a rigid representation.? Behind an interface, we can
>> hide lazy parsing and inflation, wrapping other representations to
>> reduce copies, etc.
> First, let me refine the question.
> There are only 4 kinds of JSON values that benefit from having different representations, object, array, string and number.
> For object and array, both takes an interface as parameter (Map or List) so JsonArray and JSonObject do not need to be themselves interfaces.
>
> So the only values where it may be worth to be modeled using an interface are JsonString and JsonNumber, because as you said, you can do "lazy" parsing.
>
> But delaying the parsing of the content has the side effect that even if Json.parse() did not throw an exception, it does not mean that the JSON text is valid, an exception may be thrown later.
>
> Now, for me, this library is more about being simple and safe than fast.
> If you agree with that, delaying the parsing is not a good idea, thus JSON values should be modeled using records and not interfaces.
>
> regards,
> R?mi
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250516/b6662a49/attachment-0001.htm>

From naoto at openjdk.org  Fri May 16 18:05:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 May 2025 18:05:56 GMT
Subject: RFR: 8357075: Remove leftover COMPAT locale data tests [v2]
In-Reply-To: <ybUfk4KD0jMOEn3ki-VKlALRXABRpZfCFR6mCUp1EqQ=.4a2e12dc-ab43-4fde-b9a8-9682e3fb4f66@github.com>
References: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
 <ybUfk4KD0jMOEn3ki-VKlALRXABRpZfCFR6mCUp1EqQ=.4a2e12dc-ab43-4fde-b9a8-9682e3fb4f66@github.com>
Message-ID: <XuVgr1XKrNJ0FfCafRqPIf_FX1IIFZQ8sNqCe9ApABc=.e8fa9635-9de9-48aa-8241-27be1c1deabb@github.com>

On Thu, 15 May 2025 20:53:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing now-defunct COMPAT locale provider tests.
>
> Naoto Sato has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25257#issuecomment-2887364827

From naoto at openjdk.org  Fri May 16 18:05:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 May 2025 18:05:56 GMT
Subject: Integrated: 8357075: Remove leftover COMPAT locale data tests
In-Reply-To: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
References: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
Message-ID: <uulY9ZHvv7E5QO78VbnGpmiD40X_s0LYPJkDXKnAwk0=.3466c929-1bdf-4018-ad4c-118089766424@github.com>

On Thu, 15 May 2025 19:31:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing now-defunct COMPAT locale provider tests.

This pull request has now been integrated.

Changeset: 3dd34517
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3dd34517000e4ce1a21619922c62c025f98aad44
Stats:     8496 lines in 2 files changed: 0 ins; 8484 del; 12 mod

8357075: Remove leftover COMPAT locale data tests

Reviewed-by: joehw, iris, jlu

-------------

PR: https://git.openjdk.org/jdk/pull/25257

From rriggs at openjdk.org  Fri May 16 18:16:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 16 May 2025 18:16:57 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
Message-ID: <ZYxg_QnA1c0w84zoJQJ0Ay7HubbwkoQXljK14oWAkU0=.0b3af2c9-73ac-4661-9ffa-40519e004a24@github.com>

On Wed, 14 May 2025 18:16:22 GMT, Brian Burkhalter <bpb at openjdk.org> 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: Replace getChars in previous commit with subSequence

src/java.base/share/classes/java/io/Reader.java line 478:

> 476:      *
> 477:      * <p> If an I/O error occurs reading from the stream, then it
> 478:      * may do so after some, but not all, characters have been read.

Is this better?
Suggestion:

     * <p> If an I/O error occurs reading from the stream, then some characters, but not all, may have been read.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2093493065

From bpb at openjdk.org  Fri May 16 18:23:59 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 16 May 2025 18:23:59 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <ZYxg_QnA1c0w84zoJQJ0Ay7HubbwkoQXljK14oWAkU0=.0b3af2c9-73ac-4661-9ffa-40519e004a24@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <ZYxg_QnA1c0w84zoJQJ0Ay7HubbwkoQXljK14oWAkU0=.0b3af2c9-73ac-4661-9ffa-40519e004a24@github.com>
Message-ID: <MbLTLYFhywojPyY0r9KZ9NuJ6hWVUQT3WNgcK2Nnsi8=.161b7e89-8657-4e3f-ba99-1d48684dda61@github.com>

On Fri, 16 May 2025 18:13:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Is this better?

I think it is clearer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2093501372

From forax at univ-mlv.fr  Fri May 16 18:37:52 2025
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 16 May 2025 20:37:52 +0200 (CEST)
Subject: Towards a JSON API for the JDK
In-Reply-To: <f041b91c-07b9-4a68-8fc1-f96cec165ae1@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <f041b91c-07b9-4a68-8fc1-f96cec165ae1@oracle.com>
Message-ID: <897655549.267921263.1747420672400.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "naoto sato" <naoto.sato at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "Paul Sandoz" <paul.sandoz at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Friday, May 16, 2025 6:35:50 PM
> Subject: Re: Towards a JSON API for the JDK

> Hi R?mi,
> 
> On 5/15/25 2:27 PM, Remi Forax wrote:
>> Hi Paul,
>> yes, not having a simple JSON API in Java is an issue for beginners.
>> 
>> It's not clear to me why JsonArray (for example) has to be an interface instead
>> of a record ?
>> 
>> I understand why Json.parse() only works on String and char[] but the API make
>> it too easy to have many performance issues.
>> I think you need versions using a Reader and a Path.
>> Bonus point, if there is a method walk() that also returns a JsonValue but the
>> List/Map inside JsonArray/JsonObject are populated lazily.
>> 
>> Minor point: Json.toDisplayString() should takes a second parameters indicating
>> the number of spaces used for the indentation (like JSON.stringify in JS).
> 
> That would be better. Will implement it soon.

Thank you !

> 
> Naoto

R?mi

> 
>> 
>> regards,
>> R?mi
>> 
>> ----- Original Message -----
>>> From: "Paul Sandoz" <paul.sandoz at oracle.com>
>>> To: "core-libs-dev" <core-libs-dev at openjdk.org>
>>> Sent: Thursday, May 15, 2025 10:30:42 PM
>>> Subject: Towards a JSON API for the JDK
>> 
>>> Hi,
>>>
>>> We would like to share with you our thoughts and plans towards a JSON API for
>>> the JDK.
>>> Please see the document below.
>>>
>>> -
>>>
>>> We have had the pleasure of using a clone of this API in some experiments we are
>>> conducting with
>>> ONNX and code reflection [1]. Using the API we were able to quickly write code
>>> to ingest and convert
>>> a JSON document representing ONNX operation schema into instances of records
>>> modeling the schema
>>> (see here [2]).
>>>
>>> The overall out-of-box experience with such a minimal "batteries included? API
>>> has so far been positive.
>>>
>>> Thanks,
>>> Paul.
>>>
>>> [1] https://openjdk.org/projects/babylon/
>>> [2]
>>> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87
>>>
>>> # Towards a JSON API for the JDK
>>>
>>> One of the most common requests for the JDK is an API for parsing and generating
>>> JSON. While JSON originated as a text-based serialization format for JSON
>>> objects ("JSON" stands for "JavaScript Object Notation"), because of its simple
>>> and flexible syntax, it eventually found use outside the JavaScript ecosystem as
>>> a general data interchange format, such as framework configuration files and web
>>> service requests/response formats.
>>>
>>> While the JDK cannot, and should not, provide libraries for every conceivable
>>> file format or protocol, the JDK philosophy is one of "batteries included",
>>> which is to say we should be able to write basic programs that use common
>>> protocols such as HTTP, without having to appeal to third party libraries.
>>> The Java ecosystem already has plenty of JSON libraries, so inclusion in
>>> the JDK is largely meant to be a convenience, rather than needing to be the "one
>>> true" JSON library to meet the needs of all users. Users with specific needs
>>> are always free to select one of the existing third-party libraries.
>>>
>>> ## Goals and requirements
>>>
>>> Our primary goal is that the library be simple to use for parsing, traversing,
>>> and generating conformant JSON documents. Advanced features, such as data
>>> binding or path-based traversal should be possible to implement as layered
>>> features, but for simplicity are not included in the core API. We adopt a goal
>>> that the performance should be "good enough", but where performance
>>> considerations conflict with simplicity and usability, we will choose in favor
>>> of the latter.
>>>
>>> ## API design approach
>>>
>>> The description of JSON at `https:://json.org` describes a JSON document using
>>> the familiar "railroad diagram":
>>> ![image](https://www.json.org/img/value.png)
>>>
>>> This diagram describes an algebraic data type (a sum of products), which we
>>> model directly with a set of Java interfaces:
>>>
>>> ```
>>> interface JsonValue { }
>>> interface JsonArray extends JsonValue { List<JsonValue> values(); }
>>> interface JsonObject extends JsonValue { Map<String, JsonValue> members(); }
>>> interface JsonNumber extends JsonValue { Number toNumber(); }
>>> interface JsonString extends JsonValue { String value(); }
>>> interface JsonBoolean extends JsonValue  { boolean value(); }
>>> interface JsonNull extends JsonValue { }
>>> ```
>>>
>>> These interfaces have (hidden) companion implementation classes that admit
>>> greater flexibility of implementation than modeling them directly with records
>>> would permit.
>>> Further, these interfaces are unsealed. We compromise on the sealed sum of
>>> products to enable
>>> alternative implementations, for example to support alternative formats that
>>> encode the same information in a JSON document but in a more efficient form than
>>> text.
>>>
>>> The API has static methods for parsing strings into a `JsonValue`, conversion to
>>> and from purely untyped representations (lists and maps), and factory methods
>>> for building JSON documents. We apply composition consistently, e.g, a
>>> JsonString has a string, a JsonObject has a map of string to JsonValue, as
>>> opposed to extension for structural JSON values.
>>>
>>> It turns out that this simple API is almost all we need for traversal. It gives
>>> us an immutable representation of a document, and we can use pattern matching to
>>> answer the myriad questions that will come up (Does this object have key X? Does
>>> it map to a number? Is that number representable as an integer?) when going
>>> from an untyped format like JSON to a more strongly typed domain model.
>>> Given a simple document like:
>>>
>>> ```
>>>     {
>>>         "name": "John?,
>>>         "age": 30
>>>     }
>>> ```
>>>
>>> we can parse and traverse the document as follows:
>>>
>>> ```
>>> JsonValue doc = Json.parse(inputString);
>>> if (doc instanceof JsonObject o
>>>     && o.members().get("name") instanceof JsonString s
>>>     && s.value() instanceof String name
>>>     && o.members().get("age") instanceof JsonNumber n
>>>     && n.toNumber() instanceof Long l && l instanceof int age) {
>>>             // use "name" and "age"
>>>         }
>>> ```
>>>
>>> Later, when the language acquires the ability to expose deconstruction patterns
>>> for arbitrary interfaces (similar to today's record patterns, see
>>> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns),
>>> this will be simplifiable to:
>>>
>>> ```
>>> JsonValue doc = Json.parse(inputString);
>>> if (doc instanceof JsonObject(var members)
>>>     && members.get("name") instanceof JsonString(String name)
>>>     && members.get("age") instanceof JsonNumber(int age)) {
>>>             // use "name" and "age"
>>>         }
>>> ```
>>>
>>> So, overtime, as more pattern matching features are introduced we anticipate
>>> improved use of the API. This is a primary reason why the API is so minimal.
>>> Convenience methods we add today, such as a method that accesses a JSON
>>> object component as say a JSON string or throws an exception, will become
>>> redundant in the future.
>>>
>>> ## JSON numbers
>>>
>>> The specification of JSON number makes no explicit distinction between integral
>>> and decimal numbers, nor specifies limits on the size of those numbers.
>>> This is a common source of interoperability issues when consuming JSON
>>> documents. Generally users cannot always but often do assume JSON numbers are
>>> parsable, without loss of precision, to IEEE double-precision floating point
>>> numbers or 32-bit signed integers.
>>>
>>> In this respect the API provides three means to operate on the JSON number,
>>> giving the user full control:
>>>
>>> 1. Underlying string representation can be obtained, if preserving syntactic
>>>    details such as leading or trailing zeros is important.
>>> 2. The string representation can be parsed to an instance of `BigDecimal`, using
>>>    `toBigDecimal` if preserving decimal numbers is important.
>>> 3. The string representation can be parsed into an instance of `Long`, `Double`,
>>>    `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this method
>>>    depends on how the representation can be parsed, possibly losing precision,
>>>    choosing a suitably convenient numeric type that can then be pattern
>>>    matched on.
>>>
>>> Primitive pattern matching will help as will further pattern matching features
>>> enabling the user to partially match.
>>>
>>> ## Prototype implementation
>>>
>>> The prototype implementation is currently located into the JDK sandbox
>>> repository
>>> under the `json` branch, see
>>> here
>>> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json
>>> The prototype API javadoc generated from the repository is also available at
>>> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html
>>>
>>> ### Testing and conformance
>>>
>>> The prototype implementation passes all conformance test cases but two,
>>> available
>>> on https://github.com/nst/JSONTestSuite. The two exceptions are the ones which
>>> the
>>> prototype specifically prohibits, i.e, duplicated names in JSON objects
>>> (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35).
>>>
>>> ### Performance
>>>
>>> Our main focus so far has been on the API design and a functional
>>> implementation.
>>> Hence, there has been less focus on performance even though we know there are a
>>> number of performance enhancements we can make eventually.
>>> We are reasonably happy with the current performance. The
>>> implementation performs well when compared to other JSON implementations
>>> parsing from string instances and traversing documents.
>>>
>>> An example of where we may choose simplicity and usability over performance
>>> is the rejection of JSON documents containing objects that in turn contain
>>> members
>>> with duplicate names. That may increase the cost of parsing, but simplifies the
>>> user
>>> experience for the majority of cases since if we reasonably assume JsonObjects
>>> are
>>> map-like, what should the user do with such members, pick one the last one?
>>> merge
>>> the values? or reject?
>>>
>>> ## A JSON JEP?
>>>
>>> We plan to draft JEP when we are ready. Attentive readers will observe that
>>> a JEP already exists, JEP 198: Light-Weight JSON API
>>> (https://openjdk.org/jeps/198). We will
> >> either update this JEP, or withdraw it and draft a new one.

From bpb at openjdk.org  Fri May 16 18:40:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 16 May 2025 18:40:38 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v23]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: <vulwfENcql99vTQcLGcYn8EXEMYV0wXxL-OFbqAxh8Y=.a99d67a3-3c67-4af9-92a0-859788873172@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: Improve verbiage about I/O errors

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/1afba6e6..a86610d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=21-22

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From bpb at openjdk.org  Fri May 16 18:40:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 16 May 2025 18:40:38 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <MbLTLYFhywojPyY0r9KZ9NuJ6hWVUQT3WNgcK2Nnsi8=.161b7e89-8657-4e3f-ba99-1d48684dda61@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <ZYxg_QnA1c0w84zoJQJ0Ay7HubbwkoQXljK14oWAkU0=.0b3af2c9-73ac-4661-9ffa-40519e004a24@github.com>
 <MbLTLYFhywojPyY0r9KZ9NuJ6hWVUQT3WNgcK2Nnsi8=.161b7e89-8657-4e3f-ba99-1d48684dda61@github.com>
Message-ID: <6ETSuONme1PBf9nNbzO2K54_AsmNTTKSmti_NJqq4Qg=.627bd84e-67f1-445b-b226-51f5d51ad369@github.com>

On Fri, 16 May 2025 18:21:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 478:
>> 
>>> 476:      *
>>> 477:      * <p> If an I/O error occurs reading from the stream, then it
>>> 478:      * may do so after some, but not all, characters have been read.
>> 
>> Is this better?
>> Suggestion:
>> 
>>      * <p> If an I/O error occurs reading from the stream, then some characters, but not all, may have been read.
>
>> Is this better?
> 
> I think it is clearer.

Thanks.

Applied in [a86610d](https://github.com/openjdk/jdk/pull/24728/commits/a86610d06169445a5c4b81a0c60527130a45e045).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2093518217

From bpb at openjdk.org  Fri May 16 18:40:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 16 May 2025 18:40:38 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <XhhlO7kp9gHxAH8FtiI7By4_KixYmqbDr6kKCbTmtXE=.afcdff58-ff7f-4ae8-9e2a-fb7153732125@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <XhhlO7kp9gHxAH8FtiI7By4_KixYmqbDr6kKCbTmtXE=.afcdff58-ff7f-4ae8-9e2a-fb7153732125@github.com>
Message-ID: <OFzwCUP8551ajdWuUCOGE3LM3aZ-niEocXo7couS1m0=.5113cf96-1d25-4efc-9c23-930b72330205@github.com>

On Fri, 16 May 2025 07:57:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I read this sentence a couple of times [...]

Please see [a86610d](https://github.com/openjdk/jdk/pull/24728/commits/a86610d06169445a5c4b81a0c60527130a45e045).

> I suspect that sentence was motivated from similar existing text in `Files.readString(...)` and there too I find it confusing.

If you think it worthwhile, please file an issue to improve that verbiage as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2093519255

From forax at univ-mlv.fr  Fri May 16 18:42:47 2025
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 16 May 2025 20:42:47 +0200 (CEST)
Subject: Towards a JSON API for the JDK
In-Reply-To: <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <f3cc90ef-25f3-41e3-a82b-0bac063c5733@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
Message-ID: <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Paul Sandoz" <paul.sandoz at oracle.com>, "core-libs-dev"
> <core-libs-dev at openjdk.org>
> Sent: Friday, May 16, 2025 7:46:09 PM
> Subject: Re: Towards a JSON API for the JDK

> If you read the implementation, you'll see that significant laziness is indeed
> possible for JsonObject and JsonArray, even while doing eager validation. (Of
> course, one can shift the balance to achieve various other tradeoffs.)
Reading the implementation is on my TODO list :) 

R?mi 

> On 5/16/2025 10:35 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>> ----- Original Message -----

>>> From: "Brian Goetz" [ mailto:brian.goetz at oracle.com | <brian.goetz at oracle.com> ]
>>> To: "Remi Forax" [ mailto:forax at univ-mlv.fr | <forax at univ-mlv.fr> ] , "Paul
>>> Sandoz" [ mailto:paul.sandoz at oracle.com | <paul.sandoz at oracle.com> ] Cc:
>>> "core-libs-dev" [ mailto:core-libs-dev at openjdk.org |
>>> <core-libs-dev at openjdk.org> ] Sent: Friday, May 16, 2025 2:53:18 PM
>>> Subject: Re: Towards a JSON API for the JDK

>>> On 5/15/2025 5:27 PM, Remi Forax wrote:

>>>> It's not clear to me why JsonArray (for example) has to be an interface instead
>>>> of a record ?

>>> Oh, you know the answer to this.? A record limits us to a single
>>> implementation with a rigid representation.? Behind an interface, we can
>>> hide lazy parsing and inflation, wrapping other representations to
>>> reduce copies, etc.

>> First, let me refine the question.
>> There are only 4 kinds of JSON values that benefit from having different
>> representations, object, array, string and number.
>> For object and array, both takes an interface as parameter (Map or List) so
>> JsonArray and JSonObject do not need to be themselves interfaces.

>> So the only values where it may be worth to be modeled using an interface are
>> JsonString and JsonNumber, because as you said, you can do "lazy" parsing.

>> But delaying the parsing of the content has the side effect that even if
>> Json.parse() did not throw an exception, it does not mean that the JSON text is
>> valid, an exception may be thrown later.

>> Now, for me, this library is more about being simple and safe than fast.
>> If you agree with that, delaying the parsing is not a good idea, thus JSON
>> values should be modeled using records and not interfaces.

>> regards,
>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250516/1b08c103/attachment.htm>

From lancea at openjdk.org  Fri May 16 19:00:00 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 May 2025 19:00:00 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v8]
In-Reply-To: <MuvMoKXj9GSHjncG8_kd0Cv4yXEjch_eLzTYSt-bCzI=.94cabdc7-f6d5-4cfa-a7d6-4ed88ad35506@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <MuvMoKXj9GSHjncG8_kd0Cv4yXEjch_eLzTYSt-bCzI=.94cabdc7-f6d5-4cfa-a7d6-4ed88ad35506@github.com>
Message-ID: <ogb8nRQUga5OZlGei9xRAkHN9D1v4cJ-gFqQsA5fm6E=.db9bd5e3-e719-4573-88be-7aef725fccc2@github.com>

On Thu, 15 May 2025 21:57:17 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust message based on review feedback

Hi Henry,

A few comments based on an initial pass through last update

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 65:

> 63:      * - does not contain a backslash, '\'
> 64:      * - does not contain a drive letter
> 65:      * - path element does not include '..'

change to 
 >    * - path element does not include '.' or '..'

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 117:

> 115:      * and UNIX file systems etc.
> 116:      * Also validate that the file name is not "." and that any name element is
> 117:      * not equal to ".."

Also validate that the file name is not "." or ".." and that any name element is
     * not equal to ".." or "."

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 132:

> 130:      * - CEN and LOC should have same entries, in the same order
> 131:      * NOTE: This implementation assumes CEN entries are to be added before
> 132:      *       add any LOC entries.

I think you should probably expand this comment a bit with the expected work flow as it takes a while to grasp your intent otherwise

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 155:

> 153:             }
> 154: 
> 155:             boolean isPlaceHolder() {

A comment would be helpful here for future maintainers

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 287:

> 285: \                             or invalid file names that could lead to unintended effects.\n\
> 286: \                             Check with the developer to ensure the jar archive integrity\n\
> 287: \                             when warnings observed after using this option.

I  think this could be improved perhaps something like:


main.help.opt.main.validate=\
\      --validate             Validate the contents of the jar archive. This option will:\n\
\                             + validate that the API exported by a multi-release\n\
\                                 jar archive is consistent across all different release\n\
\                                versions.\n\
\                             + warn if there are duplicate or invalid file names\n\


I think you can remove the verbiage WRT "Check with..."  from the help message

src/jdk.jartool/share/man/jar.md line 111:

> 109: `--validate`
> 110: :   Validate the contents of the jar archive.
> 111:     Check with the developer to ensure the jar archive integrity

You can remove here and add a suggestion in the "integrity of a Jar Archive" section as to what to do.

src/jdk.jartool/share/man/jar.md line 223:

> 221: 
> 222: ## Integrity of a jar Archive
> 223: As a jar archive is based on ZIP format, it is possible to manufacture a jar archive using tools

manufacture -> create

src/jdk.jartool/share/man/jar.md line 224:

> 222: ## Integrity of a jar Archive
> 223: As a jar archive is based on ZIP format, it is possible to manufacture a jar archive using tools
> 224: other than the `jar` command. The `--validate` options checks a jar archive for some integrity

`The '--validate' option performs the following integrity checks:`

src/jdk.jartool/share/man/jar.md line 237:

> 235: -   The API exported by a multi-release jar archive is consistent across all different release
> 236:     versions.
> 237: 

I would consider something similar to:


 - That there are no duplicate Zip Entry file names
 - Verify that the Zip Entry file name:
      - is not an absolute path
      - the file name is not '.' or '..'
      - does not contain a backslash, ''
      - does not contain a drive letter
      - path element does not include '.' or '..
  - The API exported by a multi-release jar archive is consistent across all different release versions.

 The jar tool will return a status code of 0 if there were  no integrity issues encountered and a status code of 1 an issue was found.
  
When an integrity issue is reported, it will often require that the jar file is re-created by the original source of the jar file
```.

test/jdk/tools/jar/ValidatorTest.java line 325:

> 323:     }
> 324: 
> 325:     private void rm(String cmdline) {

Maybe I missed it, but is this method used?

-------------

PR Review: https://git.openjdk.org/jdk/pull/24430#pullrequestreview-2847026334
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093296698
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093300176
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093421481
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093422620
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093445110
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093448844
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093450314
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093452262
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093475451
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093537089

From asemenyuk at openjdk.org  Fri May 16 19:02:03 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 16 May 2025 19:02:03 GMT
Subject: RFR: 8333664: Decouple command line parsing and package building
 in jpackage [v4]
In-Reply-To: <_IWCckFl77gXXM8TOCh1GlDTBrqrHTvJjNvvcaGt3-A=.7f61f15f-a5bf-4182-b609-1f3d6e199d89@github.com>
References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>
 <_IWCckFl77gXXM8TOCh1GlDTBrqrHTvJjNvvcaGt3-A=.7f61f15f-a5bf-4182-b609-1f3d6e199d89@github.com>
Message-ID: <3QTgvW106VE7nzle7N_Sm4EaSMZRdmaBn_OUpakYNLE=.65e1028c-7305-48bb-9274-3df5d77ce284@github.com>

On Sat, 10 May 2025 19:02:45 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Refactor jpackage to separate the configuration and execution phases.
>> At the configuration phase, jpackage parses command-line arguments and validates them.
>> At the execution phase, jpackage builds a bundle based on data collected at the configuration phase.
>> 
>> There was no clear separation between these phases. Both used the same data type (`Map<String, Object>`), making it hard to understand and use properly.
>> 
>> This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling.
>> 
>> The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map<String, Object>` "params".
>> 
>> Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers.
>> 
>> jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html
>> 
>> **Functional changes**
>> jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below.
>> 
>>  - Minimize copying of the source app image when doing native packaging.
>> 
>> Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations.
>> 
>> - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles.
>> 
>> post- and pre- install PKG scripts for SimplePackageTest package before and after the change:
>> <table>
>> <thead>
>> <tr>
>> <th>Scr...
>
> Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 512 commits:
> 
>  - Add ConfigFilesStasher that allows to save contents of jpackage build directories in external directory; Add clean_stashed_files.sh
>  - Merge branch 'master' into JDK-8333664
>  - Remove redundant StandardBundlerParam.createResource()
>  - Adapt JDK-8352480 fix
>  - Merge branch 'master' into JDK-8333664
>  - Fix javadoc
>  - Merge branch 'master' into JDK-8333664
>  - 8333568: Test that jpackage doesn't modify R/O files/directories
>    
>    Reviewed-by: almatvee
>  - 8356562: SigningAppImageTwoStepsTest test fails
>    
>    Reviewed-by: almatvee
>  - Remove clean_stashed_files.sh
>  - ... and 502 more: https://git.openjdk.org/jdk/compare/43696030...011eb710

Thank you for the review! I'll address the findings.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19668#issuecomment-2887469234

From asemenyuk at openjdk.org  Fri May 16 19:23:59 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 16 May 2025 19:23:59 GMT
Subject: RFR: 8333664: Decouple command line parsing and package building
 in jpackage [v4]
In-Reply-To: <4GqhkY0xKEKx5h6p3aLH-1ooMcWVmWZksJyKsAdBdec=.41398343-bbf0-4e1a-b25e-378a359439f0@github.com>
References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>
 <_IWCckFl77gXXM8TOCh1GlDTBrqrHTvJjNvvcaGt3-A=.7f61f15f-a5bf-4182-b609-1f3d6e199d89@github.com>
 <4GqhkY0xKEKx5h6p3aLH-1ooMcWVmWZksJyKsAdBdec=.41398343-bbf0-4e1a-b25e-378a359439f0@github.com>
Message-ID: <UhHp4NjswmG_visbkJbp2MYrDjZrO2mtqfBBe5SOAlM=.63002b52-d2d1-4009-99aa-447ce22fa73b@github.com>

On Tue, 13 May 2025 01:55:19 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 512 commits:
>> 
>>  - Add ConfigFilesStasher that allows to save contents of jpackage build directories in external directory; Add clean_stashed_files.sh
>>  - Merge branch 'master' into JDK-8333664
>>  - Remove redundant StandardBundlerParam.createResource()
>>  - Adapt JDK-8352480 fix
>>  - Merge branch 'master' into JDK-8333664
>>  - Fix javadoc
>>  - Merge branch 'master' into JDK-8333664
>>  - 8333568: Test that jpackage doesn't modify R/O files/directories
>>    
>>    Reviewed-by: almatvee
>>  - 8356562: SigningAppImageTwoStepsTest test fails
>>    
>>    Reviewed-by: almatvee
>>  - Remove clean_stashed_files.sh
>>  - ... and 502 more: https://git.openjdk.org/jdk/compare/43696030...011eb710
>
> src/jdk.jpackage/linux/classes/jdk/jpackage/internal/DesktopIntegration.java line 477:
> 
>> 475:             return Optional.of(fa)
>> 476:                     .flatMap(FileAssociation::icon)
>> 477:                     .map(DesktopIntegration::getSquareSizeOfImage)
> 
> `getSquareSizeOfImage` will return 0, if exception is thrown for invalid image. Should it return -1 or should we only accept icons if `getIconSize() > 0`?

`getIconSize()` returns the value returned by `getSquareSizeOfImage()` call or -1 if icon is not specified. This way the return value of `getIconSize()` falls into three categories:
 - <0 - failed to get dimensions of the given icon;
 - 0 - no icon file specified;
 - \>0 - icon size;

If we change `getSquareSizeOfImage()` as you suggest, the return value of `getIconSize()` will fall into two categories:
 - <0 - failed to get dimensions of the given icon, or the icon was not specified;
 - \>0 - icon size;

This change will make it impossible to tell if the icon was given or if an error occurred reading it from the return value of `getIconSize()`.

The caller code accepts an icon for the file association only if its size >0.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19668#discussion_r2093568135

From jrose at openjdk.org  Fri May 16 19:49:56 2025
From: jrose at openjdk.org (John R Rose)
Date: Fri, 16 May 2025 19:49:56 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6]
In-Reply-To: <Y-iTd9LtJ2nW9QZkNz1_xQ1kXToP8DcovFP-LAxrqXk=.8e9f7b28-fa77-4d27-a2c7-36a429a2f3ae@github.com>
References: <dm6o-XRNWecHjZeenCSRhAOEYI7L_mOOqfguvjlk_Bc=.cdb4e2e5-3500-48d5-8c05-749ff01f06f1@github.com>
 <Y-iTd9LtJ2nW9QZkNz1_xQ1kXToP8DcovFP-LAxrqXk=.8e9f7b28-fa77-4d27-a2c7-36a429a2f3ae@github.com>
Message-ID: <qgSvQFi40TedqSizh9VzWzdOkgl1nYXuTIG4SJ2M5cU=.d90dbc0c-9a52-4acf-b4d5-c4733c7ecd60@github.com>

On Wed, 30 Apr 2025 22:26:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Move intrinsic to be a subsection; just one most common function of the annotation
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>  - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - Shorter first sentence
>  - Updates, thanks to John
>  - Refine validation and defensive copying
>  - 8355223: Improve documentation on @IntrinsicCandidate

src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 33:

> 31:  * The {@code @IntrinsicCandidate} indicates that an annotated method is
> 32:  * recognized by {@code vmIntrinsics.hpp} for special treatment by the HotSpot
> 33:  * VM, unlike the other methods.  The HotSpot VM checks, when loading a class,

/, unlike the other methods/s/the other/other/

If you want something at the top that teaches about "the other methods", maybe say something like:

> Normally, the VM executes methods using only their bytecodes (or JNI definitions), but the VM is (in addition) allowed to use specialized code or analysis logic for methods marked as intrinsics.  Thus, intrinsic calls can be replaced or modified or specially optimized by the VM.

But those points will be covered further down, so maybe not.

More concisely:  s/, unlike the other methods/, unlike normal methods, which depend only on bytecodes or native entry points for their meaning to the VM/

Or just: s/, unlike the other methods//

Also, s/The HotSpot VM checks, when loading a class,/When loading a class, the HotSpot VM checks/ (fewer commas, better logical flow)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2093593792

From weijun at openjdk.org  Fri May 16 19:59:26 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 May 2025 19:59:26 GMT
Subject: RFR: 8357062: Update Public Suffix List to 823beb1
Message-ID: <RyvYtcgLjREsgMPvBFOoTJmsE-HeF54J5rVskIJ4hYk=.7b85a124-2e90-48de-bcf3-d3657879a31c@github.com>

This is a routine update to synchronize with the [Mozilla Public Suffix List](https://github.com/publicsuffix/list) for JDK 25, matching commit 823beb1 from 2025-05-12.

The test has been updated to reflect corresponding changes.

-------------

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/25273/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25273&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357062
  Stats: 3563 lines in 5 files changed: 1500 ins; 1442 del; 621 mod
  Patch: https://git.openjdk.org/jdk/pull/25273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25273/head:pull/25273

PR: https://git.openjdk.org/jdk/pull/25273

From duke at openjdk.org  Fri May 16 20:02:02 2025
From: duke at openjdk.org (duke)
Date: Fri, 16 May 2025 20:02:02 GMT
Subject: Withdrawn: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public
In-Reply-To: <sOHFKbGMg5BxWi50PAlpvRQM1BT9umFJTCE0UBlmzIc=.755d86f0-3e10-4877-9dd3-328194b08c81@github.com>
References: <sOHFKbGMg5BxWi50PAlpvRQM1BT9umFJTCE0UBlmzIc=.755d86f0-3e10-4877-9dd3-328194b08c81@github.com>
Message-ID: <mNr6mtSmpRylGg5UlZFesR_fwFQuXMyB3dZICRVz8NQ=.5b9de9c2-e6bd-4ad9-80f6-80d3eb67cd4b@github.com>

On Fri, 14 Mar 2025 12:29:22 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> 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.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24057

From rriggs at openjdk.org  Fri May 16 20:03:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 16 May 2025 20:03:56 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <uvpXW26IrXksJTYg12DdLAF7i1SNHG3zlIdWKcyVEHc=.cf20aaec-bbec-40ea-8b07-086e38303553@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <x1nMqw3J0aQoPyMt3WZ8YPnPFEwAebt_cnGtQYSXNSs=.6ae13f2a-5eeb-410d-9971-958526a8f16e@github.com>
 <BErvDbjWrXY7YGuIyQwR22cHeUP4knxU8MU4tw6AMN4=.c6b174ea-abdb-4b11-b6f9-0d97a03dc6ff@github.com>
 <Swr1GEuPbIhL4A273oZfYFmAlwYw3lPF2vaWhTzt4aE=.401b5bda-92db-4361-a581-579756ecf562@github.com>
 <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com>
 <RbqVx9l3PqI3nGa04lI8LZc8q4RyriZK8KP0-sqL098=.257abdaf-af46-4148-b925-42eebb1a3666@github.com>
 <6pcsLU3w7BQmpUbZ-p53iZsOK3kVckilpiHzyOu2VK8=.10d95ba6-1259-4e90-a994-407f9c247a67@github.com>
 <-alnojXx7gvsHuZyAugz_zk_1bf_QT0PfSZMdvP_Xt8=.0791cdf3-f466-4dd0-b672-5a0f619d14d7@github.com>
 <dJ6QbcWd3g7UZrHLzDKDZpsg1JGl5przqySy6chS8xM=.8f09904b-0f74-42d9-9562-47fcb73f5dc7@github.com>
 <dwtS71dqeIYLsEVqpFl0-AMfQRX35vq0zgp
 BrzDfkw4=.0af8ec7d-614e-4098-adaa-c1ab56d1f035@github.com>
 <uvpXW26IrXksJTYg12DdLAF7i1SNHG3zlIdWKcyVEHc=.cf20aaec-bbec-40ea-8b07-086e38303553@github.com>
Message-ID: <Y0KfcOCu9LV1wI_2qSbwsjC-bWuZ9biwAmPrvMc9yn8=.649731e0-99e4-4ea1-9523-38d41b2a64ff@github.com>

On Thu, 15 May 2025 20:34:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> @stuart-marks Sorry, didn't want to pull you in here, that's why I said, I am just *paraphrasing*.
>> 
>> That is correct, it is a different case, but the *final effect* for the caller is the same: If he needs to now whether a copy is made *or not*, he needs to have JavaDocs telling him *how* the new method works inside (whether it calls `subSequence` or whether it calls `getChars`). Otherwise he might make false assumptions about the result.
>
> This API is concerned with the "what" and not so much the "how."

The purpose of Reader and subclasses is to normalize characters in various forms (char arrays, byte streams, char buffers, etc) into a coherent stream of characters and be able to read it incrementally.
If the caller is going to use the entire CharSequence, as in the case of `Reader.of(cs)`, there is no reason to have a reader at all. Both String and CharSequence have more useful APIs than Reader for parsing.
The motivation for reading all characters and reading lines came from use cases around input from sub-processes where the input is decoded from a byte stream, but that's not `Reader.of(cs).`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2093611355

From jrose at openjdk.org  Fri May 16 20:23:57 2025
From: jrose at openjdk.org (John R Rose)
Date: Fri, 16 May 2025 20:23:57 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6]
In-Reply-To: <Y-iTd9LtJ2nW9QZkNz1_xQ1kXToP8DcovFP-LAxrqXk=.8e9f7b28-fa77-4d27-a2c7-36a429a2f3ae@github.com>
References: <dm6o-XRNWecHjZeenCSRhAOEYI7L_mOOqfguvjlk_Bc=.cdb4e2e5-3500-48d5-8c05-749ff01f06f1@github.com>
 <Y-iTd9LtJ2nW9QZkNz1_xQ1kXToP8DcovFP-LAxrqXk=.8e9f7b28-fa77-4d27-a2c7-36a429a2f3ae@github.com>
Message-ID: <RQSSJoSzJXiFcTeA1hCYkS7X1lof5wmtGWScPHKXKag=.6314ada9-e50a-4730-a232-6c48d86c16d8@github.com>

On Wed, 30 Apr 2025 22:26:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Move intrinsic to be a subsection; just one most common function of the annotation
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>  - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - Shorter first sentence
>  - Updates, thanks to John
>  - Refine validation and defensive copying
>  - 8355223: Improve documentation on @IntrinsicCandidate

Marked as reviewed by jrose (Reviewer).

src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 38:

> 36:  *
> 37:  * <h2 id="intrinsification">Intrinsification</h2>
> 38:  * The most frequently special treatment is intrinsification, which replaces a

> The most frequently special treatment is intrinsification, which

Better:

> Most frequently, the special treatment of an intrinsic is <em>intrinsification</em>, which

src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 47:

> 45:  * intrinsics necessary.
> 46:  * <p>
> 47:  * Intrinsification may never happen, or happen at any moment during execution.

s/or happen/or may happen/ (easier to parse)

src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 53:

> 51:  * intrinsic implementors must ensure that non-bytecode execution has the same
> 52:  * results as execution of the actual Java code in all application contexts
> 53:  * (given the assumptions on the arguments hold).

s/given the/given that the/

src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 57:

> 55:  * A candidate method should contain a minimal piece of Java code that should be
> 56:  * replaced by an intrinsic wholesale.  The backing intrinsic is (in the common
> 57:  * case) <strong>unsafe</strong> - they do not perform checks, but have

s/they do not perform/it may omit safety/
s/but have/but instead makes/
s/their/its/
s/that can ensure type safety/that type safety is ensured elsewhere/

src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 67:

> 65:  * accessing a field or method on an object which does not possess that field or
> 66:  * method; accessing an element of an array not actually present in the array;
> 67:  * and manipulating managed references in a way that prevents the GC from

? s/managed references/object references/  ("manage" is mentioned a moment later)

src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 90:

> 88:  * intrinsic.)  For example, the documentation can simply say that the result is
> 89:  * undefined if a race happens.  However, race conditions must not lead to
> 90:  * program failures or type safety breaches, as listed above.

Maybe add a teaching paragraph:

> Reasoning about such race conditions is difficult, but it is a necessary skill when working with intrinsics that can observe racing shared variables.  One example of a tolerable race is a repeated read of a shared reference.  This only works if the algorithm takes no action based on the first read, other than deciding to perform the second read; it must "forget what it saw" in the first read.  This is why the array-mismatch intrinsics can sometimes report a tentative search hit (maybe using vectorized code), which can then be confirmed (by scalar code) as the caller makes a fresh and independent observation. 

(This is done when the array mismatch logic performs NaN-folding.  I just noticed that the NaN-folding code in ArraysSupport is slightly incorrect with respect to races!)

-------------

PR Review: https://git.openjdk.org/jdk/pull/24777#pullrequestreview-2847502871
PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2093599254
PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2093605455
PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2093605395
PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2093605356
PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2093605323
PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2093632716

From shaojin.wensj at alibaba-inc.com  Fri May 16 21:41:30 2025
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Sat, 17 May 2025 05:41:30 +0800
Subject: =?UTF-8?B?5Zue5aSN77yaVG93YXJkcyBhIEpTT04gQVBJIGZvciB0aGUgSkRL?=
In-Reply-To: <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <f3cc90ef-25f3-41e3-a82b-0bac063c5733@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>,
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <3c9d37e7-fb38-40cb-ab95-5d7ad3e56019.shaojin.wensj@alibaba-inc.com>

As the author of a popular json library (fastjson/fastjson2), I think the current design is not good, not easy to use, and the performance is not good.
The JsonNull/JsonNumber/JsonString/JsonValue here should not be designed like this, which will cause trouble to users and affect performance.
For simple types of JSON, you can directly use Java type mapping, such as:
null -> null
string -> string
number -> integer/long/bigint/float/double, select the mapping type through configuration, or according to a rule we set.
Array and Object types should also support more flexible mapping:
object -> JsonObject or Map (HashMap/LinkedHashMap/ConcurrentHashMap...)
array -> JsonArray or List(ArrayList/LinkedList/...) or typed-array
Lazy parsing should not be used because it will degrade performance. If we need to support partial parsing, we can provide a skip api, and later we can provide a jsonpath api, or support passing in type/JsonSchema information and parsing according to the schema.
Also, if we want better performance, both Parser and Generator should provide both UTF16 and UTF8 implementations.
------------------------------------------------------------------
????forax <forax at univ-mlv.fr>
?????2025?5?17?(??) 02:43
????Brian Goetz<brian.goetz at oracle.com>
????Paul Sandoz<paul.sandoz at oracle.com>; "core-libs-dev"<core-libs-dev at openjdk.org>
????Re: Towards a JSON API for the JDK
From: "Brian Goetz" <brian.goetz at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "Paul Sandoz" <paul.sandoz at oracle.com>, "core-libs-dev" <core-libs-dev at openjdk.org>
Sent: Friday, May 16, 2025 7:46:09 PM
Subject: Re: Towards a JSON API for the JDK
If you read the implementation, you'll see that significant laziness is indeed possible for JsonObject and JsonArray, even while doing eager validation. (Of course, one can shift the balance to achieve various other tradeoffs.)
Reading the implementation is on my TODO list :)
R?mi
On 5/16/2025 10:35 AM, forax at univ-mlv.fr <mailto:forax at univ-mlv.fr > wrote:
----- Original Message ----- From: "Brian Goetz" <brian.goetz at oracle.com> <mailto:brian.goetz at oracle.com > To: "Remi Forax" <forax at univ-mlv.fr> <mailto:forax at univ-mlv.fr >, "Paul Sandoz" <paul.sandoz at oracle.com> <mailto:paul.sandoz at oracle.com > Cc: "core-libs-dev" <core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org > Sent: Friday, May 16, 2025 2:53:18 PM Subject: Re: Towards a JSON API for the JDK On 5/15/2025 5:27 PM, Remi Forax wrote: It's not clear to me why JsonArray (for example) has to be an interface instead of a record ? Oh, you know the answer to this. A record limits us to a single implementation with a rigid representation. Behind an interface, we can hide lazy parsing and inflation, wrapping other representations to reduce copies, etc. First, let me refine the question. There are only 4 kinds of JSON values that benefit from having different representations, object, array, string and number. For object and array, both takes an interface as parameter (Map or List) so JsonArray and JSonObject do not need to be themselves interfaces. So the only values where it may be worth to be modeled using an interface are JsonString and JsonNumber, because as you said, you can do "lazy" parsing. But delaying the parsing of the content has the side effect that even if Json.parse() did not throw an exception, it does not mean that the JSON text is valid, an exception may be thrown later. Now, for me, this library is more about being simple and safe than fast. If you agree with that, delaying the parsing is not a good idea, thus JSON values should be modeled using records and not interfaces. regards, R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250517/6fc7623b/attachment.htm>

From asemenyuk at openjdk.org  Fri May 16 23:43:48 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 16 May 2025 23:43:48 GMT
Subject: RFR: 8333664: Decouple command line parsing and package building
 in jpackage [v5]
In-Reply-To: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>
References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>
Message-ID: <9Dt1iXbcsd6PQVdANTY-8mhGFYoszrfVxUsEHnkOXIs=.b16637aa-7320-404b-bee6-29fadc99ed4b@github.com>

> Refactor jpackage to separate the configuration and execution phases.
> At the configuration phase, jpackage parses command-line arguments and validates them.
> At the execution phase, jpackage builds a bundle based on data collected at the configuration phase.
> 
> There was no clear separation between these phases. Both used the same data type (`Map<String, Object>`), making it hard to understand and use properly.
> 
> This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling.
> 
> The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map<String, Object>` "params".
> 
> Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers.
> 
> jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html
> 
> **Functional changes**
> jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below.
> 
>  - Minimize copying of the source app image when doing native packaging.
> 
> Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations.
> 
> - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles.
> 
> post- and pre- install PKG scripts for SimplePackageTest package before and after the change:
> <table>
> <thead>
> <tr>
> <th>Script</th>
> <th>New</th>
> <th>Old</th>
> </tr>
> </thead>
> <tbody...

Alexey Semenyuk has updated the pull request incrementally with three additional commits since the last revision:

 - Cleanup
 - appImageLyout -> appImageLayout
 - destktop -> desktop

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19668/files
  - new: https://git.openjdk.org/jdk/pull/19668/files/011eb710..8447a3e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19668&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19668&range=03-04

  Stats: 42 lines in 15 files changed: 4 ins; 6 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/19668.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19668/head:pull/19668

PR: https://git.openjdk.org/jdk/pull/19668

From asemenyuk at openjdk.org  Fri May 16 23:47:07 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 16 May 2025 23:47:07 GMT
Subject: RFR: 8333664: Decouple command line parsing and package building
 in jpackage [v4]
In-Reply-To: <_IWCckFl77gXXM8TOCh1GlDTBrqrHTvJjNvvcaGt3-A=.7f61f15f-a5bf-4182-b609-1f3d6e199d89@github.com>
References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>
 <_IWCckFl77gXXM8TOCh1GlDTBrqrHTvJjNvvcaGt3-A=.7f61f15f-a5bf-4182-b609-1f3d6e199d89@github.com>
Message-ID: <heJGw3SwLlo9fQPoJbWsgQY-0iP72tGXq1_6xn4XWAw=.c52ff4d5-9f0b-4971-b506-343fe8121e59@github.com>

On Sat, 10 May 2025 19:02:45 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Refactor jpackage to separate the configuration and execution phases.
>> At the configuration phase, jpackage parses command-line arguments and validates them.
>> At the execution phase, jpackage builds a bundle based on data collected at the configuration phase.
>> 
>> There was no clear separation between these phases. Both used the same data type (`Map<String, Object>`), making it hard to understand and use properly.
>> 
>> This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling.
>> 
>> The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map<String, Object>` "params".
>> 
>> Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers.
>> 
>> jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html
>> 
>> **Functional changes**
>> jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below.
>> 
>>  - Minimize copying of the source app image when doing native packaging.
>> 
>> Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations.
>> 
>> - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles.
>> 
>> post- and pre- install PKG scripts for SimplePackageTest package before and after the change:
>> <table>
>> <thead>
>> <tr>
>> <th>Scr...
>
> Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 512 commits:
> 
>  - Add ConfigFilesStasher that allows to save contents of jpackage build directories in external directory; Add clean_stashed_files.sh
>  - Merge branch 'master' into JDK-8333664
>  - Remove redundant StandardBundlerParam.createResource()
>  - Adapt JDK-8352480 fix
>  - Merge branch 'master' into JDK-8333664
>  - Fix javadoc
>  - Merge branch 'master' into JDK-8333664
>  - 8333568: Test that jpackage doesn't modify R/O files/directories
>    
>    Reviewed-by: almatvee
>  - 8356562: SigningAppImageTwoStepsTest test fails
>    
>    Reviewed-by: almatvee
>  - Remove clean_stashed_files.sh
>  - ... and 502 more: https://git.openjdk.org/jdk/compare/43696030...011eb710

All findings fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19668#issuecomment-2887850571

From acobbs at openjdk.org  Fri May 16 23:55:57 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 16 May 2025 23:55:57 GMT
Subject: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for()
 loops [v3]
In-Reply-To: <hPAjrTbUUlkLrYiL8CJkkIrz5df8oSS5dy0pKmVFkAI=.63747977-f94b-4b46-a561-4a8faee89f4b@github.com>
References: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
 <hPAjrTbUUlkLrYiL8CJkkIrz5df8oSS5dy0pKmVFkAI=.63747977-f94b-4b46-a561-4a8faee89f4b@github.com>
Message-ID: <jHpcsOHvFj2G2HTS6BfoscYxH4Qn_tFVp2AJMzHYnQ0=.2e7ec784-4853-4f13-8d1f-ea90774bc7b8@github.com>

On Thu, 15 May 2025 21:04:40 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this small performance tweak `ArrayDeque`.
>> 
>> `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Blackhole ArrayDeque to ensure it's not ignored by the compiler.

I'm closing the PR because it's gone into low-level optimization details that are beyond me.

However I'm still unclear on whether bulk memory set operations are being fully optimized. By that I mean doing [something like this](https://git.zx2c4.com/glibc/commit/?id=cec3aef32412779e207f825db0d057ebb4628ae8) on arm64 at least. Any insights from the experts would be appreciated.

Thanks for the interesting discussion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25237#issuecomment-2887858521

From acobbs at openjdk.org  Fri May 16 23:55:57 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 16 May 2025 23:55:57 GMT
Subject: Withdrawn: 8356993: ArrayDeque should use Arrays.fill() instead of
 for() loops
In-Reply-To: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
References: <V-tAdrm5sicmGd660kXwEJYHA0kOAPIqP8plQqp-LXk=.4c63142e-2fe5-4974-a42b-8cf86fc83eab@github.com>
Message-ID: <4yLc7hJ5iTo4C1dRixGE6m-icwHq1WK1cTBga_ztCi0=.8d08547f-008f-4540-8a3f-992ab2dc92f7@github.com>

On Wed, 14 May 2025 19:37:37 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this small performance tweak `ArrayDeque`.
> 
> `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `Arrays.fill()` instead.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25237

From naoto at openjdk.org  Sat May 17 00:13:05 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 17 May 2025 00:13:05 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
Message-ID: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>

`java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.

-------------

Commit messages:
 - Tests read* method variations
 - Merge branch 'master' into JDK-8356985-Use-stdin-encoding-in-Console
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/25271/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356985
  Stats: 270 lines in 11 files changed: 241 ins; 3 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/25271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25271/head:pull/25271

PR: https://git.openjdk.org/jdk/pull/25271

From smarks at openjdk.org  Sat May 17 01:02:03 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 17 May 2025 01:02:03 GMT
Subject: RFR: 8351230: Collections.synchronizedList returns a list that is
 not thread-safe [v2]
In-Reply-To: <3-h5cco6E3PRpslFiqAR913I_lJ8_c0tMHhREoHCkps=.a9ba0091-c77d-4dda-b7d0-53e83ac57ca3@github.com>
References: <HtBkFlpJ7N3BjMiDZcA2LgM0YOEkd4L1_6XKIPJwwew=.6325e6ba-153e-43c6-9de6-ab00c1e972ed@github.com>
 <DRxCjR218Sb5Px9jomhYtD8HV-g71CqeJ0Pei-xYsBk=.def444b8-bf73-44f4-85d0-3750774b9be6@github.com>
 <3-h5cco6E3PRpslFiqAR913I_lJ8_c0tMHhREoHCkps=.a9ba0091-c77d-4dda-b7d0-53e83ac57ca3@github.com>
Message-ID: <ya2XYGQdDYJDq99nkK6iVhWCOqRup9wbezeodFGDVqU=.fda2ed8f-006c-4896-8431-af92d86f9987@github.com>

On Fri, 16 May 2025 09:24:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reversed view of SynchronizedRandomAccessList should also be RandomAccess.
>>   Add tests to ensure RandomAccess is preserved when reversing.
>
> test/jdk/java/util/Collections/SyncListBash.java line 31:
> 
>> 29:  * @run     main SyncListBash f
>> 30:  * @run     main SyncListBash r
>> 31:  * @summary Test that List's new SequencedCollection methods are properly
> 
> Nit - jtreg recommends `@summary` to be after `@bug` https://openjdk.org/jtreg/tag-spec.html#ORDER. It would be good to follow that for this new test.

Oh, thanks for pointing this out. I'll fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24990#discussion_r2093806293

From almatvee at openjdk.org  Sat May 17 01:09:00 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 17 May 2025 01:09:00 GMT
Subject: RFR: 8333664: Decouple command line parsing and package building
 in jpackage [v5]
In-Reply-To: <9Dt1iXbcsd6PQVdANTY-8mhGFYoszrfVxUsEHnkOXIs=.b16637aa-7320-404b-bee6-29fadc99ed4b@github.com>
References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>
 <9Dt1iXbcsd6PQVdANTY-8mhGFYoszrfVxUsEHnkOXIs=.b16637aa-7320-404b-bee6-29fadc99ed4b@github.com>
Message-ID: <Bfz_MWMMnojCpRx_oX1NsvarDtT7zMlIUsAiJ5T7Xdk=.91d73785-453e-4ba4-ac76-85c5b4c43567@github.com>

On Fri, 16 May 2025 23:43:48 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Refactor jpackage to separate the configuration and execution phases.
>> At the configuration phase, jpackage parses command-line arguments and validates them.
>> At the execution phase, jpackage builds a bundle based on data collected at the configuration phase.
>> 
>> There was no clear separation between these phases. Both used the same data type (`Map<String, Object>`), making it hard to understand and use properly.
>> 
>> This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling.
>> 
>> The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map<String, Object>` "params".
>> 
>> Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers.
>> 
>> jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html
>> 
>> **Functional changes**
>> jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below.
>> 
>>  - Minimize copying of the source app image when doing native packaging.
>> 
>> Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations.
>> 
>> - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles.
>> 
>> post- and pre- install PKG scripts for SimplePackageTest package before and after the change:
>> <table>
>> <thead>
>> <tr>
>> <th>Scr...
>
> Alexey Semenyuk has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Cleanup
>  - appImageLyout -> appImageLayout
>  - destktop -> desktop

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19668#pullrequestreview-2847819117

From smarks at openjdk.org  Sat May 17 01:14:01 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 17 May 2025 01:14:01 GMT
Subject: RFR: 8351230: Collections.synchronizedList returns a list that is
 not thread-safe [v2]
In-Reply-To: <gd0qhk7C0xp6JN808P3nHA3bCi2eNE3Xj7Nb3_HZEd4=.8c45c363-3ca8-409a-8773-2a9dccbb0063@github.com>
References: <HtBkFlpJ7N3BjMiDZcA2LgM0YOEkd4L1_6XKIPJwwew=.6325e6ba-153e-43c6-9de6-ab00c1e972ed@github.com>
 <DRxCjR218Sb5Px9jomhYtD8HV-g71CqeJ0Pei-xYsBk=.def444b8-bf73-44f4-85d0-3750774b9be6@github.com>
 <gd0qhk7C0xp6JN808P3nHA3bCi2eNE3Xj7Nb3_HZEd4=.8c45c363-3ca8-409a-8773-2a9dccbb0063@github.com>
Message-ID: <5Kk4sYns2VWuHD1MLEVCP96dfxCMt3mecJ1xhdUv6bA=.4720bdaf-a943-496d-b7ec-7f0d89369a3d@github.com>

On Thu, 15 May 2025 12:17:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reversed view of SynchronizedRandomAccessList should also be RandomAccess.
>>   Add tests to ensure RandomAccess is preserved when reversing.
>
> src/java.base/share/classes/java/util/Collections.java line 2782:
> 
>> 2780:             synchronized (mutex) {list.sort(c);}
>> 2781:         }
>> 2782:         public void addFirst(E element) {
> 
> Are these overloads strictly needed as the `default` implementations will delegate to `get` and `set`, which, in turn, are thread safe?

(I think you mean overrides?) Good question. It might be possible to get away without overriding and delegating every method. However, these wrapper classes have historically had bugs that arose from failing to override some methods. This isn't the first time this has happened. Thus I'm inclined to add the overrides even if they aren't strictly necessary. I added this note to the bug report just now:

> It's clear that the getFirst(), getLast(), removeFirst(), and removeLast() default methods must be overridden and synchronized in order to guarantee proper operation. The addFirst() and addLast() methods each resolve to a single call to 'this' and so we could probably get away without overriding them. However, it's possible, though unlikely, that the default method implementations could change, making them unsafe. In addition, it's a bit nicer to the backing list to have all the methods on the wrapper delegate to the corresponding methods of the backing list. This might be helpful if the backing list has some optimizations for particular methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24990#discussion_r2093809289

From smarks at openjdk.org  Sat May 17 01:25:14 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 17 May 2025 01:25:14 GMT
Subject: RFR: 8351230: Collections.synchronizedList returns a list that is
 not thread-safe [v3]
In-Reply-To: <HtBkFlpJ7N3BjMiDZcA2LgM0YOEkd4L1_6XKIPJwwew=.6325e6ba-153e-43c6-9de6-ab00c1e972ed@github.com>
References: <HtBkFlpJ7N3BjMiDZcA2LgM0YOEkd4L1_6XKIPJwwew=.6325e6ba-153e-43c6-9de6-ab00c1e972ed@github.com>
Message-ID: <4roAjSkqEbwwAk5GsfRSGAPTXZLBcXwzdxXa9SqTyLg=.5974684e-fbce-4cee-8ad2-cb5098bac213@github.com>

> Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper:
> 
> - overrides and adds locking to SequencedCollection methods;
> - performs instance management of reversed synchronized views;
> - adds test for race conditions and functional tests of synchronized wrappers.

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 eight additional commits since the last revision:

 - Merge branch 'master' into JDK-8351230-synchronized-list
 - Adjust @summary line in test.
 - Reversed view of SynchronizedRandomAccessList should also be RandomAccess.
   Add tests to ensure RandomAccess is preserved when reversing.
 - moar comments
 - Various tweaks.
 - fix for synch list
 - fix copyright line
 - tests for synch list

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24990/files
  - new: https://git.openjdk.org/jdk/pull/24990/files/1750bb20..0ad5d080

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24990&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24990&range=01-02

  Stats: 58374 lines in 1704 files changed: 29902 ins; 19676 del; 8796 mod
  Patch: https://git.openjdk.org/jdk/pull/24990.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24990/head:pull/24990

PR: https://git.openjdk.org/jdk/pull/24990

From henryjen at openjdk.org  Sat May 17 01:27:38 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Sat, 17 May 2025 01:27:38 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>

> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Address review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/1bc1f8cb..da4a9139

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=07-08

  Stats: 53 lines in 4 files changed: 12 ins; 20 del; 21 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 jpai at openjdk.org  Sat May 17 02:20:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 17 May 2025 02:20:00 GMT
Subject: RFR: 8351230: Collections.synchronizedList returns a list that is
 not thread-safe [v3]
In-Reply-To: <4roAjSkqEbwwAk5GsfRSGAPTXZLBcXwzdxXa9SqTyLg=.5974684e-fbce-4cee-8ad2-cb5098bac213@github.com>
References: <HtBkFlpJ7N3BjMiDZcA2LgM0YOEkd4L1_6XKIPJwwew=.6325e6ba-153e-43c6-9de6-ab00c1e972ed@github.com>
 <4roAjSkqEbwwAk5GsfRSGAPTXZLBcXwzdxXa9SqTyLg=.5974684e-fbce-4cee-8ad2-cb5098bac213@github.com>
Message-ID: <V9IK1vQCOJrQVCikCyboOpQCJ8-ZQivY0EzOruvM_M0=.ab94fc8d-b0ec-44ee-a077-015dcc0de27e@github.com>

On Sat, 17 May 2025 01:25:14 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper:
>> 
>> - overrides and adds locking to SequencedCollection methods;
>> - performs instance management of reversed synchronized views;
>> - adds test for race conditions and functional tests of synchronized wrappers.
>
> 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8351230-synchronized-list
>  - Adjust @summary line in test.
>  - Reversed view of SynchronizedRandomAccessList should also be RandomAccess.
>    Add tests to ensure RandomAccess is preserved when reversing.
>  - moar comments
>  - Various tweaks.
>  - fix for synch list
>  - fix copyright line
>  - tests for synch list

Thank you for the update, Stuart. This looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24990#pullrequestreview-2847863986

From liach at openjdk.org  Sat May 17 02:21:36 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 17 May 2025 02:21:36 GMT
Subject: RFR: 8357178: Simplify Class::componentType
Message-ID: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com>

`isArray` and null return is now redundant when `componentType` is changed to an explicit field.

-------------

Commit messages:
 - 8357178: Simplify Class::componentType

Changes: https://git.openjdk.org/jdk/pull/25280/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25280&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357178
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25280.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25280/head:pull/25280

PR: https://git.openjdk.org/jdk/pull/25280

From ethan at mccue.dev  Sat May 17 05:58:37 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Sat, 17 May 2025 07:58:37 +0200
Subject: Towards a JSON API for the JDK
In-Reply-To: <1353089152.267509212.1747398414378.JavaMail.zimbra@univ-eiffel.fr>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gt3GNjDPS2m-2wha5AwgumMvBRxKw+bwgTCNQ1xCiDfg@mail.gmail.com>
 <1353089152.267509212.1747398414378.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CA+NR86hECE-T9gMZT6+gbSoFhDpLeVDkvGYqyz-ByV18_MgpVw@mail.gmail.com>

I fail to see a fundamental difference in level (high vs. low) - we should
consider extensibility, ergonomics, and how people are likely to
use the API.

"It gets in the way of laziness" is a valid reason to have JsonObject not
be a Map<String, Json> (though I still want to interrogate it), "the idea
is to use delegation" and a desire for "DOP over OOP" is not.

This is part of why fromUntyped/toUntyped is uncomfortable - it's choosing
one particular encoding of JSON and making it central to the API. Is that
really the most important encoding?

And I get a lot of mileage out of Json extending JsonEncodable - both in
terms of ergonomics for constructing Json structures (being able to turn a
List<Person> into Json using the same overload as you would a List<Json>,
etc.) as well as an extension point for interacting with other json
libraries (easy to teach jackson and co. to treat something implementing an
interface differently).

On Fri, May 16, 2025 at 2:26?PM <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"Ethan McCue" <ethan at mccue.dev>
> *To: *"Remi Forax" <forax at univ-mlv.fr>
> *Cc: *"Paul Sandoz" <paul.sandoz at oracle.com>, "core-libs-dev" <
> core-libs-dev at openjdk.org>
> *Sent: *Friday, May 16, 2025 1:44:52 AM
> *Subject: *Re: Towards a JSON API for the JDK
>
> I present for your consideration the library I made when spiraling about
> this problem space a few years ago
>
> https://github.com/bowbahdoe/json
>
>
> https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html
>
> Notably missing during the design process here were patterns, hence the
> JsonDecoder design. I haven't been able to evaluate how patterns affect
> that on account of them not being out.
>
> I will more thoroughly peruse the draft of java.util.json at a later date,
> but my initial observations/comments:
>
> * I am not sure having JsonValue be distinct from Json has value.
> * toUntyped feels a little strange to me - the only type information
> presumably lost is the sealed-ness of the hierarchy. The interplay between
> that and toNumber is also a little unnerving.
> * One notion that I found helpful was that a class could be "json
> encodable," meaning there is a method to call to obtain a canonical json
> representation.
>
> record Person(String name) implements JsonEncodable {
> @Override
>     public Json toJson() {
>         return Json.objectBuilder()
>             .put("namen", name)
>             .build();
>     }
> }
>
> Which helper methods like Json#of(List<? extends JsonEncodable>) could
> make use of. Json itself (JsonValue in your prototype) could then have a
> vacuous implementation.
>
> * Terminology wise - I went with reading/writing for the actual
> parsing/generation of json and encoding/decoding for the mapping of those
> representations to/from specific classes. The merits are not top of mind,
> just noting the difference. read/write vs parse/toString+toDisplayString
> * One thing I did was make the helper methods in Json null tolerant and
> the ones in the specific subtypes like JsonString not. This was because
> from what I saw of usages of javax.json/jakarta.json that nullability was a
> footgun and correcting for it required changes to code structure (breaking
> up builder chains with if (x != null) checks)
> * The functionality you want from JsonNumber could be achieved by making
> it just extend Number (
> https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/JsonNumber.java)
> instead of a bespoke toNumber. You need the extra methods to go to big
> decimal and co, but it's just an extension to the behavior of Number at
> that point.
> * JsonObject and JsonArray could implement Map<String, Json> and
> List<Json> respectively. This lowers the need for toUntyped() - since
> presumably one of the use cases for that is turning the json tree into
> something that more generic map/list traversal code can handle. It also
> complicates any lazy loading somewhat.
> * Assuming patterns can be placed on interfaces, you might want to
> consider something similar to JsonDecoder, but with a pattern instead of
> a method that throws an exception.
>
> // Where here fromJson would box up the logic for testing and extracting
> from each element in the array.
> List<Person> people = array(json, Person::fromJson);
>
> * I don't think there is sufficient cause for anything to be non-sealed at
> this point.
> * JsonBoolean and JsonNull do not have reasonable alternative
> implementations - as far as I can imagine, maybe i'm wrong - so maybe those
> can just be final classes?
> * If you seal up the whole hierarchy then its pretty trivial to make it
> serializable (
> https://github.com/bowbahdoe/json/blob/main/src/main/java/dev/mccue/json/serialization/JsonSerializationProxy.java
> )
>
>
> Hello,
> I think your library is more high-level than java.util.json.
> Moreover, Paul proposes a design closer to DOP (Data Oriented Programming)
> than OOP.
>
> JsonNumber should not extend Number, JsonObject and JsonArray should not
> implements Map and List, the idea is to use delegation instead.
> (BTW extending Number will become an issue in the future if the VM tries
> to flatten filed typed with a value capable abstract class like Number)
>
> JSON is fundamentally untyped and recursive, but also describe data
> structures, for me, the proposed API exposes that structure (the subtypes
> of JsonValue) and make it easy to move from a JSON text to Java objects or
> vice-versa.
> The java.util.json API is very simple,
> - Json.fromUntyped() see a Java object to a structured JSON value (a
> JsonValue),
> - Json.toUntyped() unwrap a structured JSON value to extract the
> underlying Java object.
> - Json.parse() from String to a structured JSON value
> - Json.toDisplayString() (i would prefer "prettyString") goes from a
> structured JSON value to a pretty string.
>
> Having a JsonEncoder and JsonDecoder, JsonDecodable, etc is more high
> level than what is proposed here, so you can write objects like
> JsonEncoder/Decoder on top of it.
> Your example of JsonEncodable can be re-written to use the java.util.json
> API like this
>
> record Person(String name) implements JsonEncodable {
>     @Override
>     public JsonValue toJson() {
>         return Json.fromUntyped(Map.of("name", name));
>     }
> }
>
> Compared to your code, java.util.json uses immutable data structures
> instead of a mutable builder (and yes, you lose the order, until
> SequenceMap.of() exists).
>
> regards,
> R?mi
>
>
>
>
> On Thu, May 15, 2025 at 11:29?PM Remi Forax <forax at univ-mlv.fr> wrote:
>
>> Hi Paul,
>> yes, not having a simple JSON API in Java is an issue for beginners.
>>
>> It's not clear to me why JsonArray (for example) has to be an interface
>> instead of a record ?
>>
>> I understand why Json.parse() only works on String and char[] but the API
>> make it too easy to have many performance issues.
>> I think you need versions using a Reader and a Path.
>> Bonus point, if there is a method walk() that also returns a JsonValue
>> but the List/Map inside JsonArray/JsonObject are populated lazily.
>>
>> Minor point: Json.toDisplayString() should takes a second parameters
>> indicating the number of spaces used for the indentation (like
>> JSON.stringify in JS).
>>
>> regards,
>> R?mi
>>
>> ----- Original Message -----
>> > From: "Paul Sandoz" <paul.sandoz at oracle.com>
>> > To: "core-libs-dev" <core-libs-dev at openjdk.org>
>> > Sent: Thursday, May 15, 2025 10:30:42 PM
>> > Subject: Towards a JSON API for the JDK
>>
>> > Hi,
>> >
>> > We would like to share with you our thoughts and plans towards a JSON
>> API for
>> > the JDK.
>> > Please see the document below.
>> >
>> > -
>> >
>> > We have had the pleasure of using a clone of this API in some
>> experiments we are
>> > conducting with
>> > ONNX and code reflection [1]. Using the API we were able to quickly
>> write code
>> > to ingest and convert
>> > a JSON document representing ONNX operation schema into instances of
>> records
>> > modeling the schema
>> > (see here [2]).
>> >
>> > The overall out-of-box experience with such a minimal "batteries
>> included? API
>> > has so far been positive.
>> >
>> > Thanks,
>> > Paul.
>> >
>> > [1] https://openjdk.org/projects/babylon/
>> > [2]
>> >
>> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87
>> >
>> > # Towards a JSON API for the JDK
>> >
>> > One of the most common requests for the JDK is an API for parsing and
>> generating
>> > JSON. While JSON originated as a text-based serialization format for
>> JSON
>> > objects ("JSON" stands for "JavaScript Object Notation"), because of
>> its simple
>> > and flexible syntax, it eventually found use outside the JavaScript
>> ecosystem as
>> > a general data interchange format, such as framework configuration
>> files and web
>> > service requests/response formats.
>> >
>> > While the JDK cannot, and should not, provide libraries for every
>> conceivable
>> > file format or protocol, the JDK philosophy is one of "batteries
>> included",
>> > which is to say we should be able to write basic programs that use
>> common
>> > protocols such as HTTP, without having to appeal to third party
>> libraries.
>> > The Java ecosystem already has plenty of JSON libraries, so inclusion in
>> > the JDK is largely meant to be a convenience, rather than needing to be
>> the "one
>> > true" JSON library to meet the needs of all users. Users with specific
>> needs
>> > are always free to select one of the existing third-party libraries.
>> >
>> > ## Goals and requirements
>> >
>> > Our primary goal is that the library be simple to use for parsing,
>> traversing,
>> > and generating conformant JSON documents. Advanced features, such as
>> data
>> > binding or path-based traversal should be possible to implement as
>> layered
>> > features, but for simplicity are not included in the core API. We adopt
>> a goal
>> > that the performance should be "good enough", but where performance
>> > considerations conflict with simplicity and usability, we will choose
>> in favor
>> > of the latter.
>> >
>> > ## API design approach
>> >
>> > The description of JSON at `https:://json.org` describes a JSON
>> document using
>> > the familiar "railroad diagram":
>> > ![image](https://www.json.org/img/value.png)
>> >
>> > This diagram describes an algebraic data type (a sum of products),
>> which we
>> > model directly with a set of Java interfaces:
>> >
>> > ```
>> > interface JsonValue { }
>> > interface JsonArray extends JsonValue { List<JsonValue> values(); }
>> > interface JsonObject extends JsonValue { Map<String, JsonValue>
>> members(); }
>> > interface JsonNumber extends JsonValue { Number toNumber(); }
>> > interface JsonString extends JsonValue { String value(); }
>> > interface JsonBoolean extends JsonValue  { boolean value(); }
>> > interface JsonNull extends JsonValue { }
>> > ```
>> >
>> > These interfaces have (hidden) companion implementation classes that
>> admit
>> > greater flexibility of implementation than modeling them directly with
>> records
>> > would permit.
>> > Further, these interfaces are unsealed. We compromise on the sealed sum
>> of
>> > products to enable
>> > alternative implementations, for example to support alternative formats
>> that
>> > encode the same information in a JSON document but in a more efficient
>> form than
>> > text.
>> >
>> > The API has static methods for parsing strings into a `JsonValue`,
>> conversion to
>> > and from purely untyped representations (lists and maps), and factory
>> methods
>> > for building JSON documents. We apply composition consistently, e.g, a
>> > JsonString has a string, a JsonObject has a map of string to JsonValue,
>> as
>> > opposed to extension for structural JSON values.
>> >
>> > It turns out that this simple API is almost all we need for traversal.
>> It gives
>> > us an immutable representation of a document, and we can use pattern
>> matching to
>> > answer the myriad questions that will come up (Does this object have
>> key X? Does
>> > it map to a number? Is that number representable as an integer?) when
>> going
>> > from an untyped format like JSON to a more strongly typed domain model.
>> > Given a simple document like:
>> >
>> > ```
>> >    {
>> >        "name": "John?,
>> >        "age": 30
>> >    }
>> > ```
>> >
>> > we can parse and traverse the document as follows:
>> >
>> > ```
>> > JsonValue doc = Json.parse(inputString);
>> > if (doc instanceof JsonObject o
>> >    && o.members().get("name") instanceof JsonString s
>> >    && s.value() instanceof String name
>> >    && o.members().get("age") instanceof JsonNumber n
>> >    && n.toNumber() instanceof Long l && l instanceof int age) {
>> >            // use "name" and "age"
>> >        }
>> > ```
>> >
>> > Later, when the language acquires the ability to expose deconstruction
>> patterns
>> > for arbitrary interfaces (similar to today's record patterns, see
>> >
>> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns
>> ),
>> > this will be simplifiable to:
>> >
>> > ```
>> > JsonValue doc = Json.parse(inputString);
>> > if (doc instanceof JsonObject(var members)
>> >    && members.get("name") instanceof JsonString(String name)
>> >    && members.get("age") instanceof JsonNumber(int age)) {
>> >            // use "name" and "age"
>> >        }
>> > ```
>> >
>> > So, overtime, as more pattern matching features are introduced we
>> anticipate
>> > improved use of the API. This is a primary reason why the API is so
>> minimal.
>> > Convenience methods we add today, such as a method that accesses a JSON
>> > object component as say a JSON string or throws an exception, will
>> become
>> > redundant in the future.
>> >
>> > ## JSON numbers
>> >
>> > The specification of JSON number makes no explicit distinction between
>> integral
>> > and decimal numbers, nor specifies limits on the size of those numbers.
>> > This is a common source of interoperability issues when consuming JSON
>> > documents. Generally users cannot always but often do assume JSON
>> numbers are
>> > parsable, without loss of precision, to IEEE double-precision floating
>> point
>> > numbers or 32-bit signed integers.
>> >
>> > In this respect the API provides three means to operate on the JSON
>> number,
>> > giving the user full control:
>> >
>> > 1. Underlying string representation can be obtained, if preserving
>> syntactic
>> >   details such as leading or trailing zeros is important.
>> > 2. The string representation can be parsed to an instance of
>> `BigDecimal`, using
>> >   `toBigDecimal` if preserving decimal numbers is important.
>> > 3. The string representation can be parsed into an instance of `Long`,
>> `Double`,
>> >   `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this
>> method
>> >   depends on how the representation can be parsed, possibly losing
>> precision,
>> >   choosing a suitably convenient numeric type that can then be pattern
>> >   matched on.
>> >
>> > Primitive pattern matching will help as will further pattern matching
>> features
>> > enabling the user to partially match.
>> >
>> > ## Prototype implementation
>> >
>> > The prototype implementation is currently located into the JDK sandbox
>> > repository
>> > under the `json` branch, see
>> > here
>> >
>> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json
>> > The prototype API javadoc generated from the repository is also
>> available at
>> >
>> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html
>> >
>> > ### Testing and conformance
>> >
>> > The prototype implementation passes all conformance test cases but two,
>> > available
>> > on https://github.com/nst/JSONTestSuite. The two exceptions are the
>> ones which
>> > the
>> > prototype specifically prohibits, i.e, duplicated names in JSON objects
>> > (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35
>> ).
>> >
>> > ### Performance
>> >
>> > Our main focus so far has been on the API design and a functional
>> > implementation.
>> > Hence, there has been less focus on performance even though we know
>> there are a
>> > number of performance enhancements we can make eventually.
>> > We are reasonably happy with the current performance. The
>> > implementation performs well when compared to other JSON implementations
>> > parsing from string instances and traversing documents.
>> >
>> > An example of where we may choose simplicity and usability over
>> performance
>> > is the rejection of JSON documents containing objects that in turn
>> contain
>> > members
>> > with duplicate names. That may increase the cost of parsing, but
>> simplifies the
>> > user
>> > experience for the majority of cases since if we reasonably assume
>> JsonObjects
>> > are
>> > map-like, what should the user do with such members, pick one the last
>> one?
>> > merge
>> > the values? or reject?
>> >
>> > ## A JSON JEP?
>> >
>> > We plan to draft JEP when we are ready. Attentive readers will observe
>> that
>> > a JEP already exists, JEP 198: Light-Weight JSON API
>> > (https://openjdk.org/jeps/198). We will
>> > either update this JEP, or withdraw it and draft a new one.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250517/c66591c3/attachment-0001.htm>

From duke at openjdk.org  Sat May 17 06:39:55 2025
From: duke at openjdk.org (Markus KARG)
Date: Sat, 17 May 2025 06:39:55 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <Y0KfcOCu9LV1wI_2qSbwsjC-bWuZ9biwAmPrvMc9yn8=.649731e0-99e4-4ea1-9523-38d41b2a64ff@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <x1nMqw3J0aQoPyMt3WZ8YPnPFEwAebt_cnGtQYSXNSs=.6ae13f2a-5eeb-410d-9971-958526a8f16e@github.com>
 <BErvDbjWrXY7YGuIyQwR22cHeUP4knxU8MU4tw6AMN4=.c6b174ea-abdb-4b11-b6f9-0d97a03dc6ff@github.com>
 <Swr1GEuPbIhL4A273oZfYFmAlwYw3lPF2vaWhTzt4aE=.401b5bda-92db-4361-a581-579756ecf562@github.com>
 <_3Y4elzEunYP8CDAtEOAIEjROXaZhnfYm7igroc1jGI=.eda14696-2ab7-4eb5-b54b-24f37bc07898@github.com>
 <RbqVx9l3PqI3nGa04lI8LZc8q4RyriZK8KP0-sqL098=.257abdaf-af46-4148-b925-42eebb1a3666@github.com>
 <6pcsLU3w7BQmpUbZ-p53iZsOK3kVckilpiHzyOu2VK8=.10d95ba6-1259-4e90-a994-407f9c247a67@github.com>
 <-alnojXx7gvsHuZyAugz_zk_1bf_QT0PfSZMdvP_Xt8=.0791cdf3-f466-4dd0-b672-5a0f619d14d7@github.com>
 <dJ6QbcWd3g7UZrHLzDKDZpsg1JGl5przqySy6chS8xM=.8f09904b-0f74-42d9-9562-47fcb73f5dc7@github.com>
 <dwtS71dqeIYLsEVqpFl0-AMfQRX35vq0zgp
 BrzDfkw4=.0af8ec7d-614e-4098-adaa-c1ab56d1f035@github.com>
 <uvpXW26IrXksJTYg12DdLAF7i1SNHG3zlIdWKcyVEHc=.cf20aaec-bbec-40ea-8b07-086e38303553@github.com>
 <Y0KfcOCu9LV1wI_2qSbwsjC-bWuZ9biwAmPrvMc9yn8=.649731e0-99e4-4ea1-9523-38d41b2a64ff@github.com>
Message-ID: <VxrFO8Q_7zILx853rQp0JIjZnEU6uA93VJTWMYDSvq4=.823aba90-4eef-41aa-8b04-718c8c8fcf99@github.com>

On Fri, 16 May 2025 20:00:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This API is concerned with the "what" and not so much the "how."
>
> The purpose of Reader and subclasses is to normalize characters in various forms (char arrays, byte streams, char buffers, etc) into a coherent stream of characters and be able to read it incrementally.
> If the caller is going to use the entire CharSequence, as in the case of `Reader.of(cs)`, there is no reason to have a reader at all. Both String and CharSequence have more useful APIs than Reader for parsing.
> The motivation for reading all characters and reading lines came from use cases around input from sub-processes where the input is decoded from a byte stream, but that's not `Reader.of(cs).`

In many situations the programmer has no choice whether to use a reader or not, as the code he works in must fulfill a given specification (like JAX-RS), so he is getting a `Reader` *whether needed or not* -- it is not under *his* control. But as he wants to get *all* content, he likes to use this new method. Pretty valid and frequent use case in the enterprise world.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2093982275

From thomas.stuefe at gmail.com  Sat May 17 06:41:19 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sat, 17 May 2025 08:41:19 +0200
Subject: ProcessImpl: Can we obsolete the vfork mode?
In-Reply-To: <CAA-vtUxQT5pbQ+gzAeu9t5BRJ2KRWLmGGrHKFSLmxv8wZkjzOA@mail.gmail.com>
References: <CAA-vtUz19h6x4noK3zKgzjp8_Tm49bbKRsBQKz96w8N+aTs-vw@mail.gmail.com>
 <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com>
 <CAA-vtUz0PWXCs7aJO8V8ncRgUe2wKm7PBqCtt3=qj3nxy8AyKg@mail.gmail.com>
 <8c291ee4-f1c0-487e-9dca-e43567cd6466@oracle.com>
 <CAA-vtUwsqPZWSoR8a2376GnCYjE_PQeGu1bDjex0b5zzcuurrg@mail.gmail.com>
 <d871711d-a1cc-4058-9a83-3b2617296eef@oracle.com>
 <CAA-vtUxQT5pbQ+gzAeu9t5BRJ2KRWLmGGrHKFSLmxv8wZkjzOA@mail.gmail.com>
Message-ID: <CAA-vtUwTUnVZGcbaJBH-VLW85_9Lw-kGq6PM4vKD1uJG5yTF7A@mail.gmail.com>

Side note, I did not find any tests for the VFORK mode. Even the FORK mode
seems not that well covered ( we only seem to run
java/lang/ProcessBuilder/Basic.java in FORK mode)

On Fri, May 16, 2025 at 6:59?PM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> I am fine with waiting past 25, though the continued existence of this
> mode makes me apprehensive. Back at SAP I have seen real customer issues
> from these kind of problems, and we only catched those out of accident.
>
> A separate deprecation for JDK 25 may be a good first step (a warning, but
> continued acceptance, of the VFORK mode)
>
> On Fri, May 16, 2025 at 6:20?PM Joseph D. Darcy <joe.darcy at oracle.com>
> wrote:
>
>> I concur that this work is better down early in JDK 26.
>>
>> Thanks,
>>
>> -Joe
>>
>> On 5/16/2025 12:26 AM, Thomas St?fe wrote:
>>
>> Okay, moved the release version to 26.
>>
>> Could one of you (you or @Roger Riggs <roger.riggs at oracle.com> ) review
>> the CSR if you have the cycles to spare?
>>
>> https://bugs.openjdk.org/browse/JDK-8357090
>>
>> Thanks!
>>
>> On Fri, May 16, 2025 at 7:56?AM Alan Bateman <alan.bateman at oracle.com>
>> wrote:
>>
>>> On 16/05/2025 05:10, Thomas St?fe wrote:
>>>
>>>
>>>
>>>>
>>> Thank you, Alan. I will prepare a patch and a CSR.
>>>
>>> Okay, and maybe something for early in JDK 26 to avoid touching this
>>> area close to the fork for JDK 25 RDP1.
>>>
>>> -Alan
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250517/465957da/attachment.htm>

From thomas.stuefe at gmail.com  Sat May 17 06:52:44 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sat, 17 May 2025 08:52:44 +0200
Subject: ProcessImpl: Can we obsolete the vfork mode?
In-Reply-To: <CAA-vtUwTUnVZGcbaJBH-VLW85_9Lw-kGq6PM4vKD1uJG5yTF7A@mail.gmail.com>
References: <CAA-vtUz19h6x4noK3zKgzjp8_Tm49bbKRsBQKz96w8N+aTs-vw@mail.gmail.com>
 <682d5379-afaa-4cbf-842c-6af671f217b1@oracle.com>
 <CAA-vtUz0PWXCs7aJO8V8ncRgUe2wKm7PBqCtt3=qj3nxy8AyKg@mail.gmail.com>
 <8c291ee4-f1c0-487e-9dca-e43567cd6466@oracle.com>
 <CAA-vtUwsqPZWSoR8a2376GnCYjE_PQeGu1bDjex0b5zzcuurrg@mail.gmail.com>
 <d871711d-a1cc-4058-9a83-3b2617296eef@oracle.com>
 <CAA-vtUxQT5pbQ+gzAeu9t5BRJ2KRWLmGGrHKFSLmxv8wZkjzOA@mail.gmail.com>
 <CAA-vtUwTUnVZGcbaJBH-VLW85_9Lw-kGq6PM4vKD1uJG5yTF7A@mail.gmail.com>
Message-ID: <CAA-vtUybnOY9kh7b+U1wjS9=X=BnnCgMEpHmfaUL-KVDiRzLxA@mail.gmail.com>

This is the deprecation issue: https://bugs.openjdk.org/browse/JDK-8357179
Deprecation patch PR: https://github.com/openjdk/jdk/pull/25282
Deprecation CSR: https://bugs.openjdk.org/browse/JDK-8357180
Deprecation Release Note: https://bugs.openjdk.org/browse/JDK-8357181

Cheers, Thomas

On Sat, May 17, 2025 at 8:41?AM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Side note, I did not find any tests for the VFORK mode. Even the FORK mode
> seems not that well covered ( we only seem to run
> java/lang/ProcessBuilder/Basic.java in FORK mode)
>
> On Fri, May 16, 2025 at 6:59?PM Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
>> I am fine with waiting past 25, though the continued existence of this
>> mode makes me apprehensive. Back at SAP I have seen real customer issues
>> from these kind of problems, and we only catched those out of accident.
>>
>> A separate deprecation for JDK 25 may be a good first step (a warning,
>> but continued acceptance, of the VFORK mode)
>>
>> On Fri, May 16, 2025 at 6:20?PM Joseph D. Darcy <joe.darcy at oracle.com>
>> wrote:
>>
>>> I concur that this work is better down early in JDK 26.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> On 5/16/2025 12:26 AM, Thomas St?fe wrote:
>>>
>>> Okay, moved the release version to 26.
>>>
>>> Could one of you (you or @Roger Riggs <roger.riggs at oracle.com> ) review
>>> the CSR if you have the cycles to spare?
>>>
>>> https://bugs.openjdk.org/browse/JDK-8357090
>>>
>>> Thanks!
>>>
>>> On Fri, May 16, 2025 at 7:56?AM Alan Bateman <alan.bateman at oracle.com>
>>> wrote:
>>>
>>>> On 16/05/2025 05:10, Thomas St?fe wrote:
>>>>
>>>>
>>>>
>>>>>
>>>> Thank you, Alan. I will prepare a patch and a CSR.
>>>>
>>>> Okay, and maybe something for early in JDK 26 to avoid touching this
>>>> area close to the fork for JDK 25 RDP1.
>>>>
>>>> -Alan
>>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250517/cc6228a6/attachment-0001.htm>

From stuefe at openjdk.org  Sat May 17 06:55:02 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 17 May 2025 06:55:02 GMT
Subject: RFR: 8357179: Deprecate VFORK launch mechanism from Process
 implementation (linux)
Message-ID: <KZUCnliZBaa1PgMeT9PSEQ26BttrtNGZed2I70C0Mbc=.d66fb189-2d88-420c-a8bd-227cb2b817cb@github.com>

For the ratio behind this please see the companion CSR: https://bugs.openjdk.org/browse/JDK-8357180.

We plan to deprecate this in JDK 25 and to remove it in JDK 26.

This patch just writes a deprecation message to stderr:


08:46:38 thomas at starfish java -Djdk.lang.Process.launchMechanism=VFORK SimpleSpawn ls
VFORK MODE DEPRECATED
The VFORK launch mechanism has been deprecated for being dangerous.
It will be removed in a future java version. Either remove the
jdk.lang.Process.launchMechanism property (preferred) or use FORK mode
instead (-Djdk.lang.Process.launchMechanism=FORK).
...

-------------

Commit messages:
 - deprecate-vfork

Changes: https://git.openjdk.org/jdk/pull/25282/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25282&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357179
  Stats: 14 lines in 1 file changed: 10 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25282.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25282/head:pull/25282

PR: https://git.openjdk.org/jdk/pull/25282

From ethan at mccue.dev  Sat May 17 08:29:36 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Sat, 17 May 2025 10:29:36 +0200
Subject: Towards a JSON API for the JDK
In-Reply-To: <3c9d37e7-fb38-40cb-ab95-5d7ad3e56019.shaojin.wensj@alibaba-inc.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <f3cc90ef-25f3-41e3-a82b-0bac063c5733@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <3c9d37e7-fb38-40cb-ab95-5d7ad3e56019.shaojin.wensj@alibaba-inc.com>
Message-ID: <CA+NR86jH9PAg0AQhDNdg25+pciFWMbNir5tvt4qLFt_JKk8Y-w@mail.gmail.com>

I think we should pull apart those concerns a little:

I am of the opinion that the API is more important at this stage than the
actual implementation, save for the places where having an API of a
particular shape mandates implementation choices.

> The JsonNull/JsonNumber/JsonString/JsonValue here should not be designed
like this, which will cause trouble to users and affect performance.

Can you go very deep on why you think this is the case? There are
properties of this today (i.e. indirection due to a lack of value classes)
which can be resolved in time, but others which are intrinsic.

> For simple types of JSON, you can directly use Java type mapping, such as:
> null -> null
> string -> string
> number -> integer/long/bigint/float/double, select the mapping type
through configuration, or according to a rule we set.

So that is what toUntyped provides in this draft - having a pass-through
with the explicit hierarchy. Can you also elaborate on the use cases you
have seen for the "direct Java type mapping?" What APIs expect these
generic structures?



On Fri, May 16, 2025 at 11:42?PM wenshao <shaojin.wensj at alibaba-inc.com>
wrote:

> As the author of a popular json library (fastjson/fastjson2), I think the
> current design is not good, not easy to use, and the performance is not
> good.
> The JsonNull/JsonNumber/JsonString/JsonValue here should not be designed
> like this, which will cause trouble to users and affect performance.
>
> For simple types of JSON, you can directly use Java type mapping, such as:
> null -> null
> string -> string
> number -> integer/long/bigint/float/double, select the mapping type
> through configuration, or according to a rule we set.
>
>
> Array and Object types should also support more flexible mapping:
> object -> JsonObject or Map (HashMap/LinkedHashMap/ConcurrentHashMap...)
> array -> JsonArray or List(ArrayList/LinkedList/...) or typed-array
>
>
> Lazy parsing should not be used because it will degrade performance. If we
> need to support partial parsing, we can provide a skip api, and later we
> can provide a jsonpath api, or support passing in type/JsonSchema
> information and parsing according to the schema.
>
> Also, if we want better performance, both Parser and Generator should
> provide both UTF16 and UTF8 implementations.
>
> ------------------------------------------------------------------
> ????forax <forax at univ-mlv.fr>
> ?????2025?5?17?(??) 02:43
> ????Brian Goetz<brian.goetz at oracle.com>
> ? ??Paul Sandoz<paul.sandoz at oracle.com>; "core-libs-dev"<
> core-libs-dev at openjdk.org>
> ? ??Re: Towards a JSON API for the JDK
>
>
>
> ------------------------------
> *From: *"Brian Goetz" <brian.goetz at oracle.com>
> *To: *"Remi Forax" <forax at univ-mlv.fr>
> *Cc: *"Paul Sandoz" <paul.sandoz at oracle.com>, "core-libs-dev" <
> core-libs-dev at openjdk.org>
> *Sent: *Friday, May 16, 2025 7:46:09 PM
> *Subject: *Re: Towards a JSON API for the JDK
> If you read the implementation, you'll see that significant laziness is
> indeed possible for JsonObject and JsonArray, even while doing eager
> validation.  (Of course, one can shift the balance to achieve various other
> tradeoffs.)
>
> Reading the implementation is on my TODO list :)
>
> R?mi
>
>
>
> On 5/16/2025 10:35 AM, forax at univ-mlv.fr wrote:
>
> ----- Original Message -----
>
> From: "Brian Goetz" <brian.goetz at oracle.com> <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr> <forax at univ-mlv.fr>, "Paul Sandoz" <paul.sandoz at oracle.com> <paul.sandoz at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org>
> Sent: Friday, May 16, 2025 2:53:18 PM
> Subject: Re: Towards a JSON API for the JDK
>
> On 5/15/2025 5:27 PM, Remi Forax wrote:
>
> It's not clear to me why JsonArray (for example) has to be an interface instead
> of a record ?
>
> Oh, you know the answer to this.  A record limits us to a single
> implementation with a rigid representation.  Behind an interface, we can
> hide lazy parsing and inflation, wrapping other representations to
> reduce copies, etc.
>
> First, let me refine the question.
> There are only 4 kinds of JSON values that benefit from having different representations, object, array, string and number.
> For object and array, both takes an interface as parameter (Map or List) so JsonArray and JSonObject do not need to be themselves interfaces.
>
> So the only values where it may be worth to be modeled using an interface are JsonString and JsonNumber, because as you said, you can do "lazy" parsing.
>
> But delaying the parsing of the content has the side effect that even if Json.parse() did not throw an exception, it does not mean that the JSON text is valid, an exception may be thrown later.
>
> Now, for me, this library is more about being simple and safe than fast.
> If you agree with that, delaying the parsing is not a good idea, thus JSON values should be modeled using records and not interfaces.
>
> regards,
> R?mi
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250517/6fc3cae4/attachment-0001.htm>

From duke at openjdk.org  Sat May 17 11:28:51 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 17 May 2025 11:28:51 GMT
Subject: RFR: 8077587: BigInteger Roots [v15]
In-Reply-To: <V4he0DJLrCSGDVnq5JmOWXh4OcEIwlUUH7R-vLno3VA=.3ba1b7e6-237d-48bf-9d2d-88b0bf830083@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <NepVSdYvhMG501_Fjefgk_ezwqK3FT2rOfIfcKiQ8O4=.1b994e30-acd2-488c-b876-ed7b95d3c4bb@github.com>
 <V4he0DJLrCSGDVnq5JmOWXh4OcEIwlUUH7R-vLno3VA=.3ba1b7e6-237d-48bf-9d2d-88b0bf830083@github.com>
Message-ID: <8id1JAg7v3hZfZgSn2aRRA_V-mnpgMWrHD8xhwb7qMM=.f31152a1-23ac-43a5-b26c-21a5f53a1272@github.com>

On Wed, 14 May 2025 18:48:50 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "Use type long for bitLength instead of int"
>>   
>>   This reverts commit c8e1b8159206d9fb5532df7ccdf98abcab888f2c.
>
> The [Rampdown Phase One](https://openjdk.org/projects/jdk/25/) for JDK 25 is about 3 weeks from now.
> 
> I think it's a bit too late for API additions to be approved in due time. And even if we could rush this work for 25, it makes little sense to have this in 25 and the future one in 26. IMO, they should be released together. So this and the followup PR for `BigDecimal` will probably be integrated only in 26.
> 
> In other words, take your time ;-)

@rgiulietti Regarding the tests for _n_-th root, the tests for `sqrt()` and `pow()` could be extended in order to test also `nthRoot()`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2888313569

From ethan at mccue.dev  Sat May 17 11:37:28 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Sat, 17 May 2025 13:37:28 +0200
Subject: Towards a JSON API for the JDK
In-Reply-To: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
Message-ID: <CA+NR86g8FRfZqv9FCF-pHh3JM9Vcin=A0q3_YWkwxQZaM_GpTQ@mail.gmail.com>

I think it's worth noting that the way you used the prospective API in your
ONNX code is not representative of how the API would generally be used in a
jdk-only scenario. Custom making a general transformation from JsonValue ->
Record is outside the ken of i'd say most. I'd be interested in an
experience report of using it straight up.

On Thu, May 15, 2025 at 10:31?PM Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
>
> We would like to share with you our thoughts and plans towards a JSON API
> for the JDK.
> Please see the document below.
>
> -
>
> We have had the pleasure of using a clone of this API in some experiments
> we are conducting with
> ONNX and code reflection [1]. Using the API we were able to quickly write
> code to ingest and convert
> a JSON document representing ONNX operation schema into instances of
> records modeling the schema
> (see here [2]).
>
> The overall out-of-box experience with such a minimal "batteries included?
> API has so far been positive.
>
> Thanks,
> Paul.
>
> [1] https://openjdk.org/projects/babylon/
> [2]
> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87
>
> # Towards a JSON API for the JDK
>
> One of the most common requests for the JDK is an API for parsing and
> generating
> JSON. While JSON originated as a text-based serialization format for JSON
> objects ("JSON" stands for "JavaScript Object Notation"), because of its
> simple
> and flexible syntax, it eventually found use outside the JavaScript
> ecosystem as
> a general data interchange format, such as framework configuration files
> and web
> service requests/response formats.
>
> While the JDK cannot, and should not, provide libraries for every
> conceivable
> file format or protocol, the JDK philosophy is one of "batteries included",
> which is to say we should be able to write basic programs that use common
> protocols such as HTTP, without having to appeal to third party libraries.
> The Java ecosystem already has plenty of JSON libraries, so inclusion in
> the JDK is largely meant to be a convenience, rather than needing to be
> the "one
> true" JSON library to meet the needs of all users. Users with specific
> needs
> are always free to select one of the existing third-party libraries.
>
> ## Goals and requirements
>
> Our primary goal is that the library be simple to use for parsing,
> traversing,
> and generating conformant JSON documents. Advanced features, such as data
> binding or path-based traversal should be possible to implement as layered
> features, but for simplicity are not included in the core API. We adopt a
> goal
> that the performance should be "good enough", but where performance
> considerations conflict with simplicity and usability, we will choose in
> favor
> of the latter.
>
> ## API design approach
>
> The description of JSON at `https:://json.org` describes a JSON document
> using
> the familiar "railroad diagram":
> ![image](https://www.json.org/img/value.png)
>
> This diagram describes an algebraic data type (a sum of products), which we
> model directly with a set of Java interfaces:
>
> ```
> interface JsonValue { }
> interface JsonArray extends JsonValue { List<JsonValue> values(); }
> interface JsonObject extends JsonValue { Map<String, JsonValue> members();
> }
> interface JsonNumber extends JsonValue { Number toNumber(); }
> interface JsonString extends JsonValue { String value(); }
> interface JsonBoolean extends JsonValue  { boolean value(); }
> interface JsonNull extends JsonValue { }
> ```
>
> These interfaces have (hidden) companion implementation classes that admit
> greater flexibility of implementation than modeling them directly with
> records would permit.
> Further, these interfaces are unsealed. We compromise on the sealed sum of
> products to enable
> alternative implementations, for example to support alternative formats
> that
> encode the same information in a JSON document but in a more efficient
> form than
> text.
>
> The API has static methods for parsing strings into a `JsonValue`,
> conversion to
> and from purely untyped representations (lists and maps), and factory
> methods
> for building JSON documents. We apply composition consistently, e.g, a
> JsonString has a string, a JsonObject has a map of string to JsonValue, as
> opposed to extension for structural JSON values.
>
> It turns out that this simple API is almost all we need for traversal. It
> gives
> us an immutable representation of a document, and we can use pattern
> matching to
> answer the myriad questions that will come up (Does this object have key
> X? Does
> it map to a number? Is that number representable as an integer?) when going
> from an untyped format like JSON to a more strongly typed domain model.
> Given a simple document like:
>
> ```
>     {
>         "name": "John?,
>         "age": 30
>     }
> ```
>
> we can parse and traverse the document as follows:
>
> ```
> JsonValue doc = Json.parse(inputString);
> if (doc instanceof JsonObject o
>     && o.members().get("name") instanceof JsonString s
>     && s.value() instanceof String name
>     && o.members().get("age") instanceof JsonNumber n
>     && n.toNumber() instanceof Long l && l instanceof int age) {
>             // use "name" and "age"
>         }
> ```
>
> Later, when the language acquires the ability to expose deconstruction
> patterns
> for arbitrary interfaces (similar to today's record patterns, see
>
> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns
> ),
> this will be simplifiable to:
>
> ```
> JsonValue doc = Json.parse(inputString);
> if (doc instanceof JsonObject(var members)
>     && members.get("name") instanceof JsonString(String name)
>     && members.get("age") instanceof JsonNumber(int age)) {
>             // use "name" and "age"
>         }
> ```
>
> So, overtime, as more pattern matching features are introduced we
> anticipate
> improved use of the API. This is a primary reason why the API is so
> minimal.
> Convenience methods we add today, such as a method that accesses a JSON
> object component as say a JSON string or throws an exception, will become
> redundant in the future.
>
> ## JSON numbers
>
> The specification of JSON number makes no explicit distinction between
> integral
> and decimal numbers, nor specifies limits on the size of those numbers.
> This is a common source of interoperability issues when consuming JSON
> documents. Generally users cannot always but often do assume JSON numbers
> are
> parsable, without loss of precision, to IEEE double-precision floating
> point
> numbers or 32-bit signed integers.
>
> In this respect the API provides three means to operate on the JSON number,
> giving the user full control:
>
> 1. Underlying string representation can be obtained, if preserving
> syntactic
>    details such as leading or trailing zeros is important.
> 2. The string representation can be parsed to an instance of `BigDecimal`,
> using
>    `toBigDecimal` if preserving decimal numbers is important.
> 3. The string representation can be parsed into an instance of `Long`,
> `Double`,
>    `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this
> method
>    depends on how the representation can be parsed, possibly losing
> precision,
>    choosing a suitably convenient numeric type that can then be pattern
>    matched on.
>
> Primitive pattern matching will help as will further pattern matching
> features
> enabling the user to partially match.
>
> ## Prototype implementation
>
> The prototype implementation is currently located into the JDK sandbox
> repository
> under the `json` branch, see
> here
> https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json
> The prototype API javadoc generated from the repository is also available
> at
>
> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html
>
> ### Testing and conformance
>
> The prototype implementation passes all conformance test cases but two,
> available
> on https://github.com/nst/JSONTestSuite. The two exceptions are the ones
> which the
> prototype specifically prohibits, i.e, duplicated names in JSON objects
> (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35).
>
> ### Performance
>
> Our main focus so far has been on the API design and a functional
> implementation.
> Hence, there has been less focus on performance even though we know there
> are a
> number of performance enhancements we can make eventually.
> We are reasonably happy with the current performance. The
> implementation performs well when compared to other JSON implementations
> parsing from string instances and traversing documents.
>
> An example of where we may choose simplicity and usability over performance
> is the rejection of JSON documents containing objects that in turn contain
> members
> with duplicate names. That may increase the cost of parsing, but
> simplifies the user
> experience for the majority of cases since if we reasonably assume
> JsonObjects are
> map-like, what should the user do with such members, pick one the last
> one? merge
> the values? or reject?
>
> ## A JSON JEP?
>
> We plan to draft JEP when we are ready. Attentive readers will observe that
> a JEP already exists, JEP 198: Light-Weight JSON API (
> https://openjdk.org/jeps/198). We will
> either update this JEP, or withdraw it and draft a new one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250517/aa482580/attachment-0001.htm>

From duke at openjdk.org  Sat May 17 13:05:50 2025
From: duke at openjdk.org (Markus KARG)
Date: Sat, 17 May 2025 13:05:50 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v4]
In-Reply-To: <Rjmq4n-QIKTcuPhiU29BsSdBWZLA2YG5S5U5mySYVMA=.6e92fd18-298e-4ce1-b78b-5e7166beaac4@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <V8ZrRweDmVS9HD5kY8TM6xIVWBfiZy8StMHs6LPO78o=.59017549-3ec8-4627-b206-a9e897045081@github.com>
 <fmTENnnls6QlNngwvE7zC-zZWbJPYb2Qo9hhLUgV9lM=.017ce3f7-d529-40ca-8290-f8567d7f1933@github.com>
 <Rjmq4n-QIKTcuPhiU29BsSdBWZLA2YG5S5U5mySYVMA=.6e92fd18-298e-4ce1-b78b-5e7166beaac4@github.com>
Message-ID: <qPQYFDXANQOSnbMHmKwIFY9RJLlAW9n6WiIHeyMa8_M=.53358927-3349-42aa-9c3d-338bba1c0935@github.com>

On Fri, 2 May 2025 07:13:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>>> ```java
>>> >         char[] ca = new char[end - off];
>>> ```
>>> 
>>> Your code here has a memory allocation, which may cause slowdown
>> 
>> This is exactly what I wanted to express with my posting.
>
>> > ```java
>> > >         char[] ca = new char[end - off];
>> > ```
>> > 
>> > 
>> >     
>> >       
>> >     
>> > 
>> >       
>> >     
>> > 
>> >     
>> >   
>> > Your code here has a memory allocation, which may cause slowdown
>> 
>> This is exactly what I wanted to express with my posting.
> 
> I agree with you that this PR can improve the performance of Reader's method ` int read(char[] cbuf, int off, int len)`, but may not help the performance of Reader::getChars.

@wenshao Why did you remove UTF16::compress from your proposal? Wasn't it providing the expected benefit?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-2888375783

From duke at openjdk.org  Sat May 17 14:39:01 2025
From: duke at openjdk.org (ExE Boss)
Date: Sat, 17 May 2025 14:39:01 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant [v2]
In-Reply-To: <fc3PZJ4V4V5SHyLJVfRYzRL6AhHiI7yJUMeM7bgoZhI=.5b31249a-b4d4-42e3-8204-fea187c1aff5@github.com>
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
 <fc3PZJ4V4V5SHyLJVfRYzRL6AhHiI7yJUMeM7bgoZhI=.5b31249a-b4d4-42e3-8204-fea187c1aff5@github.com>
Message-ID: <Jq99uq5uKM3lOpk090YEAeQORdHe4Juf8RGElb9-pUI=.7b70901f-a5cd-4398-abef-4acd04898c28@github.com>

On Mon, 24 Feb 2025 23:45:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> LF editor spins classes, this avoids the spinning overhead and should speed up non-capturing lambdas too.
>> 
>> There may need to be additional intrinsic work for MH combinator lf bytecode generation.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   We no longer load DelegateMH as we no longer rebind

Changes requested by ExE-Boss at github.com (no known OpenJDK username).

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4893:

> 4891:      * @return a constant method handle of the given type, which returns a default value of the given return type
> 4892:      * @throws NullPointerException if the argument is null
> 4893:      * @see MethodHandles#primitiveZero

`MethodHandles?.primitiveZero(?)` is?a?private internal?API.
Suggestion:

     * @see MethodHandles#zero

-------------

PR Review: https://git.openjdk.org/jdk/pull/23706#pullrequestreview-2848299662
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r2094138280

From liach at openjdk.org  Sat May 17 14:39:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 17 May 2025 14:39:01 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant [v2]
In-Reply-To: <Jq99uq5uKM3lOpk090YEAeQORdHe4Juf8RGElb9-pUI=.7b70901f-a5cd-4398-abef-4acd04898c28@github.com>
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
 <fc3PZJ4V4V5SHyLJVfRYzRL6AhHiI7yJUMeM7bgoZhI=.5b31249a-b4d4-42e3-8204-fea187c1aff5@github.com>
 <Jq99uq5uKM3lOpk090YEAeQORdHe4Juf8RGElb9-pUI=.7b70901f-a5cd-4398-abef-4acd04898c28@github.com>
Message-ID: <sF5RzCob_uPMXBbbZQS4p_9LDHRcaQtWtib9KgyskZk=.e6bd5315-e33c-47c2-9472-96006730d39c@github.com>

On Sat, 17 May 2025 14:32:43 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   We no longer load DelegateMH as we no longer rebind
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4893:
> 
>> 4891:      * @return a constant method handle of the given type, which returns a default value of the given return type
>> 4892:      * @throws NullPointerException if the argument is null
>> 4893:      * @see MethodHandles#primitiveZero
> 
> `MethodHandles?.primitiveZero(?)` is?a?private internal?API.
> Suggestion:
> 
>      * @see MethodHandles#zero

There's a general rfe for checking inaccessible links. Don't recall why thisv was even changed, most likely ide being too smart.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r2094138728

From swen at openjdk.org  Sat May 17 14:58:53 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 17 May 2025 14:58:53 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v4]
In-Reply-To: <Rjmq4n-QIKTcuPhiU29BsSdBWZLA2YG5S5U5mySYVMA=.6e92fd18-298e-4ce1-b78b-5e7166beaac4@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <V8ZrRweDmVS9HD5kY8TM6xIVWBfiZy8StMHs6LPO78o=.59017549-3ec8-4627-b206-a9e897045081@github.com>
 <fmTENnnls6QlNngwvE7zC-zZWbJPYb2Qo9hhLUgV9lM=.017ce3f7-d529-40ca-8290-f8567d7f1933@github.com>
 <Rjmq4n-QIKTcuPhiU29BsSdBWZLA2YG5S5U5mySYVMA=.6e92fd18-298e-4ce1-b78b-5e7166beaac4@github.com>
Message-ID: <wb7wr4QmVN_CiDOFzwN9b-DuGr06I-6WWitHXqD7vaM=.646a3a12-5e06-4294-b611-1f4b941bc561@github.com>

On Fri, 2 May 2025 07:13:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>>> ```java
>>> >         char[] ca = new char[end - off];
>>> ```
>>> 
>>> Your code here has a memory allocation, which may cause slowdown
>> 
>> This is exactly what I wanted to express with my posting.
>
>> > ```java
>> > >         char[] ca = new char[end - off];
>> > ```
>> > 
>> > 
>> >     
>> >       
>> >     
>> > 
>> >       
>> >     
>> > 
>> >     
>> >   
>> > Your code here has a memory allocation, which may cause slowdown
>> 
>> This is exactly what I wanted to express with my posting.
> 
> I agree with you that this PR can improve the performance of Reader's method ` int read(char[] cbuf, int off, int len)`, but may not help the performance of Reader::getChars.

> @wenshao Why did you remove UTF16::compress from your proposal? Wasn't it providing the expected benefit?

StringUTF16::compress has been added in PR #24967

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-2888440484

From markus at headcrashing.eu  Sat May 17 15:01:00 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Sat, 17 May 2025 17:01:00 +0200
Subject: RFC: 8357183: Improving efficiency of Writer::append(CharSequence)
 and Writer::append(CharSequence, int, int) / Sub Task of 8356679: Using
 CharSequence::getChars internally
In-Reply-To: <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com>
References: <f4cf0270-eb00-4c52-99a4-8e8057bb2bc9@gmx.net>
 <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com>
 <f4330452-258c-42f8-a24b-9217da839892@headcrashing.eu>
 <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com>
 <b43e53d6-eb0b-4074-80e4-ca7bc0bf64f0@headcrashing.eu>
 <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com>
Message-ID: <36b5f579-3d45-48ee-948c-a73507ca6764@headcrashing.eu>

Roger,

thank you for your comments.

Following your advice I have splitted the larger work of JDK-8356679 
into sub tasks.

I would like to start with a first PR implementing the *foundational* 
work, i. e. optimizing Writer::append for efficiency (JDK-8357183). For 
convenience, attached below is a copy of the description.

Comments Welcome!

If everybody is fine with this, I would be happy to get some +1 to 
publish the PR for JDK-8357183!

-Markus


This sub task of JDK-8356679 proposes implementation-only changes to 
java.io.Writer. No API is changed. Implementation behavior is slightly 
changed w.r.t to self-calls to non-private methods.

The target is to make the Writer::append(CharSequence) and 
Writer::append(CharSequence, int, int) methods *in the non-String* case 
be as efficient as they are already *in the String* case.

This is achived by now handling CharSequence in *the exact same* 
optimized way as String was specifically handled before. This 
generalization of the previously String-specific optimization is 
possible since Java 25, thanks to the new CharSequence::getChars(int, 
int, char[], int) bulk-read method.

Prior to the proposed change, the code was unefficient, as ontop of what 
the String-case did, the text content of other CharSequences (like 
StringBuilder and CharBuffer) had to be copied *once or multiply*, 
before it was finally processed *as* a String.

The changes in detail are:
* Extract the original implementation of Writer::write(String, int, int) 
to become a newly introduced, internal method 
Writer::implWrite(CharSequence, int, int). This allows making use of 
that exact original implementation by other methods, particularly 
CharSequence::append, but potentially also sub classes in the same 
package (for subsequent enhancement of specific Writers).
* Writer::append(CharSequence) prevents the previously implied creation 
of an intermediate String representation in the non-String case (which 
implied creating another temporary object on the heap, and duplicating 
full text content), ontop of what the String case did
* Writer::append(CharSequence, int, int), in addition to the 
optimization of the single-arg case, also prevents the previously 
implied creation of a sub sequence (which always meant to create another 
temporary object on the heap, and in many cases meant to duplicate 
partial text content).
* As a benefit, the JavaDocs of these methods can be simplified thanks 
to the reduced number of self-calls. While this changes the internal 
behavior slightly, it is finally clarifying that these JavaDoc sections 
were originally meant as explanatory notes what *the default code* does, 
but not as as mandatory specs what *subclasses* have to do.

This work is foundational to subsequent enhancements of specific 
Writers, as the new implWrite(CharSequence, int, int) method is to be 
called by them *instead* of the previously called write(String, int, 
int) method, to allow for the same efficiency optimiziation now found in 
the new default code. Due to that, no other Writers are changed in this 
first step; these Writers will follow in subsequent JBS / PRs.


Am 14.05.2025 um 15:57 schrieb Roger Riggs:
> Hi Markus,
>
> Starting out with the common case is a good idea for the first PR.
>
> I much prefer a PR with a single goal and that comes to a conclusion 
> and does not add new features or changes after the PR is submitted.
> I tend to lose interest in PRs with lots of churn, it means I have to 
> re-review the bulk of it when there is a change and may wait days to 
> let it settle down before coming back to it.
>
> I tend to think the PR was not really ready to be reviewed if simple 
> issues and corrections have to be made frequently.
> Do your own checking for typos and copyrights and simple refactoring 
> before opening the PR.
> Quality before quantity or speed.
>
> I'm fine with separate Jira issues that clearly delineate a specific 
> scope and goal.
>
> The title of this issue (8356679) doesn't identify the real goal.
> It seems to be to improve performance or memory usage, not just to use 
> a new API.
>
> These are my personal opinions about contributions and process.
>
> Regards, Roger
>
>
> On 5/14/25 6:48 AM, Markus KARG wrote:
>> Many of the modified classes derive from a common super class and 
>> share one needed common change (which is one of the points which are 
>> easy to see once you see all of those classes in a single PR, but 
>> hard to explain in plaint-text pre-PR mailing list threads), so at 
>> least those need to be discussed *together*. But to spare JBS and 
>> PRs, I can open the PR with just the first set of changes, and once 
>> we agree that this set is fine, I can push the next commit *in the 
>> same PR*. Otherwise we would need endless JBS, mailing list threads, 
>> and PRs, just to fixe a dozen internal code lines.
>>
>> Having said that, does the current state of this thread count as 
>> "reached common agreement to file a PR" or do I still have to wait 
>> until more people chime in?
>>
>> -Markus
>>
>>
>> Am 13.05.2025 um 15:10 schrieb Roger Riggs:
>>> Hi Markus,
>>>
>>> A main point was to avoid trying to do everything at once.
>>> The PR comments become hard to follow and intermingled and it takes 
>>> longer to get agreement because of the thrash in the PR.
>>>
>>> Roger
>>>
>>> On 5/13/25 5:05 AM, Markus KARG wrote:
>>>> Thank you, Roger.
>>>>
>>>> Actually the method helps in the "toString()" variants, too, as in 
>>>> some places we could *get rid* of "toString()" (which is more work 
>>>> than "just" a buffer due to the added compression complexity).
>>>>
>>>> In fact, I already took the time to rewrite *all* of them while 
>>>> waiting for the approval of this list posting. In *all* cases 
>>>> *less* buffering / copying is needed, and *less* "toString()" 
>>>> conversion (which is a copy under the hood) is needed. So if I 
>>>> would be allowed to show the code as a PR, it would be much easier 
>>>> to explain and discuss.
>>>>
>>>> A PR is the best place to discuss "how to code would change". In 
>>>> the worst case, let's drop it if we see that it is actually a bad 
>>>> thing.
>>>>
>>>> -Markus
>>>>
>>>>
>>>> Am 12.05.2025 um 20:18 schrieb Roger Riggs:
>>>>> Hi Markus,
>>>>>
>>>>> On the surface, its looks constructive.
>>>>> I suspect that many of these cases will turn into discussions 
>>>>> about the right/best/better way to buffer the characters.
>>>>> The getChars method only helps when extracting to a char array, 
>>>>> many of the current implementations create strings as the 
>>>>> intermediary. The advantage of the 1 character at a time technique 
>>>>> is not needing a (separated allocated) buffer.
>>>>> Consider taking a few at a time before launching into the whole set.
>>>>>
>>>>> $.02, Roger
>>>>>
>>>>> On 5/11/25 2:45 AM, Markus KARG wrote:
>>>>>> Dear Core Libs Team,
>>>>>>
>>>>>> I am hereby requesting comments on JDK-8356679.
>>>>>>
>>>>>> I would like to invest some time and set up a PR implementing 
>>>>>> Chen Liangs's proposal laid out in 
>>>>>> https://bugs.openjdk.org/browse/JDK-8356679. For your 
>>>>>> convenience, the text of that JBS is copied below. According to 
>>>>>> the Developer's Guide I do need to get broad agreement BEFORE 
>>>>>> filing a PR. Therefore, I kindly ask everybody to briefly show 
>>>>>> consent, so I may file a PR.
>>>>>>
>>>>>> Thanks
>>>>>> -Markus
>>>>>>
>>>>>>
>>>>>> Copy from https://bugs.openjdk.org/browse/JDK-8356679:
>>>>>>
>>>>>> Recently OpenJDK adopted the new method 
>>>>>> CharSequence::getChars(int, int, char[], int) for inclusion in 
>>>>>> Java 25. As a bulk reader method, it allows potentially improved 
>>>>>> efficiency over the previously available char-by-char reader 
>>>>>> method CharSequence::charAt(int).
>>>>>>
>>>>>> Chen Liang suggested on March 23rd on the core-lib-dev mailing 
>>>>>> list to use the new method within the internal source code of 
>>>>>> OpenJDK for the implementation of Appendables (see 
>>>>>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). 
>>>>>> The idea behind this is that the implementations might be more 
>>>>>> efficient then.
>>>>>>
>>>>>> A quick analysis of the OpenJDK source code identified (at least) 
>>>>>> the following classes which could potentially run more efficient 
>>>>>> when using CharSequence::getChars internally, thanks to bulk 
>>>>>> reading and / or prevention of internal copies / toString() 
>>>>>> conversions:
>>>>>> * java.io.Writer
>>>>>> * java.io.StringWriter
>>>>>> * java.io.PrintWriter
>>>>>> * java.io.BufferedWriter
>>>>>> * java.io.CharArrayWriter
>>>>>> * java.io.FileWriter
>>>>>> * java.io.OutputStreamWriter
>>>>>> * sun.nio.cs.StreamEncoder
>>>>>> * java.io.PrintStream
>>>>>> * java.nio.CharBuffer
>>>>>>
>>>>>> In the sense of "eat your own dog food", it makes sense to 
>>>>>> implement Chen's idea in (at least) those classes. Possibly more 
>>>>>> classes could get identified when taking a deeper look. Besides 
>>>>>> the potential efficiency improvements, it would be a good show 
>>>>>> case for the usage of the new API.
>>>>>>
>>>>>> The risk of this change should be low, as test coverage exists, 
>>>>>> and as the intended changes are solely internal to the 
>>>>>> implementation. No API will get changed. In some cases the 
>>>>>> JavaDocs will get slightly adapted where it currently exposes the 
>>>>>> actual implementation (to not lie in future).
>>>>>>
>>>>>
>>>
>

From duke at openjdk.org  Sat May 17 15:07:05 2025
From: duke at openjdk.org (Markus KARG)
Date: Sat, 17 May 2025 15:07:05 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v9]
In-Reply-To: <iJrQbiBRYwsvUoqSn8pEloR8rSPoBgC17UjuS8g08iY=.18822b98-0d34-41dc-bdb4-ddfae851fd1a@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <iJrQbiBRYwsvUoqSn8pEloR8rSPoBgC17UjuS8g08iY=.18822b98-0d34-41dc-bdb4-ddfae851fd1a@github.com>
Message-ID: <9NTR14nhT6i_PCj6UT762FRW1ozfIZgTJ7O_Nd6g-is=.71a41cd0-036f-44cc-b984-a3af9c2599c6@github.com>

On Fri, 9 May 2025 16:41:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
>> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
>> Support methods are static, designed to pass all values as arguments and return a value.
>> 
>> The value byte array is reallocated under 3 conditions:
>> - Increasing the capacity with the same encoder
>> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
>> - Inflation with the same capacity
>> 
>> Added StressSBTest to exercise public instance methods of StringBuilder.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed extraneous "the"

src/java.base/share/classes/java/lang/StringUTF16.java line 1535:

> 1533:         checkBoundsBeginEnd(i, end, value);
> 1534:         putChar(value, i, c1);
> 1535:         putChar(value, i + 1, c2);

Can someone please shed some light on this change: What is the benefit of `i + constant` over `i++`? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2094144854

From liach at openjdk.org  Sat May 17 17:09:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 17 May 2025 17:09:59 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder [v9]
In-Reply-To: <9NTR14nhT6i_PCj6UT762FRW1ozfIZgTJ7O_Nd6g-is=.71a41cd0-036f-44cc-b984-a3af9c2599c6@github.com>
References: <smBB0nyYfF12EOfy0qmgcU-bgxci370_16VuEXXG5bE=.df66a2b0-2ebe-4608-8a1b-46c0c6cba5c7@github.com>
 <iJrQbiBRYwsvUoqSn8pEloR8rSPoBgC17UjuS8g08iY=.18822b98-0d34-41dc-bdb4-ddfae851fd1a@github.com>
 <9NTR14nhT6i_PCj6UT762FRW1ozfIZgTJ7O_Nd6g-is=.71a41cd0-036f-44cc-b984-a3af9c2599c6@github.com>
Message-ID: <jKwPbBwU0HHxL42_Q-m5-D6BmXK3QefNydr3maOW8vs=.5bff0f6a-9843-4175-b6a7-13070da6b782@github.com>

On Sat, 17 May 2025 15:04:21 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed extraneous "the"
>
> src/java.base/share/classes/java/lang/StringUTF16.java line 1535:
> 
>> 1533:         checkBoundsBeginEnd(i, end, value);
>> 1534:         putChar(value, i, c1);
>> 1535:         putChar(value, i + 1, c2);
> 
> Can someone please shed some light on this change: What is the benefit of `i + constant` over `i++`? ?

i++ generates excessive store bytecodes compared to +1, +2, ... and the result bytecode size is larger, which is harmful to jit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2094169027

From cay.horstmann at gmail.com  Sun May 18 05:55:12 2025
From: cay.horstmann at gmail.com (Cay Horstmann)
Date: Sun, 18 May 2025 07:55:12 +0200
Subject: Towards a JSON API for the JDK
In-Reply-To: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
Message-ID: <52514642-e172-4096-a616-a2c9a9787552@gmail.com>

+1 for having a JSON battery included with the JDK. And for "Our primary goal is that the library be simple to use for parsing, traversing, and generating conformant JSON documents."

Generating JSON could be easier. Why not convenience methods Json.newObject and Json.newArray like in https://github.com/arkanovicz/essential-json?

Parsing with instanceof will work, but is obviously painful today, as your example shows. The simplification with deconstruction patterns is not impressive either.

JsonValue doc = Json.parse(inputString);
if (doc instanceof JsonObject(var members)
      && members.get("name") instanceof JsonString(String name)
      && members.get("age") instanceof JsonNumber(int age)) {
              // use "name" and "age"
} else throw new NoSuchArgumentException();

vs. Jackson

String name = doc.get("name").asText();
int age = doc.get("age").asInt();
...

If only there was some deconstruction magic that approximates the JavaScript code

const doc = { name: "John", age: 30 }
const { name, age } = doc

What about editing documents? With Jackson, you can mutate objects and arrays. I see the appeal of immutability, but then there needs to be a convenient transform API. Right now, making John one year older is not pretty:

var nextYearDoc = switch (doc) {
     case JsonObject(var members) if
         members.get("name") instanceof JsonString(String name)
         && members.get("age") instanceof JsonNumber(int age)) ->
             Json.fromUntyped(Map.of("name", name, "age", age + 1));
     default -> throw new NoSuchArgumentException();
}

And it gets worse if John is nested more deeply in a document.

I have worked a lot with immutable XML in Scala. One minimally needs a mechanism for recursive rewriting with a node replacement function. I am not aware of an existing library that attempts this in Java for JSON. I am sure it can be done, but it may not be trivial to do such an API well.

Cheers,

Cay

PS. Trying to create and show the youthful John gives me grief right now:

Json.fromUntyped(Map.of("name", "John", "age", 30)).toString()
|  Exception java.lang.NullPointerException: Cannot read the array length because "value" is null
|        at String.rangeCheck (String.java:307)
|        at String.<init> (String.java:303)
|        at JsonNumberImpl.toString (JsonNumberImpl.java:105)
|        at JsonObjectImpl.toString (JsonObjectImpl.java:56)
|        at (#23:1)

The JsonNumberImpl.toString method needs to handle the case that it was constructed from a Number.

Il 15/05/25 22:30, Paul Sandoz ha scritto:
> Hi,
> 
> We would like to share with you our thoughts and plans towards a JSON API for the JDK.
> Please see the document below.
> 
> -
> 
> We have had the pleasure of using a clone of this API in some experiments we are conducting with
> ONNX and code reflection [1]. Using the API we were able to quickly write code to ingest and convert
> a JSON document representing ONNX operation schema into instances of records modeling the schema
> (see here [2]).
> 
> The overall out-of-box experience with such a minimal "batteries included? API has so far been positive.
> 
> Thanks,
> Paul.
> 
> [1] https://openjdk.org/projects/babylon/
> [2] https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87
> 
> # Towards a JSON API for the JDK
> 
> One of the most common requests for the JDK is an API for parsing and generating
> JSON. While JSON originated as a text-based serialization format for JSON
> objects ("JSON" stands for "JavaScript Object Notation"), because of its simple
> and flexible syntax, it eventually found use outside the JavaScript ecosystem as
> a general data interchange format, such as framework configuration files and web
> service requests/response formats.
> 
> While the JDK cannot, and should not, provide libraries for every conceivable
> file format or protocol, the JDK philosophy is one of "batteries included",
> which is to say we should be able to write basic programs that use common
> protocols such as HTTP, without having to appeal to third party libraries.
> The Java ecosystem already has plenty of JSON libraries, so inclusion in
> the JDK is largely meant to be a convenience, rather than needing to be the "one
> true" JSON library to meet the needs of all users. Users with specific needs
> are always free to select one of the existing third-party libraries.
> 
> ## Goals and requirements
> 
> Our primary goal is that the library be simple to use for parsing, traversing,
> and generating conformant JSON documents. Advanced features, such as data
> binding or path-based traversal should be possible to implement as layered
> features, but for simplicity are not included in the core API. We adopt a goal
> that the performance should be "good enough", but where performance
> considerations conflict with simplicity and usability, we will choose in favor
> of the latter.
> 
> ## API design approach
> 
> The description of JSON at `https:://json.org` describes a JSON document using
> the familiar "railroad diagram":
> ![image](https://www.json.org/img/value.png)
> 
> This diagram describes an algebraic data type (a sum of products), which we
> model directly with a set of Java interfaces:
> 
> ```
> interface JsonValue { }
> interface JsonArray extends JsonValue { List<JsonValue> values(); }
> interface JsonObject extends JsonValue { Map<String, JsonValue> members(); }
> interface JsonNumber extends JsonValue { Number toNumber(); }
> interface JsonString extends JsonValue { String value(); }
> interface JsonBoolean extends JsonValue  { boolean value(); }
> interface JsonNull extends JsonValue { }
> ```
> 
> These interfaces have (hidden) companion implementation classes that admit
> greater flexibility of implementation than modeling them directly with records would permit.
> Further, these interfaces are unsealed. We compromise on the sealed sum of products to enable
> alternative implementations, for example to support alternative formats that
> encode the same information in a JSON document but in a more efficient form than
> text.
> 
> The API has static methods for parsing strings into a `JsonValue`, conversion to
> and from purely untyped representations (lists and maps), and factory methods
> for building JSON documents. We apply composition consistently, e.g, a
> JsonString has a string, a JsonObject has a map of string to JsonValue, as
> opposed to extension for structural JSON values.
> 
> It turns out that this simple API is almost all we need for traversal. It gives
> us an immutable representation of a document, and we can use pattern matching to
> answer the myriad questions that will come up (Does this object have key X? Does
> it map to a number? Is that number representable as an integer?) when going
> from an untyped format like JSON to a more strongly typed domain model.
> Given a simple document like:
> 
> ```
>      {
>          "name": "John?,
>          "age": 30
>      }
> ```
> 
> we can parse and traverse the document as follows:
> 
> ```
> JsonValue doc = Json.parse(inputString);
> if (doc instanceof JsonObject o
>      && o.members().get("name") instanceof JsonString s
>      && s.value() instanceof String name
>      && o.members().get("age") instanceof JsonNumber n
>      && n.toNumber() instanceof Long l && l instanceof int age) {
>              // use "name" and "age"
>          }
> ```
> 
> Later, when the language acquires the ability to expose deconstruction patterns
> for arbitrary interfaces (similar to today's record patterns, see
> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns),
> this will be simplifiable to:
> 
> ```
> JsonValue doc = Json.parse(inputString);
> if (doc instanceof JsonObject(var members)
>      && members.get("name") instanceof JsonString(String name)
>      && members.get("age") instanceof JsonNumber(int age)) {
>              // use "name" and "age"
>          }
> ```
> 
> So, overtime, as more pattern matching features are introduced we anticipate
> improved use of the API. This is a primary reason why the API is so minimal.
> Convenience methods we add today, such as a method that accesses a JSON
> object component as say a JSON string or throws an exception, will become
> redundant in the future.
> 
> ## JSON numbers
> 
> The specification of JSON number makes no explicit distinction between integral
> and decimal numbers, nor specifies limits on the size of those numbers.
> This is a common source of interoperability issues when consuming JSON
> documents. Generally users cannot always but often do assume JSON numbers are
> parsable, without loss of precision, to IEEE double-precision floating point
> numbers or 32-bit signed integers.
> 
> In this respect the API provides three means to operate on the JSON number,
> giving the user full control:
> 
> 1. Underlying string representation can be obtained, if preserving syntactic
>     details such as leading or trailing zeros is important.
> 2. The string representation can be parsed to an instance of `BigDecimal`, using
>     `toBigDecimal` if preserving decimal numbers is important.
> 3. The string representation can be parsed into an instance of `Long`, `Double`,
>     `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this method
>     depends on how the representation can be parsed, possibly losing precision,
>     choosing a suitably convenient numeric type that can then be pattern
>     matched on.
> 
> Primitive pattern matching will help as will further pattern matching features
> enabling the user to partially match.
> 
> ## Prototype implementation
> 
> The prototype implementation is currently located into the JDK sandbox
> repository
> under the `json` branch, see
> here https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json
> The prototype API javadoc generated from the repository is also available at
> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html
> 
> ### Testing and conformance
> 
> The prototype implementation passes all conformance test cases but two, available
> on https://github.com/nst/JSONTestSuite. The two exceptions are the ones which the
> prototype specifically prohibits, i.e, duplicated names in JSON objects
> (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35).
> 
> ### Performance
> 
> Our main focus so far has been on the API design and a functional implementation.
> Hence, there has been less focus on performance even though we know there are a
> number of performance enhancements we can make eventually.
> We are reasonably happy with the current performance. The
> implementation performs well when compared to other JSON implementations
> parsing from string instances and traversing documents.
> 
> An example of where we may choose simplicity and usability over performance
> is the rejection of JSON documents containing objects that in turn contain members
> with duplicate names. That may increase the cost of parsing, but simplifies the user
> experience for the majority of cases since if we reasonably assume JsonObjects are
> map-like, what should the user do with such members, pick one the last one? merge
> the values? or reject?
> 
> ## A JSON JEP?
> 
> We plan to draft JEP when we are ready. Attentive readers will observe that
> a JEP already exists, JEP 198: Light-Weight JSON API (https://openjdk.org/jeps/198). We will
> either update this JEP, or withdraw it and draft a new one.

-- 

Cay S. Horstmann | https://horstmann.com


From kbarrett at openjdk.org  Sun May 18 11:41:59 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 18 May 2025 11:41:59 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner
Message-ID: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>

This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
use java.lang.ref.Cleaner.

This change is algorithmically similar to the two previous versions:
JDK-6857566 and JDK-8156500 (current mainline). The critical function is
Bits::reserveMemory(). For both of those versions and this change, a thread
calls that function and tries to reserve some space. If it fails, then it
keeps trying until all cleaners deactivated (cleared) by prior GCs have been
cleaned. If reservation still fails, then it invokes the GC to try to
deactivate more cleaners for cleaning. After that GC it keeps trying the
reservation and waiting for cleaning, with sleeps to avoid a spin loop,
eventually either succeeding or giving up and throwing OOME.

Retaining that algorithmic approach is one of the goals of this change, since
it has been successfully in use since JDK 9 (and was originally developed and
extensively tested in JDK 8).

The key to this approach is having a way to determine that deactivated
cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
threads help the reference processor until there was no available work.
JDK-8156500 waits for the reference processor to quiesce, relying on its
immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
to do this, which is why this change rolls its own Cleaner-like mechanism from
the underlying primitives. Like JDK-6857566, this change has waiting threads
help with cleaning references. This was a potentially undesirable feature of
JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
(Though by the time of JDK-6857566 the cleaners were only used by DBB, and
became internal-only somewhere around that time as well.) That's not a concern
here, as the cleaners involved are only from DBB, and we know what they look
like.

As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
being done off the reference processing thread, as it may be expensive and
slow down enqueuing other pending references. JDK-6857566 only did some of
that, and JDK-8156500 lost that feature. This change moves all of the DBB
cleaning off of the reference processing thread. (So does PR 22165.)

Neither JDK-6857566 nor this change are completely precise. For both, a thread
may find there is no available work while other threads have work in progress.
Making this change more precise seems to cost complexity and performance.
JDK-8156500 is precise in this respect, so we're losing that. But this
imprecision wasn't known to cause problems for JDK-6857566, and there hasn't
been any evidence of problems with this change either.

During the development of JDK-6857566 it was noticed that parallel cleaning
didn't seem to have much (if any) performance benefit. That seems to be true
for this change as well.

PR 22165 uses java.lang.ref.Cleaner to manage cleaning. That class doesn't
provide a good way to detect progress toward or completion of cleaning of
deactivated cleaners from prior GCs. So PR 22165 uses a somewhat clumsy and
unreliable mechanism (the canaries) to try to do that. A proposal for such
functionality was discussed (in PR 22165) but deemed (probably rightly so) too
intrusive. An unpublished alternative was less intrusive, but still might
raise questions. The change being proposed here avoids changing or using that
class, and performs at least as well.

Another issue with PR 22165 is that if we are indeed out of memory and on our
way to OOME, each allocating thread may come up against the slow path lock in
Bits::reserveMemory, and in turn perform 9 full GCs and then OOME. That seems
kind of pathological. For JDK-6857566, JDK-8156500, and this change, an
allocating thread only performs 1 full GC before OOME.

One issue with this change is that it incorporates a near-copy of the
CleanableList class from java.lang.ref.Cleaner. Possible future work would
merge the two into a common utility. There's another potential client for
this: java.desktop/share/classes/sun/java2d/Disposer.java. I tried using a
hashtable for this change (as with Disposer), but the CleanableList performed
significantly better.

A well-known issue with all of these approaches is -XX:+DisableExplicitGC. If
used, then the GCs to request reference processing don't happen. That will
likely lead to OOME, though the sleeps might provide an opportunity for
automatic GCs to occur, maybe sometimes dodging OOME that way.

https://mail.openjdk.org/pipermail/core-libs-dev/2013-October/021547.html
Thread for discussion of development of JDK-6857566

Testing: mach5 tier1-6

Many runs of new tests micro/org/openjdk/bench/java/nio/DirectByteBuffer{GC,Churn}
(thanks for those @shipilev), and jdk/java/nio/Buffer/DirectByteBufferAlloc
for various versions of this change.

The test java/nio/Buffer/DirectByteBufferAlloc.java can be run explicitly as a
benchmark. But the arguments suggested in that file cause the measurements to
be dominated by full GC times, swamping any other differences. Increasing the
value of `XX:MaxDirectMemorySize` from 128m to 1024m provides a more useful
comparison.

Result of running that test with `-XX:MaxDirectMemorySize=1024m`, with other
options as suggested in the file, and comparing the periodic per thread
`ms/allocation` outputs, produces results like this:

|        | this change  | PR 22165 | baseline |
| ------ | ------------ | -------- | -------- |
| avg    | 0.76165      | 1.00368  | 1.02719  |
| stddev | 0.12396      | 0.18361  | 0.27210  |
| min    | 0.54         | 0.6      | 0.59     |
| max    | 1.54         | 2.13     | 2.39     |

-------------

Commit messages:
 - copyrights
 - remove java.nio use of jdk.internal.ref.Cleaner
 - add micros from Shipilev

Changes: https://git.openjdk.org/jdk/pull/25289/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25289&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344332
  Stats: 499 lines in 9 files changed: 450 ins; 22 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/25289.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25289/head:pull/25289

PR: https://git.openjdk.org/jdk/pull/25289

From alanb at openjdk.org  Sun May 18 12:13:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 18 May 2025 12:13:59 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner
In-Reply-To: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
Message-ID: <lYLXZxlwTG0V-ujQ4LAoVSnKNVisunvAyJSTy7rEszQ=.d095c373-4722-4821-9040-2c075ebae800@github.com>

On Sun, 18 May 2025 11:35:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
> use java.lang.ref.Cleaner.
> 
> This change is algorithmically similar to the two previous versions:
> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
> Bits::reserveMemory(). For both of those versions and this change, a thread
> calls that function and tries to reserve some space. If it fails, then it
> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
> cleaned. If reservation still fails, then it invokes the GC to try to
> deactivate more cleaners for cleaning. After that GC it keeps trying the
> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
> eventually either succeeding or giving up and throwing OOME.
> 
> Retaining that algorithmic approach is one of the goals of this change, since
> it has been successfully in use since JDK 9 (and was originally developed and
> extensively tested in JDK 8).
> 
> The key to this approach is having a way to determine that deactivated
> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
> threads help the reference processor until there was no available work.
> JDK-8156500 waits for the reference processor to quiesce, relying on its
> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
> to do this, which is why this change rolls its own Cleaner-like mechanism from
> the underlying primitives. Like JDK-6857566, this change has waiting threads
> help with cleaning references. This was a potentially undesirable feature of
> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
> became internal-only somewhere around that time as well.) That's not a concern
> here, as the cleaners involved are only from DBB, and we know what they look
> like.
> 
> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
> being done off the reference processing thread, as it may be expensive and
> slow down enqueuing other pending references. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
> 
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there is no available work whil...

src/java.base/share/classes/jdk/internal/nio/Cleaner.java line 26:

> 24:  */
> 25: 
> 26: package jdk.internal.nio;

The implementation/internal classes for this area are in sun.nio (for historical reasons). Probably best to keep them together.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2094505609

From markus at headcrashing.eu  Sun May 18 15:09:43 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Sun, 18 May 2025 17:09:43 +0200
Subject: RFC: 8356679: Using CharSequence::getChars internally
In-Reply-To: <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com>
References: <f4cf0270-eb00-4c52-99a4-8e8057bb2bc9@gmx.net>
 <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com>
 <f4330452-258c-42f8-a24b-9217da839892@headcrashing.eu>
 <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com>
 <b43e53d6-eb0b-4074-80e4-ca7bc0bf64f0@headcrashing.eu>
 <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com>
Message-ID: <8b59d6d1-fcf8-4be8-93a2-8b5b434b2174@headcrashing.eu>

Roger,

thank you for your comments.

Following your advice I have splitted the larger work of JDK-8356679 
into sub tasks.

I would like to start with a first PR implementing the *foundational* 
work, i. e. optimizing Writer::append for efficiency (JDK-8357183). For 
convenience, attached below is a copy of the description.

Comments Welcome!

If everybody is fine with this, I would be happy to get some +1 to 
publish the PR for JDK-8357183!

Am 14.05.2025 um 15:57 schrieb Roger Riggs:
> Hi Markus,
>
> Starting out with the common case is a good idea for the first PR.
>
> I much prefer a PR with a single goal and that comes to a conclusion 
> and does not add new features or changes after the PR is submitted.
> I tend to lose interest in PRs with lots of churn, it means I have to 
> re-review the bulk of it when there is a change and may wait days to 
> let it settle down before coming back to it.
>
> I tend to think the PR was not really ready to be reviewed if simple 
> issues and corrections have to be made frequently.
> Do your own checking for typos and copyrights and simple refactoring 
> before opening the PR.
> Quality before quantity or speed.
>
> I'm fine with separate Jira issues that clearly delineate a specific 
> scope and goal.
>
> The title of this issue (8356679) doesn't identify the real goal.
> It seems to be to improve performance or memory usage, not just to use 
> a new API.
>
> These are my personal opinions about contributions and process.
>
> Regards, Roger
>
>
> On 5/14/25 6:48 AM, Markus KARG wrote:
>> Many of the modified classes derive from a common super class and 
>> share one needed common change (which is one of the points which are 
>> easy to see once you see all of those classes in a single PR, but 
>> hard to explain in plaint-text pre-PR mailing list threads), so at 
>> least those need to be discussed *together*. But to spare JBS and 
>> PRs, I can open the PR with just the first set of changes, and once 
>> we agree that this set is fine, I can push the next commit *in the 
>> same PR*. Otherwise we would need endless JBS, mailing list threads, 
>> and PRs, just to fixe a dozen internal code lines.
>>
>> Having said that, does the current state of this thread count as 
>> "reached common agreement to file a PR" or do I still have to wait 
>> until more people chime in?
>>
>> -Markus
>>
>>
>> Am 13.05.2025 um 15:10 schrieb Roger Riggs:
>>> Hi Markus,
>>>
>>> A main point was to avoid trying to do everything at once.
>>> The PR comments become hard to follow and intermingled and it takes 
>>> longer to get agreement because of the thrash in the PR.
>>>
>>> Roger
>>>
>>> On 5/13/25 5:05 AM, Markus KARG wrote:
>>>> Thank you, Roger.
>>>>
>>>> Actually the method helps in the "toString()" variants, too, as in 
>>>> some places we could *get rid* of "toString()" (which is more work 
>>>> than "just" a buffer due to the added compression complexity).
>>>>
>>>> In fact, I already took the time to rewrite *all* of them while 
>>>> waiting for the approval of this list posting. In *all* cases 
>>>> *less* buffering / copying is needed, and *less* "toString()" 
>>>> conversion (which is a copy under the hood) is needed. So if I 
>>>> would be allowed to show the code as a PR, it would be much easier 
>>>> to explain and discuss.
>>>>
>>>> A PR is the best place to discuss "how to code would change". In 
>>>> the worst case, let's drop it if we see that it is actually a bad 
>>>> thing.
>>>>
>>>> -Markus
>>>>
>>>>
>>>> Am 12.05.2025 um 20:18 schrieb Roger Riggs:
>>>>> Hi Markus,
>>>>>
>>>>> On the surface, its looks constructive.
>>>>> I suspect that many of these cases will turn into discussions 
>>>>> about the right/best/better way to buffer the characters.
>>>>> The getChars method only helps when extracting to a char array, 
>>>>> many of the current implementations create strings as the 
>>>>> intermediary. The advantage of the 1 character at a time technique 
>>>>> is not needing a (separated allocated) buffer.
>>>>> Consider taking a few at a time before launching into the whole set.
>>>>>
>>>>> $.02, Roger
>>>>>
>>>>> On 5/11/25 2:45 AM, Markus KARG wrote:
>>>>>> Dear Core Libs Team,
>>>>>>
>>>>>> I am hereby requesting comments on JDK-8356679.
>>>>>>
>>>>>> I would like to invest some time and set up a PR implementing 
>>>>>> Chen Liangs's proposal laid out in 
>>>>>> https://bugs.openjdk.org/browse/JDK-8356679. For your 
>>>>>> convenience, the text of that JBS is copied below. According to 
>>>>>> the Developer's Guide I do need to get broad agreement BEFORE 
>>>>>> filing a PR. Therefore, I kindly ask everybody to briefly show 
>>>>>> consent, so I may file a PR.
>>>>>>
>>>>>> Thanks
>>>>>> -Markus
>>>>>>
>>>>>>
>>>>>> Copy from https://bugs.openjdk.org/browse/JDK-8356679:
>>>>>>
>>>>>> Recently OpenJDK adopted the new method 
>>>>>> CharSequence::getChars(int, int, char[], int) for inclusion in 
>>>>>> Java 25. As a bulk reader method, it allows potentially improved 
>>>>>> efficiency over the previously available char-by-char reader 
>>>>>> method CharSequence::charAt(int).
>>>>>>
>>>>>> Chen Liang suggested on March 23rd on the core-lib-dev mailing 
>>>>>> list to use the new method within the internal source code of 
>>>>>> OpenJDK for the implementation of Appendables (see 
>>>>>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). 
>>>>>> The idea behind this is that the implementations might be more 
>>>>>> efficient then.
>>>>>>
>>>>>> A quick analysis of the OpenJDK source code identified (at least) 
>>>>>> the following classes which could potentially run more efficient 
>>>>>> when using CharSequence::getChars internally, thanks to bulk 
>>>>>> reading and / or prevention of internal copies / toString() 
>>>>>> conversions:
>>>>>> * java.io.Writer
>>>>>> * java.io.StringWriter
>>>>>> * java.io.PrintWriter
>>>>>> * java.io.BufferedWriter
>>>>>> * java.io.CharArrayWriter
>>>>>> * java.io.FileWriter
>>>>>> * java.io.OutputStreamWriter
>>>>>> * sun.nio.cs.StreamEncoder
>>>>>> * java.io.PrintStream
>>>>>> * java.nio.CharBuffer
>>>>>>
>>>>>> In the sense of "eat your own dog food", it makes sense to 
>>>>>> implement Chen's idea in (at least) those classes. Possibly more 
>>>>>> classes could get identified when taking a deeper look. Besides 
>>>>>> the potential efficiency improvements, it would be a good show 
>>>>>> case for the usage of the new API.
>>>>>>
>>>>>> The risk of this change should be low, as test coverage exists, 
>>>>>> and as the intended changes are solely internal to the 
>>>>>> implementation. No API will get changed. In some cases the 
>>>>>> JavaDocs will get slightly adapted where it currently exposes the 
>>>>>> actual implementation (to not lie in future).
>>>>>>
>>>>>
>>>
>

From markus at headcrashing.eu  Sun May 18 15:12:05 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Sun, 18 May 2025 17:12:05 +0200
Subject: RFC: 8356679: Using CharSequence::getChars internally
In-Reply-To: <8b59d6d1-fcf8-4be8-93a2-8b5b434b2174@headcrashing.eu>
References: <f4cf0270-eb00-4c52-99a4-8e8057bb2bc9@gmx.net>
 <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com>
 <f4330452-258c-42f8-a24b-9217da839892@headcrashing.eu>
 <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com>
 <b43e53d6-eb0b-4074-80e4-ca7bc0bf64f0@headcrashing.eu>
 <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com>
 <8b59d6d1-fcf8-4be8-93a2-8b5b434b2174@headcrashing.eu>
Message-ID: <01ed672c-f974-48ae-8f50-7d2bb9e1e8f5@headcrashing.eu>

Sorry, the posting below was cross-posted by accident.

-Markus


Am 18.05.2025 um 17:09 schrieb Markus KARG:
> Roger,
>
> thank you for your comments.
>
> Following your advice I have splitted the larger work of JDK-8356679 
> into sub tasks.
>
> I would like to start with a first PR implementing the *foundational* 
> work, i. e. optimizing Writer::append for efficiency (JDK-8357183). 
> For convenience, attached below is a copy of the description.
>
> Comments Welcome!
>
> If everybody is fine with this, I would be happy to get some +1 to 
> publish the PR for JDK-8357183!
>
> Am 14.05.2025 um 15:57 schrieb Roger Riggs:
>> Hi Markus,
>>
>> Starting out with the common case is a good idea for the first PR.
>>
>> I much prefer a PR with a single goal and that comes to a conclusion 
>> and does not add new features or changes after the PR is submitted.
>> I tend to lose interest in PRs with lots of churn, it means I have to 
>> re-review the bulk of it when there is a change and may wait days to 
>> let it settle down before coming back to it.
>>
>> I tend to think the PR was not really ready to be reviewed if simple 
>> issues and corrections have to be made frequently.
>> Do your own checking for typos and copyrights and simple refactoring 
>> before opening the PR.
>> Quality before quantity or speed.
>>
>> I'm fine with separate Jira issues that clearly delineate a specific 
>> scope and goal.
>>
>> The title of this issue (8356679) doesn't identify the real goal.
>> It seems to be to improve performance or memory usage, not just to 
>> use a new API.
>>
>> These are my personal opinions about contributions and process.
>>
>> Regards, Roger
>>
>>
>> On 5/14/25 6:48 AM, Markus KARG wrote:
>>> Many of the modified classes derive from a common super class and 
>>> share one needed common change (which is one of the points which are 
>>> easy to see once you see all of those classes in a single PR, but 
>>> hard to explain in plaint-text pre-PR mailing list threads), so at 
>>> least those need to be discussed *together*. But to spare JBS and 
>>> PRs, I can open the PR with just the first set of changes, and once 
>>> we agree that this set is fine, I can push the next commit *in the 
>>> same PR*. Otherwise we would need endless JBS, mailing list threads, 
>>> and PRs, just to fixe a dozen internal code lines.
>>>
>>> Having said that, does the current state of this thread count as 
>>> "reached common agreement to file a PR" or do I still have to wait 
>>> until more people chime in?
>>>
>>> -Markus
>>>
>>>
>>> Am 13.05.2025 um 15:10 schrieb Roger Riggs:
>>>> Hi Markus,
>>>>
>>>> A main point was to avoid trying to do everything at once.
>>>> The PR comments become hard to follow and intermingled and it takes 
>>>> longer to get agreement because of the thrash in the PR.
>>>>
>>>> Roger
>>>>
>>>> On 5/13/25 5:05 AM, Markus KARG wrote:
>>>>> Thank you, Roger.
>>>>>
>>>>> Actually the method helps in the "toString()" variants, too, as in 
>>>>> some places we could *get rid* of "toString()" (which is more work 
>>>>> than "just" a buffer due to the added compression complexity).
>>>>>
>>>>> In fact, I already took the time to rewrite *all* of them while 
>>>>> waiting for the approval of this list posting. In *all* cases 
>>>>> *less* buffering / copying is needed, and *less* "toString()" 
>>>>> conversion (which is a copy under the hood) is needed. So if I 
>>>>> would be allowed to show the code as a PR, it would be much easier 
>>>>> to explain and discuss.
>>>>>
>>>>> A PR is the best place to discuss "how to code would change". In 
>>>>> the worst case, let's drop it if we see that it is actually a bad 
>>>>> thing.
>>>>>
>>>>> -Markus
>>>>>
>>>>>
>>>>> Am 12.05.2025 um 20:18 schrieb Roger Riggs:
>>>>>> Hi Markus,
>>>>>>
>>>>>> On the surface, its looks constructive.
>>>>>> I suspect that many of these cases will turn into discussions 
>>>>>> about the right/best/better way to buffer the characters.
>>>>>> The getChars method only helps when extracting to a char array, 
>>>>>> many of the current implementations create strings as the 
>>>>>> intermediary. The advantage of the 1 character at a time 
>>>>>> technique is not needing a (separated allocated) buffer.
>>>>>> Consider taking a few at a time before launching into the whole set.
>>>>>>
>>>>>> $.02, Roger
>>>>>>
>>>>>> On 5/11/25 2:45 AM, Markus KARG wrote:
>>>>>>> Dear Core Libs Team,
>>>>>>>
>>>>>>> I am hereby requesting comments on JDK-8356679.
>>>>>>>
>>>>>>> I would like to invest some time and set up a PR implementing 
>>>>>>> Chen Liangs's proposal laid out in 
>>>>>>> https://bugs.openjdk.org/browse/JDK-8356679. For your 
>>>>>>> convenience, the text of that JBS is copied below. According to 
>>>>>>> the Developer's Guide I do need to get broad agreement BEFORE 
>>>>>>> filing a PR. Therefore, I kindly ask everybody to briefly show 
>>>>>>> consent, so I may file a PR.
>>>>>>>
>>>>>>> Thanks
>>>>>>> -Markus
>>>>>>>
>>>>>>>
>>>>>>> Copy from https://bugs.openjdk.org/browse/JDK-8356679:
>>>>>>>
>>>>>>> Recently OpenJDK adopted the new method 
>>>>>>> CharSequence::getChars(int, int, char[], int) for inclusion in 
>>>>>>> Java 25. As a bulk reader method, it allows potentially improved 
>>>>>>> efficiency over the previously available char-by-char reader 
>>>>>>> method CharSequence::charAt(int).
>>>>>>>
>>>>>>> Chen Liang suggested on March 23rd on the core-lib-dev mailing 
>>>>>>> list to use the new method within the internal source code of 
>>>>>>> OpenJDK for the implementation of Appendables (see 
>>>>>>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html). 
>>>>>>> The idea behind this is that the implementations might be more 
>>>>>>> efficient then.
>>>>>>>
>>>>>>> A quick analysis of the OpenJDK source code identified (at 
>>>>>>> least) the following classes which could potentially run more 
>>>>>>> efficient when using CharSequence::getChars internally, thanks 
>>>>>>> to bulk reading and / or prevention of internal copies / 
>>>>>>> toString() conversions:
>>>>>>> * java.io.Writer
>>>>>>> * java.io.StringWriter
>>>>>>> * java.io.PrintWriter
>>>>>>> * java.io.BufferedWriter
>>>>>>> * java.io.CharArrayWriter
>>>>>>> * java.io.FileWriter
>>>>>>> * java.io.OutputStreamWriter
>>>>>>> * sun.nio.cs.StreamEncoder
>>>>>>> * java.io.PrintStream
>>>>>>> * java.nio.CharBuffer
>>>>>>>
>>>>>>> In the sense of "eat your own dog food", it makes sense to 
>>>>>>> implement Chen's idea in (at least) those classes. Possibly more 
>>>>>>> classes could get identified when taking a deeper look. Besides 
>>>>>>> the potential efficiency improvements, it would be a good show 
>>>>>>> case for the usage of the new API.
>>>>>>>
>>>>>>> The risk of this change should be low, as test coverage exists, 
>>>>>>> and as the intended changes are solely internal to the 
>>>>>>> implementation. No API will get changed. In some cases the 
>>>>>>> JavaDocs will get slightly adapted where it currently exposes 
>>>>>>> the actual implementation (to not lie in future).
>>>>>>>
>>>>>>
>>>>
>>

From shaojin.wensj at alibaba-inc.com  Sun May 18 15:51:15 2025
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Sun, 18 May 2025 23:51:15 +0800
Subject: =?UTF-8?B?QzIgaW5saW5pbmcgZmFpbGVkIGJlY2F1c2UgdGhlIFN0cmluZyBjb25zdHJ1Y3RvciBpcyB0?=
 =?UTF-8?B?b28gbGFyZ2U=?=
Message-ID: <8ff93fce-71d1-492d-ad8b-375d4fe4cf56.shaojin.wensj@alibaba-inc.com>

Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline.
The following is the output information of PrintInlining:
```
 @ 9 java.lang.String::<init> (12 bytes) inline (hot)
!m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot)
! @ 8 java.lang.String::<init> (852 bytes) failed to inline: hot method too big
```
In Java code, the big method that cannot be inlined is the following constructor
```java
String(Charset charset, byte[] bytes, int offset, int length) {}
```
This is an important method that is called frequently. Breaking it into small methods does not require changing the code logic and is easy to accomplish. 
It is the easiest gain with minimal impact. I suggest solving this problem in JDK 25.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250518/95eff098/attachment.htm>

From darcy at openjdk.org  Sun May 18 18:20:51 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 18 May 2025 18:20:51 GMT
Subject: RFR: 8357178: Simplify Class::componentType
In-Reply-To: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com>
References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com>
Message-ID: <qu6L562rjh0PbjZsNVcZtCgATWM79ieGPNm_Mpvw_ow=.7e1be13b-6ab3-41a2-b53c-da5f3bc63c23@github.com>

On Sat, 17 May 2025 02:15:42 GMT, Chen Liang <liach at openjdk.org> wrote:

> `isArray` and null return is now redundant when `componentType` is changed to an explicit field.

src/java.base/share/classes/java/lang/Class.java line 3985:

> 3983:     @Override
> 3984:     public Class<?> componentType() {
> 3985:         return componentType;

Did you consider calling getComponentType(), which already returns the field?

Are there regression tests for Class::componentType()/Class::getComponentType() somewhere? I didn't see them in the obvious test/jdk/java/lang/Class directory.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25280#discussion_r2094593495

From forax at univ-mlv.fr  Sun May 18 19:29:47 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 18 May 2025 21:29:47 +0200 (CEST)
Subject: C2 inlining failed because the String constructor is too large
In-Reply-To: <8ff93fce-71d1-492d-ad8b-375d4fe4cf56.shaojin.wensj@alibaba-inc.com>
References: <8ff93fce-71d1-492d-ad8b-375d4fe4cf56.shaojin.wensj@alibaba-inc.com>
Message-ID: <1447913636.268929756.1747596587470.JavaMail.zimbra@univ-eiffel.fr>

It's perhaps easier to just add an annotation @ForceInlining. 

regards, 
R?mi 

> From: "wenshao" <shaojin.wensj at alibaba-inc.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Sunday, May 18, 2025 5:51:15 PM
> Subject: C2 inlining failed because the String constructor is too large

> Through JVM Option +PrintInlining, we found that String has a constructor
> codeSize of 852, which is too large. This caused failed to inline.

> The following is the output information of PrintInlining:
> ```
> @ 9 java.lang.String::<init> (12 bytes) inline (hot)
> !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes) inline (hot)
> ! @ 8 java.lang.String::<init> (852 bytes) failed to inline: hot method too big
> ```

> In Java code, the big method that cannot be inlined is the following constructor

> ```java
> String(Charset charset, byte[] bytes, int offset, int length) {}
> ```

> This is an important method that is called frequently. Breaking it into small
> methods does not require changing the code logic and is easy to accomplish.

> It is the easiest gain with minimal impact. I suggest solving this problem in
> JDK 25.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250518/31208fb6/attachment-0001.htm>

From chen.l.liang at oracle.com  Sun May 18 20:44:46 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sun, 18 May 2025 20:44:46 +0000
Subject: C2 inlining failed because the String constructor is too large
In-Reply-To: <8ff93fce-71d1-492d-ad8b-375d4fe4cf56.shaojin.wensj@alibaba-inc.com>
References: <8ff93fce-71d1-492d-ad8b-375d4fe4cf56.shaojin.wensj@alibaba-inc.com>
Message-ID: <CH3PR10MB767713FDFEB46ADD8A1D0BAAA29DA@CH3PR10MB7677.namprd10.prod.outlook.com>

This sounds like a very interesting proposal. If we can split up the constructor, we might be able to merge the two separate yes replacement (constructor) and no replacement (NoRepl) implementations into one down the road.

I saw the PR https://github.com/openjdk/jdk/pull/25290, and from the diff (when Hide Whitespace is chosen), I see the change does bring much more consistency.

Chen
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of wenshao <shaojin.wensj at alibaba-inc.com>
Sent: Sunday, May 18, 2025 10:51 AM
To: core-libs-dev <core-libs-dev at openjdk.org>
Subject: C2 inlining failed because the String constructor is too large

Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline.

The following is the output information of PrintInlining:
```
                @ 9   java.lang.String::<init> (12 bytes)   inline (hot)
!m                 @ 1   java.nio.charset.Charset::defaultCharset (52 bytes)   inline (hot)
!                  @ 8   java.lang.String::<init> (852 bytes)   failed to inline: hot method too big
```

In Java code, the big method that cannot be inlined is the following constructor

```java
String(Charset charset, byte[] bytes, int offset, int length) {}
```

This is an important method that is called frequently. Breaking it into small methods does not require changing the code logic and is easy to accomplish.

It is the easiest gain with minimal impact. I suggest solving this problem in JDK 25.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250518/19ecbd53/attachment.htm>

From chen.l.liang at oracle.com  Sun May 18 20:50:06 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sun, 18 May 2025 20:50:06 +0000
Subject: RFC: 8356679: Using CharSequence::getChars internally
In-Reply-To: <8b59d6d1-fcf8-4be8-93a2-8b5b434b2174@headcrashing.eu>
References: <f4cf0270-eb00-4c52-99a4-8e8057bb2bc9@gmx.net>
 <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com>
 <f4330452-258c-42f8-a24b-9217da839892@headcrashing.eu>
 <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com>
 <b43e53d6-eb0b-4074-80e4-ca7bc0bf64f0@headcrashing.eu>
 <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com>
 <8b59d6d1-fcf8-4be8-93a2-8b5b434b2174@headcrashing.eu>
Message-ID: <SJ2PR10MB766968186EE02189D1D9039DA29DA@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Markus,
I think you can submit a draft PR - while some people here like Alan Bateman use draft PRs to indicate "not ready for any review" and discussions are not forwarded to the mailing lists, they are still very useful for looking at the change set.

Note that we are a few short weeks from RDP1 of 25 - while I also wish improvements can be integrated into the JDK, there is no guarantee that they will make 25, and we shouldn't rush changes in order to catch up with a release train.

Regards, Chen
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Markus KARG <markus at headcrashing.eu>
Sent: Sunday, May 18, 2025 10:09 AM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: RFC: 8356679: Using CharSequence::getChars internally

Roger,

thank you for your comments.

Following your advice I have splitted the larger work of JDK-8356679
into sub tasks.

I would like to start with a first PR implementing the *foundational*
work, i. e. optimizing Writer::append for efficiency (JDK-8357183). For
convenience, attached below is a copy of the description.

Comments Welcome!

If everybody is fine with this, I would be happy to get some +1 to
publish the PR for JDK-8357183!

Am 14.05.2025 um 15:57 schrieb Roger Riggs:
> Hi Markus,
>
> Starting out with the common case is a good idea for the first PR.
>
> I much prefer a PR with a single goal and that comes to a conclusion
> and does not add new features or changes after the PR is submitted.
> I tend to lose interest in PRs with lots of churn, it means I have to
> re-review the bulk of it when there is a change and may wait days to
> let it settle down before coming back to it.
>
> I tend to think the PR was not really ready to be reviewed if simple
> issues and corrections have to be made frequently.
> Do your own checking for typos and copyrights and simple refactoring
> before opening the PR.
> Quality before quantity or speed.
>
> I'm fine with separate Jira issues that clearly delineate a specific
> scope and goal.
>
> The title of this issue (8356679) doesn't identify the real goal.
> It seems to be to improve performance or memory usage, not just to use
> a new API.
>
> These are my personal opinions about contributions and process.
>
> Regards, Roger
>
>
> On 5/14/25 6:48 AM, Markus KARG wrote:
>> Many of the modified classes derive from a common super class and
>> share one needed common change (which is one of the points which are
>> easy to see once you see all of those classes in a single PR, but
>> hard to explain in plaint-text pre-PR mailing list threads), so at
>> least those need to be discussed *together*. But to spare JBS and
>> PRs, I can open the PR with just the first set of changes, and once
>> we agree that this set is fine, I can push the next commit *in the
>> same PR*. Otherwise we would need endless JBS, mailing list threads,
>> and PRs, just to fixe a dozen internal code lines.
>>
>> Having said that, does the current state of this thread count as
>> "reached common agreement to file a PR" or do I still have to wait
>> until more people chime in?
>>
>> -Markus
>>
>>
>> Am 13.05.2025 um 15:10 schrieb Roger Riggs:
>>> Hi Markus,
>>>
>>> A main point was to avoid trying to do everything at once.
>>> The PR comments become hard to follow and intermingled and it takes
>>> longer to get agreement because of the thrash in the PR.
>>>
>>> Roger
>>>
>>> On 5/13/25 5:05 AM, Markus KARG wrote:
>>>> Thank you, Roger.
>>>>
>>>> Actually the method helps in the "toString()" variants, too, as in
>>>> some places we could *get rid* of "toString()" (which is more work
>>>> than "just" a buffer due to the added compression complexity).
>>>>
>>>> In fact, I already took the time to rewrite *all* of them while
>>>> waiting for the approval of this list posting. In *all* cases
>>>> *less* buffering / copying is needed, and *less* "toString()"
>>>> conversion (which is a copy under the hood) is needed. So if I
>>>> would be allowed to show the code as a PR, it would be much easier
>>>> to explain and discuss.
>>>>
>>>> A PR is the best place to discuss "how to code would change". In
>>>> the worst case, let's drop it if we see that it is actually a bad
>>>> thing.
>>>>
>>>> -Markus
>>>>
>>>>
>>>> Am 12.05.2025 um 20:18 schrieb Roger Riggs:
>>>>> Hi Markus,
>>>>>
>>>>> On the surface, its looks constructive.
>>>>> I suspect that many of these cases will turn into discussions
>>>>> about the right/best/better way to buffer the characters.
>>>>> The getChars method only helps when extracting to a char array,
>>>>> many of the current implementations create strings as the
>>>>> intermediary. The advantage of the 1 character at a time technique
>>>>> is not needing a (separated allocated) buffer.
>>>>> Consider taking a few at a time before launching into the whole set.
>>>>>
>>>>> $.02, Roger
>>>>>
>>>>> On 5/11/25 2:45 AM, Markus KARG wrote:
>>>>>> Dear Core Libs Team,
>>>>>>
>>>>>> I am hereby requesting comments on JDK-8356679.
>>>>>>
>>>>>> I would like to invest some time and set up a PR implementing
>>>>>> Chen Liangs's proposal laid out in
>>>>>> https://bugs.openjdk.org/browse/JDK-8356679. For your
>>>>>> convenience, the text of that JBS is copied below. According to
>>>>>> the Developer's Guide I do need to get broad agreement BEFORE
>>>>>> filing a PR. Therefore, I kindly ask everybody to briefly show
>>>>>> consent, so I may file a PR.
>>>>>>
>>>>>> Thanks
>>>>>> -Markus
>>>>>>
>>>>>>
>>>>>> Copy from https://bugs.openjdk.org/browse/JDK-8356679:
>>>>>>
>>>>>> Recently OpenJDK adopted the new method
>>>>>> CharSequence::getChars(int, int, char[], int) for inclusion in
>>>>>> Java 25. As a bulk reader method, it allows potentially improved
>>>>>> efficiency over the previously available char-by-char reader
>>>>>> method CharSequence::charAt(int).
>>>>>>
>>>>>> Chen Liang suggested on March 23rd on the core-lib-dev mailing
>>>>>> list to use the new method within the internal source code of
>>>>>> OpenJDK for the implementation of Appendables (see
>>>>>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html).
>>>>>> The idea behind this is that the implementations might be more
>>>>>> efficient then.
>>>>>>
>>>>>> A quick analysis of the OpenJDK source code identified (at least)
>>>>>> the following classes which could potentially run more efficient
>>>>>> when using CharSequence::getChars internally, thanks to bulk
>>>>>> reading and / or prevention of internal copies / toString()
>>>>>> conversions:
>>>>>> * java.io.Writer
>>>>>> * java.io.StringWriter
>>>>>> * java.io.PrintWriter
>>>>>> * java.io.BufferedWriter
>>>>>> * java.io.CharArrayWriter
>>>>>> * java.io.FileWriter
>>>>>> * java.io.OutputStreamWriter
>>>>>> * sun.nio.cs.StreamEncoder
>>>>>> * java.io.PrintStream
>>>>>> * java.nio.CharBuffer
>>>>>>
>>>>>> In the sense of "eat your own dog food", it makes sense to
>>>>>> implement Chen's idea in (at least) those classes. Possibly more
>>>>>> classes could get identified when taking a deeper look. Besides
>>>>>> the potential efficiency improvements, it would be a good show
>>>>>> case for the usage of the new API.
>>>>>>
>>>>>> The risk of this change should be low, as test coverage exists,
>>>>>> and as the intended changes are solely internal to the
>>>>>> implementation. No API will get changed. In some cases the
>>>>>> JavaDocs will get slightly adapted where it currently exposes the
>>>>>> actual implementation (to not lie in future).
>>>>>>
>>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250518/aeef4e79/attachment-0001.htm>

From kbarrett at openjdk.org  Sun May 18 20:55:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 18 May 2025 20:55:48 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
Message-ID: <wp_i02Ji5nG8obVLo9gJvHwA73hfC_b2dx56nXVsCoM=.c481ac3c-77ca-4d27-89be-31d98055964f@github.com>

> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
> use java.lang.ref.Cleaner.
> 
> This change is algorithmically similar to the two previous versions:
> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
> Bits::reserveMemory(). For both of those versions and this change, a thread
> calls that function and tries to reserve some space. If it fails, then it
> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
> cleaned. If reservation still fails, then it invokes the GC to try to
> deactivate more cleaners for cleaning. After that GC it keeps trying the
> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
> eventually either succeeding or giving up and throwing OOME.
> 
> Retaining that algorithmic approach is one of the goals of this change, since
> it has been successfully in use since JDK 9 (and was originally developed and
> extensively tested in JDK 8).
> 
> The key to this approach is having a way to determine that deactivated
> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
> threads help the reference processor until there was no available work.
> JDK-8156500 waits for the reference processor to quiesce, relying on its
> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
> to do this, which is why this change rolls its own Cleaner-like mechanism from
> the underlying primitives. Like JDK-6857566, this change has waiting threads
> help with cleaning references. This was a potentially undesirable feature of
> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
> became internal-only somewhere around that time as well.) That's not a concern
> here, as the cleaners involved are only from DBB, and we know what they look
> like.
> 
> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
> being done off the reference processing thread, as it may be expensive and
> slow down enqueuing other pending references. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
> 
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there is no available work whil...

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  move jdk.internal.nio.Cleaner to sun.nio

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25289/files
  - new: https://git.openjdk.org/jdk/pull/25289/files/3ebf665c..45d0b1ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25289&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25289&range=00-01

  Stats: 8 lines in 6 files changed: 2 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25289.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25289/head:pull/25289

PR: https://git.openjdk.org/jdk/pull/25289

From kbarrett at openjdk.org  Sun May 18 20:55:49 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 18 May 2025 20:55:49 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner
In-Reply-To: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
Message-ID: <u7Tf8pqk1ddYU4vAm0xcCTRRVbkyH5M_7aeJ4vk5mhk=.5b85798d-d55c-4cc6-9e67-4edeb7297200@github.com>

On Sun, 18 May 2025 11:35:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
> use java.lang.ref.Cleaner.
> 
> This change is algorithmically similar to the two previous versions:
> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
> Bits::reserveMemory(). For both of those versions and this change, a thread
> calls that function and tries to reserve some space. If it fails, then it
> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
> cleaned. If reservation still fails, then it invokes the GC to try to
> deactivate more cleaners for cleaning. After that GC it keeps trying the
> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
> eventually either succeeding or giving up and throwing OOME.
> 
> Retaining that algorithmic approach is one of the goals of this change, since
> it has been successfully in use since JDK 9 (and was originally developed and
> extensively tested in JDK 8).
> 
> The key to this approach is having a way to determine that deactivated
> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
> threads help the reference processor until there was no available work.
> JDK-8156500 waits for the reference processor to quiesce, relying on its
> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
> to do this, which is why this change rolls its own Cleaner-like mechanism from
> the underlying primitives. Like JDK-6857566, this change has waiting threads
> help with cleaning references. This was a potentially undesirable feature of
> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
> became internal-only somewhere around that time as well.) That's not a concern
> here, as the cleaners involved are only from DBB, and we know what they look
> like.
> 
> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
> being done off the reference processing thread, as it may be expensive and
> slow down enqueuing other pending references. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
> 
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there is no available work whil...

BTW, I'm fine with a suggestion to wait until JDK 26 before integrating this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25289#issuecomment-2889206138

From kbarrett at openjdk.org  Sun May 18 20:55:50 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 18 May 2025 20:55:50 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: <lYLXZxlwTG0V-ujQ4LAoVSnKNVisunvAyJSTy7rEszQ=.d095c373-4722-4821-9040-2c075ebae800@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <lYLXZxlwTG0V-ujQ4LAoVSnKNVisunvAyJSTy7rEszQ=.d095c373-4722-4821-9040-2c075ebae800@github.com>
Message-ID: <dE-Pk4NLUyJ7x1UrGnEwAme4zI6LzhcrcnyhK9_0Drs=.3215116b-cd50-4cae-b4c0-1ec6194cacdb@github.com>

On Sun, 18 May 2025 12:11:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/jdk/internal/nio/Cleaner.java line 26:
> 
>> 24:  */
>> 25: 
>> 26: package jdk.internal.nio;
> 
> The implementation/internal classes for this area are in sun.nio (for historical reasons). Probably best to keep them together.

Good point.  Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2094623283

From liach at openjdk.org  Sun May 18 21:17:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 18 May 2025 21:17:50 GMT
Subject: RFR: 8357178: Simplify Class::componentType
In-Reply-To: <qu6L562rjh0PbjZsNVcZtCgATWM79ieGPNm_Mpvw_ow=.7e1be13b-6ab3-41a2-b53c-da5f3bc63c23@github.com>
References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com>
 <qu6L562rjh0PbjZsNVcZtCgATWM79ieGPNm_Mpvw_ow=.7e1be13b-6ab3-41a2-b53c-da5f3bc63c23@github.com>
Message-ID: <N2psbJ2BkNXy9NexHty3Jmvt0thh9PmLMFdcstyeD68=.acc0468a-7efd-4101-9316-78b5c38abc14@github.com>

On Sun, 18 May 2025 18:18:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Did you consider calling getComponentType(), which already returns the field?

I don't think we want an extra indirection here - The logic here is quite simple. Counterargument could be that `MethodType::descriptorString` calls `toMethodDescriptorString`, except these methods involve more complex caching and is not simple like this field access.

> Are there regression tests for Class::componentType()/Class::getComponentType() somewhere? I didn't see them in the obvious test/jdk/java/lang/Class directory.

They are located in `test/jdk/java/lang/constant/TypeDescriptorTest.java`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25280#discussion_r2094628277

From liach at openjdk.org  Sun May 18 22:03:28 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 18 May 2025 22:03:28 GMT
Subject: RFR: 8357165: test java/lang/invoke/ClassValueTest.java fails
 intermittently
Message-ID: <i1B1gJuokz34xZAlURjip2LvwLnx7bCE04Ye3H3F7-g=.aa67b2d1-3dff-4be3-8250-49ab6ce5aad6@github.com>

The test was originally written with product builds in mind; it didn't consider the slowness of debug builds, thus causing tests to fail.

Also there was a bug in testWeakAgainstClassValue: the test need to flush the backing map in the class to have the weak value removed. It is fixed in this patch as well.

Testing: ClassValueTest repeated 10 times on windows-x64/linux-x64/macosx-aarch64/linux-aarch64 fastdebug.

-------------

Commit messages:
 - Restore incorrectly removed annotation
 - Fix problems with class value tests

Changes: https://git.openjdk.org/jdk/pull/25292/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25292&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357165
  Stats: 14 lines in 1 file changed: 5 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25292.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25292/head:pull/25292

PR: https://git.openjdk.org/jdk/pull/25292

From duke at openjdk.org  Sun May 18 23:47:08 2025
From: duke at openjdk.org (fabioromano1)
Date: Sun, 18 May 2025 23:47:08 GMT
Subject: RFR: 8077587: BigInteger Roots [v16]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <tje_KJoG4OGmhb9phb1KzJDSyuGQ6jBx7MT7gA1g8Gc=.7de45fd1-f5ce-4bdc-b33d-0bfa67b2c492@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Do first refinement loop only if shift == 0

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/aeef24cb..307af7f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=14-15

  Stats: 30 lines in 1 file changed: 12 ins; 11 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From liach at openjdk.org  Mon May 19 00:22:08 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 May 2025 00:22:08 GMT
Subject: RFR: 8357178: Simplify Class::componentType [v2]
In-Reply-To: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com>
References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com>
Message-ID: <HtEqf_NTEWnVWPfHMCzPBwoBWIwAGrwCBYWWlZzWnTo=.e989ba16-68f9-40a5-a774-82dd6dc5d292@github.com>

> `isArray` and null return is now redundant when `componentType` is changed to an explicit field.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  For parity with MT.descriptorString

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25280/files
  - new: https://git.openjdk.org/jdk/pull/25280/files/272ee25d..f8f0bf65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25280&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25280&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25280.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25280/head:pull/25280

PR: https://git.openjdk.org/jdk/pull/25280

From xgong at openjdk.org  Mon May 19 03:13:55 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 19 May 2025 03:13:55 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API
In-Reply-To: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
Message-ID: <z9_9NOdQqxNvv_l0VxjGD4Xc-baboKUmbY5NGbXdAHw=.f8486a40-5d28-4f9c-913e-8155baadbec2@github.com>

On Fri, 9 May 2025 07:35:41 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]).
> 
> Two key areas require improvement:
> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance.
> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types  increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance.
> 
> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures.
> 
> Main changes:
> 1. Java-side API refactoring:
>    - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on
>      architectures like AArch64.
> 2. C2 compiler IR refactoring:
>    - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types.
> 3. Backend changes:
>    - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level.
> 
> Performance:
> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below:
> 
> Benchmark                                                 Mode   Cnt Unit    SIZE    Before      After    Gain
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  64    53682.012   52650.325  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  256   14484.252   14255.156  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  1024   3664.900    3595.615  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  4096    908.312     935.269  1.02
> GatherOperationsBenchmark.micr...

Ping again~  could any one please take a look at this PR? Thanks a lot!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2889487313

From jlahoda at openjdk.org  Mon May 19 03:49:20 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 19 May 2025 03:49:20 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v4]
In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
Message-ID: <EEHy4qY8GtcneNUjXWZJj-2UF6i_N7z-05oBncDKR24=.9a21e713-e6df-4e75-b58d-a422bc411950@github.com>

> A consider class like this:
> 
> 
> public class TwoMains {
>     private static void main(String... args) {}
>     static void main() {
>         System.out.println("Should be called, but is not.");
>     }
> }
> 
> 
> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
> 
> Something similar happens if the return type is not `void`.
> 
> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
> 
> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Adjusting message and tests.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25256/files
  - new: https://git.openjdk.org/jdk/pull/25256/files/f63dab37..db7e7ceb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=02-03

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25256/head:pull/25256

PR: https://git.openjdk.org/jdk/pull/25256

From kbarrett at openjdk.org  Mon May 19 05:53:51 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 19 May 2025 05:53:51 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v4]
In-Reply-To: <osvnYqxUKpb8w975g7_QLJh-mnLco5QDXqIxjZLpYrA=.51981ba7-e0d4-4ee8-b5ba-e231bb0ccd1b@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <KZ41_YxAj8W5EVG9t2V5EOX86wBGgnV9K_iviT2aFZ0=.3fd302c5-63c3-4165-b3a5-340b1c8a586d@github.com>
 <Edt-A0se0SLBHKLueCgW7MZTv1isPR7ZgI_a6ZjOow0=.a052fce7-e422-44d1-94a1-79557b4ae1bc@github.com>
 <we44CFHJBu2JnN5Yf9rJXHgBWLDScdXFXKNlz7hL5kI=.a56ee994-6926-47bf-addf-6aea98053159@github.com>
 <vjlqBUhDXCI54LvDJ4EEUmShrq1noX55NSZJB6SDJDE=.c3d28a76-05ac-4ee5-8038-cb2662b01f6f@github.com>
 <-oOK2Dh2vnn9Qc5MBRiKoeauVFVPPV_9fKMqAQwjFfY=.b20b09d9-a268-4ca9-9362-7045c6a3afce@github.com>
 <Ldh_3-rwQc-SKv48LsEvl0sP4_iTIzBSHIX7TAofxCk=.2667b385-40e8-417d-9a0d-481c36750b63@github.com>
 <osvnYqxUKpb8w975g7_QLJh-mnLco5QDXqIxjZLpYrA=.51981ba7-e0d4-4ee8-b5ba-e231bb0ccd1b@github.com>
Message-ID: <bnYBb1wE7m9hwSob9MlXE1XS-SF3L-XArFmBbvc3iNY=.834b52d0-ab85-4398-8903-fdc886d50ad8@github.com>

On Fri, 11 Apr 2025 10:52:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 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.
>> 
> ...
>
> 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, [JDK-8354417](https://bugs.openjdk.org/browse/JDK-8354417).
> 
> That said, I am still not 100% sure there is no bug, because I see intrinsics like `Object.hashCode` do seem to handle virtual cases.

Quoting from https://bugs.openjdk.org/browse/JDK-8271862

> However, Object.clone() and Object.hashCode() are also virtual, native and @IntrinsicCandidate, and these get special treatment by C2 to get the intrinsic generated more optimally. It's not clear to me if we should do something similar with refersTo0() or if the above workaround should be considered good enough.

For Reference.refersTo (and later, Reference.clear) we did the workaround, avoiding methods that had all 3
properties.  Similarly for Reference.get here.  But it might be worthwhile looking into this issue more carefully
and generally, both to make sure there aren't other affected intrinsics, and to either solve that case better or
complain when it arises.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2094884157

From jpai at openjdk.org  Mon May 19 06:22:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 06:22:56 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v4]
In-Reply-To: <EEHy4qY8GtcneNUjXWZJj-2UF6i_N7z-05oBncDKR24=.9a21e713-e6df-4e75-b58d-a422bc411950@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
 <EEHy4qY8GtcneNUjXWZJj-2UF6i_N7z-05oBncDKR24=.9a21e713-e6df-4e75-b58d-a422bc411950@github.com>
Message-ID: <vS5YDG53mDSz6jH9vclF2PSYGwTVBuoHb5gSTBoWdxA=.b897aee8-2133-4502-9de8-248d342ede27@github.com>

On Mon, 19 May 2025 03:49:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A consider class like this:
>> 
>> 
>> public class TwoMains {
>>     private static void main(String... args) {}
>>     static void main() {
>>         System.out.println("Should be called, but is not.");
>>     }
>> }
>> 
>> 
>> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
>> 
>> Something similar happens if the return type is not `void`.
>> 
>> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
>> 
>> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusting message and tests.

The updated changes look good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25256#pullrequestreview-2849510798

From jpai at openjdk.org  Mon May 19 07:02:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 07:02:58 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <OFzwCUP8551ajdWuUCOGE3LM3aZ-niEocXo7couS1m0=.5113cf96-1d25-4efc-9c23-930b72330205@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <XhhlO7kp9gHxAH8FtiI7By4_KixYmqbDr6kKCbTmtXE=.afcdff58-ff7f-4ae8-9e2a-fb7153732125@github.com>
 <OFzwCUP8551ajdWuUCOGE3LM3aZ-niEocXo7couS1m0=.5113cf96-1d25-4efc-9c23-930b72330205@github.com>
Message-ID: <uJD3_543RevQ83bhjZPKw4xLAHjPayk6TaF9_cbtDis=.4d22f0a0-250b-40e3-936c-fe45a6e31dd4@github.com>

On Fri, 16 May 2025 18:37:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 478:
>> 
>>> 476:      *
>>> 477:      * <p> If an I/O error occurs reading from the stream, then it
>>> 478:      * may do so after some, but not all, characters have been read.
>> 
>> Hello Brian, I read this sentence a couple of times but it wasn't clear to me what this meant. I am guessing that we want to state that if an I/O error occurs when some (but not all?) characters have been read then the stream may be in an inconsistent state? Should we reword this paragraph?
>> 
>> I suspect that sentence was motivated from similar existing text in `Files.readString(...)` and there too I find it confusing.
>
>> I read this sentence a couple of times [...]
> 
> Please see [a86610d](https://github.com/openjdk/jdk/pull/24728/commits/a86610d06169445a5c4b81a0c60527130a45e045).
> 
>> I suspect that sentence was motivated from similar existing text in `Files.readString(...)` and there too I find it confusing.
> 
> If you think it worthwhile, please file an issue to improve that verbiage as well.

Thank you Brian, the updated text for this section looks good to me. Once this PR gets integrated, I'll go through the Files.readXXX methods and file an issue to have that text simplified too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2094977207

From alanb at openjdk.org  Mon May 19 07:17:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 May 2025 07:17:56 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <uJD3_543RevQ83bhjZPKw4xLAHjPayk6TaF9_cbtDis=.4d22f0a0-250b-40e3-936c-fe45a6e31dd4@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <XhhlO7kp9gHxAH8FtiI7By4_KixYmqbDr6kKCbTmtXE=.afcdff58-ff7f-4ae8-9e2a-fb7153732125@github.com>
 <OFzwCUP8551ajdWuUCOGE3LM3aZ-niEocXo7couS1m0=.5113cf96-1d25-4efc-9c23-930b72330205@github.com>
 <uJD3_543RevQ83bhjZPKw4xLAHjPayk6TaF9_cbtDis=.4d22f0a0-250b-40e3-936c-fe45a6e31dd4@github.com>
Message-ID: <8SJl_mDv3MuJGgTfW3pc4adoVxHpbwVyPEgD0n2nguM=.d9845fcc-cf54-46e8-b2af-a2ce16f4b991@github.com>

On Mon, 19 May 2025 06:59:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> I read this sentence a couple of times [...]
>> 
>> Please see [a86610d](https://github.com/openjdk/jdk/pull/24728/commits/a86610d06169445a5c4b81a0c60527130a45e045).
>> 
>>> I suspect that sentence was motivated from similar existing text in `Files.readString(...)` and there too I find it confusing.
>> 
>> If you think it worthwhile, please file an issue to improve that verbiage as well.
>
> Thank you Brian, the updated text for this section looks good to me. Once this PR gets integrated, I'll go through the Files.readXXX methods and file an issue to have that text simplified too.

I see this has been changed to  "then some characters, but not all" but it doesn't flow very well. The original sentence, which was copied/modified from InputStream.readAllBytes, is much cleaner and I think I would prefer to go back to that.  Maybe Jai's issue could be address by dropping the first comma from the sentence?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2095001660

From jlahoda at openjdk.org  Mon May 19 07:32:02 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 19 May 2025 07:32:02 GMT
Subject: Integrated: 8357016: Candidate main methods not computed properly
In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
Message-ID: <wLWCtjTOidPjqk0X3M19yNPmPiMt175rbVBS5OCjSFI=.4b0d5f9c-5dff-4822-8f84-1d266048ce39@github.com>

On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> A consider class like this:
> 
> 
> public class TwoMains {
>     private static void main(String... args) {}
>     static void main() {
>         System.out.println("Should be called, but is not.");
>     }
> }
> 
> 
> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
> 
> Something similar happens if the return type is not `void`.
> 
> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
> 
> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).

This pull request has now been integrated.

Changeset: 77a3e04f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/77a3e04ffc27554c14e3d45ba16ad0ee8f3c1eb1
Stats:     177 lines in 8 files changed: 151 ins; 10 del; 16 mod

8357016: Candidate main methods not computed properly

Reviewed-by: jpai, vromero

-------------

PR: https://git.openjdk.org/jdk/pull/25256

From tvaleev at openjdk.org  Mon May 19 07:34:43 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Mon, 19 May 2025 07:34:43 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface
Message-ID: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>

Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
The specification is mostly composed of Math.min/max and Collections.min/max specifications. 

The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.

I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.

-------------

Commit messages:
 - Fix linebreaks
 - JDK-8356995 Provide default methods min(T, T) and max(T, T) in Comparator interface

Changes: https://git.openjdk.org/jdk/pull/25297/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356995
  Stats: 112 lines in 2 files changed: 110 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25297.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25297/head:pull/25297

PR: https://git.openjdk.org/jdk/pull/25297

From forax at univ-mlv.fr  Mon May 19 08:13:13 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 19 May 2025 10:13:13 +0200 (CEST)
Subject: Towards a JSON API for the JDK
In-Reply-To: <52514642-e172-4096-a616-a2c9a9787552@gmail.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <52514642-e172-4096-a616-a2c9a9787552@gmail.com>
Message-ID: <1926856506.269259526.1747642393592.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "cay horstmann" <cay.horstmann at gmail.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Sunday, May 18, 2025 7:55:12 AM
> Subject: Re: Towards a JSON API for the JDK

Hello Cay,

> +1 for having a JSON battery included with the JDK. And for "Our primary goal is
> that the library be simple to use for parsing, traversing, and generating
> conformant JSON documents."
> 
> Generating JSON could be easier. Why not convenience methods Json.newObject and
> Json.newArray like in https://github.com/arkanovicz/essential-json?
> 
> Parsing with instanceof will work, but is obviously painful today, as your
> example shows. The simplification with deconstruction patterns is not
> impressive either.
> 
> JsonValue doc = Json.parse(inputString);
> if (doc instanceof JsonObject(var members)
>      && members.get("name") instanceof JsonString(String name)
>      && members.get("age") instanceof JsonNumber(int age)) {
>              // use "name" and "age"
> } else throw new NoSuchArgumentException();
> 
> vs. Jackson
> 
> String name = doc.get("name").asText();
> int age = doc.get("age").asInt();
> ...
> 
> If only there was some deconstruction magic that approximates the JavaScript
> code
> 
> const doc = { name: "John", age: 30 }
> const { name, age } = doc

We already have that, it's called a record :)

Basically, you are advocating for a mapping JsonObject <--> record.

[...]

> 
> Cheers,
> 
> Cay
> 

Here is a simple JsonObject mapper using java.util.json types.
  https://github.com/forax/json-object-mapper

I believe this is also the fastest possible ... it leverages method handles to generate the mapping code (it's only 128 lines of code, obviously, it's a prototype)
  https://github.com/forax/json-object-mapper/blob/master/src/main/java/json/RecordMapperImpl.java

It's mostly on par with hand-coded code (i've just a supplementary lookup through a StableValue)

  // Benchmark                        Mode  Cnt   Score   Error  Units
  // RecordMapperBench.mappingSimple  avgt    5  15,057 ? 0,050  ns/op
  // RecordMapperBench.recordMapper   avgt    5  16,997 ? 0,044  ns/op
  

regards,
R?mi

From jlahoda at openjdk.org  Mon May 19 08:31:56 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 19 May 2025 08:31:56 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v16]
In-Reply-To: <GzzgfleafLsCdPZxFZ05PIGjejVSBNdfn-OU4eJMBBA=.60c11dfc-876e-4719-8e57-659ca5554cfe@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <GzzgfleafLsCdPZxFZ05PIGjejVSBNdfn-OU4eJMBBA=.60c11dfc-876e-4719-8e57-659ca5554cfe@github.com>
Message-ID: <path6TRLoBeD1bFwvVZvX6tD6Us6Ypp6RUgocuTnFOc=.f621fb44-24ed-40b8-afb0-57163e5ba87c@github.com>

On Thu, 15 May 2025 22:32:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

javac changes look good to me, with one trivial nit in `Check`.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5848:

> 5846:         }
> 5847:     }
> 5848:  }

Nit - there appears to be an extra space at the beginning of this line.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24746#pullrequestreview-2849882159
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2095145360

From jpai at openjdk.org  Mon May 19 08:55:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 08:55:53 GMT
Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id
 contains "-J"
In-Reply-To: <GJ80lme__hVwt5Y2yGHqCmxZta8fpTLGorMjYRkWjbo=.a7053f26-d608-4f29-978f-80364a8bafda@github.com>
References: <GJ80lme__hVwt5Y2yGHqCmxZta8fpTLGorMjYRkWjbo=.a7053f26-d608-4f29-978f-80364a8bafda@github.com>
Message-ID: <WkPNV1mmBZWAnmXamUh8KoZuKXm7KQUJpJyKNIFnBZM=.166c6ecc-926c-4dd1-8382-935089925f90@github.com>

On Wed, 14 May 2025 14:40:41 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at:
> 
> https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134
> 
> This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure.
> 
> Testing:
>  - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332)
>  - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing

Hello Manuel,

> When passing -J-version to the patched javac, tools/launcher/ToolsOpts.java wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly

The proposed change looks reasonable to me. A brief look through JEP-223 https://openjdk.org/jeps/223 suggests that a space character cannot appear in the JDK version, so this proposed change to use " -J-" won't run into the same issue as previously.

The copyright year on this test will need an update. Please also add a "noreg-self" (https://openjdk.org/guide/#noreg) to the JBS issue.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25230#pullrequestreview-2849969430

From pminborg at openjdk.org  Mon May 19 09:13:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 19 May 2025 09:13:03 GMT
Subject: RFR: 8357178: Simplify Class::componentType [v2]
In-Reply-To: <HtEqf_NTEWnVWPfHMCzPBwoBWIwAGrwCBYWWlZzWnTo=.e989ba16-68f9-40a5-a774-82dd6dc5d292@github.com>
References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com>
 <HtEqf_NTEWnVWPfHMCzPBwoBWIwAGrwCBYWWlZzWnTo=.e989ba16-68f9-40a5-a774-82dd6dc5d292@github.com>
Message-ID: <5K8uBd9NeI5sS4c6qT-BCiPOJp0DnC5dNmBnoSZvS14=.577456e6-50be-4a36-9a79-47de1d4e38fb@github.com>

On Mon, 19 May 2025 00:22:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `isArray` and null return is now redundant when `componentType` is changed to an explicit field.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   For parity with MT.descriptorString

Question: Why was this overload added in the first place, as it seems equivalent to `getComponentType()`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25280#issuecomment-2890245474

From jpai at openjdk.org  Mon May 19 09:13:14 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 09:13:14 GMT
Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id
 contains "-J" [v2]
In-Reply-To: <HB7SWMI4eA-1iPlWuJ0q9eqpDxj_MMtPETiLAatpY3o=.2e999d13-f5e3-487d-a6be-842d81bc6272@github.com>
References: <GJ80lme__hVwt5Y2yGHqCmxZta8fpTLGorMjYRkWjbo=.a7053f26-d608-4f29-978f-80364a8bafda@github.com>
 <HB7SWMI4eA-1iPlWuJ0q9eqpDxj_MMtPETiLAatpY3o=.2e999d13-f5e3-487d-a6be-842d81bc6272@github.com>
Message-ID: <iyTj04aCKbXW5XUyyRXmNuohYaM6q0eE63zXs_rLlY4=.bca4fc74-2810-41df-a3c6-e8589142f55d@github.com>

On Mon, 19 May 2025 09:10:21 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at:
>> 
>> https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134
>> 
>> This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure.
>> 
>> Testing:
>>  - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332)
>>  - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

Thank you for the update. Looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25230#pullrequestreview-2850018076

From mhaessig at openjdk.org  Mon May 19 09:13:14 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 19 May 2025 09:13:14 GMT
Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id
 contains "-J" [v2]
In-Reply-To: <GJ80lme__hVwt5Y2yGHqCmxZta8fpTLGorMjYRkWjbo=.a7053f26-d608-4f29-978f-80364a8bafda@github.com>
References: <GJ80lme__hVwt5Y2yGHqCmxZta8fpTLGorMjYRkWjbo=.a7053f26-d608-4f29-978f-80364a8bafda@github.com>
Message-ID: <HB7SWMI4eA-1iPlWuJ0q9eqpDxj_MMtPETiLAatpY3o=.2e999d13-f5e3-487d-a6be-842d81bc6272@github.com>

> When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at:
> 
> https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134
> 
> This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure.
> 
> Testing:
>  - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332)
>  - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing

Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25230/files
  - new: https://git.openjdk.org/jdk/pull/25230/files/a11ff5e5..388f3683

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25230&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25230&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25230.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25230/head:pull/25230

PR: https://git.openjdk.org/jdk/pull/25230

From jpai at openjdk.org  Mon May 19 09:22:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 09:22:54 GMT
Subject: RFR: 8357106: Add missing classpath exception copyright headers
In-Reply-To: <Wu-CDJPi0tLHx96hLhkRaoryY4QpEKuK7eU80IBdzKA=.52bb83ef-1016-4764-aac8-232d2f66d167@github.com>
References: <Wu-CDJPi0tLHx96hLhkRaoryY4QpEKuK7eU80IBdzKA=.52bb83ef-1016-4764-aac8-232d2f66d167@github.com>
Message-ID: <bS0iBgIWjAlb7KUGZZArfxUtODDm_yhwP9Xy_IHgp9w=.2b3a271e-34e8-44e5-a69a-3e78e1d48ed0@github.com>

On Fri, 16 May 2025 07:04:04 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

> This PR adds missing classpath exception

The change looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25261#pullrequestreview-2850053263

From jpai at openjdk.org  Mon May 19 09:31:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 09:31:55 GMT
Subject: RFR: 8357081: Removed unused methods of HexDigits
In-Reply-To: <NmneRyd1Xg5PGjAiG1Pgq5dqkWMiE23LRjALLutkoyA=.912425d2-b549-40f7-bea2-46f2f869fa30@github.com>
References: <NmneRyd1Xg5PGjAiG1Pgq5dqkWMiE23LRjALLutkoyA=.912425d2-b549-40f7-bea2-46f2f869fa30@github.com>
Message-ID: <Er0V3dvPaBHmlzeiaAqCmsKj5yh60J4k91dPNNHKSEg=.6e9796d0-57b3-46a7-a122-74fe796c90b4@github.com>

On Thu, 15 May 2025 22:03:22 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In HexDigits, getCharsLatin1 and getCharsUTF16 are no longer used, so remove these methods

It does indeed look like these are unused. The change looks OK to me but please wait for one more review from someone more familiar with this code to understand if there's anything more to consider.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25258#pullrequestreview-2850079533

From duke at openjdk.org  Mon May 19 09:32:53 2025
From: duke at openjdk.org (duke)
Date: Mon, 19 May 2025 09:32:53 GMT
Subject: RFR: 8357106: Add missing classpath exception copyright headers
In-Reply-To: <Wu-CDJPi0tLHx96hLhkRaoryY4QpEKuK7eU80IBdzKA=.52bb83ef-1016-4764-aac8-232d2f66d167@github.com>
References: <Wu-CDJPi0tLHx96hLhkRaoryY4QpEKuK7eU80IBdzKA=.52bb83ef-1016-4764-aac8-232d2f66d167@github.com>
Message-ID: <lOZ0c2tZYdli6jZaGm7aS5Q5PizcdEn7oNqiYea9iSg=.f4646b0c-fe2c-4cfa-891b-84caffc18667@github.com>

On Fri, 16 May 2025 07:04:04 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

> This PR adds missing classpath exception

@Sorna-Sarathi 
Your change (at version 1b55b287f84d5cad1958aec440f3b499a874b04c) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25261#issuecomment-2890316340

From mhaessig at openjdk.org  Mon May 19 09:32:53 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 19 May 2025 09:32:53 GMT
Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id
 contains "-J" [v2]
In-Reply-To: <HB7SWMI4eA-1iPlWuJ0q9eqpDxj_MMtPETiLAatpY3o=.2e999d13-f5e3-487d-a6be-842d81bc6272@github.com>
References: <GJ80lme__hVwt5Y2yGHqCmxZta8fpTLGorMjYRkWjbo=.a7053f26-d608-4f29-978f-80364a8bafda@github.com>
 <HB7SWMI4eA-1iPlWuJ0q9eqpDxj_MMtPETiLAatpY3o=.2e999d13-f5e3-487d-a6be-842d81bc6272@github.com>
Message-ID: <tLGrpHj6a_CyyiQCPp2RNsrdhMdCRKzNyrz3xk9tCoM=.27d6698f-eb68-46f2-aa17-923ad60201b6@github.com>

On Mon, 19 May 2025 09:13:14 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at:
>> 
>> https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134
>> 
>> This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure.
>> 
>> Testing:
>>  - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332)
>>  - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

Thank you for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25230#issuecomment-2890310647

From duke at openjdk.org  Mon May 19 09:32:54 2025
From: duke at openjdk.org (duke)
Date: Mon, 19 May 2025 09:32:54 GMT
Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id
 contains "-J" [v2]
In-Reply-To: <HB7SWMI4eA-1iPlWuJ0q9eqpDxj_MMtPETiLAatpY3o=.2e999d13-f5e3-487d-a6be-842d81bc6272@github.com>
References: <GJ80lme__hVwt5Y2yGHqCmxZta8fpTLGorMjYRkWjbo=.a7053f26-d608-4f29-978f-80364a8bafda@github.com>
 <HB7SWMI4eA-1iPlWuJ0q9eqpDxj_MMtPETiLAatpY3o=.2e999d13-f5e3-487d-a6be-842d81bc6272@github.com>
Message-ID: <joIYaHlbdTpCAVVgxK2X4tV2FmAEip02OqZNygS-IK4=.d5547cf7-e991-41eb-aacc-0c81ba313741@github.com>

On Mon, 19 May 2025 09:13:14 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at:
>> 
>> https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134
>> 
>> This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure.
>> 
>> Testing:
>>  - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332)
>>  - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

@mhaessig 
Your change (at version 388f36832198c72268a3302cacb3192e9e93cf21) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25230#issuecomment-2890316802

From mhaessig at openjdk.org  Mon May 19 10:18:58 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 19 May 2025 10:18:58 GMT
Subject: Integrated: 8356974: tools/launcher/ToolsOpts.java fails if the build
 id contains "-J"
In-Reply-To: <GJ80lme__hVwt5Y2yGHqCmxZta8fpTLGorMjYRkWjbo=.a7053f26-d608-4f29-978f-80364a8bafda@github.com>
References: <GJ80lme__hVwt5Y2yGHqCmxZta8fpTLGorMjYRkWjbo=.a7053f26-d608-4f29-978f-80364a8bafda@github.com>
Message-ID: <sO3ji6d5B-ZSutIIOzOEcEl_khLmZwg6cXxsw_KqaqM=.eec386dc-4de8-46a6-b114-8a83fa71c65e@github.com>

On Wed, 14 May 2025 14:40:41 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at:
> 
> https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134
> 
> This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure.
> 
> Testing:
>  - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332)
>  - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing

This pull request has now been integrated.

Changeset: 36c9be70
Author:    Manuel H?ssig <mhaessig at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/36c9be70e27eccdd2a156931fafa1f55dd3fb022
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J"

Reviewed-by: jpai, thartmann

-------------

PR: https://git.openjdk.org/jdk/pull/25230

From ssarathi at openjdk.org  Mon May 19 10:19:55 2025
From: ssarathi at openjdk.org (Sorna Sarathi N)
Date: Mon, 19 May 2025 10:19:55 GMT
Subject: Integrated: 8357106: Add missing classpath exception copyright headers
In-Reply-To: <Wu-CDJPi0tLHx96hLhkRaoryY4QpEKuK7eU80IBdzKA=.52bb83ef-1016-4764-aac8-232d2f66d167@github.com>
References: <Wu-CDJPi0tLHx96hLhkRaoryY4QpEKuK7eU80IBdzKA=.52bb83ef-1016-4764-aac8-232d2f66d167@github.com>
Message-ID: <_z7ivO4xGAYExHsow29YjGlW_YjsfkDaztbrOkFTGrc=.99772a7f-ee07-47e1-81ef-22f88aa8bcd0@github.com>

On Fri, 16 May 2025 07:04:04 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

> This PR adds missing classpath exception

This pull request has now been integrated.

Changeset: afcaf840
Author:    Sorna Sarathi N <ssarathi at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/afcaf84022f165d66068c16460b7666f48e84773
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8357106: Add missing classpath exception copyright headers

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/25261

From duke at openjdk.org  Mon May 19 10:21:08 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 19 May 2025 10:21:08 GMT
Subject: RFR: 8077587: BigInteger Roots [v17]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <UsWLsm90yVJdkJRhXLc0JwwB_5TSGc53IMRXGWOoG50=.9a46582b-d06d-4c48-be62-b70c75050f24@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Code simplification

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/307af7f6..fe82fa72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=15-16

  Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From liach at openjdk.org  Mon May 19 10:46:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 May 2025 10:46:52 GMT
Subject: RFR: 8357178: Simplify Class::componentType [v2]
In-Reply-To: <5K8uBd9NeI5sS4c6qT-BCiPOJp0DnC5dNmBnoSZvS14=.577456e6-50be-4a36-9a79-47de1d4e38fb@github.com>
References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com>
 <HtEqf_NTEWnVWPfHMCzPBwoBWIwAGrwCBYWWlZzWnTo=.e989ba16-68f9-40a5-a774-82dd6dc5d292@github.com>
 <5K8uBd9NeI5sS4c6qT-BCiPOJp0DnC5dNmBnoSZvS14=.577456e6-50be-4a36-9a79-47de1d4e38fb@github.com>
Message-ID: <1rO5rd1EN4l_CuHuxsB4tUINs0pBzm-qEiq4sSGF8lo=.d346059c-9bf1-442e-b6b5-2fdf092d336a@github.com>

On Mon, 19 May 2025 09:10:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   For parity with MT.descriptorString
>
> Question: Why was this overload added in the first place, as it seems equivalent to `getComponentType()`?

@minborg It implements a method in TypeDescriptor.OfField.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25280#issuecomment-2890543283

From dfuchs at openjdk.org  Mon May 19 11:09:00 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 19 May 2025 11:09:00 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v10]
In-Reply-To: <bi8YKmS-MSABbDfusziw4Ig1gJNUdNlVmm6qT-hf4Y0=.5c7261b0-834d-41b0-b1d4-428e5741b24a@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <bi8YKmS-MSABbDfusziw4Ig1gJNUdNlVmm6qT-hf4Y0=.5c7261b0-834d-41b0-b1d4-428e5741b24a@github.com>
Message-ID: <U-6OnS3dKkBpFuvz-qTxnpiUp8iQbuYtI1Ihi3GXMrQ=.642ef9d0-a7d0-4d0d-9f83-512a10043465@github.com>

On Fri, 16 May 2025 11:42:08 GMT, Michael McMahon <michaelm at openjdk.org> 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 26 commits:
> 
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - update to minimise code changes
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/64a858c7...3b7861b0

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 78:

> 76:      * controlled. Consider using a unique value for the
> 77:      * SecurityProperties.includedInExceptions(String value) mechanism
> 78:      * Current values defined are "socket", "jar", "userInfo"

If I am not mistaken the "socket" info is no longer here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2095457460

From jbhateja at openjdk.org  Mon May 19 11:30:50 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 19 May 2025 11:30:50 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API
In-Reply-To: <z9_9NOdQqxNvv_l0VxjGD4Xc-baboKUmbY5NGbXdAHw=.f8486a40-5d28-4f9c-913e-8155baadbec2@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <z9_9NOdQqxNvv_l0VxjGD4Xc-baboKUmbY5NGbXdAHw=.f8486a40-5d28-4f9c-913e-8155baadbec2@github.com>
Message-ID: <waRApxfwTKaooXE5vOPH6Oc-pEFSzkXxm4mU7gpndbU=.3d7c9968-6aad-4c78-9312-5d9613fcf174@github.com>

On Mon, 19 May 2025 03:10:46 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]).
>> 
>> Two key areas require improvement:
>> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance.
>> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types  increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance.
>> 
>> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures.
>> 
>> Main changes:
>> 1. Java-side API refactoring:
>>    - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on
>>      architectures like AArch64.
>> 2. C2 compiler IR refactoring:
>>    - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types.
>> 3. Backend changes:
>>    - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level.
>> 
>> Performance:
>> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below:
>> 
>> Benchmark                                                 Mode   Cnt Unit    SIZE    Before      After    Gain
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  64    53682.012   52650.325  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  256   14484.252   14255.156  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  1024   3664.900    3595.615  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  4096    908.31...
>
> Ping again~  could any one please take a look at this PR? Thanks a lot!

Hi @XiaohongGong ,
Very nice work!,  Looks good to me, will do some testing and get back.

Do you have any idea about following regression?


GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  64    55844.814   48311.847  0.86
GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  256   15139.459   13009.848  0.85
GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  1024   3861.834    3284.944  0.85
GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  4096    938.665     817.673  0.87


Best Regards

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2890659302

From nbenalla at openjdk.org  Mon May 19 11:34:31 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 19 May 2025 11:34:31 GMT
Subject: RFR: 8356629: Incorrect use of {@linkplain} in java.sql
Message-ID: <lHdtlZO7OsPQqd8SEBfLMyuxKBcwXAseIj3ZtGbguK8=.c41528ea-72be-4a3c-b0a4-733f6e95086c@github.com>

Please review this trivial patch to fix a javadoc bug.

TIA

-------------

Commit messages:
 - use  PseudoColumnUsage#name() instead
 - fix incorrect `@link` tags

Changes: https://git.openjdk.org/jdk/pull/25286/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25286&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356629
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25286.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25286/head:pull/25286

PR: https://git.openjdk.org/jdk/pull/25286

From duke at openjdk.org  Mon May 19 11:35:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 11:35:54 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <Hshk19tLkpqUY-Lc0apS8ul2aOVtYQ3CmRkCTeoAuLc=.98aec5fc-c8b0-459b-bb63-8439f8652717@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
 <TIyKoUhUEzKutdfkt1jIoGZPNfB7WMlkGeYEsqT8n40=.9fca5d23-4be4-45f9-8848-6ca45e9e4208@github.com>
 <Hshk19tLkpqUY-Lc0apS8ul2aOVtYQ3CmRkCTeoAuLc=.98aec5fc-c8b0-459b-bb63-8439f8652717@github.com>
Message-ID: <QY2aYmDn7F-ONoEV9QDZHVuZkwXEMPsKQRRGA3RYFqo=.eaa7544b-535e-4b5f-b8ff-976d85ad060c@github.com>

On Fri, 16 May 2025 15:38:33 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/jdk.zipfs/share/classes/module-info.java line 299:
>> 
>>> 297:  *           <li>
>>> 298:  *               Any other values will cause an {@code IllegalArgumentException}
>>> 299:  *               to be thrown.
>> 
>> The wording looks great. Just one thing with the "causes an IAE to be thrown" where I think it can be expanded to say that it causes IAE to be thrown when attempting to create the ZIP file system. The existing compressMethod property has word for this too.
>
> The IAE message would be best to standardize around the wording that the compressMethod property uses (same for releaseVersion while we are at it.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095504122

From duke at openjdk.org  Mon May 19 11:35:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 11:35:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <JoYBy9mw1zJ99-VgFw2GN7T5x1nSptIDqBlRx4HxEqY=.7f36a29c-292e-488f-a9d3-1a4fb0abe19b@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <JoYBy9mw1zJ99-VgFw2GN7T5x1nSptIDqBlRx4HxEqY=.7f36a29c-292e-488f-a9d3-1a4fb0abe19b@github.com>
Message-ID: <R2NxY6aNMfaWE60xn_d5jkWaFtAw7l607YOxeIVpzF8=.3451e1aa-3065-4fc3-9b1f-61b57956848b@github.com>

On Wed, 14 May 2025 16:42:07 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes based on review feedback.
>
> test/jdk/jdk/nio/zipfs/TestPosix.java line 434:
> 
>> 432:         createTestZipFile(ZIP_FILE, ENV_DEFAULT).close();
>> 433:         // check entries on zipfs with default options
>> 434:         try (FileSystem zip = FileSystems.newFileSystem(ZIP_FILE, ENV_DEFAULT)) {
> 
> This tests an empty Map and should still be a test as it is different from ENV_READ_ONLY

Revert and added new ReadOnly variants of those tests. Thanks for calling me out on this, it was a bit sloppy of me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095503763

From duke at openjdk.org  Mon May 19 11:45:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 11:45:54 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <PnCfACKzgUPJFmIl1jOToEJHjKVfNvQq8ZDYu9mgB4s=.48fc1387-134d-42a6-ae86-8a08e398a906@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
 <PnCfACKzgUPJFmIl1jOToEJHjKVfNvQq8ZDYu9mgB4s=.48fc1387-134d-42a6-ae86-8a08e398a906@github.com>
Message-ID: <3kUW3YQrrh5z2ZHea8beg7tgbzWX_wDH3_UWnLxNafE=.ad3a3955-6c95-4e9a-b448-6ecce423478c@github.com>

On Fri, 16 May 2025 14:23:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes based on review feedback.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 114:
> 
>> 112:     private final ZipPath rootdir;
>> 113:     // Starts in readOnly (safe mode), but might be reset at the end of initialization.
>> 114:     private boolean readOnly = true;
> 
> If `readOnly` gets used by some code when a `ZipFileSystem` instance is being constructed (which is why I believe this can't be a `final` field), then I think we should not change this value to `true`. In other words, would this change now have a chance of introducing a `ReadOnlyFileSystemException` when constructing the `ZipFileSystem` whereas before it wouldn't?

""would this change now have a chance of introducing a ReadOnlyFileSystemException when constructing the ZipFileSystem whereas before it wouldn't?""

If there was ever a "ReadOnlyFileSystemException" when initializing the ZipFileSystem, we have a very serious bug already. Since we already have the opening of Zip working for cases where the underlying file is read-only in the file system, it has to be true that no attempt is made to modify the file contents.

While I accept that this new code now calls out to functions with this flag in a different state to before, I believe this is an absolute improvement since:

1. It is not acceptable to say to users "we support a read-only mode" if during initialization we might modify the file in any way (even including changing last-modification times etc.).

2. All the evidence points to whichever operations are being done during init as being fundamentally "read-only" (both due to it working on read-only zip files, and there being no conceptual need to modify anything during setup).

I'll happily do a thorough audit of everything which could be affected by this change if that will give you confidence, but I would not want to change this code back to its default "read-write until stated otherwise" behaviour.

> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 245:
> 
>> 243:                     : "The underlying ZIP file is not writable";
>> 244:             throw new IOException(
>> 245:                     "A writable ZIP file system could not be opened for: " + zfpath + "\n" + reason);
> 
> The JDK coding guidelines recommend excluding file paths from exception messages. So in this case the `zfpath` should be left out from the exception message. Additionally, I haven't seen us using newline characters in exception messages that we construct in the JDK code. So I think we should leave that out too. 
> 
> Given this, I think it might be simpler to just change this `if` block to something like:
> 
> 
> 
> if (...) {
>     String reason = multiReleaseVersion.isPresent()
>         ? "the multi-release JAR file is not writable"
>         : "the ZIP file is not writable";
> 
>     throw new IOException(reason);
> }

Thanks for letting me know. Now I think about the "no filename" things is very sensible for core libraries.
Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095517691
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095520598

From duke at openjdk.org  Mon May 19 11:45:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 11:45:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <vDLKjPD5jCjmX48TWotMkgG33gtJslCXYZruYYYK9Ek=.90d99b76-fd7c-4692-9cf2-5d911e464831@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
 <j5vOlgg8d8NGtb-dbaiHUrwth3sCi-Z8tpGsqq1PnGY=.6e3719fd-a7a9-49ea-802c-7fccc764615f@github.com>
 <vDLKjPD5jCjmX48TWotMkgG33gtJslCXYZruYYYK9Ek=.90d99b76-fd7c-4692-9cf2-5d911e464831@github.com>
Message-ID: <cwPE0BJCUn06YWise_FGiUQoBW3cPBrn5s572awMbyw=.3c7f555d-48b1-449e-8426-a7c4b2c6f46d@github.com>

On Fri, 16 May 2025 15:19:26 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 230:
>> 
>>> 228:         // It requires 'entryLookup' and 'readOnly' to have safe defaults (which
>>> 229:         // is why they are the only non-final fields), and it requires that the
>>> 230:         // inode map has been initialized.
>> 
>> It's good to note that `determineReleaseVersion(...)` (and `createVersionedLinks(...)`) access instance fields of the `ZipFileSystem` being constructed. I think the comment however could be brief and should leave out the details about safe defaults.
>> 
>> Perhaps something like:
>> 
>>> determineReleaseVersion() and createVersionedLinks() access instance fields while 'this' ZipFileSystem instance is being constructed.
>
> Not sure I see a need for the last sentence regarding the inode map having to be initialized in addition to Jai's comments above

Fair enough, removed. I err on the side of over explaining things for future maintainers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095518822

From duke at openjdk.org  Mon May 19 11:48:58 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 11:48:58 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <ThoC8WQ91e8pQYP5dgeTipJhNUR2ScoPqp10NFoK_2U=.696fe9d5-a1a1-45fa-b263-994d7e5a7226@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <Oy0qyz1t7uiPneV1X2Na2hoQEknB3zxsIGFVoKvlm1o=.4919bdb1-b994-4afe-8fa4-200118e117bd@github.com>
 <ThoC8WQ91e8pQYP5dgeTipJhNUR2ScoPqp10NFoK_2U=.696fe9d5-a1a1-45fa-b263-994d7e5a7226@github.com>
Message-ID: <foMZ8Lss9V9s-LNKa8GuFixlUV3giyNHg6riTSJz6jU=.052e961e-5795-404e-a137-ee3a52f9420c@github.com>

On Fri, 16 May 2025 15:17:40 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 221:
>> 
>>> 219:         }
>>> 220:         // sm and existence check
>>> 221:         zfpath.getFileSystem().provider().checkAccess(zfpath, java.nio.file.AccessMode.READ);
>> 
>> Type name clash with existing AccessMode class. Since new enum is private, happy to rename.
>
> So perhaps change the name of the newly added enum

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095527265

From duke at openjdk.org  Mon May 19 11:52:56 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 11:52:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <rRYz0yPs9wwv_PRvxm3CnB5Ky_zD2ZfKgLKg72tDcC0=.7b8377a8-685a-4c5b-a77c-846d3c71b0d1@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
 <rRYz0yPs9wwv_PRvxm3CnB5Ky_zD2ZfKgLKg72tDcC0=.7b8377a8-685a-4c5b-a77c-846d3c71b0d1@github.com>
Message-ID: <ZvEqD9fvlgFYPWWfoXWrGMitBoD0R9DRaNaxJCuyJho=.d6753ba3-e48c-47b9-8920-8ec742353bc7@github.com>

On Fri, 16 May 2025 14:37:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes based on review feedback.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 241:
> 
>> 239:         this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath);
>> 240:         if (readOnly && accessMode == AccessMode.READ_WRITE) {
>> 241:             String reason = Files.isWritable(zfpath)
> 
> Nit - this additional call to Files.isWritable(...) can be avoided if we store the value of the previous call (a couple of lines above). I realize that the previous `Files.isWritable` is stashed at the end of the `||` conditionals to prevent it from being invoked in certain situations.
> 
> So maybe a better change would be something like:
> 
> 
> String reason = multiReleaseVersion.isPresent()
>    ? "A multi-release JAR file opened with a specified version is not writable"
>    : "The underlying ZIP file is not writable";
> 
> 
> which would then avoid any additional calls to `Files.isWritable`.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095532769

From duke at openjdk.org  Mon May 19 11:53:56 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Mon, 19 May 2025 11:53:56 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v16]
In-Reply-To: <GzzgfleafLsCdPZxFZ05PIGjejVSBNdfn-OU4eJMBBA=.60c11dfc-876e-4719-8e57-659ca5554cfe@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <GzzgfleafLsCdPZxFZ05PIGjejVSBNdfn-OU4eJMBBA=.60c11dfc-876e-4719-8e57-659ca5554cfe@github.com>
Message-ID: <argMlZQAGTefG5GDtGD7TnNH1lqGPLozrCo_YS-NeEA=.156eff07-f8fa-4b10-b566-7bb0375ba58b@github.com>

On Thu, 15 May 2025 22:32:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 308:

> 306:             "Ljdk/internal/ValueBased+Annotation;";
> 307:     private static final String REQUIRES_IDENTITY_ANNOTATION =
> 308:             "Ljdk/internal/RequieresIdentity;";

typo: RequieresIdentity -> RequiresIdentity

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2095534505

From duke at openjdk.org  Mon May 19 12:01:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 12:01:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <ThoC8WQ91e8pQYP5dgeTipJhNUR2ScoPqp10NFoK_2U=.696fe9d5-a1a1-45fa-b263-994d7e5a7226@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <Oy0qyz1t7uiPneV1X2Na2hoQEknB3zxsIGFVoKvlm1o=.4919bdb1-b994-4afe-8fa4-200118e117bd@github.com>
 <ThoC8WQ91e8pQYP5dgeTipJhNUR2ScoPqp10NFoK_2U=.696fe9d5-a1a1-45fa-b263-994d7e5a7226@github.com>
Message-ID: <wHGw94LU9IQR7VtId1gBNk--JdD9V3lyaHiO9K97-8Q=.8f22686c-5478-41bd-a5f2-c5eaa2a07cfe@github.com>

On Fri, 16 May 2025 15:35:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 259:
>> 
>>> 257: 
>>> 258:         // Pass "this" as a parameter after everything else is set up.
>>> 259:         this.rootdir = new ZipPath(this, new byte[]{'/'});
>> 
>> This could probably be set above release version etc. but it's a choice of either:
>> 1. waiting until everything is set up before passing "this"
>> 2. letting an incomplete "this" instance get passed to another class (possible escape risk?)
>> 
>> Though in this case the "incompleteness" is limited to it not being set up for multi-jar reading yet, which absolutely shouldn't affect the root path. It feels safer to me to leave it to the end, or perhaps we should dig in to ZipPath, figure out what it really wants here, and just call a different constructor?
>
> I think it was fine where it was originally given how rootdir is used

I'd rather at least have it over the last part where the non-final fields are modified (in that state it's an instance functionally identical to one opened on a non-MR JAR).

Looking through the ZipPath code, it seems to (currently) only need to read back the ZipCoder field (but I'm still nervous about restoring the "this" escape to its original location since the ZipPath code might change one day and rely on something not initialized).

I moved it so it's the last final field initialized, but I'll revert it completely if you want.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095549535

From duke at openjdk.org  Mon May 19 12:12:10 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 12:12:10 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v5]
In-Reply-To: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
Message-ID: <8zTn8lVzIJC3VY0ZfQIDrMMGSGenVKBnqnqUCoKXdTA=.11f09e50-e233-400b-80f1-c475f606d48a@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Changes based on review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/2326999b..a82e4019

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=03-04

  Stats: 65 lines in 4 files changed: 35 ins; 7 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

PR: https://git.openjdk.org/jdk/pull/25178

From duke at openjdk.org  Mon May 19 12:15:38 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 12:15:38 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
Message-ID: <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Fixed test.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/a82e4019..ea781c16

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=04-05

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

PR: https://git.openjdk.org/jdk/pull/25178

From jpai at openjdk.org  Mon May 19 12:26:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 12:26:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <3kUW3YQrrh5z2ZHea8beg7tgbzWX_wDH3_UWnLxNafE=.ad3a3955-6c95-4e9a-b448-6ecce423478c@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
 <PnCfACKzgUPJFmIl1jOToEJHjKVfNvQq8ZDYu9mgB4s=.48fc1387-134d-42a6-ae86-8a08e398a906@github.com>
 <3kUW3YQrrh5z2ZHea8beg7tgbzWX_wDH3_UWnLxNafE=.ad3a3955-6c95-4e9a-b448-6ecce423478c@github.com>
Message-ID: <0ARoEDpYgpVgOK9JOqD-Fbc5FC6kC0Nj48TQMoV9cu8=.95a929fa-edc0-4401-b2e2-cb179511cb0f@github.com>

On Mon, 19 May 2025 11:41:16 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 114:
>> 
>>> 112:     private final ZipPath rootdir;
>>> 113:     // Starts in readOnly (safe mode), but might be reset at the end of initialization.
>>> 114:     private boolean readOnly = true;
>> 
>> If `readOnly` gets used by some code when a `ZipFileSystem` instance is being constructed (which is why I believe this can't be a `final` field), then I think we should not change this value to `true`. In other words, would this change now have a chance of introducing a `ReadOnlyFileSystemException` when constructing the `ZipFileSystem` whereas before it wouldn't?
>
> ""would this change now have a chance of introducing a ReadOnlyFileSystemException when constructing the ZipFileSystem whereas before it wouldn't?""
> 
> If there was ever a "ReadOnlyFileSystemException" when initializing the ZipFileSystem, we have a very serious bug already. Since we already have the opening of Zip working for cases where the underlying file is read-only in the file system, it has to be true that no attempt is made to modify the file contents.
> 
> While I accept that this new code now calls out to functions with this flag in a different state to before, I believe this is an absolute improvement since:
> 
> 1. It is not acceptable to say to users "we support a read-only mode" if during initialization we might modify the file in any way (even including changing last-modification times etc.).
> 
> 2. All the evidence points to whichever operations are being done during init as being fundamentally "read-only" (both due to it working on read-only zip files, and there being no conceptual need to modify anything during setup).
> 
> I'll happily do a thorough audit of everything which could be affected by this change if that will give you confidence, but I would not want to change this code back to its default "read-write until stated otherwise" behaviour.

Hello David, I had another look at this code and after going through it, it looked like `readOnly` field can in fact be made `final` because of the refactoring changes that you did in this PR. I checked out your latest PR locally and here's the additional change I did:


diff --git a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
index e2fddd96fe8..f54b5360ac5 100644
--- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
+++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
@@ -110,8 +110,7 @@ class ZipFileSystem extends FileSystem {
     private final Path zfpath;
     final ZipCoder zc;
     private final ZipPath rootdir;
-    // Starts in readOnly (safe mode), but might be reset at the end of initialization.
-    private boolean readOnly = true;
+    private final boolean readOnly;
 
     // default time stamp for pseudo entries
     private final long zfsDefaultTimeStamp = System.currentTimeMillis();
@@ -227,11 +226,6 @@ static ZipAccessMode from(Object value) {
 
         // Determining a release version uses 'this' instance to read paths etc.
         Optional<Integer> multiReleaseVersion = determineReleaseVersion(env);
-
-        // Set the version-based lookup function for multi-release JARs.
-        this.entryLookup =
-                multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity());
-
         // We only allow read-write zip/jar files if they are not multi-release
         // JARs and the underlying file is writable.
         this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath);
@@ -241,6 +235,10 @@ static ZipAccessMode from(Object value) {
                     : "the ZIP file is not writable";
             throw new IOException(reason);
         }
+        // Set the version-based lookup function for multi-release JARs.
+        this.entryLookup =
+                multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity());
+
     }
 
     /**




With the refactoring changes you have done so far, we are now able to determine the ultimate value for `readOnly` before anything in the construction of `ZipFileSystem` would need access to it. Does this additional change look reasonable to you? I haven't run any tests against this change.

Making it `final` and having it not accessed until the ultimate value is set in the constructor would get us past any of the concerns we may have about the "initial" value of `readOnly`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095587777

From jpai at openjdk.org  Mon May 19 12:26:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 12:26:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <0ARoEDpYgpVgOK9JOqD-Fbc5FC6kC0Nj48TQMoV9cu8=.95a929fa-edc0-4401-b2e2-cb179511cb0f@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
 <PnCfACKzgUPJFmIl1jOToEJHjKVfNvQq8ZDYu9mgB4s=.48fc1387-134d-42a6-ae86-8a08e398a906@github.com>
 <3kUW3YQrrh5z2ZHea8beg7tgbzWX_wDH3_UWnLxNafE=.ad3a3955-6c95-4e9a-b448-6ecce423478c@github.com>
 <0ARoEDpYgpVgOK9JOqD-Fbc5FC6kC0Nj48TQMoV9cu8=.95a929fa-edc0-4401-b2e2-cb179511cb0f@github.com>
Message-ID: <PivCKhB6vrzWB9DJMCIoyz3LjHiovmNXkPwEO_7SEvg=.7a64990e-1639-4fab-aab1-99f079fb0141@github.com>

On Mon, 19 May 2025 12:22:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> ""would this change now have a chance of introducing a ReadOnlyFileSystemException when constructing the ZipFileSystem whereas before it wouldn't?""
>> 
>> If there was ever a "ReadOnlyFileSystemException" when initializing the ZipFileSystem, we have a very serious bug already. Since we already have the opening of Zip working for cases where the underlying file is read-only in the file system, it has to be true that no attempt is made to modify the file contents.
>> 
>> While I accept that this new code now calls out to functions with this flag in a different state to before, I believe this is an absolute improvement since:
>> 
>> 1. It is not acceptable to say to users "we support a read-only mode" if during initialization we might modify the file in any way (even including changing last-modification times etc.).
>> 
>> 2. All the evidence points to whichever operations are being done during init as being fundamentally "read-only" (both due to it working on read-only zip files, and there being no conceptual need to modify anything during setup).
>> 
>> I'll happily do a thorough audit of everything which could be affected by this change if that will give you confidence, but I would not want to change this code back to its default "read-write until stated otherwise" behaviour.
>
> Hello David, I had another look at this code and after going through it, it looked like `readOnly` field can in fact be made `final` because of the refactoring changes that you did in this PR. I checked out your latest PR locally and here's the additional change I did:
> 
> 
> diff --git a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
> index e2fddd96fe8..f54b5360ac5 100644
> --- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
> +++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
> @@ -110,8 +110,7 @@ class ZipFileSystem extends FileSystem {
>      private final Path zfpath;
>      final ZipCoder zc;
>      private final ZipPath rootdir;
> -    // Starts in readOnly (safe mode), but might be reset at the end of initialization.
> -    private boolean readOnly = true;
> +    private final boolean readOnly;
>  
>      // default time stamp for pseudo entries
>      private final long zfsDefaultTimeStamp = System.currentTimeMillis();
> @@ -227,11 +226,6 @@ static ZipAccessMode from(Object value) {
>  
>          // Determining a release version uses 'this' instance to read paths etc.
>          Optional<Integer> multiReleaseVersion = determineReleaseVersion(env);
> -
> -        // Set the version-based lookup function for multi-release JARs.
> -        this.entryLookup =
> -                multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity());
> -
>          // We only allow read-write zip/jar files if they are not multi-release
>          // JARs and the underlying file is writable.
>          this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath);
> @@ -241,6 +235,10 @@ static ZipAccessMode from(Object value) {
>                      : "the ZIP file is not writable";
>              throw new IOException(reason);
>          }
> +        // Set the version-based lookup function for multi-release JARs.
> +        this.entryLookup =
> +                multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity());
> +
>      }
>  
>      /**
> 
> 
> 
> 
> With the refactoring changes you have done so far, we are now able to determine the ultimate value for `readOnly` before anything in the construction of `ZipFileSystem` would need access to it. Does this additional change look reasonable to you? I haven't run any tests against this change.
> 
> Making it `final` and having it not accessed until the ultimate value is set in the constructor would get us past any of t...

On second thought, may be this isn't enough. I see that I missed the fact that `determineReleaseVersion()` requires access to `this`. Please leave this in the current form that you have in your PR. I need a few more moments to consider if anything needs to be changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095591964

From jpai at openjdk.org  Mon May 19 12:35:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 12:35:58 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
Message-ID: <JH2hlss8BlFw-QXtGyKrOyJbs2NMPQO1xXqwObkD-zY=.5cab5134-9110-4add-b711-a840cf71fd72@github.com>

On Mon, 19 May 2025 12:15:38 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test.

src/jdk.zipfs/share/classes/module-info.java line 290:

> 288:  *               already exist, and is incompatible with {@code "create"=true}.
> 289:  *               Specifying both will cause an {@code IllegalArgumentException}
> 290:  *               to be thrown when the Zip filesystem is created

To be precise, perhaps this last sentence should be reworded to:

> Specifying {@code create} as {@code true} and {@code accessMode} as {@code readOnly} will cause an {@code IllegalArgumentException} to be thrown when the ZIP filesystem is created.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095608509

From jpai at openjdk.org  Mon May 19 12:44:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 12:44:07 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v3]
In-Reply-To: <zGh_FEPRnTiW34WQMTQfBNXsGT957vTaMn40uP3vtdk=.f6f73eab-2c69-483b-827b-c15a692bd3a2@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <-3H9Zm4fw4NFs1L-iUHe4bR8NSj3pvI-GPXSQyNqJbA=.e17218ea-af9e-4873-ae48-b7eea6111709@github.com>
 <OUM38oaCUaIARxcaYgrAU4yKlhb3vDYlD5x1dHP4h5E=.f1ab1320-bb3b-43e1-814b-5493aeeb99c8@github.com>
 <zGh_FEPRnTiW34WQMTQfBNXsGT957vTaMn40uP3vtdk=.f6f73eab-2c69-483b-827b-c15a692bd3a2@github.com>
Message-ID: <vj2vqXyfWhdNclKxYd6Jw_1keYXruLbi0vpZ9HBXd6U=.626914a5-36d0-4c85-9627-8852a4a4ca12@github.com>

On Thu, 15 May 2025 17:27:42 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 167:
>> 
>>> 165:                     return null;
>>> 166:                 }
>>> 167:                 case String label when READ_WRITE.label.equals(label) -> {
>> 
>> I haven't yet fully caught up on the newer features of switch/case. Does this have any advantage as compared to the simpler:
>> 
>> 
>> case "readWrite" -> {
>>    return READ_WRITE;
>> }
>> case "readOnly" -> {
>>    return READ_ONLY;
>> }
>
> Or just an if :)
> 
> The reason for the new style was the "need" for the "String label when" qualifier, which I don't actually need because String.equals(xx) copes with being given non-strings fine. You can't use the syntax you suggested in the new switch since "value" isn't a String.

Thank you for updating this to a traditional and trivial `if/else`.

>> src/jdk.zipfs/share/classes/module-info.java line 277:
>> 
>>> 275:  *   <td>
>>> 276:  *       A value defining the desired read/write access mode of the file system
>>> 277:  *       (either <em>read-write</em> or <em>read-only</em>).
>> 
>> This line is slightly confusing. Initially I thought `read-write` and `read-only` are the actual values that this environment property will accept. But further review suggests that the actual literals supported are `readOnly` and `readWrite` and this line here I think is trying to explain the supported semantics of the file system.
>> 
>> Perhaps we could reword this to something like:
>> 
>>>
>>> A value defining the desired access mode of the file system. A ZIP file system can be created to allow for read-write access or read-only access.
>
> Yeah, I tried to distinguish the accessMode flags (for which there are 3 states, ro, rw, n/a) and the final state of the file system from fs.isReadOnly(). Hence using `<em>...</em>` for whenever the actually resulting state is mentioned. I guess it wasn't clear enough.

Thank you for updating this part, this is much more clearer now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095625151
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095622485

From jpai at openjdk.org  Mon May 19 12:44:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 12:44:08 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
Message-ID: <125rqfO-1BASoEzo9N25YwMIsU8yaPYuI10so0ePVVk=.a776aa87-f1d5-4da1-bc49-06af12e3b066@github.com>

On Mon, 19 May 2025 12:15:38 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 210:

> 208:             }
> 209:         }
> 210:         // sm and existence check

Nit - this is pre-existing, but would be good to cleanup. The "sm" here refers to SecurityManager. In JDK mainline, the SecurityManager is no longer present. So it would be good to change this comment to just "existence check" and remove reference to "sm".

src/jdk.zipfs/share/classes/module-info.java line 304:

> 302:  *           </li>
> 303:  *       </ul>
> 304:  *       The access mode has no effect on reported POSIX file permissions (in cases

For consistency, I think this should be:

> The {@code accessMode} has no ....

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095621216
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095616802

From jpai at openjdk.org  Mon May 19 12:50:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 12:50:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
Message-ID: <OMrsQbofYv_9rxfp3ATSFLS9rNDWnmGJsB5miGj4gyM=.a94963af-e170-4cc9-bf93-e4c2e4e7cbca@github.com>

On Mon, 19 May 2025 12:15:38 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test.

test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 208:

> 206:         // Multi-release JARs, when opened with a specified version are inherently read-only.
> 207:         Path multiReleaseJar = createMultiReleaseJar();
> 208:         try (FileSystem fs = FileSystems.newFileSystem(multiReleaseJar, Map.of("accessMode", "readWrite"))) {

I wonder if the ZIP filesystem implementation should throw an exception in this case. In the case where the application code has explicitly stated `accessMode=readWrite`, if the underlying file `Path` isn't writable, then we currently throw an `IOException`. I think we should specify and implement the same for the case where `accessMode=readWrite` and the file is a multi-release JAR file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095637058

From jpai at openjdk.org  Mon May 19 12:56:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 12:56:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
Message-ID: <Qo2HjVlr4iBSMNoYYGKLb6nXVIeUWthzo8DZLswHpIc=.b47eca39-a611-47a0-bdf2-ae01d69552f0@github.com>

On Mon, 19 May 2025 12:15:38 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test.

test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 224:

> 222:         // Underlying file is read-only.
> 223:         Path readOnlyZip = Utils.createJarFile("read_only.zip", Map.of("file.txt", "Hello World"));
> 224:         readOnlyZip.toFile().setReadOnly();

`java.io.File.setReadOnly()` specifies:

> On some platforms it may be possible to start the
> Java virtual machine with special privileges that allow it to modify
> files that are marked read-only. Whether or not a read-only file or
> directory may be deleted depends upon the underlying system.

So I think we should run the subsequent asserts in this test after first checking if the file was set to read-only. If it isn't then we should skip the test. Something like:


final boolean marked  = readOnlyZip.toFile().setReadOnly();
Assumptions.assumeTrue(marked, "skipping test since " + readOnlyZip + " couldn't be marked read-only");
assertThrows(IOException.class,
                () -> FileSystems.newFileSystem(readOnlyZip, Map.of("accessMode", "readWrite")));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095650541

From jpai at openjdk.org  Mon May 19 13:03:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 13:03:00 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
Message-ID: <yK9YTQv-mY5w7pMOgJkRei_MUZ0Xo8VCHpeDcLkfMw8=.110abfe3-85e3-490c-a585-7a404588edc8@github.com>

On Mon, 19 May 2025 12:15:38 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test.

On a general note, all of these updated files will require a copyright year update.

test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 239:

> 237:             assertTrue(fs.isReadOnly());
> 238:             if (!"First version".equals(Files.readString(fs.getPath("file.txt"), UTF_8))) {
> 239:                 fail("unexpected file content");

Nit, for this and the other new `fail` statements, it might be good to include the unexpected file content in the fail message. If at all the test fails for whatever reason, that additional detail usually help to quickly debug the failures. Or maybe just replace the `if` followed by a `fail` with an `assertEquals()` call.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25178#issuecomment-2890930980
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095657482

From jpai at openjdk.org  Mon May 19 13:09:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 13:09:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: <Oy0qyz1t7uiPneV1X2Na2hoQEknB3zxsIGFVoKvlm1o=.4919bdb1-b994-4afe-8fa4-200118e117bd@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <Oy0qyz1t7uiPneV1X2Na2hoQEknB3zxsIGFVoKvlm1o=.4919bdb1-b994-4afe-8fa4-200118e117bd@github.com>
Message-ID: <rRRlOf-SJPbEeqWaoYRB5BNzhSDCyIS8gGwEnmRDx1U=.5702bbae-a7e6-4e27-aa10-a38e54a06077@github.com>

On Mon, 12 May 2025 10:01:05 GMT, David Beaumont <duke at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed test.
>
> test/jdk/jdk/nio/zipfs/Utils.java line 52:
> 
>> 50:      */
>> 51:     static Path createJarFile(String name, String... entries) throws IOException {
>> 52:         Path jarFile = Paths.get(name);
> 
> Previous tests always had the test file called the same thing.
> Note that in jtreg tests, the file of the same name often already exists in the test directory.
> I tried adding a "ensure file doesn't already exist" check and it fails lots of tests.

It's interesting that we have several places in the test which use this `Utils.createJarFile()` and pass it a test specific JAR file name and yet this utility was ignoring the passed name hard coding the name to `basic.jar`. It appears to be an oversight and your fix here I believe is a good thing.

> I tried adding a "ensure file doesn't already exist" check and it fails lots of tests.

I think it's OK in its current form to allow the file to be overwritten. Plus, you have also updated the javadoc of this test utility method to explicitly state its current behaviour, which I think is enough to let the call sites know how this behaves.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095672596

From jpai at openjdk.org  Mon May 19 13:09:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 13:09:57 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
Message-ID: <ZQnlEQeCpZKcyYGy5ZU5wV-Zzx9jgI7m5JBToNkaLlE=.3f696f9d-658a-4d2f-847e-80d44b26450d@github.com>

On Mon, 19 May 2025 12:15:38 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test.

test/jdk/jdk/nio/zipfs/Utils.java line 52:

> 50:      */
> 51:     static Path createJarFile(String name, String... entries) throws IOException {
> 52:         Path jarFile = Paths.get(name);

In recent times we have replaced `Paths.get(...)` call in the JDK code with `Path.of(...)`. We should do the same here and the other line in this utility class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095676145

From jpai at openjdk.org  Mon May 19 13:14:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 13:14:58 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
Message-ID: <GhInw5TN33TWbMaqA-rG3RwLAdH4PE57Sq1tKdTyvNw=.9f58e146-9a74-4055-bb04-54ee7c8b221f@github.com>

On Mon, 19 May 2025 12:15:38 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test.

test/jdk/jdk/nio/zipfs/Utils.java line 48:

> 46:      *
> 47:      * @param name the file name of the jar file to create in the working directory.
> 48:      * @param entries a list of JAR entries to be populated with random bytes.

Nit - maybe reword this to:

> @param entries JAR file entry names, whose content will be populated with random bytes.

test/jdk/jdk/nio/zipfs/Utils.java line 78:

> 76:      *
> 77:      * @param name the file name of the jar file to create in the working directory.
> 78:      * @param entries a map of relative file name path strings to file content

Nit - I think we should replace this description with something like:

> @param entries a map of JAR file entry names to entry content

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095686442
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095684096

From jpai at openjdk.org  Mon May 19 13:25:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 13:25:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
Message-ID: <87vFNxeXLspOxvNyBLBbVyAnEMwLSTCokW0o1fItFRM=.27c91bbb-9269-4b12-a443-8070dd61048f@github.com>

On Mon, 19 May 2025 12:15:38 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test.

test/jdk/jdk/nio/zipfs/TestPosix.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, 2025, SAP SE. All rights reserved.

For non-Oracle copyright lines like these, we don't edit them and instead we introduce a newline for the Oracle copyright year. So we should revert the change to this line and introduce the following new line just after this current one:

* Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095707195

From swen at openjdk.org  Mon May 19 13:32:55 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 19 May 2025 13:32:55 GMT
Subject: RFR: 8357081: Removed unused methods of HexDigits
In-Reply-To: <NmneRyd1Xg5PGjAiG1Pgq5dqkWMiE23LRjALLutkoyA=.912425d2-b549-40f7-bea2-46f2f869fa30@github.com>
References: <NmneRyd1Xg5PGjAiG1Pgq5dqkWMiE23LRjALLutkoyA=.912425d2-b549-40f7-bea2-46f2f869fa30@github.com>
Message-ID: <NulJKeNO7Zgan8NGlPn6EYf8Yit6U5DLZ-oC7Bf1PWc=.7afedcce-aefd-41ec-a5e7-978ea018c16e@github.com>

On Thu, 15 May 2025 22:03:22 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In HexDigits, getCharsLatin1 and getCharsUTF16 are no longer used, so remove these methods

The getCharsLatin1/getCharsUTF16 methods of HexDigits may be used in j.u.Formatter/HexFormat in the future. For this reason, should we keep them? @cl4es

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25258#issuecomment-2891047804

From duke at openjdk.org  Mon May 19 13:33:56 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 13:33:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: <125rqfO-1BASoEzo9N25YwMIsU8yaPYuI10so0ePVVk=.a776aa87-f1d5-4da1-bc49-06af12e3b066@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
 <125rqfO-1BASoEzo9N25YwMIsU8yaPYuI10so0ePVVk=.a776aa87-f1d5-4da1-bc49-06af12e3b066@github.com>
Message-ID: <pW3Al7kMYKYayjp3MekYrzduFZ3DxT2Yh9_nPdVoO7U=.abcae40f-268b-4782-8b89-c53d9cd171bf@github.com>

On Mon, 19 May 2025 12:39:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed test.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 210:
> 
>> 208:             }
>> 209:         }
>> 210:         // sm and existence check
> 
> Nit - this is pre-existing, but would be good to cleanup. The "sm" here refers to SecurityManager. In JDK mainline, the SecurityManager is no longer present. So it would be good to change this comment to just "existence check" and remove reference to "sm".

Done.

> src/jdk.zipfs/share/classes/module-info.java line 290:
> 
>> 288:  *               already exist, and is incompatible with {@code "create"=true}.
>> 289:  *               Specifying both will cause an {@code IllegalArgumentException}
>> 290:  *               to be thrown when the Zip filesystem is created
> 
> To be precise, perhaps this last sentence should be reworded to:
> 
>> Specifying {@code create} as {@code true} and {@code accessMode} as {@code readOnly} will cause an {@code IllegalArgumentException} to be thrown when the ZIP filesystem is created.

Done.

> src/jdk.zipfs/share/classes/module-info.java line 304:
> 
>> 302:  *           </li>
>> 303:  *       </ul>
>> 304:  *       The access mode has no effect on reported POSIX file permissions (in cases
> 
> For consistency, I think this should be:
> 
>> The {@code accessMode} has no ....

Done.

> test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 208:
> 
>> 206:         // Multi-release JARs, when opened with a specified version are inherently read-only.
>> 207:         Path multiReleaseJar = createMultiReleaseJar();
>> 208:         try (FileSystem fs = FileSystems.newFileSystem(multiReleaseJar, Map.of("accessMode", "readWrite"))) {
> 
> I wonder if the ZIP filesystem implementation should throw an exception in this case. In the case where the application code has explicitly stated `accessMode=readWrite`, if the underlying file `Path` isn't writable, then we currently throw an `IOException`. I think we should specify and implement the same for the case where `accessMode=readWrite` and the file is a multi-release JAR file.

It does throw if accessMode=readWrite and the result is not writable for any reason.


this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath);
if (readOnly && accessMode == ZipAccessMode.READ_WRITE) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095718428
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095714913
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095715684
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095723172

From duke at openjdk.org  Mon May 19 13:39:03 2025
From: duke at openjdk.org (kieran-farrell)
Date: Mon, 19 May 2025 13:39:03 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC
 9562
Message-ID: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>

With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 

The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).

The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:


- random-byte-only - 99.8%
- higher-precision - 3.5%
- counter-based - 0%


Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:

- random-byte-only   143.487 ? 10.932  ns/op
- higher-precision      149.651 ?  8.438 ns/op
- counter-based         245.036 ?  2.943  ns/op

The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.

-------------

Commit messages:
 - update to add ns percision
 - 3 variantions
 - UUID src and test

Changes: https://git.openjdk.org/jdk/pull/25303/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334015
  Stats: 108 lines in 2 files changed: 104 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303

PR: https://git.openjdk.org/jdk/pull/25303

From jpai at openjdk.org  Mon May 19 13:43:04 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 13:43:04 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: <pW3Al7kMYKYayjp3MekYrzduFZ3DxT2Yh9_nPdVoO7U=.abcae40f-268b-4782-8b89-c53d9cd171bf@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
 <125rqfO-1BASoEzo9N25YwMIsU8yaPYuI10so0ePVVk=.a776aa87-f1d5-4da1-bc49-06af12e3b066@github.com>
 <pW3Al7kMYKYayjp3MekYrzduFZ3DxT2Yh9_nPdVoO7U=.abcae40f-268b-4782-8b89-c53d9cd171bf@github.com>
Message-ID: <gxrrLtvDZRbQNo9e1yPSJMKU1jnHT3wNJ6RQ3-roLJ4=.f938c683-670f-411b-aa11-3c70334927bf@github.com>

On Mon, 19 May 2025 13:31:04 GMT, David Beaumont <duke at openjdk.org> wrote:

>> test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 208:
>> 
>>> 206:         // Multi-release JARs, when opened with a specified version are inherently read-only.
>>> 207:         Path multiReleaseJar = createMultiReleaseJar();
>>> 208:         try (FileSystem fs = FileSystems.newFileSystem(multiReleaseJar, Map.of("accessMode", "readWrite"))) {
>> 
>> I wonder if the ZIP filesystem implementation should throw an exception in this case. In the case where the application code has explicitly stated `accessMode=readWrite`, if the underlying file `Path` isn't writable, then we currently throw an `IOException`. I think we should specify and implement the same for the case where `accessMode=readWrite` and the file is a multi-release JAR file.
>
> It does throw if accessMode=readWrite and the result is not writable for any reason.
> 
> 
> this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath);
> if (readOnly && accessMode == ZipAccessMode.READ_WRITE) {

Actually looking at the current proposed implementation in ZipFileSystem where we have:



this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath);
if (readOnly && accessMode == ZipAccessMode.READ_WRITE) {
    String reason = multiReleaseVersion.isPresent()
            ? "the multi-release JAR file is not writable"
            : "the ZIP file is not writable";
    throw new IOException(reason);
}


I'm surprised this test currently passes. Shouldn't this line in the test lead to an `IOException`:

FileSystems.newFileSystem(multiReleaseJar, Map.of("accessMode", "readWrite")))


Did I misread something?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095732163

From duke at openjdk.org  Mon May 19 13:43:07 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 13:43:07 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: <yK9YTQv-mY5w7pMOgJkRei_MUZ0Xo8VCHpeDcLkfMw8=.110abfe3-85e3-490c-a585-7a404588edc8@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
 <yK9YTQv-mY5w7pMOgJkRei_MUZ0Xo8VCHpeDcLkfMw8=.110abfe3-85e3-490c-a585-7a404588edc8@github.com>
Message-ID: <jHQATVS-gYSiA5jmmx5BcSGAfltyLGsePlFlkTNguxE=.876bcafe-e369-4409-9cd4-0333b7ff8b62@github.com>

On Mon, 19 May 2025 12:58:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed test.
>
> test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 239:
> 
>> 237:             assertTrue(fs.isReadOnly());
>> 238:             if (!"First version".equals(Files.readString(fs.getPath("file.txt"), UTF_8))) {
>> 239:                 fail("unexpected file content");
> 
> Nit, for this and the other new `fail` statements, it might be good to include the unexpected file content in the fail message. If at all the test fails for whatever reason, that additional detail usually help to quickly debug the failures. Or maybe just replace the `if` followed by a `fail` with an `assertEquals()` call.

Urgh, my bad. That's the hangover from these tests being first implemented in the ZipFSTester class without access to sensible assert methods.

> test/jdk/jdk/nio/zipfs/TestPosix.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2019, 2025, SAP SE. All rights reserved.
> 
> For non-Oracle copyright lines like these, we don't edit them and instead we introduce a newline for the Oracle copyright year. So we should revert the change to this line and introduce the following new line just after this current one:
> 
> * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

Thanks! Done.

> test/jdk/jdk/nio/zipfs/Utils.java line 48:
> 
>> 46:      *
>> 47:      * @param name the file name of the jar file to create in the working directory.
>> 48:      * @param entries a list of JAR entries to be populated with random bytes.
> 
> Nit - maybe reword this to:
> 
>> @param entries JAR file entry names, whose content will be populated with random bytes.

Done.

> test/jdk/jdk/nio/zipfs/Utils.java line 52:
> 
>> 50:      */
>> 51:     static Path createJarFile(String name, String... entries) throws IOException {
>> 52:         Path jarFile = Paths.get(name);
> 
> In recent times we have replaced `Paths.get(...)` call in the JDK code with `Path.of(...)`. We should do the same here and the other line in this utility class.

Good spot, thanks.
Sadly I'm currently working on other code in which Path.of() is not permitted, so I won't naturally spot these things.

> test/jdk/jdk/nio/zipfs/Utils.java line 78:
> 
>> 76:      *
>> 77:      * @param name the file name of the jar file to create in the working directory.
>> 78:      * @param entries a map of relative file name path strings to file content
> 
> Nit - I think we should replace this description with something like:
> 
>> @param entries a map of JAR file entry names to entry content

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095730823
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095740846
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095740347
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095735890
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095738222

From duke at openjdk.org  Mon May 19 13:46:16 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 13:46:16 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v7]
In-Reply-To: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
Message-ID: <oEMPKMM_YtpjvJ8xbNd11yqcEfHOEcLp1aRTc4C6Hxc=.04b891c7-2d23-4728-a5a0-6a8ad069b202@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Changes based on feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/ea781c16..46b19106

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=05-06

  Stats: 26 lines in 5 files changed: 6 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

PR: https://git.openjdk.org/jdk/pull/25178

From vromero at openjdk.org  Mon May 19 13:47:50 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 19 May 2025 13:47:50 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v17]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <VH-SkrPWeoWzA0EHZCD1Ys5QIBa8jVhqZJas6wJsryo=.ea1082d8-e75e-4725-a4ab-c66d669a289a@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/def2505f..cf92614c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=15-16

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

PR: https://git.openjdk.org/jdk/pull/24746

From jpai at openjdk.org  Mon May 19 14:04:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 14:04:08 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: <gxrrLtvDZRbQNo9e1yPSJMKU1jnHT3wNJ6RQ3-roLJ4=.f938c683-670f-411b-aa11-3c70334927bf@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
 <125rqfO-1BASoEzo9N25YwMIsU8yaPYuI10so0ePVVk=.a776aa87-f1d5-4da1-bc49-06af12e3b066@github.com>
 <pW3Al7kMYKYayjp3MekYrzduFZ3DxT2Yh9_nPdVoO7U=.abcae40f-268b-4782-8b89-c53d9cd171bf@github.com>
 <gxrrLtvDZRbQNo9e1yPSJMKU1jnHT3wNJ6RQ3-roLJ4=.f938c683-670f-411b-aa11-3c70334927bf@github.com>
Message-ID: <Vi7eSqbqSdLDX5qDn6rpYAHA7JBMWJdnMiuzVnJS7rY=.ff48d9d8-b153-4d96-b906-1371e4e7aa13@github.com>

On Mon, 19 May 2025 13:35:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Did I misread something?

I missed the fact that for a multi-release JAR file, we mark the file system as read-only, only if the `multi-release` or the `releaseVersion` environment properties have been set. So in this test here, the file system can indeed be opened in read-write mode. Sorry about the noise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095779244

From duke at openjdk.org  Mon May 19 14:04:08 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 14:04:08 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v8]
In-Reply-To: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
Message-ID: <VUZ--UhBeE3vrj1SVWYT5iIrsCzNRYhJIRCjfmI3-3w=.b2ad7d74-4536-4668-8e76-a2617370734e@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Changes based on feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/46b19106..3b3fe2d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=06-07

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

PR: https://git.openjdk.org/jdk/pull/25178

From duke at openjdk.org  Mon May 19 14:04:09 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 14:04:09 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v6]
In-Reply-To: <Qo2HjVlr4iBSMNoYYGKLb6nXVIeUWthzo8DZLswHpIc=.b47eca39-a611-47a0-bdf2-ae01d69552f0@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <L6uslcc9kALOmrdKbIkcwvwJBzhfUPytOESNdk5QwEQ=.64fd8f40-6156-43e2-ba07-46643d2d5e52@github.com>
 <Qo2HjVlr4iBSMNoYYGKLb6nXVIeUWthzo8DZLswHpIc=.b47eca39-a611-47a0-bdf2-ae01d69552f0@github.com>
Message-ID: <ejHLzbYuCdvbMp5r8v_fPzsIMkbpt-mueAJ5J-Eu6fw=.72bdc5be-d167-440c-b4ed-52b45e68408b@github.com>

On Mon, 19 May 2025 12:54:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed test.
>
> test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 224:
> 
>> 222:         // Underlying file is read-only.
>> 223:         Path readOnlyZip = Utils.createJarFile("read_only.zip", Map.of("file.txt", "Hello World"));
>> 224:         readOnlyZip.toFile().setReadOnly();
> 
> `java.io.File.setReadOnly()` specifies:
> 
>> On some platforms it may be possible to start the
>> Java virtual machine with special privileges that allow it to modify
>> files that are marked read-only. Whether or not a read-only file or
>> directory may be deleted depends upon the underlying system.
> 
> So I think we should run the subsequent asserts in this test after first checking if the file was set to read-only. If it isn't then we should skip the test. Something like:
> 
> 
> final boolean marked  = readOnlyZip.toFile().setReadOnly();
> Assumptions.assumeTrue(marked, "skipping test since " + readOnlyZip + " couldn't be marked read-only");
> assertThrows(IOException.class,
>                 () -> FileSystems.newFileSystem(readOnlyZip, Map.of("accessMode", "readWrite")));

Done. Thanks for introducing me to the Assumptions class :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095780258

From cay.horstmann at gmail.com  Mon May 19 14:12:55 2025
From: cay.horstmann at gmail.com (Cay Horstmann)
Date: Mon, 19 May 2025 16:12:55 +0200
Subject: Towards a JSON API for the JDK
In-Reply-To: <1926856506.269259526.1747642393592.JavaMail.zimbra@univ-eiffel.fr>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <52514642-e172-4096-a616-a2c9a9787552@gmail.com>
 <1926856506.269259526.1747642393592.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <5cffce95-71ab-40a8-87ec-edeb774e9890@gmail.com>

Il 19/05/25 10:13, Remi Forax ha scritto:
>> If only there was some deconstruction magic that approximates the JavaScript
>> code
>>
>> const doc = { name: "John", age: 30 }
>> const { name, age } = doc
> 
> We already have that, it's called a record :)
> 
> Basically, you are advocating for a mapping JsonObject <--> record.
> 
> [...]
> 
>>
>> Cheers,
>>
>> Cay
>>
> 
> Here is a simple JsonObject mapper using java.util.json types.
>    https://github.com/forax/json-object-mapper

That's interesting, but I don't think it works as a solution to read generic JSON. I have to deal with much JSON that is at best semi-structured. And anyway, databinding is is excluded from the scope of the core Java JSON API.

Let me explain in more detail what I was trying say offhandedly. For tree traversal, Jackson has isXxx, asXxx, get, path (for "safe" chaining), and JSON Pointer support. The core Java JSON library proposes to rely on pattern matching instead. With the capabilities of pattern matching today, that is unappealing. Could it get better with some of the ideas in https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns?

Let's assume we have a factory method

var doc = JsonObject.of("name", JsonString.of("John"), "age", JsonNumber.of(30));

Could there be a matching deconstructor? It couldn't be overloads like

public inverse JsonObject of(String key1, JsonValue value1, String key2, JsonValue value2)

The deconstructor could not know which entries to pick and in what order. But similar to the regex example in the design note, one could define a "pattern object" holding the keys:

case JsonObject.withKeys("name", "age").of(JsonString.of(String name), JsonNumber.of(long age)) ->

Maybe even:

case JsonObject.withKeys("name", "age").fromUntyped(String name, Long age) ->

With nested objects:

case JsonObject.withKeys("user").of(
     JsonObject.withKeys("name", "age").fromUntyped(String name, Long age)) -> { /* use name, age */ }
default -> /* deal with error */

I made some impromptu design decisions to get this far, as well as assumptions how deconstruction would eventually work. Which may well be wrong.

In Jackson, it would be

try {
     JsonNode user = nestedDoc.get("user");
     String name = user.get("name").asText();
     int age = user.get("age").asInt();
     /* use name, age */
} catch (...) { /* deal with error */ }

At first I thought the pattern matching version would be worse, but I admit that the structural safety is appealing.

Cheers,

Cay



-- 

Cay S. Horstmann | https://horstmann.com


From snazy at snazy.de  Mon May 19 14:34:35 2025
From: snazy at snazy.de (Robert Stupp)
Date: Mon, 19 May 2025 16:34:35 +0200
Subject: ClassLoader.definePackage() throwing IllegalArgumentException
Message-ID: <8c837531-0bb5-4456-8042-5bc024d38542@snazy.de>

Hi,

I'd like to follow up on https://bugs.openjdk.org/browse/JDK-8350547.

TL;DR java.lang.ClassLoader.definePackage() (the one taking 8 arguments) 
clearly defines that a IllegalArgumentException is thrown, "if a package 
of the given name is already defined by this class loader".

However, it seems that it's a common oversight that an IAE can be 
thrown. Examples are the CDI reference implementation ("Weld") and 
Quarkus. In other words: "naively" calling 'definePackage' without a 
retry on IAE leads to issues when defining classes in custom class 
loaders in parallel.

The CL.definePackage() API is there since Java 1.2, and I admit that my 
initial approach to change the currently observed behavior isn't going 
to fly.

I thought about adding more information to the message of the IAE thrown 
in 'definePackage()', but even this "innocent" change could break the 
observed behavior / existing code.

One option could be to add a new function 'definePackageIfNotExists()` 
to j.l.ClassLoader, which works like the existing 'definePackage()' but 
returns the existing package, if it already exists and is compatible 
with the given arguments. The downside is that it could still throw, if 
the arguments are incompatible (e.g. a different "implTitle") - so it 
might just be a less likely, but still possible way of unexpectedly 
hitting an IAE.

With 'definePackageIfNotExists()` it might be possible to deprecate 
'definePackage()', but that deprecation largely depends on the actual 
usage of it in the wild, which I do not know. I'm not sure whether such 
a deprecation can fly. And the next question would be whether it can be 
deprecated for removal ; and if yes, when could it be removed.

Actually, even a new 'definePackageIfNotExists()` could break existing 
code, in case an implementation overrides the existing 'definePackage' 
but not 'definePackageIfNotExists()`.

Another question to which I don't know the answer is whether the 7 
package attribute parameters specification/implementation 
title/version/vendor + seal-base do fit "all today's wishes & needs". 
Or: is there demand for a "better" or "more flexible" way to define a 
class/package? Or: can that API be redefined in a different way tailored 
for today's needs and wishes? And are there any that would justify such 
an effort?

Overall, I'm a bit lost on what the "best" way would be for this. Maybe 
the answer is that there is no better way yet, which is also fine. Maybe 
the only "fix" is to enhance the Javadocs and prominently highlight the 
behavior and add a "reference code snippet" how 'definePackage()' should 
be used and why.

Robert

-- 
Robert Stupp
@snazy


From vromero at openjdk.org  Mon May 19 14:35:40 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 19 May 2025 14:35:40 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v18]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <MPgukNWo0agINMH9L7hhU13BNo-_ZlWV311WmPyZSVQ=.d4b4e536-4280-416c-91f9-910561b97169@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - Merge branch 'master' into JDK-8354556
 - review comments
 - addressing review comments
 - addressing review comments
 - update warning message
 - Merge branch 'master' into JDK-8354556
 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - additional changes from Archie
 - removing dead code
 - integrating code from Archie
 - ... and 29 more: https://git.openjdk.org/jdk/compare/265d6301...904bd4cd

-------------

Changes: https://git.openjdk.org/jdk/pull/24746/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=17
  Stats: 647 lines in 32 files changed: 562 ins; 37 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

PR: https://git.openjdk.org/jdk/pull/24746

From forax at univ-mlv.fr  Mon May 19 14:54:46 2025
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 19 May 2025 16:54:46 +0200 (CEST)
Subject: Towards a JSON API for the JDK
In-Reply-To: <5cffce95-71ab-40a8-87ec-edeb774e9890@gmail.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <52514642-e172-4096-a616-a2c9a9787552@gmail.com>
 <1926856506.269259526.1747642393592.JavaMail.zimbra@univ-eiffel.fr>
 <5cffce95-71ab-40a8-87ec-edeb774e9890@gmail.com>
Message-ID: <1366070687.269600941.1747666486192.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "cay horstmann" <cay.horstmann at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Monday, May 19, 2025 4:12:55 PM
> Subject: Re: Towards a JSON API for the JDK

> Il 19/05/25 10:13, Remi Forax ha scritto:
>>> If only there was some deconstruction magic that approximates the JavaScript
>>> code
>>>
>>> const doc = { name: "John", age: 30 }
>>> const { name, age } = doc
>> 
>> We already have that, it's called a record :)
>> 
>> Basically, you are advocating for a mapping JsonObject <--> record.
>> 
>> [...]
>> 
>>>
>>> Cheers,
>>>
>>> Cay
>>>
>> 
>> Here is a simple JsonObject mapper using java.util.json types.
>>    https://github.com/forax/json-object-mapper
> 
> That's interesting, but I don't think it works as a solution to read generic
> JSON. I have to deal with much JSON that is at best semi-structured. And
> anyway, databinding is is excluded from the scope of the core Java JSON API.

If the mapping is driven by the record definition then mapping and matching are mostly equivalent,
mapping throws exceptions when something goes wrong while matching returns something saying no-match.

Here is an example,

    record Person(String name, int age) {}

    var recordMapper = RecordMapper.of(MethodHandles.lookup());

    JsonObject json = ...

    if (recordMapper.match(json, Person.class) instanceof Person(String name, int age)) {
      // can use name and age here
    }

see https://github.com/forax/json-object-mapper/blob/master/src/test/java/json/RecordMapperTest.java#L40

[...]

> 
> At first I thought the pattern matching version would be worse, but I admit that
> the structural safety is appealing.

I agree.

> 
> Cheers,
> 
> Cay

R?mi

From acobbs at openjdk.org  Mon May 19 15:01:55 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 19 May 2025 15:01:55 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface
In-Reply-To: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
Message-ID: <Om5uUGrxdGADt0an95YYA_rknawkgxv19eJ7NPTz7e4=.3ebfe48c-5a7f-4d2d-a830-4929cff5083c@github.com>

On Mon, 19 May 2025 07:25:17 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.

IMHO it makes sense. It's the min/max analog to a stable sort.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-2891353170

From rgiulietti at openjdk.org  Mon May 19 15:06:56 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 19 May 2025 15:06:56 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v8]
In-Reply-To: <Al3Piz6jgHq6TSsjiGH5pHsMSo94in2GW61MZ5ZW8Xc=.5696e283-7f95-4fa5-a900-ff679735ac18@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <Al3Piz6jgHq6TSsjiGH5pHsMSo94in2GW61MZ5ZW8Xc=.5696e283-7f95-4fa5-a900-ff679735ac18@github.com>
Message-ID: <hG0FP0V7YdSEkU0E-nXsSmOIjOQ0WY7Upi2h4P4i1r8=.20a07d56-19ee-45fd-a802-361301cf4aaf@github.com>

On Fri, 16 May 2025 11:10:12 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   An optimization

src/java.base/share/classes/java/math/BigInteger.java line 5034:

> 5032:      */
> 5033:     private byte[] magSerializedForm() {
> 5034:         byte[] result = new byte[(magBitLength() + 7) >>> 3];

I think there's a risk of overflow, so consider
Suggestion:

        byte[] result = new byte[(magBitLength() - 1 >>> 3) + 1];

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2095920641

From rgiulietti at openjdk.org  Mon May 19 15:06:57 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 19 May 2025 15:06:57 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v8]
In-Reply-To: <hG0FP0V7YdSEkU0E-nXsSmOIjOQ0WY7Upi2h4P4i1r8=.20a07d56-19ee-45fd-a802-361301cf4aaf@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <Al3Piz6jgHq6TSsjiGH5pHsMSo94in2GW61MZ5ZW8Xc=.5696e283-7f95-4fa5-a900-ff679735ac18@github.com>
 <hG0FP0V7YdSEkU0E-nXsSmOIjOQ0WY7Upi2h4P4i1r8=.20a07d56-19ee-45fd-a802-361301cf4aaf@github.com>
Message-ID: <yC0kjfqjAk9a_41RcJEMYQYf5ZIjQtwVBUpJlyZAbyg=.0facef93-99c9-4763-adbf-81b94e1eaa38@github.com>

On Mon, 19 May 2025 15:02:57 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   An optimization
>
> src/java.base/share/classes/java/math/BigInteger.java line 5034:
> 
>> 5032:      */
>> 5033:     private byte[] magSerializedForm() {
>> 5034:         byte[] result = new byte[(magBitLength() + 7) >>> 3];
> 
> I think there's a risk of overflow, so consider
> Suggestion:
> 
>         byte[] result = new byte[(magBitLength() - 1 >>> 3) + 1];

Ah no, there's a unsigned shift `>>>`.
Disregard

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2095922459

From forax at univ-mlv.fr  Mon May 19 15:16:38 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 19 May 2025 17:16:38 +0200 (CEST)
Subject: Towards a JSON API for the JDK
In-Reply-To: <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <f3cc90ef-25f3-41e3-a82b-0bac063c5733@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>

Okay, 
i've taken a look to the design and this is not pretty. 

The main issue is that the javadoc claims that 
"Both JsonValue instances and their underlying values are immutable." 
but at the same time any subtypes of JsonValue is non-sealed so anyone can implement let say JsonString and adds it's own mutable implementation. 

Because the hierarchy is non sealed, it also means that it is easy to create JsonValue that are invalid, 
for example 

var funJsonNumber = new JsonNumber() { 
public Number toNumber () { 
return Double . NaN ; 
} 
public BigDecimal toBigDecimal () { 
throw new UnsupportedOperationException(); 
} 
public String toString () { 
return "NaN" ; 
} 
}; 

var json = Json.fromUntyped( List . of ( funJsonNumber )); 

For me, the Json hierarchy should be implemented with true ADTs, with all subtypes of JsonValue being records. 

regards, 
R?mi 

> From: "Remi Forax" <forax at univ-mlv.fr>
> To: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "Paul Sandoz" <paul.sandoz at oracle.com>, "core-libs-dev"
> <core-libs-dev at openjdk.org>
> Sent: Friday, May 16, 2025 8:42:47 PM
> Subject: Re: Towards a JSON API for the JDK

>> From: "Brian Goetz" <brian.goetz at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "Paul Sandoz" <paul.sandoz at oracle.com>, "core-libs-dev"
>> <core-libs-dev at openjdk.org>
>> Sent: Friday, May 16, 2025 7:46:09 PM
>> Subject: Re: Towards a JSON API for the JDK

>> If you read the implementation, you'll see that significant laziness is indeed
>> possible for JsonObject and JsonArray, even while doing eager validation. (Of
>> course, one can shift the balance to achieve various other tradeoffs.)
> Reading the implementation is on my TODO list :)

> R?mi

>> On 5/16/2025 10:35 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>>> ----- Original Message -----

>>>> From: "Brian Goetz" [ mailto:brian.goetz at oracle.com | <brian.goetz at oracle.com> ]
>>>> To: "Remi Forax" [ mailto:forax at univ-mlv.fr | <forax at univ-mlv.fr> ] , "Paul
>>>> Sandoz" [ mailto:paul.sandoz at oracle.com | <paul.sandoz at oracle.com> ] Cc:
>>>> "core-libs-dev" [ mailto:core-libs-dev at openjdk.org |
>>>> <core-libs-dev at openjdk.org> ] Sent: Friday, May 16, 2025 2:53:18 PM
>>>> Subject: Re: Towards a JSON API for the JDK

>>>> On 5/15/2025 5:27 PM, Remi Forax wrote:

>>>>> It's not clear to me why JsonArray (for example) has to be an interface instead
>>>>> of a record ?

>>>> Oh, you know the answer to this.? A record limits us to a single
>>>> implementation with a rigid representation.? Behind an interface, we can
>>>> hide lazy parsing and inflation, wrapping other representations to
>>>> reduce copies, etc.

>>> First, let me refine the question.
>>> There are only 4 kinds of JSON values that benefit from having different
>>> representations, object, array, string and number.
>>> For object and array, both takes an interface as parameter (Map or List) so
>>> JsonArray and JSonObject do not need to be themselves interfaces.

>>> So the only values where it may be worth to be modeled using an interface are
>>> JsonString and JsonNumber, because as you said, you can do "lazy" parsing.

>>> But delaying the parsing of the content has the side effect that even if
>>> Json.parse() did not throw an exception, it does not mean that the JSON text is
>>> valid, an exception may be thrown later.

>>> Now, for me, this library is more about being simple and safe than fast.
>>> If you agree with that, delaying the parsing is not a good idea, thus JSON
>>> values should be modeled using records and not interfaces.

>>> regards,
>>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250519/5e5dcd0d/attachment-0001.htm>

From duke at openjdk.org  Mon May 19 15:18:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 19 May 2025 15:18:12 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v9]
In-Reply-To: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
Message-ID: <U0LwRKkDgSKWFVWw4GXUsKEvQSF5vmy_ZBl7HHzBDfI=.817c4ee6-f6a0-4dd5-ae44-ca5206c41821@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Don't use JUnit utils in TestNg.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/3b3fe2d7..e5725599

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=07-08

  Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

PR: https://git.openjdk.org/jdk/pull/25178

From duke at openjdk.org  Mon May 19 15:21:58 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 19 May 2025 15:21:58 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v8]
In-Reply-To: <yC0kjfqjAk9a_41RcJEMYQYf5ZIjQtwVBUpJlyZAbyg=.0facef93-99c9-4763-adbf-81b94e1eaa38@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <Al3Piz6jgHq6TSsjiGH5pHsMSo94in2GW61MZ5ZW8Xc=.5696e283-7f95-4fa5-a900-ff679735ac18@github.com>
 <hG0FP0V7YdSEkU0E-nXsSmOIjOQ0WY7Upi2h4P4i1r8=.20a07d56-19ee-45fd-a802-361301cf4aaf@github.com>
 <yC0kjfqjAk9a_41RcJEMYQYf5ZIjQtwVBUpJlyZAbyg=.0facef93-99c9-4763-adbf-81b94e1eaa38@github.com>
Message-ID: <CPYh7CPTvXYggU6icB3ZU6BojY1EAh9CR4FMDuJMJ68=.bb4f9a45-7396-43a7-a2e6-3438f0923334@github.com>

On Mon, 19 May 2025 15:03:51 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 5034:
>> 
>>> 5032:      */
>>> 5033:     private byte[] magSerializedForm() {
>>> 5034:         byte[] result = new byte[(magBitLength() + 7) >>> 3];
>> 
>> I think there's a risk of overflow, so consider
>> Suggestion:
>> 
>>         byte[] result = new byte[(magBitLength() - 1 >>> 3) + 1];
>
> Ah no, there's a unsigned shift `>>>`.
> Disregard

Indeed, I had thought about this possibility too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2095957646

From bpb at openjdk.org  Mon May 19 15:22:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 19 May 2025 15:22:53 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v4]
In-Reply-To: <QWT_v0Htu4AsLaRGJNbLfDpDiY6KyOn6AnVrYOIf45c=.2eb58ec4-f58f-4f74-a768-618b8cea7a64@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <66pv5IvWk1pnQbXk3swAPR46Zfxt7L7VXPMIod0X3tk=.38446b76-4ef7-4702-929a-fabf3497080b@github.com>
 <rwXcUZ5-L8SUGT-ZQ-cU9JFRM9Wy6cBFPco-VMQuCP8=.10dadf56-a1f2-4159-a7b9-de5752700098@github.com>
 <fFsRN-Y7HUvOXQsgT7uYAysTLWM5pIrUFqPIaj3R3OM=.34bb0412-a4c1-4a43-b7e3-c11c818bd20a@github.com>
 <QWT_v0Htu4AsLaRGJNbLfDpDiY6KyOn6AnVrYOIf45c=.2eb58ec4-f58f-4f74-a768-618b8cea7a64@github.com>
Message-ID: <60m1CyEBrAUyg87HIAwdl555_8iza79wi_gOJ3cjN1A=.d71e80bc-7aa6-4393-957c-af1e4484c5e4@github.com>

On Fri, 16 May 2025 17:22:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I guess collapsing the tests made them more ambiguous. Will fix.
>
> Split the test method in half for Unix and Windows in [fa2273e](https://github.com/openjdk/jdk/pull/24977/commits/fa2273eded040a22c1e32ba8870571d3a7daf427).

> The behavior and system property is Windows specific and might make things simpler to make it a Windows only test.

I think I might have misunderstood this comment. Was the intent to make this test use `@requires os.family == "windows"`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2095962959

From rriggs at openjdk.org  Mon May 19 15:52:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 May 2025 15:52:52 GMT
Subject: RFR: 8357179: Deprecate VFORK launch mechanism from Process
 implementation (linux)
In-Reply-To: <KZUCnliZBaa1PgMeT9PSEQ26BttrtNGZed2I70C0Mbc=.d66fb189-2d88-420c-a8bd-227cb2b817cb@github.com>
References: <KZUCnliZBaa1PgMeT9PSEQ26BttrtNGZed2I70C0Mbc=.d66fb189-2d88-420c-a8bd-227cb2b817cb@github.com>
Message-ID: <gViYKk4JNVTzLPMXUbU1-iaP8eGHRvH_9TVfCyob9Hg=.a8415761-6128-4181-9d53-e05d65d92e00@github.com>

On Sat, 17 May 2025 06:49:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> For the ratio behind this please see the companion CSR: https://bugs.openjdk.org/browse/JDK-8357180.
> 
> We plan to deprecate this in JDK 25 and to remove it in JDK 26.
> 
> This patch just writes a deprecation message to stderr:
> 
> 
> 08:46:38 thomas at starfish java -Djdk.lang.Process.launchMechanism=VFORK SimpleSpawn ls
> VFORK MODE DEPRECATED
> The VFORK launch mechanism has been deprecated for being dangerous.
> It will be removed in a future java version. Either remove the
> jdk.lang.Process.launchMechanism property (preferred) or use FORK mode
> instead (-Djdk.lang.Process.launchMechanism=FORK).
> ...

lgtm;  thanks

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25282#pullrequestreview-2851284733

From rgiulietti at openjdk.org  Mon May 19 15:53:10 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 19 May 2025 15:53:10 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v6]
In-Reply-To: <P445HUqyZZyqKYkHTKNeVzJEGAt4ZpUXcfNUqdsgD3o=.0eb60b30-7d94-42a8-b7d9-22678e86b66a@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <Fe1FcysTPgZYA1aEUGFHRfBxnQ_QkYXJ-4it0QscrS8=.7c1fa510-c570-481c-aa40-5cca05667f34@github.com>
 <nzlgNFOS19-pWtj6EjtduLAMgwO1vXjn81Fi9gCBws0=.02b124e4-a9e2-48db-994d-42bfbc62cdbc@github.com>
 <P445HUqyZZyqKYkHTKNeVzJEGAt4ZpUXcfNUqdsgD3o=.0eb60b30-7d94-42a8-b7d9-22678e86b66a@github.com>
Message-ID: <lSKTwfwn7dBkxSEfXBmvIq4v7L2aPl6t1M2UXM6zDOE=.c6444c3c-331e-45a2-8c00-f143e665d630@github.com>

On Fri, 16 May 2025 13:30:01 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 3860:
>> 
>>> 3858:                 && Integer.lowestOneBit(mag[0]) == mag[0]
>>> 3859:                 && numberOfTrailingZeroInts() == mag.length - 1
>>> 3860:             ? magBitLength() - 1 : magBitLength();
>> 
>> Suggestion:
>> 
>>         int[] mag = this.mag;
>>         return magBitLength() 
>>                 - (signum < 0
>>                    // Check if magnitude is a power of two
>>                    && Integer.lowestOneBit(mag[0]) == mag[0]
>>                    && numberOfTrailingZeroInts() == mag.length - 1
>>                    ? 1 : 0);
>> 
>> 
>> In this way, codeSize will drop from 52 to 45
>
> What is the usefulness of doing `int[] mag = this.mag;` at line 3856, since `bitLength()` does not access to `static` fields and `BigInteger` is not threadsafe, and therefore no race conditions occur?

I think the suggestion is fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2096038516

From duke at openjdk.org  Mon May 19 15:53:10 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 19 May 2025 15:53:10 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v9]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <iV2zQOxMrEPeyOdm8mNOIb9B1GWJxxN83fnhQX9AsRw=.8d635562-6458-4a62-93bf-df13a5fbe3c1@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Removed numberOfTrailingZeros() as a duplicate of the cached getLowestSetBit()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/b151b7e3..b74fefa5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=07-08

  Stats: 18 lines in 1 file changed: 5 ins; 11 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From alanb at openjdk.org  Mon May 19 15:59:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 May 2025 15:59:59 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v4]
In-Reply-To: <60m1CyEBrAUyg87HIAwdl555_8iza79wi_gOJ3cjN1A=.d71e80bc-7aa6-4393-957c-af1e4484c5e4@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <66pv5IvWk1pnQbXk3swAPR46Zfxt7L7VXPMIod0X3tk=.38446b76-4ef7-4702-929a-fabf3497080b@github.com>
 <rwXcUZ5-L8SUGT-ZQ-cU9JFRM9Wy6cBFPco-VMQuCP8=.10dadf56-a1f2-4159-a7b9-de5752700098@github.com>
 <fFsRN-Y7HUvOXQsgT7uYAysTLWM5pIrUFqPIaj3R3OM=.34bb0412-a4c1-4a43-b7e3-c11c818bd20a@github.com>
 <QWT_v0Htu4AsLaRGJNbLfDpDiY6KyOn6AnVrYOIf45c=.2eb58ec4-f58f-4f74-a768-618b8cea7a64@github.com>
 <60m1CyEBrAUyg87HIAwdl555_8iza79wi_gOJ3cjN1A=.d71e80bc-7aa6-4393-957c-af1e4484c5e4@github.com>
Message-ID: <XqdgRJcVapqU7eNob6wVLgfRIBQ2A4dFyNxRIyWhma0=.83c3485c-e458-41c5-a30e-36d2661a1b5e@github.com>

On Mon, 19 May 2025 15:20:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Split the test method in half for Unix and Windows in [fa2273e](https://github.com/openjdk/jdk/pull/24977/commits/fa2273eded040a22c1e32ba8870571d3a7daf427).
>
>> The behavior and system property is Windows specific and might make things simpler to make it a Windows only test.
> 
> I think I might have misunderstood this comment. Was the intent to make this test use `@requires os.family == "windows"`?

I think that would be simpler and means the `@EnabledOnOs` usages would go away, but it's up to you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2096050597

From alanb at openjdk.org  Mon May 19 16:01:25 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 May 2025 16:01:25 GMT
Subject: RFR: 8357179: Deprecate VFORK launch mechanism from Process
 implementation (linux)
In-Reply-To: <KZUCnliZBaa1PgMeT9PSEQ26BttrtNGZed2I70C0Mbc=.d66fb189-2d88-420c-a8bd-227cb2b817cb@github.com>
References: <KZUCnliZBaa1PgMeT9PSEQ26BttrtNGZed2I70C0Mbc=.d66fb189-2d88-420c-a8bd-227cb2b817cb@github.com>
Message-ID: <2QsUpYlpfhTSliyQQJ_vwPBiCErV4MjOIfyNeefES3E=.748e86cc-9d47-4744-9e1b-14375881a392@github.com>

On Sat, 17 May 2025 06:49:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> For the ratio behind this please see the companion CSR: https://bugs.openjdk.org/browse/JDK-8357180.
> 
> We plan to deprecate this in JDK 25 and to remove it in JDK 26.
> 
> This patch just writes a deprecation message to stderr:
> 
> 
> 08:46:38 thomas at starfish java -Djdk.lang.Process.launchMechanism=VFORK SimpleSpawn ls
> VFORK MODE DEPRECATED
> The VFORK launch mechanism has been deprecated for being dangerous.
> It will be removed in a future java version. Either remove the
> jdk.lang.Process.launchMechanism property (preferred) or use FORK mode
> instead (-Djdk.lang.Process.launchMechanism=FORK).
> ...

src/java.base/unix/classes/java/lang/ProcessImpl.java line 111:

> 109:                                            "It will be removed in a future java version. Either remove the\n" +
> 110:                                            "jdk.lang.Process.launchMechanism property (preferred) or use FORK mode\n" +
> 111:                                            "instead (-Djdk.lang.Process.launchMechanism=FORK).");

This is okay although I could imagine someone wanting to replace this with a text block.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25282#discussion_r2096052329

From jlahoda at openjdk.org  Mon May 19 16:02:00 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 19 May 2025 16:02:00 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v18]
In-Reply-To: <MPgukNWo0agINMH9L7hhU13BNo-_ZlWV311WmPyZSVQ=.d4b4e536-4280-416c-91f9-910561b97169@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <MPgukNWo0agINMH9L7hhU13BNo-_ZlWV311WmPyZSVQ=.d4b4e536-4280-416c-91f9-910561b97169@github.com>
Message-ID: <4WJiJCaO8Kf9FzD4YX0nP13CoVOcDw9wePKvBVyaQw8=.81f09b20-763c-4e6b-a0ff-a12167e0644c@github.com>

On Mon, 19 May 2025 14:35:40 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - Merge branch 'master' into JDK-8354556
>  - review comments
>  - addressing review comments
>  - addressing review comments
>  - update warning message
>  - Merge branch 'master' into JDK-8354556
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - additional changes from Archie
>  - removing dead code
>  - integrating code from Archie
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/265d6301...904bd4cd

javac changes look good to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24746#pullrequestreview-2851310025

From nbenalla at openjdk.org  Mon May 19 16:08:02 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 19 May 2025 16:08:02 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
Message-ID: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>

Please review this patch to fix some `javadoc` bugs in `java.base`.
Certain `@link` tags used to refer to private fields instead of public APIs.

A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.

TIA

-------------

Commit messages:
 - respond to feedback
 - fix incorrect `@link` tags

Changes: https://git.openjdk.org/jdk/pull/25287/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25287&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356632
  Stats: 14 lines in 6 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25287.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25287/head:pull/25287

PR: https://git.openjdk.org/jdk/pull/25287

From liach at openjdk.org  Mon May 19 16:08:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 May 2025 16:08:03 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
In-Reply-To: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
Message-ID: <SnUSWGwMDdeWI9ivGw50g8tiYs7CTTACfWI_pmI93Ho=.0cace409-d43b-4e15-bb0f-9939555429e5@github.com>

On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to fix some `javadoc` bugs in `java.base`.
> Certain `@link` tags used to refer to private fields instead of public APIs.
> 
> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
> 
> TIA

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4893:

> 4891:      * @return a constant method handle of the given type, which returns a default value of the given return type
> 4892:      * @throws NullPointerException if the argument is null
> 4893:      * @see <code>primitiveZero(Wrapper)</code>

Just `#zero(Class)` should be sufficient. This is probably changed by intellij during my original work to consolidate zero and constant.

src/java.base/share/classes/java/lang/invoke/MethodType.java line 1341:

> 1339:      * @throws ClassNotFoundException if one of the component classes cannot be resolved
> 1340:      * @see <code>MethodType.readResolve()</code>
> 1341:      * @see <code>MethodType.writeObject(ObjectOutputStream s)</code>

This is already not generated by the javadoc as this method is private. Why is this check against a private method?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2094316583
PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2094316628

From duke at openjdk.org  Mon May 19 16:08:04 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 19 May 2025 16:08:04 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
In-Reply-To: <SnUSWGwMDdeWI9ivGw50g8tiYs7CTTACfWI_pmI93Ho=.0cace409-d43b-4e15-bb0f-9939555429e5@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
 <SnUSWGwMDdeWI9ivGw50g8tiYs7CTTACfWI_pmI93Ho=.0cace409-d43b-4e15-bb0f-9939555429e5@github.com>
Message-ID: <b8Lmu1eAM7BHZOWKxWKFMH7wVAaZ02WB3CmFuiN9rUs=.dcefa204-dcb2-4583-b5a9-da50d4e6bc74@github.com>

On Sun, 18 May 2025 02:17:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch to fix some `javadoc` bugs in `java.base`.
>> Certain `@link` tags used to refer to private fields instead of public APIs.
>> 
>> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
>> 
>> TIA
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4893:
> 
>> 4891:      * @return a constant method handle of the given type, which returns a default value of the given return type
>> 4892:      * @throws NullPointerException if the argument is null
>> 4893:      * @see <code>primitiveZero(Wrapper)</code>
> 
> Just `#zero(Class)` should be sufficient. This is probably changed by intellij during my original work to consolidate zero and constant.

From?<https://github.com/openjdk/jdk/pull/23706#discussion_r2094138280>:
Suggestion:

     * @see MethodHandles#zero

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2094592478

From nbenalla at openjdk.org  Mon May 19 16:08:04 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 19 May 2025 16:08:04 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
In-Reply-To: <SnUSWGwMDdeWI9ivGw50g8tiYs7CTTACfWI_pmI93Ho=.0cace409-d43b-4e15-bb0f-9939555429e5@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
 <SnUSWGwMDdeWI9ivGw50g8tiYs7CTTACfWI_pmI93Ho=.0cace409-d43b-4e15-bb0f-9939555429e5@github.com>
Message-ID: <SR_4-v-Y3EajMlQGMIxGQyfkZx4XlchmSs4MQTD6yAM=.97982bd4-8aec-406a-b13e-43ffce663f52@github.com>

On Sun, 18 May 2025 02:18:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch to fix some `javadoc` bugs in `java.base`.
>> Certain `@link` tags used to refer to private fields instead of public APIs.
>> 
>> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
>> 
>> TIA
>
> src/java.base/share/classes/java/lang/invoke/MethodType.java line 1341:
> 
>> 1339:      * @throws ClassNotFoundException if one of the component classes cannot be resolved
>> 1340:      * @see <code>MethodType.readResolve()</code>
>> 1341:      * @see <code>MethodType.writeObject(ObjectOutputStream s)</code>
> 
> This is already not generated by the javadoc as this method is private. Why is this check against a private method?

They are documented in [this page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2095501605

From duke at openjdk.org  Mon May 19 16:15:59 2025
From: duke at openjdk.org (duke)
Date: Mon, 19 May 2025 16:15:59 GMT
Subject: Withdrawn: 8349545: ClassLoader.definePackage() throws
 IllegalArgumentException if package already defined
In-Reply-To: <nPvgVf0OlU00h6YkrG0OXwiAqjc9_Eu7qBdUmTSSUYg=.1de24d04-2a4b-45a7-999d-529658b4d497@github.com>
References: <nPvgVf0OlU00h6YkrG0OXwiAqjc9_Eu7qBdUmTSSUYg=.1de24d04-2a4b-45a7-999d-529658b4d497@github.com>
Message-ID: <klcdXiNQe8rUy_pzY94_DRAS7rI8a4L1mofKi3c7Y1o=.3b23d1d2-d81a-46c5-928c-7d05cd078a85@github.com>

On Sun, 23 Feb 2025 11:32:41 GMT, Robert Stupp <rstupp at openjdk.org> wrote:

> Concurent calls to `ClassLoader.definePackage()` can yield `IllegalArgumentException`s if the package is already defined. Some built-in class loaders, like `URLClassLoader`, already handle this case, but custom class loaders (would) have to handle this case.
> 
> This change updates the logic of `CL.definePackage` to not throw an IAE if the "redefined" package is equal to the already defined one.
> 
> Tests added in `jdk/java/lang/Package/PackageDefineTest.java` (+ pulling up the `TestClassLoader` from `PackageDefineTest`).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23737

From darcy at openjdk.org  Mon May 19 16:20:50 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 19 May 2025 16:20:50 GMT
Subject: RFR: 8357178: Simplify Class::componentType [v2]
In-Reply-To: <N2psbJ2BkNXy9NexHty3Jmvt0thh9PmLMFdcstyeD68=.acc0468a-7efd-4101-9316-78b5c38abc14@github.com>
References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com>
 <qu6L562rjh0PbjZsNVcZtCgATWM79ieGPNm_Mpvw_ow=.7e1be13b-6ab3-41a2-b53c-da5f3bc63c23@github.com>
 <N2psbJ2BkNXy9NexHty3Jmvt0thh9PmLMFdcstyeD68=.acc0468a-7efd-4101-9316-78b5c38abc14@github.com>
Message-ID: <EuXMQby6ryaod2KSDPzgM1YTsEpygVuFjEYLq_IrMqk=.da778176-8e88-40a1-b41a-769fca372f62@github.com>

On Sun, 18 May 2025 21:15:21 GMT, Chen Liang <liach at openjdk.org> wrote:

> > Did you consider calling getComponentType(), which already returns the field?
> 
> I don't think we want an extra indirection here - The logic here is quite simple. Counterargument could be that `MethodType::descriptorString` calls `toMethodDescriptorString`, except these methods involve more complex caching and is not simple like this field access.

My mental model anyway is that this trivial inline would be something the VM would do readily.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25280#discussion_r2096089013

From alanb at openjdk.org  Mon May 19 16:42:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 May 2025 16:42:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v9]
In-Reply-To: <U0LwRKkDgSKWFVWw4GXUsKEvQSF5vmy_ZBl7HHzBDfI=.817c4ee6-f6a0-4dd5-ae44-ca5206c41821@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <U0LwRKkDgSKWFVWw4GXUsKEvQSF5vmy_ZBl7HHzBDfI=.817c4ee6-f6a0-4dd5-ae44-ca5206c41821@github.com>
Message-ID: <Uppcv1qTw0o0vQQv3hMPAGJFJJTy8E_VuZFJyyJnQwE=.2bc16358-325f-456a-ad8a-eb09a8c257b6@github.com>

On Mon, 19 May 2025 15:18:12 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't use JUnit utils in TestNg.

src/jdk.zipfs/share/classes/module-info.java line 264:

> 262:  *               {@linkplain Runtime.Version Java SE Platform version number},
> 263:  *               an {@code IllegalArgumentException} will be thrown when the Zip
> 264:  *               filesystem is created.

I think this needs to "when creating the ZIP file system".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2096125703

From alanb at openjdk.org  Mon May 19 16:49:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 May 2025 16:49:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v9]
In-Reply-To: <U0LwRKkDgSKWFVWw4GXUsKEvQSF5vmy_ZBl7HHzBDfI=.817c4ee6-f6a0-4dd5-ae44-ca5206c41821@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <U0LwRKkDgSKWFVWw4GXUsKEvQSF5vmy_ZBl7HHzBDfI=.817c4ee6-f6a0-4dd5-ae44-ca5206c41821@github.com>
Message-ID: <A8AoQlzV_YseSkUCDZFNk12f4RC5SvHE--vObL8t80Y=.1310fc21-3a7b-4951-adac-d74257c1c671@github.com>

On Mon, 19 May 2025 15:18:12 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't use JUnit utils in TestNg.

src/jdk.zipfs/share/classes/module-info.java line 288:

> 286:  *               isReadOnly()} will always return {@code true}. Creating a
> 287:  *               <em>read-only</em> file system requires the underlying ZIP file to
> 288:  *               already exist, and is incompatible with {@code "create"=true}.

I think it would be clearer to drop "and is incompatible with {@code "create"=true}". The sentence that follows makes it clear that accessMode=readWrite && create=true cause IAE to be thrown.

src/jdk.zipfs/share/classes/module-info.java line 291:

> 289:  *               Specifying {@code create} as {@code true} and {@code accessMode} as
> 290:  *               {@code readOnly} will cause an {@code IllegalArgumentException}
> 291:  *               to be thrown when the ZIP filesystem is created.

"created" sounds past tense, so making it "when creating the ZIP file system" would work better here. Same comment on the text further down.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2096133967
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2096134802

From smarks at openjdk.org  Mon May 19 16:56:00 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 19 May 2025 16:56:00 GMT
Subject: Integrated: 8351230: Collections.synchronizedList returns a list that
 is not thread-safe
In-Reply-To: <HtBkFlpJ7N3BjMiDZcA2LgM0YOEkd4L1_6XKIPJwwew=.6325e6ba-153e-43c6-9de6-ab00c1e972ed@github.com>
References: <HtBkFlpJ7N3BjMiDZcA2LgM0YOEkd4L1_6XKIPJwwew=.6325e6ba-153e-43c6-9de6-ab00c1e972ed@github.com>
Message-ID: <YvFjJojOE-GO_ZdaKWlMANyRQ42E5ZYzgqHlM3vbAyQ=.81afa54d-1787-4a4c-b8c1-e9bd21ea11f9@github.com>

On Thu, 1 May 2025 19:05:50 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Collections.synchronizedList() returns a List implementation that doesn't do proper locking. This PR does the following on the synchronized wrapper:
> 
> - overrides and adds locking to SequencedCollection methods;
> - performs instance management of reversed synchronized views;
> - adds test for race conditions and functional tests of synchronized wrappers.

This pull request has now been integrated.

Changeset: 6818dcc0
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6818dcc08ed85e220c5206fda5c991b886e35334
Stats:     260 lines in 3 files changed: 247 ins; 9 del; 4 mod

8351230: Collections.synchronizedList returns a list that is not thread-safe

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/24990

From stuefe at openjdk.org  Mon May 19 16:59:06 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 19 May 2025 16:59:06 GMT
Subject: RFR: 8357179: Deprecate VFORK launch mechanism from Process
 implementation (linux) [v2]
In-Reply-To: <KZUCnliZBaa1PgMeT9PSEQ26BttrtNGZed2I70C0Mbc=.d66fb189-2d88-420c-a8bd-227cb2b817cb@github.com>
References: <KZUCnliZBaa1PgMeT9PSEQ26BttrtNGZed2I70C0Mbc=.d66fb189-2d88-420c-a8bd-227cb2b817cb@github.com>
Message-ID: <lgOLwRhfzwJw-Ko6kpSorv9CaXd9bqiij6X6JSuM8yw=.4f788f75-541d-4e45-97d3-8bb5e4beedf6@github.com>

> For the ratio behind this please see the companion CSR: https://bugs.openjdk.org/browse/JDK-8357180.
> 
> We plan to deprecate this in JDK 25 and to remove it in JDK 26.
> 
> This patch just writes a deprecation message to stderr:
> 
> 
> 08:46:38 thomas at starfish java -Djdk.lang.Process.launchMechanism=VFORK SimpleSpawn ls
> VFORK MODE DEPRECATED
> The VFORK launch mechanism has been deprecated for being dangerous.
> It will be removed in a future java version. Either remove the
> jdk.lang.Process.launchMechanism property (preferred) or use FORK mode
> instead (-Djdk.lang.Process.launchMechanism=FORK).
> ...

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  use string block

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25282/files
  - new: https://git.openjdk.org/jdk/pull/25282/files/8bd4a36e..ec3197f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25282&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25282&range=00-01

  Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25282.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25282/head:pull/25282

PR: https://git.openjdk.org/jdk/pull/25282

From stuefe at openjdk.org  Mon May 19 16:59:06 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 19 May 2025 16:59:06 GMT
Subject: RFR: 8357179: Deprecate VFORK launch mechanism from Process
 implementation (linux) [v2]
In-Reply-To: <2QsUpYlpfhTSliyQQJ_vwPBiCErV4MjOIfyNeefES3E=.748e86cc-9d47-4744-9e1b-14375881a392@github.com>
References: <KZUCnliZBaa1PgMeT9PSEQ26BttrtNGZed2I70C0Mbc=.d66fb189-2d88-420c-a8bd-227cb2b817cb@github.com>
 <2QsUpYlpfhTSliyQQJ_vwPBiCErV4MjOIfyNeefES3E=.748e86cc-9d47-4744-9e1b-14375881a392@github.com>
Message-ID: <z-UAxetaNOQrfakQTFsrFH1blkZih7I1F88uh7i-VHg=.a412577b-05cd-4744-a2b3-4dbb840ffe43@github.com>

On Mon, 19 May 2025 15:58:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use string block
>
> src/java.base/unix/classes/java/lang/ProcessImpl.java line 111:
> 
>> 109:                                            "It will be removed in a future java version. Either remove the\n" +
>> 110:                                            "jdk.lang.Process.launchMechanism property (preferred) or use FORK mode\n" +
>> 111:                                            "instead (-Djdk.lang.Process.launchMechanism=FORK).");
> 
> This is okay although I could imagine someone wanting to replace this with a text block.

okay, changed to string block

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25282#discussion_r2096149401

From rgiulietti at openjdk.org  Mon May 19 17:08:50 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 19 May 2025 17:08:50 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface
In-Reply-To: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
Message-ID: <KUYOP8M6SQqPy38DmkhDUZeDAack1YjwBMrLqo0wtmw=.e4724a5e-7a36-41ab-b5c8-96b9f5fa03ab@github.com>

On Mon, 19 May 2025 07:25:17 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
> 
> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
> 
> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.

@amaembo Could you please switch the test class to make use of [JUnit](https://junit.org/junit5/)? For new tests we now prefer JUnit over TestNG.
Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-2891719275

From bpb at openjdk.org  Mon May 19 17:10:50 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 19 May 2025 17:10:50 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v7]
In-Reply-To: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
Message-ID: <buorsiySbKIAHaL6l60M8MejAWQrWQFbQAo51U3QV5g=.f0a8c36b-6c5c-4509-8a82-87debcf46a78@github.com>

> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8355954: Make test Windows-only

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24977/files
  - new: https://git.openjdk.org/jdk/pull/24977/files/9fa45418..74e16983

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=05-06

  Stats: 16 lines in 1 file changed: 1 ins; 14 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24977/head:pull/24977

PR: https://git.openjdk.org/jdk/pull/24977

From bpb at openjdk.org  Mon May 19 17:10:51 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 19 May 2025 17:10:51 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v4]
In-Reply-To: <XqdgRJcVapqU7eNob6wVLgfRIBQ2A4dFyNxRIyWhma0=.83c3485c-e458-41c5-a30e-36d2661a1b5e@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <66pv5IvWk1pnQbXk3swAPR46Zfxt7L7VXPMIod0X3tk=.38446b76-4ef7-4702-929a-fabf3497080b@github.com>
 <rwXcUZ5-L8SUGT-ZQ-cU9JFRM9Wy6cBFPco-VMQuCP8=.10dadf56-a1f2-4159-a7b9-de5752700098@github.com>
 <fFsRN-Y7HUvOXQsgT7uYAysTLWM5pIrUFqPIaj3R3OM=.34bb0412-a4c1-4a43-b7e3-c11c818bd20a@github.com>
 <QWT_v0Htu4AsLaRGJNbLfDpDiY6KyOn6AnVrYOIf45c=.2eb58ec4-f58f-4f74-a768-618b8cea7a64@github.com>
 <60m1CyEBrAUyg87HIAwdl555_8iza79wi_gOJ3cjN1A=.d71e80bc-7aa6-4393-957c-af1e4484c5e4@github.com>
 <XqdgRJcVapqU7eNob6wVLgfRIBQ2A4dFyNxRIyWhma0=.83c3485c-e458-41c5-a30e-36d2661a1b5e@github.com>
Message-ID: <hHCwDtB5dc9bUdNYUNSL67tK2TgcvXNCGGjhwvwAO_M=.dabd5f0c-a7a0-4e58-a63b-27613c9044a4@github.com>

On Mon, 19 May 2025 15:57:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think that would be simpler and means the `@EnabledOnOs` usages would go away, but it's up to you.

I agree that is better. So changed in [74e1698](https://github.com/openjdk/jdk/pull/24977/commits/74e16983c94d9b29c91b660e8a025388d72aee71).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24977#discussion_r2096163983

From jd at civilian-framework.org  Mon May 19 17:15:41 2025
From: jd at civilian-framework.org (=?UTF-8?Q?Johannes_D=C3=B6bler?=)
Date: Mon, 19 May 2025 19:15:41 +0200
Subject: Towards a JSON API for the JDK
Message-ID: <eaa41fc4-b632-40fa-bbce-581b9f6365ca@civilian-framework.org>

Developers use JSON libraries like Fastjson, Jackson and Gson primarily 
(my claim) because they can marshal between JSON files and POJOs in one 
line of code with great performance and can easily tweak the mapping 
using annotations or adapter classes.
Being able to read/write a JSON file from/to a generic tree of 
JsonValues might have use-cases, but manually implementing data-binding 
based one tree traversal w/wo pattern matching will produce bloated and 
fragile code (my claim).
So my question is if there are plans to address data-binding in the 
future and how it would relate to the envisioned core API.
Thanks
Johannes


> # Towards a JSON API for the JDK
>
> One of the most common requests for the JDK is an API for parsing and generating
> JSON. While JSON originated as a text-based serialization format for JSON
> objects ("JSON" stands for "JavaScript Object Notation"), because of its simple
> and flexible syntax, it eventually found use outside the JavaScript ecosystem as
> a general data interchange format, such as framework configuration files and web
> service requests/response formats.
>
> While the JDK cannot, and should not, provide libraries for every conceivable
> file format or protocol, the JDK philosophy is one of "batteries included",
> which is to say we should be able to write basic programs that use common
> protocols such as HTTP, without having to appeal to third party libraries.
> The Java ecosystem already has plenty of JSON libraries, so inclusion in
> the JDK is largely meant to be a convenience, rather than needing to be the "one
> true" JSON library to meet the needs of all users. Users with specific needs
> are always free to select one of the existing third-party libraries.
>
> ## Goals and requirements
>
> Our primary goal is that the library be simple to use for parsing, traversing,
> and generating conformant JSON documents. Advanced features, such as data
> binding or path-based traversal should be possible to implement as layered
> features, but for simplicity are not included in the core API. We adopt a goal
> that the performance should be "good enough", but where performance
> considerations conflict with simplicity and usability, we will choose in favor
> of the latter.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250519/ab7b3c8f/attachment-0001.htm>

From rriggs at openjdk.org  Mon May 19 17:17:59 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 May 2025 17:17:59 GMT
Subject: RFR: 8357179: Deprecate VFORK launch mechanism from Process
 implementation (linux) [v2]
In-Reply-To: <lgOLwRhfzwJw-Ko6kpSorv9CaXd9bqiij6X6JSuM8yw=.4f788f75-541d-4e45-97d3-8bb5e4beedf6@github.com>
References: <KZUCnliZBaa1PgMeT9PSEQ26BttrtNGZed2I70C0Mbc=.d66fb189-2d88-420c-a8bd-227cb2b817cb@github.com>
 <lgOLwRhfzwJw-Ko6kpSorv9CaXd9bqiij6X6JSuM8yw=.4f788f75-541d-4e45-97d3-8bb5e4beedf6@github.com>
Message-ID: <j00_VHF1mwo_hqfsJQCOdZ78eICoAcaAqQWWYnIU00o=.4b7069d5-42aa-467f-9ad7-61437fea5c0c@github.com>

On Mon, 19 May 2025 16:59:06 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> For the ratio behind this please see the companion CSR: https://bugs.openjdk.org/browse/JDK-8357180.
>> 
>> We plan to deprecate this in JDK 25 and to remove it in JDK 26.
>> 
>> This patch just writes a deprecation message to stderr:
>> 
>> 
>> 08:46:38 thomas at starfish java -Djdk.lang.Process.launchMechanism=VFORK SimpleSpawn ls
>> VFORK MODE DEPRECATED
>> The VFORK launch mechanism has been deprecated for being dangerous.
>> It will be removed in a future java version. Either remove the
>> jdk.lang.Process.launchMechanism property (preferred) or use FORK mode
>> instead (-Djdk.lang.Process.launchMechanism=FORK).
>> ...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use string block

Marked as reviewed by rriggs (Reviewer).

Looks good, also reviewed the CSR, it can be finalized.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25282#pullrequestreview-2851506982
PR Comment: https://git.openjdk.org/jdk/pull/25282#issuecomment-2891742547

From duke at openjdk.org  Mon May 19 17:19:53 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 19 May 2025 17:19:53 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v6]
In-Reply-To: <lSKTwfwn7dBkxSEfXBmvIq4v7L2aPl6t1M2UXM6zDOE=.c6444c3c-331e-45a2-8c00-f143e665d630@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <Fe1FcysTPgZYA1aEUGFHRfBxnQ_QkYXJ-4it0QscrS8=.7c1fa510-c570-481c-aa40-5cca05667f34@github.com>
 <nzlgNFOS19-pWtj6EjtduLAMgwO1vXjn81Fi9gCBws0=.02b124e4-a9e2-48db-994d-42bfbc62cdbc@github.com>
 <P445HUqyZZyqKYkHTKNeVzJEGAt4ZpUXcfNUqdsgD3o=.0eb60b30-7d94-42a8-b7d9-22678e86b66a@github.com>
 <lSKTwfwn7dBkxSEfXBmvIq4v7L2aPl6t1M2UXM6zDOE=.c6444c3c-331e-45a2-8c00-f143e665d630@github.com>
Message-ID: <-rQgicittOCA_tEe4GVVYOMIIhOSIgBKEBnkOzUjwL0=.ef3e7710-9f43-4eef-a123-acee243b0b6f@github.com>

On Mon, 19 May 2025 15:50:10 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> What is the usefulness of doing `int[] mag = this.mag;` at line 3856, since `bitLength()` does not access to `static` fields and `BigInteger` is not threadsafe, and therefore no race conditions occur?
>
> I think the suggestion is fine.

Yes, but perhaps in the current version it's more clear what is the returned value according to the condition.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2096183726

From alan.bateman at oracle.com  Mon May 19 17:20:36 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Mon, 19 May 2025 18:20:36 +0100
Subject: ClassLoader.definePackage() throwing IllegalArgumentException
In-Reply-To: <8c837531-0bb5-4456-8042-5bc024d38542@snazy.de>
References: <8c837531-0bb5-4456-8042-5bc024d38542@snazy.de>
Message-ID: <0128fdaa-126b-44b8-8f01-1bb2f0935469@oracle.com>



On 19/05/2025 15:34, Robert Stupp wrote:
> Hi,
>
> I'd like to follow up on https://bugs.openjdk.org/browse/JDK-8350547.
>
> TL;DR java.lang.ClassLoader.definePackage() (the one taking 8 
> arguments) clearly defines that a IllegalArgumentException is thrown, 
> "if a package of the given name is already defined by this class loader".
>
> However, it seems that it's a common oversight that an IAE can be 
> thrown. Examples are the CDI reference implementation ("Weld") and 
> Quarkus. In other words: "naively" calling 'definePackage' without a 
> retry on IAE leads to issues when defining classes in custom class 
> loaders in parallel.
>
> The CL.definePackage() API is there since Java 1.2, and I admit that 
> my initial approach to change the currently observed behavior isn't 
> going to fly.
>
> I thought about adding more information to the message of the IAE 
> thrown in 'definePackage()', but even this "innocent" change could 
> break the observed behavior / existing code.
>
> One option could be to add a new function 'definePackageIfNotExists()` 
> to j.l.ClassLoader, which works like the existing 'definePackage()' 
> but returns the existing package, if it already exists and is 
> compatible with the given arguments. The downside is that it could 
> still throw, if the arguments are incompatible (e.g. a different 
> "implTitle") - so it might just be a less likely, but still possible 
> way of unexpectedly hitting an IAE.
>
> With 'definePackageIfNotExists()` it might be possible to deprecate 
> 'definePackage()', but that deprecation largely depends on the actual 
> usage of it in the wild, which I do not know. I'm not sure whether 
> such a deprecation can fly. And the next question would be whether it 
> can be deprecated for removal ; and if yes, when could it be removed.
>
> Actually, even a new 'definePackageIfNotExists()` could break existing 
> code, in case an implementation overrides the existing 'definePackage' 
> but not 'definePackageIfNotExists()`.
>
> Another question to which I don't know the answer is whether the 7 
> package attribute parameters specification/implementation 
> title/version/vendor + seal-base do fit "all today's wishes & needs". 
> Or: is there demand for a "better" or "more flexible" way to define a 
> class/package? Or: can that API be redefined in a different way 
> tailored for today's needs and wishes? And are there any that would 
> justify such an effort?
>
> Overall, I'm a bit lost on what the "best" way would be for this. 
> Maybe the answer is that there is no better way yet, which is also 
> fine. Maybe the only "fix" is to enhance the Javadocs and prominently 
> highlight the behavior and add a "reference code snippet" how 
> 'definePackage()' should be used and why.

As we discussed already, this API "awkwardness" goes back to JDK 1.2 
(1998) so changing the behavior now would be risky. Hard to know how 
many custom class loaders are using this method but expanding the 
apiNote to include a snippet that catches IAE to deal with concurrent 
attempts to define the package would be okay.

As to your "all today's wishes & needs" comment. The "Package Version 
Specification" was of its time. It might be interesting to see how 
definePackage is used but I wouldn't be surprised to see the specXXX and 
implXXX parameters specified as null. Also the notion of sealed packages 
is legacy now.

-Alan

From alanb at openjdk.org  Mon May 19 17:25:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 May 2025 17:25:52 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win) [v7]
In-Reply-To: <buorsiySbKIAHaL6l60M8MejAWQrWQFbQAo51U3QV5g=.f0a8c36b-6c5c-4509-8a82-87debcf46a78@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
 <buorsiySbKIAHaL6l60M8MejAWQrWQFbQAo51U3QV5g=.f0a8c36b-6c5c-4509-8a82-87debcf46a78@github.com>
Message-ID: <e_EA4OKdLHzhphdQNw1jWGk91EdTNfPi9MkAFsrquKU=.d608483f-381f-4153-a761-bdf02b9d98a2@github.com>

On Mon, 19 May 2025 17:10:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355954: Make test Windows-only

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24977#pullrequestreview-2851532693

From rriggs at openjdk.org  Mon May 19 17:31:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 May 2025 17:31:52 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface
In-Reply-To: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
Message-ID: <rzItZkhAHl4SUyQvf40nFRAWWyu-HJROMySuUGtIFNo=.c013dc3b-2fae-4b6f-8458-0b803a82a2f0@github.com>

On Mon, 19 May 2025 07:25:17 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
> 
> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
> 
> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.

Min and Max for the equals case would be more consistent if the value returned for equals was the same as the condition, as if `=>` or `<=` were used for the comparison.
The code would be easier to read and match the description if max used `>=` and min used `<=`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25297#pullrequestreview-2851547425

From rgiulietti at openjdk.org  Mon May 19 17:36:52 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 19 May 2025 17:36:52 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v6]
In-Reply-To: <-rQgicittOCA_tEe4GVVYOMIIhOSIgBKEBnkOzUjwL0=.ef3e7710-9f43-4eef-a123-acee243b0b6f@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <Fe1FcysTPgZYA1aEUGFHRfBxnQ_QkYXJ-4it0QscrS8=.7c1fa510-c570-481c-aa40-5cca05667f34@github.com>
 <nzlgNFOS19-pWtj6EjtduLAMgwO1vXjn81Fi9gCBws0=.02b124e4-a9e2-48db-994d-42bfbc62cdbc@github.com>
 <P445HUqyZZyqKYkHTKNeVzJEGAt4ZpUXcfNUqdsgD3o=.0eb60b30-7d94-42a8-b7d9-22678e86b66a@github.com>
 <lSKTwfwn7dBkxSEfXBmvIq4v7L2aPl6t1M2UXM6zDOE=.c6444c3c-331e-45a2-8c00-f143e665d630@github.com>
 <-rQgicittOCA_tEe4GVVYOMIIhOSIgBKEBnkOzUjwL0=.ef3e7710-9f43-4eef-a123-acee243b0b6f@github.com>
Message-ID: <OsgwIG9K_NUqTFE4c-suCsGvFWWboQSW0fq8t-5E150=.6cc537e1-df1c-45ce-977a-b2cb9e0e0fbb@github.com>

On Mon, 19 May 2025 17:16:58 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> I think the suggestion is fine.
>
> Yes, but perhaps in the current version it's more clear what is the returned value according to the condition.

One could see the suggested variant as "return magBitLength(), except for a corrective term in case blah blah..."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2096209014

From duke at openjdk.org  Mon May 19 17:43:56 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 19 May 2025 17:43:56 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v6]
In-Reply-To: <OsgwIG9K_NUqTFE4c-suCsGvFWWboQSW0fq8t-5E150=.6cc537e1-df1c-45ce-977a-b2cb9e0e0fbb@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <Fe1FcysTPgZYA1aEUGFHRfBxnQ_QkYXJ-4it0QscrS8=.7c1fa510-c570-481c-aa40-5cca05667f34@github.com>
 <nzlgNFOS19-pWtj6EjtduLAMgwO1vXjn81Fi9gCBws0=.02b124e4-a9e2-48db-994d-42bfbc62cdbc@github.com>
 <P445HUqyZZyqKYkHTKNeVzJEGAt4ZpUXcfNUqdsgD3o=.0eb60b30-7d94-42a8-b7d9-22678e86b66a@github.com>
 <lSKTwfwn7dBkxSEfXBmvIq4v7L2aPl6t1M2UXM6zDOE=.c6444c3c-331e-45a2-8c00-f143e665d630@github.com>
 <-rQgicittOCA_tEe4GVVYOMIIhOSIgBKEBnkOzUjwL0=.ef3e7710-9f43-4eef-a123-acee243b0b6f@github.com>
 <OsgwIG9K_NUqTFE4c-suCsGvFWWboQSW0fq8t-5E150=.6cc537e1-df1c-45ce-977a-b2cb9e0e0fbb@github.com>
Message-ID: <1TYLBX7dQMXEARyetI6hnxkAr9lgj17f4jE-ID76K7I=.b640f392-b382-4c26-b237-e99fa430b85c@github.com>

On Mon, 19 May 2025 17:34:16 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Yes, but perhaps in the current version it's more clear what is the returned value according to the condition.
>
> One could see the suggested variant as "return magBitLength(), except for a corrective term in case blah blah..."

Moreover, the current version avoids a subtraction in almost all cases, although probably it is negligible.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2096217698

From naoto.sato at oracle.com  Mon May 19 18:02:28 2025
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 19 May 2025 11:02:28 -0700
Subject: Towards a JSON API for the JDK
In-Reply-To: <52514642-e172-4096-a616-a2c9a9787552@gmail.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <52514642-e172-4096-a616-a2c9a9787552@gmail.com>
Message-ID: <9eb26b27-6579-45ed-9a7d-70859efef7a7@oracle.com>

Hi,

On 5/17/25 10:55 PM, Cay Horstmann wrote:
> PS. Trying to create and show the youthful John gives me grief right now:
> 
> Json.fromUntyped(Map.of("name", "John", "age", 30)).toString()
> |? Exception java.lang.NullPointerException: Cannot read the array 
> length because "value" is null
> |??????? at String.rangeCheck (String.java:307)
> |??????? at String.<init> (String.java:303)
> |??????? at JsonNumberImpl.toString (JsonNumberImpl.java:105)
> |??????? at JsonObjectImpl.toString (JsonObjectImpl.java:56)
> |??????? at (#23:1)
> 
> The JsonNumberImpl.toString method needs to handle the case that it was 
> constructed from a Number.

I could not reproduce it with the current branch. Could you please 
elaborate it more?

Naoto

From nbenalla at openjdk.org  Mon May 19 18:11:34 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 19 May 2025 18:11:34 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v3]
In-Reply-To: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
Message-ID: <Nu5ZnPIRoa--jtdnVjIdy2i7lgJIM4Nf040_kOO39Y0=.e18061ba-9024-4176-9177-4be9d9843e51@github.com>

> Get JDK 26 underway.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Update --release 25 symbol information for JDK 25 build 23
   The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
 - Update release date
 - Update --release 25 symbol information for JDK 25 build 21
   The macOS/AArch64 build 21 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
   
   # Conflicts:
   #	test/langtools/tools/javac/versions/Versions.java
 - feedback: never bump ASM version
 - Update copyright years
   
   Note: any commit hashes below might be outdated due to subsequent
   history rewriting (e.g. git rebase).
   
    + update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitorPreview.java due to 6077665a274
    + update src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java due to 6077665a274
    + update src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java due to 6077665a274
    + update test/langtools/tools/javac/api/TestGetSourceVersions.java due to 6077665a274
    + update test/langtools/tools/javac/classfiles/ClassVersionChecker.java due to 6077665a274
    + update test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java due to 6077665a274
    + update test/langtools/tools/javac/versions/Versions.java due to 6077665a274
 - Update --release 25 symbol information for JDK 24 build 20
   The macOS/AArch64 build 20 was taken from https://jdk.java.net/25/
 - initial commit start-of-JDK-26

-------------

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=02
  Stats: 1705 lines in 56 files changed: 1616 ins; 16 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/25008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008

PR: https://git.openjdk.org/jdk/pull/25008

From vyazici at openjdk.org  Mon May 19 18:11:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 19 May 2025 18:11:55 GMT
Subject: RFR: 8357063: Document preconditions for DecimalDigits methods
 [v4]
In-Reply-To: <pFjJy7Omzm3w-dzls5Ja0EkyCVbs0fd9MNJS_-excic=.6ffd8c75-350f-4ccc-b067-dd7ee3a38e43@github.com>
References: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
 <pFjJy7Omzm3w-dzls5Ja0EkyCVbs0fd9MNJS_-excic=.6ffd8c75-350f-4ccc-b067-dd7ee3a38e43@github.com>
Message-ID: <IhUHZCt7eYgv48WGWf5Q5dlAfi2FmrtGd-fq9l-e7Lw=.8a20d0ca-b436-49f3-91aa-5180cbb9ef3c@github.com>

On Fri, 16 May 2025 16:10:29 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Similar to PR #24982 
>> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   warning

Marked as reviewed by vyazici (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25246#pullrequestreview-2851630246

From rriggs at openjdk.org  Mon May 19 18:21:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 May 2025 18:21:52 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562
In-Reply-To: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
Message-ID: <Jm4ATGoFWP2a8HSBuwAglmdQS5fcBKBxt7TOklUQRjk=.b47ef4c7-26cd-4603-a074-76be89fa898c@github.com>

On Mon, 19 May 2025 13:33:51 GMT, kieran-farrell <duke at openjdk.org> wrote:

> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
> 
> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
> 
> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
> 
> 
> - random-byte-only - 99.8%
> - higher-precision - 3.5%
> - counter-based - 0%
> 
> 
> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
> 
> - random-byte-only   143.487 ? 10.932  ns/op
> - higher-precision      149.651 ?  8.438 ns/op
> - counter-based         245.036 ?  2.943  ns/op
> 
> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.

src/java.base/share/classes/java/util/UUID.java line 195:

> 193:      *
> 194:      * @return A {@code UUID} generated from the current system time
> 195:      */

Seems like there should be a reference to the RFC somewhere here using the @spec javadoc tag.

And also in the class javadoc.

src/java.base/share/classes/java/util/UUID.java line 219:

> 217:         randomBytes[8] |= (byte) 0x80;
> 218: 
> 219:         return new UUID(randomBytes);

This could remove the allocation by composing the high and low longs using shifts and binary operations and ng.next().
Can the sub-microsecond value just be truncated and avoid the expensive divide operation?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2096254869
PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2096265946

From rriggs at openjdk.org  Mon May 19 18:44:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 May 2025 18:44:53 GMT
Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v3]
In-Reply-To: <MgRSlPSknv15Raob7wJjgIROw0Vf8jo43DI6IPnirGM=.8e0d26de-a7f2-47d8-8aeb-bcc86f77847a@github.com>
References: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
 <MgRSlPSknv15Raob7wJjgIROw0Vf8jo43DI6IPnirGM=.8e0d26de-a7f2-47d8-8aeb-bcc86f77847a@github.com>
Message-ID: <WqN3u6iDJoH7iie4yMvWpD9HhTROCj-Cwr5yOaEtv-I=.3cd118f7-e277-4a2f-ad5e-fad3e842fae4@github.com>

On Sat, 5 Apr 2025 05:30:25 GMT, Shaojin Wen <swen at openjdk.org> 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

Please update the performance comparisons (percentage improvement.)

src/java.base/share/classes/java/util/UUID.java line 491:

> 489:      * hexadecimal representation, concatenate these hexadecimal strings into one continuous string, and then interpret
> 490:      * this string as a hexadecimal number to form and return a long value.
> 491:      */

Is there a reference describing this technique?  Such as the Hacker's Delight citation used in java.lang.Long?
If not a longer descriptive comment would be good for maintainability.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22928#pullrequestreview-2851674685
PR Review Comment: https://git.openjdk.org/jdk/pull/22928#discussion_r2096283194

From duke at openjdk.org  Mon May 19 18:46:10 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 19 May 2025 18:46:10 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: <wp_i02Ji5nG8obVLo9gJvHwA73hfC_b2dx56nXVsCoM=.c481ac3c-77ca-4d27-89be-31d98055964f@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <wp_i02Ji5nG8obVLo9gJvHwA73hfC_b2dx56nXVsCoM=.c481ac3c-77ca-4d27-89be-31d98055964f@github.com>
Message-ID: <eWOReitkYl_PFU-pEdWGrLZshlXurcc31h2furS_ZRg=.7efe8b67-fd58-48c4-80eb-aae2844063d0@github.com>

On Sun, 18 May 2025 20:55:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>> use java.lang.ref.Cleaner.
>> 
>> This change is algorithmically similar to the two previous versions:
>> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
>> Bits::reserveMemory(). For both of those versions and this change, a thread
>> calls that function and tries to reserve some space. If it fails, then it
>> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
>> cleaned. If reservation still fails, then it invokes the GC to try to
>> deactivate more cleaners for cleaning. After that GC it keeps trying the
>> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
>> eventually either succeeding or giving up and throwing OOME.
>> 
>> Retaining that algorithmic approach is one of the goals of this change, since
>> it has been successfully in use since JDK 9 (and was originally developed and
>> extensively tested in JDK 8).
>> 
>> The key to this approach is having a way to determine that deactivated
>> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
>> threads help the reference processor until there was no available work.
>> JDK-8156500 waits for the reference processor to quiesce, relying on its
>> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
>> to do this, which is why this change rolls its own Cleaner-like mechanism from
>> the underlying primitives. Like JDK-6857566, this change has waiting threads
>> help with cleaning references. This was a potentially undesirable feature of
>> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
>> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
>> became internal-only somewhere around that time as well.) That's not a concern
>> here, as the cleaners involved are only from DBB, and we know what they look
>> like.
>> 
>> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
>> being done off the reference processing thread, as it may be expensive and
>> slow down enqueuing other pending references. JDK-6857566 only did some of
>> that, and JDK-8156500 lost that feature. This change moves all of the DBB
>> cleaning off of the reference processing thread. (So does PR 22165.)
>> 
>> Neither JDK-6857566 nor this change are...
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move jdk.internal.nio.Cleaner to sun.nio

src/java.base/share/classes/java/nio/Bits.java line 145:

> 143:                         // Increment with overflow to 0, so the value can
> 144:                         // never equal the initial/reset cleanedEpoch value.
> 145:                         RESERVE_GC_EPOCH = Integer.max(0, RESERVE_GC_EPOCH + 1);

Could?also do?the?following which?avoids the?branch in?`Integer.max`:
Suggestion:

                        RESERVE_GC_EPOCH = (RESERVE_GC_EPOCH + 1) & Integer.MAX_VALUE;

src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 209:

> 207:         super(-1, 0, cap, cap, fd, isSync, segment);
> 208:         address = addr;
> 209: 	cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper);

**OpenJDK** unfortunately?uses the?less?accessible?spaces[^1]:
Suggestion:

        cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper);


[^1]:	- https://github.com/prettier/prettier/issues/7475
	- https://alexandersandberg.com/tabs-for-accessibility/

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096283888
PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096296130

From rriggs at openjdk.org  Mon May 19 18:47:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 May 2025 18:47:54 GMT
Subject: RFR: 8357063: Document preconditions for DecimalDigits methods
 [v4]
In-Reply-To: <pFjJy7Omzm3w-dzls5Ja0EkyCVbs0fd9MNJS_-excic=.6ffd8c75-350f-4ccc-b067-dd7ee3a38e43@github.com>
References: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
 <pFjJy7Omzm3w-dzls5Ja0EkyCVbs0fd9MNJS_-excic=.6ffd8c75-350f-4ccc-b067-dd7ee3a38e43@github.com>
Message-ID: <yVopLIUIgqvXHKfKsLT95l7dLhMn1PDTTpsHRa6sSeI=.82829c8c-4ef6-4b55-a2db-4c0ad97ca482@github.com>

On Fri, 16 May 2025 16:10:29 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Similar to PR #24982 
>> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   warning

Useful renames and comment placement improvements.  lgtm.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25246#pullrequestreview-2851703586

From duke at openjdk.org  Mon May 19 18:49:52 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 19 May 2025 18:49:52 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: <dE-Pk4NLUyJ7x1UrGnEwAme4zI6LzhcrcnyhK9_0Drs=.3215116b-cd50-4cae-b4c0-1ec6194cacdb@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <lYLXZxlwTG0V-ujQ4LAoVSnKNVisunvAyJSTy7rEszQ=.d095c373-4722-4821-9040-2c075ebae800@github.com>
 <dE-Pk4NLUyJ7x1UrGnEwAme4zI6LzhcrcnyhK9_0Drs=.3215116b-cd50-4cae-b4c0-1ec6194cacdb@github.com>
Message-ID: <YOoKHc4s1HHMdTnaXnM6zlK1uvwThc6x9gPK9oRyy6E=.fd1a9df6-54fd-4373-919f-a908cc9c5dff@github.com>

On Sun, 18 May 2025 20:50:41 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/nio/Cleaner.java line 26:
>> 
>>> 24:  */
>>> 25: 
>>> 26: package jdk.internal.nio;
>> 
>> The implementation/internal classes for this area are in sun.nio (for historical reasons). Probably best to keep them together.
>
> Good point.  Done.

But?`MhUtil` was?added to?the?newly created?`jdk.internal.invoke` package in?<https://github.com/openjdk/jdk/pull/20972> instead of?adding?it to?the?pre?existing `sun.invoke`?package.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096304667

From vromero at openjdk.org  Mon May 19 19:21:57 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 19 May 2025 19:21:57 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v18]
In-Reply-To: <MPgukNWo0agINMH9L7hhU13BNo-_ZlWV311WmPyZSVQ=.d4b4e536-4280-416c-91f9-910561b97169@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <MPgukNWo0agINMH9L7hhU13BNo-_ZlWV311WmPyZSVQ=.d4b4e536-4280-416c-91f9-910561b97169@github.com>
Message-ID: <cllOLOISOc5eGoHidGa1OrbhnGS04BWPIIs4eERCWdc=.9019fd88-095f-4022-a33c-0e8d6b33c1a3@github.com>

On Mon, 19 May 2025 14:35:40 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - Merge branch 'master' into JDK-8354556
>  - review comments
>  - addressing review comments
>  - addressing review comments
>  - update warning message
>  - Merge branch 'master' into JDK-8354556
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - additional changes from Archie
>  - removing dead code
>  - integrating code from Archie
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/265d6301...904bd4cd

thanks for the reviews

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2892039464

From rriggs at openjdk.org  Mon May 19 19:37:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 May 2025 19:37:52 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: <wp_i02Ji5nG8obVLo9gJvHwA73hfC_b2dx56nXVsCoM=.c481ac3c-77ca-4d27-89be-31d98055964f@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <wp_i02Ji5nG8obVLo9gJvHwA73hfC_b2dx56nXVsCoM=.c481ac3c-77ca-4d27-89be-31d98055964f@github.com>
Message-ID: <YQRD37sSMcVIjPBMvGTEmv7e_pzircI13BlVMMISyHM=.a7f5bbd2-dadc-4a8b-be59-451dfbbc4e0b@github.com>

On Sun, 18 May 2025 20:55:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>> use java.lang.ref.Cleaner.
>> 
>> This change is algorithmically similar to the two previous versions:
>> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
>> Bits::reserveMemory(). For both of those versions and this change, a thread
>> calls that function and tries to reserve some space. If it fails, then it
>> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
>> cleaned. If reservation still fails, then it invokes the GC to try to
>> deactivate more cleaners for cleaning. After that GC it keeps trying the
>> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
>> eventually either succeeding or giving up and throwing OOME.
>> 
>> Retaining that algorithmic approach is one of the goals of this change, since
>> it has been successfully in use since JDK 9 (and was originally developed and
>> extensively tested in JDK 8).
>> 
>> The key to this approach is having a way to determine that deactivated
>> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
>> threads help the reference processor until there was no available work.
>> JDK-8156500 waits for the reference processor to quiesce, relying on its
>> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
>> to do this, which is why this change rolls its own Cleaner-like mechanism from
>> the underlying primitives. Like JDK-6857566, this change has waiting threads
>> help with cleaning references. This was a potentially undesirable feature of
>> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
>> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
>> became internal-only somewhere around that time as well.) That's not a concern
>> here, as the cleaners involved are only from DBB, and we know what they look
>> like.
>> 
>> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
>> being done off the reference processing thread, as it may be expensive and
>> slow down enqueuing other pending references. JDK-6857566 only did some of
>> that, and JDK-8156500 lost that feature. This change moves all of the DBB
>> cleaning off of the reference processing thread. (So does PR 22165.)
>> 
>> Neither JDK-6857566 nor this change are...
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move jdk.internal.nio.Cleaner to sun.nio

The initial PR description is copied into every email. The detail in the PR is appreciated but can be less intrusive if included in a comment after the initial description.

src/java.base/share/classes/java/nio/Bits.java line 170:

> 168:             // without it that test likely fails.  Since failure here
> 169:             // ends in OOME, there's no need to hurry.
> 170:             for (int sleeps = 0; true; ) {

More typical coding pattern in openjdk code.  Here and elsewhere in this PR.
Suggestion:

            while (true) {
                int sleeps = 0;

src/java.base/share/classes/java/nio/BufferCleaner.java line 33:

> 31: import java.util.Objects;
> 32: import sun.nio.Cleaner;
> 33: 

A class cleaner describing the overall objective (an excerpt from the PR description) would be useful.

src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 88:

> 86:                 // Long-standing behavior: when deallocation fails, VM exits.
> 87:                 if (System.err != null) {
> 88:                     new Error("Cleaner terminated abnormally", x).printStackTrace();

The message would be more useful to identify this as a **Buffer** Cleaner terminated abnormally.

src/java.base/share/classes/sun/nio/Cleaner.java line 31:

> 29:  * {@code Cleaner} represents an object and a cleaning action.
> 30:  */
> 31: public interface Cleaner {

Can this be renamed NIOCleaner or NIOBufClenaer or something to avoid the ambiguity between the other cleaner.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25289#pullrequestreview-2851749648
PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096331929
PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096341238
PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096351666
PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096355156

From rriggs at openjdk.org  Mon May 19 19:40:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 May 2025 19:40:52 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: <eWOReitkYl_PFU-pEdWGrLZshlXurcc31h2furS_ZRg=.7efe8b67-fd58-48c4-80eb-aae2844063d0@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <wp_i02Ji5nG8obVLo9gJvHwA73hfC_b2dx56nXVsCoM=.c481ac3c-77ca-4d27-89be-31d98055964f@github.com>
 <eWOReitkYl_PFU-pEdWGrLZshlXurcc31h2furS_ZRg=.7efe8b67-fd58-48c4-80eb-aae2844063d0@github.com>
Message-ID: <f9Aa_t-0AFXS517sWQ28XmD9gpcCez2QTOqwfJoNVoE=.c0ecf2b2-1ded-41d5-b13b-0a087ef19c42@github.com>

On Mon, 19 May 2025 18:40:56 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 209:
> 
>> 207:         super(-1, 0, cap, cap, fd, isSync, segment);
>> 208:         address = addr;
>> 209: 	cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper);
> 
> **OpenJDK** unfortunately?uses the?less?accessible?spaces[^1]:
> Suggestion:
> 
>         cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper);
> 
> 
> [^1]:	- prettier/prettier#7475
> 	- https://alexandersandberg.com/tabs-for-accessibility/

OpenJDK has not considered adoption of tabs-for-accessibility and sticks to using spaces across the codebase.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096367503

From paul.sandoz at oracle.com  Mon May 19 19:55:22 2025
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 19 May 2025 19:55:22 +0000
Subject: Towards a JSON API for the JDK
In-Reply-To: <CA+NR86hECE-T9gMZT6+gbSoFhDpLeVDkvGYqyz-ByV18_MgpVw@mail.gmail.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gt3GNjDPS2m-2wha5AwgumMvBRxKw+bwgTCNQ1xCiDfg@mail.gmail.com>
 <1353089152.267509212.1747398414378.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86hECE-T9gMZT6+gbSoFhDpLeVDkvGYqyz-ByV18_MgpVw@mail.gmail.com>
Message-ID: <FC59D02C-8EF0-49E4-8AF1-97A115495FD1@oracle.com>


> 
> This is part of why fromUntyped/toUntyped is uncomfortable - it's choosing one particular encoding of JSON and making it central to the API. Is that really the most important encoding?
> 


It's one opinionated kind, a simple bi-directional mapping (embedding-projection pair) based on what the json values contain. The implementations can be entirely written less than 100 lines of code using the public API (there are more lines for the documentation). Users can easily write their own and can serve as an example with a bit more exposition in the documentation. The methods could be removed and it would not affect anything else, so it's not fundamental nor central.

Paul.

From paul.sandoz at oracle.com  Mon May 19 19:59:17 2025
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 19 May 2025 19:59:17 +0000
Subject: Towards a JSON API for the JDK
In-Reply-To: <CA+NR86g8FRfZqv9FCF-pHh3JM9Vcin=A0q3_YWkwxQZaM_GpTQ@mail.gmail.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <CA+NR86g8FRfZqv9FCF-pHh3JM9Vcin=A0q3_YWkwxQZaM_GpTQ@mail.gmail.com>
Message-ID: <E685C3A3-959C-4322-8134-9BEC3611AFDA@oracle.com>



On May 17, 2025, at 4:37?AM, Ethan McCue <ethan at mccue.dev> wrote:

I think it's worth noting that the way you used the prospective API in your ONNX code is not representative of how the API would generally be used in a jdk-only scenario. Custom making a general transformation from JsonValue -> Record is outside the ken of i'd say most. I'd be interested in an experience report of using it straight up.


Fair point. Although my use-case is likely more complex I hope my out-of-the-box experience is similar for others that may use it in less complex ways.

Pau.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250519/fc34da40/attachment-0001.htm>

From jiangli at openjdk.org  Mon May 19 19:59:51 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 19 May 2025 19:59:51 GMT
Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder
 on static-jdk [v2]
In-Reply-To: <ayYWJF-nXUjwIXdCqQnKuPC4DDaRRiYp6ud9PpXoxeY=.a21e6eee-bf39-4670-b10d-ca4a5fe9b320@github.com>
References: <E986980rvWra05uWXYMdT8N4i_0RGxNC_KubDF6tXAw=.a6ab5563-b75c-45b2-b367-31d001cc294e@github.com>
 <3RWZl77waTqYm1lm8ImxBegeni5IcB3jD0cUUiJvWJw=.11c71454-89b8-46ec-8aee-e484de538480@github.com>
 <ayYWJF-nXUjwIXdCqQnKuPC4DDaRRiYp6ud9PpXoxeY=.a21e6eee-bf39-4670-b10d-ca4a5fe9b320@github.com>
Message-ID: <40zDBK-DvbpQPX1ColLdmfgGA1yTeUtidbOQV22QZCg=.93953b52-747c-4f8a-9ef4-5ad45d30f6d5@github.com>

On Thu, 15 May 2025 17:15:20 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> test/lib-test/TEST.ROOT line 31:
>> 
>>> 29: keys=randomness
>>> 30: 
>>> 31: # Minimum jtreg version
>> 
>> Shoule we update the copyright year for file TestNativeProcessBuilder.java
>
> @sendaoYan Please let me know if you have any additional review comments, thanks.
> 
> Also looking for a 'R'eviewer for reviewing. Thanks!

A friendly ping

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25220#discussion_r2096399535

From paul.sandoz at oracle.com  Mon May 19 20:02:50 2025
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 19 May 2025 20:02:50 +0000
Subject: Towards a JSON API for the JDK
In-Reply-To: <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <f3cc90ef-25f3-41e3-a82b-0bac063c5733@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>



On May 19, 2025, at 8:16?AM, Remi Forax <forax at univ-mlv.fr> wrote:

Okay,
i've taken a look to the design and this is not pretty.


That seems an exaggerated statement to me. It's a trade-off, a compromise, allowing others to implement their own parsers, perhaps from non-textual representations. So of course we cannot enforce certain constraints and we need to specify how implementations must behave.


The main issue is that the javadoc claims that
  "Both JsonValue instances and their underlying values are immutable."
but at the same time any subtypes of JsonValue is non-sealed so anyone can implement let say JsonString and adds it's own mutable implementation.

Because the hierarchy is non sealed, it also means that it is easy to create JsonValue that are invalid,
for example


var funJsonNumber = new JsonNumber() {
  public Number toNumber() {
    return Double.NaN;
  }
  public BigDecimal toBigDecimal() {
    throw new UnsupportedOperationException();
  }
  public String toString() {
    return "NaN";
  }
};

var json = Json.fromUntyped(List.of(funJsonNumber));

For me, the Json hierarchy should be implemented with true ADTs, with all subtypes of JsonValue being records.


Not doing that for reasons Brian has already explained.

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250519/229b47e2/attachment.htm>

From paul.sandoz at oracle.com  Mon May 19 20:15:55 2025
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 19 May 2025 20:15:55 +0000
Subject: Towards a JSON API for the JDK
In-Reply-To: <eaa41fc4-b632-40fa-bbce-581b9f6365ca@civilian-framework.org>
References: <eaa41fc4-b632-40fa-bbce-581b9f6365ca@civilian-framework.org>
Message-ID: <6F0F7985-2011-4530-8110-A6FCA53F6E05@oracle.com>

The approach to the design of this API leans heavily on ongoing and future language and library features. This is why the API is so small as we don?t want conflicts with what we may do in the future. In the document we briefly mention data binding but don?t provide further context:

Advanced features, such as data
binding or path-based traversal should be possible to implement as layered
features, but for simplicity are not included in the core API

We think that Serialization 2.0 [1], a data-oriented approach to serialization, may provide the mechanism for binding between instances of JsonValue.

Paul.

[1] https://www.youtube.com/watch?v=fbqAyRJoQO0

On May 19, 2025, at 10:15?AM, Johannes D?bler <jd at civilian-framework.org> wrote:

Developers use JSON libraries like Fastjson, Jackson and Gson primarily (my claim) because they can marshal between JSON files and POJOs in one line of code with great performance and can easily tweak the mapping using annotations or adapter classes.
Being able to read/write a JSON file from/to a generic tree of JsonValues might have use-cases, but manually implementing data-binding based one tree traversal w/wo pattern matching will produce bloated and fragile code (my claim).
So my question is if there are plans to address data-binding in the future and how it would relate to the envisioned core API.
Thanks
Johannes


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250519/efcd0534/attachment-0001.htm>

From swen at openjdk.org  Mon May 19 20:17:43 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 19 May 2025 20:17:43 GMT
Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v4]
In-Reply-To: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
References: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
Message-ID: <xz61IFhEj4GnYbVwNp3rN528na-u-_GHm-sF7jON-HE=.e1b75fef-4270-4987-84c0-a03ea59dd670@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 with a new target base 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:

 - Merge remote-tracking branch 'upstream/master' into optim_uuid_to_string_202501
 - simplify code
 - Remove redundant comments
 - 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
 - ... and 6 more: https://git.openjdk.org/jdk/compare/6f6e5efd...878a3cb7

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22928/files
  - new: https://git.openjdk.org/jdk/pull/22928/files/55223571..878a3cb7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=02-03

  Stats: 353363 lines in 4033 files changed: 118357 ins; 216754 del; 18252 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 kbarrett at openjdk.org  Mon May 19 20:18:54 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 19 May 2025 20:18:54 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: <eWOReitkYl_PFU-pEdWGrLZshlXurcc31h2furS_ZRg=.7efe8b67-fd58-48c4-80eb-aae2844063d0@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <wp_i02Ji5nG8obVLo9gJvHwA73hfC_b2dx56nXVsCoM=.c481ac3c-77ca-4d27-89be-31d98055964f@github.com>
 <eWOReitkYl_PFU-pEdWGrLZshlXurcc31h2furS_ZRg=.7efe8b67-fd58-48c4-80eb-aae2844063d0@github.com>
Message-ID: <_Sn16clurXPHgVjZVt8Uq4uH4WeJ23qa1XTQnw3WY4w=.62794a53-a9d0-4eb6-a8df-62b04604b555@github.com>

On Mon, 19 May 2025 18:30:45 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/java/nio/Bits.java line 145:
> 
>> 143:                         // Increment with overflow to 0, so the value can
>> 144:                         // never equal the initial/reset cleanedEpoch value.
>> 145:                         RESERVE_GC_EPOCH = Integer.max(0, RESERVE_GC_EPOCH + 1);
> 
> Could?also do?the?following which?avoids the?branch in?`Integer.max`:
> Suggestion:
> 
>                         RESERVE_GC_EPOCH = (RESERVE_GC_EPOCH + 1) & Integer.MAX_VALUE;

I think the use of `Integer.max` is clearer, any performance difference is insignificant, and the compiler can
make that change as an optimization if appropriate. So I'm not inclined to accept this suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096422654

From bpb at openjdk.org  Mon May 19 20:21:50 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 19 May 2025 20:21:50 GMT
Subject: RFR: 8357052: java/io/File/GetXSpace.java prints wrong values in
 exception
In-Reply-To: <uKC3cFU14_1fPbsr9tamorif3MftHeN-Sfbz2483uik=.b18e053d-9be9-4b94-8a5f-cbed7f2e032a@github.com>
References: <uKC3cFU14_1fPbsr9tamorif3MftHeN-Sfbz2483uik=.b18e053d-9be9-4b94-8a5f-cbed7f2e032a@github.com>
Message-ID: <BjB1MN5ig43IZpiovy_3lCIA3QV1NqfbHCXndcJWuOU=.99c2ba20-b5a8-4ca3-9af5-40bace5b8214@github.com>

On Thu, 15 May 2025 13:49:14 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> When the test java/io/File/GetXSpace.java fails, because the usable space is greater than the free space, the values in the exception are not the correct ones.

@ArnoZeller Please issue the `/integrate` command so that this request may be sponsored.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25250#issuecomment-2892170536

From kbarrett at openjdk.org  Mon May 19 20:22:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 19 May 2025 20:22:52 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: <f9Aa_t-0AFXS517sWQ28XmD9gpcCez2QTOqwfJoNVoE=.c0ecf2b2-1ded-41d5-b13b-0a087ef19c42@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <wp_i02Ji5nG8obVLo9gJvHwA73hfC_b2dx56nXVsCoM=.c481ac3c-77ca-4d27-89be-31d98055964f@github.com>
 <eWOReitkYl_PFU-pEdWGrLZshlXurcc31h2furS_ZRg=.7efe8b67-fd58-48c4-80eb-aae2844063d0@github.com>
 <f9Aa_t-0AFXS517sWQ28XmD9gpcCez2QTOqwfJoNVoE=.c0ecf2b2-1ded-41d5-b13b-0a087ef19c42@github.com>
Message-ID: <3DkRh7Fg6uianW9tEAegtTMlS0XPR-p2-AVcG0AaM5c=.b7207af6-1340-4041-888f-ed76da0e321c@github.com>

On Mon, 19 May 2025 19:37:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 209:
>> 
>>> 207:         super(-1, 0, cap, cap, fd, isSync, segment);
>>> 208:         address = addr;
>>> 209: 	cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper);
>> 
>> **OpenJDK** unfortunately?uses the?less?accessible?spaces[^1]:
>> Suggestion:
>> 
>>         cleaner = (unmapper == null) ? null : BufferCleaner.register(this, unmapper);
>> 
>> 
>> [^1]:	- prettier/prettier#7475
>> 	- https://alexandersandberg.com/tabs-for-accessibility/
>
> OpenJDK has not considered adoption of tabs-for-accessibility and sticks to using spaces across the codebase.

I didn't notice that a tab had snuck in there.  Thanks for spotting.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096427690

From paul.sandoz at oracle.com  Mon May 19 20:36:11 2025
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 19 May 2025 20:36:11 +0000
Subject: Towards a JSON API for the JDK
In-Reply-To: <52514642-e172-4096-a616-a2c9a9787552@gmail.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <52514642-e172-4096-a616-a2c9a9787552@gmail.com>
Message-ID: <42EC08C7-4C39-4F05-A947-70F08C2818CE@oracle.com>

Hi Cay,

It would be really helpful to share some more detailed use-cases on editing/modification that you may reasonably expect users to perform.

I hope we might be able to devise a transformation API, hopefully layered on top of the public API and possibly with structural sharing for unmodified parts. One such experiment is presented below that copies the flat map transformation patterns used by the class file API and code reflection (a combination of traversal + building). It can be used like this:

        JsonObject o = ...

        System.out.println(transformObject(o, (jc, c) -> {
            if (jc instanceof JsonObjectEntry(var name, JsonNumber n) && name.equals("UnitPrice")) {
                // Replace number
                c.accept(new JsonObjectEntry(name, JsonNumber.of(n.value().doubleValue() + 10.0)));
            } else {
                // Copy
                c.accept(jc);
            }
        }));

This needs a lot more thought but there might be something to this.

Paul.


public class JsonTransform {
    public sealed interface JsonComponent {
    }

    public record JsonObjectMember(String name, JsonValue v) implements JsonComponent {
    }

    public record JsonArrayElement(JsonValue v) implements JsonComponent {
    }

    public static JsonObject transformObject(JsonObject o, BiConsumer<JsonComponent, Consumer<JsonComponent>> f) {
        /* value */
        class ObjectConsumer implements Consumer<JsonComponent> {
            final Map<String, JsonValue> outputEntries = new HashMap<>();

            JsonObjectMember input;

            @Override
            public void accept(JsonComponent _output) {
                JsonObjectMember output = (JsonObjectMember) _output;

                JsonValue outputValue;
                if (input == output) {
                    // traverse
                    outputValue = switch (input.v()) {
                        case JsonArray ja -> transformArray(ja, f);
                        case JsonObject jo -> transformObject(jo, f);
                        case JsonValue jv -> jv;
                    };
                } else {
                    // replace
                    outputValue = output.v();
                }

                outputEntries.put(output.name(), outputValue);
            }
        }
        ObjectConsumer c = new ObjectConsumer();

        for (Map.Entry<String, JsonValue> inputEntry : o.members().entrySet()) {
            JsonObjectMember input = c.input = new JsonObjectMember(inputEntry.getKey(), inputEntry.getValue());
            f.accept(input, c);
        }

        return JsonObject.of(c.outputEntries);
    }

    public static JsonArray transformArray(JsonArray a, BiConsumer<JsonComponent, Consumer<JsonComponent>> f) {
        /* value */
        class ArrayConsumer implements Consumer<JsonComponent> {
            final ArrayList<JsonValue> outputElements = new ArrayList<>();

            JsonArrayElement input;

            @Override
            public void accept(JsonComponent _output) {
                JsonArrayElement output = (JsonArrayElement) _output;

                JsonValue outputValue;
                if (input == output) {
                    // traverse
                    outputValue = switch (input.v()) {
                        case JsonArray ja -> transformArray(ja, f);
                        case JsonObject jo -> transformObject(jo, f);
                        case JsonValue jv -> jv;
                    };
                } else {
                    // replace
                    outputValue = output.v();
                }

                outputElements.add(outputValue);
            }
        }
        ArrayConsumer c = new ArrayConsumer();

        List<JsonValue> values = a.values();
        for (int i = 0; i < values.size(); i++) {
            // @@@ pass index?
            JsonArrayElement input = c.input = new JsonArrayElement(values.get(i));
            f.accept(input, c);
        }
        return JsonArray.of(c.outputElements);
    }
}


On May 17, 2025, at 10:55?PM, Cay Horstmann <cay.horstmann at gmail.com> wrote:

+1 for having a JSON battery included with the JDK. And for "Our primary goal is that the library be simple to use for parsing, traversing, and generating conformant JSON documents."

Generating JSON could be easier. Why not convenience methods Json.newObject and Json.newArray like in https://github.com/arkanovicz/essential-json?

Parsing with instanceof will work, but is obviously painful today, as your example shows. The simplification with deconstruction patterns is not impressive either.

JsonValue doc = Json.parse(inputString);
if (doc instanceof JsonObject(var members)
    && members.get("name") instanceof JsonString(String name)
    && members.get("age") instanceof JsonNumber(int age)) {
            // use "name" and "age"
} else throw new NoSuchArgumentException();

vs. Jackson

String name = doc.get("name").asText();
int age = doc.get("age").asInt();
...

If only there was some deconstruction magic that approximates the JavaScript code

const doc = { name: "John", age: 30 }
const { name, age } = doc

What about editing documents? With Jackson, you can mutate objects and arrays. I see the appeal of immutability, but then there needs to be a convenient transform API. Right now, making John one year older is not pretty:

var nextYearDoc = switch (doc) {
   case JsonObject(var members) if
       members.get("name") instanceof JsonString(String name)
       && members.get("age") instanceof JsonNumber(int age)) ->
           Json.fromUntyped(Map.of("name", name, "age", age + 1));
   default -> throw new NoSuchArgumentException();
}

And it gets worse if John is nested more deeply in a document.

I have worked a lot with immutable XML in Scala. One minimally needs a mechanism for recursive rewriting with a node replacement function. I am not aware of an existing library that attempts this in Java for JSON. I am sure it can be done, but it may not be trivial to do such an API well.

Cheers,

Cay

PS. Trying to create and show the youthful John gives me grief right now:

Json.fromUntyped(Map.of("name", "John", "age", 30)).toString()
|  Exception java.lang.NullPointerException: Cannot read the array length because "value" is null
|        at String.rangeCheck (String.java:307)
|        at String.<init> (String.java:303)
|        at JsonNumberImpl.toString (JsonNumberImpl.java:105)
|        at JsonObjectImpl.toString (JsonObjectImpl.java:56)
|        at (#23:1)

The JsonNumberImpl.toString method needs to handle the case that it was constructed from a Number.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250519/2ef8bc07/attachment-0001.htm>

From kbarrett at openjdk.org  Mon May 19 20:36:51 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 19 May 2025 20:36:51 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: <YQRD37sSMcVIjPBMvGTEmv7e_pzircI13BlVMMISyHM=.a7f5bbd2-dadc-4a8b-be59-451dfbbc4e0b@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <wp_i02Ji5nG8obVLo9gJvHwA73hfC_b2dx56nXVsCoM=.c481ac3c-77ca-4d27-89be-31d98055964f@github.com>
 <YQRD37sSMcVIjPBMvGTEmv7e_pzircI13BlVMMISyHM=.a7f5bbd2-dadc-4a8b-be59-451dfbbc4e0b@github.com>
Message-ID: <iQjnHXb8bIKGOx3df776ZV0GltHfKqJAl2cPP084s_4=.fa94696a-bb43-425e-baf9-aacc38ad50f9@github.com>

On Mon, 19 May 2025 19:27:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/sun/nio/Cleaner.java line 31:
> 
>> 29:  * {@code Cleaner} represents an object and a cleaning action.
>> 30:  */
>> 31: public interface Cleaner {
> 
> Can this be renamed NIOCleaner or NIOBufClenaer or something to avoid the ambiguity between the other cleaner.

I intentionally (re)used the "Cleaner" name to avoid a bunch of renames that
would increase the size of the change and distract from the meat of it. I
think the name to use might be affected by how the implementation of the set
of cleanup objects might get merged between the new java.nio.BufferCleaner and
java.lang.ref.Cleaner. Perhaps the java.lang.ref.Cleaner.Cleanable interface
should be used throughout? I didn't want to expand this change to include
those kinds of questions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096448999

From darcy at openjdk.org  Mon May 19 20:43:52 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 19 May 2025 20:43:52 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
In-Reply-To: <SR_4-v-Y3EajMlQGMIxGQyfkZx4XlchmSs4MQTD6yAM=.97982bd4-8aec-406a-b13e-43ffce663f52@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
 <SnUSWGwMDdeWI9ivGw50g8tiYs7CTTACfWI_pmI93Ho=.0cace409-d43b-4e15-bb0f-9939555429e5@github.com>
 <SR_4-v-Y3EajMlQGMIxGQyfkZx4XlchmSs4MQTD6yAM=.97982bd4-8aec-406a-b13e-43ffce663f52@github.com>
Message-ID: <WZZYF8Iya98gTL9llOIM3I7BnaP_H9j8FAngihjK7Bg=.4dce64e4-4b73-4a7d-b6d9-c3d49802fa0e@github.com>

On Mon, 19 May 2025 11:31:23 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodType.java line 1341:
>> 
>>> 1339:      * @throws ClassNotFoundException if one of the component classes cannot be resolved
>>> 1340:      * @see <code>MethodType.readResolve()</code>
>>> 1341:      * @see <code>MethodType.writeObject(ObjectOutputStream s)</code>
>> 
>> This is already not generated by the javadoc as this method is private. Why is this check against a private method?
>
> They are documented in [this page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType)

Okay -- if there is some link to the private serial-related methods even in a public javadoc run, I think it would be preferable if links to those methods could be resolved by javadoc. Otherwise, if the links to private methods _from a private method_, would be valid in a private javadoc run, I thinks more refined version of warning would let those be.

As it is, if the see tags are going to stay, I don't think `<code>foo</code>` markup should be used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2096456914

From kbarrett at openjdk.org  Mon May 19 20:46:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 19 May 2025 20:46:55 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: <YQRD37sSMcVIjPBMvGTEmv7e_pzircI13BlVMMISyHM=.a7f5bbd2-dadc-4a8b-be59-451dfbbc4e0b@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <wp_i02Ji5nG8obVLo9gJvHwA73hfC_b2dx56nXVsCoM=.c481ac3c-77ca-4d27-89be-31d98055964f@github.com>
 <YQRD37sSMcVIjPBMvGTEmv7e_pzircI13BlVMMISyHM=.a7f5bbd2-dadc-4a8b-be59-451dfbbc4e0b@github.com>
Message-ID: <KkX0Jw-Xrm-MgKomtLfWeuK9gn6Pj9ksNn1Y8bIaAoA=.7056391c-7b85-479c-aec4-9ecdc5051153@github.com>

On Mon, 19 May 2025 19:24:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 88:
> 
>> 86:                 // Long-standing behavior: when deallocation fails, VM exits.
>> 87:                 if (System.err != null) {
>> 88:                     new Error("Cleaner terminated abnormally", x).printStackTrace();
> 
> The message would be more useful to identify this as a **Buffer** Cleaner terminated abnormally.

This code was cribbed from https://github.com/openjdk/jdk/pull/22165, but your suggestion has led me to
discover that wasn't right. I'm going to need to do some rework of the exception handling around cleaning.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2096460505

From forax at univ-mlv.fr  Mon May 19 20:56:32 2025
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 19 May 2025 22:56:32 +0200 (CEST)
Subject: Towards a JSON API for the JDK
In-Reply-To: <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <f3cc90ef-25f3-41e3-a82b-0bac063c5733@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
 <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
Message-ID: <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>

> From: "Paul Sandoz" <paul.sandoz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "core-libs-dev"
> <core-libs-dev at openjdk.org>
> Sent: Monday, May 19, 2025 10:02:50 PM
> Subject: Re: Towards a JSON API for the JDK

>> On May 19, 2025, at 8:16 AM, Remi Forax <forax at univ-mlv.fr> wrote:

>> Okay,
>> i've taken a look to the design and this is not pretty.

> That seems an exaggerated statement to me. It's a trade-off, a compromise,
> allowing others to implement their own parsers, perhaps from non-textual
> representations. So of course we cannot enforce certain constraints and we need
> to specify how implementations must behave.

>> The main issue is that the javadoc claims that
>> "Both JsonValue instances and their underlying values are immutable."
>> but at the same time any subtypes of JsonValue is non-sealed so anyone can
>> implement let say JsonString and adds it's own mutable implementation.

You can not claim that JsonValue instances are immutable while obviously they are not. 
You can not claim that JsonValue subtypes are ADTs while obviously JsonValue is not algebraic. 

You allow anybody to write their own class inside the JsonValue hierarchy, so there is no safety, strings can be not escaped correctly, number can represent invalid values, etc. 

The minute I write a method that takes a JsonValue as parameter i'm writing unsafe code, 

You are hoping that nobody will ever extend JsonValue subtypes, that's wishful thinking, this is not a safe design ... this is not pretty. 

R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250519/b161488d/attachment-0001.htm>

From markus at headcrashing.eu  Mon May 19 21:02:18 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Mon, 19 May 2025 23:02:18 +0200
Subject: Towards a JSON API for the JDK
In-Reply-To: <42EC08C7-4C39-4F05-A947-70F08C2818CE@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <52514642-e172-4096-a616-a2c9a9787552@gmail.com>
 <42EC08C7-4C39-4F05-A947-70F08C2818CE@oracle.com>
Message-ID: <78efdce4-c8da-4c2a-8275-d4e6334831a9@headcrashing.eu>

Paul,

thank you for picking up the topic JSON. I do like the simplicity of 
your proposal, OTOH I have concerns:

* Will it it be sustaining?

We added a XML API when XML was "the" big thing, and now it is not a big 
thing anymore and we can't get rid of the XML API without breaking 
things. So does it really make sense to add a JSON API to OpenJDK? I see 
the risk that in 10 years we are in the same situation as with XML: It 
got replaced with "the" next big thing, and then it lingers in the JDK 
together with the XML API. Maybe it would be better to have some 
"beginner's bundle" with all those goodies that newcomers need, instead 
of making all of that part of the JRE?

* Will it be too late?

As JSON is such a big thing for many years, there are lots of 
implementations, and several abstracting APIs already, most prominently 
Jakarta JSON-P (formerly Java EE JSON-P; 
https://jakartaee.github.io/jsonp-api/). Does it make really make much 
sense to provide a competitive abstraction API?

* Will it be too verbose?

I doubt that the not really short-to-read code samples really attract 
beginners. And all others simply go with existing solutions, as they 
have no benefit from abondoning existing solutions.

-Markus


From jlu at openjdk.org  Mon May 19 21:02:49 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 19 May 2025 21:02:49 GMT
Subject: RFR: 8357275: Locale.Builder.setLanguageTag should explicitly state
 extlangs are allowed
Message-ID: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>

It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/25309/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25309&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357275
  Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25309.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25309/head:pull/25309

PR: https://git.openjdk.org/jdk/pull/25309

From paul.sandoz at oracle.com  Mon May 19 21:18:26 2025
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 19 May 2025 21:18:26 +0000
Subject: Towards a JSON API for the JDK
In-Reply-To: <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <f3cc90ef-25f3-41e3-a82b-0bac063c5733@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
 <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
 <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com>

Those extending the non-sealed subtypes of JsonValue must conform to the requirements that are specified. The current documentation could be more clearly written as to what those requirements are. Of course we cannot enforce those requirements any more than we can enforce the requirements specified for implementations of List.

Paul.

On May 19, 2025, at 1:56?PM, forax at univ-mlv.fr wrote:



________________________________
From: "Paul Sandoz" <paul.sandoz at oracle.com>
To: "Remi Forax" <forax at univ-mlv.fr>
Cc: "Brian Goetz" <brian.goetz at oracle.com>, "core-libs-dev" <core-libs-dev at openjdk.org>
Sent: Monday, May 19, 2025 10:02:50 PM
Subject: Re: Towards a JSON API for the JDK


On May 19, 2025, at 8:16?AM, Remi Forax <forax at univ-mlv.fr> wrote:

Okay,
i've taken a look to the design and this is not pretty.


That seems an exaggerated statement to me. It's a trade-off, a compromise, allowing others to implement their own parsers, perhaps from non-textual representations. So of course we cannot enforce certain constraints and we need to specify how implementations must behave.


The main issue is that the javadoc claims that
  "Both JsonValue instances and their underlying values are immutable."
but at the same time any subtypes of JsonValue is non-sealed so anyone can implement let say JsonString and adds it's own mutable implementation.

You can not claim that JsonValue instances are immutable while obviously they are not.
You can not claim that JsonValue subtypes are ADTs while obviously JsonValue is not algebraic.

You allow anybody to write their own class inside the JsonValue hierarchy, so there is no safety, strings can be not escaped correctly, number can represent invalid values, etc.

The minute I write a method that takes a JsonValue as parameter i'm writing unsafe code,

You are hoping that nobody will ever extend JsonValue subtypes, that's wishful thinking, this is not a safe design ... this is not pretty.

R?mi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250519/d0f2ea41/attachment-0001.htm>

From forax at univ-mlv.fr  Mon May 19 21:55:51 2025
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 19 May 2025 23:55:51 +0200 (CEST)
Subject: Towards a JSON API for the JDK
In-Reply-To: <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
 <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
 <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>
 <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com>
Message-ID: <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr>

> From: "Paul Sandoz" <paul.sandoz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "core-libs-dev"
> <core-libs-dev at openjdk.org>
> Sent: Monday, May 19, 2025 11:18:26 PM
> Subject: Re: Towards a JSON API for the JDK

> Those extending the non-sealed subtypes of JsonValue must conform to the
> requirements that are specified. The current documentation could be more
> clearly written as to what those requirements are. Of course we cannot enforce
> those requirements any more than we can enforce the requirements specified for
> implementations of List.

List is such a good example. 
For a List, like for a JsonValue, you have no idea if the implementation is mutable or not, 
so you can use a defensive copy using List.copyOf() (or Collections.unmodifiableList(new ArrayList<>(list)) in the older version of Java). 

How to do a defensive copy of a JsonValue ? 

The other issue I see is lazyness in Json.parse(). The API is restricted to String/char[], so restricted to JSON document that are not big. 
If the document is not big, lazyness usually make things slower and it also delays the moment you know if the document is a valid JSON document or not. 
With the actual design, you have no way to know if a JSON document is valid. 

If you combine both things, the fact that you have a big list of requirements for each subtypes and eager parsing, you are not far from having only one implementation possible, 
hence the idea of implementing real ADTs using records. 

> Paul.

R?mi 

>> On May 19, 2025, at 1:56 PM, forax at univ-mlv.fr wrote:

>>> From: "Paul Sandoz" <paul.sandoz at oracle.com>
>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "core-libs-dev"
>>> <core-libs-dev at openjdk.org>
>>> Sent: Monday, May 19, 2025 10:02:50 PM
>>> Subject: Re: Towards a JSON API for the JDK

>>>> On May 19, 2025, at 8:16 AM, Remi Forax <forax at univ-mlv.fr> wrote:

>>>> Okay,
>>>> i've taken a look to the design and this is not pretty.

>>> That seems an exaggerated statement to me. It's a trade-off, a compromise,
>>> allowing others to implement their own parsers, perhaps from non-textual
>>> representations. So of course we cannot enforce certain constraints and we need
>>> to specify how implementations must behave.

>>>> The main issue is that the javadoc claims that
>>>> "Both JsonValue instances and their underlying values are immutable."
>>>> but at the same time any subtypes of JsonValue is non-sealed so anyone can
>>>> implement let say JsonString and adds it's own mutable implementation.

>> You can not claim that JsonValue instances are immutable while obviously they
>> are not.
>> You can not claim that JsonValue subtypes are ADTs while obviously JsonValue is
>> not algebraic.

>> You allow anybody to write their own class inside the JsonValue hierarchy, so
>> there is no safety, strings can be not escaped correctly, number can represent
>> invalid values, etc.

>> The minute I write a method that takes a JsonValue as parameter i'm writing
>> unsafe code,

>> You are hoping that nobody will ever extend JsonValue subtypes, that's wishful
>> thinking, this is not a safe design ... this is not pretty.

>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250519/f08d6795/attachment.htm>

From ethan at mccue.dev  Mon May 19 22:46:31 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Mon, 19 May 2025 18:46:31 -0400
Subject: Towards a JSON API for the JDK
In-Reply-To: <FC59D02C-8EF0-49E4-8AF1-97A115495FD1@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gt3GNjDPS2m-2wha5AwgumMvBRxKw+bwgTCNQ1xCiDfg@mail.gmail.com>
 <1353089152.267509212.1747398414378.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86hECE-T9gMZT6+gbSoFhDpLeVDkvGYqyz-ByV18_MgpVw@mail.gmail.com>
 <FC59D02C-8EF0-49E4-8AF1-97A115495FD1@oracle.com>
Message-ID: <CA+NR86h4Zwc=6D8Eodze=zAHQVgTGgMCpzzJvvg06O8j1_DLZw@mail.gmail.com>

What I mean by central in this context isn't that it's at the core of
things and features are built on top of it - as you note it is a valid
transformation of the hierarchy.

What I mean is that absent other construction/deconstruction apis it is the
most convenient avenue for those tasks. So code using the API would trend
towards using it. See Remi's usage of fromUntyped elsewhere in the
discussion tree.

The thing that the language doesn't have yet is patterns. We have all the
mechanism for creating objects. The broad issue I see is that, if we take
the view that >in general< deconstruction should be the dual of
construction - the mechanics for construction should probably be influenced
by how you want people pulling these things apart.

Basic example - JsonString.of - that is null hostile for good reason, but
it is very easy to imagine wanting to write code that deals uniformly with
absent, null, and string values for a field in an object.

So that puts a pressure - beyond creation ergonomics - on a Json.of that is
null-tolerant. Since that would be a good place for a dual pattern for
pulling out a possibly nullable object member.

(but still wouldn't solve for absent ones - I have a doc somewhere with
like 15 options none of which inspire joy and many of which are conditional
on exactly how patterns ship)

On Mon, May 19, 2025, 3:55?PM Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> >
> > This is part of why fromUntyped/toUntyped is uncomfortable - it's
> choosing one particular encoding of JSON and making it central to the API.
> Is that really the most important encoding?
> >
>
>
> It's one opinionated kind, a simple bi-directional mapping
> (embedding-projection pair) based on what the json values contain. The
> implementations can be entirely written less than 100 lines of code using
> the public API (there are more lines for the documentation). Users can
> easily write their own and can serve as an example with a bit more
> exposition in the documentation. The methods could be removed and it would
> not affect anything else, so it's not fundamental nor central.
>
> Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250519/6bf0f1b1/attachment-0001.htm>

From vromero at openjdk.org  Mon May 19 22:50:04 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 19 May 2025 22:50:04 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v18]
In-Reply-To: <MPgukNWo0agINMH9L7hhU13BNo-_ZlWV311WmPyZSVQ=.d4b4e536-4280-416c-91f9-910561b97169@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <MPgukNWo0agINMH9L7hhU13BNo-_ZlWV311WmPyZSVQ=.d4b4e536-4280-416c-91f9-910561b97169@github.com>
Message-ID: <uRyaK_g1CX8Xba6I2uCuPjiOAuzdAa1WfX1Blg0df88=.12cdaa10-5aff-4080-9f1a-7cde88af85c2@github.com>

On Mon, 19 May 2025 14:35:40 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - Merge branch 'master' into JDK-8354556
>  - review comments
>  - addressing review comments
>  - addressing review comments
>  - update warning message
>  - Merge branch 'master' into JDK-8354556
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - additional changes from Archie
>  - removing dead code
>  - integrating code from Archie
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/265d6301...904bd4cd

thanks guys for the reviews and contributions

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2892451481

From vromero at openjdk.org  Mon May 19 22:50:06 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 19 May 2025 22:50:06 GMT
Subject: Integrated: 8354556: Expand value-based class warnings to
 java.lang.ref API
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <5a5jcUgnclxBixFti4n6YX4EPOqXQBKCzhQqZQVPXHU=.987b3c82-af88-47a6-a2bd-d91c1002aedf@github.com>

On Fri, 18 Apr 2025 00:06:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

This pull request has now been integrated.

Changeset: 637e9d16
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/637e9d16ddb21003234abcd32f759aefd91f21f9
Stats:     647 lines in 32 files changed: 562 ins; 37 del; 48 mod

8354556: Expand value-based class warnings to java.lang.ref API

Co-authored-by: Archie Cobbs <acobbs at openjdk.org>
Reviewed-by: jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/24746

From swen at openjdk.org  Mon May 19 23:07:58 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 19 May 2025 23:07:58 GMT
Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v4]
In-Reply-To: <xz61IFhEj4GnYbVwNp3rN528na-u-_GHm-sF7jON-HE=.e1b75fef-4270-4987-84c0-a03ea59dd670@github.com>
References: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
 <xz61IFhEj4GnYbVwNp3rN528na-u-_GHm-sF7jON-HE=.e1b75fef-4270-4987-84c0-a03ea59dd670@github.com>
Message-ID: <5B2SVUN_H6PROzr5_PLAhU8nv9l7NUwF0TCr1BUAgks=.38cd964f-20ca-4d02-a5ef-0f084eb0b66e@github.com>

On Mon, 19 May 2025 20:17:43 GMT, Shaojin Wen <swen at openjdk.org> 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 with a new target base 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:
> 
>  - Merge remote-tracking branch 'upstream/master' into optim_uuid_to_string_202501
>  - simplify code
>  - Remove redundant comments
>  - 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
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/f9f2be52...878a3cb7

The latest performance test numbers show that under AMD X64, the performance is improved by about 21%, and under MacBook M1 Pro, the performance is improved by about 7%.

## performance test scripts

git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

# origin
git checkout bd99525633e4d3d3f180a6678eedb8780dbb6139
make test TEST="micro:java.util.UUIDBench.toString"

# current
git checkout 878a3cb7c73b777eb5385b3e4d158c998cd9be46
make test TEST="micro:java.util.UUIDBench.toString"



## aliyun_ecs_c8a_x64 (CPU AMD EPYC? Genoa)

-# origin  bd99525633e4d3d3f180a6678eedb8780dbb6139
-Benchmark           (size)   Mode  Cnt   Score   Error   Units
-UUIDBench.toString   20000  thrpt   15  93.320 ? 0.359  ops/us

+# current 878a3cb7c73b777eb5385b3e4d158c998cd9be46
+Benchmark           (size)   Mode  Cnt    Score   Error   Units
+UUIDBench.toString   20000  thrpt   15  113.508 ? 1.372  ops/us +21.63%


## Apple MackBook M1 Pro

-# origin  bd99525633e4d3d3f180a6678eedb8780dbb6139
-Benchmark           (size)   Mode  Cnt    Score   Error   Units
-UUIDBench.toString   20000  thrpt   15  106.199 ? 0.568  ops/us

+# current 878a3cb7c73b777eb5385b3e4d158c998cd9be46
+Benchmark           (size)   Mode  Cnt    Score   Error   Units
+UUIDBench.toString   20000  thrpt   15  113.911 ? 0.628  ops/us +7.34%

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2892476915

From swen at openjdk.org  Mon May 19 23:34:34 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 19 May 2025 23:34:34 GMT
Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v5]
In-Reply-To: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
References: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
Message-ID: <xFMej1TEYwaSULo9tfBFW9fRqxQ4HZV4zW9Rty7FTBA=.8d91d05a-6444-40fa-a782-4abecf200b6d@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:

  hex8 comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22928/files
  - new: https://git.openjdk.org/jdk/pull/22928/files/878a3cb7..4e62d43c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=03-04

  Stats: 44 lines in 1 file changed: 38 ins; 0 del; 6 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 naoto at openjdk.org  Mon May 19 23:43:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 19 May 2025 23:43:51 GMT
Subject: RFR: 8357275: Locale.Builder.setLanguageTag should explicitly
 state extlangs are allowed
In-Reply-To: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
Message-ID: <QUtJwLbVsoGtCyv848P1vvnFfEgiFmZ34masOOPmJyM=.afc55604-b3ac-4cd1-b2b6-3ff2158d2992@github.com>

On Mon, 19 May 2025 20:56:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.

src/java.base/share/classes/java/util/Locale.java line 2792:

> 2790:          * tag). {@code languageTag} may contain up to three extlang subtags.
> 2791:          + For such occurrences, the first extlang subtag is used as the language,
> 2792:          * and the primary language subtag and other extlang subtags are ignored.

Should we throw an exeption here? I had an impression that the new description actually contradicts to the previous sentense, which asserts exception on ill-formed tag.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2096613695

From swen at openjdk.org  Mon May 19 23:53:07 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 19 May 2025 23:53:07 GMT
Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v6]
In-Reply-To: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
References: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
Message-ID: <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@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:

  hex8 comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22928/files
  - new: https://git.openjdk.org/jdk/pull/22928/files/4e62d43c..3b94f81f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=04-05

  Stats: 69 lines in 1 file changed: 11 ins; 5 del; 53 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 jlu at openjdk.org  Mon May 19 23:55:51 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 19 May 2025 23:55:51 GMT
Subject: RFR: 8357275: Locale.Builder.setLanguageTag should explicitly
 state extlangs are allowed
In-Reply-To: <QUtJwLbVsoGtCyv848P1vvnFfEgiFmZ34masOOPmJyM=.afc55604-b3ac-4cd1-b2b6-3ff2158d2992@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
 <QUtJwLbVsoGtCyv848P1vvnFfEgiFmZ34masOOPmJyM=.afc55604-b3ac-4cd1-b2b6-3ff2158d2992@github.com>
Message-ID: <yO0NeGsCmo4vIPU3ioLORjTJ3IgK9cjutuR_H2CII7M=.2674da7f-406c-453f-bb1a-e333bebf1b5d@github.com>

On Mon, 19 May 2025 23:41:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.
>
> src/java.base/share/classes/java/util/Locale.java line 2792:
> 
>> 2790:          * tag). {@code languageTag} may contain up to three extlang subtags.
>> 2791:          + For such occurrences, the first extlang subtag is used as the language,
>> 2792:          * and the primary language subtag and other extlang subtags are ignored.
> 
> Should we throw an exeption here? I had an impression that the new description actually contradicts to the previous sentense, which asserts exception on ill-formed tag.

An exception is thrown when more than three extlang subtags are provided (ill-formed). The new wording is when an allowed amount of extlang subtags are provided (not ill-formed). For example,

`new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-czh-CN").build()` // throws
`new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-czh-CN").build()` // ==> yue_CN

i.e. if one to three extlang subtags occur, discard extras. If more than 3 occur, then it is ill-formed, and the method is already specified to throw on ill-formed tags.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2096619811

From naoto at openjdk.org  Tue May 20 00:41:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 May 2025 00:41:51 GMT
Subject: RFR: 8357275: Locale.Builder.setLanguageTag should explicitly
 state extlangs are allowed
In-Reply-To: <yO0NeGsCmo4vIPU3ioLORjTJ3IgK9cjutuR_H2CII7M=.2674da7f-406c-453f-bb1a-e333bebf1b5d@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
 <QUtJwLbVsoGtCyv848P1vvnFfEgiFmZ34masOOPmJyM=.afc55604-b3ac-4cd1-b2b6-3ff2158d2992@github.com>
 <yO0NeGsCmo4vIPU3ioLORjTJ3IgK9cjutuR_H2CII7M=.2674da7f-406c-453f-bb1a-e333bebf1b5d@github.com>
Message-ID: <JAXXxlfm30nkxcWaP69ToMTy-u-zT2B0UU7XsxFMZCw=.41f9f8f1-e728-4755-9b76-1a1c18f07641@github.com>

On Mon, 19 May 2025 23:50:59 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Locale.java line 2792:
>> 
>>> 2790:          * tag). {@code languageTag} may contain up to three extlang subtags.
>>> 2791:          + For such occurrences, the first extlang subtag is used as the language,
>>> 2792:          * and the primary language subtag and other extlang subtags are ignored.
>> 
>> Should we throw an exeption here? I had an impression that the new description actually contradicts to the previous sentense, which asserts exception on ill-formed tag.
>
> An exception is thrown when more than three extlang subtags are provided (ill-formed). The new wording is when an allowed amount of extlang subtags are provided (not ill-formed). For example,
> 
> `new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-czh-CN").build()` // throws
> `new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-CN").build()` // ==> yue_CN
> 
> i.e. if one to three extlang subtags occur, discard extras. If more than 3 occur, then it is ill-formed, and the method is already specified to throw on ill-formed tags. (Edit: Forgot to adjust the example)

OK. I would add these examples here too, which may be more helpful.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2096650651

From henryjen at openjdk.org  Tue May 20 00:51:51 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 20 May 2025 00:51:51 GMT
Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder
 on static-jdk [v2]
In-Reply-To: <akvr3HuFyZubFssoMOl6_c7wwbKgTxXAEUJfgvnnkGs=.ba807f25-823c-48f3-8831-71067ac1cc31@github.com>
References: <E986980rvWra05uWXYMdT8N4i_0RGxNC_KubDF6tXAw=.a6ab5563-b75c-45b2-b367-31d001cc294e@github.com>
 <akvr3HuFyZubFssoMOl6_c7wwbKgTxXAEUJfgvnnkGs=.ba807f25-823c-48f3-8831-71067ac1cc31@github.com>
Message-ID: <Om91kw_Tj8JHpS_uqQR7mB9R_lGZ462Z-Bf4lLIV-O8=.71401529-53d9-4dd3-84bb-df72284e29ea@github.com>

On Wed, 14 May 2025 15:44:08 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this PR for skipping jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the context from https://bugs.openjdk.org/browse/JDK-8356904 description:
>> 
>> jdk/test/lib/process/TestNativeProcessBuilder.java (in lib-test/tier1) uses a native test launcher executable, exejvm-test-launcher, which has explicitly dependency on libjvm.so. The test fails on static-jdk. This is the same issue as [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276). With [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276), we decided to skip the affected hotspot tier1 tests on static-jdk. We should skip jdk/test/lib/process/TestNativeProcessBuilder.java on static-jdk as well. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year in test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java.

Marked as reviewed by henryjen (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25220#pullrequestreview-2852249506

From henryjen at openjdk.org  Tue May 20 00:51:52 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 20 May 2025 00:51:52 GMT
Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder
 on static-jdk [v2]
In-Reply-To: <40zDBK-DvbpQPX1ColLdmfgGA1yTeUtidbOQV22QZCg=.93953b52-747c-4f8a-9ef4-5ad45d30f6d5@github.com>
References: <E986980rvWra05uWXYMdT8N4i_0RGxNC_KubDF6tXAw=.a6ab5563-b75c-45b2-b367-31d001cc294e@github.com>
 <3RWZl77waTqYm1lm8ImxBegeni5IcB3jD0cUUiJvWJw=.11c71454-89b8-46ec-8aee-e484de538480@github.com>
 <ayYWJF-nXUjwIXdCqQnKuPC4DDaRRiYp6ud9PpXoxeY=.a21e6eee-bf39-4670-b10d-ca4a5fe9b320@github.com>
 <40zDBK-DvbpQPX1ColLdmfgGA1yTeUtidbOQV22QZCg=.93953b52-747c-4f8a-9ef4-5ad45d30f6d5@github.com>
Message-ID: <vm6J5LNiOnOrsIe7FqE6yAJeof-Emsa28rG2RuALkEU=.f4e435e2-6435-49f5-9c5d-865480fa8100@github.com>

On Mon, 19 May 2025 19:56:52 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> @sendaoYan Please let me know if you have any additional review comments, thanks.
>> 
>> Also looking for a 'R'eviewer for reviewing. Thanks!
>
> A friendly ping

LGTM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25220#discussion_r2096657809

From swen at openjdk.org  Tue May 20 00:52:53 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 20 May 2025 00:52:53 GMT
Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v3]
In-Reply-To: <WqN3u6iDJoH7iie4yMvWpD9HhTROCj-Cwr5yOaEtv-I=.3cd118f7-e277-4a2f-ad5e-fad3e842fae4@github.com>
References: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
 <MgRSlPSknv15Raob7wJjgIROw0Vf8jo43DI6IPnirGM=.8e0d26de-a7f2-47d8-8aeb-bcc86f77847a@github.com>
 <WqN3u6iDJoH7iie4yMvWpD9HhTROCj-Cwr5yOaEtv-I=.3cd118f7-e277-4a2f-ad5e-fad3e842fae4@github.com>
Message-ID: <DrFWfec9-aQhSXWGYLNqaUXvDkIz1sKZ95IZoinbd_c=.3ea5807c-1fd5-4bcd-afad-05e46f0f7a91@github.com>

On Mon, 19 May 2025 18:30:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simplify code
>
> src/java.base/share/classes/java/util/UUID.java line 491:
> 
>> 489:      * hexadecimal representation, concatenate these hexadecimal strings into one continuous string, and then interpret
>> 490:      * this string as a hexadecimal number to form and return a long value.
>> 491:      */
> 
> Is there a reference describing this technique?  Such as the Hacker's Delight citation used in java.lang.Long?
> If not a longer descriptive comment would be good for maintainability.

This algorithm was researched and implemented by me, and I have added detailed description and comments

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22928#discussion_r2096658412

From almatvee at openjdk.org  Tue May 20 00:53:29 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 20 May 2025 00:53:29 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles
Message-ID: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>

Fixed jpackage to produce valid Java runtimes based on description below:

Definitions:

- JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
- Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
- JDK image defined as content of "Contents/Home".
- Signed JDK image does not exist, since it cannot be signed as bundle.

jpackage output based on input:

1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
- jpackage will copy all files as is from provided path and run ad-hoc codesign.

2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
- jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
 
3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
- jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.

4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
- jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.

5. "--runtime-image" points to JDK image and --mac-sign is not provided:
 - jpackage will check for libjli.dylib presence in "lib" folder.
 - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
- Ad-hoc signing will done.

6. "--runtime-image" points to JDK image and --mac-sign is provided:
- 2 first steps from 5 and certificate signing will be done.

-------------

Commit messages:
 - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles

Changes: https://git.openjdk.org/jdk/pull/25314/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25314&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351073
  Stats: 689 lines in 14 files changed: 608 ins; 50 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/25314.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25314/head:pull/25314

PR: https://git.openjdk.org/jdk/pull/25314

From swen at openjdk.org  Tue May 20 01:01:30 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 20 May 2025 01:01:30 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller methods
Message-ID: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>

Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline.

The following is the output information of PrintInlining:

                @ 9   java.lang.String::<init> (12 bytes)   inline (hot)
!m                 @ 1   java.nio.charset.Charset::defaultCharset (52 bytes)   inline (hot)
!                  @ 8   java.lang.String::<init> (852 bytes)   failed to inline: hot method too big


In Java code, the big method that cannot be inlined is the following constructor


String(Charset charset, byte[] bytes, int offset, int length) {}

The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2.

-------------

Commit messages:
 - bug fix
 - code style, from @liach
 - remove record
 - make create method codeSize < 325
 - split String constructor

Changes: https://git.openjdk.org/jdk/pull/25290/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357289
  Stats: 206 lines in 1 file changed: 62 ins; 74 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/25290.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25290/head:pull/25290

PR: https://git.openjdk.org/jdk/pull/25290

From swen at openjdk.org  Tue May 20 01:01:31 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 20 May 2025 01:01:31 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods
In-Reply-To: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
Message-ID: <qbjvo021ZFm_v-utJk0UwEXEh--cwqxxFT0V0bn74Ac=.ed4cacfa-d3e9-42b2-b515-7544cf619df8@github.com>

On Sun, 18 May 2025 12:48:07 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline.
> 
> The following is the output information of PrintInlining:
> 
>                 @ 9   java.lang.String::<init> (12 bytes)   inline (hot)
> !m                 @ 1   java.nio.charset.Charset::defaultCharset (52 bytes)   inline (hot)
> !                  @ 8   java.lang.String::<init> (852 bytes)   failed to inline: hot method too big
> 
> 
> In Java code, the big method that cannot be inlined is the following constructor
> 
> 
> String(Charset charset, byte[] bytes, int offset, int length) {}
> 
> The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2.

Below are the performance numbers on the MacBook M1 Max. The numbers show that after the small split method, the performance has been significantly improved.


-# master 6c42856b8d5
-Benchmark                                                  (size)  Mode  Cnt   Score   Error  Units
-StringConstructor.newStringFromBytes                            7  avgt   15   6.628 ? 0.048  ns/op
-StringConstructor.newStringFromBytes                           64  avgt   15  10.182 ? 0.079  ns/op
-StringConstructor.newStringFromBytesRanged                      7  avgt   15  10.187 ? 0.871  ns/op
-StringConstructor.newStringFromBytesRanged                     64  avgt   15  11.304 ? 0.111  ns/op
-StringConstructor.newStringFromBytesRangedWithCharsetUTF8       7  avgt   15  10.869 ? 0.753  ns/op
-StringConstructor.newStringFromBytesRangedWithCharsetUTF8      64  avgt   15  11.348 ? 0.134  ns/op
-StringConstructor.newStringFromBytesWithCharsetNameUTF8         7  avgt   15   9.483 ? 0.119  ns/op
-StringConstructor.newStringFromBytesWithCharsetNameUTF8        64  avgt   15  12.755 ? 0.089  ns/op
-StringConstructor.newStringFromBytesWithCharsetUTF8             7  avgt   15   6.721 ? 0.107  ns/op
-StringConstructor.newStringFromBytesWithCharsetUTF8            64  avgt   15  10.208 ? 0.065  ns/op


+# current 4ebac0ddc64
+Benchmark                                                  (size)  Mode  Cnt   Score   Error  Units
+StringConstructor.newStringFromBytes                            7  avgt   15   4.715 ? 0.029  ns/op +40.57%
+StringConstructor.newStringFromBytes                           64  avgt   15   8.019 ? 0.152  ns/op +26.97%
+StringConstructor.newStringFromBytesRanged                      7  avgt   15   5.563 ? 0.059  ns/op +83.12%
+StringConstructor.newStringFromBytesRanged                     64  avgt   15   9.549 ? 0.217  ns/op +18.37%
+StringConstructor.newStringFromBytesRangedWithCharsetUTF8       7  avgt   15   5.579 ? 0.076  ns/op +94.81%
+StringConstructor.newStringFromBytesRangedWithCharsetUTF8      64  avgt   15   9.407 ? 0.047  ns/op +20.63%
+StringConstructor.newStringFromBytesWithCharsetNameUTF8         7  avgt   15   8.168 ? 0.084  ns/op +16.09%
+StringConstructor.newStringFromBytesWithCharsetNameUTF8        64  avgt   15  12.574 ? 0.268  ns/op + 1.43%
+StringConstructor.newStringFromBytesWithCharsetUTF8             7  avgt   15   4.722 ? 0.043  ns/op +42.33%
+StringConstructor.newStringFromBytesWithCharsetUTF8            64  avgt   15   8.077 ? 0.144  ns/op +26.38%

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25290#issuecomment-2889044580

From jiangli at openjdk.org  Tue May 20 01:08:51 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 20 May 2025 01:08:51 GMT
Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder
 on static-jdk [v2]
In-Reply-To: <Om91kw_Tj8JHpS_uqQR7mB9R_lGZ462Z-Bf4lLIV-O8=.71401529-53d9-4dd3-84bb-df72284e29ea@github.com>
References: <E986980rvWra05uWXYMdT8N4i_0RGxNC_KubDF6tXAw=.a6ab5563-b75c-45b2-b367-31d001cc294e@github.com>
 <akvr3HuFyZubFssoMOl6_c7wwbKgTxXAEUJfgvnnkGs=.ba807f25-823c-48f3-8831-71067ac1cc31@github.com>
 <Om91kw_Tj8JHpS_uqQR7mB9R_lGZ462Z-Bf4lLIV-O8=.71401529-53d9-4dd3-84bb-df72284e29ea@github.com>
Message-ID: <WDtc3YUrNym2nzXeIdlwAabA5bZsfrePYsrm9TpXNs0=.595d1403-caa9-44fc-ab47-3f81bf952ad1@github.com>

On Tue, 20 May 2025 00:49:28 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year in test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java.
>
> Marked as reviewed by henryjen (Committer).

@slowhog Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25220#issuecomment-2892617923

From liach at openjdk.org  Tue May 20 01:12:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 May 2025 01:12:52 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods
In-Reply-To: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
Message-ID: <xfWn9pLVoEV313a_uOSw_Q257l37DjWUQ6YSg8fkgu0=.5092b59e-a6b3-45e5-a827-b7775e5db4a2@github.com>

On Sun, 18 May 2025 12:48:07 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline.
> 
> The following is the output information of PrintInlining:
> 
>                 @ 9   java.lang.String::<init> (12 bytes)   inline (hot)
> !m                 @ 1   java.nio.charset.Charset::defaultCharset (52 bytes)   inline (hot)
> !                  @ 8   java.lang.String::<init> (852 bytes)   failed to inline: hot method too big
> 
> 
> In Java code, the big method that cannot be inlined is the following constructor
> 
> 
> String(Charset charset, byte[] bytes, int offset, int length) {}
> 
> The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2.

src/java.base/share/classes/java/lang/String.java line 690:

> 688:                 .onUnmappableCharacter(CodingErrorAction.REPLACE);
> 689:         char[] ca = new char[en];
> 690:         int caLen = decodeWithDecoder(cd, ca, bytes, offset, length);

Let's restore the CharacterCodingException for now. I don't think we should change the exceptions as part of the break down.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2094621982

From swen at openjdk.org  Tue May 20 01:23:51 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 20 May 2025 01:23:51 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods
In-Reply-To: <xfWn9pLVoEV313a_uOSw_Q257l37DjWUQ6YSg8fkgu0=.5092b59e-a6b3-45e5-a827-b7775e5db4a2@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
 <xfWn9pLVoEV313a_uOSw_Q257l37DjWUQ6YSg8fkgu0=.5092b59e-a6b3-45e5-a827-b7775e5db4a2@github.com>
Message-ID: <BgP-oLOwkel3XY7ngnKmpeao4bRViN6tFWzPVt4Qwew=.a4986010-8578-491f-9a8d-d3bdb70a9ee2@github.com>

On Sun, 18 May 2025 20:44:12 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline.
>> 
>> The following is the output information of PrintInlining:
>> 
>>                 @ 9   java.lang.String::<init> (12 bytes)   inline (hot)
>> !m                 @ 1   java.nio.charset.Charset::defaultCharset (52 bytes)   inline (hot)
>> !                  @ 8   java.lang.String::<init> (852 bytes)   failed to inline: hot method too big
>> 
>> 
>> In Java code, the big method that cannot be inlined is the following constructor
>> 
>> 
>> String(Charset charset, byte[] bytes, int offset, int length) {}
>> 
>> The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2.
>
> src/java.base/share/classes/java/lang/String.java line 690:
> 
>> 688:                 .onUnmappableCharacter(CodingErrorAction.REPLACE);
>> 689:         char[] ca = new char[en];
>> 690:         int caLen = decodeWithDecoder(cd, ca, bytes, offset, length);
> 
> Let's restore the CharacterCodingException for now. I don't think we should change the exceptions as part of the break down.

Restoring the exception handling here will cause the codeSize of the create method to be greater than 325. This exception will not occur here, so the exception handling is moved to decodeWithDecoder.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2096683192

From liach at openjdk.org  Tue May 20 01:39:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 May 2025 01:39:00 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods
In-Reply-To: <BgP-oLOwkel3XY7ngnKmpeao4bRViN6tFWzPVt4Qwew=.a4986010-8578-491f-9a8d-d3bdb70a9ee2@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
 <xfWn9pLVoEV313a_uOSw_Q257l37DjWUQ6YSg8fkgu0=.5092b59e-a6b3-45e5-a827-b7775e5db4a2@github.com>
 <BgP-oLOwkel3XY7ngnKmpeao4bRViN6tFWzPVt4Qwew=.a4986010-8578-491f-9a8d-d3bdb70a9ee2@github.com>
Message-ID: <AFIi-AwS1Z8dGVF2t4IOqCQ2cTqHBd2gBVST0sQsODM=.6a2f90ee-7eb0-4fcf-9128-0e317ae1d682@github.com>

On Tue, 20 May 2025 01:21:34 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 690:
>> 
>>> 688:                 .onUnmappableCharacter(CodingErrorAction.REPLACE);
>>> 689:         char[] ca = new char[en];
>>> 690:         int caLen = decodeWithDecoder(cd, ca, bytes, offset, length);
>> 
>> Let's restore the CharacterCodingException for now. I don't think we should change the exceptions as part of the break down.
>
> Restoring the exception handling here will cause the codeSize of the create method to be greater than 325. This exception will not occur here, so the exception handling is moved to decodeWithDecoder.

I think in this case, a better approach might be declaring `char[] ca` and `int cLen`/`caLen` -> the array decoder and the regular decoder can initialize these two variables, and share the final code that compress the strings.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2096694772

From iklam at openjdk.org  Tue May 20 02:02:44 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 20 May 2025 02:02:44 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v10]
In-Reply-To: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
Message-ID: <sc31SIpcmKIBImDWljxQv_pEsfMnkT_azDCib4QOvyQ=.54471e8c-efb6-4f40-92fc-d0c02b688506@github.com>

> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
> 
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
> - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
> 
> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
> 
> Examples:
> 
> 
> # Create an AOT cache with a single command:
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> Hello World
> Temporary AOTConfiguration recorded: foo.aot.config
> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
> [...]
> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
> AOTCache creation is complete: foo.aot 10240000 bytes
> 
> # Create logging file for the AOT cache assembly phase
> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> 
> 
> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - @erikj79 comments
 - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
 - @vnkozlov comments
 - added info about JTREG/AOT_JDK testing
 - fixed whitespace
 - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
 - java.md updates from @rose00
 - Resolved differences with CSR JDK-8356010
 - Added param to makefile function SetupAOT for choosing onestep vs twostep
 - Allow one-step training even when -XX:AOTMode=auto is specified
 - ... and 14 more: https://git.openjdk.org/jdk/compare/890456f0...0956fcad

-------------

Changes: https://git.openjdk.org/jdk/pull/24942/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=09
  Stats: 2088 lines in 24 files changed: 1564 ins; 459 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/24942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942

PR: https://git.openjdk.org/jdk/pull/24942

From swen at openjdk.org  Tue May 20 02:04:24 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 20 May 2025 02:04:24 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods [v2]
In-Reply-To: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
Message-ID: <th89Kw496H-WPisChjm1eWvVF0TN2ErA4Ng4y0v3Z0A=.9b71582b-fef3-4b04-865d-d22182a1f52f@github.com>

> Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline.
> 
> The following is the output information of PrintInlining:
> 
>                 @ 9   java.lang.String::<init> (12 bytes)   inline (hot)
> !m                 @ 1   java.nio.charset.Charset::defaultCharset (52 bytes)   inline (hot)
> !                  @ 8   java.lang.String::<init> (852 bytes)   failed to inline: hot method too big
> 
> 
> In Java code, the big method that cannot be inlined is the following constructor
> 
> 
> String(Charset charset, byte[] bytes, int offset, int length) {}
> 
> The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  create method share variant val & coder

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25290/files
  - new: https://git.openjdk.org/jdk/pull/25290/files/f7abb552..b6f0a2db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=00-01

  Stats: 67 lines in 1 file changed: 31 ins; 16 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/25290.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25290/head:pull/25290

PR: https://git.openjdk.org/jdk/pull/25290

From swen at openjdk.org  Tue May 20 02:11:34 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 20 May 2025 02:11:34 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods [v3]
In-Reply-To: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
Message-ID: <SMAz5R1EFhePJhslGUGTDYdAPuPJGbfmn6t14cDpiXc=.950cf100-d65b-4fa4-8ae7-fe28d990b4f9@github.com>

> Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline.
> 
> The following is the output information of PrintInlining:
> 
>                 @ 9   java.lang.String::<init> (12 bytes)   inline (hot)
> !m                 @ 1   java.nio.charset.Charset::defaultCharset (52 bytes)   inline (hot)
> !                  @ 8   java.lang.String::<init> (852 bytes)   failed to inline: hot method too big
> 
> 
> In Java code, the big method that cannot be inlined is the following constructor
> 
> 
> String(Charset charset, byte[] bytes, int offset, int length) {}
> 
> The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  create method share variant val & coder

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25290/files
  - new: https://git.openjdk.org/jdk/pull/25290/files/b6f0a2db..fab7728b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=01-02

  Stats: 38 lines in 1 file changed: 14 ins; 11 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/25290.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25290/head:pull/25290

PR: https://git.openjdk.org/jdk/pull/25290

From xgong at openjdk.org  Tue May 20 02:24:51 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 20 May 2025 02:24:51 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API
In-Reply-To: <z9_9NOdQqxNvv_l0VxjGD4Xc-baboKUmbY5NGbXdAHw=.f8486a40-5d28-4f9c-913e-8155baadbec2@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <z9_9NOdQqxNvv_l0VxjGD4Xc-baboKUmbY5NGbXdAHw=.f8486a40-5d28-4f9c-913e-8155baadbec2@github.com>
Message-ID: <t1DdwodJEC_7OWaci1nCnC6LZVV62x5flDo7rjzYcoM=.91f68c49-f044-43e3-8bba-67a2bd5a5800@github.com>

On Mon, 19 May 2025 03:10:46 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]).
>> 
>> Two key areas require improvement:
>> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance.
>> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types  increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance.
>> 
>> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures.
>> 
>> Main changes:
>> 1. Java-side API refactoring:
>>    - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on
>>      architectures like AArch64.
>> 2. C2 compiler IR refactoring:
>>    - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types.
>> 3. Backend changes:
>>    - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level.
>> 
>> Performance:
>> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below:
>> 
>> Benchmark                                                 Mode   Cnt Unit    SIZE    Before      After    Gain
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  64    53682.012   52650.325  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  256   14484.252   14255.156  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  1024   3664.900    3595.615  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  4096    908.31...
>
> Ping again~  could any one please take a look at this PR? Thanks a lot!

> Hi @XiaohongGong , Very nice work!, Looks good to me, will do some testing and get back.
> 
> Do you have any idea about following regression?
> 
> ```
> GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  64    55844.814   48311.847  0.86
> GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  256   15139.459   13009.848  0.85
> GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  1024   3861.834    3284.944  0.85
> GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  4096    938.665     817.673  0.87
> ```
> 
> Best Regards

Yes, I also observed such regression. After analyzing, I found it was caused by the java side changes, which influences the range check elimination inside `IntVector.fromArray()` and `ByteVector.intoArray()` in the benchmark. The root cause is the counted loop in following benchmark case is not recognized by compiler as expected:

public void microByteGather256() {
        for (int i = 0; i < SIZE; i += B256.length()) {
            ByteVector.fromArray(B256, barr, 0, index, i)
                            .intoArray(bres, i);
        }
 }
``` 
The loop iv phi node is not recognized successfully when C2 recognize the counted loop pattern, because it was casted twice with `CastII` in this case. The ideal graph looks like:

                           Loop
                               \
                                    \        / -------------------------
                                       \  /                                        |
                                       Phi                                        |
                                         |                                          | 
                                      CastII                                     |
                                          |                                         |
                                      CastII                                     |
                                          |                                         |
                                             \       ConI                       |
                                                 \     |                            |
                                                AddVI                          |
                                                      |--------------------|                           

Relative code is https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L1667. 

Before the change, the graph should be:

                           Loop
                               \
                                    \        / -------------------------
                                       \  /                                        |
                                       Phi                                        |
                                         |                                          | 
                                      CastII                                     |
                                          |                                         |                                       |
                                             \       ConI                       |
                                                 \     |                            |
                                                AddVI                          |
                                                      |--------------------|    
``` 
The difference comes from the index generation in `ByteVector.fromArray()` (I mean calling of `IntVector.fromArray()` in java). Before, the `i` in above loop is not directly used by `IntVector.fromArray()`. Instead, it was used by another loop phi node. Hence, there is no additional `CastII`. But after my change, the loop in the java implementation of `ByteVector.fromArray()` is removed, and `i` is directly used by `IntVector.fromArray()` . It will be used by boundary check before loading the indexes. Hence another `CastII` is generated.

When recognizing the loop iv phi node, it will check whether the `Phi` is used by a `CastII` first. And get the input of the `CastII` if then. But this check only happens once. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L1659

  if (xphi->Opcode() == Op_Cast(iv_bt)) {
    xphi = xphi->in(1);
  }


Once the `PhiNode` is casted more than one times, the pattern is not recognized. I think we should refine the logic of recognizing the counted loop, by changing above `if` to `while` to make the iv phi node is recognized successfully. Potential change should be:

  while (xphi->Opcode() == Op_Cast(iv_bt)) {
    xphi = xphi->in(1);
  }


I'v tested this change, and found the benchmarks with regression can be improved as before. Consider I'm not familiar with C2's loop transform code, I prefer to do more investigation for this issue, and may fix it with a followed-up patch. Any suggestions?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2892720654

From d.ukhlov at gmail.com  Tue May 20 02:42:19 2025
From: d.ukhlov at gmail.com (Dmytro Ukhlov)
Date: Tue, 20 May 2025 05:42:19 +0300
Subject: Reducing Classloader's parallelLockMap memory consumption proposal
Message-ID: <CAGKffi85riNTzUT67O2jLRZgoHiX5t9=W5yRXXSoyDd-Rs6QMA@mail.gmail.com>

Hello!

I created PR is scope of jenkins-core project:
https://github.com/jenkinsci/jenkins/pull/10659
Jira ticket: https://issues.jenkins.io/browse/JENKINS-75675

In this PR i propped to override
protected Object getClassLoadingLock(String className)
method and use weak references for lock objects

Jenkins is a plugable platform, each plugin has its own class loader
and its parallelLockMap may consume 10mb of RAM. As a result it might
have 2gb overhead if ~200 plugins installed.

Jenkins maintainers ask me to consider making this improvement in base

From iklam at openjdk.org  Tue May 20 03:43:39 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 20 May 2025 03:43:39 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v11]
In-Reply-To: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
Message-ID: <cWzCTmCSk7hJDxFqRLf_kuU-TOmWrGdSHQdoxEVnj0Y=.7a4b8e46-4dca-4e92-bbe0-dff36f382402@github.com>

> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
> 
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
> - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
> 
> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
> 
> Examples:
> 
> 
> # Create an AOT cache with a single command:
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> Hello World
> Temporary AOTConfiguration recorded: foo.aot.config
> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
> [...]
> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
> AOTCache creation is complete: foo.aot 10240000 bytes
> 
> # Create logging file for the AOT cache assembly phase
> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> 
> 
> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed merge

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24942/files
  - new: https://git.openjdk.org/jdk/pull/24942/files/0956fcad..502d1c07

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942

PR: https://git.openjdk.org/jdk/pull/24942

From epeter at openjdk.org  Tue May 20 05:37:51 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 20 May 2025 05:37:51 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API
In-Reply-To: <t1DdwodJEC_7OWaci1nCnC6LZVV62x5flDo7rjzYcoM=.91f68c49-f044-43e3-8bba-67a2bd5a5800@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <z9_9NOdQqxNvv_l0VxjGD4Xc-baboKUmbY5NGbXdAHw=.f8486a40-5d28-4f9c-913e-8155baadbec2@github.com>
 <t1DdwodJEC_7OWaci1nCnC6LZVV62x5flDo7rjzYcoM=.91f68c49-f044-43e3-8bba-67a2bd5a5800@github.com>
Message-ID: <ymD8K31VZK3Ux-lG6YDH2MG-bjsuc3Qwgbok_6TsIYE=.6b3cc5bb-bd50-433a-a9ca-dcc3b1e67279@github.com>

On Tue, 20 May 2025 02:22:13 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Ping again~  could any one please take a look at this PR? Thanks a lot!
>
>> Hi @XiaohongGong , Very nice work!, Looks good to me, will do some testing and get back.
>> 
>> Do you have any idea about following regression?
>> 
>> ```
>> GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  64    55844.814   48311.847  0.86
>> GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  256   15139.459   13009.848  0.85
>> GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  1024   3861.834    3284.944  0.85
>> GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  4096    938.665     817.673  0.87
>> ```
>> 
>> Best Regards
> 
> Yes, I also observed such regression. After analyzing, I found it was caused by the java side changes, which influences the range check elimination inside `IntVector.fromArray()` and `ByteVector.intoArray()` in the benchmark. The root cause is the counted loop in following benchmark case is not recognized by compiler as expected:
> 
> public void microByteGather256() {
>         for (int i = 0; i < SIZE; i += B256.length()) {
>             ByteVector.fromArray(B256, barr, 0, index, i)
>                             .intoArray(bres, i);
>         }
>  }
> ``` 
> The loop iv phi node is not recognized successfully when C2 recognize the counted loop pattern, because it was casted twice with `CastII` in this case. The ideal graph looks like:
> 
>                            Loop
>                                \
>                                     \        / -----------------------------
>                                        \  /                                 |
>                                        Phi                                  |
>                                          |                                  | 
>                                       CastII                                |
>                                           |                                 |
>                                       CastII                                |
>                                           |                                 |
>                                              \   ConI                       |
>                                                 \  |                        |
>                                                 AddVI                       |
>                                                   |-------------------------|                           
> 
> Relative code is https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L1667. 
> 
> Befor...

@XiaohongGong Thanks for splitting this one out, and for investigating the regressions here.

Putting the permalink here, fixed to the current change (the link you pasted will always refer to the newest, which may later on point to the wrong line when lines above are inserted / deleted):
https://github.com/openjdk/jdk/blob/7077535c0b0a6ea0a2a167f9135b1504a3d71fb3/src/hotspot/share/opto/loopnode.cpp#L1659-L1661

I wonder if we should just use `Node::uncast` there? But I'm quite unsure about that.

> Yes, I also observed such regression.
It would be nice if you proactively mentioned regressions, so it does not have to be pointed out by reviewers.

For me, it could be ok to fix it in a follow-up patch. I think we are too close to RDP1 for JDK25 now anyway, and so we could push this patch here into JDK26, and then we have enough time in JDK26 to investigate the regression. Even better would be if we could do the other patch first, so we never even encounter a regression.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2893017948

From xgong at openjdk.org  Tue May 20 05:42:51 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 20 May 2025 05:42:51 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API
In-Reply-To: <t1DdwodJEC_7OWaci1nCnC6LZVV62x5flDo7rjzYcoM=.91f68c49-f044-43e3-8bba-67a2bd5a5800@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <z9_9NOdQqxNvv_l0VxjGD4Xc-baboKUmbY5NGbXdAHw=.f8486a40-5d28-4f9c-913e-8155baadbec2@github.com>
 <t1DdwodJEC_7OWaci1nCnC6LZVV62x5flDo7rjzYcoM=.91f68c49-f044-43e3-8bba-67a2bd5a5800@github.com>
Message-ID: <yYd0dXTCX-TXZpluDy9iktVQWeLifmY5GG_GNHkH9lU=.c414c05b-af7e-4b67-8f0f-9ba39696c82a@github.com>

On Tue, 20 May 2025 02:22:13 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Ping again~  could any one please take a look at this PR? Thanks a lot!
>
>> Hi @XiaohongGong , Very nice work!, Looks good to me, will do some testing and get back.
>> 
>> Do you have any idea about following regression?
>> 
>> ```
>> GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  64    55844.814   48311.847  0.86
>> GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  256   15139.459   13009.848  0.85
>> GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  1024   3861.834    3284.944  0.85
>> GatherOperationsBenchmark.microByteGather256              thrpt  30  ops/ms  4096    938.665     817.673  0.87
>> ```
>> 
>> Best Regards
> 
> Yes, I also observed such regression. After analyzing, I found it was caused by the java side changes, which influences the range check elimination inside `IntVector.fromArray()` and `ByteVector.intoArray()` in the benchmark. The root cause is the counted loop in following benchmark case is not recognized by compiler as expected:
> 
> public void microByteGather256() {
>         for (int i = 0; i < SIZE; i += B256.length()) {
>             ByteVector.fromArray(B256, barr, 0, index, i)
>                             .intoArray(bres, i);
>         }
>  }
> ``` 
> The loop iv phi node is not recognized successfully when C2 recognize the counted loop pattern, because it was casted twice with `CastII` in this case. The ideal graph looks like:
> 
>                            Loop
>                                \
>                                     \        / -----------------------------
>                                        \  /                                 |
>                                        Phi                                  |
>                                          |                                  | 
>                                       CastII                                |
>                                           |                                 |
>                                       CastII                                |
>                                           |                                 |
>                                              \   ConI                       |
>                                                 \  |                        |
>                                                 AddVI                       |
>                                                   |-------------------------|                           
> 
> Relative code is https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L1667. 
> 
> Befor...

> @XiaohongGong Thanks for splitting this one out, and for investigating the regressions here.
> 
> Putting the permalink here, fixed to the current change (the link you pasted will always refer to the newest, which may later on point to the wrong line when lines above are inserted / deleted):
> 
> https://github.com/openjdk/jdk/blob/7077535c0b0a6ea0a2a167f9135b1504a3d71fb3/src/hotspot/share/opto/loopnode.cpp#L1659-L1661
> 
> I wonder if we should just use `Node::uncast` there? But I'm quite unsure about that.

Sounds good to me. I will have a deep investigation for it. Thanks!



> > Yes, I also observed such regression.
> > It would be nice if you proactively mentioned regressions, so it does not have to be pointed out by reviewers.
> 
> For me, it could be ok to fix it in a follow-up patch. I think we are too close to RDP1 for JDK25 now anyway, and so we could push this patch here into JDK26, and then we have enough time in JDK26 to investigate the regression. Even better would be if we could do the other patch first, so we never even encounter a regression.

Sounds good to me. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2893026228

From jpai at openjdk.org  Tue May 20 06:10:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 May 2025 06:10:55 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6]
In-Reply-To: <Y-iTd9LtJ2nW9QZkNz1_xQ1kXToP8DcovFP-LAxrqXk=.8e9f7b28-fa77-4d27-a2c7-36a429a2f3ae@github.com>
References: <dm6o-XRNWecHjZeenCSRhAOEYI7L_mOOqfguvjlk_Bc=.cdb4e2e5-3500-48d5-8c05-749ff01f06f1@github.com>
 <Y-iTd9LtJ2nW9QZkNz1_xQ1kXToP8DcovFP-LAxrqXk=.8e9f7b28-fa77-4d27-a2c7-36a429a2f3ae@github.com>
Message-ID: <mywKv4OJEmbTf_Y4mc5bMAv2sPplyFz3TwXmal12bG4=.5afa10a6-34ad-41f0-85ef-dc75b25e68d9@github.com>

On Wed, 30 Apr 2025 22:26:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Move intrinsic to be a subsection; just one most common function of the annotation
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>  - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - Shorter first sentence
>  - Updates, thanks to John
>  - Refine validation and defensive copying
>  - 8355223: Improve documentation on @IntrinsicCandidate

src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 39:

> 37:  * <h2 id="intrinsification">Intrinsification</h2>
> 38:  * The most frequently special treatment is intrinsification, which replaces a
> 39:  * candidate method's body, bytecode or native, with handwritten platform

Is this sentence missing the word "code" after "native"? Should it have been:

> bytecode or native code, ...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2097002980

From jpai at openjdk.org  Tue May 20 06:10:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 May 2025 06:10:56 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6]
In-Reply-To: <RQSSJoSzJXiFcTeA1hCYkS7X1lof5wmtGWScPHKXKag=.6314ada9-e50a-4730-a232-6c48d86c16d8@github.com>
References: <dm6o-XRNWecHjZeenCSRhAOEYI7L_mOOqfguvjlk_Bc=.cdb4e2e5-3500-48d5-8c05-749ff01f06f1@github.com>
 <Y-iTd9LtJ2nW9QZkNz1_xQ1kXToP8DcovFP-LAxrqXk=.8e9f7b28-fa77-4d27-a2c7-36a429a2f3ae@github.com>
 <RQSSJoSzJXiFcTeA1hCYkS7X1lof5wmtGWScPHKXKag=.6314ada9-e50a-4730-a232-6c48d86c16d8@github.com>
Message-ID: <mRatp2NalCiKM0WPzJdl9Uw4CWNdccpoPb5Z8MzmS_k=.80ef3123-1b4b-48e4-a7e2-26f040916cc2@github.com>

On Fri, 16 May 2025 19:55:58 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Move intrinsic to be a subsection; just one most common function of the annotation
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>>  - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java
>>    
>>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>>  - Shorter first sentence
>>  - Updates, thanks to John
>>  - Refine validation and defensive copying
>>  - 8355223: Improve documentation on @IntrinsicCandidate
>
> src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 47:
> 
>> 45:  * intrinsics necessary.
>> 46:  * <p>
>> 47:  * Intrinsification may never happen, or happen at any moment during execution.
> 
> s/or happen/or may happen/ (easier to parse)

Hello John, are there are any hotspot VM flags that can be enabled to check whether or not intrinsification happen for a particular method during the lifetime of an application? Should any of those flags be documented in this proposed text?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2097001318

From jpai at openjdk.org  Tue May 20 06:21:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 May 2025 06:21:54 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6]
In-Reply-To: <Y-iTd9LtJ2nW9QZkNz1_xQ1kXToP8DcovFP-LAxrqXk=.8e9f7b28-fa77-4d27-a2c7-36a429a2f3ae@github.com>
References: <dm6o-XRNWecHjZeenCSRhAOEYI7L_mOOqfguvjlk_Bc=.cdb4e2e5-3500-48d5-8c05-749ff01f06f1@github.com>
 <Y-iTd9LtJ2nW9QZkNz1_xQ1kXToP8DcovFP-LAxrqXk=.8e9f7b28-fa77-4d27-a2c7-36a429a2f3ae@github.com>
Message-ID: <wUBHkojEOzZe-eMMxLPjoyVNCdBOVWekF74Su4zwCIo=.a9b9f66a-6375-4d36-9d0c-e8c518019076@github.com>

On Wed, 30 Apr 2025 22:26:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Move intrinsic to be a subsection; just one most common function of the annotation
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>  - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - Shorter first sentence
>  - Updates, thanks to John
>  - Refine validation and defensive copying
>  - 8355223: Improve documentation on @IntrinsicCandidate

src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 50:

> 48:  * For example, the bytecodes of a candidate method may be executed by lower
> 49:  * compilation tiers of VM execution, while higher compilation tiers may replace
> 50:  * the bytecodes with specialized assembly code and/or compiler IR.  Therefore,

> while higher compilation tiers may replace the bytecodes with specialized assembly code and/or compiler IR

Is there ever a case, where for a `@IntrinsicCandidate` method, the runtime will choose to execute the instrinsic for that method for a certain duration and then at a later point in time replace the intrinsic with compiler generated code? In other words, once the runtime executes the intrinsic implementation for a `@IntrinsicCandidate` method, will the method's implementation be switched to anything else during the lifetime of an application?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2097016882

From alanb at openjdk.org  Tue May 20 06:50:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 May 2025 06:50:51 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
In-Reply-To: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
Message-ID: <VcfrHDkeY9BD6yyKCDnOI58TH0DBihbleOxIBJknmUQ=.5fe13ac5-1863-4e7a-8917-2c8d0170fa9f@github.com>

On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to fix some `javadoc` bugs in `java.base`.
> Certain `@link` tags used to refer to private fields instead of public APIs.
> 
> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
> 
> TIA

src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 138:

> 136:  * {@link #isCompletedAbnormally} is true if a task was either
> 137:  * cancelled or encountered an exception, in which case {@link
> 138:  * #getException()} will return either the encountered exception or

Looks right too, the private overload of getException was added in JDK 22.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2097113958

From alanb at openjdk.org  Tue May 20 06:54:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 May 2025 06:54:58 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
In-Reply-To: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
Message-ID: <2ZTFvRUO5p9CkTijR0qS6x9bwgbI3o4C286Wk9HvHVU=.04f8ca7b-cdf9-4a09-9d3d-587a414d51e1@github.com>

On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to fix some `javadoc` bugs in `java.base`.
> Certain `@link` tags used to refer to private fields instead of public APIs.
> 
> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
> 
> TIA

src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 2023:

> 2021:         /**
> 2022:          * Provides a service with one or more implementations. The package for
> 2023:          * each {@link Provides#providers() provider} (or provider factory) is

okay

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2097120353

From stuefe at openjdk.org  Tue May 20 07:33:14 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 20 May 2025 07:33:14 GMT
Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(),
 use FD_CLOEXEC instead of close()
Message-ID: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>

Hi, please consider the following patch.

This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors (the fail pipe fd needs to be kept open right up to the execve(), and we have internal file descriptors in use during iteration of the proc file system to find open file descriptors).

This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem of needing to keep a log file descriptor open right until execve happens).

Note: Using fcntl with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409

This patch also fixes two subtle bugs:
- we didn't check the return value of the close() inside closeAllFileDescriptors
- the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it)

----

Testing:

We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and with out without FD_CLOEXEC.

- in the parent JVM, the test opens a file in native code without FD_CLOEXEC
- test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open

I verified that the test correctly detects a broken implementation that leaks file descriptors. 

I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX).

I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green.

-------------

Commit messages:
 - close dir fd on fcntl error
 - Mark fds with cloexec, plus test

Changes: https://git.openjdk.org/jdk/pull/25301/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25301&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8210549
  Stats: 204 lines in 5 files changed: 181 ins; 9 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25301/head:pull/25301

PR: https://git.openjdk.org/jdk/pull/25301

From sarma.swaranga at gmail.com  Tue May 20 07:53:39 2025
From: sarma.swaranga at gmail.com (Swaranga Sarma)
Date: Tue, 20 May 2025 00:53:39 -0700
Subject: Towards a JSON API for the JDK
In-Reply-To: <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
 <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
 <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>
 <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com>
 <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CAGZD2TAbv+dQQJCTbpQqa3LVFB90vqBZ-9sbcynAZpOE32bxag@mail.gmail.com>

Hello, I am not a language or a library developer by any means but I wanted
to offer my perspective as a prospective user of such an API.

I am sure this was considered but feel compelled to raise it regardless -
instead of the low level tree API (and baking whatever design choice is
made forever into the JDK), was a higher level data binding API considered
while keeping any low-level tree implementation private to the JDK?
Basically a way to take a Json document (String/Reader/...) and deserialize
it into an instance of a user-defined Record (and vice versa). From my
perspective, this would be a more useful addition for the simpler and most
common cases and if there are more complex requirements around
flexibility/performance then there are lots of 3rd party options available
in Java. I do not have data to back my hunch that this will be more
valuable but I am offering my real production use-case where I would find
it useful:

I have a bunch of rest APIs for which my callers want me to vend a Java
client that has the Java POJO classes for the request and response shapes;
they don't want to write it by hand which is a reasonable ask. I usually
create a Java library that uses the standard Java Http client under the
hood to make the calls and serialize and deserialize the DTOs using
Jackson. The problem is that as soon as I add Jackson to the client
library's dependencies, it is no longer a zero-runtime dependency library
and the callers have to deal with multiple versions, version
incompatibility etc (in case they also use Jackson in the client app). With
a Json api with support for data binding in the standard library, I could
vend a very thin zero additional dependencies Java client to my callers.

This is not quite what JEP 198 is stating as its goals but I am also not
sure if this discussion is towards an implementation for that JEP.

Thank you
Swaranga


On Mon, May 19, 2025 at 2:56?PM <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"Paul Sandoz" <paul.sandoz at oracle.com>
> *To: *"Remi Forax" <forax at univ-mlv.fr>
> *Cc: *"Brian Goetz" <brian.goetz at oracle.com>, "core-libs-dev" <
> core-libs-dev at openjdk.org>
> *Sent: *Monday, May 19, 2025 11:18:26 PM
> *Subject: *Re: Towards a JSON API for the JDK
>
> Those extending the non-sealed subtypes of JsonValue must conform to the
> requirements that are specified. The current documentation could be more
> clearly written as to what those requirements are. Of course we cannot
> enforce those requirements any more than we can enforce the requirements
> specified for implementations of List.
>
>
> List is such a good example.
> For a List, like for a JsonValue, you have no idea if the implementation
> is mutable or not,
> so you can use a defensive copy using List.copyOf() (or
> Collections.unmodifiableList(new ArrayList<>(list)) in the older version of
> Java).
>
> How to do a defensive copy of a JsonValue ?
>
> The other issue I see is lazyness in Json.parse(). The API is restricted
> to String/char[], so restricted to JSON document that are not big.
> If the document is not big, lazyness usually make things slower and it
> also delays the moment you know if the document is a valid JSON document or
> not.
> With the actual design, you have no way to know if a JSON document is
> valid.
>
> If you combine both things, the fact that you have a big list of
> requirements for each subtypes and eager parsing, you are not far from
> having only one implementation possible,
> hence the idea of implementing real ADTs using records.
>
>
> Paul.
>
>
> R?mi
>
>
>
> On May 19, 2025, at 1:56?PM, forax at univ-mlv.fr wrote:
>
>
>
> ------------------------------
>
> *From:*"Paul Sandoz" <paul.sandoz at oracle.com>
> *To:*"Remi Forax" <forax at univ-mlv.fr>
> *Cc:*"Brian Goetz" <brian.goetz at oracle.com>, "core-libs-dev" <
> core-libs-dev at openjdk.org>
> *Sent:*Monday, May 19, 2025 10:02:50 PM
> *Subject:*Re: Towards a JSON API for the JDK
>
>
>
> On May 19, 2025, at 8:16?AM, Remi Forax <forax at univ-mlv.fr> wrote:
>
> Okay,
> i've taken a look to the design and this is not pretty.
>
>
> That seems an exaggerated statement to me. It's a trade-off, a compromise,
> allowing others to implement their own parsers, perhaps from non-textual
> representations. So of course we cannot enforce certain constraints and we
> need to specify how implementations must behave.
>
>
> The main issue is that the javadoc claims that
>   "BothJsonValueinstances and their underlying values are immutable."
> but at the same time any subtypes of JsonValue is non-sealed so anyone can
> implement let say JsonString and adds it's own mutable implementation.
>
>
> You can not claim that JsonValue instances are immutable while obviously
> they are not.
> You can not claim that JsonValue subtypes are ADTs while obviously
> JsonValue is not algebraic.
>
> You allow anybody to write their own class inside the JsonValue hierarchy,
> so there is no safety, strings can be not escaped correctly, number can
> represent invalid values, etc.
>
> The minute I write a method that takes a JsonValue as parameter i'm
> writing unsafe code,
>
> You are hoping that nobody will ever extend JsonValue subtypes, that's
> wishful thinking, this is not a safe design ... this is not pretty.
>
> R?mi
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250520/dd6c79f4/attachment-0001.htm>

From pminborg at openjdk.org  Tue May 20 08:28:51 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 20 May 2025 08:28:51 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods [v3]
In-Reply-To: <SMAz5R1EFhePJhslGUGTDYdAPuPJGbfmn6t14cDpiXc=.950cf100-d65b-4fa4-8ae7-fe28d990b4f9@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
 <SMAz5R1EFhePJhslGUGTDYdAPuPJGbfmn6t14cDpiXc=.950cf100-d65b-4fa4-8ae7-fe28d990b4f9@github.com>
Message-ID: <rWMwqD7cN6zJcOHlBYPczOITJQHsR9xpamfhIUJcE38=.90caf52e-c055-4cbf-a11b-e24c58cbef57@github.com>

On Tue, 20 May 2025 02:11:34 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline.
>> 
>> The following is the output information of PrintInlining:
>> 
>>                 @ 9   java.lang.String::<init> (12 bytes)   inline (hot)
>> !m                 @ 1   java.nio.charset.Charset::defaultCharset (52 bytes)   inline (hot)
>> !                  @ 8   java.lang.String::<init> (852 bytes)   failed to inline: hot method too big
>> 
>> 
>> In Java code, the big method that cannot be inlined is the following constructor
>> 
>> 
>> String(Charset charset, byte[] bytes, int offset, int length) {}
>> 
>> The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   create method share variant val & coder

I wonder if it would be better to first check `COMPACT_STRINGS` in a first-level `if` and then branch off to separate support methods? Looking at the comments near the declaration of `COMPACT_STRINGS`, this might provide additional benefits.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25290#issuecomment-2893426860

From azeller at openjdk.org  Tue May 20 08:34:51 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Tue, 20 May 2025 08:34:51 GMT
Subject: RFR: 8357052: java/io/File/GetXSpace.java prints wrong values in
 exception
In-Reply-To: <BjB1MN5ig43IZpiovy_3lCIA3QV1NqfbHCXndcJWuOU=.99c2ba20-b5a8-4ca3-9af5-40bace5b8214@github.com>
References: <uKC3cFU14_1fPbsr9tamorif3MftHeN-Sfbz2483uik=.b18e053d-9be9-4b94-8a5f-cbed7f2e032a@github.com>
 <BjB1MN5ig43IZpiovy_3lCIA3QV1NqfbHCXndcJWuOU=.99c2ba20-b5a8-4ca3-9af5-40bace5b8214@github.com>
Message-ID: <_2c3O7v_NV_9PHUw0wVrniD2DrMlK2oBFPq7Wralu9Q=.aa61f5d4-a046-4db5-a29c-df75fa7c3648@github.com>

On Mon, 19 May 2025 20:19:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> @ArnoZeller Please issue the `/integrate` command so that this request may be sponsored.

Thanks for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25250#issuecomment-2893448783

From duke at openjdk.org  Tue May 20 08:34:51 2025
From: duke at openjdk.org (duke)
Date: Tue, 20 May 2025 08:34:51 GMT
Subject: RFR: 8357052: java/io/File/GetXSpace.java prints wrong values in
 exception
In-Reply-To: <uKC3cFU14_1fPbsr9tamorif3MftHeN-Sfbz2483uik=.b18e053d-9be9-4b94-8a5f-cbed7f2e032a@github.com>
References: <uKC3cFU14_1fPbsr9tamorif3MftHeN-Sfbz2483uik=.b18e053d-9be9-4b94-8a5f-cbed7f2e032a@github.com>
Message-ID: <NtP5oswc1d32lB30z6sSYITmigkR19EErkvP4IBF2sU=.1ec1386b-1bd8-475e-87bc-a4f8229e6037@github.com>

On Thu, 15 May 2025 13:49:14 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> When the test java/io/File/GetXSpace.java fails, because the usable space is greater than the free space, the values in the exception are not the correct ones.

@ArnoZeller 
Your change (at version 8506932622f713e0a21dda7150128773718d283a) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25250#issuecomment-2893454910

From swen at openjdk.org  Tue May 20 08:48:53 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 20 May 2025 08:48:53 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods [v3]
In-Reply-To: <rWMwqD7cN6zJcOHlBYPczOITJQHsR9xpamfhIUJcE38=.90caf52e-c055-4cbf-a11b-e24c58cbef57@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
 <SMAz5R1EFhePJhslGUGTDYdAPuPJGbfmn6t14cDpiXc=.950cf100-d65b-4fa4-8ae7-fe28d990b4f9@github.com>
 <rWMwqD7cN6zJcOHlBYPczOITJQHsR9xpamfhIUJcE38=.90caf52e-c055-4cbf-a11b-e24c58cbef57@github.com>
Message-ID: <yh5rGgnKHezcNgl6_p0L5Gj9C7omAJggC-eHkVmF2GM=.ac881d8b-61a7-45dc-b308-d06e1aa7b0f1@github.com>

On Tue, 20 May 2025 08:26:20 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> I wonder if it would be better to first check `COMPACT_STRINGS` in a first-level `if` and then branch off to separate support methods? Looking at the comments near the declaration of `COMPACT_STRINGS`, this might provide additional benefits.

Now all the broken methods have CodeSize < 325 and can be inlined by C2. If we check COMPACT_STRINGS at the first level, we need to change more. I want to achieve the goal with minimal changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25290#issuecomment-2893507842

From mik3hall at gmail.com  Tue May 20 09:13:19 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 20 May 2025 04:13:19 -0500
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles
In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
Message-ID: <D9E39011-3545-4A43-A0DD-C36CB82BC114@gmail.com>

> On May 19, 2025, at 7:53?PM, Alexander Matveev <almatvee at openjdk.org> wrote:
> 
> Fixed jpackage to produce valid Java runtimes based on description below:
> 
> Definitions:


Thanks for the follow-up.

To the comments on the issue of would it be useful for jpackage to do this. 

The runtime images that you get with make images doesn?t work for applications. So it can?t be used to test applications. I assume your changes make that possible. How often you might want to test 
jdk builds against applications I don?t know.  

Validation again seemed to me to be important. In trying this out I attempted different ways to use the ?runtime-image parameter. All of them succeeded in creating dmg?s but the images were not valid.

Is there some test being added?

From mik3hall at gmail.com  Tue May 20 09:27:57 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 20 May 2025 04:27:57 -0500
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles
In-Reply-To: <D9E39011-3545-4A43-A0DD-C36CB82BC114@gmail.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
 <D9E39011-3545-4A43-A0DD-C36CB82BC114@gmail.com>
Message-ID: <C39375F7-84F4-4AB8-BB2D-81B94A7D8C18@gmail.com>



> On May 20, 2025, at 4:13?AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> The runtime images that you get with make images doesn?t work for applications. 

I might be misremembering on this. It might be useable as a runtime image to embed in applications with jpackage?
It is not valid as a system runtime image that can be installed into JavaVirtualMachines and become the default system runtime for command line and applications.
This would sort of seem the purpose of a jpackage option that allows putting a runtime into a dmg that can be drag and drop installed into JavaVirtualMachines. 
It should be a valid runtime for this purpose. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250520/6f939fb1/attachment.htm>

From kbarrett at openjdk.org  Tue May 20 09:34:51 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 20 May 2025 09:34:51 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: <YQRD37sSMcVIjPBMvGTEmv7e_pzircI13BlVMMISyHM=.a7f5bbd2-dadc-4a8b-be59-451dfbbc4e0b@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <wp_i02Ji5nG8obVLo9gJvHwA73hfC_b2dx56nXVsCoM=.c481ac3c-77ca-4d27-89be-31d98055964f@github.com>
 <YQRD37sSMcVIjPBMvGTEmv7e_pzircI13BlVMMISyHM=.a7f5bbd2-dadc-4a8b-be59-451dfbbc4e0b@github.com>
Message-ID: <-8uXuvzZnsXlaHEUfBtG3qSpxLqQT-ViLyXk81zT_zo=.3e08d0b4-7eee-44fd-a829-98673c979c6c@github.com>

On Mon, 19 May 2025 19:08:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/java/nio/Bits.java line 170:
> 
>> 168:             // without it that test likely fails.  Since failure here
>> 169:             // ends in OOME, there's no need to hurry.
>> 170:             for (int sleeps = 0; true; ) {
> 
> More typical coding pattern in openjdk code.  Here and elsewhere in this PR.
> Suggestion:
> 
>             while (true) {
>                 int sleeps = 0;

That's not the same thing, and doesn't do what's needed here.  Perhaps you meant

int sleeps = 0;
while (true) {

I like limiting the scope of the variable.  Is that a suggestion or a request to change?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2097487954

From vklang at openjdk.org  Tue May 20 10:14:03 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 20 May 2025 10:14:03 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message
In-Reply-To: <AnrjLD7rJwg1dT8fNc5XMs8rqhSlLxIPNPk27zZtN7k=.34540e60-36c4-4c98-9a11-668fff434160@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <AnrjLD7rJwg1dT8fNc5XMs8rqhSlLxIPNPk27zZtN7k=.34540e60-36c4-4c98-9a11-668fff434160@github.com>
Message-ID: <3C_11D3AR_qG3ifDbWztlzhD8rZyultJEKh_89wWN1M=.5af79488-6978-4f80-a07e-b4c38139b390@github.com>

On Tue, 11 Feb 2025 03:54:56 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

>> 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.
>
> It would be much nicer if you take this one:), we are on JDK 21 and want to have this in the next LTS.

@He-Pin Just pinging you here, in case the notification from my most recent comments got lost in transit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2893787581

From azeller at openjdk.org  Tue May 20 10:22:01 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Tue, 20 May 2025 10:22:01 GMT
Subject: Integrated: 8357052: java/io/File/GetXSpace.java prints wrong values
 in exception
In-Reply-To: <uKC3cFU14_1fPbsr9tamorif3MftHeN-Sfbz2483uik=.b18e053d-9be9-4b94-8a5f-cbed7f2e032a@github.com>
References: <uKC3cFU14_1fPbsr9tamorif3MftHeN-Sfbz2483uik=.b18e053d-9be9-4b94-8a5f-cbed7f2e032a@github.com>
Message-ID: <ccrf2HrjTl-GI-rd7DGlQT9AJj-Kwu_TWPibTzbZH3s=.f0505890-932b-4f6e-b4f7-9def74a84416@github.com>

On Thu, 15 May 2025 13:49:14 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> When the test java/io/File/GetXSpace.java fails, because the usable space is greater than the free space, the values in the exception are not the correct ones.

This pull request has now been integrated.

Changeset: f8fc7eeb
Author:    Arno Zeller <azeller at openjdk.org>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f8fc7eeb24156f9c38ddd478b026074f522e39c4
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8357052: java/io/File/GetXSpace.java prints wrong values in exception

Reviewed-by: bpb

-------------

PR: https://git.openjdk.org/jdk/pull/25250

From liach at openjdk.org  Tue May 20 10:38:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 May 2025 10:38:51 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6]
In-Reply-To: <mRatp2NalCiKM0WPzJdl9Uw4CWNdccpoPb5Z8MzmS_k=.80ef3123-1b4b-48e4-a7e2-26f040916cc2@github.com>
References: <dm6o-XRNWecHjZeenCSRhAOEYI7L_mOOqfguvjlk_Bc=.cdb4e2e5-3500-48d5-8c05-749ff01f06f1@github.com>
 <Y-iTd9LtJ2nW9QZkNz1_xQ1kXToP8DcovFP-LAxrqXk=.8e9f7b28-fa77-4d27-a2c7-36a429a2f3ae@github.com>
 <RQSSJoSzJXiFcTeA1hCYkS7X1lof5wmtGWScPHKXKag=.6314ada9-e50a-4730-a232-6c48d86c16d8@github.com>
 <mRatp2NalCiKM0WPzJdl9Uw4CWNdccpoPb5Z8MzmS_k=.80ef3123-1b4b-48e4-a7e2-26f040916cc2@github.com>
Message-ID: <qndOjUPJLx73xRoWjRJUX8LzCum8Yt34pgeCpKjtzmY=.55aac44a-19a9-4554-bbc9-85897448ccba@github.com>

On Tue, 20 May 2025 06:07:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 47:
>> 
>>> 45:  * intrinsics necessary.
>>> 46:  * <p>
>>> 47:  * Intrinsification may never happen, or happen at any moment during execution.
>> 
>> s/or happen/or may happen/ (easier to parse)
>
> Hello John, are there are any hotspot VM flags that can be enabled to check whether or not intrinsification happen for a particular method during the lifetime of an application? Should any of those flags be documented in this proposed text?

I see there is a `ControlIntrinsic` flag in `globals.hpp`, but I am not sure how it actually interacts with intrinsics.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2097622562

From duke at openjdk.org  Tue May 20 10:54:44 2025
From: duke at openjdk.org (He-Pin (kerr))
Date: Tue, 20 May 2025 10:54:44 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message [v5]
In-Reply-To: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
Message-ID: <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com>

> 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 two additional commits since the last revision:

 - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
   
   Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
 - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
   
   Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23050/files
  - new: https://git.openjdk.org/jdk/pull/23050/files/b4a10d1c..ad67bd17

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23050&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23050&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 vyazici at openjdk.org  Tue May 20 11:34:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 20 May 2025 11:34:53 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
In-Reply-To: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
Message-ID: <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>

On Fri, 16 May 2025 18:11:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.

src/java.base/share/classes/java/io/Console.java line 560:

> 558:     static final Charset STDIN_CHARSET =
> 559:         Charset.forName(System.getProperty("stdin.encoding"), UTF_8.INSTANCE);
> 560:     static final Charset STDOUT_CHARSET =

I guess these can be marked `private`?

Suggestion:

    private static final Charset STDIN_CHARSET =
        Charset.forName(System.getProperty("stdin.encoding"), UTF_8.INSTANCE);
    private static final Charset STDOUT_CHARSET =

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 160:

> 158: 
> 159:             try {
> 160:                 Terminal terminal = TerminalBuilder.builder().encoding(outCharset)

Shouldn't ideally `JdkConsole::charset` and `Terminal::encoding` be adapted for stdin/stdout variants?

test/jdk/java/io/Console/CharsetTest.java line 1:

> 1: /*

Copyright year update is missing.

test/jdk/java/io/Console/StdinEncodingTest.java line 46:

> 44:  * @run junit StdinEncodingTest
> 45:  */
> 46: public class StdinEncodingTest {

AFAICT, there is no similar test (e.g., one using a mock `CharsetProvider`) for `stdout.encoding`. Will it be addressed by another ticket? Shall we consider adding a similar `StdoutEncodingTest` too? (Not necessarily in this PR.)

test/jdk/java/io/Console/StdinEncodingTest.java line 49:

> 47: 
> 48:     @Test
> 49:     @EnabledOnOs({OS.LINUX, OS.MAC})

Shall we replace `@EnabledOnOs` with the `@requires (os.family == "linux" | os.family == "mac")` JTreg directive instead per [JDK-8211673](https://bugs.openjdk.org/browse/JDK-8211673)?

test/jdk/java/io/Console/csp/provider/MockCharsetProvider.java line 36:

> 34: 
> 35: // A test charset provider that decodes every input byte into its uppercase
> 36: public class MockCharsetProvider extends CharsetProvider {

*Nit:* Maybe a more self-explanatory name, e.g., `UpperCasingCharsetProvider`?

test/jdk/java/io/Console/csp/provider/MockCharsetProvider.java line 83:

> 81:             while (in.remaining() > 0) {
> 82:                 char c = (char)in.get();
> 83:                 if (c != '\n') {

`Character.toUpperCase('\n') == '\n'`, not? If so, do we still need this `if`-branching?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097641573
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097630717
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097578092
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097718253
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097671831
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097711653
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097704883

From rgiulietti at openjdk.org  Tue May 20 11:35:54 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 20 May 2025 11:35:54 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v6]
In-Reply-To: <_7_Cbd9Yq1qPpOWvVIz7ROCzvrHwHPmDjbCS_wBtGUo=.badca150-12bb-4b98-b795-31699efcc947@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <Fe1FcysTPgZYA1aEUGFHRfBxnQ_QkYXJ-4it0QscrS8=.7c1fa510-c570-481c-aa40-5cca05667f34@github.com>
 <hoQilPfsm719vv9gOH4kkZVdLoTONdoWfOA0XK1FPHg=.bef64c99-7b68-40a7-b570-68700336de11@github.com>
 <_7_Cbd9Yq1qPpOWvVIz7ROCzvrHwHPmDjbCS_wBtGUo=.badca150-12bb-4b98-b795-31699efcc947@github.com>
Message-ID: <uZ0t_zopT7FX8nLH7wLzlno2q3oAxBGB7RnY4SAm6e0=.3dd1d5a4-cacc-48a3-b221-47a58e64bd90@github.com>

On Fri, 16 May 2025 10:10:28 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you please crosscheck?
>
>> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you please crosscheck?
> 
> @rgiulietti  It seems there is a slowdown in the creation of large pseudoprimes, maybe due to `BitSieve` methods.

@fabioromano1 I'm ready to approve.
Please keep in mind that rampdown is on 2025-06-05, so there is time for other small changes you might want to add to this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2894008015

From duke at openjdk.org  Tue May 20 11:58:30 2025
From: duke at openjdk.org (kieran-farrell)
Date: Tue, 20 May 2025 11:58:30 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v2]
In-Reply-To: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
Message-ID: <oUfkyKRcZ1MZmrcaljHHFzxW5QMD4dOwwMRAtM0P-QQ=.348e32d4-ff3d-4887-b8fb-bdeffb20db62@github.com>

> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
> 
> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
> 
> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
> 
> 
> - random-byte-only - 99.8%
> - higher-precision - 3.5%
> - counter-based - 0%
> 
> 
> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
> 
> - random-byte-only   143.487 ? 10.932  ns/op
> - higher-precision      149.651 ?  8.438 ns/op
> - counter-based         245.036 ?  2.943  ns/op
> 
> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.

kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:

  update RFC

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25303/files
  - new: https://git.openjdk.org/jdk/pull/25303/files/b0b4f7a8..922869b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=00-01

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303

PR: https://git.openjdk.org/jdk/pull/25303

From duke at openjdk.org  Tue May 20 12:02:53 2025
From: duke at openjdk.org (kieran-farrell)
Date: Tue, 20 May 2025 12:02:53 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v2]
In-Reply-To: <Jm4ATGoFWP2a8HSBuwAglmdQS5fcBKBxt7TOklUQRjk=.b47ef4c7-26cd-4603-a074-76be89fa898c@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <Jm4ATGoFWP2a8HSBuwAglmdQS5fcBKBxt7TOklUQRjk=.b47ef4c7-26cd-4603-a074-76be89fa898c@github.com>
Message-ID: <D2OwQlifY_F57s5ntpnVSYAMxZ8lacAyv03fME6O3ZM=.524387cc-ad76-4261-9269-8e2f08aeb6fb@github.com>

On Mon, 19 May 2025 18:08:18 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update RFC
>
> src/java.base/share/classes/java/util/UUID.java line 195:
> 
>> 193:      *
>> 194:      * @return A {@code UUID} generated from the current system time
>> 195:      */
> 
> Seems like there should be a reference to the RFC somewhere here using the @spec javadoc tag.
> 
> And also in the class javadoc.

spec updated in class javadoc to RFC 9562 which obsolete RFC 4122, @spec tag also added above the method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2097772811

From aturbanov at openjdk.org  Tue May 20 12:09:52 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 20 May 2025 12:09:52 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v2]
In-Reply-To: <oUfkyKRcZ1MZmrcaljHHFzxW5QMD4dOwwMRAtM0P-QQ=.348e32d4-ff3d-4887-b8fb-bdeffb20db62@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <oUfkyKRcZ1MZmrcaljHHFzxW5QMD4dOwwMRAtM0P-QQ=.348e32d4-ff3d-4887-b8fb-bdeffb20db62@github.com>
Message-ID: <oFaaRMCbHKFY7Q1WcBGJ0_w7xgIIZkJpueV7fXMbL0U=.808e3eac-3f84-4196-95c7-e63c485673f1@github.com>

On Tue, 20 May 2025 11:58:30 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
>> 
>> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
>> 
>> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
>> 
>> 
>> - random-byte-only - 99.8%
>> - higher-precision - 3.5%
>> - counter-based - 0%
>> 
>> 
>> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
>> 
>> - random-byte-only   143.487 ? 10.932  ns/op
>> - higher-precision      149.651 ?  8.438 ns/op
>> - counter-based         245.036 ?  2.943  ns/op
>> 
>> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.
>
> kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update RFC

src/java.base/share/classes/java/util/UUID.java line 213:

> 211:         int nsBits = (int) ((nsTime % 1_000_000) / 1_000_000.0 * 4096);
> 212: 
> 213:         // Set version and increased percision time bits

Suggestion:

        // Set version and increased precision time bits

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2097785581

From duke at openjdk.org  Tue May 20 12:57:34 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 20 May 2025 12:57:34 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v10]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <lDYHpY35XrgVLBmHxK_Wj85UkxxSNuTmUXguOdrYnn0=.fd28ba1e-b2ac-4005-a3d3-e3974b1ceeca@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Small code simplifications

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/b74fefa5..ed2e7c35

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=08-09

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From jlahoda at openjdk.org  Tue May 20 13:12:28 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 20 May 2025 13:12:28 GMT
Subject: RFR: 8347050: Console.readLine() drops '\' when reading through JLine
Message-ID: <CrRA1pKBHMYHwGSTVCA4j_TTDsl56xMZ4jG_cd-KBhg=.97ee6b8b-06db-4831-ab6e-a15242df941b@github.com>

JLine can do history expansion, and interpret escapes, when returning a value. That is not desirable when using JLine as a backend for Console.readLine().

This PR proposes to disable the history expansion.

-------------

Commit messages:
 - Adding bug number
 - 8347050: Console.readLine() drops '\' when reading through JLine

Changes: https://git.openjdk.org/jdk/pull/25326/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25326&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347050
  Stats: 16 lines in 2 files changed: 14 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25326.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25326/head:pull/25326

PR: https://git.openjdk.org/jdk/pull/25326

From duke at openjdk.org  Tue May 20 13:20:10 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 20 May 2025 13:20:10 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v11]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <Ab8f2QVk70iQVEUG1prjN5bneKHHdj3KUO2SG-_cBrM=.96702d91-982e-4b51-a1c8-34fff966677a@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Removed redundant code for choosing division's algorithm logic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/ed2e7c35..7a0b0211

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=09-10

  Stats: 72 lines in 1 file changed: 0 ins; 69 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From duke at openjdk.org  Tue May 20 13:37:51 2025
From: duke at openjdk.org (kieran-farrell)
Date: Tue, 20 May 2025 13:37:51 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v2]
In-Reply-To: <Jm4ATGoFWP2a8HSBuwAglmdQS5fcBKBxt7TOklUQRjk=.b47ef4c7-26cd-4603-a074-76be89fa898c@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <Jm4ATGoFWP2a8HSBuwAglmdQS5fcBKBxt7TOklUQRjk=.b47ef4c7-26cd-4603-a074-76be89fa898c@github.com>
Message-ID: <gfboyaqw8NXiohbBi1Q0cWStFPuvXI6RFMUoIMtaJVM=.2c27a47a-dc32-4d5f-b3ba-35dd00f4b106@github.com>

On Mon, 19 May 2025 18:17:09 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Can the sub-microsecond value just be truncated and avoid the expensive divide operation?'

method 3 of secion 6.2 of https://www.rfc-editor.org/rfc/rfc9562.html#name-monotonicity-and-counters states 

> start with the portion of the timestamp expressed as a fraction of the clock's tick value (fraction of a millisecond for UUIDv7). Compute the count of possible values that can be represented in the available bit space, 4096 for the UUIDv7 rand_a field. Using floating point or scaled integer arithmetic, multiply this fraction of a millisecond value by 4096 and round down (toward zero) to an integer result to arrive at a number between 0 and the maximum allowed for the indicated bits, which sorts monotonically based on time. '

so i think we might have to keep the division? though i re-shuffled the equation to 

`int nsBits = (int) ((nsTime % 1_000_000) / 1_000_000.0 * 4096);`

which gives scaled integer division rather than floating point and gave a very slight imporved perfomance to 143.758 ? 2.135  ns/op

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2097994819

From duke at openjdk.org  Tue May 20 13:59:54 2025
From: duke at openjdk.org (kieran-farrell)
Date: Tue, 20 May 2025 13:59:54 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v2]
In-Reply-To: <gfboyaqw8NXiohbBi1Q0cWStFPuvXI6RFMUoIMtaJVM=.2c27a47a-dc32-4d5f-b3ba-35dd00f4b106@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <Jm4ATGoFWP2a8HSBuwAglmdQS5fcBKBxt7TOklUQRjk=.b47ef4c7-26cd-4603-a074-76be89fa898c@github.com>
 <gfboyaqw8NXiohbBi1Q0cWStFPuvXI6RFMUoIMtaJVM=.2c27a47a-dc32-4d5f-b3ba-35dd00f4b106@github.com>
Message-ID: <pD8XqEflVmkHQIAn0enmOXPR3JYRvrC3eR_X0Cm1Jyc=.3bbff99b-b1d0-41d7-992e-1185c8bdc671@github.com>

On Tue, 20 May 2025 13:35:32 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/UUID.java line 219:
>> 
>>> 217:         randomBytes[8] |= (byte) 0x80;
>>> 218: 
>>> 219:         return new UUID(randomBytes);
>> 
>> This could remove the allocation by composing the high and low longs using shifts and binary operations and ng.next().
>> Can the sub-microsecond value just be truncated and avoid the expensive divide operation?
>
>> Can the sub-microsecond value just be truncated and avoid the expensive divide operation?'
> 
> method 3 of secion 6.2 of https://www.rfc-editor.org/rfc/rfc9562.html#name-monotonicity-and-counters states 
> 
>> start with the portion of the timestamp expressed as a fraction of the clock's tick value (fraction of a millisecond for UUIDv7). Compute the count of possible values that can be represented in the available bit space, 4096 for the UUIDv7 rand_a field. Using floating point or scaled integer arithmetic, multiply this fraction of a millisecond value by 4096 and round down (toward zero) to an integer result to arrive at a number between 0 and the maximum allowed for the indicated bits, which sorts monotonically based on time. '
> 
> so i think we might have to keep the division? though i re-shuffled the equation to 
> 
> `int nsBits = (int) ((nsTime % 1_000_000) / 1_000_000.0 * 4096);`
> 
> which gives scaled integer division rather than floating point and gave a very slight imporved perfomance to 143.758 ? 2.135  ns/op

> This could remove the allocation by composing the high and low longs using shifts and binary operations and ng.next().

do you mean to create the UUID using most and least significant bytes? if so, I've tried out some variations, i found creating the 64 bit lsb with ng.nextLong() brings a large pefomance decrease over using the nextBytes method, but the below implemntation keeping with the nextByte(byte[]) api brings a performance increase to 121.128 ? 30.486  ns/op, though the code might appear a little roundabout.


    public static UUID timestampUUID() {
        long msTime = System.currentTimeMillis();
        long nsTime = System.nanoTime();

        // Scale sub-ms nanoseconds to a 12-bit value
        int nsBits = (int) ((nsTime % 1_000_000L) * 4096L / 1_000_000L);

        // Compose the 64 most significant bits: [48-bit msTime | 4-bit version | 12-bit nsBits]
        long mostSigBits =
                ((msTime & 0xFFFFFFFFFFFFL) << 16) |
                        (0x7L << 12) |
                        nsBits;

        // Generate 8 random bytes for least significant bits
        byte[] randomBytes = new byte[8];
        SecureRandom ng = UUID.Holder.numberGenerator;
        ng.nextBytes(randomBytes);

        long leastSigBits = 0;
        for (int i = 0; i < 8; i++) {
            leastSigBits = (leastSigBits << 8) | (randomBytes[i] & 0xFF);
        }

        // Set variant (bits 62?63) to '10'
        leastSigBits &= 0x3FFFFFFFFFFFFFFFL;
        leastSigBits |= 0x8000000000000000L;

        return new UUID(mostSigBits, leastSigBits);
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2098044396

From dfuchs at openjdk.org  Tue May 20 14:04:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 20 May 2025 14:04:51 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
In-Reply-To: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
Message-ID: <kxT45XYpRXuXA-BdYHrEDFAS4GF3V2avnHPpwlySnVw=.0b90c3e6-183b-4e34-82a7-0e39ece26ab4@github.com>

On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to fix some `javadoc` bugs in `java.base`.
> Certain `@link` tags used to refer to private fields instead of public APIs.
> 
> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
> 
> TIA

Changes to `java.net.Socket` LGTM

-------------

PR Review: https://git.openjdk.org/jdk/pull/25287#pullrequestreview-2854340236

From rgiulietti at openjdk.org  Tue May 20 14:11:57 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 20 May 2025 14:11:57 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v11]
In-Reply-To: <Ab8f2QVk70iQVEUG1prjN5bneKHHdj3KUO2SG-_cBrM=.96702d91-982e-4b51-a1c8-34fff966677a@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <Ab8f2QVk70iQVEUG1prjN5bneKHHdj3KUO2SG-_cBrM=.96702d91-982e-4b51-a1c8-34fff966677a@github.com>
Message-ID: <VK0_qN3AH5OTwH6LD09Cym8Vif0XOU8TyFivG11A_OA=.53f613da-0ef6-441a-8feb-ee1d84c55997@github.com>

On Tue, 20 May 2025 13:20:10 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed redundant code for choosing division's algorithm logic

The last commit about `divide` is a bit out of scope. While it is simple, I suggest deferring it to another PR.

I've long planned a reorganization of `BigInteger`s implementation to shift the heavy-lifting work to `MutableBigInteger` (in particular, the multiplication algorithms) and leave `BigInteger` as a simple wrapper of `MutableBigInteger` (the thinner, the better). The `divide` simplifications could be part of that work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2894578950

From nbenalla at openjdk.org  Tue May 20 14:27:51 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 20 May 2025 14:27:51 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base
In-Reply-To: <WZZYF8Iya98gTL9llOIM3I7BnaP_H9j8FAngihjK7Bg=.4dce64e4-4b73-4a7d-b6d9-c3d49802fa0e@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
 <SnUSWGwMDdeWI9ivGw50g8tiYs7CTTACfWI_pmI93Ho=.0cace409-d43b-4e15-bb0f-9939555429e5@github.com>
 <SR_4-v-Y3EajMlQGMIxGQyfkZx4XlchmSs4MQTD6yAM=.97982bd4-8aec-406a-b13e-43ffce663f52@github.com>
 <WZZYF8Iya98gTL9llOIM3I7BnaP_H9j8FAngihjK7Bg=.4dce64e4-4b73-4a7d-b6d9-c3d49802fa0e@github.com>
Message-ID: <AcjwrzK8MJLJeTiMG3VAJyPcG3-kGYEprMCumpI_vGg=.4e1b3a27-6d48-42b9-a3e4-6a712bf781f0@github.com>

On Mon, 19 May 2025 20:41:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> They are documented in [this page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType)
>
> Okay -- if there is some link to the private serial-related methods even in a public javadoc run, I think it would be preferable if links to those methods could be resolved by javadoc. Otherwise, if the links to private methods _from a private method_, would be valid in a private javadoc run, I thinks more refined version of warning would let those be.
> 
> As it is, if the see tags are going to stay, I don't think `<code>foo</code>` markup should be used.

I will revert the changes to `MethoType.java` and try to make the links to the private methods resolvable. (In a future patch)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2098123931

From rriggs at openjdk.org  Tue May 20 14:42:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 20 May 2025 14:42:54 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: <-8uXuvzZnsXlaHEUfBtG3qSpxLqQT-ViLyXk81zT_zo=.3e08d0b4-7eee-44fd-a829-98673c979c6c@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <wp_i02Ji5nG8obVLo9gJvHwA73hfC_b2dx56nXVsCoM=.c481ac3c-77ca-4d27-89be-31d98055964f@github.com>
 <YQRD37sSMcVIjPBMvGTEmv7e_pzircI13BlVMMISyHM=.a7f5bbd2-dadc-4a8b-be59-451dfbbc4e0b@github.com>
 <-8uXuvzZnsXlaHEUfBtG3qSpxLqQT-ViLyXk81zT_zo=.3e08d0b4-7eee-44fd-a829-98673c979c6c@github.com>
Message-ID: <OAjlVMeeuymJHgkZaZBUK-8x4RqPESZ_40KzmQAtL7I=.55e4d7af-f062-40c8-8541-4b92ee1b5ab1@github.com>

On Tue, 20 May 2025 09:32:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/Bits.java line 170:
>> 
>>> 168:             // without it that test likely fails.  Since failure here
>>> 169:             // ends in OOME, there's no need to hurry.
>>> 170:             for (int sleeps = 0; true; ) {
>> 
>> More typical coding pattern in openjdk code.  Here and elsewhere in this PR.
>> Suggestion:
>> 
>>             while (true) {
>>                 int sleeps = 0;
>
> That's not the same thing, and doesn't do what's needed here.  Perhaps you meant
> 
> int sleeps = 0;
> while (true) {
> 
> I like limiting the scope of the variable.  Is that a suggestion or a request to change?

right, your form does better limit the scope of the loop, and is correct as is; (just looks unusual)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2098160773

From duke at openjdk.org  Tue May 20 15:05:17 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 20 May 2025 15:05:17 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v10]
In-Reply-To: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
Message-ID: <kdkI3citrqw1Om9J75aWr8LHi-PFwb-sh3Aw1t78Sa4=.1a4f5e94-fb14-4478-8134-47d4fa953110@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Tweaking exact wording.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/e5725599..793e1856

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=08-09

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

PR: https://git.openjdk.org/jdk/pull/25178

From michaelm at openjdk.org  Tue May 20 15:31:12 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 20 May 2025 15:31:12 GMT
Subject: RFR: 8353124: java/lang/Thread/virtual/stress/Skynet.java#Z times out
 on macosx-x64-debug
Message-ID: <F4TigL343CD7V_qcvCrTLizAF4NiV3kgQQzv6avwSuw=.44197229-be1a-4369-91a4-1fda34d8478f@github.com>

Hi,

This is a simple test update which increases a timeout from 300s to 400 to account for slow mac os test machines.
A repeat 50 test of :jdk_lang passes. I will run this a few more times before pushing, if the change is acceptable.

Thanks,
Michael

-------------

Commit messages:
 - test update

Changes: https://git.openjdk.org/jdk/pull/25331/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25331&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353124
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25331.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25331/head:pull/25331

PR: https://git.openjdk.org/jdk/pull/25331

From paul.sandoz at oracle.com  Tue May 20 15:53:16 2025
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 20 May 2025 15:53:16 +0000
Subject: Towards a JSON API for the JDK
In-Reply-To: <CA+NR86h4Zwc=6D8Eodze=zAHQVgTGgMCpzzJvvg06O8j1_DLZw@mail.gmail.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gt3GNjDPS2m-2wha5AwgumMvBRxKw+bwgTCNQ1xCiDfg@mail.gmail.com>
 <1353089152.267509212.1747398414378.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86hECE-T9gMZT6+gbSoFhDpLeVDkvGYqyz-ByV18_MgpVw@mail.gmail.com>
 <FC59D02C-8EF0-49E4-8AF1-97A115495FD1@oracle.com>
 <CA+NR86h4Zwc=6D8Eodze=zAHQVgTGgMCpzzJvvg06O8j1_DLZw@mail.gmail.com>
Message-ID: <3DE8F8D4-C203-481D-91E6-414698D43A86@oracle.com>

I think I see what you mean, although to me the general characterization as construction/deconstruction is too narrow - there are a zillion ways to pack-in and pack-out the tree, some partial, and some lossy etc. The canonical pack-in/out is arguably parsing and writing from and to JSON documents.

fromUptyped is way to ?pack-in? the tree, transforming maps and lists, where leaf elements are directly input to the construction of JSON (leaf) values. toUptyped is the functional inverse to "pack-out?, and when we have deconstructor patterns we can more clearly and concisely express the deconstruction relationship in the switch statement e.g., perhaps like [1]. I think it a feature that they directly lean into construction and (currently implement) deconstruction of JSON values without much or any embellishment.

This of course punts on the problem of dealing with present, absent, or null values of a field. Perhaps that is more suited for data binding use cases?

Paul.

[1]
    public static Object toUntyped(JsonValue src) {
        Objects.requireNonNull(src);
        return switch (src) {
            case JsonObject(Map<String, JsonValue> members)) -> members.entrySet().stream()
                    .collect(LinkedHashMap::new, // to allow `null` value
                            (m, e) -> m.put(e.getKey(), Json.toUntyped(e.getValue())),
                            HashMap::putAll);
            case JsonArray(List<JsonValue> values)) -> values.stream()
                    .map(Json::toUntyped)
                    .toList();
            case JsonBoolean(boolean value) -> value;
            case JsonNull _ -> null;
            case JsonNumber(Number value) -> value;
            case JsonString(String value) -> value;
        };
    }

On May 19, 2025, at 3:46?PM, Ethan McCue <ethan at mccue.dev> wrote:

What I mean by central in this context isn't that it's at the core of things and features are built on top of it - as you note it is a valid transformation of the hierarchy.

What I mean is that absent other construction/deconstruction apis it is the most convenient avenue for those tasks. So code using the API would trend towards using it. See Remi's usage of fromUntyped elsewhere in the discussion tree.

The thing that the language doesn't have yet is patterns. We have all the mechanism for creating objects. The broad issue I see is that, if we take the view that >in general< deconstruction should be the dual of construction - the mechanics for construction should probably be influenced by how you want people pulling these things apart.

Basic example - JsonString.of - that is null hostile for good reason, but it is very easy to imagine wanting to write code that deals uniformly with absent, null, and string values for a field in an object.

So that puts a pressure - beyond creation ergonomics - on a Json.of that is null-tolerant. Since that would be a good place for a dual pattern for pulling out a possibly nullable object member.

(but still wouldn't solve for absent ones - I have a doc somewhere with like 15 options none of which inspire joy and many of which are conditional on exactly how patterns ship)

On Mon, May 19, 2025, 3:55?PM Paul Sandoz <paul.sandoz at oracle.com<mailto:paul.sandoz at oracle.com>> wrote:

>
> This is part of why fromUntyped/toUntyped is uncomfortable - it's choosing one particular encoding of JSON and making it central to the API. Is that really the most important encoding?
>


It's one opinionated kind, a simple bi-directional mapping (embedding-projection pair) based on what the json values contain. The implementations can be entirely written less than 100 lines of code using the public API (there are more lines for the documentation). Users can easily write their own and can serve as an example with a bit more exposition in the documentation. The methods could be removed and it would not affect anything else, so it's not fundamental nor central.

Paul.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250520/b91d0ae7/attachment-0001.htm>

From bpb at openjdk.org  Tue May 20 15:53:16 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 20 May 2025 15:53:16 GMT
Subject: Integrated: 8355954: File.delete removes read-only files (win)
In-Reply-To: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
References: <AfQLQ9E8sMDzvQyJDKocAS9synyLiWeJyq4YVv48-jQ=.10cd7afb-ab80-4e13-899d-f21873942e28@github.com>
Message-ID: <NsWf-KhdN_H1rHFkNRIEc5TpeiSviGWODN7XWprOZIE=.f708495c-7681-46e5-94b5-f98f34e82f91@github.com>

On Wed, 30 Apr 2025 23:38:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired.

This pull request has now been integrated.

Changeset: bcf5cd69
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bcf5cd69413abd95bf7c3a0249fe1c9b713c85a6
Stats:     132 lines in 5 files changed: 106 ins; 4 del; 22 mod

8355954: File.delete removes read-only files (win)

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/24977

From duke at openjdk.org  Tue May 20 15:53:17 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 20 May 2025 15:53:17 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v12]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <WYr3Oz68WllgtHu9J3sHrDS1jgUx3869Yhqe03dhnyY=.fd9ea764-4b59-4d19-9809-75bf16217214@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Removed redundant code for choosing division's algorithm logic"
  
  This reverts commit 7a0b0211c658014f8c3736f6032e7d3ef35fb820.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/7a0b0211..8c4587bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=10-11

  Stats: 72 lines in 1 file changed: 69 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From jpai at openjdk.org  Tue May 20 15:56:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 May 2025 15:56:02 GMT
Subject: RFR: 8357063: Document preconditions for DecimalDigits methods
 [v4]
In-Reply-To: <pFjJy7Omzm3w-dzls5Ja0EkyCVbs0fd9MNJS_-excic=.6ffd8c75-350f-4ccc-b067-dd7ee3a38e43@github.com>
References: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
 <pFjJy7Omzm3w-dzls5Ja0EkyCVbs0fd9MNJS_-excic=.6ffd8c75-350f-4ccc-b067-dd7ee3a38e43@github.com>
Message-ID: <cj8rvdCqhDrwLctpmus9Z959uqCcXypPwgJDLvEHpNM=.0b3ca71a-ff94-4671-8309-e34afbed9ca4@github.com>

On Fri, 16 May 2025 16:10:29 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Similar to PR #24982 
>> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   warning

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 348:

> 346:      */
> 347:     public static int getChars(long i, int index, char[] buf) {
> 348:         // Used by trusted callers.  Assumes all necessary bounds checks have been done by the caller.

Hello Shaojin, I think this was a misplaced comment previously. Looking at the implementation of this method, there's no "unsafe" access happening in this method's implementation. It ends up calling `putChar` which does a Java style array access and thus is backed by the language's bounds checking.

Removing this comment I believe is the right thing. Having said that, I am unsure the javadoc comment of this method should refer to `DecimalDigits#uncheckedGetCharsUTF16` because that is confusing and misleading.

Should we change the javadoc text of this method to:

> Places characters representing the long i into the character array buf. The characters are placed into the buffer backwards starting with the least significant digit at the specified index (exclusive), and working backwards from there.

Would that accurately describe what this method's implementation currently does?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2098328985

From lancea at openjdk.org  Tue May 20 16:07:57 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 May 2025 16:07:57 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
Message-ID: <tS9_tBI1KCYr4Z4NS2IrniR-gGG2Gat9z2S1-Rt_Wmc=.0123a91e-3a05-4b7e-bef0-c18aa0eed8b3@github.com>

On Sat, 17 May 2025 01:27:38 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedback

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 285:

> 283: \                             versions.\n\
> 284: \                             Warn if there are duplicate or invalid file names
> 285: 

Would probably be clearer if:

> main.help.opt.main.validate=\
> \      --validate             Validate the contents of the jar archive. This option: \n\
> \                              - Validates that the API exported by a multi-release\n\
> \                                 jar archive is consistent across all different release\n\
> \                                 versions.`
> \                              - Issues a warning if there are invalid or duplicate file names
>

src/jdk.jartool/share/man/jar.md line 222:

> 220: ## Integrity of a jar Archive
> 221: As a jar archive is based on ZIP format, it is possible to create a jar archive using tools
> 222: other than the `jar` command. The `--validate` option performs the following integrity checks:

I would  simplify to:

The `--validate` option  may be used to perform the following integrity checks against a jar archive:

src/jdk.jartool/share/man/jar.md line 239:

> 237: 
> 238: Check with the developer to ensure the jar archive integrity when warnings observed after using
> 239: the `--validate` option.

I don't see a need for this last sentence given the last sentence in the paragraph above.

I would not know who "the developer" is (though the same could be said of "the original source of the jar file"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098323828
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098341490
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098346535

From duke at openjdk.org  Tue May 20 16:16:43 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 20 May 2025 16:16:43 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v13]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <xJyoauute7BbwKTO4Sr9U6JqsHy0YWF7hdfprqKERBU=.de7b8dcb-a7a9-4ae6-a321-3b005240646e@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Small code simplifications

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/8c4587bf..d6b4d2e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=11-12

  Stats: 15 lines in 1 file changed: 0 ins; 5 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From swen at openjdk.org  Tue May 20 16:22:58 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 20 May 2025 16:22:58 GMT
Subject: RFR: 8357063: Document preconditions for DecimalDigits methods
 [v4]
In-Reply-To: <cj8rvdCqhDrwLctpmus9Z959uqCcXypPwgJDLvEHpNM=.0b3ca71a-ff94-4671-8309-e34afbed9ca4@github.com>
References: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
 <pFjJy7Omzm3w-dzls5Ja0EkyCVbs0fd9MNJS_-excic=.6ffd8c75-350f-4ccc-b067-dd7ee3a38e43@github.com>
 <cj8rvdCqhDrwLctpmus9Z959uqCcXypPwgJDLvEHpNM=.0b3ca71a-ff94-4671-8309-e34afbed9ca4@github.com>
Message-ID: <9so71TcpEGWXLnsBLZmWHPhmg3-9doY9YgsbUoce02c=.ed9cfb78-3edf-4ff1-91cc-22a7b747de27@github.com>

On Tue, 20 May 2025 15:53:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   warning
>
> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 348:
> 
>> 346:      */
>> 347:     public static int getChars(long i, int index, char[] buf) {
>> 348:         // Used by trusted callers.  Assumes all necessary bounds checks have been done by the caller.
> 
> Hello Shaojin, I think this was a misplaced comment previously. Looking at the implementation of this method, there's no "unsafe" access happening in this method's implementation. It ends up calling `putChar` which does a Java style array access and thus is backed by the language's bounds checking.
> 
> Removing this comment I believe is the right thing. Having said that, I am unsure the javadoc comment of this method should refer to `DecimalDigits#uncheckedGetCharsUTF16` because that is confusing and misleading.
> 
> Should we change the javadoc text of this method to:
> 
>> Places characters representing the long i into the character array buf. The characters are placed into the buffer backwards starting with the least significant digit at the specified index (exclusive), and working backwards from there.
> 
> Would that accurately describe what this method's implementation currently does?

This method has the same algorithm as uncheckedGetCharsUTF16, the only difference is the safe array access of char[] and the unsafe access of byte[] by uncheckedPutPairUTF16. 

This method was also copied from uncheckedGetCharsUTF16 and then modified when the code was written, so I think the reference here is OK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25246#discussion_r2098387154

From duke at openjdk.org  Tue May 20 16:41:08 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 20 May 2025 16:41:08 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v14]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <JlHR6Os-_n8LhhSTH5wGYMJmMYTNfXL0cPjixSzDqtQ=.36fd5ead-66a2-4243-88d4-667b319af63f@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Avoid redundance of stripLeadingZeroInts()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/d6b4d2e1..f3ef2601

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=12-13

  Stats: 31 lines in 1 file changed: 0 ins; 14 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From asemenyuk at openjdk.org  Tue May 20 16:44:54 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 20 May 2025 16:44:54 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles
In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
Message-ID: <v4vRW6uWpa5qS50WACawSF15CS04QyzJQrZZ1h8pbko=.aa0ff2df-3472-4323-830e-6789d135267c@github.com>

On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Fixed jpackage to produce valid Java runtimes based on description below:
> 
> Definitions:
> 
> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
> - JDK image defined as content of "Contents/Home".
> - Signed JDK image does not exist, since it cannot be signed as bundle.
> 
> jpackage output based on input:
> 
> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
> 
> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>  
> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
> 
> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
> 
> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>  - jpackage will check for libjli.dylib presence in "lib" folder.
>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
> - Ad-hoc signing will done.
> 
> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
> - 2 first steps from 5 and certificate signing will be done.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java line 246:

> 244: 
> 245:     public static String getPropertyFromFile(Path filename, String name) {
> 246:         // load properties file

That is a bad idea to expose jpackage API that uses jpackage's Log class. Where will these log messages go?

src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java line 251:

> 249:             properties.load(reader);
> 250:         } catch (IOException e) {
> 251:             Log.error("Exception: " + e.getMessage());

This is an exception swallow, not good. Logging it in place doesn't make it right. If this is an unrecoverable error, it should be forwarded to the caller.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2098429635
PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2098434269

From asemenyuk at openjdk.org  Tue May 20 16:38:54 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 20 May 2025 16:38:54 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles
In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
Message-ID: <Cn6MvOJe_p4bXVBdIXbmpHZWaLK2XYfnr2OKGq7S3bQ=.6c443ead-c4c7-4c35-8d86-b2e6a9bf9c1e@github.com>

On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Fixed jpackage to produce valid Java runtimes based on description below:
> 
> Definitions:
> 
> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
> - JDK image defined as content of "Contents/Home".
> - Signed JDK image does not exist, since it cannot be signed as bundle.
> 
> jpackage output based on input:
> 
> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
> 
> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>  
> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
> 
> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
> 
> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>  - jpackage will check for libjli.dylib presence in "lib" folder.
>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
> - Ad-hoc signing will done.
> 
> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
> - 2 first steps from 5 and certificate signing will be done.

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties line 45:

> 43: resource.app-info-plist=Application Info.plist
> 44: resource.runtime-info-plist=Java Runtime Info.plist
> 45: resource.runtime-image-info-plist=Java Runtime Bundle Info.plist

`resource.runtime-bundle-info-plist` would be a better name as the list file belongs to a bundle, not the image.

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties line 88:

> 86: message.codesign.failed.reason.xcode.tools=Possible reason for "codesign" failure is missing Xcode with command line developer tools. Install Xcode with command line developer tools to see if it resolves the problem.
> 87: message.runtime-image-invalid=Provided runtime image at "{0}" is invalid or corrupted.
> 88: message.runtime-image-invalid.advice=Runtime image should be valid JDK bundle or JDK image.

We need negative test cases for these new error conditions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2098422966
PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2098425687

From asemenyuk at openjdk.org  Tue May 20 16:56:58 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 20 May 2025 16:56:58 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps
In-Reply-To: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
Message-ID: <2GLmGAWCUplxhAeiwVfOKzXw_RDZQedXbgK3lqdzAfw=.730af4f3-4506-43ad-9379-b8d3d380dae5@github.com>

On Fri, 14 Feb 2025 15:01:35 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space
> 
> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372

Changes requested by asemenyuk (Reviewer).

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties line 298:

> 296: \  --linux-menu-group <menu-group-name>\n\
> 297: \          Menu group this application is placed in\n\
> 298: \  --linux-package-deps <package-dep>[, <package-dep>...]\n\

The value of this CLI option is a string, not a comma-separated string list. For jpackage it is a "pass through" value.
Maybe

--linux-package-deps <package-dep-string>\n\

?

-------------

PR Review: https://git.openjdk.org/jdk/pull/23638#pullrequestreview-2816429421
PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2074396184

From henryjen at openjdk.org  Tue May 20 16:57:56 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 20 May 2025 16:57:56 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
Message-ID: <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>

On Sat, 17 May 2025 01:27:38 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedback

src/jdk.jartool/share/man/jar.md line 235:

> 233: 
> 234: The jar tool will return a status code of 0 if there were no integrity issues encountered and a
> 235: status code of 1 an issue was found. When an integrity issue is reported, it will often require

I am wondering if we should not explicitly said status code of 1 to be more flexible.
s/status code of 1/non-zero status code

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098459726

From asemenyuk at openjdk.org  Tue May 20 16:59:50 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 20 May 2025 16:59:50 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles
In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
Message-ID: <GWT43lOFTJQMTuyPCpjDsTdCUX1CrrwtonynMMyWM9U=.7d5e2ae4-f5b0-4323-bf69-4f39c9e25745@github.com>

On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Fixed jpackage to produce valid Java runtimes based on description below:
> 
> Definitions:
> 
> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
> - JDK image defined as content of "Contents/Home".
> - Signed JDK image does not exist, since it cannot be signed as bundle.
> 
> jpackage output based on input:
> 
> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
> 
> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>  
> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
> 
> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
> 
> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>  - jpackage will check for libjli.dylib presence in "lib" folder.
>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
> - Ad-hoc signing will done.
> 
> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
> - 2 first steps from 5 and certificate signing will be done.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java line 199:

> 197:                         }
> 198:                         return version;
> 199:                     },

I guess, this is a workaround for the case when the version comes from JDK's release file. This is the wrong place for this workaround. It should be a part of the code reading version from JDK's release file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2098462753

From asemenyuk at openjdk.org  Tue May 20 17:02:53 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 20 May 2025 17:02:53 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles
In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
Message-ID: <GpnSmeYJ-sLbVqmV85mlWYoeOmptre9JDCvJJViifBk=.8b448182-b149-413f-a401-8624c6916180@github.com>

On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Fixed jpackage to produce valid Java runtimes based on description below:
> 
> Definitions:
> 
> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
> - JDK image defined as content of "Contents/Home".
> - Signed JDK image does not exist, since it cannot be signed as bundle.
> 
> jpackage output based on input:
> 
> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
> 
> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>  
> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
> 
> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
> 
> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>  - jpackage will check for libjli.dylib presence in "lib" folder.
>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
> - Ad-hoc signing will done.
> 
> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
> - 2 first steps from 5 and certificate signing will be done.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 1004:

> 1002:             // External runtime image should be R/O unless it is on macOS.
> 1003:             // On macOS it will be signed ad-hoc or with real certificate.
> 1004:             return !TKit.isOSX();

Should be

return !(TKit.isOSX() && MacHelper.signPredefinedAppImage(cmd));


Otherwise, it will be turned off for macOS entirely.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2098467190

From duke at openjdk.org  Tue May 20 17:04:24 2025
From: duke at openjdk.org (kieran-farrell)
Date: Tue, 20 May 2025 17:04:24 GMT
Subject: RFR: 8347027: String replaceAll with Function<String, String>
Message-ID: <j54JsESf9b6YB14jeAx9nBktIQC0f3C6R7pbUWYYshU=.b0ec838f-6b1e-4bcb-ae3e-6890ab7bc2b7@github.com>

New API to the String.java class - replaceAllMapped(String, Function<MatchResult, String>) that allows regex based replacement via a user defined function allowing dynamic replacemnt based on the match. It delegates to the already existing Pattern.matcher().replaceAll(Function).

-------------

Commit messages:
 - whitespace
 - updates
 - replaceAllMapped and test

Changes: https://git.openjdk.org/jdk/pull/25335/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25335&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347027
  Stats: 61 lines in 3 files changed: 61 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25335.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25335/head:pull/25335

PR: https://git.openjdk.org/jdk/pull/25335

From asemenyuk at openjdk.org  Tue May 20 17:08:59 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 20 May 2025 17:08:59 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles
In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
Message-ID: <1xpPgU-jZVXZaBrp0A7CSqzSSNt8GqgoAvnp3tcLt_g=.8e7cd068-407f-442e-a596-0a9f6f3d4d9f@github.com>

On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Fixed jpackage to produce valid Java runtimes based on description below:
> 
> Definitions:
> 
> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
> - JDK image defined as content of "Contents/Home".
> - Signed JDK image does not exist, since it cannot be signed as bundle.
> 
> jpackage output based on input:
> 
> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
> 
> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>  
> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
> 
> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
> 
> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>  - jpackage will check for libjli.dylib presence in "lib" folder.
>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
> - Ad-hoc signing will done.
> 
> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
> - 2 first steps from 5 and certificate signing will be done.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java line 337:

> 335:         }
> 336: 
> 337:         return installLocation.resolve(cmd.name() + (cmd.isRuntime() ? ".jdk" : ".app"));

Why the ".jdk" suffix and not ".app"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2098475988

From duke at openjdk.org  Tue May 20 17:12:08 2025
From: duke at openjdk.org (kieran-farrell)
Date: Tue, 20 May 2025 17:12:08 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v3]
In-Reply-To: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
Message-ID: <gN7ennufo5CWbUiIfn4mTKQ0-utdvn7S-TjQxWTLmvw=.2318b708-2199-4213-9d6b-d1b8392821cf@github.com>

> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
> 
> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
> 
> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
> 
> 
> - random-byte-only - 99.8%
> - higher-precision - 3.5%
> - counter-based - 0%
> 
> 
> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
> 
> - random-byte-only   143.487 ? 10.932  ns/op
> - higher-precision      149.651 ?  8.438 ns/op
> - counter-based         245.036 ?  2.943  ns/op
> 
> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.

kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/util/UUID.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25303/files
  - new: https://git.openjdk.org/jdk/pull/25303/files/922869b3..c7efd528

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303

PR: https://git.openjdk.org/jdk/pull/25303

From duke at openjdk.org  Tue May 20 17:15:15 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 20 May 2025 17:15:15 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v15]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <U__x_G1v6K81G3BBnlAPpdUNhUTfNwQEXaYnoy9oitA=.f63bd8af-66fc-4fcd-905f-666fa155b8b4@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Simplify two's complement in makePositive(int[])

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/f3ef2601..69d24210

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=13-14

  Stats: 15 lines in 1 file changed: 5 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From fweimer at redhat.com  Tue May 20 17:16:33 2025
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 20 May 2025 19:16:33 +0200
Subject: Towards a JSON API for the JDK
In-Reply-To: <a5db35c2-800d-4b4a-99f4-91a47008aaac@oracle.com> (Brian Goetz's
 message of "Fri, 16 May 2025 09:17:16 -0400")
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1479048606.266979740.1747344477147.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gt3GNjDPS2m-2wha5AwgumMvBRxKw+bwgTCNQ1xCiDfg@mail.gmail.com>
 <b0e7ff8e-f6dc-48b1-ad0f-5de52d8191b3@apache.org>
 <a5db35c2-800d-4b4a-99f4-91a47008aaac@oracle.com>
Message-ID: <87tt5f5hji.fsf@oldenburg.str.redhat.com>

* Brian Goetz:

> But then we discovered that JSON5 also sneaks in some semantics, by
> also supporting the exotic numeric values (NaN, infinities, signed
> zero), which now has consequences for "what is a number", the numeric
> representation, the API for unpacking numeric values, etc.  (Having
> multiple parsers is one thing; having multiple parsers that produce
> different semantics is entirely another.)

But that's independent of JSON5: some data sources expected their
numbers to be parsed as integers that require more than 53 bits to
represent.  That means double as the universal numerical type is out.
BigDecimal would work, but may result in unexpected overhead.

Thanks,
Florian


From jlu at openjdk.org  Tue May 20 17:19:32 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 20 May 2025 17:19:32 GMT
Subject: RFR: 8357275: Locale.Builder.setLanguageTag should explicitly
 state extlangs are allowed [v2]
In-Reply-To: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
Message-ID: <hmWGxITz4VOuIknq6n8_eTaUdQnvG-P00eAC4a2oKMI=.bf67fede-75c5-46a1-8791-ebecb4a832ba@github.com>

> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  setLanguageTag should mention all conversions, not just extlang

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25309/files
  - new: https://git.openjdk.org/jdk/pull/25309/files/204338ae..2d70bf79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25309&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25309&range=00-01

  Stats: 7 lines in 1 file changed: 2 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25309.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25309/head:pull/25309

PR: https://git.openjdk.org/jdk/pull/25309

From jlu at openjdk.org  Tue May 20 17:19:32 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 20 May 2025 17:19:32 GMT
Subject: RFR: 8357275: Locale.Builder.setLanguageTag should explicitly
 state extlangs are allowed [v2]
In-Reply-To: <JAXXxlfm30nkxcWaP69ToMTy-u-zT2B0UU7XsxFMZCw=.41f9f8f1-e728-4755-9b76-1a1c18f07641@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
 <QUtJwLbVsoGtCyv848P1vvnFfEgiFmZ34masOOPmJyM=.afc55604-b3ac-4cd1-b2b6-3ff2158d2992@github.com>
 <yO0NeGsCmo4vIPU3ioLORjTJ3IgK9cjutuR_H2CII7M=.2674da7f-406c-453f-bb1a-e333bebf1b5d@github.com>
 <JAXXxlfm30nkxcWaP69ToMTy-u-zT2B0UU7XsxFMZCw=.41f9f8f1-e728-4755-9b76-1a1c18f07641@github.com>
Message-ID: <BTJXyclR7mduiJ0I7HsRVqH5duEDmw7ebw2PS7wEblo=.4d8de939-0da5-46c9-b377-8c206b528e02@github.com>

On Tue, 20 May 2025 00:39:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> An exception is thrown when more than three extlang subtags are provided (ill-formed). The new wording is when an allowed amount of extlang subtags are provided (not ill-formed). For example,
>> 
>> `new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-czh-CN").build()` // throws
>> `new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-CN").build()` // ==> yue_CN
>> 
>> i.e. if one to three extlang subtags occur, discard extras. If more than 3 occur, then it is ill-formed, and the method is already specified to throw on ill-formed tags. (Edit: Forgot to adjust the example)
>
> OK. I would add these examples here too, which may be more helpful.

Actually, `Locale.Builder.setLanguageTag` should mention all of the conversions that are made on the language tag, not just _extlang_ specifically. I'll link to the conversions section in `Locale.forLanguageTag` instead.
I also adjusted the _extlang_ example in `forLanguageTag` to indicate that the 4 _extlang_ example is "ill-formed" which should imply `Locale.Builder.setLanguageTag` throws an exception for that respective example.

Please see https://github.com/openjdk/jdk/pull/25309/commits/2d70bf799ba1285d599067c3d174dd8bd227db1f.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2098491604

From asemenyuk at openjdk.org  Tue May 20 17:20:52 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 20 May 2025 17:20:52 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles
In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
Message-ID: <TDrb1cmDZ1YaWu9kIu1jR2UVCjYKr__VUGaFd6pRu2I=.fb55c85d-eb2c-4503-86dd-9fb1a929839b@github.com>

On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Fixed jpackage to produce valid Java runtimes based on description below:
> 
> Definitions:
> 
> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
> - JDK image defined as content of "Contents/Home".
> - Signed JDK image does not exist, since it cannot be signed as bundle.
> 
> jpackage output based on input:
> 
> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
> 
> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>  
> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
> 
> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
> 
> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>  - jpackage will check for libjli.dylib presence in "lib" folder.
>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
> - Ad-hoc signing will done.
> 
> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
> - 2 first steps from 5 and certificate signing will be done.

The description is missing some important changes:
 - jpackage will attempt to get a package version from the JDK's release file if the `--version` option is not specified.
 - The bundle's top directory name will have the ".jdk" suffix.

I like the idea of reading the package's version from the JDK's release file when bundling a runtime package, but it is out of the scope of the "jpackage produces invalid Java runtime DMG bundles" fix. It should be a separate fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25314#issuecomment-2895251471

From henryjen at openjdk.org  Tue May 20 17:32:15 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 20 May 2025 17:32:15 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v10]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <ZOjTb3XvEzR6RtDdwt1tWswMPOgFs9_xp_tmieHdIyk=.8c5ac78d-ccae-40fd-8823-2e56914ed042@github.com>

> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Adapt review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/da4a9139..0caecfcd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=08-09

  Stats: 12 lines in 2 files changed: 2 ins; 2 del; 8 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 bpb at openjdk.org  Tue May 20 17:35:14 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 20 May 2025 17:35:14 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v24]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: <g3Jkn3xaPYQC0fBjgZZ0Kg0VhDcqCbI52u4LNCPRaZY=.343b45d8-aa5a-4e6d-b22e-6b6c353fce06@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: Revert previous commit and remove first comma in the change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/a86610d0..0880af29

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=22-23

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From bpb at openjdk.org  Tue May 20 17:35:14 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 20 May 2025 17:35:14 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <8SJl_mDv3MuJGgTfW3pc4adoVxHpbwVyPEgD0n2nguM=.d9845fcc-cf54-46e8-b2af-a2ce16f4b991@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <XhhlO7kp9gHxAH8FtiI7By4_KixYmqbDr6kKCbTmtXE=.afcdff58-ff7f-4ae8-9e2a-fb7153732125@github.com>
 <OFzwCUP8551ajdWuUCOGE3LM3aZ-niEocXo7couS1m0=.5113cf96-1d25-4efc-9c23-930b72330205@github.com>
 <uJD3_543RevQ83bhjZPKw4xLAHjPayk6TaF9_cbtDis=.4d22f0a0-250b-40e3-936c-fe45a6e31dd4@github.com>
 <8SJl_mDv3MuJGgTfW3pc4adoVxHpbwVyPEgD0n2nguM=.d9845fcc-cf54-46e8-b2af-a2ce16f4b991@github.com>
Message-ID: <NsUi0hSmRQuCsoexmT1aKMxirrIFmsjpdFQPV_6Dkm4=.58814ece-14ce-435a-a1c1-04a541ce3539@github.com>

On Mon, 19 May 2025 07:15:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thank you Brian, the updated text for this section looks good to me. Once this PR gets integrated, I'll go through the Files.readXXX methods and file an issue to have that text simplified too.
>
> I see this has been changed to  "then some characters, but not all" but it doesn't flow very well. The original sentence, which was copied/modified from InputStream.readAllBytes, is much cleaner and I think I would prefer to go back to that.  Maybe Jai's issue could be address by dropping the first comma from the sentence?

In 0880af2 reverted previous commit then removed first comma from the modified sentence.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2098520689

From duke at openjdk.org  Tue May 20 17:41:14 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 20 May 2025 17:41:14 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v16]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <fOeTUoyubkQMEDrUM99H1UHGZjRFBOHOiE5G6BymhhM=.c2f1d23f-8c83-4744-af2c-683fa8d7ec76@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Some code simplifications for *ValueExact()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/69d24210..9a8678bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=14-15

  Stats: 19 lines in 1 file changed: 0 ins; 6 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From duke at openjdk.org  Tue May 20 17:52:32 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 20 May 2025 17:52:32 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v17]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <ojJpqJ3WoJc6Ck8808znzYLWI7fQ35gAuyM20WsOOpA=.114e00a3-e0d3-4f4a-b1d6-26a7ba787f1c@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Use bitwise or instead of + in longValue()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/9a8678bf..1fa0c9e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=15-16

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From duke at openjdk.org  Tue May 20 18:02:10 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 20 May 2025 18:02:10 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v18]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <_LFzlaMFEaJO4FzFpS11uyZev2ReP34ii2QSa-Pn1rU=.456015bc-d718-4c00-9510-5e3d7836c51e@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  A minor change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/1fa0c9e0..46114836

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=16-17

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From lancea at openjdk.org  Tue May 20 18:03:54 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 May 2025 18:03:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
 <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
Message-ID: <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>

On Tue, 20 May 2025 16:55:44 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> I am wondering if we should not explicitly said status code of 1 to be more flexible. s/status code of 1/non-zero status code

Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098574945

From rgiulietti at openjdk.org  Tue May 20 18:05:55 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 20 May 2025 18:05:55 GMT
Subject: RFR: 8356891: Some code simplifications for basic BigIntegers' bit
 operations [v6]
In-Reply-To: <_7_Cbd9Yq1qPpOWvVIz7ROCzvrHwHPmDjbCS_wBtGUo=.badca150-12bb-4b98-b795-31699efcc947@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <Fe1FcysTPgZYA1aEUGFHRfBxnQ_QkYXJ-4it0QscrS8=.7c1fa510-c570-481c-aa40-5cca05667f34@github.com>
 <hoQilPfsm719vv9gOH4kkZVdLoTONdoWfOA0XK1FPHg=.bef64c99-7b68-40a7-b570-68700336de11@github.com>
 <_7_Cbd9Yq1qPpOWvVIz7ROCzvrHwHPmDjbCS_wBtGUo=.badca150-12bb-4b98-b795-31699efcc947@github.com>
Message-ID: <AIDq23Uo4xBKyGdG1CLa_cXIS4ggEWWFG2-ARiw3cnI=.69313050-1e38-46af-a3b5-622bc5481b78@github.com>

On Fri, 16 May 2025 10:10:28 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you please crosscheck?
>
>> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you please crosscheck?
> 
> @rgiulietti  It seems there is a slowdown in the creation of large pseudoprimes, maybe due to `BitSieve` methods.

@fabioromano1 Please either restrict the changes to "bit operations", like the subject of this PR, or else change the title to something more encompassing, like "8356891: Some code simplifications in BigInteger".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25166#issuecomment-2895364988

From henryjen at openjdk.org  Tue May 20 18:16:56 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 20 May 2025 18:16:56 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
 <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
 <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>
Message-ID: <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com>

On Tue, 20 May 2025 18:00:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/jdk.jartool/share/man/jar.md line 235:
>> 
>>> 233: 
>>> 234: The jar tool will return a status code of 0 if there were no integrity issues encountered and a
>>> 235: status code of 1 an issue was found. When an integrity issue is reported, it will often require
>> 
>> I am wondering if we should not explicitly said status code of 1 to be more flexible.
>> s/status code of 1/non-zero status code
>
>> I am wondering if we should not explicitly said status code of 1 to be more flexible. s/status code of 1/non-zero status code
> 
> Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc...

We report all issues, not just one, so that would also involve what do we prioritized for the exit code...
In general, a non-zero code for invalid jar needs attention. We still 0 with unmatched order.
Also the process could fail with other issues like I/O or non-zip file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098596892

From lancea at openjdk.org  Tue May 20 18:33:53 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 May 2025 18:33:53 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
 <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
 <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>
 <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com>
Message-ID: <PphfDWen7gKIUoGPV2NnZ2M7_LB47Rd2VmpzTnKDpGk=.5415e56a-eb35-4c65-bca5-692457061f11@github.com>

On Tue, 20 May 2025 18:14:15 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>>> I am wondering if we should not explicitly said status code of 1 to be more flexible. s/status code of 1/non-zero status code
>> 
>> Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc...
>
> We report all issues, not just one, so that would also involve what do we prioritized for the exit code...
> In general, a non-zero code for invalid jar needs attention. We still 0 with unmatched order.
> Also the process could fail with other issues like I/O or non-zip file.

Yes I understand and currently we have no documentation as to what the return values might be.  An inconsistency in the order should also be 1 based we only return a 0 if there are no issues.  Any warning should be treated the same

My point is that it is worth considering with these changes

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098625246

From vlivanov at openjdk.org  Tue May 20 18:45:56 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 20 May 2025 18:45:56 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v6]
In-Reply-To: <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com>
Message-ID: <ymq-cS14PaC1PpdKAzAZJwxdwtVTbSZtT-LNC21lW6Q=.f956592a-fd59-4bb5-a485-f4138942d290@github.com>

On Fri, 9 May 2025 15:59:38 GMT, Kim Barrett <kbarrett at openjdk.org> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into native-reference-get
>  - use new waitForRefProc, some tidying
>  - Merge branch 'master' into native-reference-get
>  - remove timeout by using waitForReferenceProcessing
>  - make ill-timed gc in non-concurrent case less likely
>  - fix test package use
>  - add package decl to test
>  - parameterized return type of native get0
>  - test native method
>  - native Reference.get helper

Overall, looks good.

src/java.base/share/classes/java/lang/ref/Reference.java line 366:

> 364: 
> 365:     /* Implementation of unintrinsified get().  Making get() native may lead
> 366:      * C2 to sometimes prefer the native implementation over the intrinsic.

Can you share more details on this?

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24315#pullrequestreview-2855249526
PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2098645006

From paul.sandoz at oracle.com  Tue May 20 18:49:02 2025
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 20 May 2025 18:49:02 +0000
Subject: Towards a JSON API for the JDK
In-Reply-To: <CAGZD2TAbv+dQQJCTbpQqa3LVFB90vqBZ-9sbcynAZpOE32bxag@mail.gmail.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
 <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
 <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>
 <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com>
 <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr>
 <CAGZD2TAbv+dQQJCTbpQqa3LVFB90vqBZ-9sbcynAZpOE32bxag@mail.gmail.com>
Message-ID: <CB7705F0-77B5-4119-BB77-D05D87B270F5@oracle.com>

JEP 198 will likely be withdrawn and a new JEP will be drafted aligned with the document sent in this email thread.

It?s a not a goal to solve the dependency problem (a very hard problem!) even in a narrow sense.

A potential advantage that we (the OpenJDK community) can more easily do is devise an API that resonates with direction the Java platform is heading, specifically around the pattern matching and serialization 2.0, and potentially so with further out features. This has a number of advantages:

1. It should enable us to devise a simpler API that naturally gains more power as it is used in combination with those features;
2. It provides feedback to those features and perhaps the other way around too; and
3. It provides a template for others to copy in their own libraries.

Paul.

> On May 20, 2025, at 12:53?AM, Swaranga Sarma <sarma.swaranga at gmail.com> wrote:
> 
> Hello, I am not a language or a library developer by any means but I wanted to offer my perspective as a prospective user of such an API. 
> 
> I am sure this was considered but feel compelled to raise it regardless - instead of the low level tree API (and baking whatever design choice is made forever into the JDK), was a higher level data binding API considered while keeping any low-level tree implementation private to the JDK? Basically a way to take a Json document (String/Reader/...) and deserialize it into an instance of a user-defined Record (and vice versa). From my perspective, this would be a more useful addition for the simpler and most common cases and if there are more complex requirements around flexibility/performance then there are lots of 3rd party options available in Java. I do not have data to back my hunch that this will be more valuable but I am offering my real production use-case where I would find it useful: 
> 
> I have a bunch of rest APIs for which my callers want me to vend a Java client that has the Java POJO classes for the request and response shapes; they don't want to write it by hand which is a reasonable ask. I usually create a Java library that uses the standard Java Http client under the hood to make the calls and serialize and deserialize the DTOs using Jackson. The problem is that as soon as I add Jackson to the client library's dependencies, it is no longer a zero-runtime dependency library and the callers have to deal with multiple versions, version incompatibility etc (in case they also use Jackson in the client app). With a Json api with support for data binding in the standard library, I could vend a very thin zero additional dependencies Java client to my callers.
> 
> This is not quite what JEP 198 is stating as its goals but I am also not sure if this discussion is towards an implementation for that JEP.
> 
> Thank you
> Swaranga


From rriggs at openjdk.org  Tue May 20 18:58:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 20 May 2025 18:58:51 GMT
Subject: RFR: 8347027: String replaceAll with Function<String, String>
In-Reply-To: <j54JsESf9b6YB14jeAx9nBktIQC0f3C6R7pbUWYYshU=.b0ec838f-6b1e-4bcb-ae3e-6890ab7bc2b7@github.com>
References: <j54JsESf9b6YB14jeAx9nBktIQC0f3C6R7pbUWYYshU=.b0ec838f-6b1e-4bcb-ae3e-6890ab7bc2b7@github.com>
Message-ID: <w_aLg8VV5PL-r7DdwYseul71ISiMiQa5l6pOCjp1M9M=.21bc704b-8e36-4c2a-9454-5147ceb212c4@github.com>

On Tue, 20 May 2025 16:59:10 GMT, kieran-farrell <duke at openjdk.org> wrote:

> New API to the String.java class - replaceAllMapped(String, Function<MatchResult, String>) that allows regex based replacement via a user defined function allowing dynamic replacemnt based on the match. It delegates to the already existing Pattern.matcher().replaceAll(Function).

Please elaborate on the rationale and use cases. I don't this a compelling API or functionality. Tnx.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25335#issuecomment-2895494882

From rriggs at openjdk.org  Tue May 20 19:01:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 20 May 2025 19:01:54 GMT
Subject: RFR: 8347027: String replaceAll with Function<String, String>
In-Reply-To: <j54JsESf9b6YB14jeAx9nBktIQC0f3C6R7pbUWYYshU=.b0ec838f-6b1e-4bcb-ae3e-6890ab7bc2b7@github.com>
References: <j54JsESf9b6YB14jeAx9nBktIQC0f3C6R7pbUWYYshU=.b0ec838f-6b1e-4bcb-ae3e-6890ab7bc2b7@github.com>
Message-ID: <pAgA_zzz2xStWG4F6J92RjEvFdgV2RsEDpd5JjdUc-Y=.de85fea9-8eb0-4de9-a27d-4e5822ede277@github.com>

On Tue, 20 May 2025 16:59:10 GMT, kieran-farrell <duke at openjdk.org> wrote:

> New API to the String.java class - replaceAllMapped(String, Function<MatchResult, String>) that allows regex based replacement via a user defined function allowing dynamic replacemnt based on the match. It delegates to the already existing Pattern.matcher().replaceAll(Function).

Since its implemented as 1-one function, it doesn't add much value and requires recompiling the regex on each use.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25335#issuecomment-2895499907

From vyazici at openjdk.org  Tue May 20 19:20:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 20 May 2025 19:20:53 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
In-Reply-To: <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
Message-ID: <Pup4nswVBdebz4T4tOR33WuL7iedobsLXh-FjSh4e6E=.7eb43d7b-4c9a-490e-9a1f-168fee7bdf9b@github.com>

On Tue, 20 May 2025 10:40:39 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 160:
> 
>> 158: 
>> 159:             try {
>> 160:                 Terminal terminal = TerminalBuilder.builder().encoding(outCharset)
> 
> Shouldn't ideally `JdkConsole::charset` and `Terminal::encoding` be adapted for stdin/stdout variants?

Also noticed `DumbTerminalProvider::sysTerminal` calls `DumbTerminal` with `new FileInputStream(FileDescriptor.in)`. Later on `DumbTerminal` applies `encoding()` both for passed `stdin` and `std{out,err}`. In short, `TerminalProvider` might need to undergo a similar refactoring separating input and output encodings.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2098698322

From sarma.swaranga at gmail.com  Tue May 20 19:21:47 2025
From: sarma.swaranga at gmail.com (Swaranga Sarma)
Date: Tue, 20 May 2025 12:21:47 -0700
Subject: Towards a JSON API for the JDK
In-Reply-To: <CB7705F0-77B5-4119-BB77-D05D87B270F5@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
 <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
 <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>
 <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com>
 <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr>
 <CAGZD2TAbv+dQQJCTbpQqa3LVFB90vqBZ-9sbcynAZpOE32bxag@mail.gmail.com>
 <CB7705F0-77B5-4119-BB77-D05D87B270F5@oracle.com>
Message-ID: <CAGZD2TDQf8CtDXt0=Qdt50AAb-Ktouq2cA9L33pFCzBTwDEhqA@mail.gmail.com>

> It?s a not a goal to solve the dependency problem (a very hard problem!)
even in a narrow sense.

That was only an example where a data-binding API would be useful - it
wasn't a meant to be the only use-case or even a suggestion that it should
be solved in the general case.

> A potential advantage that we (the OpenJDK community) can more easily do
is devise an API that resonates with direction the Java platform is
heading, specifically around the pattern matching and serialization 2.0

Right, but most of the discussion here seems to be on the low level tree
API and how one might navigate it (perhaps using pattern matching). I am
not seeing any discussion on the serialization/deserialization or any
reasoning why that is not the goal of the new JEP. Basically a very focused
and narrow API:

```
var jsonStr = "..."
var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a few
other variants
var serialized = Json.serialize(myRecord)
```

This leaves the tree API open to reimplementation later when pattern
matching and other features are firmly in place in the JDK. I am making a
case that this would be more immediately useful for the most common and
simpler cases.


Regards
Swaranga


On Tue, May 20, 2025 at 11:49?AM Paul Sandoz <paul.sandoz at oracle.com> wrote:

> JEP 198 will likely be withdrawn and a new JEP will be drafted aligned
> with the document sent in this email thread.
>
> It?s a not a goal to solve the dependency problem (a very hard problem!)
> even in a narrow sense.
>
> A potential advantage that we (the OpenJDK community) can more easily do
> is devise an API that resonates with direction the Java platform is
> heading, specifically around the pattern matching and serialization 2.0,
> and potentially so with further out features. This has a number of
> advantages:
>
> 1. It should enable us to devise a simpler API that naturally gains more
> power as it is used in combination with those features;
> 2. It provides feedback to those features and perhaps the other way around
> too; and
> 3. It provides a template for others to copy in their own libraries.
>
> Paul.
>
> > On May 20, 2025, at 12:53?AM, Swaranga Sarma <sarma.swaranga at gmail.com>
> wrote:
> >
> > Hello, I am not a language or a library developer by any means but I
> wanted to offer my perspective as a prospective user of such an API.
> >
> > I am sure this was considered but feel compelled to raise it regardless
> - instead of the low level tree API (and baking whatever design choice is
> made forever into the JDK), was a higher level data binding API considered
> while keeping any low-level tree implementation private to the JDK?
> Basically a way to take a Json document (String/Reader/...) and deserialize
> it into an instance of a user-defined Record (and vice versa). From my
> perspective, this would be a more useful addition for the simpler and most
> common cases and if there are more complex requirements around
> flexibility/performance then there are lots of 3rd party options available
> in Java. I do not have data to back my hunch that this will be more
> valuable but I am offering my real production use-case where I would find
> it useful:
> >
> > I have a bunch of rest APIs for which my callers want me to vend a Java
> client that has the Java POJO classes for the request and response shapes;
> they don't want to write it by hand which is a reasonable ask. I usually
> create a Java library that uses the standard Java Http client under the
> hood to make the calls and serialize and deserialize the DTOs using
> Jackson. The problem is that as soon as I add Jackson to the client
> library's dependencies, it is no longer a zero-runtime dependency library
> and the callers have to deal with multiple versions, version
> incompatibility etc (in case they also use Jackson in the client app). With
> a Json api with support for data binding in the standard library, I could
> vend a very thin zero additional dependencies Java client to my callers.
> >
> > This is not quite what JEP 198 is stating as its goals but I am also not
> sure if this discussion is towards an implementation for that JEP.
> >
> > Thank you
> > Swaranga
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250520/15125fcc/attachment.htm>

From vyazici at openjdk.org  Tue May 20 19:26:52 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 20 May 2025 19:26:52 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
In-Reply-To: <Pup4nswVBdebz4T4tOR33WuL7iedobsLXh-FjSh4e6E=.7eb43d7b-4c9a-490e-9a1f-168fee7bdf9b@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <Pup4nswVBdebz4T4tOR33WuL7iedobsLXh-FjSh4e6E=.7eb43d7b-4c9a-490e-9a1f-168fee7bdf9b@github.com>
Message-ID: <ogXKGEuLuPNjbiKf2n8GLsIAUAgCqs6alj69rYqGMDU=.c72dc1a5-dfa2-44dc-a808-81162dec14b6@github.com>

On Tue, 20 May 2025 19:18:43 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 160:
>> 
>>> 158: 
>>> 159:             try {
>>> 160:                 Terminal terminal = TerminalBuilder.builder().encoding(outCharset)
>> 
>> Shouldn't ideally `JdkConsole::charset` and `Terminal::encoding` be adapted for stdin/stdout variants?
>
> Also noticed `DumbTerminalProvider::sysTerminal` calls `DumbTerminal` with `new FileInputStream(FileDescriptor.in)`. Later on `DumbTerminal` applies `encoding()` both for passed `stdin` and `std{out,err}`. In short, `TerminalProvider` might need to undergo a similar refactoring separating input and output encodings.

All `FileDescriptor.in` encounters in `jdk.internal.org.jline.terminal` that might need attention:

src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/DumbTerminalProvider.java
src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/exec/ExecPty.java
src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/FfmTerminalProvider.java

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2098707061

From rriggs at openjdk.org  Tue May 20 19:35:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 20 May 2025 19:35:55 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v3]
In-Reply-To: <pD8XqEflVmkHQIAn0enmOXPR3JYRvrC3eR_X0Cm1Jyc=.3bbff99b-b1d0-41d7-992e-1185c8bdc671@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <Jm4ATGoFWP2a8HSBuwAglmdQS5fcBKBxt7TOklUQRjk=.b47ef4c7-26cd-4603-a074-76be89fa898c@github.com>
 <gfboyaqw8NXiohbBi1Q0cWStFPuvXI6RFMUoIMtaJVM=.2c27a47a-dc32-4d5f-b3ba-35dd00f4b106@github.com>
 <pD8XqEflVmkHQIAn0enmOXPR3JYRvrC3eR_X0Cm1Jyc=.3bbff99b-b1d0-41d7-992e-1185c8bdc671@github.com>
Message-ID: <cYhyGDeePCnlPTzDgcRQfCnXQtDoCukifEOa2bvxeuM=.2eb9307c-9926-42de-8a2f-0dd17d69718c@github.com>

On Tue, 20 May 2025 13:56:42 GMT, kieran-farrell <duke at openjdk.org> wrote:

>>> Can the sub-microsecond value just be truncated and avoid the expensive divide operation?'
>> 
>> method 3 of secion 6.2 of https://www.rfc-editor.org/rfc/rfc9562.html#name-monotonicity-and-counters states 
>> 
>>> start with the portion of the timestamp expressed as a fraction of the clock's tick value (fraction of a millisecond for UUIDv7). Compute the count of possible values that can be represented in the available bit space, 4096 for the UUIDv7 rand_a field. Using floating point or scaled integer arithmetic, multiply this fraction of a millisecond value by 4096 and round down (toward zero) to an integer result to arrive at a number between 0 and the maximum allowed for the indicated bits, which sorts monotonically based on time. '
>> 
>> so i think we might have to keep the division? though i re-shuffled the equation to 
>> 
>> `int nsBits = (int) ((nsTime % 1_000_000) / 1_000_000.0 * 4096);`
>> 
>> which gives scaled integer division rather than floating point and gave a very slight imporved perfomance to 143.758 ? 2.135  ns/op
>
>> This could remove the allocation by composing the high and low longs using shifts and binary operations and ng.next().
> 
> do you mean to create the UUID using most and least significant bytes? if so, I've tried out some variations, i found creating the 64 bit lsb with ng.nextLong() brings a large pefomance decrease over using the nextBytes method, but the below implemntation keeping with the nextByte(byte[]) api brings a performance increase to 121.128 ? 30.486  ns/op, though the code might appear a little roundabout.
> 
> 
>     public static UUID timestampUUID() {
>         long msTime = System.currentTimeMillis();
>         long nsTime = System.nanoTime();
> 
>         // Scale sub-ms nanoseconds to a 12-bit value
>         int nsBits = (int) ((nsTime % 1_000_000L) * 4096L / 1_000_000L);
> 
>         // Compose the 64 most significant bits: [48-bit msTime | 4-bit version | 12-bit nsBits]
>         long mostSigBits =
>                 ((msTime & 0xFFFFFFFFFFFFL) << 16) |
>                         (0x7L << 12) |
>                         nsBits;
> 
>         // Generate 8 random bytes for least significant bits
>         byte[] randomBytes = new byte[8];
>         SecureRandom ng = UUID.Holder.numberGenerator;
>         ng.nextBytes(randomBytes);
> 
>         long leastSigBits = 0;
>         for (int i = 0; i < 8; i++) {
>             leastSigBits = (leastSigBits << 8) | (randomBytes[i] & 0xFF);
>         }
> 
>         // Set variant (bits 62?63) to '10'
>         leastSigBits &= 0x3FFFFFFFFFFFFFFFL;
>         leastSigBits |= 0x8000000000000000L;
> 
>         return new UUID(mostSigBits, leastSigBits);
>     }

There's no (time-based) relationship between the currentTimeMillis() value and the nanoTime value.
They are independent clocks and are read separately and are un-correlated. They won't be usable as lsb of the millis value.

I'm surprised that the `nextBytes` is slower, since it looks like it calls `nextLong` and puts it in a newly allocated byte[8].  Normal perf measurements won't account for the gc overhead to recover it.

The nsBits computation looks odd, nanoTme returns nanoseconds (10^9), the remainder (% 1_000_000) is then milliseconds.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2098719719

From duke at openjdk.org  Tue May 20 19:41:59 2025
From: duke at openjdk.org (Philippe Marschall)
Date: Tue, 20 May 2025 19:41:59 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v3]
In-Reply-To: <gN7ennufo5CWbUiIfn4mTKQ0-utdvn7S-TjQxWTLmvw=.2318b708-2199-4213-9d6b-d1b8392821cf@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <gN7ennufo5CWbUiIfn4mTKQ0-utdvn7S-TjQxWTLmvw=.2318b708-2199-4213-9d6b-d1b8392821cf@github.com>
Message-ID: <FxxV0reMyTXmhEpSdRM3M2XIVGOgfbY10eDCGVURMGM=.1e95888c-e706-4add-ac29-810a09e8ebb5@github.com>

On Tue, 20 May 2025 17:12:08 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
>> 
>> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
>> 
>> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
>> 
>> 
>> - random-byte-only - 99.8%
>> - higher-precision - 3.5%
>> - counter-based - 0%
>> 
>> 
>> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
>> 
>> - random-byte-only   143.487 ? 10.932  ns/op
>> - higher-precision      149.651 ?  8.438 ns/op
>> - counter-based         245.036 ?  2.943  ns/op
>> 
>> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.
>
> kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/UUID.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

src/java.base/share/classes/java/util/UUID.java line 200:

> 198:     public static UUID timestampUUID() {
> 199:         long msTime = System.currentTimeMillis();
> 200:         long nsTime = System.nanoTime();

I is my understanding that `System#nanoTime()` does not provide the nanosecond fraction and is not guaranteed to have nanosecond resolution. You'd have to look at `VM#getNanoTimeAdjustment(long)` to get the nanotime adjustment. However the resolution of this is OS dependent, usually microseconds, likely 10 microseconds on Windows.

src/java.base/share/classes/java/util/UUID.java line 203:

> 201:         SecureRandom ng = Holder.numberGenerator;
> 202:         byte[] randomBytes = new byte[16];
> 203:         ng.nextBytes(randomBytes);

It's a bit unfortunate that `SecureRandom#nextBytes(byte[])` does not allow us to pass an offset and length. Here we generate 16 bytes of random data but throw the first 8 bytes away.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2098704776
PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2098708696

From duke at openjdk.org  Tue May 20 19:41:59 2025
From: duke at openjdk.org (Philippe Marschall)
Date: Tue, 20 May 2025 19:41:59 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v3]
In-Reply-To: <cYhyGDeePCnlPTzDgcRQfCnXQtDoCukifEOa2bvxeuM=.2eb9307c-9926-42de-8a2f-0dd17d69718c@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <Jm4ATGoFWP2a8HSBuwAglmdQS5fcBKBxt7TOklUQRjk=.b47ef4c7-26cd-4603-a074-76be89fa898c@github.com>
 <gfboyaqw8NXiohbBi1Q0cWStFPuvXI6RFMUoIMtaJVM=.2c27a47a-dc32-4d5f-b3ba-35dd00f4b106@github.com>
 <pD8XqEflVmkHQIAn0enmOXPR3JYRvrC3eR_X0Cm1Jyc=.3bbff99b-b1d0-41d7-992e-1185c8bdc671@github.com>
 <cYhyGDeePCnlPTzDgcRQfCnXQtDoCukifEOa2bvxeuM=.2eb9307c-9926-42de-8a2f-0dd17d69718c@github.com>
Message-ID: <aeb3sh4-fM8iC0R4xhatMynB7i2VUbZcWTFpOf882ss=.d86cf934-b407-4207-aad1-fc2b468d1cd0@github.com>

On Tue, 20 May 2025 19:32:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> This could remove the allocation by composing the high and low longs using shifts and binary operations and ng.next().
>> 
>> do you mean to create the UUID using most and least significant bytes? if so, I've tried out some variations, i found creating the 64 bit lsb with ng.nextLong() brings a large pefomance decrease over using the nextBytes method, but the below implemntation keeping with the nextByte(byte[]) api brings a performance increase to 121.128 ? 30.486  ns/op, though the code might appear a little roundabout.
>> 
>> 
>>     public static UUID timestampUUID() {
>>         long msTime = System.currentTimeMillis();
>>         long nsTime = System.nanoTime();
>> 
>>         // Scale sub-ms nanoseconds to a 12-bit value
>>         int nsBits = (int) ((nsTime % 1_000_000L) * 4096L / 1_000_000L);
>> 
>>         // Compose the 64 most significant bits: [48-bit msTime | 4-bit version | 12-bit nsBits]
>>         long mostSigBits =
>>                 ((msTime & 0xFFFFFFFFFFFFL) << 16) |
>>                         (0x7L << 12) |
>>                         nsBits;
>> 
>>         // Generate 8 random bytes for least significant bits
>>         byte[] randomBytes = new byte[8];
>>         SecureRandom ng = UUID.Holder.numberGenerator;
>>         ng.nextBytes(randomBytes);
>> 
>>         long leastSigBits = 0;
>>         for (int i = 0; i < 8; i++) {
>>             leastSigBits = (leastSigBits << 8) | (randomBytes[i] & 0xFF);
>>         }
>> 
>>         // Set variant (bits 62?63) to '10'
>>         leastSigBits &= 0x3FFFFFFFFFFFFFFFL;
>>         leastSigBits |= 0x8000000000000000L;
>> 
>>         return new UUID(mostSigBits, leastSigBits);
>>     }
>
> There's no (time-based) relationship between the currentTimeMillis() value and the nanoTime value.
> They are independent clocks and are read separately and are un-correlated. They won't be usable as lsb of the millis value.
> 
> I'm surprised that the `nextBytes` is slower, since it looks like it calls `nextLong` and puts it in a newly allocated byte[8].  Normal perf measurements won't account for the gc overhead to recover it.
> 
> The nsBits computation looks odd, nanoTme returns nanoseconds (10^9), the remainder (% 1_000_000) is then milliseconds.

> if so, I've tried out some variations, i found creating the 64 bit lsb with ng.nextLong() brings a large pefomance decrease over using the nextBytes method

Probably because `SecureRandom` gets `#nextLong()` from `Random`, which ends up calling `#next(int)` twice, so it allocates twice. Overriding `#nextLong()` in `SecureRandom` may help a little but will still have to allocate as long as `SecureRandomSpi` is not updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2098727054

From paul.sandoz at oracle.com  Tue May 20 19:46:12 2025
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 20 May 2025 19:46:12 +0000
Subject: Towards a JSON API for the JDK
In-Reply-To: <CAGZD2TDQf8CtDXt0=Qdt50AAb-Ktouq2cA9L33pFCzBTwDEhqA@mail.gmail.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
 <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
 <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>
 <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com>
 <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr>
 <CAGZD2TAbv+dQQJCTbpQqa3LVFB90vqBZ-9sbcynAZpOE32bxag@mail.gmail.com>
 <CB7705F0-77B5-4119-BB77-D05D87B270F5@oracle.com>
 <CAGZD2TDQf8CtDXt0=Qdt50AAb-Ktouq2cA9L33pFCzBTwDEhqA@mail.gmail.com>
Message-ID: <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com>

Data binding is a complex feature, even if some examples make it appear simple. Our intention is to explore alignment with the serialization 2.0 effort, when we are ready to so. Hence, I would urge folks to be patience and watch out Brian and Viktor?s Devoxx 2024 talk on the topic.

Paul.

> On May 20, 2025, at 12:21?PM, Swaranga Sarma <sarma.swaranga at gmail.com> wrote:
> 
> > A potential advantage that we (the OpenJDK community) can more easily do is devise an API that resonates with direction the Java platform is heading, specifically around the pattern matching and serialization 2.0
> 
> Right, but most of the discussion here seems to be on the low level tree API and how one might navigate it (perhaps using pattern matching). I am not seeing any discussion on the serialization/deserialization or any reasoning why that is not the goal of the new JEP. Basically a very focused and narrow API:
> 
> ```
> var jsonStr = "..."
> var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a few other variants
> var serialized = Json.serialize(myRecord)
> ```
> 
> This leaves the tree API open to reimplementation later when pattern matching and other features are firmly in place in the JDK. I am making a case that this would be more immediately useful for the most common and simpler cases.
> 
> 
> Regards
> Swaranga


From erikj at openjdk.org  Tue May 20 19:50:53 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 20 May 2025 19:50:53 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v11]
In-Reply-To: <cWzCTmCSk7hJDxFqRLf_kuU-TOmWrGdSHQdoxEVnj0Y=.7a4b8e46-4dca-4e92-bbe0-dff36f382402@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <cWzCTmCSk7hJDxFqRLf_kuU-TOmWrGdSHQdoxEVnj0Y=.7a4b8e46-4dca-4e92-bbe0-dff36f382402@github.com>
Message-ID: <pjcoo4DTnGm9lyG98gdQzy9HUB_QxQhVu-CHWUiJZOY=.e1efb2fd-adff-42b1-a386-2af35b4c8ad6@github.com>

On Tue, 20 May 2025 03:43:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>> 
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
>> - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
>> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
>> 
>> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
>> 
>> Examples:
>> 
>> 
>> # Create an AOT cache with a single command:
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> Hello World
>> Temporary AOTConfiguration recorded: foo.aot.config
>> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
>> [...]
>> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
>> AOTCache creation is complete: foo.aot 10240000 bytes
>> 
>> # Create logging file for the AOT cache assembly phase
>> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> 
>> 
>> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed merge

make/RunTests.gmk line 753:

> 751: 	$$(call MakeDir, $$($1_AOT_JDK_OUTPUT_DIR))
> 752: 
> 753:   ifeq ($$($1_TRAINING), onestep)

Sorry for not noticing this earlier. This is a conditional within a recipe. The preferred style for those are to align the `ifeq`, `else` and `endif` with the recipe itself, using spaces (as it's not a recipe line), and then indent the body with 2 extra spaces for logical indentation. See points 5 and 6 in https://openjdk.org/groups/build/doc/code-conventions.html. You can find an example of this in `make/Bundles.gmk`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2098741011

From rriggs at openjdk.org  Tue May 20 19:53:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 20 May 2025 19:53:52 GMT
Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v6]
In-Reply-To: <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com>
References: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
 <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com>
Message-ID: <SgM_wIBF4W9rmI_jh3sA8XQPDXJ2XKBvzbnpflqovxw=.7d3e906b-c68a-498f-acb3-dac26ccae23f@github.com>

On Mon, 19 May 2025 23:53:07 GMT, Shaojin Wen <swen at openjdk.org> 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:
> 
>   hex8 comments

src/java.base/share/classes/java/util/UUID.java line 528:

> 526:      * <pre>
> 527:      * Input:  0x0123456789ABCDEF
> 528:      * Output: 0x3031323334353637 ('0','1','2','3','4','5','6','7' in ASCII)

Only the low 32 bits are used, the example only needs to show the input ox 0x0123457.
Or change the signature to accept an `int`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22928#discussion_r2098745362

From duke at openjdk.org  Tue May 20 20:41:12 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 20 May 2025 20:41:12 GMT
Subject: RFR: 8356891: Some code simplifications in BigInteger [v19]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <0OgjI18h6PpSgw2z1vkfcpv3yTQxzUegZBqU64ScRaQ=.205ab0a2-7b0f-47bc-872d-25ccc3f5a5ae@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Simplify two's complement in makePositive(int[])

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/46114836..6267a258

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=17-18

  Stats: 9 lines in 1 file changed: 0 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From swen at openjdk.org  Tue May 20 21:55:52 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 20 May 2025 21:55:52 GMT
Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v6]
In-Reply-To: <SgM_wIBF4W9rmI_jh3sA8XQPDXJ2XKBvzbnpflqovxw=.7d3e906b-c68a-498f-acb3-dac26ccae23f@github.com>
References: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
 <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com>
 <SgM_wIBF4W9rmI_jh3sA8XQPDXJ2XKBvzbnpflqovxw=.7d3e906b-c68a-498f-acb3-dac26ccae23f@github.com>
Message-ID: <kW-RBQ6ZrcaMGf8ZfhUVxr3T32po0A_Gno3HauLMqQM=.251ac411-b6b6-44e7-bf5e-a7987dde2de5@github.com>

On Tue, 20 May 2025 19:51:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   hex8 comments
>
> src/java.base/share/classes/java/util/UUID.java line 528:
> 
>> 526:      * <pre>
>> 527:      * Input:  0x0123456789ABCDEF
>> 528:      * Output: 0x3031323334353637 ('0','1','2','3','4','5','6','7' in ASCII)
> 
> Only the low 32 bits are used, the example only needs to show the input ox 0x0123457.
> Or change the signature to accept an `int`.

Because the input of Long.expand is long, if the parameter is int, it will cause a redundant conversion process of long -> int -> long.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22928#discussion_r2098934998

From naoto at openjdk.org  Tue May 20 21:57:45 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 May 2025 21:57:45 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
Message-ID: <lErNIJyBSEaDtbZk91B6GQtqHc0o2qqGOaI-MH0r5ns=.404cffc7-5422-4b1d-b081-48bb8b9cf67a@github.com>

> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25271/files
  - new: https://git.openjdk.org/jdk/pull/25271/files/f2eb1ad8..ec420654

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=00-01

  Stats: 218 lines in 7 files changed: 108 ins; 93 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/25271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25271/head:pull/25271

PR: https://git.openjdk.org/jdk/pull/25271

From henryjen at openjdk.org  Tue May 20 22:02:54 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 20 May 2025 22:02:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <PphfDWen7gKIUoGPV2NnZ2M7_LB47Rd2VmpzTnKDpGk=.5415e56a-eb35-4c65-bca5-692457061f11@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
 <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
 <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>
 <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com>
 <PphfDWen7gKIUoGPV2NnZ2M7_LB47Rd2VmpzTnKDpGk=.5415e56a-eb35-4c65-bca5-692457061f11@github.com>
Message-ID: <PsoyPBx8Ayu9MaNQoao_JYd6OLb8Omp7TuSJQUa9P5k=.de0888a1-ac2d-4691-ad0a-80b16d29f69e@github.com>

On Tue, 20 May 2025 18:30:46 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> We report all issues, not just one, so that would also involve what do we prioritized for the exit code...
>> In general, a non-zero code for invalid jar needs attention. We still 0 with unmatched order.
>> Also the process could fail with other issues like I/O or non-zip file.
>
> Yes I understand and currently we have no documentation as to what the return values might be.  An inconsistency in the order should also be 1 based we only return a 0 if there are no issues.  Any warning should be treated the same
> 
> My point is that it is worth considering with these changes

Point taken. For documentation wise, I don't think it's necessary to specify at this point.
For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098943146

From naoto at openjdk.org  Tue May 20 22:06:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 May 2025 22:06:50 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <ogXKGEuLuPNjbiKf2n8GLsIAUAgCqs6alj69rYqGMDU=.c72dc1a5-dfa2-44dc-a808-81162dec14b6@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <Pup4nswVBdebz4T4tOR33WuL7iedobsLXh-FjSh4e6E=.7eb43d7b-4c9a-490e-9a1f-168fee7bdf9b@github.com>
 <ogXKGEuLuPNjbiKf2n8GLsIAUAgCqs6alj69rYqGMDU=.c72dc1a5-dfa2-44dc-a808-81162dec14b6@github.com>
Message-ID: <gjZaymAsEf2eto9WZwSgSOCBVCy4n_3-CYUaIrGDaKI=.a6168cc0-d6b9-4685-97d9-82eba329680b@github.com>

On Tue, 20 May 2025 19:24:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Also noticed `DumbTerminalProvider::sysTerminal` calls `DumbTerminal` with `new FileInputStream(FileDescriptor.in)`. Later on `DumbTerminal` applies `encoding()` both for passed `stdin` and `std{out,err}`. In short, `TerminalProvider` might need to undergo a similar refactoring separating input and output encodings.
>
> All `FileDescriptor.in` encounters in `jdk.internal.org.jline.terminal` that might need attention:
> 
> src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/DumbTerminalProvider.java
> src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/exec/ExecPty.java
> src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/FfmTerminalProvider.java

JLine is a 3rd party library. It would be desirable that they change their implementation to separately handle in/out in their terminal, but that is out of scope of this PR

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2098947104

From naoto at openjdk.org  Tue May 20 22:06:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 May 2025 22:06:52 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
Message-ID: <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com>

On Tue, 20 May 2025 11:29:42 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> test/jdk/java/io/Console/StdinEncodingTest.java line 46:
> 
>> 44:  * @run junit StdinEncodingTest
>> 45:  */
>> 46: public class StdinEncodingTest {
> 
> AFAICT, there is no similar test (e.g., one using a mock `CharsetProvider`) for `stdout.encoding`. Will it be addressed by another ticket? Shall we consider adding a similar `StdoutEncodingTest` too? (Not necessarily in this PR.)

`stdout.encoding` validity is tested through the public `charset()` mehtod, which is in `CharsetTest.java`

> test/jdk/java/io/Console/csp/provider/MockCharsetProvider.java line 83:
> 
>> 81:             while (in.remaining() > 0) {
>> 82:                 char c = (char)in.get();
>> 83:                 if (c != '\n') {
> 
> `Character.toUpperCase('\n') == '\n'`, not? If so, do we still need this `if`-branching?

Eliminating newlines was a hack to ignore them in the expect responses so that it can check the combined output in one shot. Now I think it is better to check the result separately, so modified as such.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2098947409
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2098947338

From kbarrett at openjdk.org  Tue May 20 22:16:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 20 May 2025 22:16:55 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v6]
In-Reply-To: <ymq-cS14PaC1PpdKAzAZJwxdwtVTbSZtT-LNC21lW6Q=.f956592a-fd59-4bb5-a485-f4138942d290@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com>
 <ymq-cS14PaC1PpdKAzAZJwxdwtVTbSZtT-LNC21lW6Q=.f956592a-fd59-4bb5-a485-f4138942d290@github.com>
Message-ID: <lnDH0vCQvoIGjjsjeO7ukv8gpTfp1vWR8hOX-CXlFjA=.a859787f-bc16-40c2-9f9d-ae879e68dc25@github.com>

On Tue, 20 May 2025 18:43:16 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into native-reference-get
>>  - use new waitForRefProc, some tidying
>>  - Merge branch 'master' into native-reference-get
>>  - remove timeout by using waitForReferenceProcessing
>>  - make ill-timed gc in non-concurrent case less likely
>>  - fix test package use
>>  - add package decl to test
>>  - parameterized return type of native get0
>>  - test native method
>>  - native Reference.get helper
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 366:
> 
>> 364: 
>> 365:     /* Implementation of unintrinsified get().  Making get() native may lead
>> 366:      * C2 to sometimes prefer the native implementation over the intrinsic.
> 
> Can you share more details on this?

See review thread slightly above here, specifically https://github.com/openjdk/jdk/pull/24315/files#r2094884157.
I've looked at the intrinsics for Object.clone() and Object.hashCode(), but only enough to decide I
understand the approach being taken here better than what's in those.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2098956661

From naoto at openjdk.org  Tue May 20 23:05:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 May 2025 23:05:52 GMT
Subject: RFR: 8357275: Locale.Builder.setLanguageTag should mention
 conversions made on language tag [v2]
In-Reply-To: <hmWGxITz4VOuIknq6n8_eTaUdQnvG-P00eAC4a2oKMI=.bf67fede-75c5-46a1-8791-ebecb4a832ba@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
 <hmWGxITz4VOuIknq6n8_eTaUdQnvG-P00eAC4a2oKMI=.bf67fede-75c5-46a1-8791-ebecb4a832ba@github.com>
Message-ID: <4LtNxZysNOzlXDdluBcxbXJh5LBv5bfaxJeMbRskcMs=.5ff1ed81-41b8-4223-9da0-3aacc69f1dfd@github.com>

On Tue, 20 May 2025 17:19:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   setLanguageTag should mention all conversions, not just extlang

src/java.base/share/classes/java/util/Locale.java line 1837:

> 1835:      *     Locale.forLanguageTag("en-abc-def-us").toString(); // returns "abc_US"
> 1836:      *     Locale.forLanguageTag("zh-yue-gan-cmn-czh-CN").toString();
> 1837:      *     // returns "yue"; the rest of the tag is considered ill-formed

I'd rather not use "ill-formed" here, or change the wording, as "the rest of the tag" implies subtags other than "yue" which include "zh." If this "zh" is considered ill-formed, following "yue" should be discarded according to the prior definition.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2098999406

From swen at openjdk.org  Tue May 20 23:10:56 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 20 May 2025 23:10:56 GMT
Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for ZIP entry with
 empty file data [v3]
In-Reply-To: <uSCkEpxPEocKZrI3TEo9oi5R-nzbhQOxg2t-FC0XR30=.1ddf943c-49f3-466f-aff5-f33fd1678004@github.com>
References: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
 <uSCkEpxPEocKZrI3TEo9oi5R-nzbhQOxg2t-FC0XR30=.1ddf943c-49f3-466f-aff5-f33fd1678004@github.com>
Message-ID: <Akak4yZG26KpfAsCfC25aUzkUK3hi0-FsrTFhrxanbQ=.d8b09a0b-d3fd-478c-a0d8-93fd86c32e9a@github.com>

On Mon, 12 May 2025 11:27:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799?
>> 
>> `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix.
>> 
>> tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's suggestion - simplify argument creation, given just a handful number of argument values

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 430:

> 428:                     throw new ZipException("invalid entry CRC (expected 0x"
> 429:                             + Long.toHexString(currentEntry.crc)
> 430:                             + " but got 0x" + Long.toHexString(crc.getValue()) + ")");

Suggestion:

                    throw new ZipException("invalid entry CRC (expected 0x%x but got 0x%x)".formatted(currentEntry.crc, crc.getValue()));

Can String::formatted be used here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25116#discussion_r2099003883

From jlu at openjdk.org  Tue May 20 23:24:33 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 20 May 2025 23:24:33 GMT
Subject: RFR: 8357275: Locale.Builder.setLanguageTag should mention
 conversions made on language tag [v3]
In-Reply-To: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
Message-ID: <x5F0H4IXSnMdL3zwscgGx9HdOv9zDER7M6olVGy6_5k=.21446558-8e6b-4f7c-9ba7-085f423c3854@github.com>

> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  adjust example wording

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25309/files
  - new: https://git.openjdk.org/jdk/pull/25309/files/2d70bf79..62714a26

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25309&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25309&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25309.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25309/head:pull/25309

PR: https://git.openjdk.org/jdk/pull/25309

From jlu at openjdk.org  Tue May 20 23:24:33 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 20 May 2025 23:24:33 GMT
Subject: RFR: 8357275: Locale.Builder.setLanguageTag should mention
 conversions made on language tag [v2]
In-Reply-To: <4LtNxZysNOzlXDdluBcxbXJh5LBv5bfaxJeMbRskcMs=.5ff1ed81-41b8-4223-9da0-3aacc69f1dfd@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
 <hmWGxITz4VOuIknq6n8_eTaUdQnvG-P00eAC4a2oKMI=.bf67fede-75c5-46a1-8791-ebecb4a832ba@github.com>
 <4LtNxZysNOzlXDdluBcxbXJh5LBv5bfaxJeMbRskcMs=.5ff1ed81-41b8-4223-9da0-3aacc69f1dfd@github.com>
Message-ID: <fm132ZhxaMkk2FlBq3Avc5QzGA31UJBhcixHAsBFHhw=.3ec5c23c-4c4b-48f8-954c-cba310ac205a@github.com>

On Tue, 20 May 2025 23:02:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   setLanguageTag should mention all conversions, not just extlang
>
> src/java.base/share/classes/java/util/Locale.java line 1837:
> 
>> 1835:      *     Locale.forLanguageTag("en-abc-def-us").toString(); // returns "abc_US"
>> 1836:      *     Locale.forLanguageTag("zh-yue-gan-cmn-czh-CN").toString();
>> 1837:      *     // returns "yue"; the rest of the tag is considered ill-formed
> 
> I'd rather not use "ill-formed" here, or change the wording, as "the rest of the tag" implies subtags other than "yue" which include "zh." If this "zh" is considered ill-formed, following "yue" should be discarded according to the prior definition.

OK, I'd like to keep "ill-formed" because it allows the example to have meaning for both `[for/set]LanguageTag`.
I updated the wording so that it is clear that "czh", (the fourth extlang) and subsequent subtags are what is considered ill-formed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2099018994

From duke at openjdk.org  Wed May 21 00:23:52 2025
From: duke at openjdk.org (Johannes Graham)
Date: Wed, 21 May 2025 00:23:52 GMT
Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v6]
In-Reply-To: <kW-RBQ6ZrcaMGf8ZfhUVxr3T32po0A_Gno3HauLMqQM=.251ac411-b6b6-44e7-bf5e-a7987dde2de5@github.com>
References: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
 <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com>
 <SgM_wIBF4W9rmI_jh3sA8XQPDXJ2XKBvzbnpflqovxw=.7d3e906b-c68a-498f-acb3-dac26ccae23f@github.com>
 <kW-RBQ6ZrcaMGf8ZfhUVxr3T32po0A_Gno3HauLMqQM=.251ac411-b6b6-44e7-bf5e-a7987dde2de5@github.com>
Message-ID: <r1ULVGYm4IoSm4kVvzw43Qfiv8_d8qx-IuK2sq5ExIk=.9b00e4bc-d786-4b7e-9c60-34b78749603b@github.com>

On Tue, 20 May 2025 21:53:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/UUID.java line 528:
>> 
>>> 526:      * <pre>
>>> 527:      * Input:  0x0123456789ABCDEF
>>> 528:      * Output: 0x3031323334353637 ('0','1','2','3','4','5','6','7' in ASCII)
>> 
>> Only the low 32 bits are used, the example only needs to show the input ox 0x0123457.
>> Or change the signature to accept an `int`.
>
> Because the input of Long.expand is long, if the parameter is int, it will cause a redundant conversion process of long -> int -> long.

I think the issue is just the example input and output should be something like:

Input: 0xABCDEF01
Output: 0x3130666564636261

to demonstrate that it is the low-order bits that are used, as well as that the digit order is reversed in the result.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22928#discussion_r2099071960

From duke at openjdk.org  Wed May 21 00:29:55 2025
From: duke at openjdk.org (Johannes Graham)
Date: Wed, 21 May 2025 00:29:55 GMT
Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v6]
In-Reply-To: <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com>
References: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
 <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com>
Message-ID: <XvxfaACEtuA68fFF7LfraqzPXkHzTJIz9kSBcKSvBAA=.1303ab15-9516-4ffa-b2b3-63ed3e8ea623@github.com>

On Mon, 19 May 2025 23:53:07 GMT, Shaojin Wen <swen at openjdk.org> 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:
> 
>   hex8 comments

src/java.base/share/classes/java/util/UUID.java line 534:

> 532:      */
> 533:     private static long hex8(long i) {
> 534:         // Expand each 4-bit group into 8 bits, spreading them out in the long value: 0xAABBCCDD -> 0x0A0B0C0D0A0B0C0D

should be `0xAABBCCDD -> 0xA0A0B0B0C0C0D0D`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22928#discussion_r2099076402

From duke at openjdk.org  Wed May 21 00:33:53 2025
From: duke at openjdk.org (Johannes Graham)
Date: Wed, 21 May 2025 00:33:53 GMT
Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v6]
In-Reply-To: <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com>
References: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
 <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com>
Message-ID: <xqlDDMuATpwSp2l-arBusEW_DMTIRlb5zgABoH7qRNs=.4cc61817-3ac5-4f59-a813-25673db407f2@github.com>

On Mon, 19 May 2025 23:53:07 GMT, Shaojin Wen <swen at openjdk.org> 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:
> 
>   hex8 comments

src/java.base/share/classes/java/util/UUID.java line 492:

> 490:      * achieving significantly better performance compared to traditional loop-based conversion.
> 491:      *
> 492:      * <p>The conversion algorithm works as follows:

I think the in-line comment describing the algorithm is enough - doesn't need the details in the javadoc as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22928#discussion_r2099078808

From duke at openjdk.org  Wed May 21 00:37:52 2025
From: duke at openjdk.org (Johannes Graham)
Date: Wed, 21 May 2025 00:37:52 GMT
Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v6]
In-Reply-To: <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com>
References: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
 <92GGI04F0DMlolFn2Gy_Dr0bdKwuprY7Qx6OeVkCBTQ=.04f16342-9549-41dd-bb7b-82e748841b01@github.com>
Message-ID: <mE46QdVbLLTYJUpPGBdSKyeltHpkLP3GPLBeKSIHKf4=.b9e97a3a-1ca0-47f3-b939-d0336f0f54d5@github.com>

On Mon, 19 May 2025 23:53:07 GMT, Shaojin Wen <swen at openjdk.org> 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:
> 
>   hex8 comments

src/java.base/share/classes/java/util/UUID.java line 469:

> 467:         buf[18] = '-';
> 468:         buf[23] = '-';
> 469: 

I would suggest a comment here along the lines of "Although the UUID byte ordering is defined to be big-endian, LittleEndian is used here to optimize for the most common architectures. `hex8` reverses the order internally."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22928#discussion_r2099081840

From swen at openjdk.org  Wed May 21 00:50:10 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 21 May 2025 00:50:10 GMT
Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v7]
In-Reply-To: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
References: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
Message-ID: <ES5AT07uaPCLsCEyxJbqiFYNFLR67NOaM4O5sxM93gg=.d180ff8d-44ef-4897-98fc-14d71bb37fa3@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 two additional commits since the last revision:

 - add comments, from @j3graham
 - fix comments, from @j3graham

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22928/files
  - new: https://git.openjdk.org/jdk/pull/22928/files/3b94f81f..61e3faee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=05-06

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 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  Wed May 21 00:57:30 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 21 May 2025 00:57:30 GMT
Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v8]
In-Reply-To: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
References: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
Message-ID: <G7zjTKnYvpFza0OH2jtfj9NWuNjSX8lRbUj46rYP4Lw=.6bbc52ad-26e5-453c-810c-b5c055359c38@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:

  fix comments, from @j3graham

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22928/files
  - new: https://git.openjdk.org/jdk/pull/22928/files/61e3faee..8d0e8fd3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 almatvee at openjdk.org  Wed May 21 01:27:01 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 May 2025 01:27:01 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles
In-Reply-To: <Cn6MvOJe_p4bXVBdIXbmpHZWaLK2XYfnr2OKGq7S3bQ=.6c443ead-c4c7-4c35-8d86-b2e6a9bf9c1e@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
 <Cn6MvOJe_p4bXVBdIXbmpHZWaLK2XYfnr2OKGq7S3bQ=.6c443ead-c4c7-4c35-8d86-b2e6a9bf9c1e@github.com>
Message-ID: <I2mfsF57tAlRNQE5bAqJ-EehZH3FVp3oWhEyj1gtDxo=.e9c99d74-9894-49d8-be38-1b16e63fa43e@github.com>

On Tue, 20 May 2025 16:35:57 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Fixed jpackage to produce valid Java runtimes based on description below:
>> 
>> Definitions:
>> 
>> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
>> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
>> - JDK image defined as content of "Contents/Home".
>> - Signed JDK image does not exist, since it cannot be signed as bundle.
>> 
>> jpackage output based on input:
>> 
>> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
>> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
>> 
>> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
>> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>>  
>> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
>> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
>> 
>> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
>> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
>> 
>> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>>  - jpackage will check for libjli.dylib presence in "lib" folder.
>>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
>> - Ad-hoc signing will done.
>> 
>> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
>> - 2 first steps from 5 and certificate signing will be done.
>
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties line 45:
> 
>> 43: resource.app-info-plist=Application Info.plist
>> 44: resource.runtime-info-plist=Java Runtime Info.plist
>> 45: resource.runtime-image-info-plist=Java Runtime Bundle Info.plist
> 
> `resource.runtime-bundle-info-plist` would be a better name as the list file belongs to a bundle, not the image.

Fixed.

> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties line 88:
> 
>> 86: message.codesign.failed.reason.xcode.tools=Possible reason for "codesign" failure is missing Xcode with command line developer tools. Install Xcode with command line developer tools to see if it resolves the problem.
>> 87: message.runtime-image-invalid=Provided runtime image at "{0}" is invalid or corrupted.
>> 88: message.runtime-image-invalid.advice=Runtime image should be valid JDK bundle or JDK image.
> 
> We need negative test cases for these new error conditions.

Test cases are added.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099120626
PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099120720

From asemenyuk at openjdk.org  Wed May 21 01:41:55 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 21 May 2025 01:41:55 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles
In-Reply-To: <I2mfsF57tAlRNQE5bAqJ-EehZH3FVp3oWhEyj1gtDxo=.e9c99d74-9894-49d8-be38-1b16e63fa43e@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
 <Cn6MvOJe_p4bXVBdIXbmpHZWaLK2XYfnr2OKGq7S3bQ=.6c443ead-c4c7-4c35-8d86-b2e6a9bf9c1e@github.com>
 <I2mfsF57tAlRNQE5bAqJ-EehZH3FVp3oWhEyj1gtDxo=.e9c99d74-9894-49d8-be38-1b16e63fa43e@github.com>
Message-ID: <aU2MY0qaPfm2KYZt3lTEnzV2xWE0LRD_bz1uN0uQowY=.2fc076dd-8e70-428f-a6c5-30fc96d77c9e@github.com>

On Wed, 21 May 2025 01:24:16 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties line 88:
>> 
>>> 86: message.codesign.failed.reason.xcode.tools=Possible reason for "codesign" failure is missing Xcode with command line developer tools. Install Xcode with command line developer tools to see if it resolves the problem.
>>> 87: message.runtime-image-invalid=Provided runtime image at "{0}" is invalid or corrupted.
>>> 88: message.runtime-image-invalid.advice=Runtime image should be valid JDK bundle or JDK image.
>> 
>> We need negative test cases for these new error conditions.
>
> Test cases are added.

Can you give a reference to a test that expects jpackage to fail with `message.runtime-image-invalid` error in the output? I can't find it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099135430

From almatvee at openjdk.org  Wed May 21 01:41:56 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 May 2025 01:41:56 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles
In-Reply-To: <v4vRW6uWpa5qS50WACawSF15CS04QyzJQrZZ1h8pbko=.aa0ff2df-3472-4323-830e-6789d135267c@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
 <v4vRW6uWpa5qS50WACawSF15CS04QyzJQrZZ1h8pbko=.aa0ff2df-3472-4323-830e-6789d135267c@github.com>
Message-ID: <gV_TKGIKqd0xdoJqEQjfHajp-TtHMWuNj4jB6N3hNiI=.a38b9e45-deb2-48ce-b9e8-6edfa1c1b4e4@github.com>

On Tue, 20 May 2025 16:39:02 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Fixed jpackage to produce valid Java runtimes based on description below:
>> 
>> Definitions:
>> 
>> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
>> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
>> - JDK image defined as content of "Contents/Home".
>> - Signed JDK image does not exist, since it cannot be signed as bundle.
>> 
>> jpackage output based on input:
>> 
>> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
>> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
>> 
>> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
>> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>>  
>> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
>> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
>> 
>> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
>> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
>> 
>> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>>  - jpackage will check for libjli.dylib presence in "lib" folder.
>>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
>> - Ad-hoc signing will done.
>> 
>> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
>> - 2 first steps from 5 and certificate signing will be done.
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java line 246:
> 
>> 244: 
>> 245:     public static String getPropertyFromFile(Path filename, String name) {
>> 246:         // load properties file
> 
> That is a bad idea to expose jpackage API that uses jpackage's Log class. Where will these log messages go?

Fixed.

> src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java line 251:
> 
>> 249:             properties.load(reader);
>> 250:         } catch (IOException e) {
>> 251:             Log.error("Exception: " + e.getMessage());
> 
> This is an exception swallow, not good. Logging it in place doesn't make it right. If this is an unrecoverable error, it should be forwarded to the caller.

Fixed. Yes, we should consider it as an unrecoverable error.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099133805
PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099134380

From almatvee at openjdk.org  Wed May 21 01:47:53 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 May 2025 01:47:53 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles
In-Reply-To: <GWT43lOFTJQMTuyPCpjDsTdCUX1CrrwtonynMMyWM9U=.7d5e2ae4-f5b0-4323-bf69-4f39c9e25745@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
 <GWT43lOFTJQMTuyPCpjDsTdCUX1CrrwtonynMMyWM9U=.7d5e2ae4-f5b0-4323-bf69-4f39c9e25745@github.com>
Message-ID: <VqFrksKESaCiJ3cnIG_l9qAeqGctpqMSGabq1vfw52w=.7bcf7493-4965-45d3-aba6-7ba429865f83@github.com>

On Tue, 20 May 2025 16:57:34 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Fixed jpackage to produce valid Java runtimes based on description below:
>> 
>> Definitions:
>> 
>> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
>> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
>> - JDK image defined as content of "Contents/Home".
>> - Signed JDK image does not exist, since it cannot be signed as bundle.
>> 
>> jpackage output based on input:
>> 
>> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
>> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
>> 
>> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
>> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>>  
>> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
>> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
>> 
>> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
>> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
>> 
>> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>>  - jpackage will check for libjli.dylib presence in "lib" folder.
>>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
>> - Ad-hoc signing will done.
>> 
>> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
>> - 2 first steps from 5 and certificate signing will be done.
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java line 199:
> 
>> 197:                         }
>> 198:                         return version;
>> 199:                     },
> 
> I guess, this is a workaround for the case when the version comes from JDK's release file. This is the wrong place for this workaround. It should be a part of the code reading version from JDK's release file.

Yes, this is workaround when the version comes from JDK's release file. In this case name will be customeJDK-25.0.0.0 for example if we change it when we read version form file. Other platform do not need it. Only PRODUCT_VERSION in MSI needs to be 2 or 4 components, so I think it is correct location for it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099140330

From almatvee at openjdk.org  Wed May 21 01:53:50 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 May 2025 01:53:50 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles
In-Reply-To: <GpnSmeYJ-sLbVqmV85mlWYoeOmptre9JDCvJJViifBk=.8b448182-b149-413f-a401-8624c6916180@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
 <GpnSmeYJ-sLbVqmV85mlWYoeOmptre9JDCvJJViifBk=.8b448182-b149-413f-a401-8624c6916180@github.com>
Message-ID: <0XxbdYMVs8a-EgJzzgRw2afvoTGeKRxDhybE8YrqcVw=.d3f88818-848d-4d33-9442-ea9e9f9f01af@github.com>

On Tue, 20 May 2025 17:00:21 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Fixed jpackage to produce valid Java runtimes based on description below:
>> 
>> Definitions:
>> 
>> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
>> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
>> - JDK image defined as content of "Contents/Home".
>> - Signed JDK image does not exist, since it cannot be signed as bundle.
>> 
>> jpackage output based on input:
>> 
>> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
>> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
>> 
>> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
>> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>>  
>> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
>> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
>> 
>> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
>> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
>> 
>> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>>  - jpackage will check for libjli.dylib presence in "lib" folder.
>>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
>> - Ad-hoc signing will done.
>> 
>> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
>> - 2 first steps from 5 and certificate signing will be done.
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 1004:
> 
>> 1002:             // External runtime image should be R/O unless it is on macOS.
>> 1003:             // On macOS it will be signed ad-hoc or with real certificate.
>> 1004:             return !TKit.isOSX();
> 
> Do I get the comment right, and jpackage will modify the image supplied with `--runtime-image` parameter? This is wrong. jpackage must not modify any externally supplied files/directories unless this is app image signing on macos.

Yes, you get the comment right. We do sign runtime image as well (same as app image). We do ad-hoc signing for runtime image if signing is not requested. Ad-hoc signing will modify runtime image. I think you mean case when "--app-image" and "--runtime-image" is specified, then yes we should not modify it, but when we packaging just runtime it will be modify due to signature. I will update test to reflect it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099145308

From almatvee at openjdk.org  Wed May 21 01:59:58 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 May 2025 01:59:58 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles
In-Reply-To: <1xpPgU-jZVXZaBrp0A7CSqzSSNt8GqgoAvnp3tcLt_g=.8e7cd068-407f-442e-a596-0a9f6f3d4d9f@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
 <1xpPgU-jZVXZaBrp0A7CSqzSSNt8GqgoAvnp3tcLt_g=.8e7cd068-407f-442e-a596-0a9f6f3d4d9f@github.com>
Message-ID: <ZID20anPxNq49ZVBPGSTjvCkY0ThjWmZJCojsutH37I=.86f5030f-9ee1-45c3-bc69-25e67409f223@github.com>

On Tue, 20 May 2025 17:05:55 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Fixed jpackage to produce valid Java runtimes based on description below:
>> 
>> Definitions:
>> 
>> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
>> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
>> - JDK image defined as content of "Contents/Home".
>> - Signed JDK image does not exist, since it cannot be signed as bundle.
>> 
>> jpackage output based on input:
>> 
>> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
>> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
>> 
>> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
>> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>>  
>> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
>> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
>> 
>> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
>> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
>> 
>> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>>  - jpackage will check for libjli.dylib presence in "lib" folder.
>>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
>> - Ad-hoc signing will done.
>> 
>> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
>> - 2 first steps from 5 and certificate signing will be done.
>> 
>> Additional changes:
>> - jpackage will attempt to get a package version from the JDK's release file if the --version option is not specified.
>> - The bundle's top directory name will have the ".jdk" suffix.
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java line 337:
> 
>> 335:         }
>> 336: 
>> 337:         return installLocation.resolve(cmd.name() + (cmd.isRuntime() ? ".jdk" : ".app"));
> 
> Why the ".jdk" suffix and not ".app"?

Because JDK bundles has ".jdk" suffix. Why it should be ".app"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099150610

From almatvee at openjdk.org  Wed May 21 02:04:49 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 May 2025 02:04:49 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles
In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
Message-ID: <mcIuxuG3YEeFG6D8ab4wpmCuspRrYw4o8H27UaQCuzA=.e93c81f4-52e7-44e4-bf3f-019a9db69a04@github.com>

On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Fixed jpackage to produce valid Java runtimes based on description below:
> 
> Definitions:
> 
> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
> - JDK image defined as content of "Contents/Home".
> - Signed JDK image does not exist, since it cannot be signed as bundle.
> 
> jpackage output based on input:
> 
> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
> 
> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>  
> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
> 
> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
> 
> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>  - jpackage will check for libjli.dylib presence in "lib" folder.
>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
> - Ad-hoc signing will done.
> 
> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
> - 2 first steps from 5 and certificate signing will be done.
> 
> Additional changes:
> - jpackage will attempt to get a package version from the JDK's release file if the --version option is not specified.
> - The bundle's top directory name will have the ".jdk" suffix.

I updated description.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25314#issuecomment-2896251592

From almatvee at openjdk.org  Wed May 21 02:19:31 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 May 2025 02:19:31 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v2]
In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
Message-ID: <qpleLEU1QbnV4G_QAgAIUiYC0QUZV_WHKftHmH1aTqc=.2b18c3c2-661c-4432-bec5-c0b7f5144c85@github.com>

> Fixed jpackage to produce valid Java runtimes based on description below:
> 
> Definitions:
> 
> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
> - JDK image defined as content of "Contents/Home".
> - Signed JDK image does not exist, since it cannot be signed as bundle.
> 
> jpackage output based on input:
> 
> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
> 
> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>  
> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
> 
> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
> 
> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>  - jpackage will check for libjli.dylib presence in "lib" folder.
>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
> - Ad-hoc signing will done.
> 
> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
> - 2 first steps from 5 and certificate signing will be done.
> 
> Additional changes:
> - jpackage will attempt to get a package version from the JDK's release file if the --version option is not specified.
> - The bundle's top directory name will have the ".jdk" suffix.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25314/files
  - new: https://git.openjdk.org/jdk/pull/25314/files/74dd9917..182a9ddf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25314&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25314&range=00-01

  Stats: 64 lines in 6 files changed: 51 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/25314.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25314/head:pull/25314

PR: https://git.openjdk.org/jdk/pull/25314

From almatvee at openjdk.org  Wed May 21 02:19:31 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 May 2025 02:19:31 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles
In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
Message-ID: <HAdXNAzTzGyBEmtPoqk3lAcqDW7uUtx19h6HOEMSN6A=.3a4143da-3d55-42d9-b787-dc0c3479208d@github.com>

On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Fixed jpackage to produce valid Java runtimes based on description below:
> 
> Definitions:
> 
> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
> - JDK image defined as content of "Contents/Home".
> - Signed JDK image does not exist, since it cannot be signed as bundle.
> 
> jpackage output based on input:
> 
> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
> 
> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>  
> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
> 
> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
> 
> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>  - jpackage will check for libjli.dylib presence in "lib" folder.
>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
> - Ad-hoc signing will done.
> 
> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
> - 2 first steps from 5 and certificate signing will be done.
> 
> Additional changes:
> - jpackage will attempt to get a package version from the JDK's release file if the --version option is not specified.
> - The bundle's top directory name will have the ".jdk" suffix.

8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2]
 - Addresses the above comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25314#issuecomment-2896270130

From almatvee at openjdk.org  Wed May 21 02:19:31 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 May 2025 02:19:31 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v2]
In-Reply-To: <aU2MY0qaPfm2KYZt3lTEnzV2xWE0LRD_bz1uN0uQowY=.2fc076dd-8e70-428f-a6c5-30fc96d77c9e@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
 <Cn6MvOJe_p4bXVBdIXbmpHZWaLK2XYfnr2OKGq7S3bQ=.6c443ead-c4c7-4c35-8d86-b2e6a9bf9c1e@github.com>
 <I2mfsF57tAlRNQE5bAqJ-EehZH3FVp3oWhEyj1gtDxo=.e9c99d74-9894-49d8-be38-1b16e63fa43e@github.com>
 <aU2MY0qaPfm2KYZt3lTEnzV2xWE0LRD_bz1uN0uQowY=.2fc076dd-8e70-428f-a6c5-30fc96d77c9e@github.com>
Message-ID: <p8hB-cQ6s42U2DQ8r9ND0xChr6p6wULM63hbBeYrn7A=.20e5e256-1f26-44ad-b416-de7c19ca73c6@github.com>

On Wed, 21 May 2025 01:39:16 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Test cases are added.
>
> Can you give a reference to a test that expects jpackage to fail with `message.runtime-image-invalid` error in the output? I can't find it.

I just push it. See ErrorTest.java.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099164323

From asemenyuk at openjdk.org  Wed May 21 02:35:59 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 21 May 2025 02:35:59 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v2]
In-Reply-To: <VqFrksKESaCiJ3cnIG_l9qAeqGctpqMSGabq1vfw52w=.7bcf7493-4965-45d3-aba6-7ba429865f83@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
 <GWT43lOFTJQMTuyPCpjDsTdCUX1CrrwtonynMMyWM9U=.7d5e2ae4-f5b0-4323-bf69-4f39c9e25745@github.com>
 <VqFrksKESaCiJ3cnIG_l9qAeqGctpqMSGabq1vfw52w=.7bcf7493-4965-45d3-aba6-7ba429865f83@github.com>
Message-ID: <LSkpkDMdsba0xNt6nPdenD3LVARwFtyfQX-iuVqtbc8=.a813201a-a0c9-421d-88c1-66a273c3fc76@github.com>

On Wed, 21 May 2025 01:44:48 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java line 199:
>> 
>>> 197:                         }
>>> 198:                         return version;
>>> 199:                     },
>> 
>> I guess, this is a workaround for the case when the version comes from JDK's release file. This is the wrong place for this workaround. It should be a part of the code reading version from JDK's release file.
>
> Yes, this is workaround when the version comes from JDK's release file. In this case name will be customeJDK-25.0.0.0 for example if we change it when we read version form file. Other platform do not need it. Only PRODUCT_VERSION in MSI needs to be 2 or 4 components, so I think it is correct location for it.

For runtime packaging, the version can be taken from the command line or the "release" file. In the latter case the version should be valid for the current platform and packaging type. Version adjustments should be isolated in a function that reads a version from the "release" file. The result of this function call should be such that it will be used as-is without any modifications.

Ideally, we should have `Optional<String> readVersionFromRuntimeReleaseFile(String packageType, Path pathToReleaseFile)` function that we can unit test and that will return a valid version for the given packaging type ("packageType" parameter). It should return an empty Optional instance if it fails.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099180763

From kbarrett at openjdk.org  Wed May 21 02:36:16 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 21 May 2025 02:36:16 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v3]
In-Reply-To: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
Message-ID: <CxhBye_jinJNbfyBQYStOoZ1Ah1saCPxl1fwMODoeXo=.d54042aa-1113-488d-a2ab-f29f17efcc64@github.com>

> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
> use java.lang.ref.Cleaner.
> 
> This change is algorithmically similar to the two previous versions:
> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
> Bits::reserveMemory(). For both of those versions and this change, a thread
> calls that function and tries to reserve some space. If it fails, then it
> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
> cleaned. If reservation still fails, then it invokes the GC to try to
> deactivate more cleaners for cleaning. After that GC it keeps trying the
> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
> eventually either succeeding or giving up and throwing OOME.
> 
> Retaining that algorithmic approach is one of the goals of this change, since
> it has been successfully in use since JDK 9 (and was originally developed and
> extensively tested in JDK 8).
> 
> The key to this approach is having a way to determine that deactivated
> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
> threads help the reference processor until there was no available work.
> JDK-8156500 waits for the reference processor to quiesce, relying on its
> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
> to do this, which is why this change rolls its own Cleaner-like mechanism from
> the underlying primitives. Like JDK-6857566, this change has waiting threads
> help with cleaning references. This was a potentially undesirable feature of
> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
> became internal-only somewhere around that time as well.) That's not a concern
> here, as the cleaners involved are only from DBB, and we know what they look
> like.
> 
> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
> being done off the reference processing thread, as it may be expensive and
> slow down enqueuing other pending references. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
> 
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there is no available work whil...

Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:

 - add description of BufferCleaner class
 - exception handling in cleaner for backward consistency
 - detabify

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25289/files
  - new: https://git.openjdk.org/jdk/pull/25289/files/45d0b1ef..be3312cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25289&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25289&range=01-02

  Stats: 40 lines in 2 files changed: 28 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25289.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25289/head:pull/25289

PR: https://git.openjdk.org/jdk/pull/25289

From kbarrett at openjdk.org  Wed May 21 02:36:17 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 21 May 2025 02:36:17 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v2]
In-Reply-To: <YQRD37sSMcVIjPBMvGTEmv7e_pzircI13BlVMMISyHM=.a7f5bbd2-dadc-4a8b-be59-451dfbbc4e0b@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <wp_i02Ji5nG8obVLo9gJvHwA73hfC_b2dx56nXVsCoM=.c481ac3c-77ca-4d27-89be-31d98055964f@github.com>
 <YQRD37sSMcVIjPBMvGTEmv7e_pzircI13BlVMMISyHM=.a7f5bbd2-dadc-4a8b-be59-451dfbbc4e0b@github.com>
Message-ID: <wS0YRONx4h2ds6qBzAYYOdhhf-4Khksz5BvX05QMEFE=.314f062f-a53b-4395-a7ad-fcaa1e81098c@github.com>

On Mon, 19 May 2025 19:16:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/java/nio/BufferCleaner.java line 33:
> 
>> 31: import java.util.Objects;
>> 32: import sun.nio.Cleaner;
>> 33: 
> 
> A class cleaner describing the overall objective (an excerpt from the PR description) would be useful.

Assume you meant "class comment".  I've added such.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2099181042

From almatvee at openjdk.org  Wed May 21 02:47:09 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 May 2025 02:47:09 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v3]
In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
Message-ID: <2RB3dSbaiqhRS-x45Syo3bO6-Fr7o9NT8icBUbumRls=.43ef27c3-4793-493a-93a4-cc7d65f19c99@github.com>

> Fixed jpackage to produce valid Java runtimes based on description below:
> 
> Definitions:
> 
> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
> - JDK image defined as content of "Contents/Home".
> - Signed JDK image does not exist, since it cannot be signed as bundle.
> 
> jpackage output based on input:
> 
> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
> 
> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>  
> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
> 
> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
> 
> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>  - jpackage will check for libjli.dylib presence in "lib" folder.
>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
> - Ad-hoc signing will done.
> 
> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
> - 2 first steps from 5 and certificate signing will be done.
> 
> Additional changes:
> - The bundle's top directory name will have the ".jdk" suffix.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v3]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25314/files
  - new: https://git.openjdk.org/jdk/pull/25314/files/182a9ddf..dfdec21f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25314&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25314&range=01-02

  Stats: 147 lines in 6 files changed: 19 ins; 121 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25314.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25314/head:pull/25314

PR: https://git.openjdk.org/jdk/pull/25314

From asemenyuk at openjdk.org  Wed May 21 02:47:10 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 21 May 2025 02:47:10 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v2]
In-Reply-To: <qpleLEU1QbnV4G_QAgAIUiYC0QUZV_WHKftHmH1aTqc=.2b18c3c2-661c-4432-bec5-c0b7f5144c85@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
 <qpleLEU1QbnV4G_QAgAIUiYC0QUZV_WHKftHmH1aTqc=.2b18c3c2-661c-4432-bec5-c0b7f5144c85@github.com>
Message-ID: <n2591zSdYmOMNnbRCjUog4Dorg05r22v3u29k12ndTI=.bed85619-8acf-4abf-8a72-a7fbb4fd173c@github.com>

On Wed, 21 May 2025 02:19:31 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Fixed jpackage to produce valid Java runtimes based on description below:
>> 
>> Definitions:
>> 
>> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
>> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
>> - JDK image defined as content of "Contents/Home".
>> - Signed JDK image does not exist, since it cannot be signed as bundle.
>> 
>> jpackage output based on input:
>> 
>> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
>> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
>> 
>> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
>> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>>  
>> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
>> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
>> 
>> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
>> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
>> 
>> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>>  - jpackage will check for libjli.dylib presence in "lib" folder.
>>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
>> - Ad-hoc signing will done.
>> 
>> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
>> - 2 first steps from 5 and certificate signing will be done.
>> 
>> Additional changes:
>> - The bundle's top directory name will have the ".jdk" suffix.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2]

Changes requested by asemenyuk (Reviewer).

test/jdk/tools/jpackage/share/ErrorTest.java line 93:

> 91:             return appImageCmd.outputBundle().toString();
> 92:         }),
> 93:         INVALID_JDK_BUNDLE(cmd -> {

Would `INVALID_MAC_JDK_BUNDLE` name be more accurate?

test/jdk/tools/jpackage/share/ErrorTest.java line 102:

> 100:             } catch (IOException ex) {
> 101:                 TKit.error(ex.getMessage());
> 102:                 return null;

What is the point of this exception "handling"? What problem does it solve? What is the caller supposed to do with the `null`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/25314#pullrequestreview-2856070441
PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099185510
PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099184978

From almatvee at openjdk.org  Wed May 21 02:47:10 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 May 2025 02:47:10 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v2]
In-Reply-To: <qpleLEU1QbnV4G_QAgAIUiYC0QUZV_WHKftHmH1aTqc=.2b18c3c2-661c-4432-bec5-c0b7f5144c85@github.com>
References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com>
 <qpleLEU1QbnV4G_QAgAIUiYC0QUZV_WHKftHmH1aTqc=.2b18c3c2-661c-4432-bec5-c0b7f5144c85@github.com>
Message-ID: <LPJNNzXpai5Mq9BrKIAqGYnjUlcE8I942BQcUQ7vDFw=.88f77d99-4738-424d-81f2-298b7c8a508a@github.com>

On Wed, 21 May 2025 02:19:31 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Fixed jpackage to produce valid Java runtimes based on description below:
>> 
>> Definitions:
>> 
>> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
>> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
>> - JDK image defined as content of "Contents/Home".
>> - Signed JDK image does not exist, since it cannot be signed as bundle.
>> 
>> jpackage output based on input:
>> 
>> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
>> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
>> 
>> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
>> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>>  
>> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
>> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
>> 
>> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
>> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
>> 
>> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>>  - jpackage will check for libjli.dylib presence in "lib" folder.
>>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
>> - Ad-hoc signing will done.
>> 
>> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
>> - 2 first steps from 5 and certificate signing will be done.
>> 
>> Additional changes:
>> - The bundle's top directory name will have the ".jdk" suffix.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2]

8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v3]
- Removed "jpackage will attempt to get a package version from the JDK's release file if the --version option is not specified". It will be fixed as separate issue under: [JDK-8357404](https://bugs.openjdk.org/browse/JDK-8357404).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25314#issuecomment-2896397761

From david.vidal.escudero at gmail.com  Tue May 20 23:47:21 2025
From: david.vidal.escudero at gmail.com (David Vidal Escudero)
Date: Tue, 20 May 2025 18:47:21 -0500
Subject: Towards a JSON API for the JDK
In-Reply-To: <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
 <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
 <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>
 <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com>
 <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr>
 <CAGZD2TAbv+dQQJCTbpQqa3LVFB90vqBZ-9sbcynAZpOE32bxag@mail.gmail.com>
 <CB7705F0-77B5-4119-BB77-D05D87B270F5@oracle.com>
 <CAGZD2TDQf8CtDXt0=Qdt50AAb-Ktouq2cA9L33pFCzBTwDEhqA@mail.gmail.com>
 <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com>
Message-ID: <CADY0CYzppo-VdWERr4UWy=Q5zsa8zkzfXMsd=wwBGoPVDR77vQ@mail.gmail.com>

Hello,

So, if such a Json library is added to the JDK, the Java Http module now
should accept a JsonDocument implementing something like
BodyPublishers.ofJsonDocument, or better yet BodyPublishers.ofJsonEncodable
(assuming Eteh proposal).

I think also JDBC API should be modified so prepared statements can
implement .setJson and .getJson for DBMS supporting Json type (like
Postgres).

David.


---------- Forwarded message ---------
De: Paul Sandoz <paul.sandoz at oracle.com>
Date: mar, 20 de may de 2025, 14:46
Subject: Re: Towards a JSON API for the JDK
To: Swaranga Sarma <sarma.swaranga at gmail.com>
Cc: Remi Forax <forax at univ-mlv.fr>, Brian Goetz <brian.goetz at oracle.com>,
core-libs-dev <core-libs-dev at openjdk.org>


Data binding is a complex feature, even if some examples make it appear
simple. Our intention is to explore alignment with the serialization 2.0
effort, when we are ready to so. Hence, I would urge folks to be patience
and watch out Brian and Viktor?s Devoxx 2024 talk on the topic.

Paul.

> On May 20, 2025, at 12:21?PM, Swaranga Sarma <sarma.swaranga at gmail.com>
wrote:
>
> > A potential advantage that we (the OpenJDK community) can more easily
do is devise an API that resonates with direction the Java platform is
heading, specifically around the pattern matching and serialization 2.0
>
> Right, but most of the discussion here seems to be on the low level tree
API and how one might navigate it (perhaps using pattern matching). I am
not seeing any discussion on the serialization/deserialization or any
reasoning why that is not the goal of the new JEP. Basically a very focused
and narrow API:
>
> ```
> var jsonStr = "..."
> var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a
few other variants
> var serialized = Json.serialize(myRecord)
> ```
>
> This leaves the tree API open to reimplementation later when pattern
matching and other features are firmly in place in the JDK. I am making a
case that this would be more immediately useful for the most common and
simpler cases.
>
>
> Regards
> Swaranga
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250520/a6540bde/attachment.htm>

From stuefe at openjdk.org  Wed May 21 04:42:01 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 May 2025 04:42:01 GMT
Subject: RFR: 8357179: Deprecate VFORK launch mechanism from Process
 implementation (linux) [v2]
In-Reply-To: <lgOLwRhfzwJw-Ko6kpSorv9CaXd9bqiij6X6JSuM8yw=.4f788f75-541d-4e45-97d3-8bb5e4beedf6@github.com>
References: <KZUCnliZBaa1PgMeT9PSEQ26BttrtNGZed2I70C0Mbc=.d66fb189-2d88-420c-a8bd-227cb2b817cb@github.com>
 <lgOLwRhfzwJw-Ko6kpSorv9CaXd9bqiij6X6JSuM8yw=.4f788f75-541d-4e45-97d3-8bb5e4beedf6@github.com>
Message-ID: <NHoyM3OlcllTOczy43gJmwUpVStUPKKj8kmAXuRbDEY=.9a45fa03-3b79-4e98-9b4b-ecf247d86363@github.com>

On Mon, 19 May 2025 16:59:06 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> For the ratio behind this please see the companion CSR: https://bugs.openjdk.org/browse/JDK-8357180.
>> 
>> We plan to deprecate this in JDK 25 and to remove it in JDK 26.
>> 
>> This patch just writes a deprecation message to stderr:
>> 
>> 
>> 08:46:38 thomas at starfish java -Djdk.lang.Process.launchMechanism=VFORK SimpleSpawn ls
>> VFORK MODE DEPRECATED
>> The VFORK launch mechanism has been deprecated for being dangerous.
>> It will be removed in a future java version. Either remove the
>> jdk.lang.Process.launchMechanism property (preferred) or use FORK mode
>> instead (-Djdk.lang.Process.launchMechanism=FORK).
>> ...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use string block

Thanks all

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25282#issuecomment-2896543420

From stuefe at openjdk.org  Wed May 21 04:42:01 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 May 2025 04:42:01 GMT
Subject: Integrated: 8357179: Deprecate VFORK launch mechanism from Process
 implementation (linux)
In-Reply-To: <KZUCnliZBaa1PgMeT9PSEQ26BttrtNGZed2I70C0Mbc=.d66fb189-2d88-420c-a8bd-227cb2b817cb@github.com>
References: <KZUCnliZBaa1PgMeT9PSEQ26BttrtNGZed2I70C0Mbc=.d66fb189-2d88-420c-a8bd-227cb2b817cb@github.com>
Message-ID: <Koh_wByPzfU9rb8OTvO1_sf5yTw-NFKKnmz56tNMdGg=.fe412fa7-65d2-42d9-98c9-b339308df294@github.com>

On Sat, 17 May 2025 06:49:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> For the ratio behind this please see the companion CSR: https://bugs.openjdk.org/browse/JDK-8357180.
> 
> We plan to deprecate this in JDK 25 and to remove it in JDK 26.
> 
> This patch just writes a deprecation message to stderr:
> 
> 
> 08:46:38 thomas at starfish java -Djdk.lang.Process.launchMechanism=VFORK SimpleSpawn ls
> VFORK MODE DEPRECATED
> The VFORK launch mechanism has been deprecated for being dangerous.
> It will be removed in a future java version. Either remove the
> jdk.lang.Process.launchMechanism property (preferred) or use FORK mode
> instead (-Djdk.lang.Process.launchMechanism=FORK).
> ...

This pull request has now been integrated.

Changeset: 74fc4e4e
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/74fc4e4ee7f2e44d9c8339ff6665d4171d298f8f
Stats:     16 lines in 1 file changed: 12 ins; 2 del; 2 mod

8357179: Deprecate VFORK launch mechanism from Process implementation (linux)

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/25282

From stuefe at openjdk.org  Wed May 21 04:55:53 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 May 2025 04:55:53 GMT
Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(),
 use FD_CLOEXEC instead of close()
In-Reply-To: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
References: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
Message-ID: <pBrX3PMX7JIBzeQBkqAsOuVhP4XkBBhBtzLAyWoMKfs=.1e5caad2-5b77-4ff1-98f2-40e718af5776@github.com>

On Mon, 19 May 2025 12:23:07 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi, please consider the following patch.
> 
> This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc.
> 
> This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens).
> 
> Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409
> 
> This patch also fixes two subtle bugs:
> - we didn't check the return value of the close() inside closeAllFileDescriptors
> - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it)
> 
> ----
> 
> Testing:
> 
> We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC.
> 
> - in the parent JVM, the test opens a file in native code without FD_CLOEXEC
> - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open
> 
> I verified that the test correctly detects a broken implementation that leaks file descriptors. 
> 
> I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX).
> 
> I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green.

Ping @RogerRiggs ? And @simonis, perhaps?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25301#issuecomment-2896570218

From kbarrett at openjdk.org  Wed May 21 05:44:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 21 May 2025 05:44:52 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v3]
In-Reply-To: <CxhBye_jinJNbfyBQYStOoZ1Ah1saCPxl1fwMODoeXo=.d54042aa-1113-488d-a2ab-f29f17efcc64@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <CxhBye_jinJNbfyBQYStOoZ1Ah1saCPxl1fwMODoeXo=.d54042aa-1113-488d-a2ab-f29f17efcc64@github.com>
Message-ID: <exAsyfZMy1uYG8NvVHhll1AmgHr67ETeNedXNSTSRcA=.f38cf914-08cc-4eca-9226-c0af3f54de24@github.com>

On Wed, 21 May 2025 02:36:16 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>> use java.lang.ref.Cleaner.
>> 
>> This change is algorithmically similar to the two previous versions:
>> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
>> Bits::reserveMemory(). For both of those versions and this change, a thread
>> calls that function and tries to reserve some space. If it fails, then it
>> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
>> cleaned. If reservation still fails, then it invokes the GC to try to
>> deactivate more cleaners for cleaning. After that GC it keeps trying the
>> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
>> eventually either succeeding or giving up and throwing OOME.
>> 
>> Retaining that algorithmic approach is one of the goals of this change, since
>> it has been successfully in use since JDK 9 (and was originally developed and
>> extensively tested in JDK 8).
>> 
>> The key to this approach is having a way to determine that deactivated
>> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
>> threads help the reference processor until there was no available work.
>> JDK-8156500 waits for the reference processor to quiesce, relying on its
>> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
>> to do this, which is why this change rolls its own Cleaner-like mechanism from
>> the underlying primitives. Like JDK-6857566, this change has waiting threads
>> help with cleaning references. This was a potentially undesirable feature of
>> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
>> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
>> became internal-only somewhere around that time as well.) That's not a concern
>> here, as the cleaners involved are only from DBB, and we know what they look
>> like.
>> 
>> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
>> being done off the reference processing thread, as it may be expensive and
>> slow down enqueuing other pending references. JDK-6857566 only did some of
>> that, and JDK-8156500 lost that feature. This change moves all of the DBB
>> cleaning off of the reference processing thread. (So does PR 22165.)
>> 
>> Neither JDK-6857566 nor this change are...
>
> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - add description of BufferCleaner class
>  - exception handling in cleaner for backward consistency
>  - detabify

src/java.base/share/classes/java/nio/BufferCleaner.java line 82:

> 80:                         new Error("nio Cleaner terminated abnormally", x).printStackTrace();
> 81:                     }
> 82:                     System.exit(1);

This is the same behavior as jdk.internal.ref.Cleaner, for which this class is
substituting in the new regime for DBB management. PR 22165 (and earlier
versions of this PR) put this in the DBB's Deallocator::run method, but I
think it's both clearer here, and better to leave the Deallocator as it was in
mainline and be more consistent with the mainline code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2099400318

From jlu at openjdk.org  Wed May 21 06:28:54 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 21 May 2025 06:28:54 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <lErNIJyBSEaDtbZk91B6GQtqHc0o2qqGOaI-MH0r5ns=.404cffc7-5422-4b1d-b081-48bb8b9cf67a@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <lErNIJyBSEaDtbZk91B6GQtqHc0o2qqGOaI-MH0r5ns=.404cffc7-5422-4b1d-b081-48bb8b9cf67a@github.com>
Message-ID: <fl9VCx915VdNP3Bk-y4znN3OUM7_sfRJc5XMBHKf0Sk=.19862ac2-2908-424b-afd1-7939b9c0f79e@github.com>

On Tue, 20 May 2025 21:57:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

src/java.base/share/classes/java/io/Console.java line 67:

> 65:  * stdout.encoding}, in which case read operations use the {@code Charset}
> 66:  * designated by {@code stdin.encoding}.
> 67:  * <p>

`Console.charset()` states "The returned charset is used for interpreting the input and output source (e.g., keyboard and/or display) specified by the host environment or user, which defaults to the one based on stdout.encoding." If _stdin.encoding_ is set otherwise, this is no longer true, so I think this method may need a wording update as well.

test/jdk/java/io/Console/StdinEncodingTest.java line 38:

> 36:  * @test
> 37:  * @bug 8356985
> 38:  * @summary Tests if "stdin.encoding" is reflected for reading

Would be helpful to include why the test is limited to only linux and mac,

> "expect" command in Windows/Cygwin does not work as expected. Ignoring tests on Windows.

test/jdk/java/io/Console/StdinEncodingTest.java line 51:

> 49:         // check "expect" command availability
> 50:         var expect = Paths.get("/usr/bin/expect");
> 51:         if (!Files.exists(expect) || !Files.isExecutable(expect)) {

Could use `Assumptions.assumeTrue` here. Condition becomes more readable as: `Files.exists(expect) && Files.isExecutable(expect)`

test/jdk/java/io/Console/StdinEncodingTest.java line 56:

> 54: 
> 55:         // invoking "expect" command
> 56:         var testSrc = System.getProperty("test.src", ".");

The test already imports the JDK test lib, can we just replace this and the below ocurrences with `jdk.test.lib.Utils.TEST_SRC/JDK/CLASSES` directly?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099438513
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099441523
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099447047
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099443105

From duke at openjdk.org  Wed May 21 06:54:37 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Wed, 21 May 2025 06:54:37 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v6]
In-Reply-To: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
Message-ID: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com>

> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails

PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:

  address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24948/files
  - new: https://git.openjdk.org/jdk/pull/24948/files/b3ccffd7..5e1f9240

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=04-05

  Stats: 51 lines in 3 files changed: 12 ins; 17 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/24948.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24948/head:pull/24948

PR: https://git.openjdk.org/jdk/pull/24948

From duke at openjdk.org  Wed May 21 06:54:37 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Wed, 21 May 2025 06:54:37 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v5]
In-Reply-To: <F-9h51qLUK9yyhVSh34kmS777BKVrfRJnrotkrFDhv0=.e78360fa-0fb3-4814-bbfd-2b54dfff0503@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <U7dpc8IRZHFCXm8OJTMkrmNNuVbEXCzwWctZxiMj1gU=.b66cd9dd-74ad-4c65-9c5d-1a915d43fada@github.com>
 <F-9h51qLUK9yyhVSh34kmS777BKVrfRJnrotkrFDhv0=.e78360fa-0fb3-4814-bbfd-2b54dfff0503@github.com>
Message-ID: <o3w-RnUbz2C8b58KL9r6FYIyuo8tF-ohw7xoWO3xNtA=.3e35e598-533a-4a5a-b9c0-410e71eabd42@github.com>

On Thu, 15 May 2025 16:21:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused import
>
> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 73:
> 
>> 71:             return;
>> 72:         }
>> 73:         if (IS_DOCKER && ContainerRuntimeVersionTestUtils.DOCKER_VERSION_20_10_0.compareTo(ContainerRuntimeVersionTestUtils.getContainerRuntimeVersion()) > 0) {
> 
> Better to replace this with 
> `isContainerVersionSupported()`
> ...
> and implement all logic in the the ContainerRuntimeVersionTestUtils

created checkContainerVersionSupported()

> test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 38:
> 
>> 36:     private final int micro;
>> 37:     private static final ContainerRuntimeVersionTestUtils DEFAULT = new ContainerRuntimeVersionTestUtils(0, 0, 0);
>> 38:     public static final ContainerRuntimeVersionTestUtils DOCKER_VERSION_20_10_0 = new ContainerRuntimeVersionTestUtils(20, 10, 0);
> 
> Please add comment about meaning of the version or even better rename 
> DOCKER_MINIMAL_SUPPORTED_VERSION = ....

updated name to  DOCKER_MINIMAL_SUPPORTED_VERSION_CGROUPNS and PODMAN_MINIMAL_SUPPORTED_VERSION_CGROUPNS

> test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 53:
> 
>> 51:         } else if (this.major < other.major) {
>> 52:             return -1;
>> 53:         } else { // equal major
> 
> no need to add `else {` here

updated

> test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 58:
> 
>> 56:             } else if (this.minor < other.minor) {
>> 57:                 return -1;
>> 58:             } else { // equal majors and minors
> 
> no need to add `else {` here

updated

> test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 81:
> 
>> 79:         } catch (Exception e) {
>> 80:             System.out.println("Failed to parse container runtime version: " + version);
>> 81:             return DEFAULT;
> 
> Any reason to don't fail here?

updated

> test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 94:
> 
>> 92:         } catch (Exception e) {
>> 93:             System.out.println(Container.ENGINE_COMMAND + " --version command failed. Returning null");
>> 94:             return null;
> 
> Any reason to don't fail here?

updated

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099494838
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099496846
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099494004
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099494142
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099497419
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099497254

From jlahoda at openjdk.org  Wed May 21 07:07:55 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 21 May 2025 07:07:55 GMT
Subject: RFR: 8354323: Safeguard SwitchBootstraps.typeSwitch when used
 outside the compiler [v3]
In-Reply-To: <cbTTjOpj_o-DygYlZWeN74wFETw3RFWawy_xGk2T9Qk=.d74b62b8-eb54-4120-81e3-e7fa7c7411f3@github.com>
References: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
 <cbTTjOpj_o-DygYlZWeN74wFETw3RFWawy_xGk2T9Qk=.d74b62b8-eb54-4120-81e3-e7fa7c7411f3@github.com>
Message-ID: <q_Ko2D4QpAhghC-fHPWmngMrgrKAb_4asIszx3ymPwM=.708712aa-b6c1-4617-b27a-c36a6187d256@github.com>

On Tue, 13 May 2025 09:56:31 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation.
>> 
>> For example this is not valid Java (and protected) by javac:
>> 
>> 
>> byte b = 1;
>> switch (b) {
>>     case String s -> System.out.println("How did we get here? byte is " + s.getClass());
>> }
>> 
>> 
>> but this is a valid call (and not protected):
>> 
>> 
>> CallSite shortSwitch = SwitchBootstraps.typeSwitch(
>>     MethodHandles.lookup(), 
>>     "", 
>>     MethodType.methodType(int.class, short.class, int.class),  // models (short, int) -> int
>>     String.class);
>> 
>> 
>> The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. 
>> 
>> This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify unconditional exactness in both Types and SwitchBootstraps

Looks reasonable to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25090#pullrequestreview-2856549641

From jlahoda at openjdk.org  Wed May 21 07:23:07 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 21 May 2025 07:23:07 GMT
Subject: RFR: 8347050: Console.readLine() drops '\' when reading through
 JLine [v2]
In-Reply-To: <CrRA1pKBHMYHwGSTVCA4j_TTDsl56xMZ4jG_cd-KBhg=.97ee6b8b-06db-4831-ab6e-a15242df941b@github.com>
References: <CrRA1pKBHMYHwGSTVCA4j_TTDsl56xMZ4jG_cd-KBhg=.97ee6b8b-06db-4831-ab6e-a15242df941b@github.com>
Message-ID: <UwoOmfmFLX4yoa_KFHaRf9ox5oPzEROA_g_3RQLrIkw=.6b6573c1-05a4-4235-a7e1-fb57fc9605fa@github.com>

> JLine can do history expansion, and interpret escapes, when returning a value. That is not desirable when using JLine as a backend for Console.readLine().
> 
> This PR proposes to disable the history expansion.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Fixing test on Windows.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25326/files
  - new: https://git.openjdk.org/jdk/pull/25326/files/fbf17434..392cede8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25326&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25326&range=00-01

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25326.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25326/head:pull/25326

PR: https://git.openjdk.org/jdk/pull/25326

From alanb at openjdk.org  Wed May 21 07:54:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 May 2025 07:54:05 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v10]
In-Reply-To: <kdkI3citrqw1Om9J75aWr8LHi-PFwb-sh3Aw1t78Sa4=.1a4f5e94-fb14-4478-8134-47d4fa953110@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <kdkI3citrqw1Om9J75aWr8LHi-PFwb-sh3Aw1t78Sa4=.1a4f5e94-fb14-4478-8134-47d4fa953110@github.com>
Message-ID: <uAsziZVgH6n8drU6WyRT2BvmoEiLWwGeC33UtWelqyI=.5623b0d7-a5ee-414d-b0df-409dd4f2adee@github.com>

On Tue, 20 May 2025 15:05:17 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweaking exact wording.

src/jdk.zipfs/share/classes/module-info.java line 264:

> 262:  *               {@linkplain Runtime.Version Java SE Platform version number},
> 263:  *               an {@code IllegalArgumentException} will be thrown when the Zip
> 264:  *               filesystem is created.

Minor comment, I think you want "when creating the ZIP file system" here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2099609806

From cay.horstmann at gmail.com  Wed May 21 07:55:07 2025
From: cay.horstmann at gmail.com (Cay Horstmann)
Date: Wed, 21 May 2025 09:55:07 +0200
Subject: Towards a JSON API for the JDK
In-Reply-To: <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
 <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
 <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>
 <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com>
 <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr>
 <CAGZD2TAbv+dQQJCTbpQqa3LVFB90vqBZ-9sbcynAZpOE32bxag@mail.gmail.com>
 <CB7705F0-77B5-4119-BB77-D05D87B270F5@oracle.com>
 <CAGZD2TDQf8CtDXt0=Qdt50AAb-Ktouq2cA9L33pFCzBTwDEhqA@mail.gmail.com>
 <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com>
Message-ID: <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com>

Data binding is indeed complex because real-life JSON is messy. I reviewed some code in which I use Jackson data binding. Here is an example of a sticky issue. I have Content that's either a list of strings or a list of string pairs (don't ask). The JSON is

{ "strings": [..., ..., ... ] }

or

{ "pairs": [ { "first", ..., "second", ... },  ..., ... ]

The JavaScript client relies on the fact that exactly one of "strings" and "pairs" exists. No, I can't change the JSON.

I deserialize into a record Content(List<String> strings, List<Pair<String>> pairs) {}. And tweak Jackson to not to serialize entries with null values. It's not pretty, but it is easier than doing tree navigation, since this sits deeply in an otherwise fairly regular structure.

Could that work with Serialization 2.0? I suppose. Looking at https://www.youtube.com/watch?v=mIbA2ymCWDs, a marshaller can't dynamically produce either a List<String> or a List<Pair<String>>, so it would offer both in the Marshalled<Content> object, with one of them being null. I would need to tell the wire format generator to write the non-null one. Which is ok--that's what I do now with Jackson.

Here is another common issue. You have a record TimedPoint(int x, int y, Instant when) {}. How do you want to serialize the Instant? As an ISO 8601 string? Millis since the epoch? Who makes that choice? Slide 29 says "Let the class author be in charge". WHICH class author? Can java.time.Instant make a universal choice, for all possible wire formats? Surely not. Can TimedPoint? Maybe. Or it is the job of the wire format generator to do that with Marshalled<TimedPoint>?.

So here is my point. If the JDK were to include a JSON data mapper, that data mapper is either rigid or flexible. Designing a flexible data mapper is hard. Serialization 2.0 would not make it any easier.

My hunch is that flexible JSON data mapping is hard to do within the scope of the JDK. Would it follow Jakarta JSON Binding and be tied to that spec? Or strike out on its own? Neither seems attractive.

Ethan and R?mi have presented rigid JSON mappers. They handle nothing but numbers, strings, booleans, maps, lists, records. Is that useful? Surely, for simple programs. For that, there is no reason to wait for Serialization 2.0. If and when that comes, it would be a natural extension.

Cheers,

Cay

Il 20/05/25 21:46, Paul Sandoz ha scritto:
> Data binding is a complex feature, even if some examples make it appear simple. Our intention is to explore alignment with the serialization 2.0 effort, when we are ready to so. Hence, I would urge folks to be patience and watch out Brian and Viktor?s Devoxx 2024 talk on the topic.
> 
> Paul.
> 
>> On May 20, 2025, at 12:21?PM, Swaranga Sarma <sarma.swaranga at gmail.com> wrote:
>>
>>> A potential advantage that we (the OpenJDK community) can more easily do is devise an API that resonates with direction the Java platform is heading, specifically around the pattern matching and serialization 2.0
>>
>> Right, but most of the discussion here seems to be on the low level tree API and how one might navigate it (perhaps using pattern matching). I am not seeing any discussion on the serialization/deserialization or any reasoning why that is not the goal of the new JEP. Basically a very focused and narrow API:
>>
>> ```
>> var jsonStr = "..."
>> var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a few other variants
>> var serialized = Json.serialize(myRecord)
>> ```
>>
>> This leaves the tree API open to reimplementation later when pattern matching and other features are firmly in place in the JDK. I am making a case that this would be more immediately useful for the most common and simpler cases.
>>
>>
>> Regards
>> Swaranga
> 

-- 

Cay S. Horstmann | https://horstmann.com


From vyazici at openjdk.org  Wed May 21 08:23:54 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 21 May 2025 08:23:54 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <gjZaymAsEf2eto9WZwSgSOCBVCy4n_3-CYUaIrGDaKI=.a6168cc0-d6b9-4685-97d9-82eba329680b@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <Pup4nswVBdebz4T4tOR33WuL7iedobsLXh-FjSh4e6E=.7eb43d7b-4c9a-490e-9a1f-168fee7bdf9b@github.com>
 <ogXKGEuLuPNjbiKf2n8GLsIAUAgCqs6alj69rYqGMDU=.c72dc1a5-dfa2-44dc-a808-81162dec14b6@github.com>
 <gjZaymAsEf2eto9WZwSgSOCBVCy4n_3-CYUaIrGDaKI=.a6168cc0-d6b9-4685-97d9-82eba329680b@github.com>
Message-ID: <RiE9-8g0F1QOLT3xhcxUIWC6CR_TcisqFwPX9omahWM=.f39c6e44-8378-4ed6-b0b9-5a5aa252cded@github.com>

On Tue, 20 May 2025 22:04:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> All `FileDescriptor.in` encounters in `jdk.internal.org.jline.terminal` that might need attention:
>> 
>> src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/DumbTerminalProvider.java
>> src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/exec/ExecPty.java
>> src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/FfmTerminalProvider.java
>
> JLine is a 3rd party library. It would be desirable that they change their implementation to separately handle in/out in their terminal, but that is out of scope of this PR

Created jline/jline3#1282.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099671435

From shade at openjdk.org  Wed May 21 08:28:57 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 May 2025 08:28:57 GMT
Subject: RFR: 8357179: Deprecate VFORK launch mechanism from Process
 implementation (linux) [v2]
In-Reply-To: <lgOLwRhfzwJw-Ko6kpSorv9CaXd9bqiij6X6JSuM8yw=.4f788f75-541d-4e45-97d3-8bb5e4beedf6@github.com>
References: <KZUCnliZBaa1PgMeT9PSEQ26BttrtNGZed2I70C0Mbc=.d66fb189-2d88-420c-a8bd-227cb2b817cb@github.com>
 <lgOLwRhfzwJw-Ko6kpSorv9CaXd9bqiij6X6JSuM8yw=.4f788f75-541d-4e45-97d3-8bb5e4beedf6@github.com>
Message-ID: <Nw0FOu2Jodk0FhjWi77mdu-X0HHi7oIN4Be-0SNhAXA=.515854f0-e120-4721-bd21-b062af7a26d0@github.com>

On Mon, 19 May 2025 16:59:06 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> For the ratio behind this please see the companion CSR: https://bugs.openjdk.org/browse/JDK-8357180.
>> 
>> We plan to deprecate this in JDK 25 and to remove it in JDK 26.
>> 
>> This patch just writes a deprecation message to stderr:
>> 
>> 
>> 08:46:38 thomas at starfish java -Djdk.lang.Process.launchMechanism=VFORK SimpleSpawn ls
>> VFORK MODE DEPRECATED
>> The VFORK launch mechanism has been deprecated for being dangerous.
>> It will be removed in a future java version. Either remove the
>> jdk.lang.Process.launchMechanism property (preferred) or use FORK mode
>> instead (-Djdk.lang.Process.launchMechanism=FORK).
>> ...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use string block

`VFORK` deprecation sneaked up on me. I filed [JDK-8357436](https://bugs.openjdk.org/browse/JDK-8357436) to amend `jspawnhelper` warning message.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25282#issuecomment-2897063928

From vyazici at openjdk.org  Wed May 21 08:32:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 21 May 2025 08:32:53 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com>
Message-ID: <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com>

On Tue, 20 May 2025 22:04:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/io/Console/StdinEncodingTest.java line 46:
>> 
>>> 44:  * @run junit StdinEncodingTest
>>> 45:  */
>>> 46: public class StdinEncodingTest {
>> 
>> AFAICT, there is no similar test (e.g., one using a mock `CharsetProvider`) for `stdout.encoding`. Will it be addressed by another ticket? Shall we consider adding a similar `StdoutEncodingTest` too? (Not necessarily in this PR.)
>
> `stdout.encoding` validity is tested through the public `charset()` mehtod, which is in `CharsetTest.java`

Indeed there *are* `stdout.encoding` tests in `test/jdk/java/io/Console`, yet none<sup>1</sup> that thoroughly tests them with `expect` and a dedicated (mock) `CharsetProvider` as you did here. FWIW, I really liked your new test using a mock `CharsetProvider` in combination with `expect`, hence my question for doing same for stdout and stderr too.

For the record, AFAICT, there are no tests for `stderr.encoding`.

<sup>1</sup> There is `script.exp`, but it tests `sun.stdout.encoding`, not `stdout.encoding`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099692717

From shade at openjdk.org  Wed May 21 08:39:30 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 May 2025 08:39:30 GMT
Subject: RFR: 8357436: Change jspawnhelper warning recommendation from VFORK to
 FORK
Message-ID: <zp4Z2FRyTA1q32_9z9SQTEdmpW2xLI3N6Bu_0w8jee8=.4c8e8f63-7bdf-4362-aa36-a7d1219a1e0b@github.com>

In [JDK-8352533](https://bugs.openjdk.org/browse/JDK-8352533), we print the suggestion to use VFORK in jspawnhelper misbehaves. But [JDK-8357179](https://bugs.openjdk.org/browse/JDK-8357179) deprecated VFORK! So the warning message should actually suggest using FORK. This seems to be in line with [JDK-8357180](https://bugs.openjdk.org/browse/JDK-8357180) CSR discussion and the pending [JDK-8357181](https://bugs.openjdk.org/browse/JDK-8357181) release note.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `java/lang/Process java/lang/ProcessBuilder`

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/25344/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25344&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357436
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25344.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25344/head:pull/25344

PR: https://git.openjdk.org/jdk/pull/25344

From shade at openjdk.org  Wed May 21 08:39:30 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 May 2025 08:39:30 GMT
Subject: RFR: 8357436: Change jspawnhelper warning recommendation from
 VFORK to FORK
In-Reply-To: <zp4Z2FRyTA1q32_9z9SQTEdmpW2xLI3N6Bu_0w8jee8=.4c8e8f63-7bdf-4362-aa36-a7d1219a1e0b@github.com>
References: <zp4Z2FRyTA1q32_9z9SQTEdmpW2xLI3N6Bu_0w8jee8=.4c8e8f63-7bdf-4362-aa36-a7d1219a1e0b@github.com>
Message-ID: <bvy-du6Lr3nt0F3lvRSYsJeLEQjp3ROpXZ2x444YCAU=.51e0e0f5-c216-4a5d-83d5-ce17be9d1ce9@github.com>

On Wed, 21 May 2025 08:34:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In [JDK-8352533](https://bugs.openjdk.org/browse/JDK-8352533), we print the suggestion to use VFORK in jspawnhelper misbehaves. But [JDK-8357179](https://bugs.openjdk.org/browse/JDK-8357179) deprecated VFORK! So the warning message should actually suggest using FORK. This seems to be in line with [JDK-8357180](https://bugs.openjdk.org/browse/JDK-8357180) CSR discussion and the pending [JDK-8357181](https://bugs.openjdk.org/browse/JDK-8357181) release note.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/lang/Process java/lang/ProcessBuilder`

@tstuefe ^

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25344#issuecomment-2897095489

From viktor.klang at oracle.com  Wed May 21 08:56:07 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 21 May 2025 08:56:07 +0000
Subject: Towards a JSON API for the JDK
In-Reply-To: <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
 <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
 <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>
 <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com>
 <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr>
 <CAGZD2TAbv+dQQJCTbpQqa3LVFB90vqBZ-9sbcynAZpOE32bxag@mail.gmail.com>
 <CB7705F0-77B5-4119-BB77-D05D87B270F5@oracle.com>
 <CAGZD2TDQf8CtDXt0=Qdt50AAb-Ktouq2cA9L33pFCzBTwDEhqA@mail.gmail.com>
 <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com>
 <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com>
Message-ID: <MW4PR10MB57745DC0F6A03ACA50B6AD96FF9EA@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi,

The way to layer a cake like this is as follows:

[ class ]                         <- describes the general structure of the type (the types, names, and order of the parameter lists)
[ instance ]                  <- describes the specific structure of the instance (the values)
[ structure ]                 <- converts to/from structure to instance (think constructor / deconstructor pairs)
[ specific format ]    <-  converts to/from structure to specific format (think MyCompany JSON Order format version 5)
[ general format]      <- parses / generates the general format (think XML / JSON / CSV / etc)
[ IO ]                               <- reads / writes the general format (think file / socket / etc)


As for the question how to represent a Timestamp or similar, is answered in the [specific format] layer of this cake. Why? Because the next version of the specification of that layer might change how timestamps should be represented at that layer.

Now, while it is possible to short-circuit some of the layers of the cake by embedding specific format decisions at the class level, it means that there's now a tight (and somewhat exclusive) link between a specific format and class, with the implication that you cannot output the same instance as both XML and JSON (as it embeds the decisions of a specific json schema. If that was the default, and only, way to go about this, what specific format should a library decide to adhere to?

The cake layering at the beginning of this email allows types to be used by many different specific formats and even general formats, such that you could read something from JSON-over-HTTPS and output it as XML-over-SFTP.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Cay Horstmann <cay.horstmann at gmail.com>
Sent: Wednesday, 21 May 2025 09:55
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: Towards a JSON API for the JDK

Data binding is indeed complex because real-life JSON is messy. I reviewed some code in which I use Jackson data binding. Here is an example of a sticky issue. I have Content that's either a list of strings or a list of string pairs (don't ask). The JSON is

{ "strings": [..., ..., ... ] }

or

{ "pairs": [ { "first", ..., "second", ... },  ..., ... ]

The JavaScript client relies on the fact that exactly one of "strings" and "pairs" exists. No, I can't change the JSON.

I deserialize into a record Content(List<String> strings, List<Pair<String>> pairs) {}. And tweak Jackson to not to serialize entries with null values. It's not pretty, but it is easier than doing tree navigation, since this sits deeply in an otherwise fairly regular structure.

Could that work with Serialization 2.0? I suppose. Looking at https://www.youtube.com/watch?v=mIbA2ymCWDs, a marshaller can't dynamically produce either a List<String> or a List<Pair<String>>, so it would offer both in the Marshalled<Content> object, with one of them being null. I would need to tell the wire format generator to write the non-null one. Which is ok--that's what I do now with Jackson.

Here is another common issue. You have a record TimedPoint(int x, int y, Instant when) {}. How do you want to serialize the Instant? As an ISO 8601 string? Millis since the epoch? Who makes that choice? Slide 29 says "Let the class author be in charge". WHICH class author? Can java.time.Instant make a universal choice, for all possible wire formats? Surely not. Can TimedPoint? Maybe. Or it is the job of the wire format generator to do that with Marshalled<TimedPoint>?.

So here is my point. If the JDK were to include a JSON data mapper, that data mapper is either rigid or flexible. Designing a flexible data mapper is hard. Serialization 2.0 would not make it any easier.

My hunch is that flexible JSON data mapping is hard to do within the scope of the JDK. Would it follow Jakarta JSON Binding and be tied to that spec? Or strike out on its own? Neither seems attractive.

Ethan and R?mi have presented rigid JSON mappers. They handle nothing but numbers, strings, booleans, maps, lists, records. Is that useful? Surely, for simple programs. For that, there is no reason to wait for Serialization 2.0. If and when that comes, it would be a natural extension.

Cheers,

Cay

Il 20/05/25 21:46, Paul Sandoz ha scritto:
> Data binding is a complex feature, even if some examples make it appear simple. Our intention is to explore alignment with the serialization 2.0 effort, when we are ready to so. Hence, I would urge folks to be patience and watch out Brian and Viktor?s Devoxx 2024 talk on the topic.
>
> Paul.
>
>> On May 20, 2025, at 12:21?PM, Swaranga Sarma <sarma.swaranga at gmail.com> wrote:
>>
>>> A potential advantage that we (the OpenJDK community) can more easily do is devise an API that resonates with direction the Java platform is heading, specifically around the pattern matching and serialization 2.0
>>
>> Right, but most of the discussion here seems to be on the low level tree API and how one might navigate it (perhaps using pattern matching). I am not seeing any discussion on the serialization/deserialization or any reasoning why that is not the goal of the new JEP. Basically a very focused and narrow API:
>>
>> ```
>> var jsonStr = "..."
>> var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a few other variants
>> var serialized = Json.serialize(myRecord)
>> ```
>>
>> This leaves the tree API open to reimplementation later when pattern matching and other features are firmly in place in the JDK. I am making a case that this would be more immediately useful for the most common and simpler cases.
>>
>>
>> Regards
>> Swaranga
>

--

Cay S. Horstmann | https://horstmann.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250521/2228a6a4/attachment-0001.htm>

From stuefe at openjdk.org  Wed May 21 08:56:50 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 May 2025 08:56:50 GMT
Subject: RFR: 8357436: Change jspawnhelper warning recommendation from
 VFORK to FORK
In-Reply-To: <zp4Z2FRyTA1q32_9z9SQTEdmpW2xLI3N6Bu_0w8jee8=.4c8e8f63-7bdf-4362-aa36-a7d1219a1e0b@github.com>
References: <zp4Z2FRyTA1q32_9z9SQTEdmpW2xLI3N6Bu_0w8jee8=.4c8e8f63-7bdf-4362-aa36-a7d1219a1e0b@github.com>
Message-ID: <OIl_u46l69wI8Rqt5T_nI_j871lijx2ufj3njkxrf_M=.398a7ccb-9ebd-4bef-bbf1-26211b5dcfbb@github.com>

On Wed, 21 May 2025 08:34:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In [JDK-8352533](https://bugs.openjdk.org/browse/JDK-8352533), we print the suggestion to use VFORK in jspawnhelper misbehaves. But [JDK-8357179](https://bugs.openjdk.org/browse/JDK-8357179) deprecated VFORK! So the warning message should actually suggest using FORK. This seems to be in line with [JDK-8357180](https://bugs.openjdk.org/browse/JDK-8357180) CSR discussion and the pending [JDK-8357181](https://bugs.openjdk.org/browse/JDK-8357181) release note.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/lang/Process java/lang/ProcessBuilder`

Good and trivial

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25344#pullrequestreview-2856881363

From duke at openjdk.org  Wed May 21 09:04:34 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 21 May 2025 09:04:34 GMT
Subject: RFR: 8356891: Some code simplifications in BigInteger [v20]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <3FTt6zYsaifvbJyGHiZ1D4-1RB4wjnzv7FtE9haF8Zw=.43b952b0-283a-4765-8173-628da63ad519@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Use one less counter in makePositive(int[])

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/6267a258..9a354abf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=18-19

  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From duke at openjdk.org  Wed May 21 09:07:35 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 21 May 2025 09:07:35 GMT
Subject: RFR: 8356891: Some code simplifications in BigInteger [v21]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <whgwOpf-8uqwR6B9BHquyxSHcIZVkOUqlT_0-td64kc=.74752912-22fa-4b90-8530-adb06ed26f60@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Correct typo in comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/9a354abf..85f03605

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=19-20

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From tvaleev at openjdk.org  Wed May 21 09:09:15 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 21 May 2025 09:09:15 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v2]
In-Reply-To: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
Message-ID: <w-jdj2tTfuMPgqeQkUG3dxP8-LkygRZAlQtRvEtxnfU=.3e83d2dd-5c8d-48d0-9d6c-a86f599f8825@github.com>

> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
> 
> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
> 
> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Return first argument in case of tie (to be consistent with BinaryOperator); junit tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25297/files
  - new: https://git.openjdk.org/jdk/pull/25297/files/2cda59b7..9edc73e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=00-01

  Stats: 20 lines in 2 files changed: 6 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/25297.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25297/head:pull/25297

PR: https://git.openjdk.org/jdk/pull/25297

From duke at openjdk.org  Wed May 21 09:12:49 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 21 May 2025 09:12:49 GMT
Subject: RFR: 8356891: Some code simplifications in BigInteger [v22]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <u9D52c9WxdI9AWB_bPAz3I5nKirlkyddQjMdjkhZDTA=.5005597b-67fb-43a8-a9ee-eeeee3d0cc31@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Correct typo in comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/85f03605..eb3834e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=20-21

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From tvaleev at openjdk.org  Wed May 21 09:13:55 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 21 May 2025 09:13:55 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface
In-Reply-To: <KUYOP8M6SQqPy38DmkhDUZeDAack1YjwBMrLqo0wtmw=.e4724a5e-7a36-41ab-b5c8-96b9f5fa03ab@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <KUYOP8M6SQqPy38DmkhDUZeDAack1YjwBMrLqo0wtmw=.e4724a5e-7a36-41ab-b5c8-96b9f5fa03ab@github.com>
Message-ID: <lWF0tUh9XOwdgT8pDVB7-uh1A-Co_A75mZTXNA6kMcU=.c0dd96f7-f45a-4f18-a1e4-8ddf7d993097@github.com>

On Mon, 19 May 2025 17:06:17 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
>> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
>> 
>> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
>> 
>> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.
>
> @amaembo Could you please switch the test class to make use of [JUnit](https://junit.org/junit5/)? For new tests we now prefer JUnit over TestNG.
> Thanks!

@rgiulietti I tried to mimic the nearby tests which use testng. Converted to junit 5.

@archiecobbs 
> IMHO it makes sense. It's the min/max analog to a stable sort

On the second thought, there is a consistency argument. We already have BinaryOperator.minBy and BinaryOperator.maxBy, which always return the first argument in case of tie (though this is not specified, probably it should be?). So it looks like it will be better to have both APIs consistent. One more point is that Guava's [`Ordering`](https://guava.dev/releases/snapshot-jre/api/docs/com/google/common/collect/Ordering.html#max(E,E)) (which extends `Comparator`) also returns the first argument in case of tie, so if we do the same, `Ordering` will not violate the `Comparator` contract. Thus I've changed the implementation to be in sync with both BinaryOperator and Ordering. This also addresses the @RogerRiggs comment: now implementations use `>=` and `<=`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-2897204193

From duke at openjdk.org  Wed May 21 10:02:54 2025
From: duke at openjdk.org (Stefan Lobbenmeier)
Date: Wed, 21 May 2025 10:02:54 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v2]
In-Reply-To: <35OauyGRBboCkDKqCm9OWVJ6suePq0MBtzQ2Sj0Fctk=.c12a1dce-4aab-4ca6-b134-7a2d24395a42@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <2GLmGAWCUplxhAeiwVfOKzXw_RDZQedXbgK3lqdzAfw=.730af4f3-4506-43ad-9379-b8d3d380dae5@github.com>
 <35OauyGRBboCkDKqCm9OWVJ6suePq0MBtzQ2Sj0Fctk=.c12a1dce-4aab-4ca6-b134-7a2d24395a42@github.com>
Message-ID: <FRMMIWVz_184ByS5Al3X8dixrva-18XTaIKd4fiHOPc=.16dd7db1-2a3e-41b8-b1fa-1a68e6075380@github.com>

On Wed, 21 May 2025 09:57:10 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties line 298:
>> 
>>> 296: \  --linux-menu-group <menu-group-name>\n\
>>> 297: \          Menu group this application is placed in\n\
>>> 298: \  --linux-package-deps <package-dep>[, <package-dep>...]\n\
>> 
>> The value of this CLI option is a string, not a comma-separated string list. For jpackage it is a "pass through" value.
>> Maybe
>> 
>> --linux-package-deps <package-dep-string>\n\
>> 
>> ?
>
> it is a comma separated string list for the underlying implementation but you would need to quote it so it is passed as a single arg. But I agree we can simplify this to <package-dep-string>
> 
> Suggestion:
> 
> \  --linux-package-deps <package-dep-string>\n\

As in, this worked in my testing: `--linux-package-deps "foo, bar"`, see https://github.com/JetBrains/compose-multiplatform/pull/5227#issuecomment-2659470908

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2099882692

From alanb at openjdk.org  Wed May 21 10:12:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 May 2025 10:12:58 GMT
Subject: RFR: 8357436: Change jspawnhelper warning recommendation from
 VFORK to FORK
In-Reply-To: <zp4Z2FRyTA1q32_9z9SQTEdmpW2xLI3N6Bu_0w8jee8=.4c8e8f63-7bdf-4362-aa36-a7d1219a1e0b@github.com>
References: <zp4Z2FRyTA1q32_9z9SQTEdmpW2xLI3N6Bu_0w8jee8=.4c8e8f63-7bdf-4362-aa36-a7d1219a1e0b@github.com>
Message-ID: <H9f11GHZffRty-f1L8u4g3vpX8XPG-8hTlNqbQmKzFc=.8269335b-de5a-4d04-a198-f20dc11e0444@github.com>

On Wed, 21 May 2025 08:34:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In [JDK-8352533](https://bugs.openjdk.org/browse/JDK-8352533), we print the suggestion to use VFORK in jspawnhelper misbehaves. But [JDK-8357179](https://bugs.openjdk.org/browse/JDK-8357179) deprecated VFORK! So the warning message should actually suggest using FORK. This seems to be in line with [JDK-8357180](https://bugs.openjdk.org/browse/JDK-8357180) CSR discussion and the pending [JDK-8357181](https://bugs.openjdk.org/browse/JDK-8357181) release note.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/lang/Process java/lang/ProcessBuilder`

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25344#pullrequestreview-2857120972

From markus at headcrashing.eu  Wed May 21 10:41:42 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Wed, 21 May 2025 12:41:42 +0200
Subject: RFR: 8347027: String replaceAll with Function<String, String>
In-Reply-To: <j54JsESf9b6YB14jeAx9nBktIQC0f3C6R7pbUWYYshU=.b0ec838f-6b1e-4bcb-ae3e-6890ab7bc2b7@github.com>
References: <j54JsESf9b6YB14jeAx9nBktIQC0f3C6R7pbUWYYshU=.b0ec838f-6b1e-4bcb-ae3e-6890ab7bc2b7@github.com>
Message-ID: <a5bf2579-3859-466e-ab7f-c7b7181ebacc@headcrashing.eu>

What is the benefit over the existing replacement methods? Is it easier 
to use, uses less resources, runs quicker...?

Am 20.05.2025 um 19:04 schrieb kieran-farrell:
> New API to the String.java class - replaceAllMapped(String, Function<MatchResult, String>) that allows regex based replacement via a user defined function allowing dynamic replacemnt based on the match. It delegates to the already existing Pattern.matcher().replaceAll(Function).
>
> -------------
>
> Commit messages:
>   - whitespace
>   - updates
>   - replaceAllMapped and test
>
> Changes: https://git.openjdk.org/jdk/pull/25335/files
>    Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25335&range=00
>    Issue: https://bugs.openjdk.org/browse/JDK-8347027
>    Stats: 61 lines in 3 files changed: 61 ins; 0 del; 0 mod
>    Patch: https://git.openjdk.org/jdk/pull/25335.diff
>    Fetch: git fetch https://git.openjdk.org/jdk.git pull/25335/head:pull/25335
>
> PR: https://git.openjdk.org/jdk/pull/25335

From duke at openjdk.org  Wed May 21 10:43:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 21 May 2025 10:43:12 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v11]
In-Reply-To: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
Message-ID: <qlaFI_zmptAcRgWznwJpk54yR6dOdtMlyh8Bkb0NRew=.b7c70e00-9c60-44de-9c98-87c0d2e1f235@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Tweaking exact wording.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/793e1856..ab15123a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=09-10

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

PR: https://git.openjdk.org/jdk/pull/25178

From shade at openjdk.org  Wed May 21 10:56:59 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 May 2025 10:56:59 GMT
Subject: RFR: 8357436: Change jspawnhelper warning recommendation from
 VFORK to FORK
In-Reply-To: <zp4Z2FRyTA1q32_9z9SQTEdmpW2xLI3N6Bu_0w8jee8=.4c8e8f63-7bdf-4362-aa36-a7d1219a1e0b@github.com>
References: <zp4Z2FRyTA1q32_9z9SQTEdmpW2xLI3N6Bu_0w8jee8=.4c8e8f63-7bdf-4362-aa36-a7d1219a1e0b@github.com>
Message-ID: <Ar2DrpYl2wAZ82NmzqCanGFJlVYqxp97hgXbDcoQlHk=.2599dd95-7472-45ea-9444-8f9678a1cb4c@github.com>

On Wed, 21 May 2025 08:34:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In [JDK-8352533](https://bugs.openjdk.org/browse/JDK-8352533), we print the suggestion to use VFORK in jspawnhelper misbehaves. But [JDK-8357179](https://bugs.openjdk.org/browse/JDK-8357179) deprecated VFORK! So the warning message should actually suggest using FORK. This seems to be in line with [JDK-8357180](https://bugs.openjdk.org/browse/JDK-8357180) CSR discussion and the pending [JDK-8357181](https://bugs.openjdk.org/browse/JDK-8357181) release note.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/lang/Process java/lang/ProcessBuilder`

Thanks! GHA is green. Integrating under triviality rule.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25344#issuecomment-2897507616

From shade at openjdk.org  Wed May 21 10:57:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 May 2025 10:57:00 GMT
Subject: Integrated: 8357436: Change jspawnhelper warning recommendation from
 VFORK to FORK
In-Reply-To: <zp4Z2FRyTA1q32_9z9SQTEdmpW2xLI3N6Bu_0w8jee8=.4c8e8f63-7bdf-4362-aa36-a7d1219a1e0b@github.com>
References: <zp4Z2FRyTA1q32_9z9SQTEdmpW2xLI3N6Bu_0w8jee8=.4c8e8f63-7bdf-4362-aa36-a7d1219a1e0b@github.com>
Message-ID: <2SylRci5Iu6U0ktfhgysI5cAHjG2ADdkHagF1lviV-M=.feb2f2a7-70fa-4df1-9ed8-3a329d03e398@github.com>

On Wed, 21 May 2025 08:34:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In [JDK-8352533](https://bugs.openjdk.org/browse/JDK-8352533), we print the suggestion to use VFORK in jspawnhelper misbehaves. But [JDK-8357179](https://bugs.openjdk.org/browse/JDK-8357179) deprecated VFORK! So the warning message should actually suggest using FORK. This seems to be in line with [JDK-8357180](https://bugs.openjdk.org/browse/JDK-8357180) CSR discussion and the pending [JDK-8357181](https://bugs.openjdk.org/browse/JDK-8357181) release note.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/lang/Process java/lang/ProcessBuilder`

This pull request has now been integrated.

Changeset: b8057cf1
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8057cf103bff6f8e2600c098519289a43227362
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8357436: Change jspawnhelper warning recommendation from VFORK to FORK

Reviewed-by: stuefe, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25344

From jpai at openjdk.org  Wed May 21 11:05:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 11:05:52 GMT
Subject: RFR: 8357165: test java/lang/invoke/ClassValueTest.java fails
 intermittently
In-Reply-To: <i1B1gJuokz34xZAlURjip2LvwLnx7bCE04Ye3H3F7-g=.aa67b2d1-3dff-4be3-8250-49ab6ce5aad6@github.com>
References: <i1B1gJuokz34xZAlURjip2LvwLnx7bCE04Ye3H3F7-g=.aa67b2d1-3dff-4be3-8250-49ab6ce5aad6@github.com>
Message-ID: <PHOk3wXsDDhPhie7MxYJQhxq-AyooNI9xON5-TB3Xos=.c06103f0-b55d-4771-a286-b81d6255956a@github.com>

On Sun, 18 May 2025 21:58:04 GMT, Chen Liang <liach at openjdk.org> wrote:

> The test was originally written with product builds in mind; it didn't consider the slowness of debug builds, thus causing tests to fail.
> 
> Also there was a bug in testWeakAgainstClassValue: the test need to flush the backing map in the class to have the weak value removed. It is fixed in this patch as well.
> 
> Testing: ClassValueTest repeated 10 times on windows-x64/linux-x64/macosx-aarch64/linux-aarch64 fastdebug.

Hello Chen, in general for tests like these we don't use any explicit timeout value for waiting on certain condition. It's based on our past experiences in the CI and various other test runtime environments where no timeout value is a "right" timeout and can cause intermittent timeouts like here.

In this test, I think we should just switch to using `await()` and `join()` i.e. no specific timeouts. If there is any bug (either in the test or the product code) and the test doesn't complete, then the jtreg's timeout infrastructure will fail the test and at the same time has the necessary features to collect all necessary details to help debug those unexpected timeout failures.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25292#issuecomment-2897532321

From duke at openjdk.org  Wed May 21 11:17:56 2025
From: duke at openjdk.org (Stefan Lobbenmeier)
Date: Wed, 21 May 2025 11:17:56 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v2]
In-Reply-To: <oLxZu8TJCbSx5W89GiyA0cxVP5_KWrSVEadfz876iYg=.eea6c6dd-43e1-4887-8d62-986a1a8a3576@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <oLxZu8TJCbSx5W89GiyA0cxVP5_KWrSVEadfz876iYg=.eea6c6dd-43e1-4887-8d62-986a1a8a3576@github.com>
Message-ID: <vc_SVCRiUnvW_lw_7qdfoWNrauklSP4RTLeFaqXzLPI=.6b629099-7b5a-4ede-9207-8a7f335193bb@github.com>

On Wed, 21 May 2025 10:00:39 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

>> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space
>> 
>> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372
>
> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change cli option to single string as suggested in PR review

Also maybe one follow up question - what do I need to do so the change appears in older versions like
- https://docs.oracle.com/en/java/javase/21/docs/specs/man/jpackage.html
- https://docs.oracle.com/en/java/javase/17/docs/specs/man/jpackage.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2897563188

From cay.horstmann at gmail.com  Wed May 21 11:46:34 2025
From: cay.horstmann at gmail.com (Cay Horstmann)
Date: Wed, 21 May 2025 13:46:34 +0200
Subject: Towards a JSON API for the JDK
In-Reply-To: <MW4PR10MB57745DC0F6A03ACA50B6AD96FF9EA@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
 <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
 <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>
 <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com>
 <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr>
 <CAGZD2TAbv+dQQJCTbpQqa3LVFB90vqBZ-9sbcynAZpOE32bxag@mail.gmail.com>
 <CB7705F0-77B5-4119-BB77-D05D87B270F5@oracle.com>
 <CAGZD2TDQf8CtDXt0=Qdt50AAb-Ktouq2cA9L33pFCzBTwDEhqA@mail.gmail.com>
 <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com>
 <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com>
 <MW4PR10MB57745DC0F6A03ACA50B6AD96FF9EA@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <72885797-8da3-4da2-a73b-898d62021283@gmail.com>

That's exactly my point. The "specific format" issue doesn't get easier or harder with "serialization 2.0".

Il 21/05/25 10:56, Viktor Klang ha scritto:
> Hi,
> 
> The way to layer a cake like this is as follows:
> 
> [ class ]? ? ? ? ? ? ? ? ? ? ? ? ?<- describes the general structure of the type (the types, names, and order of the parameter lists)
> [ instance ]? ? ? ? ? ? ? ? ? <- describes the specific structure of the instance (the values)
> [ structure ]? ? ? ? ? ? ? ? ?<- converts to/from structure to instance (think constructor / deconstructor pairs)
> [ specific format ]? ? <-? converts to/from structure to specific format (think MyCompany JSON Order format version 5)
> [ general format]? ? ? <- parses / generates the general format (think XML / JSON / CSV / etc)
> [ IO ]? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?<- reads / writes the general format (think file / socket / etc)
> 
> 
> As for the question how to represent a Timestamp or similar, is answered in the [specific format] layer of this cake. Why? Because the next version of the specification of that layer might change how timestamps should be represented at that layer.
> 
> Now, while it is possible to short-circuit some of the layers of the cake by embedding *specific format*?decisions at the *class*?level, it means that there's now a tight (and somewhat exclusive) link between a *specific format*?and *class*, with the implication that you cannot output the same *instance*?as both XML and JSON (as it embeds the decisions of a specific *json schema*. If that was the default, and only, way to go about this, what *specific format*?should a library decide to adhere to?
> 
> The cake layering at the beginning of this email allows types to be used by many different *specific formats*?and even *general formats*, such that you could read something from JSON-over-HTTPS and output it as XML-over-SFTP.
> 
> Cheers,
> ?
> 
> *
> *
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Cay Horstmann <cay.horstmann at gmail.com>
> *Sent:* Wednesday, 21 May 2025 09:55
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: Towards a JSON API for the JDK
> Data binding is indeed complex because real-life JSON is messy. I reviewed some code in which I use Jackson data binding. Here is an example of a sticky issue. I have Content that's either a list of strings or a list of string pairs (don't ask). The JSON is
> 
> { "strings": [..., ..., ... ] }
> 
> or
> 
> { "pairs": [ { "first", ..., "second", ... },? ..., ... ]
> 
> The JavaScript client relies on the fact that exactly one of "strings" and "pairs" exists. No, I can't change the JSON.
> 
> I deserialize into a record Content(List<String> strings, List<Pair<String>> pairs) {}. And tweak Jackson to not to serialize entries with null values. It's not pretty, but it is easier than doing tree navigation, since this sits deeply in an otherwise fairly regular structure.
> 
> Could that work with Serialization 2.0? I suppose. Looking at https://www.youtube.com/watch?v=mIbA2ymCWDs <https://www.youtube.com/watch?v=mIbA2ymCWDs>, a marshaller can't dynamically produce either a List<String> or a List<Pair<String>>, so it would offer both in the Marshalled<Content> object, with one of them being null. I would need to tell the wire format generator to write the non-null one. Which is ok--that's what I do now with Jackson.
> 
> Here is another common issue. You have a record TimedPoint(int x, int y, Instant when) {}. How do you want to serialize the Instant? As an ISO 8601 string? Millis since the epoch? Who makes that choice? Slide 29 says "Let the class author be in charge". WHICH class author? Can java.time.Instant make a universal choice, for all possible wire formats? Surely not. Can TimedPoint? Maybe. Or it is the job of the wire format generator to do that with Marshalled<TimedPoint>?.
> 
> So here is my point. If the JDK were to include a JSON data mapper, that data mapper is either rigid or flexible. Designing a flexible data mapper is hard. Serialization 2.0 would not make it any easier.
> 
> My hunch is that flexible JSON data mapping is hard to do within the scope of the JDK. Would it follow Jakarta JSON Binding and be tied to that spec? Or strike out on its own? Neither seems attractive.
> 
> Ethan and R?mi have presented rigid JSON mappers. They handle nothing but numbers, strings, booleans, maps, lists, records. Is that useful? Surely, for simple programs. For that, there is no reason to wait for Serialization 2.0. If and when that comes, it would be a natural extension.
> 
> Cheers,
> 
> Cay
> 
> Il 20/05/25 21:46, Paul Sandoz ha scritto:
>> Data binding is a complex feature, even if some examples make it appear simple. Our intention is to explore alignment with the serialization 2.0 effort, when we are ready to so. Hence, I would urge folks to be patience and watch out Brian and Viktor?s Devoxx 2024 talk on the topic.
>> 
>> Paul.
>> 
>>> On May 20, 2025, at 12:21?PM, Swaranga Sarma <sarma.swaranga at gmail.com> wrote:
>>>
>>>> A potential advantage that we (the OpenJDK community) can more easily do is devise an API that resonates with direction the Java platform is heading, specifically around the pattern matching and serialization 2.0
>>>
>>> Right, but most of the discussion here seems to be on the low level tree API and how one might navigate it (perhaps using pattern matching). I am not seeing any discussion on the serialization/deserialization or any reasoning why that is not the goal of the new JEP. Basically a very focused and narrow API:
>>>
>>> ```
>>> var jsonStr = "..."
>>> var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a few other variants
>>> var serialized = Json.serialize(myRecord)
>>> ```
>>>
>>> This leaves the tree API open to reimplementation later when pattern matching and other features are firmly in place in the JDK. I am making a case that this would be more immediately useful for the most common and simpler cases.
>>>
>>>
>>> Regards
>>> Swaranga
>> 
> 
> -- 
> 
> Cay S. Horstmann | https://horstmann.com <https://horstmann.com>
> 

-- 

Cay S. Horstmann | https://horstmann.com


From rgiulietti at openjdk.org  Wed May 21 11:57:56 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 21 May 2025 11:57:56 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v2]
In-Reply-To: <w-jdj2tTfuMPgqeQkUG3dxP8-LkygRZAlQtRvEtxnfU=.3e83d2dd-5c8d-48d0-9d6c-a86f599f8825@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <w-jdj2tTfuMPgqeQkUG3dxP8-LkygRZAlQtRvEtxnfU=.3e83d2dd-5c8d-48d0-9d6c-a86f599f8825@github.com>
Message-ID: <9s3ZOLNJdFCYlyZd05FFtqNGqJjMuUCP8h_nRDsAmnY=.9fef14e2-51c8-439f-8f40-f71df65fea0e@github.com>

On Wed, 21 May 2025 09:09:15 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
>> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
>> 
>> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
>> 
>> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Return first argument in case of tie (to be consistent with BinaryOperator); junit tests

A couple of nits.

src/java.base/share/classes/java/util/Comparator.java line 200:

> 198:      * @return  the larger of {@code a} and {@code b} according to this comparator.
> 199:      * @throws  ClassCastException if the collection contains elements that are
> 200:      *          not <i>mutually comparable</i> (for example, strings and

`<em>` is more intent revealing.
Suggestion:

     *          not <em>mutually comparable</em> (for example, strings and

test/jdk/java/util/Comparator/MinMaxTest.java line 39:

> 37: public class MinMaxTest {
> 38:   @Test
> 39:   public void testMin() {

According to [this](https://junit.org/junit5/docs/snapshot/user-guide/#writing-tests-classes-and-methods), test methods do not need to be `public` (but cannot be `private`).

Suggestion:

  void testMin() {

-------------

PR Review: https://git.openjdk.org/jdk/pull/25297#pullrequestreview-2857412002
PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2100089152
PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2100089409

From asemenyuk at openjdk.org  Wed May 21 11:59:50 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 21 May 2025 11:59:50 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v2]
In-Reply-To: <oLxZu8TJCbSx5W89GiyA0cxVP5_KWrSVEadfz876iYg=.eea6c6dd-43e1-4887-8d62-986a1a8a3576@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <oLxZu8TJCbSx5W89GiyA0cxVP5_KWrSVEadfz876iYg=.eea6c6dd-43e1-4887-8d62-986a1a8a3576@github.com>
Message-ID: <SPRobujHK5qp7oQL-yRLKKwAQRHogbLDsbJJuZ5j59c=.28818ebe-887e-4389-9cff-23bea37b88d2@github.com>

On Wed, 21 May 2025 10:00:39 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

>> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space
>> 
>> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372
>
> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change cli option to single string as suggested in PR review

Thank you for making the change! Other property files and jpackage.md should also be updated to sync them with HelpResources.properties.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2897674146

From asemenyuk at openjdk.org  Wed May 21 11:59:51 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 21 May 2025 11:59:51 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v2]
In-Reply-To: <vc_SVCRiUnvW_lw_7qdfoWNrauklSP4RTLeFaqXzLPI=.6b629099-7b5a-4ede-9207-8a7f335193bb@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <oLxZu8TJCbSx5W89GiyA0cxVP5_KWrSVEadfz876iYg=.eea6c6dd-43e1-4887-8d62-986a1a8a3576@github.com>
 <vc_SVCRiUnvW_lw_7qdfoWNrauklSP4RTLeFaqXzLPI=.6b629099-7b5a-4ede-9207-8a7f335193bb@github.com>
Message-ID: <_iudidZ-9mKp7ED0Kae-FaxpxGnlOBLWC5frD64WIKo=.a3c262c1-31ea-474a-af86-eee909dcf191@github.com>

On Wed, 21 May 2025 11:15:08 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

> Also maybe one follow up question - what do I need to do so the change appears in older versions like

You need to backport this fix once it is integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2897676692

From asemenyuk at openjdk.org  Wed May 21 12:05:59 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 21 May 2025 12:05:59 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v2]
In-Reply-To: <FRMMIWVz_184ByS5Al3X8dixrva-18XTaIKd4fiHOPc=.16dd7db1-2a3e-41b8-b1fa-1a68e6075380@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <2GLmGAWCUplxhAeiwVfOKzXw_RDZQedXbgK3lqdzAfw=.730af4f3-4506-43ad-9379-b8d3d380dae5@github.com>
 <35OauyGRBboCkDKqCm9OWVJ6suePq0MBtzQ2Sj0Fctk=.c12a1dce-4aab-4ca6-b134-7a2d24395a42@github.com>
 <FRMMIWVz_184ByS5Al3X8dixrva-18XTaIKd4fiHOPc=.16dd7db1-2a3e-41b8-b1fa-1a68e6075380@github.com>
Message-ID: <dbZ87UXLFMgw7wbRK9B2bp9Tm3n-5Jb131bMvKUhLAw=.3300f4fa-3996-4b6e-b007-9ce536914577@github.com>

On Wed, 21 May 2025 10:00:03 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

> As in, this worked in my testing: --linux-package-deps "foo, bar"

Of course. You can put any string for `--linux-package-deps` option, jpackage will pass it as-is to the underlying tool. Unlike, e.g. `--arguments`, for which jpackage will tokenize the value into a string array.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2100114692

From asemenyuk at openjdk.org  Wed May 21 12:11:56 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 21 May 2025 12:11:56 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v2]
In-Reply-To: <oLxZu8TJCbSx5W89GiyA0cxVP5_KWrSVEadfz876iYg=.eea6c6dd-43e1-4887-8d62-986a1a8a3576@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <oLxZu8TJCbSx5W89GiyA0cxVP5_KWrSVEadfz876iYg=.eea6c6dd-43e1-4887-8d62-986a1a8a3576@github.com>
Message-ID: <AluEJYcNml6Q6DuYNdWEeJgy5Yy3GjVqVRhgkAK9Fh4=.8b3552bf-6bcd-4534-833e-4fe5aa0f285a@github.com>

On Wed, 21 May 2025 10:00:39 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

>> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space
>> 
>> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372
>
> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change cli option to single string as suggested in PR review

Changes requested by asemenyuk (Reviewer).

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties line 36:

> 34: MSG_Help_mac_install=\  --mac-dmg-content <Pfad zu zus??tzlichem Inhalt>[,<Pfad zu zus??tzlichem Inhalt>...]\n          Nimmt den gesamten referenzierten Inhalt in die DMG-Datei auf.\n          Diese Option kann mehrmals verwendet werden. \n
> 35: MSG_Help_mac_launcher=\  --mac-package-identifier <ID-Zeichenfolge>\n          Eine ID, die die Anwendung f??r macOS eindeutig identifiziert\n          Standardwert ist der Hauptklassenname.\n          Es d??rfen nur alphanumerische Zeichen (A-Z, a-z, 0-9), Bindestriche (-)\n          und Punkte (.) verwendet werden.\n  --mac-package-name <Namenszeichenfolge>\n          Name der Anwendung, wie in der Men??leiste angezeigt\n          Dieser kann vom Anwendungsnamen abweichen.\n          Er darf maximal 15 Zeichen enthalten und muss f??r die Anzeige\n          in der Men??leiste und im Infofenster der Anwendung geeignet sein.\n          Standardwert: Anwendungsname.\n  --mac-package-signing-prefix <Pr??fixzeichenfolge>\n          Beim Signieren des Anwendungspackages wird dieser Wert\n          allen zu signierenden Komponenten ohne vorhandene\n          Package-ID als Pr??fix vorangestellt.\n  --mac-sign\n          Anforderung zum Signieren des Packages oder des vordefinierten\n
 Anwendungsimages\n  --mac-signing-keychain <Schl??sselbundname>\n          Name des Schl??sselbundes f??r die Suche nach der Signaturidentit??t\n          Bei fehlender Angabe werden die Standardschl??sselbunde verwendet.\n  --mac-signing-key-user-name <Teamname>\n          Team- oder Benutzernamensteil der Apple-Signaturidentit??ten. Um direkt zu steuern,\n          welche Signaturidentit??t zum Signieren eines Anwendungsimages oder\n          Installationsprogramms verwendet wird, verwenden Sie --mac-app-image-sign-identity und/oder\n          --mac-installer-sign-identity. Diese Option kann nicht mit\n          --mac-app-image-sign-identity oder --mac-installer-sign-identity kombiniert werden.\n  --mac-app-image-sign-identity <identity>\n          Zum Signieren des Anwendungsimages verwendete Identit??t. Dieser Wert wird\n          direkt an die Option --sign des Tools "codesign" ??bergeben. Diese Option kann nicht\n          mit --mac-signing-key-user-name kombiniert werden.\n  
 --mac-installer-sign-identity <identity>\n          Zum Signieren des Installationsprogramms "pkg" verwendete Identit??t. Dieser Wert wird\n          direkt an die Option --sign des Tools "productbuild" ??bergeben. Diese Option\n          kann nicht mit --mac-signing-key-user-name kombiniert werden.\n  --mac-app-store\n          Gibt an, dass die jpackage-Ausgabe f??r den\n          Mac App Store bestimmt ist.\n  --mac-entitlements <Dateipfad>\n          Pfad zu einer Datei mit Berechtigungen, die beim Signieren\n          von ausf??hrbaren Dateien und Librarys im Bundle verwendet werden sollen.\n  --mac-app-category <Kategoriezeichenfolge>\n          Zeichenfolge f??r das Erstellen von LSApplicationCategoryType in\n          Anwendungs-plist. Standardwert: "utilities".\n
> 36: MSG_Help_linux_install=\  --linux-package-name <Packagename>\n          Name f??r das Linux-Package, Standardwert: Anwendungsname\n  --linux-deb-maintainer <E-Mail-Adresse>\n          Maintainer f??r .deb-Package\n  --linux-menu-group <Men??gruppenname>\n          Men??gruppe, in der diese Anwendung abgelegt wird\n  --linux-package-deps <Paketabh??ngigkeit>[, <Paketabh??ngigkeit>...]\n          Erforderliche Packages oder Funktionen f??r die Anwendung\n  --linux-rpm-license-type <Typzeichenfolge>\n          Typ der Lizenz ("License: <Wert>" der RPM-SPEC-Datei)\n  --linux-app-release <Releasewert>\n          Releasewert der RPM-SPEC-Datei <Name> oder \n          Debian-Revisionswert der DEB-Kontrolldatei\n  --linux-app-category <Kategoriewert>\n          Gruppenwert der RPM-SPEC-Datei <Name> oder \n          Abschnittswert der DEB-Kontrolldatei\n  --linux-shortcut\n          Erstellt eine Verkn??pfung f??r die Anwendung.\n

`--linux-package-deps <package-dep-string>` to sync with HelpResources.properties

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_ja.properties line 39:

> 37: MSG_Help_mac_launcher=\  --mac-package-identifier <ID string>\n          macOS???????????????????????????????????????????????????ID\n          ?????????????????????????????????????????????????????????????????????\n          ?????????(A-Z???a-z???0-9)???????????????(-)?????????????????????(.)????????????\n          ?????????????????????\n  --mac-package-name <name string>\n          ????????????????????????????????????????????????????????????????????????\n          ???????????????????????????????????????????????????\n          ???????????????16?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????\n          ?????????????????????????????????????????????????????????\n          ????????????????????????????????????????????????????????????????????????\n  --mac-package-signing-prefix <prefix string>\n          ???????????????????????????????????????????????????????????????\n          ????????????????????????ID????????????
 ??????????????????????????????????????????????????????\n          ???????????????????????????????????????????????????\n  --mac-sign\n          ???????????????????????????????????????????????????????????????????????????????????????????????????\n          ???????????????????????????\n  --mac-signing-keychain <keychain name>\n          ????????????????????????????????????????????????????????????????????????\n          ?????????????????????????????????????????????????????????????????????????????????\n  --mac-signing-key-user-name <team name>\n          Apple???????????????????????????????????????????????????????????????????????????\n          ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????\n          ?????????????????????--mac-app-image-sign-identity?????????\n          --mac-installer-sign-identity(??????????????????)?????????????????????????????????????????????\n          --mac-app-image-sign-identity?????????
 --mac-installer-sign-identity?????????????????????????????????????????????\n  --mac-app-image-sign-identity <identity>\n          ????????????????????????????????????????????????????????????????????????????????????????????????????????????\n          "codesign"????????????--sign????????????????????????????????????????????????????????????\n          \
> 38: --mac-signing-key-user-name?????????????????????????????????????????????\n  --mac-installer-sign-identity <identity>\n          "pkg"???????????????????????????????????????????????????????????????????????????????????????\n          "productbuild"????????????--sign????????????????????????????????????????????????????????????\n          --mac-signing-key-user-name?????????????????????????????????????????????\n  --mac-app-store\n          jpackage?????????Mac App Store??????????????????\n          ??????????????????\n  --mac-entitlements <file path>\n          ??????????????????????????????????????????????????????????????????????????????\n          ???????????????????????????????????????????????????\n  --mac-app-category <category string>\n          ???????????????????????????plist???LSApplicationCategoryType?????????????????????????????????????????????\n          ?????????????????????"utilities"?????????\n
> 39: MSG_Help_linux_install=\  --linux-package-name <package name>\n          Linux????????????????????????????????????????????????????????????????????????????????????????????????\n  --linux-deb-maintainer <email address>\n          .deb??????????????????Maintainer\n  --linux-menu-group <menu-group-name>\n          ?????????????????????????????????????????????????????????????????????????????????\n  --linux-package-deps <package-dep>[, <package-dep>...]\n          ??????????????????????????????????????????????????????????????????\n  --linux-rpm-license-type <type string>\n          ???????????????????????????(RPM .spec???"License: <value>")\n  --linux-app-release <release value>\n          RPM <name>.spec???????????????????????????????????????\n          DEB????????????????????????????????????Debian?????????????????????\n  --linux-app-category <category value>\n          RPM <name>.spec??????????????????????????????????????? \n           DEB???????????????????????????????????????????
 ???????????\n  --linux-shortcut\n          ?????????????????????????????????????????????????????????????????????\n

`--linux-package-deps <package-dep-string>` to sync with HelpResources.properties

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_zh_CN.properties line 37:

> 35: MSG_Help_mac_install=\  --mac-dmg-content <additional content path>[,<additional content path>...]\n          ?????? DMG ???????????????????????????\n          ??????????????????????????????\n
> 36: MSG_Help_mac_launcher=\  --mac-package-identifier <ID string>\n          ????????????????????? macOS ????????????????????????\n          ????????????????????????\n          ???????????????????????? (A-Z,a-z,0-9)???????????? (-) ???\n          ?????? (.) ?????????\n  --mac-package-name <name string>\n          ??????????????????????????????????????????\n          ???????????????????????????????????????\n          ?????????????????????????????? 16 ??????????????????\n          ????????????????????????????????????????????????????????????\n          ??????????????????????????????\n  --mac-package-signing-prefix <prefix string>\n          ?????????????????????????????????????????????????????????\n          ?????????????????????????????????????????????\n          ?????????????????????\n  --mac-sign\n          ???????????????????????????????????????????????????\n          ???????????????\n  --mac-signing-keychain <keychain name>\n          ?????????????????????????????????????????????
 ???\n          ????????????????????????????????????????????????\n  --mac-signing-key-user-name <team name>\n          Apple ?????????????????????????????????????????????????????????\n          ???????????????????????????????????????????????????????????????\n          ???????????????????????? --mac-app-image-sign-identity ???/???\n          --mac-installer-sign-identity?????????????????????\n          --mac-app-image-sign-identity ??? --mac-installer-sign-identity ???????????????\n  --mac-app-image-sign-identity <identity>\n          ??????????????????????????????????????????????????????????????????\n          ????????? "codesign" ????????? --sign ????????????????????????\n          ??? --mac-signing-key-user-name ???????????????\n  --mac-installer-sign-identity <identity>\n          ????????? "pkg" ???????????????????????????????????????????????????\n          ????????? "productbuild" ????????? --sign ????????????????????????\n          ??? --mac-signing-key-user-name ??????????????
 ?\n  --mac-app-store\n          ?????? jpackage ????????????\n          Mac App Store???\n  --mac-entitlements <file path>\n          ???????????????????????????????????????????????????????????????????????????\n          ?????????????????????????????????????????????\n  --mac-app-category <category string>\n          ???????????????????????? plist ??? LSApplicationCategoryType ???\n          ???????????????????????? "utilities"???\n
> 37: MSG_Help_linux_install=\  --linux-package-name <package name>\n          Linux ????????????????????????????????????????????????\n  --linux-deb-maintainer <email address>\n          .deb ????????????????????????\n  --linux-menu-group <menu-group-name>\n          ?????????????????????????????????\n  --linux-package-deps <package-dep>[, <package-dep>...]\n          ???????????????????????????????????????\n  --linux-rpm-license-type <type string>\n          ?????????????????????RPM .spec ??? "License: <value>"???\n  --linux-app-release <release value>\n          RPM <name>.spec ???????????????????????? \n          DEB ??????????????? Debian ????????????\n  --linux-app-category <category value>\n          RPM <name>.spec ?????????????????? \n          DEB ?????????????????????\n  --linux-shortcut\n          ????????????????????????????????????\n

`--linux-package-deps <package-dep-string>` to sync with HelpResources.properties

src/jdk.jpackage/share/man/jpackage.md line 426:

> 424: :   Menu group this application is placed in
> 425: 
> 426: <a id="option-linux-package-deps">`--linux-package-deps *package-dep* \[`,`*package-dep*...\]`</a>

Should be *package-dep-string* to sync with HelpResources.properties

-------------

PR Review: https://git.openjdk.org/jdk/pull/23638#pullrequestreview-2857464848
PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2100125034
PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2100125279
PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2100125547
PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2100122529

From viktor.klang at oracle.com  Wed May 21 12:34:04 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 21 May 2025 12:34:04 +0000
Subject: [External] : Re: Towards a JSON API for the JDK
In-Reply-To: <72885797-8da3-4da2-a73b-898d62021283@gmail.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
 <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
 <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>
 <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com>
 <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr>
 <CAGZD2TAbv+dQQJCTbpQqa3LVFB90vqBZ-9sbcynAZpOE32bxag@mail.gmail.com>
 <CB7705F0-77B5-4119-BB77-D05D87B270F5@oracle.com>
 <CAGZD2TDQf8CtDXt0=Qdt50AAb-Ktouq2cA9L33pFCzBTwDEhqA@mail.gmail.com>
 <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com>
 <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com>
 <MW4PR10MB57745DC0F6A03ACA50B6AD96FF9EA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <72885797-8da3-4da2-a73b-898d62021283@gmail.com>
Message-ID: <MW4PR10MB5774BB839D87573ACA1C1D34FF9EA@MW4PR10MB5774.namprd10.prod.outlook.com>

I'd say it's more nuanced than that?Serialization 2.0 can improve over Serializion 1.0 by allowing users to decide what their formats should be. With Serialization 1.0, it's Java Serialization.

Now, the act of defining (possibly bidirectional) conversions between the in-memory structure of classes and specific output formats typically needs to adhere to some form of specification (hence the word specific) so it definitely does help to know where such translation needs to occur, which is something Serialization 2.0 can make clear.

That was my point ?

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Cay Horstmann <cay.horstmann at gmail.com>
Sent: Wednesday, 21 May 2025 13:46
To: Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: [External] : Re: Towards a JSON API for the JDK

That's exactly my point. The "specific format" issue doesn't get easier or harder with "serialization 2.0".

Il 21/05/25 10:56, Viktor Klang ha scritto:
> Hi,
>
> The way to layer a cake like this is as follows:
>
> [ class ]                         <- describes the general structure of the type (the types, names, and order of the parameter lists)
> [ instance ]                  <- describes the specific structure of the instance (the values)
> [ structure ]                 <- converts to/from structure to instance (think constructor / deconstructor pairs)
> [ specific format ]    <-  converts to/from structure to specific format (think MyCompany JSON Order format version 5)
> [ general format]      <- parses / generates the general format (think XML / JSON / CSV / etc)
> [ IO ]                               <- reads / writes the general format (think file / socket / etc)
>
>
> As for the question how to represent a Timestamp or similar, is answered in the [specific format] layer of this cake. Why? Because the next version of the specification of that layer might change how timestamps should be represented at that layer.
>
> Now, while it is possible to short-circuit some of the layers of the cake by embedding *specific format* decisions at the *class* level, it means that there's now a tight (and somewhat exclusive) link between a *specific format* and *class*, with the implication that you cannot output the same *instance* as both XML and JSON (as it embeds the decisions of a specific *json schema*. If that was the default, and only, way to go about this, what *specific format* should a library decide to adhere to?
>
> The cake layering at the beginning of this email allows types to be used by many different *specific formats* and even *general formats*, such that you could read something from JSON-over-HTTPS and output it as XML-over-SFTP.
>
> Cheers,
> ?
>
> *
> *
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Cay Horstmann <cay.horstmann at gmail.com>
> *Sent:* Wednesday, 21 May 2025 09:55
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: Towards a JSON API for the JDK
> Data binding is indeed complex because real-life JSON is messy. I reviewed some code in which I use Jackson data binding. Here is an example of a sticky issue. I have Content that's either a list of strings or a list of string pairs (don't ask). The JSON is
>
> { "strings": [..., ..., ... ] }
>
> or
>
> { "pairs": [ { "first", ..., "second", ... },  ..., ... ]
>
> The JavaScript client relies on the fact that exactly one of "strings" and "pairs" exists. No, I can't change the JSON.
>
> I deserialize into a record Content(List<String> strings, List<Pair<String>> pairs) {}. And tweak Jackson to not to serialize entries with null values. It's not pretty, but it is easier than doing tree navigation, since this sits deeply in an otherwise fairly regular structure.
>
> Could that work with Serialization 2.0? I suppose. Looking at https://urldefense.com/v3/__https://www.youtube.com/watch?v=mIbA2ymCWDs__;!!ACWV5N9M2RV99hQ!LsgfRufAKIgg3ALBXdbz6jTNbzJptqAlG_6z0ni8APQD95TDUOJPleoK0Cy8aIGtoWlLL0BobnUi-Y-nTkfsczV05g$  <https://urldefense.com/v3/__https://www.youtube.com/watch?v=mIbA2ymCWDs__;!!ACWV5N9M2RV99hQ!LsgfRufAKIgg3ALBXdbz6jTNbzJptqAlG_6z0ni8APQD95TDUOJPleoK0Cy8aIGtoWlLL0BobnUi-Y-nTkfsczV05g$ >, a marshaller can't dynamically produce either a List<String> or a List<Pair<String>>, so it would offer both in the Marshalled<Content> object, with one of them being null. I would need to tell the wire format generator to write the non-null one. Which is ok--that's what I do now with Jackson.
>
> Here is another common issue. You have a record TimedPoint(int x, int y, Instant when) {}. How do you want to serialize the Instant? As an ISO 8601 string? Millis since the epoch? Who makes that choice? Slide 29 says "Let the class author be in charge". WHICH class author? Can java.time.Instant make a universal choice, for all possible wire formats? Surely not. Can TimedPoint? Maybe. Or it is the job of the wire format generator to do that with Marshalled<TimedPoint>?.
>
> So here is my point. If the JDK were to include a JSON data mapper, that data mapper is either rigid or flexible. Designing a flexible data mapper is hard. Serialization 2.0 would not make it any easier.
>
> My hunch is that flexible JSON data mapping is hard to do within the scope of the JDK. Would it follow Jakarta JSON Binding and be tied to that spec? Or strike out on its own? Neither seems attractive.
>
> Ethan and R?mi have presented rigid JSON mappers. They handle nothing but numbers, strings, booleans, maps, lists, records. Is that useful? Surely, for simple programs. For that, there is no reason to wait for Serialization 2.0. If and when that comes, it would be a natural extension.
>
> Cheers,
>
> Cay
>
> Il 20/05/25 21:46, Paul Sandoz ha scritto:
>> Data binding is a complex feature, even if some examples make it appear simple. Our intention is to explore alignment with the serialization 2.0 effort, when we are ready to so. Hence, I would urge folks to be patience and watch out Brian and Viktor?s Devoxx 2024 talk on the topic.
>>
>> Paul.
>>
>>> On May 20, 2025, at 12:21?PM, Swaranga Sarma <sarma.swaranga at gmail.com> wrote:
>>>
>>>> A potential advantage that we (the OpenJDK community) can more easily do is devise an API that resonates with direction the Java platform is heading, specifically around the pattern matching and serialization 2.0
>>>
>>> Right, but most of the discussion here seems to be on the low level tree API and how one might navigate it (perhaps using pattern matching). I am not seeing any discussion on the serialization/deserialization or any reasoning why that is not the goal of the new JEP. Basically a very focused and narrow API:
>>>
>>> ```
>>> var jsonStr = "..."
>>> var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a few other variants
>>> var serialized = Json.serialize(myRecord)
>>> ```
>>>
>>> This leaves the tree API open to reimplementation later when pattern matching and other features are firmly in place in the JDK. I am making a case that this would be more immediately useful for the most common and simpler cases.
>>>
>>>
>>> Regards
>>> Swaranga
>>
>
> --
>
> Cay S. Horstmann | https://urldefense.com/v3/__https://horstmann.com__;!!ACWV5N9M2RV99hQ!LsgfRufAKIgg3ALBXdbz6jTNbzJptqAlG_6z0ni8APQD95TDUOJPleoK0Cy8aIGtoWlLL0BobnUi-Y-nTkc1dP4WTA$  <https://urldefense.com/v3/__https://horstmann.com__;!!ACWV5N9M2RV99hQ!LsgfRufAKIgg3ALBXdbz6jTNbzJptqAlG_6z0ni8APQD95TDUOJPleoK0Cy8aIGtoWlLL0BobnUi-Y-nTkc1dP4WTA$ >
>

--

Cay S. Horstmann | https://urldefense.com/v3/__https://horstmann.com__;!!ACWV5N9M2RV99hQ!LsgfRufAKIgg3ALBXdbz6jTNbzJptqAlG_6z0ni8APQD95TDUOJPleoK0Cy8aIGtoWlLL0BobnUi-Y-nTkc1dP4WTA$

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250521/e8c82353/attachment-0001.htm>

From duke at openjdk.org  Wed May 21 12:34:55 2025
From: duke at openjdk.org (Stefan Lobbenmeier)
Date: Wed, 21 May 2025 12:34:55 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v2]
In-Reply-To: <AluEJYcNml6Q6DuYNdWEeJgy5Yy3GjVqVRhgkAK9Fh4=.8b3552bf-6bcd-4534-833e-4fe5aa0f285a@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <oLxZu8TJCbSx5W89GiyA0cxVP5_KWrSVEadfz876iYg=.eea6c6dd-43e1-4887-8d62-986a1a8a3576@github.com>
 <AluEJYcNml6Q6DuYNdWEeJgy5Yy3GjVqVRhgkAK9Fh4=.8b3552bf-6bcd-4534-833e-4fe5aa0f285a@github.com>
Message-ID: <dvI5GdavScQTc-PZJmpKcPp-Wwz-8eEpRIg_EUx3Eww=.d45042dc-1308-4a8f-9800-d65c5bd30ebf@github.com>

On Wed, 21 May 2025 12:07:52 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change cli option to single string as suggested in PR review
>
> src/jdk.jpackage/share/man/jpackage.md line 426:
> 
>> 424: :   Menu group this application is placed in
>> 425: 
>> 426: <a id="option-linux-package-deps">`--linux-package-deps *package-dep* \[`,`*package-dep*...\]`</a>
> 
> Should be *package-dep-string* to sync with HelpResources.properties

Suggestion:

<a id="option-linux-package-deps">`--linux-package-deps *package-dep-string*`</a>

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2100173717

From duke at openjdk.org  Wed May 21 12:41:24 2025
From: duke at openjdk.org (Stefan Lobbenmeier)
Date: Wed, 21 May 2025 12:41:24 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v3]
In-Reply-To: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
Message-ID: <zkBr9MToIDhhJ-Y7pgPbNqumbE1YtA9dlHmnJUApP5k=.287f87b7-44f0-46de-a314-c44702f16a2f@github.com>

> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space
> 
> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372

Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:

  also use <package-dep-string> in other locations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23638/files
  - new: https://git.openjdk.org/jdk/pull/23638/files/062239e7..91831e7e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23638&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23638&range=01-02

  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23638/head:pull/23638

PR: https://git.openjdk.org/jdk/pull/23638

From duke at openjdk.org  Wed May 21 12:41:24 2025
From: duke at openjdk.org (Stefan Lobbenmeier)
Date: Wed, 21 May 2025 12:41:24 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v2]
In-Reply-To: <SPRobujHK5qp7oQL-yRLKKwAQRHogbLDsbJJuZ5j59c=.28818ebe-887e-4389-9cff-23bea37b88d2@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <oLxZu8TJCbSx5W89GiyA0cxVP5_KWrSVEadfz876iYg=.eea6c6dd-43e1-4887-8d62-986a1a8a3576@github.com>
 <SPRobujHK5qp7oQL-yRLKKwAQRHogbLDsbJJuZ5j59c=.28818ebe-887e-4389-9cff-23bea37b88d2@github.com>
Message-ID: <yojpBJpc6GeWiuvYK4iw3cgvPEUjy-RO_B5uobNKJ8M=.f5bc9868-8079-4296-98eb-4bc7d52b26e5@github.com>

On Wed, 21 May 2025 11:56:31 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Thank you for making the change! Other property files and jpackage.md should also be updated to sync them with HelpResources.properties.

Done, sorry I missed them

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2897820039

From ethan at mccue.dev  Wed May 21 12:47:44 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Wed, 21 May 2025 08:47:44 -0400
Subject: Towards a JSON API for the JDK
In-Reply-To: <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
 <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
 <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>
 <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com>
 <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr>
 <CAGZD2TAbv+dQQJCTbpQqa3LVFB90vqBZ-9sbcynAZpOE32bxag@mail.gmail.com>
 <CB7705F0-77B5-4119-BB77-D05D87B270F5@oracle.com>
 <CAGZD2TDQf8CtDXt0=Qdt50AAb-Ktouq2cA9L33pFCzBTwDEhqA@mail.gmail.com>
 <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com>
 <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com>
Message-ID: <CA+NR86g24DOw7nHzND5zfU05HnCuwhwLr429cR6mT-DPAbJSjg@mail.gmail.com>

In the my world - which I am again very interested in revisiting once there
is a version of patterns I can touch - you may approach that problem in the
following way:

sealed interface Content extends JsonEncodable {
    static Content fromJson(Json json) {
        return switch (json) {
            case JsonObject obj when obj.get("pairs") != null -> new Pairs(
                    field(
                            obj,
                            "pairs",
                            pairs -> array(pairs, pair ->
Pair.fromJson(pair, string()))
                    )
            );
            case JsonObject obj when obj.get("strings") != null -> new
Strings(
                    field(obj, "strings", array(string()))
            );
            default ->
                    throw JsonDecodeException.of("Expected a top-level
\"pairs\" or \"strings\".", json);
        };
    }
}

record Pair<T>(T first, T second) {
    Json toJson(Function<T, ? extends JsonEncodable> f) {
        return Json.objectBuilder()
                .put("first", f.apply(first))
                .put("second", f.apply(second))
                .build();
    }

    static <T> Pair<T> fromJson(Json json, JsonDecoder<? extends T>
decoder) {
        return new Pair<>(
                field(json, "first", decoder),
                field(json, "second", decoder)
        );
    }
}

record Pairs(List<Pair<String>> value) implements Content {
    @Override
    public Json toJson() {
        return Json.objectBuilder()
                .put("pairs", Json.of(value, pair ->
pair.toJson(JsonString::of)))
                .build();
    }
}
record Strings(List<String> value) implements Content {
    @Override
    public Json toJson() {
        return Json.objectBuilder()
                .put("strings", Json.of(value, JsonString::of))
                .build();
    }
}

I think it is reasonable to expect/hope patterns can be an improvement on
the "yield value or throw" strategy of decoders, but I think this is
sufficient to show that this sort of task is not solely solvable via
databinding.

JSON is different from other "core capabilities" the JDK adds in that the
important factor here isn't only whether "there is an API which can
represent a JSON document," but also what form solving problems that
require JSON takes absent third-party APIs.

On Wed, May 21, 2025 at 3:56?AM Cay Horstmann <cay.horstmann at gmail.com>
wrote:

> Data binding is indeed complex because real-life JSON is messy. I reviewed
> some code in which I use Jackson data binding. Here is an example of a
> sticky issue. I have Content that's either a list of strings or a list of
> string pairs (don't ask). The JSON is
>
> { "strings": [..., ..., ... ] }
>
> or
>
> { "pairs": [ { "first", ..., "second", ... },  ..., ... ]
>
> The JavaScript client relies on the fact that exactly one of "strings" and
> "pairs" exists. No, I can't change the JSON.
>
> I deserialize into a record Content(List<String> strings,
> List<Pair<String>> pairs) {}. And tweak Jackson to not to serialize entries
> with null values. It's not pretty, but it is easier than doing tree
> navigation, since this sits deeply in an otherwise fairly regular structure.
>
> Could that work with Serialization 2.0? I suppose. Looking at
> https://www.youtube.com/watch?v=mIbA2ymCWDs, a marshaller can't
> dynamically produce either a List<String> or a List<Pair<String>>, so it
> would offer both in the Marshalled<Content> object, with one of them being
> null. I would need to tell the wire format generator to write the non-null
> one. Which is ok--that's what I do now with Jackson.
>
> Here is another common issue. You have a record TimedPoint(int x, int y,
> Instant when) {}. How do you want to serialize the Instant? As an ISO 8601
> string? Millis since the epoch? Who makes that choice? Slide 29 says "Let
> the class author be in charge". WHICH class author? Can java.time.Instant
> make a universal choice, for all possible wire formats? Surely not. Can
> TimedPoint? Maybe. Or it is the job of the wire format generator to do that
> with Marshalled<TimedPoint>?.
>
> So here is my point. If the JDK were to include a JSON data mapper, that
> data mapper is either rigid or flexible. Designing a flexible data mapper
> is hard. Serialization 2.0 would not make it any easier.
>
> My hunch is that flexible JSON data mapping is hard to do within the scope
> of the JDK. Would it follow Jakarta JSON Binding and be tied to that spec?
> Or strike out on its own? Neither seems attractive.
>
> Ethan and R?mi have presented rigid JSON mappers. They handle nothing but
> numbers, strings, booleans, maps, lists, records. Is that useful? Surely,
> for simple programs. For that, there is no reason to wait for Serialization
> 2.0. If and when that comes, it would be a natural extension.
>
> Cheers,
>
> Cay
>
> Il 20/05/25 21:46, Paul Sandoz ha scritto:
> > Data binding is a complex feature, even if some examples make it appear
> simple. Our intention is to explore alignment with the serialization 2.0
> effort, when we are ready to so. Hence, I would urge folks to be patience
> and watch out Brian and Viktor?s Devoxx 2024 talk on the topic.
> >
> > Paul.
> >
> >> On May 20, 2025, at 12:21?PM, Swaranga Sarma <sarma.swaranga at gmail.com>
> wrote:
> >>
> >>> A potential advantage that we (the OpenJDK community) can more easily
> do is devise an API that resonates with direction the Java platform is
> heading, specifically around the pattern matching and serialization 2.0
> >>
> >> Right, but most of the discussion here seems to be on the low level
> tree API and how one might navigate it (perhaps using pattern matching). I
> am not seeing any discussion on the serialization/deserialization or any
> reasoning why that is not the goal of the new JEP. Basically a very focused
> and narrow API:
> >>
> >> ```
> >> var jsonStr = "..."
> >> var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a
> few other variants
> >> var serialized = Json.serialize(myRecord)
> >> ```
> >>
> >> This leaves the tree API open to reimplementation later when pattern
> matching and other features are firmly in place in the JDK. I am making a
> case that this would be more immediately useful for the most common and
> simpler cases.
> >>
> >>
> >> Regards
> >> Swaranga
> >
>
> --
>
> Cay S. Horstmann | https://horstmann.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250521/4e5bd433/attachment-0001.htm>

From jpai at openjdk.org  Wed May 21 12:49:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 12:49:55 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <PsoyPBx8Ayu9MaNQoao_JYd6OLb8Omp7TuSJQUa9P5k=.de0888a1-ac2d-4691-ad0a-80b16d29f69e@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
 <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
 <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>
 <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com>
 <PphfDWen7gKIUoGPV2NnZ2M7_LB47Rd2VmpzTnKDpGk=.5415e56a-eb35-4c65-bca5-692457061f11@github.com>
 <PsoyPBx8Ayu9MaNQoao_JYd6OLb8Omp7TuSJQUa9P5k=.de0888a1-ac2d-4691-ad0a-80b16d29f69e@github.com>
Message-ID: <Ax8PvcYBimeOnK_3CrsKLOXKpEWqb2ISH-IYCPjvPHc=.f77d4095-d575-42b6-84a8-b46704d81912@github.com>

On Tue, 20 May 2025 22:00:39 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Yes I understand and currently we have no documentation as to what the return values might be.  An inconsistency in the order should also be 1 based we only return a 0 if there are no issues.  Any warning should be treated the same
>> 
>> My point is that it is worth considering with these changes
>
> Point taken. For documentation wise, I don't think it's necessary to specify at this point.
> For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.

Hello Lance/Henry,

> Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc...

I think from a specification point of view, for this current PR, we should only specify that the `--validate` operation returns a non-zero exit code when the `--validate` operation identifies any issues in the JAR file or the validation operation itself runs into some error. For the latter, where the operation itself runs into an error, we could explicitly state that the exit code will be `-1` (for example). For the case where the validate operation has identified issues in the JAR file, I think we should just return a single consistent non-zero code, irrespective of which validations failed. 

Using a separate exit code for different validation failures I think would make it hard to maintain as the number of validations increase in future and when more than one validation failure happens in the JAR file. What we could however consider is specifying the exact error message (or error string, imagine `ERR-12345` for duplicate entry names) that get reported for these individual validation failures.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100203673

From jpai at openjdk.org  Wed May 21 13:00:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 13:00:58 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <Ax8PvcYBimeOnK_3CrsKLOXKpEWqb2ISH-IYCPjvPHc=.f77d4095-d575-42b6-84a8-b46704d81912@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
 <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
 <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>
 <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com>
 <PphfDWen7gKIUoGPV2NnZ2M7_LB47Rd2VmpzTnKDpGk=.5415e56a-eb35-4c65-bca5-692457061f11@github.com>
 <PsoyPBx8Ayu9MaNQoao_JYd6OLb8Omp7TuSJQUa9P5k=.de0888a1-ac2d-4691-ad0a-80b16d29f69e@github.com>
 <Ax8PvcYBimeOnK_3CrsKLOXKpEWqb2ISH-IYCPjvPHc=.f77d4095-d575-42b6-84a8-b46704d81912@github.com>
Message-ID: <h8HAePVzWzxJTsr6oiT7gEAuBNdIWGwGwLm_Htd50Ws=.09efd46e-cd36-43b1-a6f0-1f18275edbac@github.com>

On Wed, 21 May 2025 12:47:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Point taken. For documentation wise, I don't think it's necessary to specify at this point.
>> For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.
>
> Hello Lance/Henry,
> 
>> Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc...
> 
> I think from a specification point of view, for this current PR, we should only specify that the `--validate` operation returns a non-zero exit code when the `--validate` operation identifies any issues in the JAR file or the validation operation itself runs into some error. For the latter, where the operation itself runs into an error, we could explicitly state that the exit code will be `-1` (for example). For the case where the validate operation has identified issues in the JAR file, I think we should just return a single consistent non-zero code, irrespective of which validations failed. 
> 
> Using a separate exit code for different validation failures I think would make it hard to maintain as the number of validations increase in future and when more than one validation failure happens in the JAR file. What we could however consider is specifying the exact error message (or error string, imagine `ERR-12345` for duplicate entry names) that get reported for these individual validation failures.

> For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.

For the `jar --validate` operation, it would be useful to not just warn (and thus exit with a non-zero exit code) for issues that violate the ZIP or JAR specification, but also for inconsistencies and uncommon JAR contents that might cause some unexpected behaviour within the platform runtime. This helps with identifying and analyzing such unexpected issues in the JAR (but not strictly violations of any specification) even before that JAR gets used in the platform runtime. This is no different for the duplicate entries in the JAR file, for which we issue warnings even if the ZIP specification explicitly allows it (and the JAR specification doesn't make a mention of it).

Based on some experiments we have run, it's not very common for a JAR file to have a different order in CEN as compared to LOC, so I think any JAR file that has a different order between these structures should result in a warning (and thus a non-zero exit code) from the validate operation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100232060

From duke at openjdk.org  Wed May 21 13:49:38 2025
From: duke at openjdk.org (serhiysachkov)
Date: Wed, 21 May 2025 13:49:38 GMT
Subject: RFR: 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java test
 scenario to run as manual
Message-ID: <IMl8opuemVxRGiD46GfPuh0eZ1d6R86xkOdc3HIsT1I=.228f1873-ee56-4c22-919b-afd86dc8cc20@github.com>

Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual

-------------

Commit messages:
 - 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual

Changes: https://git.openjdk.org/jdk/pull/25355/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25355&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357462
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25355.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25355/head:pull/25355

PR: https://git.openjdk.org/jdk/pull/25355

From erikj at openjdk.org  Wed May 21 13:53:37 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 May 2025 13:53:37 GMT
Subject: RFR: 8357173: Split jtreg test group jdk tier3 [v2]
In-Reply-To: <4H8A-53zl5Hm126KxHdtjZifalF8ZRZuknZlI--9qV0=.6c711365-6b7d-41c7-b2dd-b155bd114181@github.com>
References: <4H8A-53zl5Hm126KxHdtjZifalF8ZRZuknZlI--9qV0=.6c711365-6b7d-41c7-b2dd-b155bd114181@github.com>
Message-ID: <hUHJK_xigEn8RYwEXskv9FTwQqb18SNCKy-28uSPyAE=.5c0144e8-da7d-4e72-95dc-c8f05b0a7e06@github.com>

> We need to be able to run the jdk_jpackage tests separately from the rest of jdk tier3. To achieve this we would like to introduce tier3_part1 and tier3_part2 groups similar to how lower tiers are split.

Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision:

 - grammar
 - Clarified the group split with comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25274/files
  - new: https://git.openjdk.org/jdk/pull/25274/files/c12c5780..dc18705a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25274&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25274&range=00-01

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25274.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25274/head:pull/25274

PR: https://git.openjdk.org/jdk/pull/25274

From erikj at openjdk.org  Wed May 21 13:53:37 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 May 2025 13:53:37 GMT
Subject: RFR: 8357173: Split jtreg test group jdk tier3
In-Reply-To: <4H8A-53zl5Hm126KxHdtjZifalF8ZRZuknZlI--9qV0=.6c711365-6b7d-41c7-b2dd-b155bd114181@github.com>
References: <4H8A-53zl5Hm126KxHdtjZifalF8ZRZuknZlI--9qV0=.6c711365-6b7d-41c7-b2dd-b155bd114181@github.com>
Message-ID: <d9w11YBFS7XaBBqqjx8YQA9BZghkmcnK0ocUKpA9oMM=.5d138243-84bf-449c-bea3-ff8cf6b67866@github.com>

On Fri, 16 May 2025 20:16:02 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> We need to be able to run the jdk_jpackage tests separately from the rest of jdk tier3. To achieve this we would like to introduce tier3_part1 and tier3_part2 groups similar to how lower tiers are split.

Renamed tier3_part2 -> tier3_jpackage and added comments better detailing the reason and where to add additional tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25274#issuecomment-2898044824

From jpai at openjdk.org  Wed May 21 13:55:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 13:55:53 GMT
Subject: RFR: 8357145: CRC/Inflater/Deflater/Adler32 methods that take a
 ByteBuffer throw UOE if backed by shared memory segment
In-Reply-To: <Zks5m0BcfxrtFdXPJ4xcKApNAGbShsytTBut1nc6NCM=.52d25dbd-0145-4f11-bebd-f535e15c513a@github.com>
References: <Zks5m0BcfxrtFdXPJ4xcKApNAGbShsytTBut1nc6NCM=.52d25dbd-0145-4f11-bebd-f535e15c513a@github.com>
Message-ID: <MBzJlmRjqCjO-CcGBQ-J9Z3FEFxbX2QZV_kow2qo9bM=.941c8d76-cbbf-4e32-85f7-53c5b64950bf@github.com>

On Tue, 20 May 2025 07:37:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to use ` JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` in the package `java.util.zip` so that `Buffer` instances backed by `MemorySegment` instances can be used.
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

src/java.base/share/classes/java/util/zip/Adler32.java line 102:

> 100:             NIO_ACCESS.acquireSession(buffer);
> 101:             try {
> 102:                 adler = updateByteBuffer(adler, NIO_ACCESS.getBufferAddress(buffer), pos, rem);

Hello Per, from what I can see in the implementation of `NIO_ACCESS.getBufferAddress(...)` it merely returns `buffer.address` https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/Buffer.java#L862. So if I understand this change correctly, what we are proposing here is that we want to avoid the additional checks (checks related to `MemorySegment` that can fail?) that are there in the `DirectBuffer.address()` method implementation? Is that what this change is addressing?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25321#discussion_r2100361279

From lancea at openjdk.org  Wed May 21 14:02:58 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 21 May 2025 14:02:58 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <h8HAePVzWzxJTsr6oiT7gEAuBNdIWGwGwLm_Htd50Ws=.09efd46e-cd36-43b1-a6f0-1f18275edbac@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
 <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
 <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>
 <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com>
 <PphfDWen7gKIUoGPV2NnZ2M7_LB47Rd2VmpzTnKDpGk=.5415e56a-eb35-4c65-bca5-692457061f11@github.com>
 <PsoyPBx8Ayu9MaNQoao_JYd6OLb8Omp7TuSJQUa9P5k=.de0888a1-ac2d-4691-ad0a-80b16d29f69e@github.com>
 <Ax8PvcYBimeOnK_3CrsKLOXKpEWqb2ISH-IYCPjvPHc=.f77d4095-d575-42b6-84a8-b46704d81912@github.com>
 <h8HAePVzWzxJTsr6oiT7gEAuBNdIWGwGwLm_Htd50Ws=.09efd46e-cd36-43b1-a6f0-1f18275edbac@github.com>
Message-ID: <1k_uCX5TM9o-ewEsAvEeG16VPUqRo9BwnwPOQdJuqYA=.e2930b9d-89c9-4664-b663-8434fec12718@github.com>

On Wed, 21 May 2025 12:58:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello Lance/Henry,
>> 
>>> Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc...
>> 
>> I think from a specification point of view, for this current PR, we should only specify that the `--validate` operation returns a non-zero exit code when the `--validate` operation identifies any issues in the JAR file or the validation operation itself runs into some error. For the latter, where the operation itself runs into an error, we could explicitly state that the exit code will be `-1` (for example). For the case where the validate operation has identified issues in the JAR file, I think we should just return a single consistent non-zero code, irrespective of which validations failed. 
>> 
>> Using a separate exit code for different validation failures I think would make it hard to maintain as the number of validations increase in future and when more than one validation failure happens in the JAR file. What we could however consider is specifying the exact error message (or error string, imagine `ERR-12345` for duplicate entry names) that get reported for these individual validation failures.
>
>> For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.
> 
> For the `jar --validate` operation, it would be useful to not just warn (and thus exit with a non-zero exit code) for issues that violate the ZIP or JAR specification, but also for inconsistencies and uncommon JAR contents that might cause some unexpected behaviour within the platform runtime. This helps with identifying and analyzing such unexpected issues in the JAR (but not strictly violations of any specification) even before that JAR gets used in the platform runtime. This is no different for the duplicate entries in the JAR file, for which we issue warnings even if the ZIP specification explicitly allows it (and the JAR specification doesn't make a mention of it).
> 
> Based on some experiments we have run, it's not very common for a JAR file to have a different order in CEN as compared to LOC, so I think any JAR file that has a different order between these structures should result in a warning (and thus a non-zero exit code) from the validate operation.

> Point taken. For documentation wise, I don't think it's necessary to specify at this point. For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.

I am OK to currently specify as non-zero, it is a discussion that can be continued as to what if anything more to do (as Jai mentions)

Any warnings should result in a non-zero for a return code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100377057

From duke at openjdk.org  Wed May 21 14:12:57 2025
From: duke at openjdk.org (kieran-farrell)
Date: Wed, 21 May 2025 14:12:57 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v3]
In-Reply-To: <aeb3sh4-fM8iC0R4xhatMynB7i2VUbZcWTFpOf882ss=.d86cf934-b407-4207-aad1-fc2b468d1cd0@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <Jm4ATGoFWP2a8HSBuwAglmdQS5fcBKBxt7TOklUQRjk=.b47ef4c7-26cd-4603-a074-76be89fa898c@github.com>
 <gfboyaqw8NXiohbBi1Q0cWStFPuvXI6RFMUoIMtaJVM=.2c27a47a-dc32-4d5f-b3ba-35dd00f4b106@github.com>
 <pD8XqEflVmkHQIAn0enmOXPR3JYRvrC3eR_X0Cm1Jyc=.3bbff99b-b1d0-41d7-992e-1185c8bdc671@github.com>
 <cYhyGDeePCnlPTzDgcRQfCnXQtDoCukifEOa2bvxeuM=.2eb9307c-9926-42de-8a2f-0dd17d69718c@github.com>
 <aeb3sh4-fM8iC0R4xhatMynB7i2VUbZcWTFpOf882ss=.d86cf934-b407-4207-aad1-fc2b468d1cd0@github.com>
Message-ID: <r0XNpJL9PwSXCH4RbQHZN7DOkhI-5L4P8CB_h-seEvY=.681f2d53-72f7-4f60-bca3-c16b0df8b0cb@github.com>

On Tue, 20 May 2025 19:37:31 GMT, Philippe Marschall <duke at openjdk.org> wrote:

>> There's no (time-based) relationship between the currentTimeMillis() value and the nanoTime value.
>> They are independent clocks and are read separately and are un-correlated. They won't be usable as lsb of the millis value.
>> 
>> I'm surprised that the `nextBytes` is slower, since it looks like it calls `nextLong` and puts it in a newly allocated byte[8].  Normal perf measurements won't account for the gc overhead to recover it.
>> 
>> The nsBits computation looks odd, nanoTme returns nanoseconds (10^9), the remainder (% 1_000_000) is then milliseconds.
>
>> if so, I've tried out some variations, i found creating the 64 bit lsb with ng.nextLong() brings a large pefomance decrease over using the nextBytes method
> 
> Probably because `SecureRandom` gets `#nextLong()` from `Random`, which ends up calling `#next(int)` twice, so it allocates twice. Overriding `#nextLong()` in `SecureRandom` may help a little but will still have to allocate as long as `SecureRandomSpi` is not updated.

The nsBytes were included to give some additional but not guaranteed monotonicity in the event of msTime collisions on a single instance of a JVM. I updated the method to print the msTime and nsBits for visual purposes seen below. The nsBits increase until cycling back to a lower value on the last or +/- 1 of the last instance of the same msTime value as tested on Linux and MacOS . I'm not sure of the reason why the cycles are almost in sync given that the times are not linked. However Marschall has pointed out that nanoTime() resolution is weaker on windows so maybe its not something that can be depended on. In that case I could revert to the random byte only implementation and remove the nsBytes fro random data.

As for the nsBits computation, in order to align with the RFC, my understanding was to get the remainder of nsTime (% 1_000_000) to get the nanoseconds within the current millisecond, divide by 1_000_000 to convert to a fraction of a ms and multiply by 4096L to scale to the integer range to fit into the 12 bits permitted for the ns timestamp. 




msTime: 1747835228108, nsBits: 1336
msTime: 1747835228137, nsBits: 1333
msTime: 1747835228137, nsBits: 1794
msTime: 1747835228137, nsBits: 2206
msTime: 1747835228137, nsBits: 2766
msTime: 1747835228137, nsBits: 3040
msTime: 1747835228137, nsBits: 3485
msTime: 1747835228137, nsBits: 3901
msTime: 1747835228138, nsBits: 239
msTime: 1747835228138, nsBits: 651
msTime: 1747835228138, nsBits: 918
msTime: 1747835228138, nsBits: 1321
msTime: 1747835228138, nsBits: 1729
msTime: 1747835228138, nsBits: 2140
msTime: 1747835228138, nsBits: 2535
msTime: 1747835228138, nsBits: 2874
msTime: 1747835228138, nsBits: 3243
msTime: 1747835228138, nsBits: 3641
msTime: 1747835228138, nsBits: 3967
msTime: 1747835228139, nsBits: 227
msTime: 1747835228139, nsBits: 524

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2100405267

From alan.bateman at oracle.com  Wed May 21 14:18:04 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 21 May 2025 15:18:04 +0100
Subject: Reducing Classloader's parallelLockMap memory consumption proposal
In-Reply-To: <CAGKffi85riNTzUT67O2jLRZgoHiX5t9=W5yRXXSoyDd-Rs6QMA@mail.gmail.com>
References: <CAGKffi85riNTzUT67O2jLRZgoHiX5t9=W5yRXXSoyDd-Rs6QMA@mail.gmail.com>
Message-ID: <8168f8c8-75c0-4158-b8d8-fcc4d495dced@oracle.com>

On 20/05/2025 03:42, Dmytro Ukhlov wrote:
> Hello!
>
> I created PR is scope of jenkins-core project:
> https://github.com/jenkinsci/jenkins/pull/10659
> Jira ticket: https://issues.jenkins.io/browse/JENKINS-75675
>
> In this PR i propped to override
> protected Object getClassLoadingLock(String className)
> method and use weak references for lock objects
>
> Jenkins is a plugable platform, each plugin has its own class loader
> and its parallelLockMap may consume 10mb of RAM. As a result it might
> have 2gb overhead if ~200 plugins installed.
>
> Jenkins maintainers ask me to consider making this improvement in base

This is an issue for "parallel capable" class loaders, esp. those that 
don't directly delegate. I don't know what topology is used in the 
Jenkins plugin class loaders and whether these class loader need to 
parallel capable.

Expunging entries isn't really feasible, at least not without changing 
the spec.

JDK-8005233 [1] has a write-up from David Holmes on this topic and a 
prototype for "fully concurrent" class loaders. This work has been 
parked for several years. Maybe some day it will get dusted off and a 
JEP drafted (due to the significance).

-Alan

[1] https://bugs.openjdk.org/browse/JDK-8005233

From asemenyuk at openjdk.org  Wed May 21 14:22:57 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 21 May 2025 14:22:57 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v3]
In-Reply-To: <zkBr9MToIDhhJ-Y7pgPbNqumbE1YtA9dlHmnJUApP5k=.287f87b7-44f0-46de-a314-c44702f16a2f@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <zkBr9MToIDhhJ-Y7pgPbNqumbE1YtA9dlHmnJUApP5k=.287f87b7-44f0-46de-a314-c44702f16a2f@github.com>
Message-ID: <eNTBRla7JZP8uCsvQDcLiMDco9As_V_WsdS5VOEFqEI=.ee5f4d05-44ec-461b-9d6c-03cb0437a77e@github.com>

On Wed, 21 May 2025 12:41:24 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

>> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space
>> 
>> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372
>
> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   also use <package-dep-string> in other locations

Marked as reviewed by asemenyuk (Reviewer).

Looks good!

-------------

PR Review: https://git.openjdk.org/jdk/pull/23638#pullrequestreview-2857937512
PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2898151502

From asemenyuk at openjdk.org  Wed May 21 14:40:09 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 21 May 2025 14:40:09 GMT
Subject: Integrated: 8333664: Decouple command line parsing and package
 building in jpackage
In-Reply-To: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>
References: <3HhwytYH-tvQyEXSaf2DpDYAvq5frJZb_95ZnHljasc=.2d1b13c0-b69e-4d56-b499-cb0dd19afebe@github.com>
Message-ID: <8PxSUb6QcJjXdWw81qH_mhRd1ZnPvbvKJfXGbPYPVWw=.ee21a33e-cc8d-4fba-8613-3f20728bbca1@github.com>

On Wed, 12 Jun 2024 01:37:19 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Refactor jpackage to separate the configuration and execution phases.
> At the configuration phase, jpackage parses command-line arguments and validates them.
> At the execution phase, jpackage builds a bundle based on data collected at the configuration phase.
> 
> There was no clear separation between these phases. Both used the same data type (`Map<String, Object>`), making it hard to understand and use properly.
> 
> This change introduces data model to jpackage (classes in "jdk.jpackage.internal.model" package). The output of the configuration phase is either an instance of [jdk.jpackage.internal.model.Application](https://github.com/openjdk/jdk/pull/19668/files#diff-e4e7717f1978a09ac4806eded5c7f94aa29b2ea56671545dc053cb83eba86919) interface for app image bundling or [jdk.jpackage.internal.model.Package](https://github.com/openjdk/jdk/pull/19668/files#diff-9908b5648e03bd8a8104f6f6f5aa08e5df78fbc0508823774d3458b22927b721) for native package bundling.
> 
> The execution phase has been reworked to get configuration properties from the new `jdk.jpackage.internal.model.Application` and `jdk.jpackage.internal.model.Package` interfaces instead of extracting data from `Map<String, Object>` "params".
> 
> Additionally, a notion of "packaging pipeline" (jdk.jpackage.internal.PackagingPipeline class) was added to configure packaging declaratively with more code sharing between bundlers.
> 
> jdk.jpackage module javadoc - https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/module-summary.html
> 
> **Functional changes**
> jpackage behavior 99% remains the same, i.e., it produces the same bundles for the given parameters. This change affects only the implementation. Still, there are some changes in jpackage behavior. They are outlined below.
> 
>  - Minimize copying of the source app image when doing native packaging.
> 
> Before this change, native package bundlers made redundant copies of the source app image. E.g., msi and linux package bundlers copied the external app image (the one specified with `--app-image` parameter); linux package bundlers always transformed the source app image if the installation directory was in the "/usr" tree (`--install-dir /usr`). This change eliminates all redundant app image copy/transformations.
> 
> - PKG bundler: change "preinstall" and "postinstall" scripts in app bundles.
> 
> post- and pre- install PKG scripts for SimplePackageTest package before and after the change:
> <table>
> <thead>
> <tr>
> <th>Script</th>
> <th>New</th>
> <th>Old</th>
> </tr>
> </thead>
> <tbody...

This pull request has now been integrated.

Changeset: 21c12822
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21c1282207614e57138b37a7adca4ccf11cf5bef
Stats:     23911 lines in 195 files changed: 17135 ins; 5686 del; 1090 mod

8333664: Decouple command line parsing and package building in jpackage

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/19668

From liach at openjdk.org  Wed May 21 14:43:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 May 2025 14:43:52 GMT
Subject: RFR: 8357165: test java/lang/invoke/ClassValueTest.java fails
 intermittently
In-Reply-To: <i1B1gJuokz34xZAlURjip2LvwLnx7bCE04Ye3H3F7-g=.aa67b2d1-3dff-4be3-8250-49ab6ce5aad6@github.com>
References: <i1B1gJuokz34xZAlURjip2LvwLnx7bCE04Ye3H3F7-g=.aa67b2d1-3dff-4be3-8250-49ab6ce5aad6@github.com>
Message-ID: <0t1u8ufzpSnLQ-sKpoj92WNl94VKDTirlA193ujU2WA=.d53d60b1-9ab5-4689-8fb8-42afd78a16c8@github.com>

On Sun, 18 May 2025 21:58:04 GMT, Chen Liang <liach at openjdk.org> wrote:

> The test was originally written with product builds in mind; it didn't consider the slowness of debug builds, thus causing tests to fail.
> 
> Also there was a bug in testWeakAgainstClassValue: the test need to flush the backing map in the class to have the weak value removed. It is fixed in this patch as well.
> 
> Testing: ClassValueTest repeated 10 times on windows-x64/linux-x64/macosx-aarch64/linux-aarch64 fastdebug.

I still wish to keep these explicit timeouts - they can be fiddled around for debugging when something stalls after a ClassValue change. In comparison, the argless variants are much harder to tweak and/or debug.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25292#issuecomment-2898217956

From alanb at openjdk.org  Wed May 21 14:48:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 May 2025 14:48:54 GMT
Subject: RFR: 8357145: CRC/Inflater/Deflater/Adler32 methods that take a
 ByteBuffer throw UOE if backed by shared memory segment
In-Reply-To: <Zks5m0BcfxrtFdXPJ4xcKApNAGbShsytTBut1nc6NCM=.52d25dbd-0145-4f11-bebd-f535e15c513a@github.com>
References: <Zks5m0BcfxrtFdXPJ4xcKApNAGbShsytTBut1nc6NCM=.52d25dbd-0145-4f11-bebd-f535e15c513a@github.com>
Message-ID: <ZcSf8yvVHyzETs4I9CH5VOuHW223hQbyaT4G3I9si_8=.11fc6336-0424-4712-a130-fff3d9bb917b@github.com>

On Tue, 20 May 2025 07:37:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to use ` JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` in the package `java.util.zip` so that `Buffer` instances backed by `MemorySegment` instances can be used.
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

test/jdk/java/util/zip/ChecksumBase.java line 79:

> 77:         checksum.update(bb);
> 78:         checkChecksum(checksum, expected);
> 79:     }

The src changes look right. For the tests then I wonder if we could expand to exercise with view of byte buffers on memory segments allocated from all arenas with bounded lifetime. I think that would help the test coverage.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25321#discussion_r2100487463

From alanb at openjdk.org  Wed May 21 14:53:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 May 2025 14:53:53 GMT
Subject: RFR: 8357145: CRC/Inflater/Deflater/Adler32 methods that take a
 ByteBuffer throw UOE if backed by shared memory segment
In-Reply-To: <MBzJlmRjqCjO-CcGBQ-J9Z3FEFxbX2QZV_kow2qo9bM=.941c8d76-cbbf-4e32-85f7-53c5b64950bf@github.com>
References: <Zks5m0BcfxrtFdXPJ4xcKApNAGbShsytTBut1nc6NCM=.52d25dbd-0145-4f11-bebd-f535e15c513a@github.com>
 <MBzJlmRjqCjO-CcGBQ-J9Z3FEFxbX2QZV_kow2qo9bM=.941c8d76-cbbf-4e32-85f7-53c5b64950bf@github.com>
Message-ID: <eX-nMJoTC662FQjCNj7VxFYVJCSGGzrgxvVakwFHIOI=.04140f8d-f270-4fb6-a829-bd8eef055bb7@github.com>

On Wed, 21 May 2025 13:53:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This PR proposes to use ` JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` in the package `java.util.zip` so that `Buffer` instances backed by `MemorySegment` instances can be used.
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> src/java.base/share/classes/java/util/zip/Adler32.java line 102:
> 
>> 100:             NIO_ACCESS.acquireSession(buffer);
>> 101:             try {
>> 102:                 adler = updateByteBuffer(adler, NIO_ACCESS.getBufferAddress(buffer), pos, rem);
> 
> Hello Per, from what I can see in the implementation of `NIO_ACCESS.getBufferAddress(...)` it merely returns `buffer.address` https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/Buffer.java#L862. So if I understand this change correctly, what we are proposing here is that we want to avoid the additional checks (checks related to `MemorySegment` that can fail?) that are there in the `DirectBuffer.address()` method implementation? Is that what this change is addressing?

All methods in the API that accept a ByteBuffer and access it as DirectBuffer should have been changed to use the acquireSession/getBufferAddress/releaseSession. Several were missed, I think because we didn't have enough tests to exercise the views.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25321#discussion_r2100500374

From lmesnik at openjdk.org  Wed May 21 15:09:55 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 21 May 2025 15:09:55 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v6]
In-Reply-To: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com>
Message-ID: <4L78FN5dBp6so8QWalypTvm2lnXb9GU6zl3Hw6hK6Go=.26715817-5092-4489-ba9a-bf3a9800c478@github.com>

On Wed, 21 May 2025 06:54:37 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Thanks for fixing this!

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24948#pullrequestreview-2858114150

From henryjen at openjdk.org  Wed May 21 15:24:56 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 21 May 2025 15:24:56 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <1k_uCX5TM9o-ewEsAvEeG16VPUqRo9BwnwPOQdJuqYA=.e2930b9d-89c9-4664-b663-8434fec12718@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
 <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
 <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>
 <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com>
 <PphfDWen7gKIUoGPV2NnZ2M7_LB47Rd2VmpzTnKDpGk=.5415e56a-eb35-4c65-bca5-692457061f11@github.com>
 <PsoyPBx8Ayu9MaNQoao_JYd6OLb8Omp7TuSJQUa9P5k=.de0888a1-ac2d-4691-ad0a-80b16d29f69e@github.com>
 <Ax8PvcYBimeOnK_3CrsKLOXKpEWqb2ISH-IYCPjvPHc=.f77d4095-d575-42b6-84a8-b46704d81912@github.com>
 <h8HAePVzWzxJTsr6oiT7gEAuBNdIWGwGwLm_Htd50Ws=.09efd46e-cd36-43b1-a6f0-1f18275edbac@github.com>
 <1k_uCX5TM9o-ewEsAvEeG16VPUqRo9BwnwPOQdJuqYA=.e2930b9d-89c9-4664-b663-8434fec12718@github.com>
Message-ID: <RkcTG-90KW50Fxpjqe2jJkW9XUq4VVhs21GlGgEgPQM=.6a4ef3aa-0b37-42dc-94d0-0d83b847802c@github.com>

On Wed, 21 May 2025 14:00:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.
>> 
>> For the `jar --validate` operation, it would be useful to not just warn (and thus exit with a non-zero exit code) for issues that violate the ZIP or JAR specification, but also for inconsistencies and uncommon JAR contents that might cause some unexpected behaviour within the platform runtime. This helps with identifying and analyzing such unexpected issues in the JAR (but not strictly violations of any specification) even before that JAR gets used in the platform runtime. This is no different for the duplicate entries in the JAR file, for which we issue warnings even if the ZIP specification explicitly allows it (and the JAR specification doesn't make a mention of it).
>> 
>> Based on some experiments we have run, it's not very common for a JAR file to have a different order in CEN as compared to LOC, so I think any JAR file that has a different order between these structures should result in a warning (and thus a non-zero exit code) from the validate operation.
>
>> Point taken. For documentation wise, I don't think it's necessary to specify at this point. For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.
> 
> I am OK to currently specify as non-zero, it is a discussion that can be continued as to what if anything more to do (as Jai mentions)
> 
> Any warnings should result in a non-zero for a return code.

OK, I'll update the PR to consider inconsistent order to be invalid even though it won't cause issue but indeed a sign that's not created by the official `jar` tool.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100570620

From henryjen at openjdk.org  Wed May 21 15:49:29 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 21 May 2025 15:49:29 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>

> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Mismatched order is considered invalid

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/0caecfcd..b0df54d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=09-10

  Stats: 24 lines in 2 files changed: 16 ins; 5 del; 3 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 maurizio.cimadamore at oracle.com  Wed May 21 16:01:19 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 21 May 2025 17:01:19 +0100
Subject: Towards a JSON API for the JDK
In-Reply-To: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
Message-ID: <ef42a778-31a7-43da-b814-c584e9e90b92@oracle.com>

Hi Paul,
I like the emphasis on minimality, and extensibility of the proposed API.

One comment/question is why the API choses to expose Json arrays and 
objects as List/Maps respectively, instead of e.g. providing accessor to 
the object members/array elements.

E.g. it seems to me that creating a Map from a JSON object is a 
potentially expensive operation (although perhaps maybe an implementor 
could implement some kind of lazy list/map under the hood).

If the "minimal" contract only required basic element (for arrays) or 
key/val (for objects) accessors, perhaps this will might leave more room 
for implementors to support such accessors as they see fit? And we could 
still have default methods which could use the accessor to provide a 
List/Map view of the json array/object.

Cheers
Maurizio

On 15/05/2025 21:30, Paul Sandoz wrote:
> Hi,
>
> We would like to share with you our thoughts and plans towards a JSON API for the JDK.
> Please see the document below.
>
> -
>
> We have had the pleasure of using a clone of this API in some experiments we are conducting with
> ONNX and code reflection [1]. Using the API we were able to quickly write code to ingest and convert
> a JSON document representing ONNX operation schema into instances of records modeling the schema
> (see here [2]).
>
> The overall out-of-box experience with such a minimal "batteries included? API has so far been positive.
>
> Thanks,
> Paul.
>
> [1] https://openjdk.org/projects/babylon/
> [2] https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpSchemaParser.java#L87
>
> # Towards a JSON API for the JDK
>
> One of the most common requests for the JDK is an API for parsing and generating
> JSON. While JSON originated as a text-based serialization format for JSON
> objects ("JSON" stands for "JavaScript Object Notation"), because of its simple
> and flexible syntax, it eventually found use outside the JavaScript ecosystem as
> a general data interchange format, such as framework configuration files and web
> service requests/response formats.
>
> While the JDK cannot, and should not, provide libraries for every conceivable
> file format or protocol, the JDK philosophy is one of "batteries included",
> which is to say we should be able to write basic programs that use common
> protocols such as HTTP, without having to appeal to third party libraries.
> The Java ecosystem already has plenty of JSON libraries, so inclusion in
> the JDK is largely meant to be a convenience, rather than needing to be the "one
> true" JSON library to meet the needs of all users. Users with specific needs
> are always free to select one of the existing third-party libraries.
>
> ## Goals and requirements
>
> Our primary goal is that the library be simple to use for parsing, traversing,
> and generating conformant JSON documents. Advanced features, such as data
> binding or path-based traversal should be possible to implement as layered
> features, but for simplicity are not included in the core API. We adopt a goal
> that the performance should be "good enough", but where performance
> considerations conflict with simplicity and usability, we will choose in favor
> of the latter.
>
> ## API design approach
>
> The description of JSON at `https:://json.org` describes a JSON document using
> the familiar "railroad diagram":
> ![image](https://www.json.org/img/value.png)
>
> This diagram describes an algebraic data type (a sum of products), which we
> model directly with a set of Java interfaces:
>
> ```
> interface JsonValue { }
> interface JsonArray extends JsonValue { List<JsonValue> values(); }
> interface JsonObject extends JsonValue { Map<String, JsonValue> members(); }
> interface JsonNumber extends JsonValue { Number toNumber(); }
> interface JsonString extends JsonValue { String value(); }
> interface JsonBoolean extends JsonValue  { boolean value(); }
> interface JsonNull extends JsonValue { }
> ```
>
> These interfaces have (hidden) companion implementation classes that admit
> greater flexibility of implementation than modeling them directly with records would permit.
> Further, these interfaces are unsealed. We compromise on the sealed sum of products to enable
> alternative implementations, for example to support alternative formats that
> encode the same information in a JSON document but in a more efficient form than
> text.
>
> The API has static methods for parsing strings into a `JsonValue`, conversion to
> and from purely untyped representations (lists and maps), and factory methods
> for building JSON documents. We apply composition consistently, e.g, a
> JsonString has a string, a JsonObject has a map of string to JsonValue, as
> opposed to extension for structural JSON values.
>
> It turns out that this simple API is almost all we need for traversal. It gives
> us an immutable representation of a document, and we can use pattern matching to
> answer the myriad questions that will come up (Does this object have key X? Does
> it map to a number? Is that number representable as an integer?) when going
> from an untyped format like JSON to a more strongly typed domain model.
> Given a simple document like:
>
> ```
>      {
>          "name": "John?,
>          "age": 30
>      }
> ```
>
> we can parse and traverse the document as follows:
>
> ```
> JsonValue doc = Json.parse(inputString);
> if (doc instanceof JsonObject o
>      && o.members().get("name") instanceof JsonString s
>      && s.value() instanceof String name
>      && o.members().get("age") instanceof JsonNumber n
>      && n.toNumber() instanceof Long l && l instanceof int age) {
>              // use "name" and "age"
>          }
> ```
>
> Later, when the language acquires the ability to expose deconstruction patterns
> for arbitrary interfaces (similar to today's record patterns, see
> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns),
> this will be simplifiable to:
>
> ```
> JsonValue doc = Json.parse(inputString);
> if (doc instanceof JsonObject(var members)
>      && members.get("name") instanceof JsonString(String name)
>      && members.get("age") instanceof JsonNumber(int age)) {
>              // use "name" and "age"
>          }
> ```
>
> So, overtime, as more pattern matching features are introduced we anticipate
> improved use of the API. This is a primary reason why the API is so minimal.
> Convenience methods we add today, such as a method that accesses a JSON
> object component as say a JSON string or throws an exception, will become
> redundant in the future.
>
> ## JSON numbers
>
> The specification of JSON number makes no explicit distinction between integral
> and decimal numbers, nor specifies limits on the size of those numbers.
> This is a common source of interoperability issues when consuming JSON
> documents. Generally users cannot always but often do assume JSON numbers are
> parsable, without loss of precision, to IEEE double-precision floating point
> numbers or 32-bit signed integers.
>
> In this respect the API provides three means to operate on the JSON number,
> giving the user full control:
>
> 1. Underlying string representation can be obtained, if preserving syntactic
>     details such as leading or trailing zeros is important.
> 2. The string representation can be parsed to an instance of `BigDecimal`, using
>     `toBigDecimal` if preserving decimal numbers is important.
> 3. The string representation can be parsed into an instance of `Long`, `Double`,
>     `BigInteger`, or `BigDecimal`, using `toNumber`. The result of this method
>     depends on how the representation can be parsed, possibly losing precision,
>     choosing a suitably convenient numeric type that can then be pattern
>     matched on.
>
> Primitive pattern matching will help as will further pattern matching features
> enabling the user to partially match.
>
> ## Prototype implementation
>
> The prototype implementation is currently located into the JDK sandbox
> repository
> under the `json` branch, see
> here https://github.com/openjdk/jdk-sandbox/tree/json/src/java.base/share/classes/java/util/json
> The prototype API javadoc generated from the repository is also available at
> https://cr.openjdk.org/~naoto/json/javadoc/api/java.base/java/util/json/package-summary.html
>
> ### Testing and conformance
>
> The prototype implementation passes all conformance test cases but two, available
> on https://github.com/nst/JSONTestSuite. The two exceptions are the ones which the
> prototype specifically prohibits, i.e, duplicated names in JSON objects
> (https://cr.openjdk.org/~naoto/json/conformance/results/parsing.html#35).
>
> ### Performance
>
> Our main focus so far has been on the API design and a functional implementation.
> Hence, there has been less focus on performance even though we know there are a
> number of performance enhancements we can make eventually.
> We are reasonably happy with the current performance. The
> implementation performs well when compared to other JSON implementations
> parsing from string instances and traversing documents.
>
> An example of where we may choose simplicity and usability over performance
> is the rejection of JSON documents containing objects that in turn contain members
> with duplicate names. That may increase the cost of parsing, but simplifies the user
> experience for the majority of cases since if we reasonably assume JsonObjects are
> map-like, what should the user do with such members, pick one the last one? merge
> the values? or reject?
>
> ## A JSON JEP?
>
> We plan to draft JEP when we are ready. Attentive readers will observe that
> a JEP already exists, JEP 198: Light-Weight JSON API (https://openjdk.org/jeps/198). We will
> either update this JEP, or withdraw it and draft a new one.

From duke at openjdk.org  Wed May 21 16:25:57 2025
From: duke at openjdk.org (kieran-farrell)
Date: Wed, 21 May 2025 16:25:57 GMT
Subject: Withdrawn: 8347027: String replaceAll with Function<String, String>
In-Reply-To: <j54JsESf9b6YB14jeAx9nBktIQC0f3C6R7pbUWYYshU=.b0ec838f-6b1e-4bcb-ae3e-6890ab7bc2b7@github.com>
References: <j54JsESf9b6YB14jeAx9nBktIQC0f3C6R7pbUWYYshU=.b0ec838f-6b1e-4bcb-ae3e-6890ab7bc2b7@github.com>
Message-ID: <1u_ZQV3AZ1ddh-tvh_aS1VVW8hIKj3UL_veHH6uc5tc=.6feb9cd2-16ae-415c-9ff3-ebc2d822cc61@github.com>

On Tue, 20 May 2025 16:59:10 GMT, kieran-farrell <duke at openjdk.org> wrote:

> New API to the String.java class - replaceAllMapped(String, Function<MatchResult, String>) that allows regex based replacement via a user defined function allowing dynamic replacemnt based on the match. It delegates to the already existing Pattern.matcher().replaceAll(Function).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25335

From paul.sandoz at oracle.com  Wed May 21 16:29:37 2025
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 21 May 2025 16:29:37 +0000
Subject: Towards a JSON API for the JDK
In-Reply-To: <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
 <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
 <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>
 <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com>
 <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr>
 <CAGZD2TAbv+dQQJCTbpQqa3LVFB90vqBZ-9sbcynAZpOE32bxag@mail.gmail.com>
 <CB7705F0-77B5-4119-BB77-D05D87B270F5@oracle.com>
 <CAGZD2TDQf8CtDXt0=Qdt50AAb-Ktouq2cA9L33pFCzBTwDEhqA@mail.gmail.com>
 <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com>
 <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com>
Message-ID: <CB0376D6-B19A-450B-A047-76865A715FB9@oracle.com>

I consider this a ?known unknown? (in the words of Mr. Rumsfeld). We would need to explore this area throughly, which includes the interconnection with Serialization 2.0, before we really know what we can and should do in the near and long term. That?s a significant effort, and I would like to separate it out from the non-trivial effort to first get a rather modest API over the line.

Paul.

> On May 21, 2025, at 12:55?AM, Cay Horstmann <cay.horstmann at gmail.com> wrote:
> So here is my point. If the JDK were to include a JSON data mapper, that data mapper is either rigid or flexible. Designing a flexible data mapper is hard. Serialization 2.0 would not make it any easier.



From jpai at openjdk.org  Wed May 21 16:35:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 16:35:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
Message-ID: <aWjWvMnIEOc4h5tngG9Xl138XUGVTRaZiFj5lyhb6bo=.2634cace-d6b2-4119-8494-3274b25a8662@github.com>

On Wed, 21 May 2025 15:49:29 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mismatched order is considered invalid

src/jdk.jartool/share/man/jar.md line 106:

> 104:     overwriting (replacing) earlier copies unless -k is specified.
> 105: 
> 106: `-d` or `--describe-module`

I'm going to start with some trivial nits and other review comments. The copyright year on this file will need a update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100728423

From asemenyuk at openjdk.org  Wed May 21 16:36:31 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 21 May 2025 16:36:31 GMT
Subject: Integrated: 8357478: Fix copyright header in
 src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageDesc.java
Message-ID: <o2G0g5es_Pas8t5kz74xluG9hlAh3UMZmTONkBF-0Fc=.d9899c9a-077a-43af-a26d-367c191f3ed2@github.com>

Add a missing line to the copyright header

-------------

Commit messages:
 - 8357478: Fix copyright header in src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageDesc.java

Changes: https://git.openjdk.org/jdk/pull/25362/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25362&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357478
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25362.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25362/head:pull/25362

PR: https://git.openjdk.org/jdk/pull/25362

From jpai at openjdk.org  Wed May 21 16:36:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 16:36:31 GMT
Subject: Integrated: 8357478: Fix copyright header in
 src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageDesc.java
In-Reply-To: <o2G0g5es_Pas8t5kz74xluG9hlAh3UMZmTONkBF-0Fc=.d9899c9a-077a-43af-a26d-367c191f3ed2@github.com>
References: <o2G0g5es_Pas8t5kz74xluG9hlAh3UMZmTONkBF-0Fc=.d9899c9a-077a-43af-a26d-367c191f3ed2@github.com>
Message-ID: <Pq0CjRGeOTr5ZAFiAAKxzeHLPeUiW2dGHSepEYpKdNE=.7f0f595d-aa5f-4552-bb96-f2b5de9906b3@github.com>

On Wed, 21 May 2025 16:26:39 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add a missing line to the copyright header

The change looks correct and trivial to me. Thank you Alexey.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25362#pullrequestreview-2858443207

From asemenyuk at openjdk.org  Wed May 21 16:36:31 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 21 May 2025 16:36:31 GMT
Subject: Integrated: 8357478: Fix copyright header in
 src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageDesc.java
In-Reply-To: <o2G0g5es_Pas8t5kz74xluG9hlAh3UMZmTONkBF-0Fc=.d9899c9a-077a-43af-a26d-367c191f3ed2@github.com>
References: <o2G0g5es_Pas8t5kz74xluG9hlAh3UMZmTONkBF-0Fc=.d9899c9a-077a-43af-a26d-367c191f3ed2@github.com>
Message-ID: <zbpL7PmGRe0jUh8dX2HZGK5MGEVlcQmmgCUKVsDuR6c=.c63da73e-16d0-4f19-82b5-8b7a03a9e111@github.com>

On Wed, 21 May 2025 16:26:39 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add a missing line to the copyright header

This pull request has now been integrated.

Changeset: 6546de1d
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6546de1d3adb8c4755950ee6fb858ec9ee1c5294
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8357478: Fix copyright header in src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageDesc.java

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/25362

From jpai at openjdk.org  Wed May 21 16:44:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 16:44:58 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
Message-ID: <n8AVnZgFi-yV_dQL5eYZziuYRjTbIlImqi9NIMXQR1E=.62a1b4e4-7007-4416-8c03-e214585cb0d1@github.com>

On Wed, 21 May 2025 15:49:29 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mismatched order is considered invalid

src/jdk.jartool/share/man/jar.md line 110:

> 108: 
> 109: `--validate`
> 110: :   Validate the contents of the jar archive.

Validate the contents of the JAR file.

src/jdk.jartool/share/man/jar.md line 111:

> 109: `--validate`
> 110: :   Validate the contents of the jar archive.
> 111:     See `Integrity of a jar Archive` section below for more details.

In recent times, both in code and in API specification, we have been using `JAR` and `ZIP` (upper case) to refer to the JAR/ZIP files. For the tool itself, using the lower case jar is appropriate. Furthermore, JAR itself means Java archive, so I think we can remove the "Archive" word from that sentence. Perhaps this (and the corresponding section) should be "Integrity of a JAR file".

src/jdk.jartool/share/man/jar.md line 221:

> 219: 
> 220: ## Integrity of a jar Archive
> 221: As a jar archive is based on ZIP format, it is possible to create a jar archive using tools

Nit - As a JAR file is based on ZIP format, it is possible to create a JAR file ...

src/jdk.jartool/share/man/jar.md line 223:

> 221: As a jar archive is based on ZIP format, it is possible to create a jar archive using tools
> 222: other than the `jar` command. The --validate option may be used to perform the following
> 223: integrity checks against a jar archive:

Nit - "integrity checks against a JAR file:"

src/jdk.jartool/share/man/jar.md line 225:

> 223: integrity checks against a jar archive:
> 224: 
> 225: - That there are no duplicate Zip Entry file names

Nit - "... ZIP entry file names"

src/jdk.jartool/share/man/jar.md line 226:

> 224: 
> 225: - That there are no duplicate Zip Entry file names
> 226: - Verify that the Zip Entry file name:

Nit - ".... ZIP entry file name:"

src/jdk.jartool/share/man/jar.md line 237:

> 235: The jar tool returns a status code of 0 if there were no integrity issues encountered, otherwise
> 236: a non-zero status code would be returned.
> 237: When an integrity issue is reported, it will often require that the jar file is re-created by the

Nit - "... require that the JAR file is re-created by the original source of the JAR file."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100734549
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100733984
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100742813
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100743231
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100736667
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100737171
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100740992

From jpai at openjdk.org  Wed May 21 16:48:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 16:48:56 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
Message-ID: <Bp4U2JkzCeZykmalvThoeOCO5XTdl7IrpP0SaZZGdaU=.d69d936b-57fc-4b6c-8b71-155b68c5b64d@github.com>

On Wed, 21 May 2025 15:49:29 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mismatched order is considered invalid

src/jdk.jartool/share/man/jar.md line 235:

> 233:   versions.
> 234: 
> 235: The jar tool returns a status code of 0 if there were no integrity issues encountered, otherwise

Nit - we should call it exit code instead of status code, both for 0 and non-zero exit codes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100748899

From naoto at openjdk.org  Wed May 21 16:50:12 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 May 2025 16:50:12 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v3]
In-Reply-To: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
Message-ID: <euSlCn1VAYZ-bNi1jl0jFA8AXrVyhMSD1AyZSwWHmds=.9e874290-6358-4b91-8253-57f9561e7b77@github.com>

> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting further comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25271/files
  - new: https://git.openjdk.org/jdk/pull/25271/files/ec420654..dd370768

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=01-02

  Stats: 22 lines in 2 files changed: 9 ins; 7 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25271/head:pull/25271

PR: https://git.openjdk.org/jdk/pull/25271

From jpai at openjdk.org  Wed May 21 16:55:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 16:55:53 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
Message-ID: <6F_2GSLLN0ajSO73JcYDd0wXvTthdFjgfxXDQ8XndYU=.c3ad4280-fcc3-4eaf-a658-2d5212009260@github.com>

On Wed, 21 May 2025 15:49:29 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mismatched order is considered invalid

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 454:

> 452:                     new FileInputStream(file)))) {
> 453: 
> 454:             return Validator.validate(this, zf, zis);

I think it might be better to change the `Validator.validate()` method to accept a `java.nio.file.Path` instead of accepting a ZipFile instance and a ZipInputStream instance. In its current form it feels odd that the call site (like here) needs to pass ZipFile and ZipInputStream to a validator. The checks using a ZipFile and a ZipInputStream for the same file is more an internal detail of the validator, so it would be good to let it construct those instances internally as appropriate.

The `Validator` class itself belongs to an internal package of this tool, so changing the signature of this method to accept a `Path` wouldn't be a problem.

It also looks like the Validator uses this `Main` instance merely for error reporting. So maybe in a future update we could remove the need to pass along this `Main` instance to the validator. That one doesn't have to be done in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100761422

From naoto at openjdk.org  Wed May 21 16:57:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 May 2025 16:57:52 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <fl9VCx915VdNP3Bk-y4znN3OUM7_sfRJc5XMBHKf0Sk=.19862ac2-2908-424b-afd1-7939b9c0f79e@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <lErNIJyBSEaDtbZk91B6GQtqHc0o2qqGOaI-MH0r5ns=.404cffc7-5422-4b1d-b081-48bb8b9cf67a@github.com>
 <fl9VCx915VdNP3Bk-y4znN3OUM7_sfRJc5XMBHKf0Sk=.19862ac2-2908-424b-afd1-7939b9c0f79e@github.com>
Message-ID: <54Ipy5980SJ3mqt5isPw1n4TNQnO7hH7DOlgLg3TSDI=.62f6bb57-278f-40b3-88d2-9f9a8a2031bb@github.com>

On Wed, 21 May 2025 06:12:18 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> src/java.base/share/classes/java/io/Console.java line 67:
> 
>> 65:  * stdout.encoding}, in which case read operations use the {@code Charset}
>> 66:  * designated by {@code stdin.encoding}.
>> 67:  * <p>
> 
> `Console.charset()` states "The returned charset is used for interpreting the input and output source (e.g., keyboard and/or display) specified by the host environment or user, which defaults to the one based on stdout.encoding." If _stdin.encoding_ is set otherwise, this is no longer true, so I think this method may need a wording update as well.

Good point. Brought the same wording to the `charset()` method description for further clarification.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2100752794

From naoto at openjdk.org  Wed May 21 16:57:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 May 2025 16:57:52 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v3]
In-Reply-To: <RiE9-8g0F1QOLT3xhcxUIWC6CR_TcisqFwPX9omahWM=.f39c6e44-8378-4ed6-b0b9-5a5aa252cded@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <Pup4nswVBdebz4T4tOR33WuL7iedobsLXh-FjSh4e6E=.7eb43d7b-4c9a-490e-9a1f-168fee7bdf9b@github.com>
 <ogXKGEuLuPNjbiKf2n8GLsIAUAgCqs6alj69rYqGMDU=.c72dc1a5-dfa2-44dc-a808-81162dec14b6@github.com>
 <gjZaymAsEf2eto9WZwSgSOCBVCy4n_3-CYUaIrGDaKI=.a6168cc0-d6b9-4685-97d9-82eba329680b@github.com>
 <RiE9-8g0F1QOLT3xhcxUIWC6CR_TcisqFwPX9omahWM=.f39c6e44-8378-4ed6-b0b9-5a5aa252cded@github.com>
Message-ID: <UgD8f9t5Y-SxmsFcK0oSUWk7hIzdnysuEkZb5lSWgts=.b873bc23-dcd6-4cae-b602-be9cbdcbeed4@github.com>

On Wed, 21 May 2025 08:20:50 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> JLine is a 3rd party library. It would be desirable that they change their implementation to separately handle in/out in their terminal, but that is out of scope of this PR
>
> Created jline/jline3#1282.

Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2100753459

From naoto at openjdk.org  Wed May 21 16:57:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 May 2025 16:57:53 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v3]
In-Reply-To: <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com>
 <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com>
Message-ID: <Frh347wHPLN6iVS4uGojdUBdbnP3Ulx15keIvh7nzyM=.9399e47b-9511-4f61-b451-9e19ac9b4e19@github.com>

On Wed, 21 May 2025 08:30:26 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `stdout.encoding` validity is tested through the public `charset()` mehtod, which is in `CharsetTest.java`
>
> Indeed there *are* `stdout.encoding` tests in `test/jdk/java/io/Console`, yet none<sup>1</sup> that thoroughly tests them with `expect` and a dedicated (mock) `CharsetProvider` as you did here. FWIW, I really liked your new test using a mock `CharsetProvider` in combination with `expect`, hence my question for doing same for stdout and stderr too.
> 
> For the record, AFAICT, there are no tests for `stderr.encoding`.
> 
> <sup>1</sup> There is `script.exp`, but it tests `sun.stdout.encoding`, not `stdout.encoding`.

Actually providing mock charset was a workaround of not having public method for getting the input encoding. I think it would be an overkill to introduce a new public method because it will not be used much, as most cases are suffice with the existing one (Console is used for interactive user enviornment, and I don't believe users would like to see different characters displayed for the input).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2100762324

From naoto at openjdk.org  Wed May 21 16:57:54 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 May 2025 16:57:54 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v3]
In-Reply-To: <Frh347wHPLN6iVS4uGojdUBdbnP3Ulx15keIvh7nzyM=.9399e47b-9511-4f61-b451-9e19ac9b4e19@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com>
 <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com>
 <Frh347wHPLN6iVS4uGojdUBdbnP3Ulx15keIvh7nzyM=.9399e47b-9511-4f61-b451-9e19ac9b4e19@github.com>
Message-ID: <p95EYb_nEBCfPpj5uTtE7HhrF0txSRLcQrULKYq1nwY=.90bf3699-fc29-44c8-ab42-a580cf454b30@github.com>

On Wed, 21 May 2025 16:53:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Indeed there *are* `stdout.encoding` tests in `test/jdk/java/io/Console`, yet none<sup>1</sup> that thoroughly tests them with `expect` and a dedicated (mock) `CharsetProvider` as you did here. FWIW, I really liked your new test using a mock `CharsetProvider` in combination with `expect`, hence my question for doing same for stdout and stderr too.
>> 
>> For the record, AFAICT, there are no tests for `stderr.encoding`.
>> 
>> <sup>1</sup> There is `script.exp`, but it tests `sun.stdout.encoding`, not `stdout.encoding`.
>
> Actually providing mock charset was a workaround of not having public method for getting the input encoding. I think it would be an overkill to introduce a new public method because it will not be used much, as most cases are suffice with the existing one (Console is used for interactive user enviornment, and I don't believe users would like to see different characters displayed for the input).

> There is script.exp, but it tests sun.stdout.encoding, not stdout.encoding.

It is addressed in this PR

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2100763095

From archie.cobbs at gmail.com  Wed May 21 17:03:12 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 21 May 2025 12:03:12 -0500
Subject: Towards a JSON API for the JDK
In-Reply-To: <CB0376D6-B19A-450B-A047-76865A715FB9@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
 <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
 <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>
 <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com>
 <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr>
 <CAGZD2TAbv+dQQJCTbpQqa3LVFB90vqBZ-9sbcynAZpOE32bxag@mail.gmail.com>
 <CB7705F0-77B5-4119-BB77-D05D87B270F5@oracle.com>
 <CAGZD2TDQf8CtDXt0=Qdt50AAb-Ktouq2cA9L33pFCzBTwDEhqA@mail.gmail.com>
 <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com>
 <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com>
 <CB0376D6-B19A-450B-A047-76865A715FB9@oracle.com>
Message-ID: <CANSoFxtBXkhs5iwWHYtF489VS6GwNJBkQ0gx4ZiNbLrrrDMoOA@mail.gmail.com>

On Wed, May 21, 2025 at 11:30?AM Paul Sandoz <paul.sandoz at oracle.com> wrote:

> I consider this a ?known unknown? (in the words of Mr. Rumsfeld). We would
> need to explore this area throughly, which includes the interconnection
> with Serialization 2.0, before we really know what we can and should do in
> the near and long term. That?s a significant effort, and I would like to
> separate it out from the non-trivial effort to first get a rather modest
> API over the line.


I think the discussions about object mapping and serialization are
important and super interesting, but as Paul points out, not really an
immediate concern wrt. this proposal.

In trying to understand this discussion, there are so many different
concepts stirred up it's hard to keep track. It was helpful for me to go
through the exercise of trying to partition the discussion space. Below is
my feeble attempt at that...

Side note: for better or worse, there are lots of parallels here with XML,
so I expect the solutions to parallel the XML solutions, for many of the
same reasons. We should also avoid parallelling the mistakes (e.g.,
including too much functionality in the JDK which gets stale over time).

Q1: What is JSON? Just like XML, it's a specification for structured
documents. By "structured" we mean the syntax implies a nested tree-like
structure (by "document" we mean "file" or "streams of bytes").

Q2: What do people want to do with JSON?

1. Model a JSON document as Java objects in memory (using a "document
object model" or DOM). Analogy: org.w3c.dom

2. Convert JSON DOM objects (see #1) to/from JSON documents. Analogy:
{javax,jakarta}.xml.{parsers,transform}

3. Transform JSON documents. Analogy {javax,jakarta}.xml.transform

4. Read/write normal Java objects to/from JSON ("object mapping"). Analogy:
{javax,jakarta}.xml.bind (JAXB), JiBX

5. Read/write normal Java objects, where JSON is one possible encoding
("serialization 2.0"). Analogy: java.beans.XMLEncoder (!?)

To me these are mostly separate problems whose solutions can be solved
separately, each building on the previous (analogous to what was done with
XML).

So what problem is this new API trying to solve? Just #1 and #2.

Of course, you probably want to use the solutions to problem 1 and 2 in
your solution to problems 3, 4, and 5.

But let's respect the ordering here. In solving problems 1 and 2, we should
focus on those problems only. The solution to problems 1 and 2, if done
well, will automatically be a good foundation for solving problems 3, 4,
and 5, etc.

-Archie

P.S.  I'm interested in "serialization 2.0" too - and that discussion must
be happening somewhere else... where?

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250521/21075084/attachment-0001.htm>

From paul.sandoz at oracle.com  Wed May 21 17:06:38 2025
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 21 May 2025 17:06:38 +0000
Subject: Towards a JSON API for the JDK
In-Reply-To: <ef42a778-31a7-43da-b814-c584e9e90b92@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <ef42a778-31a7-43da-b814-c584e9e90b92@oracle.com>
Message-ID: <A7867680-E127-43E8-BB03-8539A86A9ADC@oracle.com>

It was a design choice to be consistent with each json value having an X, accepting X in on construction and producing X out (notionally) on deconstruction, which leans into pattern matching. Definitely pros/cons to that e.g., we could instead make JonObject implement Map, or do as you suggest [*], both of which adjust how one reasons about the X in and X out.

I would prefer to mostly drive the API design from user ergonomics with pattern matching rather than what is easier for implementations. It?s definitely possible for implementations to optimize (as you posit, such as a concrete implementation extending from Map with a custom implementation), and there is room for improvement in the current implementation we should explore.

Paul.

[*] Although I don?t think we can avoid exposing collection like semantics, since it requires iteration to produce the Map containing all the entries from a default method, so might as well expose Map directly.


> On May 21, 2025, at 9:01?AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> Hi Paul,
> I like the emphasis on minimality, and extensibility of the proposed API.
> 
> One comment/question is why the API choses to expose Json arrays and objects as List/Maps respectively, instead of e.g. providing accessor to the object members/array elements.
> 
> E.g. it seems to me that creating a Map from a JSON object is a potentially expensive operation (although perhaps maybe an implementor could implement some kind of lazy list/map under the hood).
> 
> If the "minimal" contract only required basic element (for arrays) or key/val (for objects) accessors, perhaps this will might leave more room for implementors to support such accessors as they see fit? And we could still have default methods which could use the accessor to provide a List/Map view of the json array/object.
> 
> Cheers
> Maurizio


From liach at openjdk.org  Wed May 21 17:09:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 May 2025 17:09:29 GMT
Subject: RFR: 8357165: test java/lang/invoke/ClassValueTest.java fails
 intermittently [v2]
In-Reply-To: <i1B1gJuokz34xZAlURjip2LvwLnx7bCE04Ye3H3F7-g=.aa67b2d1-3dff-4be3-8250-49ab6ce5aad6@github.com>
References: <i1B1gJuokz34xZAlURjip2LvwLnx7bCE04Ye3H3F7-g=.aa67b2d1-3dff-4be3-8250-49ab6ce5aad6@github.com>
Message-ID: <_Y8b69_yD3zF4kpqW3StHZ5p8E1XSNOmZOcs3Qyy6IE=.665c0ab8-ebeb-434e-b725-43a50e4f3eb1@github.com>

> The test was originally written with product builds in mind; it didn't consider the slowness of debug builds, thus causing tests to fail.
> 
> Also there was a bug in testWeakAgainstClassValue: the test need to flush the backing map in the class to have the weak value removed. It is fixed in this patch as well.
> 
> Testing: ClassValueTest repeated 10 times on windows-x64/linux-x64/macosx-aarch64/linux-aarch64 fastdebug.

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:

 - Increase timeout, add comment for adjust for debugging
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cv-test-problems
 - Restore incorrectly removed annotation
 - Fix problems with class value tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25292/files
  - new: https://git.openjdk.org/jdk/pull/25292/files/792d683e..68a13bb3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25292&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25292&range=00-01

  Stats: 36448 lines in 506 files changed: 23222 ins; 10278 del; 2948 mod
  Patch: https://git.openjdk.org/jdk/pull/25292.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25292/head:pull/25292

PR: https://git.openjdk.org/jdk/pull/25292

From jpai at openjdk.org  Wed May 21 17:15:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 17:15:53 GMT
Subject: RFR: 8357165: test java/lang/invoke/ClassValueTest.java fails
 intermittently [v2]
In-Reply-To: <_Y8b69_yD3zF4kpqW3StHZ5p8E1XSNOmZOcs3Qyy6IE=.665c0ab8-ebeb-434e-b725-43a50e4f3eb1@github.com>
References: <i1B1gJuokz34xZAlURjip2LvwLnx7bCE04Ye3H3F7-g=.aa67b2d1-3dff-4be3-8250-49ab6ce5aad6@github.com>
 <_Y8b69_yD3zF4kpqW3StHZ5p8E1XSNOmZOcs3Qyy6IE=.665c0ab8-ebeb-434e-b725-43a50e4f3eb1@github.com>
Message-ID: <2OGd66LXxsHPfRwtqXtnxc7bwfqZMKlTOXhJeznKAb8=.cdafe4a6-4976-4319-9b9a-a5515d91972c@github.com>

On Wed, 21 May 2025 17:09:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The test was originally written with product builds in mind; it didn't consider the slowness of debug builds, thus causing tests to fail.
>> 
>> Also there was a bug in testWeakAgainstClassValue: the test need to flush the backing map in the class to have the weak value removed. It is fixed in this patch as well.
>> 
>> Testing: ClassValueTest repeated 10 times on windows-x64/linux-x64/macosx-aarch64/linux-aarch64 fastdebug.
>
> 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:
> 
>  - Increase timeout, add comment for adjust for debugging
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cv-test-problems
>  - Restore incorrectly removed annotation
>  - Fix problems with class value tests

The update to increase the timeout to 1 minute * timeout factor, looks good to me.

I'm not too familiar with the bug that's requiring the `testWeakAgainstClassValue()` method to be updated, but if that helps with the test failures then it seems reasonable to fix it.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25292#pullrequestreview-2858558310

From paul.sandoz at oracle.com  Wed May 21 17:17:00 2025
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 21 May 2025 17:17:00 +0000
Subject: Towards a JSON API for the JDK
In-Reply-To: <CANSoFxtBXkhs5iwWHYtF489VS6GwNJBkQ0gx4ZiNbLrrrDMoOA@mail.gmail.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
 <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
 <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>
 <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com>
 <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr>
 <CAGZD2TAbv+dQQJCTbpQqa3LVFB90vqBZ-9sbcynAZpOE32bxag@mail.gmail.com>
 <CB7705F0-77B5-4119-BB77-D05D87B270F5@oracle.com>
 <CAGZD2TDQf8CtDXt0=Qdt50AAb-Ktouq2cA9L33pFCzBTwDEhqA@mail.gmail.com>
 <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com>
 <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com>
 <CB0376D6-B19A-450B-A047-76865A715FB9@oracle.com>
 <CANSoFxtBXkhs5iwWHYtF489VS6GwNJBkQ0gx4ZiNbLrrrDMoOA@mail.gmail.com>
Message-ID: <F030F162-488C-4FB8-A117-CCD88DFA5312@oracle.com>

Thank you Archie, nicely expressed.

The discussions in this thread will help us write a crisper set of goals/non-goals and a clearer motivation for the to-be-written JEP.

Paul.

On May 21, 2025, at 10:03?AM, Archie Cobbs <archie.cobbs at gmail.com> wrote:

On Wed, May 21, 2025 at 11:30?AM Paul Sandoz <paul.sandoz at oracle.com<mailto:paul.sandoz at oracle.com>> wrote:
I consider this a ?known unknown? (in the words of Mr. Rumsfeld). We would need to explore this area throughly, which includes the interconnection with Serialization 2.0, before we really know what we can and should do in the near and long term. That?s a significant effort, and I would like to separate it out from the non-trivial effort to first get a rather modest API over the line.

I think the discussions about object mapping and serialization are important and super interesting, but as Paul points out, not really an immediate concern wrt. this proposal.

In trying to understand this discussion, there are so many different concepts stirred up it's hard to keep track. It was helpful for me to go through the exercise of trying to partition the discussion space. Below is my feeble attempt at that...

Side note: for better or worse, there are lots of parallels here with XML, so I expect the solutions to parallel the XML solutions, for many of the same reasons. We should also avoid parallelling the mistakes (e.g., including too much functionality in the JDK which gets stale over time).

Q1: What is JSON? Just like XML, it's a specification for structured documents. By "structured" we mean the syntax implies a nested tree-like structure (by "document" we mean "file" or "streams of bytes").

Q2: What do people want to do with JSON?

1. Model a JSON document as Java objects in memory (using a "document object model" or DOM). Analogy: org.w3c.dom

2. Convert JSON DOM objects (see #1) to/from JSON documents. Analogy: {javax,jakarta}.xml.{parsers,transform}

3. Transform JSON documents. Analogy {javax,jakarta}.xml.transform

4. Read/write normal Java objects to/from JSON ("object mapping"). Analogy: {javax,jakarta}.xml.bind (JAXB), JiBX

5. Read/write normal Java objects, where JSON is one possible encoding ("serialization 2.0"). Analogy: java.beans.XMLEncoder (!?)

To me these are mostly separate problems whose solutions can be solved separately, each building on the previous (analogous to what was done with XML).

So what problem is this new API trying to solve? Just #1 and #2.

Of course, you probably want to use the solutions to problem 1 and 2 in your solution to problems 3, 4, and 5.

But let's respect the ordering here. In solving problems 1 and 2, we should focus on those problems only. The solution to problems 1 and 2, if done well, will automatically be a good foundation for solving problems 3, 4, and 5, etc.

-Archie

P.S.  I'm interested in "serialization 2.0" too - and that discussion must be happening somewhere else... where?

--
Archie L. Cobbs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250521/267c405a/attachment.htm>

From maurizio.cimadamore at oracle.com  Wed May 21 17:25:17 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 21 May 2025 18:25:17 +0100
Subject: Towards a JSON API for the JDK
In-Reply-To: <A7867680-E127-43E8-BB03-8539A86A9ADC@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <ef42a778-31a7-43da-b814-c584e9e90b92@oracle.com>
 <A7867680-E127-43E8-BB03-8539A86A9ADC@oracle.com>
Message-ID: <0e31ed85-25e7-44aa-903c-ceae80272c60@oracle.com>


On 21/05/2025 18:06, Paul Sandoz wrote:
> It was a design choice to be consistent with each json value having an
> X, accepting X in on construction and producing X out (notionally) on
> deconstruction, which leans into pattern matching. Definitely pros/cons
> to that e.g., we could instead make JonObject implement Map, or do as
> you suggest [*], both of which adjust how one reasons about the X in and
>   X out.

I agree with this. When I wrote, I thought that it might be possible to 
address some of these use cases using instance pattern declaration on 
the array class (e.g. having an instance pattern that extracts the i-th 
element of a JSONArray) -- but the instance pattern proposals we have 
discussed so far [1] are not powerful enough to model that use case.

Maurizio

[1] - 
https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250521/3ab6f27e/attachment-0001.htm>

From plevart at openjdk.org  Wed May 21 17:26:54 2025
From: plevart at openjdk.org (Peter Levart)
Date: Wed, 21 May 2025 17:26:54 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v2]
In-Reply-To: <w-jdj2tTfuMPgqeQkUG3dxP8-LkygRZAlQtRvEtxnfU=.3e83d2dd-5c8d-48d0-9d6c-a86f599f8825@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <w-jdj2tTfuMPgqeQkUG3dxP8-LkygRZAlQtRvEtxnfU=.3e83d2dd-5c8d-48d0-9d6c-a86f599f8825@github.com>
Message-ID: <jRRSKwgRO4_LVhD28AZ3v-lyd5zMUGiyfXsSfUbFaxE=.edc9ab38-41ae-438c-b42f-a7471a58a1d2@github.com>

On Wed, 21 May 2025 09:09:15 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
>> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
>> 
>> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
>> 
>> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Return first argument in case of tie (to be consistent with BinaryOperator); junit tests

Hi,

There exists a class implementing Comparator<T> and min and max methods too. But they are generic:

https://github.com/google/guava/blob/f1b962f1f1d1c96068c62b7ff55426ea249cbd55/guava/src/com/google/common/collect/Ordering.java#L622C10-L622C79


  public <E extends T> E max(E a, E b) {
    return (compare(a, b) >= 0) ? a : b;
  }


So when I have:


Comparator<CharSequence> cmp = ...

var greatest = cmp.max("foo", "bar");


...then the type of `greatest` would be `String` and not `CharSequence`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-2898707140

From jiangli at openjdk.org  Wed May 21 17:27:52 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 21 May 2025 17:27:52 GMT
Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder
 on static-jdk [v2]
In-Reply-To: <akvr3HuFyZubFssoMOl6_c7wwbKgTxXAEUJfgvnnkGs=.ba807f25-823c-48f3-8831-71067ac1cc31@github.com>
References: <E986980rvWra05uWXYMdT8N4i_0RGxNC_KubDF6tXAw=.a6ab5563-b75c-45b2-b367-31d001cc294e@github.com>
 <akvr3HuFyZubFssoMOl6_c7wwbKgTxXAEUJfgvnnkGs=.ba807f25-823c-48f3-8831-71067ac1cc31@github.com>
Message-ID: <68OItsB8gIJK4njZ1FkN-gX4iFw6JW92wjfOUlD2LxQ=.aff91b03-56c7-4dd6-baac-bf337b02baff@github.com>

On Wed, 14 May 2025 15:44:08 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this PR for skipping jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the context from https://bugs.openjdk.org/browse/JDK-8356904 description:
>> 
>> jdk/test/lib/process/TestNativeProcessBuilder.java (in lib-test/tier1) uses a native test launcher executable, exejvm-test-launcher, which has explicitly dependency on libjvm.so. The test fails on static-jdk. This is the same issue as [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276). With [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276), we decided to skip the affected hotspot tier1 tests on static-jdk. We should skip jdk/test/lib/process/TestNativeProcessBuilder.java on static-jdk as well. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year in test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java.

Still need a (R)eviewer. @AlanBateman, @jerboaa, or @dholmes-ora Could one of you help review/approve? Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25220#issuecomment-2898711067

From jpai at openjdk.org  Wed May 21 17:31:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 17:31:55 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
Message-ID: <hnTAf2Jrr2_rUheZyAgz5zqzEf7O8scbMAaYWc1zsg0=.58a3e165-d095-4916-bd82-cc49b2fdae5d@github.com>

On Wed, 21 May 2025 15:49:29 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mismatched order is considered invalid

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 119:

> 117:      * element is not equal to "." or ".."
> 118:      *
> 119:      * @param entryName CEN/LOC header file name field entry

Nit - `@param entryName ZIP entry name`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100821550

From jvernee at openjdk.org  Wed May 21 18:02:05 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 21 May 2025 18:02:05 GMT
Subject: RFR: 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java
 test scenario to run as manual
In-Reply-To: <IMl8opuemVxRGiD46GfPuh0eZ1d6R86xkOdc3HIsT1I=.228f1873-ee56-4c22-919b-afd86dc8cc20@github.com>
References: <IMl8opuemVxRGiD46GfPuh0eZ1d6R86xkOdc3HIsT1I=.228f1873-ee56-4c22-919b-afd86dc8cc20@github.com>
Message-ID: <JnZenbHLgaNADuzft2fESFrgkgtK2NXGy6Ov74EngiY=.7e9da5e2-e079-4b53-a492-b0776c78c4c1@github.com>

On Wed, 21 May 2025 13:44:09 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25355#pullrequestreview-2858676969

From jlu at openjdk.org  Wed May 21 18:09:52 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 21 May 2025 18:09:52 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v3]
In-Reply-To: <p95EYb_nEBCfPpj5uTtE7HhrF0txSRLcQrULKYq1nwY=.90bf3699-fc29-44c8-ab42-a580cf454b30@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com>
 <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com>
 <Frh347wHPLN6iVS4uGojdUBdbnP3Ulx15keIvh7nzyM=.9399e47b-9511-4f61-b451-9e19ac9b4e19@github.com>
 <p95EYb_nEBCfPpj5uTtE7HhrF0txSRLcQrULKYq1nwY=.90bf3699-fc29-44c8-ab42-a580cf454b30@github.com>
Message-ID: <myqXl51mHVhM6TjDOqMvGhCijJ5FwL3EEvk0krR6kOg=.881d941b-e2c2-46b2-8d9d-e5b2034879da@github.com>

On Wed, 21 May 2025 16:54:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Actually providing mock charset was a workaround of not having public method for getting the input encoding. I think it would be an overkill to introduce a new public method because it will not be used much, as most cases are suffice with the existing one (Console is used for interactive user enviornment, and I don't believe users would like to see different characters displayed for the input).
>
>> There is script.exp, but it tests sun.stdout.encoding, not stdout.encoding.
> 
> It is addressed in this PR

I think the JBS bug ID needs to be added to `CharsetTest.java` as well then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2100890130

From rriggs at openjdk.org  Wed May 21 18:48:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 May 2025 18:48:52 GMT
Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder
 on static-jdk [v2]
In-Reply-To: <akvr3HuFyZubFssoMOl6_c7wwbKgTxXAEUJfgvnnkGs=.ba807f25-823c-48f3-8831-71067ac1cc31@github.com>
References: <E986980rvWra05uWXYMdT8N4i_0RGxNC_KubDF6tXAw=.a6ab5563-b75c-45b2-b367-31d001cc294e@github.com>
 <akvr3HuFyZubFssoMOl6_c7wwbKgTxXAEUJfgvnnkGs=.ba807f25-823c-48f3-8831-71067ac1cc31@github.com>
Message-ID: <D6JR_xAuTLsS7bdo4DReyx29b3isrXPoqNFQB25yPDc=.49c0de35-32ab-498f-a1a7-e706b178d9dd@github.com>

On Wed, 14 May 2025 15:44:08 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this PR for skipping jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the context from https://bugs.openjdk.org/browse/JDK-8356904 description:
>> 
>> jdk/test/lib/process/TestNativeProcessBuilder.java (in lib-test/tier1) uses a native test launcher executable, exejvm-test-launcher, which has explicitly dependency on libjvm.so. The test fails on static-jdk. This is the same issue as [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276). With [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276), we decided to skip the affected hotspot tier1 tests on static-jdk. We should skip jdk/test/lib/process/TestNativeProcessBuilder.java on static-jdk as well. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year in test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java.

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25220#pullrequestreview-2858791041

From rriggs at openjdk.org  Wed May 21 18:51:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 May 2025 18:51:55 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v2]
In-Reply-To: <w-jdj2tTfuMPgqeQkUG3dxP8-LkygRZAlQtRvEtxnfU=.3e83d2dd-5c8d-48d0-9d6c-a86f599f8825@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <w-jdj2tTfuMPgqeQkUG3dxP8-LkygRZAlQtRvEtxnfU=.3e83d2dd-5c8d-48d0-9d6c-a86f599f8825@github.com>
Message-ID: <L8jUsLFqd3D3r6i8YCxi_Sgck9P2IhrozimZTU9ZFEA=.c0cca701-8197-4cc2-8de7-bfc0d6a734b4@github.com>

On Wed, 21 May 2025 09:09:15 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
>> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
>> 
>> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
>> 
>> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Return first argument in case of tie (to be consistent with BinaryOperator); junit tests

Looks good.  Thanks

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25297#pullrequestreview-2858798359

From duke at openjdk.org  Wed May 21 18:55:53 2025
From: duke at openjdk.org (Abhishek N)
Date: Wed, 21 May 2025 18:55:53 GMT
Subject: RFR: 8355393: Create a Test case to have special cases coverage
 for currency.getInstance() [v2]
In-Reply-To: <ONvSFsC7l-ZLsR9BBNbqiQoF2O-EFDd1JPa6jJn5Hgc=.074c130b-9585-47af-b589-b0970792ef39@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
 <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>
 <ONvSFsC7l-ZLsR9BBNbqiQoF2O-EFDd1JPa6jJn5Hgc=.074c130b-9585-47af-b589-b0970792ef39@github.com>
Message-ID: <mxdhF4l9bL9GXDmENHcCrTONEN5VCFP8wZb0kDLkFjA=.9deb4448-b918-482d-92f6-6bc5eef981ee@github.com>

On Thu, 15 May 2025 18:50:35 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Abhishek N has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   correcting jtreg header order, add meaningful comments for each test methods and properties file
>
> This test is not effectively testing standard ISO 4217 future transition currencies. For example, with your patch, if I supply the following changes to the ISO 4217 currency data:
> (i.e. Make country `LK` have a transition currency of `XCH` in July)
> 
> 
> --- a/src/java.base/share/data/currency/CurrencyData.properties
> +++ b/src/java.base/share/data/currency/CurrencyData.properties
> @@ -55,7 +55,7 @@ all=ADP020-AED784-AFA004-AFN971-ALL008-AMD051-ANG532-AOA973-ARS032-ATS040-AUD036
>    SRD968-SRG740-SSP728-STD678-STN930-SVC222-SYP760-SZL748-THB764-TJS972-TMM795-TMT934-TND788-TOP776-\
>    TPE626-TRL792-TRY949-TTD780-TWD901-TZS834-UAH980-UGX800-USD840-USN997-USS998-UYI940-\
>    UYU858-UZS860-VEB862-VED926-VEF937-VES928-VND704-VUV548-WST882-XAF950-XAG961-XAU959-XBA955-\
> -  XBB956-XBC957-XBD958-XCD951-XCG532-XDR960-XFO000-XFU000-XOF952-XPD964-XPF953-\
> +  XBB956-XBC957-XBD958-XCD951-XCG532-XCH533-XDR960-XFO000-XFU000-XOF952-XPD964-XPF953-\
>    XPT962-XSU994-XTS963-XUA965-XXX999-YER886-YUM891-ZAR710-ZMK894-ZMW967-ZWD716-ZWG924-\
>    ZWL932-ZWN942-ZWR935
>  
> @@ -502,7 +502,7 @@ GS=GBP
>  # SPAIN
>  ES=EUR
>  # SRI LANKA
> -LK=LKR
> +LK=LKR;2025-07-01-04-00-00;XCH
> 
> 
> and break some functionality related to _future/special_ currencies in `Currency.getInstance(String)`,
> (Similar to 8, prior to the fix backported)
> 
> 
> --- a/src/java.base/share/classes/java/util/Currency.java
> +++ b/src/java.base/share/classes/java/util/Currency.java
> @@ -326,13 +326,6 @@ private static Currency getInstance(String currencyCode, int defaultFractionDigi
>                  defaultFractionDigits = (tableEntry & SIMPLE_CASE_COUNTRY_DEFAULT_DIGITS_MASK) >> SIMPLE_CASE_COUNTRY_DEFAULT_DIGITS_SHIFT;
>                  numericCode = (tableEntry & NUMERIC_CODE_MASK) >> NUMERIC_CODE_SHIFT;
>                  found = true;
> -            } else { //special case
> -                int[] fractionAndNumericCode = SpecialCaseEntry.findEntry(currencyCode);
> -                if (fractionAndNumericCode != null) {
> -                    defaultFractionDigits = fractionAndNumericCode[0];
> -                    numericCode = fractionAndNumericCode[1];
> -                    found = true;
> -                }
>              }
> 
> 
> With the above changes, we would expect this test to fail, since `getInstance("XCH")` should throw an exception. However, your test still passes. What this patch is doing is selectively testing a handful of Currencies with the system property override. This is not sufficient to ensure test coverage for testing a standard ISO 4217 tran...

@justin-curtis-lu @weibxiao 

Our objective is to ensure the proper functionality of the Currency.getInstance() methods?particularly to guarantee that currencies defined with special conditions (such as future cutover dates) will work correctly once the system date passes those thresholds.

For example, in the case of the mapping:

LK=LKR;2025-07-01-04-00-00;XCH

we want to ensure that, once the system date passes 2025-07-01T04:00:00, both Currency.getInstance("XCH") and Currency.getInstance(new Locale("LK")) will work as expected and not throw an IllegalArgumentException.

To facilitate this, we use a custom currency.properties file that includes entries for currencies with such special conditions, where the cutover date has already passed. An example entry would be:


BI=BFI,108,0,2022-12-15T04:00:00

Without this customization, in earlier JDK versions (which do not include recent fixes), calling Currency.getInstance("BFI") would result in an IllegalArgumentException and issues such as JDK-8353433 would have been caught in earlier stages itself. 

Including these entries allows us to surface such issues earlier in the development or testing lifecycle.

**The test in mainline utilize the ClassFile API for mocking system time (such as System::currentTimeMillis), the ClassFile API is not supported in lower LTS JDK versions. Therefore, we rely on the custom currency properties approach to simulate post-cutover behavior for those environments.**

**Since additional currencies with similar cutover rules may be introduced in the future, our approach ensures that Currency.getInstance() continues to function reliably across all supported LTS JDK versions?even before the actual cutover date is reached?by validating currency data early using the custom CurrencyData.properties..**

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2898918478

From jiangli at openjdk.org  Wed May 21 18:58:56 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 21 May 2025 18:58:56 GMT
Subject: Integrated: 8356904: Skip
 jdk/test/lib/process/TestNativeProcessBuilder on static-jdk
In-Reply-To: <E986980rvWra05uWXYMdT8N4i_0RGxNC_KubDF6tXAw=.a6ab5563-b75c-45b2-b367-31d001cc294e@github.com>
References: <E986980rvWra05uWXYMdT8N4i_0RGxNC_KubDF6tXAw=.a6ab5563-b75c-45b2-b367-31d001cc294e@github.com>
Message-ID: <Khu5CKJDLRlOfvo7Y2KvNU-3lOXVK7qWFMXkQXFXh0g=.e2a5a9a6-92f0-42fe-aeb1-5ec4eaf893b4@github.com>

On Tue, 13 May 2025 21:28:00 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR for skipping jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the context from https://bugs.openjdk.org/browse/JDK-8356904 description:
> 
> jdk/test/lib/process/TestNativeProcessBuilder.java (in lib-test/tier1) uses a native test launcher executable, exejvm-test-launcher, which has explicitly dependency on libjvm.so. The test fails on static-jdk. This is the same issue as [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276). With [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276), we decided to skip the affected hotspot tier1 tests on static-jdk. We should skip jdk/test/lib/process/TestNativeProcessBuilder.java on static-jdk as well. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK.

This pull request has now been integrated.

Changeset: 400c9350
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/400c935082a0d4d843cf369af6fefde12d637438
Stats:     19 lines in 2 files changed: 18 ins; 0 del; 1 mod

8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder on static-jdk

Reviewed-by: henryjen, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/25220

From jiangli at openjdk.org  Wed May 21 18:58:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 21 May 2025 18:58:55 GMT
Subject: RFR: 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder
 on static-jdk [v2]
In-Reply-To: <D6JR_xAuTLsS7bdo4DReyx29b3isrXPoqNFQB25yPDc=.49c0de35-32ab-498f-a1a7-e706b178d9dd@github.com>
References: <E986980rvWra05uWXYMdT8N4i_0RGxNC_KubDF6tXAw=.a6ab5563-b75c-45b2-b367-31d001cc294e@github.com>
 <akvr3HuFyZubFssoMOl6_c7wwbKgTxXAEUJfgvnnkGs=.ba807f25-823c-48f3-8831-71067ac1cc31@github.com>
 <D6JR_xAuTLsS7bdo4DReyx29b3isrXPoqNFQB25yPDc=.49c0de35-32ab-498f-a1a7-e706b178d9dd@github.com>
Message-ID: <oHYaog0gwq6y6SEyglg0vdFY0FQESyk2fbSLBZ5uf2g=.4333bb89-002a-4cff-a85a-ce1698367ff5@github.com>

On Wed, 21 May 2025 18:46:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year in test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java.
>
> lgtm

@RogerRiggs Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25220#issuecomment-2898926876

From vklang at openjdk.org  Wed May 21 19:04:58 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 21 May 2025 19:04:58 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message [v5]
In-Reply-To: <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com>
Message-ID: <IVjOBAeud3_BeeMPcBpSoySfTQqpLmjk5LS-OV3pCGc=.ea6bcd15-6aac-48e3-b8e4-bc22b98c7961@github.com>

On Tue, 20 May 2025 10:54:44 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

>> 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 two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
>  - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

Thanks for your work here, @He-Pin

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23050#pullrequestreview-2858828972

From liach at openjdk.org  Wed May 21 19:09:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 May 2025 19:09:03 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message [v5]
In-Reply-To: <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com>
Message-ID: <r5TiB4UDA5P30qpeTo4kAnbrUdY158IipOHlfx0C32M=.2d52e166-7913-462f-bdeb-9cbfbab85fdc@github.com>

On Tue, 20 May 2025 10:54:44 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

>> 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 two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
>  - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

Looks good, though I would relax the check on messages to just include the offending variable names to ensure compatible evolution.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23050#pullrequestreview-2858837437

From rriggs at openjdk.org  Wed May 21 19:13:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 May 2025 19:13:53 GMT
Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(),
 use FD_CLOEXEC instead of close()
In-Reply-To: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
References: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
Message-ID: <lFj7d1LqoWpksdywivQQFvpOj_NI5ETXafl2QuQB7zc=.bf996897-fa67-47fd-b60f-a654a98d9af9@github.com>

On Mon, 19 May 2025 12:23:07 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi, please consider the following patch.
> 
> This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc.
> 
> This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens).
> 
> Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409
> 
> This patch also fixes two subtle bugs:
> - we didn't check the return value of the close() inside closeAllFileDescriptors
> - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it)
> 
> ----
> 
> Testing:
> 
> We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC.
> 
> - in the parent JVM, the test opens a file in native code without FD_CLOEXEC
> - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open
> 
> I verified that the test correctly detects a broken implementation that leaks file descriptors. 
> 
> I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX).
> 
> I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green.

Looks good

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25301#pullrequestreview-2858850942

From bpb at openjdk.org  Wed May 21 19:18:03 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 21 May 2025 19:18:03 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v25]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: <8EmX-PrYq9uwwuFk74NJbqEDmhpS5DOZjnUeciR7nvw=.0f750da6-8002-4345-b5a3-f1c3faf8237f@github.com>

> Implement the requested methods and add a test thereof.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 29 additional commits since the last revision:

 - 8354724: Update API notes
 - Merge
 - 8354724: Revert previous commit and remove first comma in the change
 - 8354724: Improve verbiage about I/O errors
 - 8354724: Replace getChars in previous commit with subSequence
 - 8354724: Improve readAllAsString method of Reader returned by Reader.of
 - 8354724: Change readAllCharsAsString as suggested; move test to proper location
 - 8354724: "stream" -> "reader"
 - 8354724: Attempt to further improve verbiage
 - Merge
 - ... and 19 more: https://git.openjdk.org/jdk/compare/bcf1bca6...f9c732eb

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/0880af29..f9c732eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=23-24

  Stats: 66091 lines in 1204 files changed: 34984 ins; 23883 del; 7224 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 plevart at openjdk.org  Wed May 21 19:22:52 2025
From: plevart at openjdk.org (Peter Levart)
Date: Wed, 21 May 2025 19:22:52 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v2]
In-Reply-To: <w-jdj2tTfuMPgqeQkUG3dxP8-LkygRZAlQtRvEtxnfU=.3e83d2dd-5c8d-48d0-9d6c-a86f599f8825@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <w-jdj2tTfuMPgqeQkUG3dxP8-LkygRZAlQtRvEtxnfU=.3e83d2dd-5c8d-48d0-9d6c-a86f599f8825@github.com>
Message-ID: <38y18L1eSJAGuzFgH8xAn38k_Xu8pqueLhYYIEAzz8M=.bd30476b-e887-414a-8f03-f3f26c78f66b@github.com>

On Wed, 21 May 2025 09:09:15 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
>> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
>> 
>> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
>> 
>> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Return first argument in case of tie (to be consistent with BinaryOperator); junit tests

What I was trying to say is that not only would Guava's Ordering not compile any more (it would still be binary compatible I think, as both methods have same erasure), but I also think that generic max and min as defined by Guava's Ordering are more useful too. So what do you think of making them generic like this:


    default <E extends T> E max(E e1, E e2) {
        return compare(e1, e2) >= 0 ? e1 : e2;
    }
    
    default <E extends T> E min(E e1, E e2) {
        return compare(e1, e2) <= 0 ? e1 : e2;
    }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-2898984302

From mikael at openjdk.org  Wed May 21 19:27:55 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 21 May 2025 19:27:55 GMT
Subject: RFR: 8357173: Split jtreg test group jdk tier3 [v2]
In-Reply-To: <hUHJK_xigEn8RYwEXskv9FTwQqb18SNCKy-28uSPyAE=.5c0144e8-da7d-4e72-95dc-c8f05b0a7e06@github.com>
References: <4H8A-53zl5Hm126KxHdtjZifalF8ZRZuknZlI--9qV0=.6c711365-6b7d-41c7-b2dd-b155bd114181@github.com>
 <hUHJK_xigEn8RYwEXskv9FTwQqb18SNCKy-28uSPyAE=.5c0144e8-da7d-4e72-95dc-c8f05b0a7e06@github.com>
Message-ID: <fCD0apswRdr-uP1edFsPsIAkvF0j-NpgfJkM16AaIgI=.950356b9-bb45-4d6f-b4a5-928ede09f838@github.com>

On Wed, 21 May 2025 13:53:37 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> We need to be able to run the jdk_jpackage tests separately from the rest of jdk tier3. To achieve this we would like to introduce tier3_part1 and tier3_part2 groups similar to how lower tiers are split.
>
> Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - grammar
>  - Clarified the group split with comments

Marked as reviewed by mikael (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25274#pullrequestreview-2858888804

From naoto at openjdk.org  Wed May 21 19:29:08 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 May 2025 19:29:08 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v4]
In-Reply-To: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
Message-ID: <kPGBTgP8cygkC-ufTlutlYYiAJ40KzRY57OGJxCu4j0=.ed8a0e9e-78b6-4bf4-8d66-4a60459d5e56@github.com>

> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  CharsetTest clean-up

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25271/files
  - new: https://git.openjdk.org/jdk/pull/25271/files/dd370768..ce1c8035

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=02-03

  Stats: 8 lines in 1 file changed: 1 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25271/head:pull/25271

PR: https://git.openjdk.org/jdk/pull/25271

From naoto at openjdk.org  Wed May 21 19:29:08 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 May 2025 19:29:08 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v4]
In-Reply-To: <myqXl51mHVhM6TjDOqMvGhCijJ5FwL3EEvk0krR6kOg=.881d941b-e2c2-46b2-8d9d-e5b2034879da@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com>
 <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com>
 <Frh347wHPLN6iVS4uGojdUBdbnP3Ulx15keIvh7nzyM=.9399e47b-9511-4f61-b451-9e19ac9b4e19@github.com>
 <p95EYb_nEBCfPpj5uTtE7HhrF0txSRLcQrULKYq1nwY=.90bf3699-fc29-44c8-ab42-a580cf454b30@github.com>
 <myqXl51mHVhM6TjDOqMvGhCijJ5FwL3EEvk0krR6kOg=.881d941b-e2c2-46b2-8d9d-e5b2034879da@github.com>
Message-ID: <fY_GgUx8bTJEM9r77v1TA-xViMXglNIUGpf-RIuVDAU=.a5e7ce8c-4b53-4ac4-9261-f8d56025ed02@github.com>

On Wed, 21 May 2025 18:07:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

>>> There is script.exp, but it tests sun.stdout.encoding, not stdout.encoding.
>> 
>> It is addressed in this PR
>
> I think the JBS bug ID needs to be added to `CharsetTest.java` as well then.

Bugid added to the test. Additionally replaced testsrc/jdk/classes with Utils ones

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2101014981

From rriggs at openjdk.org  Wed May 21 19:29:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 May 2025 19:29:55 GMT
Subject: RFR: 8353741: Eliminate table lookup in UUID.toString [v8]
In-Reply-To: <G7zjTKnYvpFza0OH2jtfj9NWuNjSX8lRbUj46rYP4Lw=.6bbc52ad-26e5-453c-810c-b5c055359c38@github.com>
References: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
 <G7zjTKnYvpFza0OH2jtfj9NWuNjSX8lRbUj46rYP4Lw=.6bbc52ad-26e5-453c-810c-b5c055359c38@github.com>
Message-ID: <KNal539gbTUUVGK9PqcVprdE2TLPx8SVR5noQ8na_tg=.681bfaa3-d386-49a9-ae29-2cd7ccad743c@github.com>

On Wed, 21 May 2025 00:57:30 GMT, Shaojin Wen <swen at openjdk.org> 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:
> 
>   fix comments, from @j3graham

Looks good. Thanks for the detailed comments and vectorized hex to string conversion.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22928#pullrequestreview-2858893329

From almatvee at openjdk.org  Wed May 21 19:35:55 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 May 2025 19:35:55 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v3]
In-Reply-To: <zkBr9MToIDhhJ-Y7pgPbNqumbE1YtA9dlHmnJUApP5k=.287f87b7-44f0-46de-a314-c44702f16a2f@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <zkBr9MToIDhhJ-Y7pgPbNqumbE1YtA9dlHmnJUApP5k=.287f87b7-44f0-46de-a314-c44702f16a2f@github.com>
Message-ID: <nl5VM69GxPhiAgntuOh9CIOWMxBDqso3Z7qMDBzappo=.829eff41-9fa2-4232-901a-2113646befd9@github.com>

On Wed, 21 May 2025 12:41:24 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

>> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space
>> 
>> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372
>
> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   also use <package-dep-string> in other locations

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties line 298:

> 296: \  --linux-menu-group <menu-group-name>\n\
> 297: \          Menu group this application is placed in\n\
> 298: \  --linux-package-deps\n\

I am not familiar with this CLI option, but if it is "dependency list separated by comma and space", then it should be documented. Similar to `--add-modules`.

Also, why we need `space` as well?

For example:

\ --linux-package-deps <package-dep-list>\n\
\ A comma (",") separated list of required packages or capabilities for the application\n\


or if space is really needed:

\ --linux-package-deps <package-dep-list>\n\
\ A comma and space (", ") separated list of required packages or capabilities for the application\n\

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2101024107

From lancea at openjdk.org  Wed May 21 19:38:54 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 21 May 2025 19:38:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <Bp4U2JkzCeZykmalvThoeOCO5XTdl7IrpP0SaZZGdaU=.d69d936b-57fc-4b6c-8b71-155b68c5b64d@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
 <Bp4U2JkzCeZykmalvThoeOCO5XTdl7IrpP0SaZZGdaU=.d69d936b-57fc-4b6c-8b71-155b68c5b64d@github.com>
Message-ID: <QwsEzNG9UTgwBrrGNcUriTdtUOSRuqauAjINIekCshQ=.e718a3d0-566c-4695-8cbe-082ba8f80324@github.com>

On Wed, 21 May 2025 16:45:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Nit - we should call it exit code instead of status code, both for 0 and non-zero exit codes.

I don't have a preference but unix/MacOS commands vary:

-  ls command: The ls utility exits?0 on success, and?>0 if an error occurs.
- grep command: 

> The grep utility exits with one of the following values:

     0     One or more lines were selected.
     1     No lines were selected.
     >1    An error occurred.

- unzip command:

> The exit status (or error level) approximates the exit codes defined by PKWARE and takes on the
       following values, except under VMS:

              0      normal; no errors or warnings detected.

              1      one or more warning errors were encountered, but processing completed successfully
                     anyway.  This includes zipfiles where one or more files was skipped due to unsupported
                     compression method or encryption with an unknown password.

              2      a generic error in the zipfile format was detected.  Processing may have completed
                     successfully anyway; some broken zipfiles created by other archivers have simple work-
                     arounds.
              3      a severe error in the zipfile format was detected.  Processing probably failed
                     immediately.

              4      unzip was unable to allocate memory for one or more buffers during program
                     initialization.

              5      unzip was unable to allocate memory or unable to obtain a tty to read the decryption
                     password(s).

              6      unzip was unable to allocate memory during decompression to disk.

              7      unzip was unable to allocate memory during in-memory decompression.

              8      [currently not used]

              9      the specified zipfiles were not found.

              10     invalid options were specified on the command line.

              11     no matching files were found.

              50     the disk is (or was) full during extraction.

              51     the end of the ZIP archive was encountered prematurely.

              80     the user aborted unzip prematurely with control-C (or similar)

              81     testing or extraction of one or more files failed due to unsupported compression methods
                     or unsupported decryption.

              82     no files were found due to bad decryption password(s).  (If even one file is successfully
                     processed, however, the exit status is 1.)

So perhaps something along the lines of

> The jar tool exits with a status of 0 if there were no integrity issues encountered and >0 if an error/warning occurred

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101029665

From almatvee at openjdk.org  Wed May 21 19:41:57 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 May 2025 19:41:57 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v3]
In-Reply-To: <dbZ87UXLFMgw7wbRK9B2bp9Tm3n-5Jb131bMvKUhLAw=.3300f4fa-3996-4b6e-b007-9ce536914577@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <2GLmGAWCUplxhAeiwVfOKzXw_RDZQedXbgK3lqdzAfw=.730af4f3-4506-43ad-9379-b8d3d380dae5@github.com>
 <35OauyGRBboCkDKqCm9OWVJ6suePq0MBtzQ2Sj0Fctk=.c12a1dce-4aab-4ca6-b134-7a2d24395a42@github.com>
 <FRMMIWVz_184ByS5Al3X8dixrva-18XTaIKd4fiHOPc=.16dd7db1-2a3e-41b8-b1fa-1a68e6075380@github.com>
 <dbZ87UXLFMgw7wbRK9B2bp9Tm3n-5Jb131bMvKUhLAw=.3300f4fa-3996-4b6e-b007-9ce536914577@github.com>
Message-ID: <fmaos-ud6DnSWRhLxKbLKFFYzdbHG9-evYJEev94ifc=.965d3970-ab46-4c68-a952-379249e3a609@github.com>

On Wed, 21 May 2025 12:03:16 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> As in, this worked in my testing: `--linux-package-deps "foo, bar"`, see https://github.com/JetBrains/compose-multiplatform/pull/5227#issuecomment-2659470908
>
>> As in, this worked in my testing: --linux-package-deps "foo, bar"
> 
> Of course. You can put any string for `--linux-package-deps` option, jpackage will pass it as-is to the underlying tool. Unlike, e.g. `--arguments`, for which jpackage will tokenize the value into a string array.

I think we should document that jpackage will pass value as-is similar to `--mac-app-image-sign-identity`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2101032436

From erikj at openjdk.org  Wed May 21 19:52:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 May 2025 19:52:56 GMT
Subject: Integrated: 8357173: Split jtreg test group jdk tier3
In-Reply-To: <4H8A-53zl5Hm126KxHdtjZifalF8ZRZuknZlI--9qV0=.6c711365-6b7d-41c7-b2dd-b155bd114181@github.com>
References: <4H8A-53zl5Hm126KxHdtjZifalF8ZRZuknZlI--9qV0=.6c711365-6b7d-41c7-b2dd-b155bd114181@github.com>
Message-ID: <alJ5B436fYhfgzntGAIbFmyR3G7rzinmIUX8LvUmTvI=.06c597c6-070f-4529-8265-930225c3e71a@github.com>

On Fri, 16 May 2025 20:16:02 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> We need to be able to run the jdk_jpackage tests separately from the rest of jdk tier3. To achieve this we would like to introduce tier3_part1 and tier3_part2 groups similar to how lower tiers are split.

This pull request has now been integrated.

Changeset: afcbf6b2
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/afcbf6b2f49c00a544e6db5b4ed9da76c0bdcba4
Stats:     13 lines in 1 file changed: 11 ins; 1 del; 1 mod

8357173: Split jtreg test group jdk tier3

Reviewed-by: mikael

-------------

PR: https://git.openjdk.org/jdk/pull/25274

From ethan at mccue.dev  Wed May 21 19:55:18 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Wed, 21 May 2025 15:55:18 -0400
Subject: Towards a JSON API for the JDK
In-Reply-To: <CANSoFxtBXkhs5iwWHYtF489VS6GwNJBkQ0gx4ZiNbLrrrDMoOA@mail.gmail.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr>
 <47c7e242-50c0-40f2-bb5b-ffd5017dbb6e@oracle.com>
 <1429266990.267927864.1747420967544.JavaMail.zimbra@univ-eiffel.fr>
 <1749769763.269642798.1747667798777.JavaMail.zimbra@univ-eiffel.fr>
 <C218A4D6-6D58-48EC-8A7A-E50317671D92@oracle.com>
 <1865551766.269836108.1747688192018.JavaMail.zimbra@univ-eiffel.fr>
 <9F1EDC9A-34D3-4A2F-9FB8-4BE2DD59C9D8@oracle.com>
 <681192895.269845176.1747691751530.JavaMail.zimbra@univ-eiffel.fr>
 <CAGZD2TAbv+dQQJCTbpQqa3LVFB90vqBZ-9sbcynAZpOE32bxag@mail.gmail.com>
 <CB7705F0-77B5-4119-BB77-D05D87B270F5@oracle.com>
 <CAGZD2TDQf8CtDXt0=Qdt50AAb-Ktouq2cA9L33pFCzBTwDEhqA@mail.gmail.com>
 <10C0BCDE-1C3A-44BA-8991-28EC3DFA0994@oracle.com>
 <32a601ec-e387-4894-8d27-6cc2fef32739@gmail.com>
 <CB0376D6-B19A-450B-A047-76865A715FB9@oracle.com>
 <CANSoFxtBXkhs5iwWHYtF489VS6GwNJBkQ0gx4ZiNbLrrrDMoOA@mail.gmail.com>
Message-ID: <CA+NR86iOQsFsLsUbeGAj0GsUP9tC0E9FNDiMHbjuLzB3X2KO4Q@mail.gmail.com>

I think you missed a 2.5 which is to use the information in DOM objects to
perform useful work.

On Wed, May 21, 2025, 1:04?PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Wed, May 21, 2025 at 11:30?AM Paul Sandoz <paul.sandoz at oracle.com>
> wrote:
>
>> I consider this a ?known unknown? (in the words of Mr. Rumsfeld). We
>> would need to explore this area throughly, which includes the
>> interconnection with Serialization 2.0, before we really know what we can
>> and should do in the near and long term. That?s a significant effort, and I
>> would like to separate it out from the non-trivial effort to first get a
>> rather modest API over the line.
>
>
> I think the discussions about object mapping and serialization are
> important and super interesting, but as Paul points out, not really an
> immediate concern wrt. this proposal.
>
> In trying to understand this discussion, there are so many different
> concepts stirred up it's hard to keep track. It was helpful for me to go
> through the exercise of trying to partition the discussion space. Below is
> my feeble attempt at that...
>
> Side note: for better or worse, there are lots of parallels here with XML,
> so I expect the solutions to parallel the XML solutions, for many of the
> same reasons. We should also avoid parallelling the mistakes (e.g.,
> including too much functionality in the JDK which gets stale over time).
>
> Q1: What is JSON? Just like XML, it's a specification for structured
> documents. By "structured" we mean the syntax implies a nested tree-like
> structure (by "document" we mean "file" or "streams of bytes").
>
> Q2: What do people want to do with JSON?
>
> 1. Model a JSON document as Java objects in memory (using a "document
> object model" or DOM). Analogy: org.w3c.dom
>
> 2. Convert JSON DOM objects (see #1) to/from JSON documents. Analogy:
> {javax,jakarta}.xml.{parsers,transform}
>
> 3. Transform JSON documents. Analogy {javax,jakarta}.xml.transform
>
> 4. Read/write normal Java objects to/from JSON ("object mapping").
> Analogy: {javax,jakarta}.xml.bind (JAXB), JiBX
>
> 5. Read/write normal Java objects, where JSON is one possible encoding
> ("serialization 2.0"). Analogy: java.beans.XMLEncoder (!?)
>
> To me these are mostly separate problems whose solutions can be solved
> separately, each building on the previous (analogous to what was done with
> XML).
>
> So what problem is this new API trying to solve? Just #1 and #2.
>
> Of course, you probably want to use the solutions to problem 1 and 2 in
> your solution to problems 3, 4, and 5.
>
> But let's respect the ordering here. In solving problems 1 and 2, we
> should focus on those problems only. The solution to problems 1 and 2, if
> done well, will automatically be a good foundation for solving problems 3,
> 4, and 5, etc.
>
> -Archie
>
> P.S.  I'm interested in "serialization 2.0" too - and that discussion must
> be happening somewhere else... where?
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250521/b5d16f8c/attachment-0001.htm>

From liach at openjdk.org  Wed May 21 20:16:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 May 2025 20:16:01 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6]
In-Reply-To: <mywKv4OJEmbTf_Y4mc5bMAv2sPplyFz3TwXmal12bG4=.5afa10a6-34ad-41f0-85ef-dc75b25e68d9@github.com>
References: <dm6o-XRNWecHjZeenCSRhAOEYI7L_mOOqfguvjlk_Bc=.cdb4e2e5-3500-48d5-8c05-749ff01f06f1@github.com>
 <Y-iTd9LtJ2nW9QZkNz1_xQ1kXToP8DcovFP-LAxrqXk=.8e9f7b28-fa77-4d27-a2c7-36a429a2f3ae@github.com>
 <mywKv4OJEmbTf_Y4mc5bMAv2sPplyFz3TwXmal12bG4=.5afa10a6-34ad-41f0-85ef-dc75b25e68d9@github.com>
Message-ID: <PYu_WF9ziMYXOY32DOhXjxjvh60gfQJoug9Z7VuIoyQ=.ffbe1bc4-ae49-472b-9b13-4f2ed1a3514e@github.com>

On Tue, 20 May 2025 06:08:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Move intrinsic to be a subsection; just one most common function of the annotation
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>>  - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java
>>    
>>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>>  - Shorter first sentence
>>  - Updates, thanks to John
>>  - Refine validation and defensive copying
>>  - 8355223: Improve documentation on @IntrinsicCandidate
>
> src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 39:
> 
>> 37:  * <h2 id="intrinsification">Intrinsification</h2>
>> 38:  * The most frequently special treatment is intrinsification, which replaces a
>> 39:  * candidate method's body, bytecode or native, with handwritten platform
> 
> Is this sentence missing the word "code" after "native"? Should it have been:
> 
>> bytecode or native code, ...

This is referring to native method's bodies. I think "bytecode or native" is sufficient to summarize the executable method body in the Java Language/Virtual Machine Specification.

> src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 50:
> 
>> 48:  * For example, the bytecodes of a candidate method may be executed by lower
>> 49:  * compilation tiers of VM execution, while higher compilation tiers may replace
>> 50:  * the bytecodes with specialized assembly code and/or compiler IR.  Therefore,
> 
>> while higher compilation tiers may replace the bytecodes with specialized assembly code and/or compiler IR
> 
> Is there ever a case, where for a `@IntrinsicCandidate` method, the runtime will choose to execute the instrinsic for that method for a certain duration and then at a later point in time replace the intrinsic with compiler generated code? In other words, once the runtime executes the intrinsic implementation for a `@IntrinsicCandidate` method, will the method's implementation be switched to anything else during the lifetime of an application?

We cannot rule it out, but this sentence begins "for example" meaning this is just one scenario and is not exhaustive.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2101082191
PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2101080051

From duke at openjdk.org  Wed May 21 20:20:56 2025
From: duke at openjdk.org (Stefan Lobbenmeier)
Date: Wed, 21 May 2025 20:20:56 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v3]
In-Reply-To: <nl5VM69GxPhiAgntuOh9CIOWMxBDqso3Z7qMDBzappo=.829eff41-9fa2-4232-901a-2113646befd9@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <zkBr9MToIDhhJ-Y7pgPbNqumbE1YtA9dlHmnJUApP5k=.287f87b7-44f0-46de-a314-c44702f16a2f@github.com>
 <nl5VM69GxPhiAgntuOh9CIOWMxBDqso3Z7qMDBzappo=.829eff41-9fa2-4232-901a-2113646befd9@github.com>
Message-ID: <NssPdGDK0SiKZ-XJIAAS_qJzsaYdN4-Z0CyXGXLHDPo=.b0fc08a0-86a3-486c-a456-71f1cf717551@github.com>

On Wed, 21 May 2025 19:33:13 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   also use <package-dep-string> in other locations
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties line 298:
> 
>> 296: \  --linux-menu-group <menu-group-name>\n\
>> 297: \          Menu group this application is placed in\n\
>> 298: \  --linux-package-deps\n\
> 
> I am not familiar with this CLI option, but if it is "dependency list separated by comma and space", then it should be documented. Similar to `--add-modules`.
> 
> Also, why we need `space` as well?
> 
> For example:
> 
> \ --linux-package-deps <package-dep-list>\n\
> \ A comma (",") separated list of required packages or capabilities for the application\n\
> 
> 
> or if space is really needed:
> 
> \ --linux-package-deps <package-dep-list>\n\
> \ A comma and space (", ") separated list of required packages or capabilities for the application\n\

I mostly learned about this through trial and error. To me it seems it is just appended to the existing default dependency list, which is separated by space and comma. Haven?t tried omitting the space though and I am unsure where this is defined

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2101088895

From lancea at openjdk.org  Wed May 21 20:23:58 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 21 May 2025 20:23:58 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <n8AVnZgFi-yV_dQL5eYZziuYRjTbIlImqi9NIMXQR1E=.62a1b4e4-7007-4416-8c03-e214585cb0d1@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
 <n8AVnZgFi-yV_dQL5eYZziuYRjTbIlImqi9NIMXQR1E=.62a1b4e4-7007-4416-8c03-e214585cb0d1@github.com>
Message-ID: <LpPzYllXtGll6AEKQKoDBDbLswCKJR8rX399QEN_io0=.47f59052-f118-4638-8a45-b3b99846e897@github.com>

On Wed, 21 May 2025 16:42:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Mismatched order is considered invalid
>
> src/jdk.jartool/share/man/jar.md line 223:
> 
>> 221: As a jar archive is based on ZIP format, it is possible to create a jar archive using tools
>> 222: other than the `jar` command. The --validate option may be used to perform the following
>> 223: integrity checks against a jar archive:
> 
> Nit - "integrity checks against a JAR file:"

I think we have other inconsistencies that we can clean up at a later time in the help and man page for the jar tool in the usages of archive/file.

The man page description can use a further overhaul as we still reference applets.  So we can do this also as follow on work

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101097000

From asemenyuk at openjdk.org  Wed May 21 20:28:02 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 21 May 2025 20:28:02 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v3]
In-Reply-To: <NssPdGDK0SiKZ-XJIAAS_qJzsaYdN4-Z0CyXGXLHDPo=.b0fc08a0-86a3-486c-a456-71f1cf717551@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <zkBr9MToIDhhJ-Y7pgPbNqumbE1YtA9dlHmnJUApP5k=.287f87b7-44f0-46de-a314-c44702f16a2f@github.com>
 <nl5VM69GxPhiAgntuOh9CIOWMxBDqso3Z7qMDBzappo=.829eff41-9fa2-4232-901a-2113646befd9@github.com>
 <NssPdGDK0SiKZ-XJIAAS_qJzsaYdN4-Z0CyXGXLHDPo=.b0fc08a0-86a3-486c-a456-71f1cf717551@github.com>
Message-ID: <PWU6uMNf9HCiHDb9ahKMZOw2L10D5qsKl9GqU9qImxg=.bf54c74c-fdce-47f2-8404-804f9f428093@github.com>

On Wed, 21 May 2025 20:17:45 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties line 298:
>> 
>>> 296: \  --linux-menu-group <menu-group-name>\n\
>>> 297: \          Menu group this application is placed in\n\
>>> 298: \  --linux-package-deps\n\
>> 
>> I am not familiar with this CLI option, but if it is "dependency list separated by comma and space", then it should be documented. Similar to `--add-modules`.
>> 
>> Also, why we need `space` as well?
>> 
>> For example:
>> 
>> \ --linux-package-deps <package-dep-list>\n\
>> \ A comma (",") separated list of required packages or capabilities for the application\n\
>> 
>> 
>> or if space is really needed:
>> 
>> \ --linux-package-deps <package-dep-list>\n\
>> \ A comma and space (", ") separated list of required packages or capabilities for the application\n\
>
> I mostly learned about this through trial and error. To me it seems it is just appended to the existing default dependency list, which is separated by space and comma. Haven?t tried omitting the space though and I am unsure where this is defined

I assume "dependency list separated by comma and space" is a quote from the PR description. I understand that this is how users interpret the value of this parameter, but for jpackage this is a pass-through option. It can be any string. And it is documented accordingly:

Required packages or capabilities for the application

It doesn't say anything about the value format because it is irrelevant for jpackage.  Probably this is an overly vague description, and we can add details that the value of this parameter will be passed verbatim to rpmbuild or dpkg commands. But this is not what this PR is about.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2101102106

From mseledtsov at openjdk.org  Wed May 21 20:31:53 2025
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Wed, 21 May 2025 20:31:53 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v6]
In-Reply-To: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com>
Message-ID: <-rGf3Cfj34SX1QlPIp1vyVRWGc67aFxFmbAqNC2iMyo=.d6eaa386-b98f-45e8-8035-94b5cf5f159a@github.com>

On Wed, 21 May 2025 06:54:37 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Thanks for the updates. Changes look good to me.

-------------

Marked as reviewed by mseledtsov (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24948#pullrequestreview-2859031087

From jlu at openjdk.org  Wed May 21 20:41:43 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 21 May 2025 20:41:43 GMT
Subject: RFR: 8357275: Locale.Builder.setLanguageTag should mention
 conversions made on language tag [v4]
In-Reply-To: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
Message-ID: <LH9qT9TNFE_IvRsRhE7az6ilAj_RC4j5SPbmZk-jnRI=.18c87588-a90e-4a75-b9c7-ac29df858fbe@github.com>

> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  CSR review - clarify that 3 extlang subtags is not a JDK specific condition

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25309/files
  - new: https://git.openjdk.org/jdk/pull/25309/files/62714a26..1ee830e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25309&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25309&range=02-03

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25309.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25309/head:pull/25309

PR: https://git.openjdk.org/jdk/pull/25309

From ethan at mccue.dev  Wed May 21 20:42:04 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Wed, 21 May 2025 16:42:04 -0400
Subject: Towards a JSON API for the JDK
In-Reply-To: <0e31ed85-25e7-44aa-903c-ceae80272c60@oracle.com>
References: <26C687E8-EC55-45A7-8A6B-4A5839E68F83@oracle.com>
 <ef42a778-31a7-43da-b814-c584e9e90b92@oracle.com>
 <A7867680-E127-43E8-BB03-8539A86A9ADC@oracle.com>
 <0e31ed85-25e7-44aa-903c-ceae80272c60@oracle.com>
Message-ID: <CA+NR86idU_a3OcywapK14FNN8BTNFxiuxQmDBEepJ_7bvF5TwQ@mail.gmail.com>

I think what has been proposed so far is powerful enough to perform that
task *if* there is an intermediate object in the mix.

if (
    // Assuming a dual pattern for JsonString.of and the SAP
    // strategy outlined in the doc
    json instanceof index(0, JsonString::of).decode(var firstName)
) {

}

On Wed, May 21, 2025 at 1:26?PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
> On 21/05/2025 18:06, Paul Sandoz wrote:
>
> It was a design choice to be consistent with each json value having an
> X, accepting X in on construction and producing X out (notionally) on
> deconstruction, which leans into pattern matching. Definitely pros/cons
> to that e.g., we could instead make JonObject implement Map, or do as
> you suggest [*], both of which adjust how one reasons about the X in and
>  X out.
>
> I agree with this. When I wrote, I thought that it might be possible to
> address some of these use cases using instance pattern declaration on the
> array class (e.g. having an instance pattern that extracts the i-th element
> of a JSONArray) -- but the instance pattern proposals we have discussed so
> far [1] are not powerful enough to model that use case.
>
> Maurizio
>
> [1] -
> https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250521/7e3cb726/attachment.htm>

From almatvee at openjdk.org  Wed May 21 20:54:54 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 May 2025 20:54:54 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v3]
In-Reply-To: <zkBr9MToIDhhJ-Y7pgPbNqumbE1YtA9dlHmnJUApP5k=.287f87b7-44f0-46de-a314-c44702f16a2f@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <zkBr9MToIDhhJ-Y7pgPbNqumbE1YtA9dlHmnJUApP5k=.287f87b7-44f0-46de-a314-c44702f16a2f@github.com>
Message-ID: <DQXva1P2kebCOQgybJccOGLgbyAwhCHDwo5o_Sec0BE=.bfd5ba3d-877b-47c0-83f7-02dbbcc82547@github.com>

On Wed, 21 May 2025 12:41:24 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

>> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space
>> 
>> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372
>
> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   also use <package-dep-string> in other locations

src/jdk.jpackage/share/man/jpackage.md line 426:

> 424: :   Menu group this application is placed in
> 425: 
> 426: <a id="option-linux-package-deps">`--linux-package-deps *package-dep-string*`</a>

Should it be "`--linux-package-deps *package-dep-string*`" -> "`--linux-package-deps` *package-dep-string*" similar to other options like `--linux-menu-group`. "``" around option only.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2101143417

From vyazici at openjdk.org  Wed May 21 21:02:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 21 May 2025 21:02:04 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
Message-ID: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>

There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.

### Fixing strategy

* Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
* Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
* Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.

@naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.

### Scanning strategy

The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:


# Perl is used for multi-line matching
find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
git grep -H 'FileDescriptor.in' "*.java"


All calls to `InputStreamReader::new` and `Scanner::new` are checked too.

### Problems encountered

1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:

    ```
    DOMImplementationRegistry 
    InputRC 
    ListingErrorHandler 
    PandocFilter 
    ```
2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

-------------

Commit messages:
 - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations

Changes: https://git.openjdk.org/jdk/pull/25368/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25368&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356893
  Stats: 244 lines in 58 files changed: 111 ins; 20 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/25368.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25368/head:pull/25368

PR: https://git.openjdk.org/jdk/pull/25368

From rriggs at openjdk.org  Wed May 21 21:08:01 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 May 2025 21:08:01 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v25]
In-Reply-To: <8EmX-PrYq9uwwuFk74NJbqEDmhpS5DOZjnUeciR7nvw=.0f750da6-8002-4345-b5a3-f1c3faf8237f@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <8EmX-PrYq9uwwuFk74NJbqEDmhpS5DOZjnUeciR7nvw=.0f750da6-8002-4345-b5a3-f1c3faf8237f@github.com>
Message-ID: <cothgtpejBT251OmYvOUGkocKBo6X2YayOimGcG4XVY=.2ace7b39-2320-4f56-a162-abd83dfb2b7d@github.com>

On Wed, 21 May 2025 19:18:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 29 additional commits since the last revision:
> 
>  - 8354724: Update API notes
>  - Merge
>  - 8354724: Revert previous commit and remove first comma in the change
>  - 8354724: Improve verbiage about I/O errors
>  - 8354724: Replace getChars in previous commit with subSequence
>  - 8354724: Improve readAllAsString method of Reader returned by Reader.of
>  - 8354724: Change readAllCharsAsString as suggested; move test to proper location
>  - 8354724: "stream" -> "reader"
>  - 8354724: Attempt to further improve verbiage
>  - Merge
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/b2ecf232...f9c732eb

Looks good as a straightforward convenience for getting lines or a string from a Reader.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24728#pullrequestreview-2859115874

From jlu at openjdk.org  Wed May 21 21:24:11 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 21 May 2025 21:24:11 GMT
Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable
Message-ID: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>

_sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/25371/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25371&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357281
  Stats: 180 lines in 3 files changed: 15 ins; 69 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/25371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25371/head:pull/25371

PR: https://git.openjdk.org/jdk/pull/25371

From liach at openjdk.org  Wed May 21 21:31:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 May 2025 21:31:16 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v7]
In-Reply-To: <dm6o-XRNWecHjZeenCSRhAOEYI7L_mOOqfguvjlk_Bc=.cdb4e2e5-3500-48d5-8c05-749ff01f06f1@github.com>
References: <dm6o-XRNWecHjZeenCSRhAOEYI7L_mOOqfguvjlk_Bc=.cdb4e2e5-3500-48d5-8c05-749ff01f06f1@github.com>
Message-ID: <vfDsc33Hcmqn4buhdw7ZV-jVSMPUkrkNOcCTdkEulCU=.74cb83d5-f2d4-4bc3-96f6-e245ee7f3842@github.com>

> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - More review updates
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
 - Move intrinsic to be a subsection; just one most common function of the annotation
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
 - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java
   
   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
 - Shorter first sentence
 - Updates, thanks to John
 - Refine validation and defensive copying
 - 8355223: Improve documentation on @IntrinsicCandidate

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24777/files
  - new: https://git.openjdk.org/jdk/pull/24777/files/317dd27a..a312d92b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24777&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24777&range=05-06

  Stats: 45626 lines in 1611 files changed: 26514 ins; 10851 del; 8261 mod
  Patch: https://git.openjdk.org/jdk/pull/24777.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24777/head:pull/24777

PR: https://git.openjdk.org/jdk/pull/24777

From liach at openjdk.org  Wed May 21 21:31:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 May 2025 21:31:16 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6]
In-Reply-To: <qgSvQFi40TedqSizh9VzWzdOkgl1nYXuTIG4SJ2M5cU=.d90dbc0c-9a52-4acf-b4d5-c4733c7ecd60@github.com>
References: <dm6o-XRNWecHjZeenCSRhAOEYI7L_mOOqfguvjlk_Bc=.cdb4e2e5-3500-48d5-8c05-749ff01f06f1@github.com>
 <Y-iTd9LtJ2nW9QZkNz1_xQ1kXToP8DcovFP-LAxrqXk=.8e9f7b28-fa77-4d27-a2c7-36a429a2f3ae@github.com>
 <qgSvQFi40TedqSizh9VzWzdOkgl1nYXuTIG4SJ2M5cU=.d90dbc0c-9a52-4acf-b4d5-c4733c7ecd60@github.com>
Message-ID: <3iH45ZNknFrbSpG6duwRFvGzrbzEGxCY0EfCF1nd6SU=.11552086-a4a7-455a-8523-172f581618d7@github.com>

On Fri, 16 May 2025 19:45:16 GMT, John R Rose <jrose at openjdk.org> wrote:

> Or just: s/, unlike the other methods//

Removed mention of "the other methods".

> src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 90:
> 
>> 88:  * intrinsic.)  For example, the documentation can simply say that the result is
>> 89:  * undefined if a race happens.  However, race conditions must not lead to
>> 90:  * program failures or type safety breaches, as listed above.
> 
> Maybe add a teaching paragraph:
> 
>> Reasoning about such race conditions is difficult, but it is a necessary skill when working with intrinsics that can observe racing shared variables.  One example of a tolerable race is a repeated read of a shared reference.  This only works if the algorithm takes no action based on the first read, other than deciding to perform the second read; it must "forget what it saw" in the first read.  This is why the array-mismatch intrinsics can sometimes report a tentative search hit (maybe using vectorized code), which can then be confirmed (by scalar code) as the caller makes a fresh and independent observation. 
> 
> (This is done when the array mismatch logic performs NaN-folding.  I just noticed that the NaN-folding code in ArraysSupport is slightly incorrect with respect to races!)

I have appened this teaching paragraph also as a blockquote inlined note after this current paragraph.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2101197921
PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2101199974

From liach at openjdk.org  Wed May 21 21:31:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 May 2025 21:31:16 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6]
In-Reply-To: <PYu_WF9ziMYXOY32DOhXjxjvh60gfQJoug9Z7VuIoyQ=.ffbe1bc4-ae49-472b-9b13-4f2ed1a3514e@github.com>
References: <dm6o-XRNWecHjZeenCSRhAOEYI7L_mOOqfguvjlk_Bc=.cdb4e2e5-3500-48d5-8c05-749ff01f06f1@github.com>
 <Y-iTd9LtJ2nW9QZkNz1_xQ1kXToP8DcovFP-LAxrqXk=.8e9f7b28-fa77-4d27-a2c7-36a429a2f3ae@github.com>
 <mywKv4OJEmbTf_Y4mc5bMAv2sPplyFz3TwXmal12bG4=.5afa10a6-34ad-41f0-85ef-dc75b25e68d9@github.com>
 <PYu_WF9ziMYXOY32DOhXjxjvh60gfQJoug9Z7VuIoyQ=.ffbe1bc4-ae49-472b-9b13-4f2ed1a3514e@github.com>
Message-ID: <wm8XZ1qvDNJSHULphiGym8ObnIdr16-RbuC0gvdMBf4=.dd5b61c6-2720-4712-8395-70e9e5106bd5@github.com>

On Wed, 21 May 2025 20:11:39 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 50:
>> 
>>> 48:  * For example, the bytecodes of a candidate method may be executed by lower
>>> 49:  * compilation tiers of VM execution, while higher compilation tiers may replace
>>> 50:  * the bytecodes with specialized assembly code and/or compiler IR.  Therefore,
>> 
>>> while higher compilation tiers may replace the bytecodes with specialized assembly code and/or compiler IR
>> 
>> Is there ever a case, where for a `@IntrinsicCandidate` method, the runtime will choose to execute the instrinsic for that method for a certain duration and then at a later point in time replace the intrinsic with compiler generated code? In other words, once the runtime executes the intrinsic implementation for a `@IntrinsicCandidate` method, will the method's implementation be switched to anything else during the lifetime of an application?
>
> We cannot rule it out, but this sentence begins "for example" meaning this is just one scenario and is not exhaustive.

To address your concern, I have reworded:

 * During execution, intrinsification may happen and may be rolled back at any
 * moment; this loading and unloading process may happen zero to many times.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2101198872

From rriggs at openjdk.org  Wed May 21 21:33:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 May 2025 21:33:56 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6]
In-Reply-To: <3iH45ZNknFrbSpG6duwRFvGzrbzEGxCY0EfCF1nd6SU=.11552086-a4a7-455a-8523-172f581618d7@github.com>
References: <dm6o-XRNWecHjZeenCSRhAOEYI7L_mOOqfguvjlk_Bc=.cdb4e2e5-3500-48d5-8c05-749ff01f06f1@github.com>
 <Y-iTd9LtJ2nW9QZkNz1_xQ1kXToP8DcovFP-LAxrqXk=.8e9f7b28-fa77-4d27-a2c7-36a429a2f3ae@github.com>
 <qgSvQFi40TedqSizh9VzWzdOkgl1nYXuTIG4SJ2M5cU=.d90dbc0c-9a52-4acf-b4d5-c4733c7ecd60@github.com>
 <3iH45ZNknFrbSpG6duwRFvGzrbzEGxCY0EfCF1nd6SU=.11552086-a4a7-455a-8523-172f581618d7@github.com>
Message-ID: <kQ33w7X3P7qH1RVlLkCoIt4DRBsEocPYFv0qi9-IHOo=.0a117036-499f-44a2-b3f2-645ccf77b913@github.com>

On Wed, 21 May 2025 21:28:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 90:
>> 
>>> 88:  * intrinsic.)  For example, the documentation can simply say that the result is
>>> 89:  * undefined if a race happens.  However, race conditions must not lead to
>>> 90:  * program failures or type safety breaches, as listed above.
>> 
>> Maybe add a teaching paragraph:
>> 
>>> Reasoning about such race conditions is difficult, but it is a necessary skill when working with intrinsics that can observe racing shared variables.  One example of a tolerable race is a repeated read of a shared reference.  This only works if the algorithm takes no action based on the first read, other than deciding to perform the second read; it must "forget what it saw" in the first read.  This is why the array-mismatch intrinsics can sometimes report a tentative search hit (maybe using vectorized code), which can then be confirmed (by scalar code) as the caller makes a fresh and independent observation. 
>> 
>> (This is done when the array mismatch logic performs NaN-folding.  I just noticed that the NaN-folding code in ArraysSupport is slightly incorrect with respect to races!)
>
> I have appened this teaching paragraph also as a blockquote inlined note after this current paragraph.

This unnecessary detail goes will beyond the description of the annotation and is more of a design doc for VM implementation so this is not really the best place for it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2101204688

From rriggs at openjdk.org  Wed May 21 21:39:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 May 2025 21:39:53 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

There too many changes in too many different areas to be in a single PR.
Please break it down by review areas.  Client, core libs, tools, etc.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25368#pullrequestreview-2859185030

From liach at openjdk.org  Wed May 21 21:42:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 May 2025 21:42:04 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v25]
In-Reply-To: <8EmX-PrYq9uwwuFk74NJbqEDmhpS5DOZjnUeciR7nvw=.0f750da6-8002-4345-b5a3-f1c3faf8237f@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <8EmX-PrYq9uwwuFk74NJbqEDmhpS5DOZjnUeciR7nvw=.0f750da6-8002-4345-b5a3-f1c3faf8237f@github.com>
Message-ID: <4pPFoeCY_nyCbqACGpn_RgSM7js2KzuXgVod7PgIyR0=.a5ce2321-9ad4-4738-9408-ca6cc4fc5dd9@github.com>

On Wed, 21 May 2025 19:18:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 29 additional commits since the last revision:
> 
>  - 8354724: Update API notes
>  - Merge
>  - 8354724: Revert previous commit and remove first comma in the change
>  - 8354724: Improve verbiage about I/O errors
>  - 8354724: Replace getChars in previous commit with subSequence
>  - 8354724: Improve readAllAsString method of Reader returned by Reader.of
>  - 8354724: Change readAllCharsAsString as suggested; move test to proper location
>  - 8354724: "stream" -> "reader"
>  - 8354724: Attempt to further improve verbiage
>  - Merge
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/c5a1d189...f9c732eb

src/java.base/share/classes/java/io/Reader.java line 460:

> 458:      */
> 459:     public List<String> readAllLines() throws IOException {
> 460:         return readAllCharsAsString().lines().toList();

I recommend an implementation comment that we intentionally avoid delegating to `readAllAsString`, which can be overridden by subclasses.  Otherwise, the purpose of `readAllCharsAsString` may not be immediately clear.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2101213305

From liach at openjdk.org  Wed May 21 21:43:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 May 2025 21:43:55 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6]
In-Reply-To: <kQ33w7X3P7qH1RVlLkCoIt4DRBsEocPYFv0qi9-IHOo=.0a117036-499f-44a2-b3f2-645ccf77b913@github.com>
References: <dm6o-XRNWecHjZeenCSRhAOEYI7L_mOOqfguvjlk_Bc=.cdb4e2e5-3500-48d5-8c05-749ff01f06f1@github.com>
 <Y-iTd9LtJ2nW9QZkNz1_xQ1kXToP8DcovFP-LAxrqXk=.8e9f7b28-fa77-4d27-a2c7-36a429a2f3ae@github.com>
 <qgSvQFi40TedqSizh9VzWzdOkgl1nYXuTIG4SJ2M5cU=.d90dbc0c-9a52-4acf-b4d5-c4733c7ecd60@github.com>
 <3iH45ZNknFrbSpG6duwRFvGzrbzEGxCY0EfCF1nd6SU=.11552086-a4a7-455a-8523-172f581618d7@github.com>
 <kQ33w7X3P7qH1RVlLkCoIt4DRBsEocPYFv0qi9-IHOo=.0a117036-499f-44a2-b3f2-645ccf77b913@github.com>
Message-ID: <I3sMGjfBk4CBek_gfin8gHNktQKgRsKsXvNzi1eJ_rI=.aaece057-6750-4d90-8260-f0ad17a4bc7f@github.com>

On Wed, 21 May 2025 21:31:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I have appened this teaching paragraph also as a blockquote inlined note after this current paragraph.
>
> This unnecessary detail goes will beyond the description of the annotation and is more of a design doc for VM implementation so this is not really the best place for it.

This is a general note for intrinsic APIs - in rendering, this is a blockquote, so it is nested as if it is an inlined footnote. It does not impact the readability of the main body.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2101216837

From naoto at openjdk.org  Wed May 21 22:18:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 May 2025 22:18:51 GMT
Subject: RFR: 8347050: Console.readLine() drops '\' when reading through
 JLine [v2]
In-Reply-To: <UwoOmfmFLX4yoa_KFHaRf9ox5oPzEROA_g_3RQLrIkw=.6b6573c1-05a4-4235-a7e1-fb57fc9605fa@github.com>
References: <CrRA1pKBHMYHwGSTVCA4j_TTDsl56xMZ4jG_cd-KBhg=.97ee6b8b-06db-4831-ab6e-a15242df941b@github.com>
 <UwoOmfmFLX4yoa_KFHaRf9ox5oPzEROA_g_3RQLrIkw=.6b6573c1-05a4-4235-a7e1-fb57fc9605fa@github.com>
Message-ID: <q8GmAfX4zAXmQ3rJVrOt5zfyxSh3kymt_84xnwXTEzQ=.107d9a11-f434-4d0e-ac65-4a08bb0305cf@github.com>

On Wed, 21 May 2025 07:23:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JLine can do history expansion, and interpret escapes, when returning a value. That is not desirable when using JLine as a backend for Console.readLine().
>> 
>> This PR proposes to disable the history expansion.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing test on Windows.

Looks fine

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25326#pullrequestreview-2859258534

From lancea at openjdk.org  Wed May 21 22:20:59 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 21 May 2025 22:20:59 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v11]
In-Reply-To: <qlaFI_zmptAcRgWznwJpk54yR6dOdtMlyh8Bkb0NRew=.b7c70e00-9c60-44de-9c98-87c0d2e1f235@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <qlaFI_zmptAcRgWznwJpk54yR6dOdtMlyh8Bkb0NRew=.b7c70e00-9c60-44de-9c98-87c0d2e1f235@github.com>
Message-ID: <De7YzSLy7QZecdx2LtzZZdQTJHzTqluXz0UjAM5zi8I=.6a1e973d-2c7d-4c50-8d8a-c0db7dc60e7a@github.com>

On Wed, 21 May 2025 10:43:12 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweaking exact wording.

src/jdk.zipfs/share/classes/module-info.java line 279:

> 277:  *       <ul>
> 278:  *           <li>
> 279:  *               If no value is set, the file system is created <em>read-write</em>

created -> created as

I think it might be better as 

> If no value is specified, the file system is created as ....

src/jdk.zipfs/share/classes/module-info.java line 289:

> 287:  *               <em>read-only</em> file system requires the underlying ZIP file to
> 288:  *               already exist.
> 289:  *               Specifying {@code create} as {@code true} and {@code accessMode} as

> Specifying {@code  create} 

You should make this clear that it is the 'create property '

src/jdk.zipfs/share/classes/module-info.java line 291:

> 289:  *               Specifying {@code create} as {@code true} and {@code accessMode} as
> 290:  *               {@code readOnly} will cause an {@code IllegalArgumentException}
> 291:  *               to be thrown when creating the ZIP file system.

I 'think' this should be "cause a" or "result in a" for the usages  of "cause an" based on how the phrase is used

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2101259671
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2101262569
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2101257012

From liach at openjdk.org  Wed May 21 22:33:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 May 2025 22:33:55 GMT
Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable
In-Reply-To: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
Message-ID: <Idp1VRv0w_3lkXRAmRKZBrjv2kxgD0RmoJ4bs_Buwdk=.45f64a22-40da-4285-a689-9de0092d7e98@github.com>

On Wed, 21 May 2025 21:19:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.

The record migration is sensible: this class is purely used as a data carrier. Its object methods of hashCode and equals were unused so we can migrate safely, and the public constructor is okay too.

One comment is about the `List<String>` returning methods: currently, you are doing:

return list.isEmpty() ? list : Collections.unmodifiableList(list);

This code is error prone: if the list becomes immutable, the wrapper is redundant; if the list becomes mutable, the empty list can have new items added, and is not safe.

Since this is only accessed by trusted code (and we don't do dangerous thingss like `contains(null)`, we have much freedom in refactoring - we might just use the raw array list because users don't change them, and add alerts on record header about the mutability. Or wrap those lists with unmodifiableList upon parsing, or copy with List.copyOf, etc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25371#issuecomment-2899412146

From swen at openjdk.org  Wed May 21 22:41:56 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 21 May 2025 22:41:56 GMT
Subject: Integrated: 8357063: Document preconditions for DecimalDigits methods
In-Reply-To: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
References: <t-W1j1Dc0b9fAl6_6UZOD0zGnpue66KDcZi2dAcx5GA=.50246074-ded6-4b9c-8ebc-23d6f31259c4@github.com>
Message-ID: <Y2rKTBIfPw2m5nr58glrqr-OS8xPXcX-XPC5AIr6XUE=.ada80473-f0e0-48a0-90e1-b05214cd69ed@github.com>

On Thu, 15 May 2025 06:24:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to PR #24982 
> Document preconditions on certain DecimalDigits methods that use operations either unsafe and/or without range checks.

This pull request has now been integrated.

Changeset: 07871cd7
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07871cd78aa7ee35762234112dfe46fe3ebc9a57
Stats:     74 lines in 7 files changed: 16 ins; 5 del; 53 mod

8357063: Document preconditions for DecimalDigits methods

Reviewed-by: vyazici, liach, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/25246

From duke at openjdk.org  Wed May 21 23:30:18 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 21 May 2025 23:30:18 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v12]
In-Reply-To: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
Message-ID: <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  More tweaking...

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/ab15123a..92355287

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=10-11

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

PR: https://git.openjdk.org/jdk/pull/25178

From swen at openjdk.org  Thu May 22 00:57:06 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 22 May 2025 00:57:06 GMT
Subject: RFR: 8349176: Speed up Integer/Long.toString via
 allocateUninitializedArray [v5]
In-Reply-To: <u9INrX9ZnlI8Hs0gC1hnE-oYiHLrnL93Q5hF1yzmJgM=.8b5bb878-27f0-4c21-a1bb-82ce65634b81@github.com>
References: <u9INrX9ZnlI8Hs0gC1hnE-oYiHLrnL93Q5hF1yzmJgM=.8b5bb878-27f0-4c21-a1bb-82ce65634b81@github.com>
Message-ID: <RIXAT24aOCc42qRpox9BVR_2pv4Jt4wCAB1GpucMNdU=.4416040a-b6ce-48ba-a014-e00215ee8042@github.com>

> 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 with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge remote-tracking branch 'upstream/master' into allocate_un_init_202501
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/Integer.java
   #	src/java.base/share/classes/java/lang/Long.java
 - simplify code
 - use Unsafe::allocateUninitializedArray
 - Merge remote-tracking branch 'upstream/master' into allocate_un_init_202501
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/Integer.java
   #	src/java.base/share/classes/java/lang/Long.java
 - use StringConcatHelper.newArray
 - simplify
 - use Unsafe.allocateUninitializedArray
 - revert StringConcatHelper newArray change
 - copyright
 - remove duplicate check
 - ... and 1 more: https://git.openjdk.org/jdk/compare/b685ea54...85e437a8

-------------

Changes: https://git.openjdk.org/jdk/pull/23353/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23353&range=04
  Stats: 18 lines in 2 files changed: 8 ins; 6 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 naoto at openjdk.org  Thu May 22 01:18:54 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 May 2025 01:18:54 GMT
Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable
In-Reply-To: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
Message-ID: <3wbh2CRyYKYPfjMrlaJUB8fiaH9FSVFusKFnhJzLBys=.3716f5f6-c196-4887-bf39-1f526d9cf8e3@github.com>

On Wed, 21 May 2025 21:19:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.

Nice refactoring. Couple of nits follow

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 53:

> 51:     public static final String PRIVUSE_VARIANT_PREFIX = "lvariant";
> 52:     private static final String EMPTY_TAG = "";
> 53:     private static final List<String> EMPTY_TAGS = Collections.emptyList();

It would be clearer to rename "TAG(S)" to "SUBTAG(S)"

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 191:

> 189:         String region = EMPTY_TAG;
> 190:         List<String> variants = EMPTY_TAGS;
> 191:         List<String> extensions = EMPTY_TAGS;

These assignments can be moved for the case of `language.isEmpty()`

-------------

PR Review: https://git.openjdk.org/jdk/pull/25371#pullrequestreview-2859485182
PR Review Comment: https://git.openjdk.org/jdk/pull/25371#discussion_r2101431166
PR Review Comment: https://git.openjdk.org/jdk/pull/25371#discussion_r2101426074

From swen at openjdk.org  Thu May 22 01:29:05 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 22 May 2025 01:29:05 GMT
Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable
In-Reply-To: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
Message-ID: <QAS4cCQ1inr_O7M13lOA_aeDB2pXo7MbNy-uVmDi5LE=.018e7894-987a-41ee-8f7e-a8f7517c9d26@github.com>

On Wed, 21 May 2025 21:19:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 458:

> 456:                 baseLanguage = "id";
> 457:             }
> 458:             language = baseLanguage;

Suggestion:

            language = switch(baseLanguage) {
                case "iw" -> "he";
                case "ji" -> "yi";
                case "in" -> "id";
                default   -> baseLanguage;
            };

use switch expression

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25371#discussion_r2101446785

From henryjen at openjdk.org  Thu May 22 01:29:12 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 22 May 2025 01:29:12 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>

> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Validator to take a file, use term JAR file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/b0df54d2..52af70aa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=10-11

  Stats: 27 lines in 3 files changed: 7 ins; 3 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/24430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430

PR: https://git.openjdk.org/jdk/pull/24430

From henryjen at openjdk.org  Thu May 22 01:45:00 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 22 May 2025 01:45:00 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <6F_2GSLLN0ajSO73JcYDd0wXvTthdFjgfxXDQ8XndYU=.c3ad4280-fcc3-4eaf-a658-2d5212009260@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
 <6F_2GSLLN0ajSO73JcYDd0wXvTthdFjgfxXDQ8XndYU=.c3ad4280-fcc3-4eaf-a658-2d5212009260@github.com>
Message-ID: <ISsFz3sMJMDu3sh5CfJWicigVorVDLsLpDIY8adVnq4=.804db444-277b-485b-981d-c154c15d07a3@github.com>

On Wed, 21 May 2025 16:53:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Mismatched order is considered invalid
>
> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 454:
> 
>> 452:                     new FileInputStream(file)))) {
>> 453: 
>> 454:             return Validator.validate(this, zf, zis);
> 
> I think it might be better to change the `Validator.validate()` method to accept a `java.nio.file.Path` instead of accepting a ZipFile instance and a ZipInputStream instance. In its current form it feels odd that the call site (like here) needs to pass ZipFile and ZipInputStream to a validator. The checks using a ZipFile and a ZipInputStream for the same file is more an internal detail of the validator, so it would be good to let it construct those instances internally as appropriate.
> 
> The `Validator` class itself belongs to an internal package of this tool, so changing the signature of this method to accept a `Path` wouldn't be a problem.
> 
> It also looks like the Validator uses this `Main` instance merely for error reporting. So maybe in a future update we could remove the need to pass along this `Main` instance to the validator. That one doesn't have to be done in this PR.

I keep File instead of Path to avoid unnecessary changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101460623

From henryjen at openjdk.org  Thu May 22 01:45:01 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 22 May 2025 01:45:01 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <LpPzYllXtGll6AEKQKoDBDbLswCKJR8rX399QEN_io0=.47f59052-f118-4638-8a45-b3b99846e897@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
 <n8AVnZgFi-yV_dQL5eYZziuYRjTbIlImqi9NIMXQR1E=.62a1b4e4-7007-4416-8c03-e214585cb0d1@github.com>
 <LpPzYllXtGll6AEKQKoDBDbLswCKJR8rX399QEN_io0=.47f59052-f118-4638-8a45-b3b99846e897@github.com>
Message-ID: <XrVT-vsFLSEx-ksEcz3Ss5km3jdoGiltBwQLhMVwHPg=.f42a0192-9194-45c8-bb1f-7bbc8fa70775@github.com>

On Wed, 21 May 2025 20:21:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/jdk.jartool/share/man/jar.md line 223:
>> 
>>> 221: As a jar archive is based on ZIP format, it is possible to create a jar archive using tools
>>> 222: other than the `jar` command. The --validate option may be used to perform the following
>>> 223: integrity checks against a jar archive:
>> 
>> Nit - "integrity checks against a JAR file:"
>
> I think we have other inconsistencies that we can clean up at a later time in the help and man page for the jar tool in the usages of archive/file.
> 
> The man page description can use a further overhaul as we still reference applets.  So we can do this also as follow on work

I changed references in the new content and leave the retrofit to future works.

>> src/jdk.jartool/share/man/jar.md line 235:
>> 
>>> 233:   versions.
>>> 234: 
>>> 235: The jar tool returns a status code of 0 if there were no integrity issues encountered, otherwise
>> 
>> Nit - we should call it exit code instead of status code, both for 0 and non-zero exit codes.
>
>> Nit - we should call it exit code instead of status code, both for 0 and non-zero exit codes.
> 
> I don't have a preference but unix/MacOS commands vary:
> 
> -  ls command: The ls utility exits?0 on success, and?>0 if an error occurs.
> - grep command: 
> 
>> The grep utility exits with one of the following values:
> 
>      0     One or more lines were selected.
>      1     No lines were selected.
>      >1    An error occurred.
> 
> - unzip command:
> 
>> The exit status (or error level) approximates the exit codes defined by PKWARE and takes on the
>        following values, except under VMS:
> 
>               0      normal; no errors or warnings detected.
> 
>               1      one or more warning errors were encountered, but processing completed successfully
>                      anyway.  This includes zipfiles where one or more files was skipped due to unsupported
>                      compression method or encryption with an unknown password.
> 
>               2      a generic error in the zipfile format was detected.  Processing may have completed
>                      successfully anyway; some broken zipfiles created by other archivers have simple work-
>                      arounds.
>               3      a severe error in the zipfile format was detected.  Processing probably failed
>                      immediately.
> 
>               4      unzip was unable to allocate memory for one or more buffers during program
>                      initialization.
> 
>               5      unzip was unable to allocate memory or unable to obtain a tty to read the decryption
>                      password(s).
> 
>               6      unzip was unable to allocate memory during decompression to disk.
> 
>               7      unzip was unable to allocate memory during in-memory decompression.
> 
>               8      [currently not used]
> 
>               9      the specified zipfiles were not found.
> 
>               10     invalid options were specified on the command line.
> 
>               11     no matching files were found.
> 
>               50     the disk is (or was) full during extraction.
> 
>               51     the end of the ZIP archive was encountered prematurely.
> 
>               80     the user aborted unzip prematurely with control-C (or similar)
> 
>               81     testing or extraction of one or more files failed due to unsupported compression methods
>                      or unsupported decryption.
> 
>               82     no files were found due to bad decryption password(s).  (If even one file is successfully
>       ...

I use exit code, but still keep non-zero instead of > 0. Leave that to future work if we want to have more specific value for exit code for different situations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101457168
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101458911

From lancea at openjdk.org  Thu May 22 01:48:54 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 22 May 2025 01:48:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <XrVT-vsFLSEx-ksEcz3Ss5km3jdoGiltBwQLhMVwHPg=.f42a0192-9194-45c8-bb1f-7bbc8fa70775@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
 <n8AVnZgFi-yV_dQL5eYZziuYRjTbIlImqi9NIMXQR1E=.62a1b4e4-7007-4416-8c03-e214585cb0d1@github.com>
 <LpPzYllXtGll6AEKQKoDBDbLswCKJR8rX399QEN_io0=.47f59052-f118-4638-8a45-b3b99846e897@github.com>
 <XrVT-vsFLSEx-ksEcz3Ss5km3jdoGiltBwQLhMVwHPg=.f42a0192-9194-45c8-bb1f-7bbc8fa70775@github.com>
Message-ID: <Y6YssGqbUHJfl3FqvtPzcyYTW4_XTFrcOZPKkuxgkT4=.e6063750-748a-48f6-97cc-bddfdf3ab345@github.com>

On Thu, 22 May 2025 01:39:45 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>>> Nit - we should call it exit code instead of status code, both for 0 and non-zero exit codes.
>> 
>> I don't have a preference but unix/MacOS commands vary:
>> 
>> -  ls command: The ls utility exits?0 on success, and?>0 if an error occurs.
>> - grep command: 
>> 
>>> The grep utility exits with one of the following values:
>> 
>>      0     One or more lines were selected.
>>      1     No lines were selected.
>>      >1    An error occurred.
>> 
>> - unzip command:
>> 
>>> The exit status (or error level) approximates the exit codes defined by PKWARE and takes on the
>>        following values, except under VMS:
>> 
>>               0      normal; no errors or warnings detected.
>> 
>>               1      one or more warning errors were encountered, but processing completed successfully
>>                      anyway.  This includes zipfiles where one or more files was skipped due to unsupported
>>                      compression method or encryption with an unknown password.
>> 
>>               2      a generic error in the zipfile format was detected.  Processing may have completed
>>                      successfully anyway; some broken zipfiles created by other archivers have simple work-
>>                      arounds.
>>               3      a severe error in the zipfile format was detected.  Processing probably failed
>>                      immediately.
>> 
>>               4      unzip was unable to allocate memory for one or more buffers during program
>>                      initialization.
>> 
>>               5      unzip was unable to allocate memory or unable to obtain a tty to read the decryption
>>                      password(s).
>> 
>>               6      unzip was unable to allocate memory during decompression to disk.
>> 
>>               7      unzip was unable to allocate memory during in-memory decompression.
>> 
>>               8      [currently not used]
>> 
>>               9      the specified zipfiles were not found.
>> 
>>               10     invalid options were specified on the command line.
>> 
>>               11     no matching files were found.
>> 
>>               50     the disk is (or was) full during extraction.
>> 
>>               51     the end of the ZIP archive was encountered prematurely.
>> 
>>               80     the user aborted unzip prematurely with control-C (or similar)
>> 
>>               81     testing or extraction of one or more files failed due to unsupported compression methods
>>                      or unsupported decryption.
>> 
>>     ...
>
> I use exit code, but still keep non-zero instead of > 0. Leave that to future work if we want to have more specific value for exit code for different situations.

Non-zero could also mean negative which we currently do not do nor do,I see that going forward as part of future additions to validate

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101463994

From duke at openjdk.org  Thu May 22 02:11:58 2025
From: duke at openjdk.org (He-Pin (kerr))
Date: Thu, 22 May 2025 02:11:58 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message
In-Reply-To: <3C_11D3AR_qG3ifDbWztlzhD8rZyultJEKh_89wWN1M=.5af79488-6978-4f80-a07e-b4c38139b390@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <AnrjLD7rJwg1dT8fNc5XMs8rqhSlLxIPNPk27zZtN7k=.34540e60-36c4-4c98-9a11-668fff434160@github.com>
 <3C_11D3AR_qG3ifDbWztlzhD8rZyultJEKh_89wWN1M=.5af79488-6978-4f80-a07e-b4c38139b390@github.com>
Message-ID: <7IXvN9Kkr1UqkczbU3DqFZK4aAnFPpysfEPoouqWdds=.fa401d16-3d5e-4d48-aec5-8a336afac317@github.com>

On Tue, 20 May 2025 10:11:03 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> It would be much nicer if you take this one:), we are on JDK 21 and want to have this in the next LTS.
>
> @He-Pin Just pinging you here, in case the notification from my most recent comments got lost in transit.

@viktorklang-ora @liach, I think we need a contribution guide that explains how to set up the work in the IDE, how to perform tests, etc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2899696140

From jpai at openjdk.org  Thu May 22 02:21:04 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 02:21:04 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance [v3]
In-Reply-To: <U5LJYS7yxDkt-d043HiYMoP2wOhCE7lX8Bg6zvQDbyA=.4e80780f-1f1c-4cd7-aab0-61a991cf0cbe@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
 <U5LJYS7yxDkt-d043HiYMoP2wOhCE7lX8Bg6zvQDbyA=.4e80780f-1f1c-4cd7-aab0-61a991cf0cbe@github.com>
Message-ID: <aCBIe8NiWcUc71cde_HZ7T8dEEujoOdzXoicwpGEQT0=.083899e6-79bb-4240-8e8a-233dcc5088b0@github.com>

On Sun, 20 Apr 2025 13:01:30 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

>> zipfs has a (undocumented) property "zipinfo-time" which was introduced in https://bugs.openjdk.org/browse/JDK-8150496 to help improve performance of the ZipFileSystem. When a ZipFileSystem is created with this property's value set to "false", then the implementation in ZipFileSystem, while constructing the entries from the ZIP file will skip reading the access time and the creation time of each ZIP entry from the entry's LOC header. This improves the performance of zipfs, since when reading the CEN, it no longer has to traverse to individual LOC headers to find the access time and creation time values of each entry.
>> 
>> Setting "zipinfo-time" = false, thus implies that the ZipFileAttributes.creationTime() and ZipFileAttributes.lastAccessTime() APIs may not return the right values when used against Path(s) corresponding to the ZIP entries in that FileSystem. Not all usages of zipfs require or use the creationTime()/lastAccessTime() APIs. Such usages can set "zipinfo-time" = false and benefit from improved performance.
>> 
>> com.sun.tools.javac.file.JavacFileManager$ArchiveContainer is one such place where when constructing the FileSystem, it could pass this property. This is especially useful since this part of the code in practice can be dealing with large number of jar files in the classpath and creating one zipfs FileSystem for each such JAR file.
>> 
>> It has been reported in the compiler-dev mailing list, that an experiment to set "zipinfo-time" = false in this part of the code has shown very noticeable performance improvements, especially on Windows, when dealing with large classpath. Details in the thread here https://mail.openjdk.org/pipermail/compiler-dev/2025-March/029529.html.
>
> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright and remove part of comment

Hello Jason, I'll just run this once in our CI today to make sure nothing fails against latest master. I'll add a comment here once that's complete and you can then integrate it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2899711012

From syan at openjdk.org  Thu May 22 03:44:57 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 22 May 2025 03:44:57 GMT
Subject: RFR: 8353124: java/lang/Thread/virtual/stress/Skynet.java#Z times
 out on macosx-x64-debug
In-Reply-To: <F4TigL343CD7V_qcvCrTLizAF4NiV3kgQQzv6avwSuw=.44197229-be1a-4369-91a4-1fda34d8478f@github.com>
References: <F4TigL343CD7V_qcvCrTLizAF4NiV3kgQQzv6avwSuw=.44197229-be1a-4369-91a4-1fda34d8478f@github.com>
Message-ID: <w60TaxVjKmsqFsOluYgJbJluFMFYZigN5UyIJpWxpVk=.486dac7f-1055-4cbb-9a62-bc04c659e267@github.com>

On Tue, 20 May 2025 15:25:52 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This is a simple test update which increases a timeout from 300s to 400 to account for slow mac os test machines.
> A repeat 50 test of :jdk_lang passes. I will run this a few more times before pushing, if the change is acceptable.
> 
> Thanks,
> Michael

Changes requested by syan (Committer).

test/jdk/java/lang/Thread/virtual/stress/Skynet.java line 32:

> 30:  */
> 31: /*
> 32:  * @test id=Z

Should we need update the copyright year

-------------

PR Review: https://git.openjdk.org/jdk/pull/25331#pullrequestreview-2859675980
PR Review Comment: https://git.openjdk.org/jdk/pull/25331#discussion_r2101559815

From duke at openjdk.org  Thu May 22 03:56:52 2025
From: duke at openjdk.org (duke)
Date: Thu, 22 May 2025 03:56:52 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v6]
In-Reply-To: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
 <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com>
Message-ID: <KnZO7hSV3Uqtq6IdwySQL3u9siX_8SMxA3_MvxMsI2Y=.c57d5aae-e0ca-493b-ad7d-d57018a735da@github.com>

On Wed, 21 May 2025 06:54:37 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

@pawanchawdhary1 
Your change (at version 5e1f9240b379356fb8d5e0db1587216d1cbeed0f) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2899823355

From alanb at openjdk.org  Thu May 22 05:54:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 May 2025 05:54:52 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <wrtUfsbfcWNXz5eMaykcIbLOPC5019cvCsig_cLn7L4=.bd0dab1a-ad1e-465c-852b-8fb66d81f401@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

javax.swing.text.DefaultEditorKit.read(InputStream ...)  is one example changed in the PR. If that is changed to special case System.in then it will require a spec change. It also means that `read(System.in)` will behave differently to say `new BufferedInputStream(System.in)`.  From a quick scan, I suspect changes that impact the APIs will need to dropped from the PR, maybe replaced with spec clarification to document the charset that is actually used. In the DefaultEditorKit.read example it might direct folks to the read(Reader ..) method so that code can control which charset to use.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2899998753

From jlahoda at openjdk.org  Thu May 22 06:01:57 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 22 May 2025 06:01:57 GMT
Subject: RFR: 8347050: Console.readLine() drops '\' when reading through
 JLine [v2]
In-Reply-To: <UwoOmfmFLX4yoa_KFHaRf9ox5oPzEROA_g_3RQLrIkw=.6b6573c1-05a4-4235-a7e1-fb57fc9605fa@github.com>
References: <CrRA1pKBHMYHwGSTVCA4j_TTDsl56xMZ4jG_cd-KBhg=.97ee6b8b-06db-4831-ab6e-a15242df941b@github.com>
 <UwoOmfmFLX4yoa_KFHaRf9ox5oPzEROA_g_3RQLrIkw=.6b6573c1-05a4-4235-a7e1-fb57fc9605fa@github.com>
Message-ID: <TNlyO937OLbSHascDrrs9L82a-iqgtYvi-hgJakJg20=.367725f1-35eb-43a5-92ce-c96c7a4e0cdf@github.com>

On Wed, 21 May 2025 07:23:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JLine can do history expansion, and interpret escapes, when returning a value. That is not desirable when using JLine as a backend for Console.readLine().
>> 
>> This PR proposes to disable the history expansion.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing test on Windows.

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25326#issuecomment-2900008739

From jlahoda at openjdk.org  Thu May 22 06:01:58 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 22 May 2025 06:01:58 GMT
Subject: Integrated: 8347050: Console.readLine() drops '\' when reading through
 JLine
In-Reply-To: <CrRA1pKBHMYHwGSTVCA4j_TTDsl56xMZ4jG_cd-KBhg=.97ee6b8b-06db-4831-ab6e-a15242df941b@github.com>
References: <CrRA1pKBHMYHwGSTVCA4j_TTDsl56xMZ4jG_cd-KBhg=.97ee6b8b-06db-4831-ab6e-a15242df941b@github.com>
Message-ID: <9Zsfwz2gsl592Z9ziQiiStxWdPf582vrXsSO1TBQVbI=.82f0c2e4-3fd6-4de4-bf56-94f4bdbad112@github.com>

On Tue, 20 May 2025 13:07:55 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JLine can do history expansion, and interpret escapes, when returning a value. That is not desirable when using JLine as a backend for Console.readLine().
> 
> This PR proposes to disable the history expansion.

This pull request has now been integrated.

Changeset: 061b5cc6
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/061b5cc6b9939e182f3b2063ad86d042e35f0a91
Stats:     19 lines in 2 files changed: 17 ins; 0 del; 2 mod

8347050: Console.readLine() drops '\' when reading through JLine

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/25326

From syan at openjdk.org  Thu May 22 06:19:55 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 22 May 2025 06:19:55 GMT
Subject: RFR: 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java
 test scenario to run as manual
In-Reply-To: <IMl8opuemVxRGiD46GfPuh0eZ1d6R86xkOdc3HIsT1I=.228f1873-ee56-4c22-919b-afd86dc8cc20@github.com>
References: <IMl8opuemVxRGiD46GfPuh0eZ1d6R86xkOdc3HIsT1I=.228f1873-ee56-4c22-919b-afd86dc8cc20@github.com>
Message-ID: <Ua0sTLOi-GKosv8u5z2aY1j8E56ZsW5GDsilAp9ciiA=.c138f2ba-baee-4403-8905-bec2868857f8@github.com>

On Wed, 21 May 2025 13:44:09 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual

Changes requested by syan (Committer).

test/jdk/java/foreign/TestMatrix.java line 38:

> 36:  * @build NativeTestHelper CallGeneratorHelper TestUpcallHighArity
> 37:  *
> 38:  * @run testng/othervm/native/manual

Should we update the copyright year to 2025.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25355#pullrequestreview-2859914726
PR Review Comment: https://git.openjdk.org/jdk/pull/25355#discussion_r2101720038

From jpai at openjdk.org  Thu May 22 06:50:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 06:50:54 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <fjXxuXGIvezZ5aoE-a_ex4EQimfGGVQq2IqoWaie1IA=.39eaa16e-f074-4993-b10e-8d6175159951@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
 <2PjV5qPpliR71q_2HQRBychDHCFCTM4Pbw4xZDAIb7M=.329d3adf-a82e-47d8-9bd8-aab1ca897c38@github.com>
 <fjXxuXGIvezZ5aoE-a_ex4EQimfGGVQq2IqoWaie1IA=.39eaa16e-f074-4993-b10e-8d6175159951@github.com>
Message-ID: <Vy414UoIgmiYePus1BZMzJuwnPaVootdf-_zKrm41PM=.7435135c-33ce-477c-a4db-05d287e8646d@github.com>

On Mon, 24 Mar 2025 22:33:56 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

>> Good catch, thanks! Ordinarily, I would say a test is required, but I can't think up a viable test to verify the effect of this change in a test, so we probably need to do it without a test.
>
>> Ordinarily, I would say a test is required, but I can't think up a viable test to verify the effect of this change in a test, so we probably need to do it without a test.
> 
> I tested this change [externally](https://github.com/retronym/jarcache/blob/ba7f5cdd5f7db976a6568855a0d517f52a1404bf/demo/src/test/scala/demo/JarCacheAgentTest.java#L75-L76) with [JFRUnit](https://github.com/moditect/jfrunit). 
> 
> If preferred, I could create a `jtreg` test along similar lines. It would use the JFR API directly to capture `jdk.FileRead` events. The test would construct a JAR that previously triggered one read per entry, and assert that after this change, only a single read is needed to initialize a compiler whose classpath includes that JAR.

tier1, tier2, tier3 testing of these changes against latest master branch has completed without any related failures. @retronym, you can go ahead and "/integrate" this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2900107948

From tvaleev at openjdk.org  Thu May 22 07:04:52 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Thu, 22 May 2025 07:04:52 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v2]
In-Reply-To: <9s3ZOLNJdFCYlyZd05FFtqNGqJjMuUCP8h_nRDsAmnY=.9fef14e2-51c8-439f-8f40-f71df65fea0e@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <w-jdj2tTfuMPgqeQkUG3dxP8-LkygRZAlQtRvEtxnfU=.3e83d2dd-5c8d-48d0-9d6c-a86f599f8825@github.com>
 <9s3ZOLNJdFCYlyZd05FFtqNGqJjMuUCP8h_nRDsAmnY=.9fef14e2-51c8-439f-8f40-f71df65fea0e@github.com>
Message-ID: <SGkjR1bkALUQQ3g09AZCPNlRStpBQo_XoHRakl9SOzA=.56963bb2-636d-4442-8c2d-491b09eac052@github.com>

On Wed, 21 May 2025 11:55:07 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Return first argument in case of tie (to be consistent with BinaryOperator); junit tests
>
> src/java.base/share/classes/java/util/Comparator.java line 200:
> 
>> 198:      * @return  the larger of {@code a} and {@code b} according to this comparator.
>> 199:      * @throws  ClassCastException if the collection contains elements that are
>> 200:      *          not <i>mutually comparable</i> (for example, strings and
> 
> `<em>` is more intent revealing.
> Suggestion:
> 
>      *          not <em>mutually comparable</em> (for example, strings and

I copied this sentence from `java.util.Collections` where `<i>` is used 48 times. I'll replace it here with `<em>`, but probably it should be updated en-masse for consistency?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2101795425

From duke at openjdk.org  Thu May 22 07:08:55 2025
From: duke at openjdk.org (duke)
Date: Thu, 22 May 2025 07:08:55 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance [v3]
In-Reply-To: <U5LJYS7yxDkt-d043HiYMoP2wOhCE7lX8Bg6zvQDbyA=.4e80780f-1f1c-4cd7-aab0-61a991cf0cbe@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
 <U5LJYS7yxDkt-d043HiYMoP2wOhCE7lX8Bg6zvQDbyA=.4e80780f-1f1c-4cd7-aab0-61a991cf0cbe@github.com>
Message-ID: <nEnWh-Bm0tq_ebvSiUsqWLN2q6Um3hMI6LzZPdlOP60=.38a2d2ff-a67a-429e-94a0-8a0223c26b7c@github.com>

On Sun, 20 Apr 2025 13:01:30 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

>> zipfs has a (undocumented) property "zipinfo-time" which was introduced in https://bugs.openjdk.org/browse/JDK-8150496 to help improve performance of the ZipFileSystem. When a ZipFileSystem is created with this property's value set to "false", then the implementation in ZipFileSystem, while constructing the entries from the ZIP file will skip reading the access time and the creation time of each ZIP entry from the entry's LOC header. This improves the performance of zipfs, since when reading the CEN, it no longer has to traverse to individual LOC headers to find the access time and creation time values of each entry.
>> 
>> Setting "zipinfo-time" = false, thus implies that the ZipFileAttributes.creationTime() and ZipFileAttributes.lastAccessTime() APIs may not return the right values when used against Path(s) corresponding to the ZIP entries in that FileSystem. Not all usages of zipfs require or use the creationTime()/lastAccessTime() APIs. Such usages can set "zipinfo-time" = false and benefit from improved performance.
>> 
>> com.sun.tools.javac.file.JavacFileManager$ArchiveContainer is one such place where when constructing the FileSystem, it could pass this property. This is especially useful since this part of the code in practice can be dealing with large number of jar files in the classpath and creating one zipfs FileSystem for each such JAR file.
>> 
>> It has been reported in the compiler-dev mailing list, that an experiment to set "zipinfo-time" = false in this part of the code has shown very noticeable performance improvements, especially on Windows, when dealing with large classpath. Details in the thread here https://mail.openjdk.org/pipermail/compiler-dev/2025-March/029529.html.
>
> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright and remove part of comment

@retronym 
Your change (at version e1334955bbe1db1cb7dd0e62c138c2321045d719) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2900148295

From tvaleev at openjdk.org  Thu May 22 07:20:11 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Thu, 22 May 2025 07:20:11 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v3]
In-Reply-To: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
Message-ID: <WpY0xzTRnW4XKAmhQQXqa0-xBBSYRfAAOtlhYvazN8k=.a461ad50-5aee-4318-90c2-9b2fb6d23f21@github.com>

> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
> 
> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
> 
> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.

Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision:

 - MinMaxTest: remove unnecessary public modifier
 - Use <em> instead of <i>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25297/files
  - new: https://git.openjdk.org/jdk/pull/25297/files/9edc73e2..b750c3fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=01-02

  Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25297.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25297/head:pull/25297

PR: https://git.openjdk.org/jdk/pull/25297

From tvaleev at openjdk.org  Thu May 22 07:22:51 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Thu, 22 May 2025 07:22:51 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v2]
In-Reply-To: <38y18L1eSJAGuzFgH8xAn38k_Xu8pqueLhYYIEAzz8M=.bd30476b-e887-414a-8f03-f3f26c78f66b@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <w-jdj2tTfuMPgqeQkUG3dxP8-LkygRZAlQtRvEtxnfU=.3e83d2dd-5c8d-48d0-9d6c-a86f599f8825@github.com>
 <38y18L1eSJAGuzFgH8xAn38k_Xu8pqueLhYYIEAzz8M=.bd30476b-e887-414a-8f03-f3f26c78f66b@github.com>
Message-ID: <WrRv8QEYDT3LtpSll8tQDJZMJcewTNhCIChVJ0FX5Zg=.4e103be5-9a15-4cfc-9012-2b20cb85f414@github.com>

On Wed, 21 May 2025 19:20:38 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Return first argument in case of tie (to be consistent with BinaryOperator); junit tests
>
> What I was trying to say is that not only would Guava's Ordering not compile any more (it would still be binary compatible I think, as both methods have same erasure), but I also think that generic max and min as defined by Guava's Ordering are more useful too. So what do you think of making them generic like this:
> 
> 
>     default <E extends T> E max(E e1, E e2) {
>         return compare(e1, e2) >= 0 ? e1 : e2;
>     }
>     
>     default <E extends T> E min(E e1, E e2) {
>         return compare(e1, e2) <= 0 ? e1 : e2;
>     }

@plevart this is definitely a good idea, and it will make the methods more convenient. I used `U` as a new type parameter, because it looks like it's more common in the OpenJDK codebase (e.g., `StructuredTaskScope::fork`). Now, Guava should be source-compatible, though it's possible that some other libraries declare non-generic min/max and they will not be source-compatible anymore. I'll mention this in CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-2900176890

From tvaleev at openjdk.org  Thu May 22 07:22:52 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Thu, 22 May 2025 07:22:52 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v2]
In-Reply-To: <9s3ZOLNJdFCYlyZd05FFtqNGqJjMuUCP8h_nRDsAmnY=.9fef14e2-51c8-439f-8f40-f71df65fea0e@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <w-jdj2tTfuMPgqeQkUG3dxP8-LkygRZAlQtRvEtxnfU=.3e83d2dd-5c8d-48d0-9d6c-a86f599f8825@github.com>
 <9s3ZOLNJdFCYlyZd05FFtqNGqJjMuUCP8h_nRDsAmnY=.9fef14e2-51c8-439f-8f40-f71df65fea0e@github.com>
Message-ID: <A6V3tRWYyYzYCTimTgwkZiZBWrVG_0ah9OA3LL_nFDY=.261dda14-9542-4ea3-95d9-2d50d81cb293@github.com>

On Wed, 21 May 2025 11:55:16 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Return first argument in case of tie (to be consistent with BinaryOperator); junit tests
>
> test/jdk/java/util/Comparator/MinMaxTest.java line 39:
> 
>> 37: public class MinMaxTest {
>> 38:   @Test
>> 39:   public void testMin() {
> 
> According to [this](https://junit.org/junit5/docs/snapshot/user-guide/#writing-tests-classes-and-methods), test methods do not need to be `public` (but cannot be `private`).
> 
> Suggestion:
> 
>   void testMin() {

Done, thanks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2101825796

From vklang at openjdk.org  Thu May 22 07:28:56 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 22 May 2025 07:28:56 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message
In-Reply-To: <7IXvN9Kkr1UqkczbU3DqFZK4aAnFPpysfEPoouqWdds=.fa401d16-3d5e-4d48-aec5-8a336afac317@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <AnrjLD7rJwg1dT8fNc5XMs8rqhSlLxIPNPk27zZtN7k=.34540e60-36c4-4c98-9a11-668fff434160@github.com>
 <3C_11D3AR_qG3ifDbWztlzhD8rZyultJEKh_89wWN1M=.5af79488-6978-4f80-a07e-b4c38139b390@github.com>
 <7IXvN9Kkr1UqkczbU3DqFZK4aAnFPpysfEPoouqWdds=.fa401d16-3d5e-4d48-aec5-8a336afac317@github.com>
Message-ID: <W54B4cZSu5ySf92bUrQFzM_li3adFuRjTzxmm602edI=.891bc5df-c436-48fd-8fca-da2c55add3e4@github.com>

On Thu, 22 May 2025 02:09:08 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

>> @He-Pin Just pinging you here, in case the notification from my most recent comments got lost in transit.
>
> @viktorklang-ora @liach, I think we need a contribution guide that explains how to set up the work in the IDE, how to perform tests, etc.

@He-Pin Please suggest improvements to https://openjdk.org/guide/ ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2900190233

From jzaugg at openjdk.org  Thu May 22 07:29:02 2025
From: jzaugg at openjdk.org (Jason Zaugg)
Date: Thu, 22 May 2025 07:29:02 GMT
Subject: Integrated: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
Message-ID: <uAoKH0xdQ6NNJJu4MwkUJr_LlSvsMcCoZVSpsZ-uTL4=.0eacab9a-523f-41d1-b193-9a9128e75484@github.com>

On Sun, 23 Mar 2025 12:38:04 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

> zipfs has a (undocumented) property "zipinfo-time" which was introduced in https://bugs.openjdk.org/browse/JDK-8150496 to help improve performance of the ZipFileSystem. When a ZipFileSystem is created with this property's value set to "false", then the implementation in ZipFileSystem, while constructing the entries from the ZIP file will skip reading the access time and the creation time of each ZIP entry from the entry's LOC header. This improves the performance of zipfs, since when reading the CEN, it no longer has to traverse to individual LOC headers to find the access time and creation time values of each entry.
> 
> Setting "zipinfo-time" = false, thus implies that the ZipFileAttributes.creationTime() and ZipFileAttributes.lastAccessTime() APIs may not return the right values when used against Path(s) corresponding to the ZIP entries in that FileSystem. Not all usages of zipfs require or use the creationTime()/lastAccessTime() APIs. Such usages can set "zipinfo-time" = false and benefit from improved performance.
> 
> com.sun.tools.javac.file.JavacFileManager$ArchiveContainer is one such place where when constructing the FileSystem, it could pass this property. This is especially useful since this part of the code in practice can be dealing with large number of jar files in the classpath and creating one zipfs FileSystem for each such JAR file.
> 
> It has been reported in the compiler-dev mailing list, that an experiment to set "zipinfo-time" = false in this part of the code has shown very noticeable performance improvements, especially on Windows, when dealing with large classpath. Details in the thread here https://mail.openjdk.org/pipermail/compiler-dev/2025-March/029529.html.

This pull request has now been integrated.

Changeset: d9b6e4b1
Author:    Jason Zaugg <jzaugg at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d9b6e4b13200684b69a161e288b9883ff0d96bec
Stats:     10 lines in 1 file changed: 7 ins; 0 del; 3 mod

8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

Reviewed-by: liach, jpai, jlahoda, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/24176

From vklang at openjdk.org  Thu May 22 07:34:02 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 22 May 2025 07:34:02 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <fjXxuXGIvezZ5aoE-a_ex4EQimfGGVQq2IqoWaie1IA=.39eaa16e-f074-4993-b10e-8d6175159951@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
 <2PjV5qPpliR71q_2HQRBychDHCFCTM4Pbw4xZDAIb7M=.329d3adf-a82e-47d8-9bd8-aab1ca897c38@github.com>
 <fjXxuXGIvezZ5aoE-a_ex4EQimfGGVQq2IqoWaie1IA=.39eaa16e-f074-4993-b10e-8d6175159951@github.com>
Message-ID: <jH-VmoWKQ_hcK6k_12K7-lsRjbA-zkoPqMu4pKDFIKw=.32ed2859-b729-4a28-8418-3d9fa2ec4a46@github.com>

On Mon, 24 Mar 2025 22:33:56 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

>> Good catch, thanks! Ordinarily, I would say a test is required, but I can't think up a viable test to verify the effect of this change in a test, so we probably need to do it without a test.
>
>> Ordinarily, I would say a test is required, but I can't think up a viable test to verify the effect of this change in a test, so we probably need to do it without a test.
> 
> I tested this change [externally](https://github.com/retronym/jarcache/blob/ba7f5cdd5f7db976a6568855a0d517f52a1404bf/demo/src/test/scala/demo/JarCacheAgentTest.java#L75-L76) with [JFRUnit](https://github.com/moditect/jfrunit). 
> 
> If preferred, I could create a `jtreg` test along similar lines. It would use the JFR API directly to capture `jdk.FileRead` events. The test would construct a JAR that previously triggered one read per entry, and assert that after this change, only a single read is needed to initialize a compiler whose classpath includes that JAR.

@retronym Great to see you here, Jason! I hope all is well. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2900199480

From pminborg at openjdk.org  Thu May 22 07:46:02 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 22 May 2025 07:46:02 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved
 using overlaps
Message-ID: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>

This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.

This has the effect of simplifying and shortening the code while improving performance. The number of branches to evaluate is reduced.

-------------

Commit messages:
 - Simplify the fill method

Changes: https://git.openjdk.org/jdk/pull/25383/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357531
  Stats: 59 lines in 1 file changed: 26 ins; 15 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/25383.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25383/head:pull/25383

PR: https://git.openjdk.org/jdk/pull/25383

From pminborg at openjdk.org  Thu May 22 07:46:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 22 May 2025 07:46:03 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps
In-Reply-To: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
Message-ID: <v340DYbWx6k7kAPRIpPAwUcvFYlKLszLevlQvP_N7tY=.697a212d-f0e4-4067-a27b-74b21e11bd01@github.com>

On Thu, 22 May 2025 07:34:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
> 
> This has the effect of simplifying and shortening the code while improving performance. The number of branches to evaluate is reduced.

Performance on an M1 Mac (Sequoia 15.4.1)

Base:


Benchmark                                   (ELEM_SIZE)  Mode  Cnt        Score        Error  Units
SegmentBulkFill.nativeSegmentFillJava                 2  avgt   30        1.618 ?      0.060  ns/op
SegmentBulkFill.nativeSegmentFillJava                 3  avgt   30        1.602 ?      0.042  ns/op
SegmentBulkFill.nativeSegmentFillJava                 4  avgt   30        1.775 ?      0.070  ns/op
SegmentBulkFill.nativeSegmentFillJava                 5  avgt   30        1.759 ?      0.051  ns/op
SegmentBulkFill.nativeSegmentFillJava                 6  avgt   30        1.771 ?      0.051  ns/op
SegmentBulkFill.nativeSegmentFillJava                 7  avgt   30        1.785 ?      0.049  ns/op
SegmentBulkFill.nativeSegmentFillJava                 8  avgt   30        2.383 ?      0.061  ns/op
SegmentBulkFill.nativeSegmentFillJava                64  avgt   30        4.010 ?      0.255  ns/op
SegmentBulkFill.nativeSegmentFillJava               512  avgt   30        6.622 ?      0.246  ns/op
SegmentBulkFill.nativeSegmentFillJava              4096  avgt   30       44.431 ?      0.832  ns/op
SegmentBulkFill.nativeSegmentFillJava             32768  avgt   30      331.429 ?      3.073  ns/op
SegmentBulkFill.nativeSegmentFillJava            262144  avgt   30     4174.795 ?     76.096  ns/op
SegmentBulkFill.nativeSegmentFillJava           2097152  avgt   30    33084.699 ?     53.530  ns/op
SegmentBulkFill.nativeSegmentFillJava          16777216  avgt   30   298953.004 ?  11241.262  ns/op
SegmentBulkFill.nativeSegmentFillJava         134217728  avgt   30  2857973.939 ? 128453.291  ns/op


Patch

Benchmark                              (ELEM_SIZE)  Mode  Cnt        Score        Error  Units
SegmentBulkFill.nativeSegmentFillJava            2  avgt   30        1.317 ?      0.022  ns/op
SegmentBulkFill.nativeSegmentFillJava            3  avgt   30        1.313 ?      0.006  ns/op
SegmentBulkFill.nativeSegmentFillJava            4  avgt   30        1.319 ?      0.018  ns/op
SegmentBulkFill.nativeSegmentFillJava            5  avgt   30        1.317 ?      0.019  ns/op
SegmentBulkFill.nativeSegmentFillJava            6  avgt   30        1.316 ?      0.016  ns/op
SegmentBulkFill.nativeSegmentFillJava            7  avgt   30        1.320 ?      0.019  ns/op
SegmentBulkFill.nativeSegmentFillJava            8  avgt   30        2.239 ?      0.047  ns/op
SegmentBulkFill.nativeSegmentFillJava           64  avgt   30        3.487 ?      0.074  ns/op
SegmentBulkFill.nativeSegmentFillJava          512  avgt   30        6.659 ?      0.102  ns/op
SegmentBulkFill.nativeSegmentFillJava         4096  avgt   30       44.461 ?      0.666  ns/op
SegmentBulkFill.nativeSegmentFillJava        32768  avgt   30      331.159 ?      5.928  ns/op
SegmentBulkFill.nativeSegmentFillJava       262144  avgt   30     4171.649 ?     60.867  ns/op
SegmentBulkFill.nativeSegmentFillJava      2097152  avgt   30    34718.817 ?    697.494  ns/op
SegmentBulkFill.nativeSegmentFillJava     16777216  avgt   30   305446.597 ?  11087.702  ns/op
SegmentBulkFill.nativeSegmentFillJava    134217728  avgt   30  2905051.303 ? 114905.125  ns/op


![image](https://github.com/user-attachments/assets/df4888ab-67d9-49fe-982b-8018d949cee3)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2900213674

From duke at openjdk.org  Thu May 22 07:58:07 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 22 May 2025 07:58:07 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message
In-Reply-To: <W54B4cZSu5ySf92bUrQFzM_li3adFuRjTzxmm602edI=.891bc5df-c436-48fd-8fca-da2c55add3e4@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <AnrjLD7rJwg1dT8fNc5XMs8rqhSlLxIPNPk27zZtN7k=.34540e60-36c4-4c98-9a11-668fff434160@github.com>
 <3C_11D3AR_qG3ifDbWztlzhD8rZyultJEKh_89wWN1M=.5af79488-6978-4f80-a07e-b4c38139b390@github.com>
 <7IXvN9Kkr1UqkczbU3DqFZK4aAnFPpysfEPoouqWdds=.fa401d16-3d5e-4d48-aec5-8a336afac317@github.com>
 <W54B4cZSu5ySf92bUrQFzM_li3adFuRjTzxmm602edI=.891bc5df-c436-48fd-8fca-da2c55add3e4@github.com>
Message-ID: <Dp4yZltiHUwwByJJxQ8pHLzavDgPV4a3ng4d3aYkBnY=.0c083afd-72e9-49f9-b4ee-638601323a98@github.com>

On Thu, 22 May 2025 07:26:29 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> @viktorklang-ora @liach, I think we need a contribution guide that explains how to set up the work in the IDE, how to perform tests, etc.
>
> @He-Pin Please suggest improvements to https://openjdk.org/guide/ ?

> @viktorklang-ora @liach, I think we need a contribution guide that explains how to set up the work in the IDE, how to perform tests, etc.

This document https://github.com/openjdk/jdk/blob/master/doc/ide.md describes IDE support, but I couldn't find if it is also contained/linked from https://openjdk.org/guide/

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2900260927

From vyazici at openjdk.org  Thu May 22 07:59:09 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 07:59:09 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
 <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>
Message-ID: <JR9YcwtR6e9rtwHNRjzrc_f3vDzGlX5P7HbsynNMOmQ=.58dcd998-ff73-4547-b619-1ba8fa12bd7d@github.com>

On Wed, 21 May 2025 21:37:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
>> 
>> ### Fixing strategy
>> 
>> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
>> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
>> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
>> 
>> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
>> 
>> ### Scanning strategy
>> 
>> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
>> 
>> 
>> # Perl is used for multi-line matching
>> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
>> git grep -H 'FileDescriptor.in' "*.java"
>> 
>> 
>> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
>> 
>> ### Problems encountered
>> 
>> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
>> 
>>     ```
>>     DOMImplementationRegistry 
>>     InputRC 
>>     ListingErrorHandler 
>>     PandocFilter 
>>     ```
>> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property
>
> There too many changes in too many different areas to be in a single PR.
> Please break it down by review areas.  Client, core libs, tools, etc.

@RogerRiggs, @AlanBateman, thanks so much for the quick review. I see your points. I will

1. withdraw this PR,
2. convert certain changes to spec clarifications,
3. and break it down to multiple PRs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2900262422

From vyazici at openjdk.org  Thu May 22 07:59:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 07:59:10 GMT
Subject: Withdrawn: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <cRfyJRr23DS3mw4U7XMBE6rBHXIWxlQiEcNpKG-wZBw=.6a7bcbb9-9cb6-45dc-8ce6-40fefbd328ff@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25368

From vyazici at openjdk.org  Thu May 22 08:05:54 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 08:05:54 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v4]
In-Reply-To: <kPGBTgP8cygkC-ufTlutlYYiAJ40KzRY57OGJxCu4j0=.ed8a0e9e-78b6-4bf4-8d66-4a60459d5e56@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <kPGBTgP8cygkC-ufTlutlYYiAJ40KzRY57OGJxCu4j0=.ed8a0e9e-78b6-4bf4-8d66-4a60459d5e56@github.com>
Message-ID: <cQELsC-0J1TuA_LuExhAZQ7mVm5wGTxr3Cv4xSaFBww=.58b8ea3f-8a12-430e-853c-95535d12bbc0@github.com>

On Wed, 21 May 2025 19:29:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CharsetTest clean-up

Marked as reviewed by vyazici (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25271#pullrequestreview-2860206112

From pminborg at openjdk.org  Thu May 22 08:14:35 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 22 May 2025 08:14:35 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v2]
In-Reply-To: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
Message-ID: <mTXrTbT8kyl5BZVzV79ZaudzVjlyrdRQMW9XaYq11L0=.53584dd8-4f9a-4a86-9ba4-24ff3ffa79cf@github.com>

> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
> 
> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Correct typo in comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25383/files
  - new: https://git.openjdk.org/jdk/pull/25383/files/1a095f60..9e0d67ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25383.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25383/head:pull/25383

PR: https://git.openjdk.org/jdk/pull/25383

From swen at openjdk.org  Thu May 22 08:14:35 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 22 May 2025 08:14:35 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v2]
In-Reply-To: <mTXrTbT8kyl5BZVzV79ZaudzVjlyrdRQMW9XaYq11L0=.53584dd8-4f9a-4a86-9ba4-24ff3ffa79cf@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <mTXrTbT8kyl5BZVzV79ZaudzVjlyrdRQMW9XaYq11L0=.53584dd8-4f9a-4a86-9ba4-24ff3ffa79cf@github.com>
Message-ID: <hr3TgVZzMik9h2D4E0-OPJAxhPlyuLEBrGOFuuSNX1I=.ce480f39-e139-47e8-b9a9-05869c5b45cf@github.com>

On Thu, 22 May 2025 08:11:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
>> 
>> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct typo in comment

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 110:

> 108:                     SCOPED_MEMORY_ACCESS.setMemory(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset(), len, value);
> 109:                 }
> 110:             }

Suggestion:

        final var sessionImpl = dst.sessionImpl();
        final var unsafeGetBase = dst.unsafeGetBase();
        final var unsafeGetOffset = dst.unsafeGetOffset();
        final var bigEndian = !Architecture.isLittleEndian();

        // Switch on log2(len) = 64 - Long.numberOfLeadingZeros(len)
        switch (64 - Long.numberOfLeadingZeros(len)) {
            case 0 -> sessionImpl.checkValidState(); // Implicit state check
            case 1 -> SCOPED_MEMORY_ACCESS.putByte(sessionImpl, unsafeGetBase, unsafeGetOffset, value);
            case 2 -> {
                SCOPED_MEMORY_ACCESS.putShortUnaligned(sessionImpl, unsafeGetBase, unsafeGetOffset, (short) longValue, bigEndian);
                SCOPED_MEMORY_ACCESS.putShortUnaligned(sessionImpl, unsafeGetBase, unsafeGetOffset + len - Short.BYTES, (short) longValue, bigEndian);
            }
            case 3 -> {
                SCOPED_MEMORY_ACCESS.putIntUnaligned(sessionImpl, unsafeGetBase, unsafeGetOffset, (int) longValue, bigEndian);
                SCOPED_MEMORY_ACCESS.putIntUnaligned(sessionImpl, unsafeGetBase, unsafeGetOffset + len - Integer.BYTES, (int) longValue, bigEndian);
            }
            default -> {
                if (len < NATIVE_THRESHOLD_FILL) {
                    final int limit = (int) (len & (NATIVE_THRESHOLD_FILL - 8));
                    for (int offset = 0; offset < limit; offset += Long.BYTES) {
                        SCOPED_MEMORY_ACCESS.putLongUnaligned(sessionImpl, unsafeGetBase, unsafeGetOffset + offset, longValue, bigEndian);
                    }
                    SCOPED_MEMORY_ACCESS.putLongUnaligned(sessionImpl, unsafeGetBase, unsafeGetOffset + len - Long.BYTES, longValue, bigEndian);
                } else {
                    // Handle larger segments via native calls
                    SCOPED_MEMORY_ACCESS.setMemory(sessionImpl, unsafeGetBase, unsafeGetOffset, len, value);
                }
            }
        }


The current CodeSize is 370, which is greater than 325. It cannot be inlined during C2 optimization. We can extract the method calls used in each branch and declare them as local variables, which can reduce the CodeSize to 298.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25383#discussion_r2101921745

From swen at openjdk.org  Thu May 22 08:25:52 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 22 May 2025 08:25:52 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v2]
In-Reply-To: <mTXrTbT8kyl5BZVzV79ZaudzVjlyrdRQMW9XaYq11L0=.53584dd8-4f9a-4a86-9ba4-24ff3ffa79cf@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <mTXrTbT8kyl5BZVzV79ZaudzVjlyrdRQMW9XaYq11L0=.53584dd8-4f9a-4a86-9ba4-24ff3ffa79cf@github.com>
Message-ID: <v7B8F-Ejn53R_FJg8gsroixDVwmQkjDrk2FDz7D8ncU=.d2f90e4c-76ba-433d-9362-edbc52a7de0f@github.com>

On Thu, 22 May 2025 08:14:35 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
>> 
>> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct typo in comment

Here you can use putShort/putInt/putLong to replace putShortUnaligned/putIntUnaligned/putLongUnaligned

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2900343335

From duke at openjdk.org  Thu May 22 08:31:06 2025
From: duke at openjdk.org (serhiysachkov)
Date: Thu, 22 May 2025 08:31:06 GMT
Subject: RFR: 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java
 test scenario to run as manual [v2]
In-Reply-To: <IMl8opuemVxRGiD46GfPuh0eZ1d6R86xkOdc3HIsT1I=.228f1873-ee56-4c22-919b-afd86dc8cc20@github.com>
References: <IMl8opuemVxRGiD46GfPuh0eZ1d6R86xkOdc3HIsT1I=.228f1873-ee56-4c22-919b-afd86dc8cc20@github.com>
Message-ID: <XXnGCB8v8vhQFa4V6SzhO8N9ORlD5zjSrJpNzNQ7ViI=.ab9023b3-1c70-4e29-be87-6f7f2dc2d7f1@github.com>

> Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual

serhiysachkov has updated the pull request incrementally with one additional commit since the last revision:

  8357462: copyright update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25355/files
  - new: https://git.openjdk.org/jdk/pull/25355/files/166a8fe2..43bf37b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25355&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25355&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25355.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25355/head:pull/25355

PR: https://git.openjdk.org/jdk/pull/25355

From abimpoudis at openjdk.org  Thu May 22 08:39:58 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 22 May 2025 08:39:58 GMT
Subject: Integrated: 8354323: Safeguard SwitchBootstraps.typeSwitch when used
 outside the compiler
In-Reply-To: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
References: <g83dC1bAfWnpc87J4YXW_EiSyLXWD8vUsQSi7_Z8e0Q=.c07d31ec-c381-4677-b714-d1a4b4596acd@github.com>
Message-ID: <y7-pvzjCotGV_kV9HMlhkyHLMg2p9tULia9ari9NYOg=.8d6ec732-de26-41d6-a8ca-6349ef8d81b9@github.com>

On Wed, 7 May 2025 11:57:02 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> While the compiler does not allow invalid queries to flow into `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch` does not prevent such usage pattern errors resulting in erroneous evaluation.
> 
> For example this is not valid Java (and protected) by javac:
> 
> 
> byte b = 1;
> switch (b) {
>     case String s -> System.out.println("How did we get here? byte is " + s.getClass());
> }
> 
> 
> but this is a valid call (and not protected):
> 
> 
> CallSite shortSwitch = SwitchBootstraps.typeSwitch(
>     MethodHandles.lookup(), 
>     "", 
>     MethodType.methodType(int.class, short.class, int.class),  // models (short, int) -> int
>     String.class);
> 
> 
> The `SwitchBootstraps.typeSwitch` returns wrong result since the code was reasoning erroneously that this pair was unconditionally exact. 
> 
> This PR proposes to add the safety check in unconditional exactness which will return false in erroneous pairs and then the actual check will be delegated to `instanceof`. For the case of erroneous pairs with primitive `boolean`s there is a check in the beginning of the type switch skeleton.

This pull request has now been integrated.

Changeset: c0665efd
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c0665efd4f7f43c567393570ba6872838debd77f
Stats:     43 lines in 3 files changed: 27 ins; 4 del; 12 mod

8354323: Safeguard SwitchBootstraps.typeSwitch when used outside the compiler

Reviewed-by: jlahoda, liach

-------------

PR: https://git.openjdk.org/jdk/pull/25090

From mcimadamore at openjdk.org  Thu May 22 08:58:50 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 22 May 2025 08:58:50 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps
In-Reply-To: <v340DYbWx6k7kAPRIpPAwUcvFYlKLszLevlQvP_N7tY=.697a212d-f0e4-4067-a27b-74b21e11bd01@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <v340DYbWx6k7kAPRIpPAwUcvFYlKLszLevlQvP_N7tY=.697a212d-f0e4-4067-a27b-74b21e11bd01@github.com>
Message-ID: <28EjVeHYRyc8FD4WTEi7AU9rdUXbzD2vUXUsOfTmdII=.0c7b5abc-1e73-476d-96af-91b5b7bfb1b8@github.com>

On Thu, 22 May 2025 07:36:51 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Performance on an M1 Mac (Sequoia 15.4.1)

Are the "regressions" for very big sizes related to this patch?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2900432766

From mcimadamore at openjdk.org  Thu May 22 08:58:52 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 22 May 2025 08:58:52 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v2]
In-Reply-To: <mTXrTbT8kyl5BZVzV79ZaudzVjlyrdRQMW9XaYq11L0=.53584dd8-4f9a-4a86-9ba4-24ff3ffa79cf@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <mTXrTbT8kyl5BZVzV79ZaudzVjlyrdRQMW9XaYq11L0=.53584dd8-4f9a-4a86-9ba4-24ff3ffa79cf@github.com>
Message-ID: <tfbzw0-HYk1SqkAyyT5HZqWdwpkW0Gyekg6tQt2b-V4=.1f18e352-3452-49ed-ba52-e568347f7606@github.com>

On Thu, 22 May 2025 08:14:35 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
>> 
>> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct typo in comment

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 93:

> 91:             case 2 -> {
> 92:                 SCOPED_MEMORY_ACCESS.putShortUnaligned(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset(), (short) longValue, !Architecture.isLittleEndian());
> 93:                 SCOPED_MEMORY_ACCESS.putShortUnaligned(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset() + len - Short.BYTES, (short) longValue, !Architecture.isLittleEndian());

So that I understand, since this configuration might pick up both length = 2 and length = 3, in 50% of cases there's a redundant store? This is also true for length = 4, 5, 6, 7 -- but in this case the chance of redundant store is reduced to 25%.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25383#discussion_r2102016436

From duke at openjdk.org  Thu May 22 09:05:27 2025
From: duke at openjdk.org (serhiysachkov)
Date: Thu, 22 May 2025 09:05:27 GMT
Subject: RFR: 8356443: Update open/test/jdk/TEST.groups manual test groups
 definitions with missing manual test
Message-ID: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com>

Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test

-------------

Commit messages:
 - 8356443: Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test

Changes: https://git.openjdk.org/jdk/pull/25360/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25360&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356443
  Stats: 7 lines in 1 file changed: 3 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25360/head:pull/25360

PR: https://git.openjdk.org/jdk/pull/25360

From stuefe at openjdk.org  Thu May 22 09:41:52 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 22 May 2025 09:41:52 GMT
Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(),
 use FD_CLOEXEC instead of close()
In-Reply-To: <lFj7d1LqoWpksdywivQQFvpOj_NI5ETXafl2QuQB7zc=.bf996897-fa67-47fd-b60f-a654a98d9af9@github.com>
References: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
 <lFj7d1LqoWpksdywivQQFvpOj_NI5ETXafl2QuQB7zc=.bf996897-fa67-47fd-b60f-a654a98d9af9@github.com>
Message-ID: <yNWPeHMAJt0DI0lV7emkacvxjd9mha_mHih3ITQuk1A=.17416a57-f14a-4e29-b6c2-72880992870e@github.com>

On Wed, 21 May 2025 19:10:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Hi, please consider the following patch.
>> 
>> This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc.
>> 
>> This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens).
>> 
>> Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409
>> 
>> This patch also fixes two subtle bugs:
>> - we didn't check the return value of the close() inside closeAllFileDescriptors
>> - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it)
>> 
>> ----
>> 
>> Testing:
>> 
>> We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC.
>> 
>> - in the parent JVM, the test opens a file in native code without FD_CLOEXEC
>> - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open
>> 
>> I verified that the test correctly detects a broken implementation that leaks file descriptors. 
>> 
>> I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX).
>> 
>> I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green.
>
> Looks good

@RogerRiggs Thank you. I hold this up a few days until JDK26 since its not super critical. Would one review be sufficient or do I need more?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25301#issuecomment-2900562843

From jpai at openjdk.org  Thu May 22 10:41:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 10:41:59 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <ISsFz3sMJMDu3sh5CfJWicigVorVDLsLpDIY8adVnq4=.804db444-277b-485b-981d-c154c15d07a3@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
 <6F_2GSLLN0ajSO73JcYDd0wXvTthdFjgfxXDQ8XndYU=.c3ad4280-fcc3-4eaf-a658-2d5212009260@github.com>
 <ISsFz3sMJMDu3sh5CfJWicigVorVDLsLpDIY8adVnq4=.804db444-277b-485b-981d-c154c15d07a3@github.com>
Message-ID: <Au9pwB-seNATiUg03WTMKvOh3bpM83Y1PRANG9OCMNc=.77689a4a-e1fb-4025-a844-40d44b4f6946@github.com>

On Thu, 22 May 2025 01:41:51 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 454:
>> 
>>> 452:                     new FileInputStream(file)))) {
>>> 453: 
>>> 454:             return Validator.validate(this, zf, zis);
>> 
>> I think it might be better to change the `Validator.validate()` method to accept a `java.nio.file.Path` instead of accepting a ZipFile instance and a ZipInputStream instance. In its current form it feels odd that the call site (like here) needs to pass ZipFile and ZipInputStream to a validator. The checks using a ZipFile and a ZipInputStream for the same file is more an internal detail of the validator, so it would be good to let it construct those instances internally as appropriate.
>> 
>> The `Validator` class itself belongs to an internal package of this tool, so changing the signature of this method to accept a `Path` wouldn't be a problem.
>> 
>> It also looks like the Validator uses this `Main` instance merely for error reporting. So maybe in a future update we could remove the need to pass along this `Main` instance to the validator. That one doesn't have to be done in this PR.
>
> I keep File instead of Path to avoid unnecessary changes.

Thank you for the update to this method, Henry. Retaining the use of `File` is fine. We have a separate plan for future to use `java.nio.file.Path` for the code in the jar tool and this can be revisited at that time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102239606

From jpai at openjdk.org  Thu May 22 10:51:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 10:51:07 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
Message-ID: <AUS1zszlE8wi3Qc1o7T77qgSubwf0DMSlySq_njCQXg=.56746d64-248a-4aaa-8684-da18cdaf727e@github.com>

On Thu, 22 May 2025 01:29:12 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Validator to take a file, use term JAR file

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 141:

> 139:      * NOTE: In order to check the encounter order based on the CEN listing,
> 140:      *       this implementation assumes CEN entries are to be added before
> 141:      *       add any LOC entries. That is, addCenEntry should be called before

This looks like a typo. Should have been "adding any ..."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102254941

From jpai at openjdk.org  Thu May 22 11:11:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 11:11:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
Message-ID: <nnfwV5PrNKiLCfn9dzqvqKj5z5Zt92rZRmxDXuhiZiU=.b8233954-22ed-4530-bbb4-7e6ae12b5f5f@github.com>

On Thu, 22 May 2025 01:29:12 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Validator to take a file, use term JAR file

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 147:

> 145:     private class EntryValidator {
> 146:         // A place holder when an entry is not yet seen in the directory
> 147:         static EntryEncounter PLACE_HOLDER = new EntryEncounter(0, 0);

It looks like this could be `final`? And then `isPlaceHolder()` could just return `this == PLACE_HOLDER`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102292540

From pminborg at openjdk.org  Thu May 22 11:16:58 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 22 May 2025 11:16:58 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps
In-Reply-To: <28EjVeHYRyc8FD4WTEi7AU9rdUXbzD2vUXUsOfTmdII=.0c7b5abc-1e73-476d-96af-91b5b7bfb1b8@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <v340DYbWx6k7kAPRIpPAwUcvFYlKLszLevlQvP_N7tY=.697a212d-f0e4-4067-a27b-74b21e11bd01@github.com>
 <28EjVeHYRyc8FD4WTEi7AU9rdUXbzD2vUXUsOfTmdII=.0c7b5abc-1e73-476d-96af-91b5b7bfb1b8@github.com>
Message-ID: <JhaTfDx4h6Zzm0OKqfcfjXIw66Ecly76Xr4-s0MkcwQ=.50883aa2-be82-4bed-a435-7f92d6d990d1@github.com>

On Thu, 22 May 2025 08:56:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > Performance on an M1 Mac (Sequoia 15.4.1)
> 
> Are the "regressions" for very big sizes related to this patch?

By default, only segments that are smaller than 32 bytes will use the affected code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2900835299

From pminborg at openjdk.org  Thu May 22 11:26:37 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 22 May 2025 11:26:37 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v3]
In-Reply-To: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
Message-ID: <w4rOH9DJsKh9KP_6qZq-tgXxRwigre-G0ShZvtqKnmg=.7e844cc8-fd62-4290-9c0a-0d25dff88967@github.com>

> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
> 
> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
> 
> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add case for long operations and break out methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25383/files
  - new: https://git.openjdk.org/jdk/pull/25383/files/9e0d67ec..65c88fba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=01-02

  Stats: 54 lines in 1 file changed: 32 ins; 17 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25383.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25383/head:pull/25383

PR: https://git.openjdk.org/jdk/pull/25383

From pminborg at openjdk.org  Thu May 22 11:26:37 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 22 May 2025 11:26:37 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v2]
In-Reply-To: <v7B8F-Ejn53R_FJg8gsroixDVwmQkjDrk2FDz7D8ncU=.d2f90e4c-76ba-433d-9362-edbc52a7de0f@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <mTXrTbT8kyl5BZVzV79ZaudzVjlyrdRQMW9XaYq11L0=.53584dd8-4f9a-4a86-9ba4-24ff3ffa79cf@github.com>
 <v7B8F-Ejn53R_FJg8gsroixDVwmQkjDrk2FDz7D8ncU=.d2f90e4c-76ba-433d-9362-edbc52a7de0f@github.com>
Message-ID: <8LSWD4ZFbb8dkGOVvUFPXutCgkatFekJye7f3wgzDNA=.95be2805-723a-4782-9913-e3bd1f5d072f@github.com>

On Thu, 22 May 2025 08:23:26 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Here you can use putShort/putInt/putLong to replace putShortUnaligned/putIntUnaligned/putLongUnaligned

The segment might be unaligned. For example, if it was sliced off an aligned segment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2900848621

From pminborg at openjdk.org  Thu May 22 11:26:37 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 22 May 2025 11:26:37 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v2]
In-Reply-To: <tfbzw0-HYk1SqkAyyT5HZqWdwpkW0Gyekg6tQt2b-V4=.1f18e352-3452-49ed-ba52-e568347f7606@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <mTXrTbT8kyl5BZVzV79ZaudzVjlyrdRQMW9XaYq11L0=.53584dd8-4f9a-4a86-9ba4-24ff3ffa79cf@github.com>
 <tfbzw0-HYk1SqkAyyT5HZqWdwpkW0Gyekg6tQt2b-V4=.1f18e352-3452-49ed-ba52-e568347f7606@github.com>
Message-ID: <QyBDrkq7f-pZRTO96ohQFdH-J-ejW9prsWKhq4CVrOk=.bcac5a0c-5f77-42cb-a942-a727b84e6197@github.com>

On Thu, 22 May 2025 08:55:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct typo in comment
>
> src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 93:
> 
>> 91:             case 2 -> {
>> 92:                 SCOPED_MEMORY_ACCESS.putShortUnaligned(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset(), (short) longValue, !Architecture.isLittleEndian());
>> 93:                 SCOPED_MEMORY_ACCESS.putShortUnaligned(dst.sessionImpl(), dst.unsafeGetBase(), dst.unsafeGetOffset() + len - Short.BYTES, (short) longValue, !Architecture.isLittleEndian());
> 
> So that I understand, since this configuration might pick up both length = 2 and length = 3, in 50% of cases there's a redundant store? This is also true for length = 4, 5, 6, 7 -- but in this case the chance of redundant store is reduced to 25%.

That is correct. But it seems the hardware can handle redundant stores better than handling more branching. One idea is to add in "halfbits" to the tableswitch which would reduce redundant stores. I think this would have little to no performance effect while complicating the code, but it might be worth trying anyhow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25383#discussion_r2102307360

From jpai at openjdk.org  Thu May 22 11:26:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 11:26:58 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
Message-ID: <OvTPJhEKFBendHavmBWOYTmqG1IyFHvebu0L03MXq8g=.18218b2c-d594-4b5d-8caf-46bbeee02f7f@github.com>

On Thu, 22 May 2025 01:29:12 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Validator to take a file, use term JAR file

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 185:

> 183:         // Encounter order in CEN, step by 1 on each new entry
> 184:         int cenEncounterOrder = 0;
> 185:         // Encounter order in LOC, step by 1 for new LOC entry exist in CEN

Nit - "for new LOC entry that exists in CEN"

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 208:

> 206:         /**
> 207:          * Record an entry apperance in LOC
> 208:          * We compare entry order based on the CEN. Thus do not step LOC

Nit - would "Thus do not increment LOC ..." be easier to understand? You don't have to do the change if you prefer it this way (I see that we use the same term on the comment of the `cenEncounterOrder` and `locEncounterOrder` fields.

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 238:

> 236:         /**
> 237:          * Validation per entry observed.
> 238:          * Each entry must appeared at least oncee in CEN or LOC.

A couple of typos - "Each entry must appear at least once in the CEN or LOC"

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 265:

> 263: 
> 264:         /**
> 265:          * Validate the jar entries by check each entry in encounter order

Typo - "by checking ..."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102312203
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102312688
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102316444
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102321661

From pminborg at openjdk.org  Thu May 22 11:37:38 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 22 May 2025 11:37:38 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v4]
In-Reply-To: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
Message-ID: <Xq72HPKBQqdX_pNsR_ciow6tENMtbXQ8gejbK-QJPuc=.e301a41a-30c1-42ad-8e99-9dfb7eb655d0@github.com>

> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
> 
> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
> 
> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Simplify

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25383/files
  - new: https://git.openjdk.org/jdk/pull/25383/files/65c88fba..eadf067b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=02-03

  Stats: 5 lines in 2 files changed: 1 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25383.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25383/head:pull/25383

PR: https://git.openjdk.org/jdk/pull/25383

From jpai at openjdk.org  Thu May 22 11:44:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 11:44:53 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <OvTPJhEKFBendHavmBWOYTmqG1IyFHvebu0L03MXq8g=.18218b2c-d594-4b5d-8caf-46bbeee02f7f@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
 <OvTPJhEKFBendHavmBWOYTmqG1IyFHvebu0L03MXq8g=.18218b2c-d594-4b5d-8caf-46bbeee02f7f@github.com>
Message-ID: <6Hk0ojFnclvLTaykOsVJBhZ3WmFw2AwJZWCbjob25xY=.6d79d9f6-a6b4-48ba-a6a6-22cd0e9447d5@github.com>

On Thu, 22 May 2025 11:20:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Validator to take a file, use term JAR file
>
> src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 185:
> 
>> 183:         // Encounter order in CEN, step by 1 on each new entry
>> 184:         int cenEncounterOrder = 0;
>> 185:         // Encounter order in LOC, step by 1 for new LOC entry exist in CEN
> 
> Nit - "for new LOC entry that exists in CEN"

I think the way you have implemented this is correct, but can you explain why we don't increment the `locEncounterOrder` for each LOC entry? I'm pretty sure I'll keep asking myself that question every time I see this code in future, so it would be good to have this clarified.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102350306

From jpai at openjdk.org  Thu May 22 11:44:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 11:44:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
Message-ID: <9eBVY2wfBH5n4aochz0yfDxWub3LmS_nVW0LlUugzkw=.bccb2195-704f-4b95-8fb1-3070a3174090@github.com>

On Thu, 22 May 2025 01:29:12 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Validator to take a file, use term JAR file

test/jdk/tools/jar/ValidatorTest.java line 60:

> 58: import jdk.test.lib.util.FileUtils;
> 59: 
> 60: @TestInstance(Lifecycle.PER_CLASS)

I haven't seen this used commonly in our tests. Is there something specific in this test that requires this usage?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102353416

From jpai at openjdk.org  Thu May 22 11:49:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 11:49:56 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
Message-ID: <9UV7peR74Nase0cMQ7evBn-99r_aGMlGjyF-0apfTRo=.0363580c-e520-46c6-88e3-dd0cece21294@github.com>

On Thu, 22 May 2025 01:29:12 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Validator to take a file, use term JAR file

test/jdk/tools/jar/ValidatorTest.java line 224:

> 222: 
> 223:     @Test
> 224:     public void testValidateJar() throws IOException {

Perhaps rename the method to `testValidJar()`?

test/jdk/tools/jar/ValidatorTest.java line 230:

> 228:             jar("--validate --file " + zip.toString());
> 229:         } catch (IOException e) {
> 230:             fail("Expecting zero exit code");

I think we should remove the try/catch block and let the IOException propagate. That way, if htis fails for whatever reason, we get the entire exception stacktrace. A comment before the `jar("--validate --file ...)` line can say that we except the `jar()` call to succeed with a zero exit code.

test/jdk/tools/jar/ValidatorTest.java line 235:

> 233: 
> 234:     @Test
> 235:     public void testValidate() throws IOException {

Perhaps rename to `testMultiManifestJar()`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102361183
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102359049
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102361579

From pminborg at openjdk.org  Thu May 22 11:52:34 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 22 May 2025 11:52:34 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v5]
In-Reply-To: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
Message-ID: <kBtT8hpgfy9e9OBLI8_5S9PBsuVmqBuTB_NcoZIwoMA=.78786b50-55ab-4604-9dbd-87f27fcdc575@github.com>

> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
> 
> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
> 
> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update benchmark to reflect new fill method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25383/files
  - new: https://git.openjdk.org/jdk/pull/25383/files/eadf067b..5c878bbd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=03-04

  Stats: 19 lines in 1 file changed: 4 ins; 3 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/25383.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25383/head:pull/25383

PR: https://git.openjdk.org/jdk/pull/25383

From jvernee at openjdk.org  Thu May 22 11:59:01 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 22 May 2025 11:59:01 GMT
Subject: RFR: 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java
 test scenario to run as manual [v2]
In-Reply-To: <XXnGCB8v8vhQFa4V6SzhO8N9ORlD5zjSrJpNzNQ7ViI=.ab9023b3-1c70-4e29-be87-6f7f2dc2d7f1@github.com>
References: <IMl8opuemVxRGiD46GfPuh0eZ1d6R86xkOdc3HIsT1I=.228f1873-ee56-4c22-919b-afd86dc8cc20@github.com>
 <XXnGCB8v8vhQFa4V6SzhO8N9ORlD5zjSrJpNzNQ7ViI=.ab9023b3-1c70-4e29-be87-6f7f2dc2d7f1@github.com>
Message-ID: <QRSjfTMY5cbNxnHMCPtFdhp95-NxNNh3WMg-d8ltgvg=.bb1b9c72-32c6-4cf6-b373-b3724173d59d@github.com>

On Thu, 22 May 2025 08:31:06 GMT, serhiysachkov <duke at openjdk.org> wrote:

>> Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual
>
> serhiysachkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357462: copyright update

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25355#pullrequestreview-2860940487

From jpai at openjdk.org  Thu May 22 11:59:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 11:59:02 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
Message-ID: <-RuOE8u98OK_ruRjXFgPQsWhOnB1aPSeh_0TeOVqmlQ=.4fc88805-062c-4619-8da2-81f9a026af0d@github.com>

On Thu, 22 May 2025 01:29:12 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Validator to take a file, use term JAR file

test/jdk/tools/jar/ValidatorTest.java line 293:

> 291:         } catch (IOException e) {
> 292:             var err = e.getMessage();
> 293:             assertTrue(err.contains("Warning: Central directory and local file header entries are not in the same order"));

Unlike in other tests, we are missing a `System.out.println(err)` before the assert here.

test/jdk/tools/jar/ValidatorTest.java line 308:

> 306:             System.out.println(err);
> 307:             for (var entryName : invalidEntryNames) {
> 308:                 assertTrue(err.contains("Warning: entry name " + entryName + " is not valid"));

To help debug any failures, it might be better to include the entryName that failed the assert, something like:


assertTrue(err.contains("Warning: entry name " + entryName + " is not valid"), "missing warning for " + entryName);

test/jdk/tools/jar/ValidatorTest.java line 325:

> 323:         try {
> 324:             int rc = JAR_TOOL.run(jarOut, err, cmdline.split(" +"));
> 325:             if (rc != 0) {

Nit - should we add a `System.out.println("exit code: " + rc);`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102370169
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102374499
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102379182

From pminborg at openjdk.org  Thu May 22 12:00:55 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 22 May 2025 12:00:55 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v5]
In-Reply-To: <kBtT8hpgfy9e9OBLI8_5S9PBsuVmqBuTB_NcoZIwoMA=.78786b50-55ab-4604-9dbd-87f27fcdc575@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <kBtT8hpgfy9e9OBLI8_5S9PBsuVmqBuTB_NcoZIwoMA=.78786b50-55ab-4604-9dbd-87f27fcdc575@github.com>
Message-ID: <hw98-uTItUM8PJdvRQKSnmYzoteP16AiT_M1Zpd0mTE=.c701b41e-59d4-4a90-a643-7160be4d66bd@github.com>

On Thu, 22 May 2025 11:52:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
>> 
>> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
>> 
>> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update benchmark to reflect new fill method

Updated benchmarks:

Base:

Benchmark                                   (ELEM_SIZE)  Mode  Cnt        Score        Error  Units
SegmentBulkFill.nativeSegmentFillJava                 2  avgt   30        1.618 ?      0.060  ns/op
SegmentBulkFill.nativeSegmentFillJava                 3  avgt   30        1.602 ?      0.042  ns/op
SegmentBulkFill.nativeSegmentFillJava                 4  avgt   30        1.775 ?      0.070  ns/op
SegmentBulkFill.nativeSegmentFillJava                 5  avgt   30        1.759 ?      0.051  ns/op
SegmentBulkFill.nativeSegmentFillJava                 6  avgt   30        1.771 ?      0.051  ns/op
SegmentBulkFill.nativeSegmentFillJava                 7  avgt   30        1.785 ?      0.049  ns/op
SegmentBulkFill.nativeSegmentFillJava                 8  avgt   30        2.383 ?      0.061  ns/op
(12 is estimated in the chart below)
SegmentBulkFill.nativeSegmentFillJava                64  avgt   30        4.010 ?      0.255  ns/op
SegmentBulkFill.nativeSegmentFillJava               512  avgt   30        6.622 ?      0.246  ns/op
SegmentBulkFill.nativeSegmentFillJava              4096  avgt   30       44.431 ?      0.832  ns/op
SegmentBulkFill.nativeSegmentFillJava             32768  avgt   30      331.429 ?      3.073  ns/op
SegmentBulkFill.nativeSegmentFillJava            262144  avgt   30     4174.795 ?     76.096  ns/op
SegmentBulkFill.nativeSegmentFillJava           2097152  avgt   30    33084.699 ?     53.530  ns/op
SegmentBulkFill.nativeSegmentFillJava          16777216  avgt   30   298953.004 ?  11241.262  ns/op
SegmentBulkFill.nativeSegmentFillJava         134217728  avgt   30  2857973.939 ? 128453.291  ns/op


Patch:

Benchmark                              (ELEM_SIZE)  Mode  Cnt  Score   Error  Units
SegmentBulkFill.nativeSegmentFillJava            2  avgt   30  1.322 ? 0.020  ns/op
SegmentBulkFill.nativeSegmentFillJava            3  avgt   30  1.313 ? 0.009  ns/op
SegmentBulkFill.nativeSegmentFillJava            4  avgt   30  1.323 ? 0.023  ns/op
SegmentBulkFill.nativeSegmentFillJava            5  avgt   30  1.309 ? 0.006  ns/op
SegmentBulkFill.nativeSegmentFillJava            6  avgt   30  1.310 ? 0.017  ns/op
SegmentBulkFill.nativeSegmentFillJava            7  avgt   30  1.308 ? 0.004  ns/op
SegmentBulkFill.nativeSegmentFillJava            8  avgt   30  1.312 ? 0.008  ns/op
SegmentBulkFill.nativeSegmentFillJava           12  avgt   30  1.316 ? 0.025  ns/op
SegmentBulkFill.nativeSegmentFillJava           64  avgt   30  3.829 ? 0.199  ns/op
SegmentBulkFill.nativeSegmentFillJava          512  avgt   30  6.661 ? 0.077  ns/op



![image](https://github.com/user-attachments/assets/69462223-e967-4d37-b7fd-ac47d0e04db9)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2900966164

From jpai at openjdk.org  Thu May 22 12:07:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 12:07:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
Message-ID: <RUyLs4AwH_FS7xWpby1AcVIGD5qelx9JlK-kY-L0npE=.a3323f76-79e5-4f52-b7cc-d6e73beb7366@github.com>

On Thu, 22 May 2025 01:29:12 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Validator to take a file, use term JAR file

Hello Henry, thank you for this enhancement. Overall this looks very good to me, especially because the validation code is concise and very cleanly done. I only had some nits and minor clarifications in this review.

Some parts of the test (like the usage of ISO_8859_1 charset) isn't clear to me, so I'll come back to that later. I'll focus on the CSR review now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24430#issuecomment-2900987846

From duke at openjdk.org  Thu May 22 12:18:53 2025
From: duke at openjdk.org (duke)
Date: Thu, 22 May 2025 12:18:53 GMT
Subject: RFR: 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java
 test scenario to run as manual [v2]
In-Reply-To: <XXnGCB8v8vhQFa4V6SzhO8N9ORlD5zjSrJpNzNQ7ViI=.ab9023b3-1c70-4e29-be87-6f7f2dc2d7f1@github.com>
References: <IMl8opuemVxRGiD46GfPuh0eZ1d6R86xkOdc3HIsT1I=.228f1873-ee56-4c22-919b-afd86dc8cc20@github.com>
 <XXnGCB8v8vhQFa4V6SzhO8N9ORlD5zjSrJpNzNQ7ViI=.ab9023b3-1c70-4e29-be87-6f7f2dc2d7f1@github.com>
Message-ID: <jF59H1wdH_Wjr_FyePCTRCfMJAIFkLfblJxGdyRNv58=.a49a4800-b1a2-44dc-a334-c52cb4669e69@github.com>

On Thu, 22 May 2025 08:31:06 GMT, serhiysachkov <duke at openjdk.org> wrote:

>> Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual
>
> serhiysachkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357462: copyright update

@serhiysachkov 
Your change (at version 43bf37b5545866752925ca521b0477aa2babd60e) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25355#issuecomment-2901017733

From liach at openjdk.org  Thu May 22 12:27:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 May 2025 12:27:02 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message [v5]
In-Reply-To: <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com>
Message-ID: <OijbLJIz8v00LipXfBnYyND1n7LHRgKY1CJ7UYK_grI=.37854405-655e-4af8-8a3d-dc831469a1c9@github.com>

On Tue, 20 May 2025 10:54:44 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

>> 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 two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
>  - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

There's a Hotspot Development section in the guide, maybe we need one for Java development that talks about IDE and such too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2901039155

From lancea at openjdk.org  Thu May 22 12:27:56 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 22 May 2025 12:27:56 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <Y6YssGqbUHJfl3FqvtPzcyYTW4_XTFrcOZPKkuxgkT4=.e6063750-748a-48f6-97cc-bddfdf3ab345@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
 <n8AVnZgFi-yV_dQL5eYZziuYRjTbIlImqi9NIMXQR1E=.62a1b4e4-7007-4416-8c03-e214585cb0d1@github.com>
 <LpPzYllXtGll6AEKQKoDBDbLswCKJR8rX399QEN_io0=.47f59052-f118-4638-8a45-b3b99846e897@github.com>
 <XrVT-vsFLSEx-ksEcz3Ss5km3jdoGiltBwQLhMVwHPg=.f42a0192-9194-45c8-bb1f-7bbc8fa70775@github.com>
 <Y6YssGqbUHJfl3FqvtPzcyYTW4_XTFrcOZPKkuxgkT4=.e6063750-748a-48f6-97cc-bddfdf3ab345@github.com>
Message-ID: <FdmZ0Yn1Kb7B9wbxj2Opih3t77PRtdhzOpHYSI8hYB0=.7fac95dc-f972-4777-b63c-6958df66a6d4@github.com>

On Thu, 22 May 2025 01:46:40 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> I use exit code, but still keep non-zero instead of > 0. Leave that to future work if we want to have more specific value for exit code for different situations.
>
> Non-zero could also mean negative which we currently do not do nor do,I see that going forward as part of future additions to validate

We are somewhat inconsistent in documenting the exit code from our commands as many do not include any mention

A few for reference

**java command**:

> The following exit values are typically returned by the launcher when the launcher is called with the wrong arguments, serious errors, or exceptions thrown by the JVM. However, a Java application may choose to return any value by using the API call System.exit(exitValue). The values are:

    0: Successful completion

    >0: An error occurred

**jarsigner command**:

>  If there is a failure, the jarsigner command exits with code 1. If there is no failure, but there are one or more severe warnings, the jarsigner command exits with code 0 when the -strict option is not specified, or exits with the OR-value of the warning codes when the -strict is specified. If there is only informational warnings or no warning at all, the command always exits with code 0.

See https://docs.oracle.com/en/java/javase/24/docs/specs/man/jarsigner.html#errors-and-warnings for the full details

**jshell command**:

> /exit [integer-expression-snippet]
>     Exits the tool. If no snippet is entered, the exit status is zero. If a snippet is entered and the result of the snippet is an integer, the result is used as the exit status. If an error occurs, or the result of the snippet is not an integer, an error is displayed and the tool remains active. 

`% jshell
|  Welcome to JShell -- Version 22.0.1
|  For an introduction type: /help intro

jshell> System.out.print("hi");
hi
jshell> /exit 1
|  Goodbye (1)
 % echo $?
1
`
So,  currently, the jdk commands use either:

- exit code
- exit value
- exit status
- exit with code

I would probably go with either "exit status" or "exit value"

And as I mentioned in a prior comment we should move away from non-zero and use either '>0' as java and several unix based commands do or use "greater than 0"

**Note:**
Other several commands such as jdeperscan do not specify the exit status value and I think we need to document the possible exit status values for the jdk commands and perhaps target this for jdk 26

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102431539

From syan at openjdk.org  Thu May 22 12:33:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 22 May 2025 12:33:01 GMT
Subject: RFR: 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java
 test scenario to run as manual [v2]
In-Reply-To: <XXnGCB8v8vhQFa4V6SzhO8N9ORlD5zjSrJpNzNQ7ViI=.ab9023b3-1c70-4e29-be87-6f7f2dc2d7f1@github.com>
References: <IMl8opuemVxRGiD46GfPuh0eZ1d6R86xkOdc3HIsT1I=.228f1873-ee56-4c22-919b-afd86dc8cc20@github.com>
 <XXnGCB8v8vhQFa4V6SzhO8N9ORlD5zjSrJpNzNQ7ViI=.ab9023b3-1c70-4e29-be87-6f7f2dc2d7f1@github.com>
Message-ID: <vq9SqgBALLOq7BWy5zcaLTk5TCYw7IFQ2Ndva0J0TIk=.5b513018-86e5-4b83-b270-63513dd7803d@github.com>

On Thu, 22 May 2025 08:31:06 GMT, serhiysachkov <duke at openjdk.org> wrote:

>> Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual
>
> serhiysachkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357462: copyright update

LGTM

-------------

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25355#pullrequestreview-2861037754

From duke at openjdk.org  Thu May 22 12:33:02 2025
From: duke at openjdk.org (serhiysachkov)
Date: Thu, 22 May 2025 12:33:02 GMT
Subject: Integrated: 8357462: Amend open/test/jdk//java/foreign/TestMatrix.java
 test scenario to run as manual
In-Reply-To: <IMl8opuemVxRGiD46GfPuh0eZ1d6R86xkOdc3HIsT1I=.228f1873-ee56-4c22-919b-afd86dc8cc20@github.com>
References: <IMl8opuemVxRGiD46GfPuh0eZ1d6R86xkOdc3HIsT1I=.228f1873-ee56-4c22-919b-afd86dc8cc20@github.com>
Message-ID: <_f_SVjwteOc31dkU8Yl0UASgVgHWKx69jSeNg62MneQ=.4b70e59f-1f1f-45be-98f5-04095297d75e@github.com>

On Wed, 21 May 2025 13:44:09 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual

This pull request has now been integrated.

Changeset: 428d33ef
Author:    Serhiy Sachkov <serhiy.sachkov at oracle.com>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/428d33ef3ca0af34d8f164fe9d9b722e81e866a7
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8357462: Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as manual

Reviewed-by: jvernee, syan

-------------

PR: https://git.openjdk.org/jdk/pull/25355

From rriggs at openjdk.org  Thu May 22 13:18:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 May 2025 13:18:56 GMT
Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(),
 use FD_CLOEXEC instead of close()
In-Reply-To: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
References: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
Message-ID: <rSf9A3pItARM1pSc5T5cVfozNyJuj4lntC_4-i_C04U=.ba5be4a6-a8da-4263-9160-d1fe7a51581b@github.com>

On Mon, 19 May 2025 12:23:07 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi, please consider the following patch.
> 
> This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc.
> 
> This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens).
> 
> Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409
> 
> This patch also fixes two subtle bugs:
> - we didn't check the return value of the close() inside closeAllFileDescriptors
> - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it)
> 
> ----
> 
> Testing:
> 
> We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC.
> 
> - in the parent JVM, the test opens a file in native code without FD_CLOEXEC
> - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open
> 
> I verified that the test correctly detects a broken implementation that leaks file descriptors. 
> 
> I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX).
> 
> I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green.

Leaving it to 26 is good.  One review is ok.  
If we were pushing for JDK 25, a second review would be warranted.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25301#issuecomment-2901193939

From pminborg at openjdk.org  Thu May 22 13:46:57 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 22 May 2025 13:46:57 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message [v5]
In-Reply-To: <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com>
Message-ID: <MPdjAHT-b5vcizjlII3vCMKQGZzM9EMsNVkUKbZ7L_U=.12684ba2-4eac-4d64-95be-e22ef663b736@github.com>

On Tue, 20 May 2025 10:54:44 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

>> 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 two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
>  - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

Looks good to me.

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23050#pullrequestreview-2861300123

From vklang at openjdk.org  Thu May 22 14:22:58 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 22 May 2025 14:22:58 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message
In-Reply-To: <7IXvN9Kkr1UqkczbU3DqFZK4aAnFPpysfEPoouqWdds=.fa401d16-3d5e-4d48-aec5-8a336afac317@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <AnrjLD7rJwg1dT8fNc5XMs8rqhSlLxIPNPk27zZtN7k=.34540e60-36c4-4c98-9a11-668fff434160@github.com>
 <3C_11D3AR_qG3ifDbWztlzhD8rZyultJEKh_89wWN1M=.5af79488-6978-4f80-a07e-b4c38139b390@github.com>
 <7IXvN9Kkr1UqkczbU3DqFZK4aAnFPpysfEPoouqWdds=.fa401d16-3d5e-4d48-aec5-8a336afac317@github.com>
Message-ID: <KJmJxmvC7oKpg4Iz02aWdQze8D7Bye4DJB6LZ0HRJJo=.bcc1765f-6dcd-438a-bae0-d92a74703423@github.com>

On Thu, 22 May 2025 02:09:08 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

>> @He-Pin Just pinging you here, in case the notification from my most recent comments got lost in transit.
>
> @viktorklang-ora @liach, I think we need a contribution guide that explains how to set up the work in the IDE, how to perform tests, etc.

@He-Pin This PR is now ready to integrate, type "/integrate" (without the quotes) as a comment on this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2901412915

From vklang at openjdk.org  Thu May 22 14:24:28 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 22 May 2025 14:24:28 GMT
Subject: RFR: 8357285 : JSR166 Test case testShutdownNow_delayedTasks failed
Message-ID: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com>

Barring other effects, it is likely that this test just needs to have some longer timeouts to ensure that a stall isn't likely to fail the test case. The shouldn't have any impact on test execution duration, as the test looks at tasks which *have not executed yet*.

-------------

Commit messages:
 - Addressing a potential stall-induced test failure in ScheduledExecutorTest::testShutdownNow_delayedTasks

Changes: https://git.openjdk.org/jdk/pull/25394/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25394&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357285
  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25394.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25394/head:pull/25394

PR: https://git.openjdk.org/jdk/pull/25394

From liach at openjdk.org  Thu May 22 14:27:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 May 2025 14:27:59 GMT
Subject: RFR: 8357165: test java/lang/invoke/ClassValueTest.java fails
 intermittently [v2]
In-Reply-To: <_Y8b69_yD3zF4kpqW3StHZ5p8E1XSNOmZOcs3Qyy6IE=.665c0ab8-ebeb-434e-b725-43a50e4f3eb1@github.com>
References: <i1B1gJuokz34xZAlURjip2LvwLnx7bCE04Ye3H3F7-g=.aa67b2d1-3dff-4be3-8250-49ab6ce5aad6@github.com>
 <_Y8b69_yD3zF4kpqW3StHZ5p8E1XSNOmZOcs3Qyy6IE=.665c0ab8-ebeb-434e-b725-43a50e4f3eb1@github.com>
Message-ID: <3dPOJ8aiXq0RrawctSyoDLc_UWh5fYfR_n8NmLsr8b0=.0f48dfdd-b916-4d8f-8683-2b099b3454e0@github.com>

On Wed, 21 May 2025 17:09:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The test was originally written with product builds in mind; it didn't consider the slowness of debug builds, thus causing tests to fail.
>> 
>> Also there was a bug in testWeakAgainstClassValue: the test need to flush the backing map in the class to have the weak value removed. It is fixed in this patch as well.
>> 
>> Testing: ClassValueTest repeated 10 times on windows-x64/linux-x64/macosx-aarch64/linux-aarch64 fastdebug.
>
> 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:
> 
>  - Increase timeout, add comment for adjust for debugging
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cv-test-problems
>  - Restore incorrectly removed annotation
>  - Fix problems with class value tests

The failing tier 1 tests on GitHub are gc ones. Thanks for the reviews! I think we are good to go.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25292#issuecomment-2901426835

From liach at openjdk.org  Thu May 22 14:28:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 May 2025 14:28:00 GMT
Subject: Integrated: 8357165: test java/lang/invoke/ClassValueTest.java fails
 intermittently
In-Reply-To: <i1B1gJuokz34xZAlURjip2LvwLnx7bCE04Ye3H3F7-g=.aa67b2d1-3dff-4be3-8250-49ab6ce5aad6@github.com>
References: <i1B1gJuokz34xZAlURjip2LvwLnx7bCE04Ye3H3F7-g=.aa67b2d1-3dff-4be3-8250-49ab6ce5aad6@github.com>
Message-ID: <GTO2L3WgFZuj-ycN6-spRXSUmkojEC9Am1X8qnseY_A=.e22cc54b-9d37-401a-93df-6c4de2c9015c@github.com>

On Sun, 18 May 2025 21:58:04 GMT, Chen Liang <liach at openjdk.org> wrote:

> The test was originally written with product builds in mind; it didn't consider the slowness of debug builds, thus causing tests to fail.
> 
> Also there was a bug in testWeakAgainstClassValue: the test need to flush the backing map in the class to have the weak value removed. It is fixed in this patch as well.
> 
> Testing: ClassValueTest repeated 10 times on windows-x64/linux-x64/macosx-aarch64/linux-aarch64 fastdebug.

This pull request has now been integrated.

Changeset: 12efc1fe
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/12efc1fe3322d16f0e703b334912241d80dbaba9
Stats:     15 lines in 1 file changed: 6 ins; 6 del; 3 mod

8357165: test java/lang/invoke/ClassValueTest.java fails intermittently

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/25292

From myankelevich at openjdk.org  Thu May 22 14:57:55 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 22 May 2025 14:57:55 GMT
Subject: RFR: 8357285 : JSR166 Test case testShutdownNow_delayedTasks
 failed
In-Reply-To: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com>
References: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com>
Message-ID: <EP6kUN_8tAz5PPBv5dFwnc2DUENWfmZErOuzDONpOQs=.da9e8d34-1b54-40ab-b67a-0be33e9e2a52@github.com>

On Thu, 22 May 2025 14:19:09 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Barring other effects, it is likely that this test just needs to have some longer timeouts to ensure that a stall isn't likely to fail the test case. The shouldn't have any impact on test execution duration, as the test looks at tasks which *have not executed yet*.

test/jdk/java/util/concurrent/tck/ScheduledExecutorTest.java line 703:

> 701:         final ScheduledThreadPoolExecutor p = new ScheduledThreadPoolExecutor(1);
> 702:         List<ScheduledFuture<?>> tasks = new ArrayList<>();
> 703:         final int DELAY = 100;

What do you think of trying to change this to `Utils.adjustTimeout(100)` so the env could change this depending on the factor used? This way may be the delay won't need to be as large.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25394#discussion_r2102774011

From vklang at openjdk.org  Thu May 22 15:02:53 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 22 May 2025 15:02:53 GMT
Subject: RFR: 8357285 : JSR166 Test case testShutdownNow_delayedTasks
 failed
In-Reply-To: <EP6kUN_8tAz5PPBv5dFwnc2DUENWfmZErOuzDONpOQs=.da9e8d34-1b54-40ab-b67a-0be33e9e2a52@github.com>
References: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com>
 <EP6kUN_8tAz5PPBv5dFwnc2DUENWfmZErOuzDONpOQs=.da9e8d34-1b54-40ab-b67a-0be33e9e2a52@github.com>
Message-ID: <KwynBdbgauVsdAxa6DO99vN1TqC8fUOMR39X-GlyVK0=.a83c6a2e-4e61-4db5-b6a7-21eaf7900802@github.com>

On Thu, 22 May 2025 14:55:21 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Barring other effects, it is likely that this test just needs to have some longer timeouts to ensure that a stall isn't likely to fail the test case. The shouldn't have any impact on test execution duration, as the test looks at tasks which *have not executed yet*.
>
> test/jdk/java/util/concurrent/tck/ScheduledExecutorTest.java line 703:
> 
>> 701:         final ScheduledThreadPoolExecutor p = new ScheduledThreadPoolExecutor(1);
>> 702:         List<ScheduledFuture<?>> tasks = new ArrayList<>();
>> 703:         final int DELAY = 100;
> 
> What do you think of trying to change this to `Utils.adjustTimeout(100)` so the env could change this depending on the factor used? This way may be the delay won't need to be as large.

@myankelev The tasks are not expected to run, so the delay does not impact the duration of the test execution. The problem is rather that if they *do run* that the test fails, so if we move the delay further into the future, the test is less prone to failing spuriously.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25394#discussion_r2102782380

From aph at openjdk.org  Thu May 22 15:09:12 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 22 May 2025 15:09:12 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v8]
In-Reply-To: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
Message-ID: <-C0JVzsxoQlBvSZWfee6q1s18AkI0NVQVEMvEhkN5Og=.96872ba4-4d2e-450a-8c10-b789911b45fc@github.com>

> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a null argument.

Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge from JDK head
 - Fix merge
 - Fix merge
 - Merge from https://github.com/openjdk/jdk
 - ScopedValue::orElse() does not accept null as an argument.
 - Remove unnecessary @since 25
 - Remove unnecessary @enablePreview in some tests
 - Since when?
 - ScopedValue::orElse() does not accept null as an argument.
 - 8355720: Implement JEP 506: Scoped Values
 - ... and 1 more: https://git.openjdk.org/jdk/compare/12efc1fe...460d82bd

-------------

Changes: https://git.openjdk.org/jdk/pull/24923/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=07
  Stats: 21 lines in 6 files changed: 3 ins; 12 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24923/head:pull/24923

PR: https://git.openjdk.org/jdk/pull/24923

From nbenalla at openjdk.org  Thu May 22 15:18:43 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 22 May 2025 15:18:43 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base [v2]
In-Reply-To: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
Message-ID: <BxNtnccz3zlXcl_eEDKL0Z92RiSSvlvnNhb28tCh8zQ=.9a9d8fbf-8479-4078-9a00-2200b0fc3377@github.com>

> Please review this patch to fix some `javadoc` bugs in `java.base`.
> Certain `@link` tags used to refer to private fields instead of public APIs.
> 
> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
> 
> TIA

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  revert changes to MethodType.java. <code>foo</code> markup should not be used

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25287/files
  - new: https://git.openjdk.org/jdk/pull/25287/files/b17b55fa..0653af94

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25287&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25287&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25287.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25287/head:pull/25287

PR: https://git.openjdk.org/jdk/pull/25287

From henryjen at openjdk.org  Thu May 22 15:29:36 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 22 May 2025 15:29:36 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v13]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <7jkcv3sSX-L6EA-0JGC4cJE-u-_0cOzrwRJJ0ZTK2N4=.969da667-e338-44ec-9f93-7c989c47c9b9@github.com>

> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Assure >0 exit code and fix typos

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/52af70aa..5118aba4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=11-12

  Stats: 18 lines in 3 files changed: 2 ins; 4 del; 12 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 smarks at openjdk.org  Thu May 22 16:18:52 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 22 May 2025 16:18:52 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <54Ipy5980SJ3mqt5isPw1n4TNQnO7hH7DOlgLg3TSDI=.62f6bb57-278f-40b3-88d2-9f9a8a2031bb@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <lErNIJyBSEaDtbZk91B6GQtqHc0o2qqGOaI-MH0r5ns=.404cffc7-5422-4b1d-b081-48bb8b9cf67a@github.com>
 <fl9VCx915VdNP3Bk-y4znN3OUM7_sfRJc5XMBHKf0Sk=.19862ac2-2908-424b-afd1-7939b9c0f79e@github.com>
 <54Ipy5980SJ3mqt5isPw1n4TNQnO7hH7DOlgLg3TSDI=.62f6bb57-278f-40b3-88d2-9f9a8a2031bb@github.com>
Message-ID: <UQT--71wmu1YGNVS6pc9KgdWFh209uGDpwb7GRkEp9w=.06799f2c-72f1-4919-8f12-5bce814e60d4@github.com>

On Wed, 21 May 2025 16:48:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 67:
>> 
>>> 65:  * stdout.encoding}, in which case read operations use the {@code Charset}
>>> 66:  * designated by {@code stdin.encoding}.
>>> 67:  * <p>
>> 
>> `Console.charset()` states "The returned charset is used for interpreting the input and output source (e.g., keyboard and/or display) specified by the host environment or user, which defaults to the one based on stdout.encoding." If _stdin.encoding_ is set otherwise, this is no longer true, so I think this method may need a wording update as well.
>
> Good point. Brought the same wording to the `charset()` method description for further clarification.

I'm confused by the actual behavior here. What might be helpful is to divide the discussion between a) what charsets get used for input and output, and b) the return value of the `charset()` method.

I'm not entirely sure, but since `stdin.encoding` and `stdout.encoding` are always set to something -- whether it comes from the platform or the command line -- won't Console just use `stdin.encoding` for input and `stdout.encoding` for output? If this is true, maybe just say this instead of deferring to the `charset()` method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2102946359

From alanb at openjdk.org  Thu May 22 16:28:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 May 2025 16:28:52 GMT
Subject: RFR: 8357285 : JSR166 Test case testShutdownNow_delayedTasks
 failed
In-Reply-To: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com>
References: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com>
Message-ID: <wWE7F73JwodhogEMy__GhOZBfGAznbkzQGCTN6q9tTA=.0ee1fa2c-4922-4752-8482-03cb6d3f8bba@github.com>

On Thu, 22 May 2025 14:19:09 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Barring other effects, it is likely that this test just needs to have some longer timeouts to ensure that a stall isn't likely to fail the test case. The shouldn't have any impact on test execution duration, as the test looks at tasks which *have not executed yet*.

I think this looks okay and I assume you've testing with debug and -Xcomp to be confident that the tasks will never run.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25394#pullrequestreview-2861875933

From henryjen at openjdk.org  Thu May 22 16:33:53 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 22 May 2025 16:33:53 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <FdmZ0Yn1Kb7B9wbxj2Opih3t77PRtdhzOpHYSI8hYB0=.7fac95dc-f972-4777-b63c-6958df66a6d4@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
 <n8AVnZgFi-yV_dQL5eYZziuYRjTbIlImqi9NIMXQR1E=.62a1b4e4-7007-4416-8c03-e214585cb0d1@github.com>
 <LpPzYllXtGll6AEKQKoDBDbLswCKJR8rX399QEN_io0=.47f59052-f118-4638-8a45-b3b99846e897@github.com>
 <XrVT-vsFLSEx-ksEcz3Ss5km3jdoGiltBwQLhMVwHPg=.f42a0192-9194-45c8-bb1f-7bbc8fa70775@github.com>
 <Y6YssGqbUHJfl3FqvtPzcyYTW4_XTFrcOZPKkuxgkT4=.e6063750-748a-48f6-97cc-bddfdf3ab345@github.com>
 <FdmZ0Yn1Kb7B9wbxj2Opih3t77PRtdhzOpHYSI8hYB0=.7fac95dc-f972-4777-b63c-6958df66a6d4@github.com>
Message-ID: <QUVrTBpKTKhxqc8eB2cW5D47FbCE3JjKTypbUYs-dog=.64c39624-5b44-4f2c-b047-d7d75959c06f@github.com>

On Thu, 22 May 2025 12:25:04 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Non-zero could also mean negative which we currently do not do nor do,I see that going forward as part of future additions to validate
>
> We are somewhat inconsistent in documenting the exit code from our commands as many do not include any mention
> 
> A few for reference
> 
> **java command**:
> 
>> The following exit values are typically returned by the launcher when the launcher is called with the wrong arguments, serious errors, or exceptions thrown by the JVM. However, a Java application may choose to return any value by using the API call System.exit(exitValue). The values are:
> 
>     0: Successful completion
> 
>     >0: An error occurred
> 
> **jarsigner command**:
> 
>>  If there is a failure, the jarsigner command exits with code 1. If there is no failure, but there are one or more severe warnings, the jarsigner command exits with code 0 when the -strict option is not specified, or exits with the OR-value of the warning codes when the -strict is specified. If there is only informational warnings or no warning at all, the command always exits with code 0.
> 
> See https://docs.oracle.com/en/java/javase/24/docs/specs/man/jarsigner.html#errors-and-warnings for the full details
> 
> **jshell command**:
> 
>> /exit [integer-expression-snippet]
>>     Exits the tool. If no snippet is entered, the exit status is zero. If a snippet is entered and the result of the snippet is an integer, the result is used as the exit status. If an error occurs, or the result of the snippet is not an integer, an error is displayed and the tool remains active. 
> 
> `% jshell
> |  Welcome to JShell -- Version 22.0.1
> |  For an introduction type: /help intro
> 
> jshell> System.out.print("hi");
> hi
> jshell> /exit 1
> |  Goodbye (1)
>  % echo $?
> 1
> `
> So,  currently, the jdk commands use either:
> 
> - exit code
> - exit value
> - exit status
> - exit with code
> 
> I would probably go with either "exit status" or "exit value"
> 
> And as I mentioned in a prior comment we should move away from non-zero and use either '>0' as java and several unix based commands do or use "greater than 0"
> 
> **Note:**
> Other several commands such as jdeperscan do not specify the exit status value and I think we need to document the possible exit status values for the jdk commands and perhaps target this for jdk 26

For noun and verb, seems we have exit code and exit with code. Do we want to use status instead of code?
I don't have a preference as long as we can agree to one.
exit status and exit with status?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102974569

From alanb at openjdk.org  Thu May 22 16:42:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 May 2025 16:42:54 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <UQT--71wmu1YGNVS6pc9KgdWFh209uGDpwb7GRkEp9w=.06799f2c-72f1-4919-8f12-5bce814e60d4@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <lErNIJyBSEaDtbZk91B6GQtqHc0o2qqGOaI-MH0r5ns=.404cffc7-5422-4b1d-b081-48bb8b9cf67a@github.com>
 <fl9VCx915VdNP3Bk-y4znN3OUM7_sfRJc5XMBHKf0Sk=.19862ac2-2908-424b-afd1-7939b9c0f79e@github.com>
 <54Ipy5980SJ3mqt5isPw1n4TNQnO7hH7DOlgLg3TSDI=.62f6bb57-278f-40b3-88d2-9f9a8a2031bb@github.com>
 <UQT--71wmu1YGNVS6pc9KgdWFh209uGDpwb7GRkEp9w=.06799f2c-72f1-4919-8f12-5bce814e60d4@github.com>
Message-ID: <ZE50hIJllKprRDuiyPyKjOFxIjTRV2xkQmPnuP_6400=.799194ca-f7fc-4184-97af-d10b5f490df1@github.com>

On Thu, 22 May 2025 16:15:56 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Good point. Brought the same wording to the `charset()` method description for further clarification.
>
> I'm confused by the actual behavior here. What might be helpful is to divide the discussion between a) what charsets get used for input and output, and b) the return value of the `charset()` method.
> 
> I'm not entirely sure, but since `stdin.encoding` and `stdout.encoding` are always set to something -- whether it comes from the platform or the command line -- won't Console just use `stdin.encoding` for input and `stdout.encoding` for output? If this is true, maybe just say this instead of deferring to the `charset()` method.

I think I agree with Stuart and it would be better to say that stdin.encoding is used for reading, and stdout.encoding for writing. They are usually the same but if they differ then Console will return the charset for output.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2102987344

From liach at openjdk.org  Thu May 22 16:44:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 May 2025 16:44:56 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v8]
In-Reply-To: <-C0JVzsxoQlBvSZWfee6q1s18AkI0NVQVEMvEhkN5Og=.96872ba4-4d2e-450a-8c10-b789911b45fc@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <-C0JVzsxoQlBvSZWfee6q1s18AkI0NVQVEMvEhkN5Og=.96872ba4-4d2e-450a-8c10-b789911b45fc@github.com>
Message-ID: <xxXxqXoD0dD9lqjG4ywuuqk60O02tiUBj5dABZW8R78=.85f07e31-9cef-4acd-a471-6afa006cc4d9@github.com>

On Thu, 22 May 2025 15:09:12 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge from JDK head
>  - Fix merge
>  - Fix merge
>  - Merge from https://github.com/openjdk/jdk
>  - ScopedValue::orElse() does not accept null as an argument.
>  - Remove unnecessary @since 25
>  - Remove unnecessary @enablePreview in some tests
>  - Since when?
>  - ScopedValue::orElse() does not accept null as an argument.
>  - 8355720: Implement JEP 506: Scoped Values
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/12efc1fe...460d82bd

The latest master merge looks good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24923#pullrequestreview-2861915865

From jlu at openjdk.org  Thu May 22 16:46:10 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 May 2025 16:46:10 GMT
Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable [v2]
In-Reply-To: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
Message-ID: <zpJcyPtB6YksaXYN1Y1EZiQYQmeNvumnJzMXngZwGqg=.a8ea90c9-ecef-42a6-aa7a-37d204d6bf09@github.com>

> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25371/files
  - new: https://git.openjdk.org/jdk/pull/25371/files/ed0acc44..2d778a85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25371&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25371&range=00-01

  Stats: 63 lines in 1 file changed: 12 ins; 16 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/25371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25371/head:pull/25371

PR: https://git.openjdk.org/jdk/pull/25371

From jlu at openjdk.org  Thu May 22 16:46:10 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 May 2025 16:46:10 GMT
Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable
In-Reply-To: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
Message-ID: <lwC-d3WZ1heW8dejDp5buSQVlMKPB7lZ4MJI-OfXJDA=.8e1b22df-d61d-4eee-b329-44f83602fa8b@github.com>

On Wed, 21 May 2025 21:19:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.

Comments addressed in https://github.com/openjdk/jdk/pull/25371/commits/2d778a85ebff14e5080a15556083c3e16986edf4. Chen, that's a good point, those getters are fragile. I opted to maintain the unmodifiable quality of the list fields, this code isn't perf sensitive and is more predictable this way. I wrapped the lists during parsing so we can drop overriding the getters altogether.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25371#issuecomment-2901903043

From jrose at openjdk.org  Thu May 22 16:49:52 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 22 May 2025 16:49:52 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v5]
In-Reply-To: <kBtT8hpgfy9e9OBLI8_5S9PBsuVmqBuTB_NcoZIwoMA=.78786b50-55ab-4604-9dbd-87f27fcdc575@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <kBtT8hpgfy9e9OBLI8_5S9PBsuVmqBuTB_NcoZIwoMA=.78786b50-55ab-4604-9dbd-87f27fcdc575@github.com>
Message-ID: <vGZhI7J1Sq0sJ_pHtngO62bAK8ae29A5nPBF1eEjJOs=.b254d305-7372-4550-b402-443ff90e6f08@github.com>

On Thu, 22 May 2025 11:52:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
>> 
>> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
>> 
>> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update benchmark to reflect new fill method

Very cool!  I'm glad it worked.  This came out of some background work I was doing to find fast ways to feed a vectorized loop over an input measured in bytes (any number of them).

https://cr.openjdk.org/~jrose/jvm/PartialMemoryWord.cpp

The corresponding read technique works quite well, also.  It has the property that (if you combine the partial overlapping reads correctly) that each byte is read exactly once, which might be a good property for building concurrent data structures.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2901911070

From henryjen at openjdk.org  Thu May 22 17:08:58 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 22 May 2025 17:08:58 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <9eBVY2wfBH5n4aochz0yfDxWub3LmS_nVW0LlUugzkw=.bccb2195-704f-4b95-8fb1-3070a3174090@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
 <9eBVY2wfBH5n4aochz0yfDxWub3LmS_nVW0LlUugzkw=.bccb2195-704f-4b95-8fb1-3070a3174090@github.com>
Message-ID: <OmcAMI0zi3jVHHqpJA09UtEFddb22ZaIyBCi4hYOF14=.4023b9b4-f03c-417f-b964-afb2da98abf3@github.com>

On Thu, 22 May 2025 11:42:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Validator to take a file, use term JAR file
>
> test/jdk/tools/jar/ValidatorTest.java line 60:
> 
>> 58: import jdk.test.lib.util.FileUtils;
>> 59: 
>> 60: @TestInstance(Lifecycle.PER_CLASS)
> 
> I haven't seen this used commonly in our tests. Is there something specific in this test that requires this usage?

I take this in as other jar tests. I think it's because we used to share the ZIP file between tests. I believe I can remove it for this test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2103031299

From duke at openjdk.org  Thu May 22 17:11:08 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Thu, 22 May 2025 17:11:08 GMT
Subject: Integrated: 8352926: New test TestDockerMemoryMetricsSubgroup.java
 fails
In-Reply-To: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
References: <n9WEIm7wAj_dWGxoT9TUdxUy1QQohH_oivPQAp_PzNU=.d9e542ed-ccff-408d-ad16-62c185f8808e@github.com>
Message-ID: <wSvW08imr32VkbgOIHKZlckjkOedt3NrD-xZYEdbe5Y=.0f593375-80bc-416a-8fc4-a39dbf114db0@github.com>

On Tue, 29 Apr 2025 13:04:15 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails

This pull request has now been integrated.

Changeset: 9ca1004e
Author:    pawan chawdhary <pawan at dhcp-10-48-118-86.wifi.oracle.com>
Committer: Mikhailo Seledtsov <mseledtsov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ca1004e76a614328cd2eb7546143839c4d2f810
Stats:     118 lines in 3 files changed: 115 ins; 3 del; 0 mod

8352926: New test TestDockerMemoryMetricsSubgroup.java fails

Reviewed-by: mseledtsov, lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/24948

From liach at openjdk.org  Thu May 22 17:17:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 May 2025 17:17:59 GMT
Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable [v2]
In-Reply-To: <zpJcyPtB6YksaXYN1Y1EZiQYQmeNvumnJzMXngZwGqg=.a8ea90c9-ecef-42a6-aa7a-37d204d6bf09@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
 <zpJcyPtB6YksaXYN1Y1EZiQYQmeNvumnJzMXngZwGqg=.a8ea90c9-ecef-42a6-aa7a-37d204d6bf09@github.com>
Message-ID: <1dNugq-Zi17b8zchOopMRON42nzKEVet4gA01oavGhQ=.88290316-0aa7-422d-a492-a70aed44fc12@github.com>

On Thu, 22 May 2025 16:46:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors

Everything else looks good.

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 249:

> 247:             return EMPTY_SUBTAGS;
> 248:         }
> 249:         List<String> extLangs = null;

Do we want to name this `extLangs` or `extlangs`? The parsing method and the record uses `extlangs`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25371#pullrequestreview-2862000028
PR Review Comment: https://git.openjdk.org/jdk/pull/25371#discussion_r2103042373

From henryjen at openjdk.org  Thu May 22 17:22:54 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 22 May 2025 17:22:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v6]
In-Reply-To: <0880cZA9IZKMn3ctbmhkEYw_1TkFjQ6hnDQhXVq7e7E=.43ea3a53-dc89-47c6-9710-2a99d7cbf598@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <Uvb8haTDHaSUlFccwMonvOOpnMogpbjr2KpffroxpmQ=.0e863939-4729-4ab6-9d67-f276570e9084@github.com>
 <kqx3sTJHVWdZpzTKzo7Ak7bYnBJqbLD1hkkJtK4okwg=.e26d85ff-7ea4-40e1-8593-dd424a0739de@github.com>
 <BCRh35_h9tPnYU1KvHxTj7VpT4k7hfA9gTA9VdTfrrk=.5d8804f5-acfd-4e6c-b65a-cd8dbbfe5208@github.com>
 <0880cZA9IZKMn3ctbmhkEYw_1TkFjQ6hnDQhXVq7e7E=.43ea3a53-dc89-47c6-9710-2a99d7cbf598@github.com>
Message-ID: <gMQ9CguqZcifWzsRdD3V7Jbrltwikb7wB_i0zmPUYLk=.afd17030-97e3-4fe5-9fb0-650b30549ecb@github.com>

On Wed, 14 May 2025 17:27:25 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> UTF-8 messed up the index, we don't want any conversion to happen.
>> Warning: Entry META-INFMAANIFEST.MF in local file header is not in central directory
>> Warning: Entry META-INF/BANIFEST.MF in local file header is not in central directory
>> Warning: Entry METAMINF/AANIFEST.MF in central directory is not in local file header
>> Warning: Entry METAMINF/BANIFEST.MF in central directory is not in local file header
>
>> UTF-8 messed up the index, we don't want any conversion to happen. Warning: Entry META-INFMAANIFEST.MF in local file header is not in central directory Warning: Entry META-INF/BANIFEST.MF in local file header is not in central directory Warning: Entry METAMINF/AANIFEST.MF in central directory is not in local file header Warning: Entry METAMINF/BANIFEST.MF in central directory is not in local file header
> 
> Without looking into this in finer detail I am not sure what the issue is and is why the other tests typically use the actual offset to modify.

Simply put, a byte in the bytearray could be extend to more than one byte with UTF-8. The base we start to looking for the character is recorded as in the bytearray. Thus could lead we start looking at wrong place. I didn't look into exactly how this happens.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2103056825

From srl at openjdk.org  Thu May 22 17:32:53 2025
From: srl at openjdk.org (Steven Loomis)
Date: Thu, 22 May 2025 17:32:53 GMT
Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable [v2]
In-Reply-To: <zpJcyPtB6YksaXYN1Y1EZiQYQmeNvumnJzMXngZwGqg=.a8ea90c9-ecef-42a6-aa7a-37d204d6bf09@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
 <zpJcyPtB6YksaXYN1Y1EZiQYQmeNvumnJzMXngZwGqg=.a8ea90c9-ecef-42a6-aa7a-37d204d6bf09@github.com>
Message-ID: <p9avSUjfdP6Vdci9R4xHZVrxc1jEAucBbv1O07bAE1A=.c916ccac-dcf5-4ce1-8e88-99ac2e62b5cb@github.com>

On Thu, 22 May 2025 16:46:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors

@yumaoka

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25371#issuecomment-2902033974

From liach at openjdk.org  Thu May 22 17:36:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 May 2025 17:36:52 GMT
Subject: RFR: 8357178: Simplify Class::componentType [v2]
In-Reply-To: <HtEqf_NTEWnVWPfHMCzPBwoBWIwAGrwCBYWWlZzWnTo=.e989ba16-68f9-40a5-a774-82dd6dc5d292@github.com>
References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com>
 <HtEqf_NTEWnVWPfHMCzPBwoBWIwAGrwCBYWWlZzWnTo=.e989ba16-68f9-40a5-a774-82dd6dc5d292@github.com>
Message-ID: <ypB-7gxf87RAQulo52WoE5SPZye_SdQANAB3bD_GHGU=.c3094e69-0568-4c73-96f0-92b7e526fe29@github.com>

On Mon, 19 May 2025 00:22:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `isArray` and null return is now redundant when `componentType` is changed to an explicit field.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   For parity with MT.descriptorString

Can anyone review this simple cleanup?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25280#issuecomment-2902042283

From naoto at openjdk.org  Thu May 22 17:46:33 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 May 2025 17:46:33 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
Message-ID: <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>

> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects wording change suggestions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25271/files
  - new: https://git.openjdk.org/jdk/pull/25271/files/ce1c8035..75fa0a89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=03-04

  Stats: 18 lines in 1 file changed: 1 ins; 6 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/25271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25271/head:pull/25271

PR: https://git.openjdk.org/jdk/pull/25271

From naoto at openjdk.org  Thu May 22 17:48:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 May 2025 17:48:53 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <ZE50hIJllKprRDuiyPyKjOFxIjTRV2xkQmPnuP_6400=.799194ca-f7fc-4184-97af-d10b5f490df1@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <lErNIJyBSEaDtbZk91B6GQtqHc0o2qqGOaI-MH0r5ns=.404cffc7-5422-4b1d-b081-48bb8b9cf67a@github.com>
 <fl9VCx915VdNP3Bk-y4znN3OUM7_sfRJc5XMBHKf0Sk=.19862ac2-2908-424b-afd1-7939b9c0f79e@github.com>
 <54Ipy5980SJ3mqt5isPw1n4TNQnO7hH7DOlgLg3TSDI=.62f6bb57-278f-40b3-88d2-9f9a8a2031bb@github.com>
 <UQT--71wmu1YGNVS6pc9KgdWFh209uGDpwb7GRkEp9w=.06799f2c-72f1-4919-8f12-5bce814e60d4@github.com>
 <ZE50hIJllKprRDuiyPyKjOFxIjTRV2xkQmPnuP_6400=.799194ca-f7fc-4184-97af-d10b5f490df1@github.com>
Message-ID: <b__yTF1CV-NkG3fNul31WWVHpEcYqnk9BxraclK7DeA=.496bf1ab-b4db-470e-b8ee-2982c2a6af4e@github.com>

On Thu, 22 May 2025 16:39:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I'm confused by the actual behavior here. What might be helpful is to divide the discussion between a) what charsets get used for input and output, and b) the return value of the `charset()` method.
>> 
>> I'm not entirely sure, but since `stdin.encoding` and `stdout.encoding` are always set to something -- whether it comes from the platform or the command line -- won't Console just use `stdin.encoding` for input and `stdout.encoding` for output? If this is true, maybe just say this instead of deferring to the `charset()` method.
>
> I think I agree with Stuart and it would be better to say that stdin.encoding is used for reading, and stdout.encoding for writing. They are usually the same but if they differ then Console will return the charset for output.

Thanks. I reworded the descriptions of the class and `charset()` method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2103101604

From jlu at openjdk.org  Thu May 22 17:51:32 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 May 2025 17:51:32 GMT
Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable [v3]
In-Reply-To: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
Message-ID: <GYKBz2_hwn2fMhvNG_AJkhj7YoD1KdEzZ_DhdAFC44Y=.8974fb06-613f-4aa4-9235-a8cd5f2b2d03@github.com>

> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.

Justin Lu has updated the pull request with a new target base 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:

 - extLangs -> extlangs
 - Merge branch 'master' into JDK-8357281-LanguageTag
 - review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors
 - init

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25371/files
  - new: https://git.openjdk.org/jdk/pull/25371/files/2d778a85..a5429599

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25371&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25371&range=01-02

  Stats: 43668 lines in 640 files changed: 29920 ins; 10197 del; 3551 mod
  Patch: https://git.openjdk.org/jdk/pull/25371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25371/head:pull/25371

PR: https://git.openjdk.org/jdk/pull/25371

From jlu at openjdk.org  Thu May 22 17:51:33 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 May 2025 17:51:33 GMT
Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable [v2]
In-Reply-To: <1dNugq-Zi17b8zchOopMRON42nzKEVet4gA01oavGhQ=.88290316-0aa7-422d-a492-a70aed44fc12@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
 <zpJcyPtB6YksaXYN1Y1EZiQYQmeNvumnJzMXngZwGqg=.a8ea90c9-ecef-42a6-aa7a-37d204d6bf09@github.com>
 <1dNugq-Zi17b8zchOopMRON42nzKEVet4gA01oavGhQ=.88290316-0aa7-422d-a492-a70aed44fc12@github.com>
Message-ID: <sYY5p7EATxiP-xioMQgUO3VU7WCjGm8SObQsOIGkDgQ=.db27bc9a-d3c1-4b51-b518-e24f7ba3d8b9@github.com>

On Thu, 22 May 2025 17:14:03 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors
>
> src/java.base/share/classes/sun/util/locale/LanguageTag.java line 249:
> 
>> 247:             return EMPTY_SUBTAGS;
>> 248:         }
>> 249:         List<String> extLangs = null;
> 
> Do we want to name this `extLangs` or `extlangs`? The parsing method and the record uses `extlangs`.

Changed to `extlangs`, more consistent.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25371#discussion_r2103105426

From henryjen at openjdk.org  Thu May 22 17:51:43 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 22 May 2025 17:51:43 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v14]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <Xt0Q1aw4NmuzkXXJYvBOdXJroiSn5o1vyb9cityXG5U=.3b89c4a0-517c-49e5-b4b3-23120f42aa8c@github.com>

> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Minor tweaks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/5118aba4..bf82d668

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=12-13

  Stats: 7 lines in 3 files changed: 3 ins; 1 del; 3 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  Thu May 22 18:07:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 May 2025 18:07:52 GMT
Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable [v3]
In-Reply-To: <GYKBz2_hwn2fMhvNG_AJkhj7YoD1KdEzZ_DhdAFC44Y=.8974fb06-613f-4aa4-9235-a8cd5f2b2d03@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
 <GYKBz2_hwn2fMhvNG_AJkhj7YoD1KdEzZ_DhdAFC44Y=.8974fb06-613f-4aa4-9235-a8cd5f2b2d03@github.com>
Message-ID: <_QUPLEkt0lQLzNp1Z7X1UO0LGGyRH1OIJzuRnlagEbU=.361cab70-0229-45f2-add7-54599c907a77@github.com>

On Thu, 22 May 2025 17:51:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.
>
> Justin Lu has updated the pull request with a new target base 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:
> 
>  - extLangs -> extlangs
>  - Merge branch 'master' into JDK-8357281-LanguageTag
>  - review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors
>  - init

This version looks much better. You might want the original author Yoshito or another I18N reviewer to check too.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25371#pullrequestreview-2862145268

From zuniquex at protonmail.com  Thu May 22 18:12:17 2025
From: zuniquex at protonmail.com (=?utf-8?Q?Steffen_Nie=C3=9Fing?=)
Date: Thu, 22 May 2025 18:12:17 +0000
Subject: Missing throws declaration for NullPointerException in
 Proxy#getInvocationHandler
Message-ID: <2RhljdZeTpLum8FCZd7FjVqkQ0xaVJQGKC2-KYnObX6Jeij1T-DCTausYHVuZqBMK17_T26kaeS75Tr9qAdX7geh-pSfw6bQxTxayu5c6Ko=@protonmail.com>

Hi,

recently I've come across the documentation of Proxy#getInvocationHandler(Object) and recognized that there's a missing throws declaration for a NullPointerException. The expression Proxy.getInvocationHandler(null) fails, because proxy.getClass() is called without asserting that proxy is not null.

I'd be happy to provide the JavaDoc update, if anyone would like to sponsor me the JBS issue for this one.

Cheers
Steffen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250522/e20ce70f/attachment.htm>

From liach at openjdk.org  Thu May 22 18:24:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 May 2025 18:24:51 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base [v2]
In-Reply-To: <BxNtnccz3zlXcl_eEDKL0Z92RiSSvlvnNhb28tCh8zQ=.9a9d8fbf-8479-4078-9a00-2200b0fc3377@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
 <BxNtnccz3zlXcl_eEDKL0Z92RiSSvlvnNhb28tCh8zQ=.9a9d8fbf-8479-4078-9a00-2200b0fc3377@github.com>
Message-ID: <2NivjYQr_KiIrdCorX_x68nTNHezBA1qKvhjaDknI1E=.5da267a6-125d-49bf-9de3-4eaf9afbfcd6@github.com>

On Thu, 22 May 2025 15:18:43 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch to fix some `javadoc` bugs in `java.base`.
>> Certain `@link` tags used to refer to private fields instead of public APIs.
>> 
>> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to MethodType.java. <code>foo</code> markup should not be used

Changes to MethodHandles look good. Please wait for a review from security developers for KEM.java.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25287#pullrequestreview-2862198182

From naoto at openjdk.org  Thu May 22 18:24:58 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 May 2025 18:24:58 GMT
Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable [v3]
In-Reply-To: <GYKBz2_hwn2fMhvNG_AJkhj7YoD1KdEzZ_DhdAFC44Y=.8974fb06-613f-4aa4-9235-a8cd5f2b2d03@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
 <GYKBz2_hwn2fMhvNG_AJkhj7YoD1KdEzZ_DhdAFC44Y=.8974fb06-613f-4aa4-9235-a8cd5f2b2d03@github.com>
Message-ID: <_FIijEYTfFnkCAHDC8UFFYSUV4IBey5-im_qVyeqwtc=.2fe202af-bad4-46a9-8717-2d2f647bc91a@github.com>

On Thu, 22 May 2025 17:51:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.
>
> Justin Lu has updated the pull request with a new target base 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:
> 
>  - extLangs -> extlangs
>  - Merge branch 'master' into JDK-8357281-LanguageTag
>  - review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors
>  - init

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25371#pullrequestreview-2862197819

From isipka at openjdk.org  Thu May 22 18:40:50 2025
From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Thu, 22 May 2025 18:40:50 GMT
Subject: RFR: 8356443: Update open/test/jdk/TEST.groups manual test groups
 definitions with missing manual test
In-Reply-To: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com>
References: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com>
Message-ID: <ytGZtTd5Rw1lok7iy6BEhQP_l4_9UWvJnZIZ-NbPA0A=.6d70a955-2b77-4843-a251-c3409c336eed@github.com>

On Wed, 21 May 2025 15:37:34 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test

https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CenSizeMaximum.java
https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestMatrix.java
https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/channels/FileChannel/BlockDeviceSize.java

are all manual and 

https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java

is not. local run starts fine. LGTM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25360#issuecomment-2902213413

From dl at openjdk.org  Thu May 22 18:48:50 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 22 May 2025 18:48:50 GMT
Subject: RFR: 8357285 : JSR166 Test case testShutdownNow_delayedTasks
 failed
In-Reply-To: <KwynBdbgauVsdAxa6DO99vN1TqC8fUOMR39X-GlyVK0=.a83c6a2e-4e61-4db5-b6a7-21eaf7900802@github.com>
References: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com>
 <EP6kUN_8tAz5PPBv5dFwnc2DUENWfmZErOuzDONpOQs=.da9e8d34-1b54-40ab-b67a-0be33e9e2a52@github.com>
 <KwynBdbgauVsdAxa6DO99vN1TqC8fUOMR39X-GlyVK0=.a83c6a2e-4e61-4db5-b6a7-21eaf7900802@github.com>
Message-ID: <SUo8rAt0MdCuFI0mSyn_cGmwAB5wNC6hQTLjEK--pNo=.c5d44d31-d826-42a8-b640-d440ca713c6c@github.com>

On Thu, 22 May 2025 14:59:04 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> test/jdk/java/util/concurrent/tck/ScheduledExecutorTest.java line 703:
>> 
>>> 701:         final ScheduledThreadPoolExecutor p = new ScheduledThreadPoolExecutor(1);
>>> 702:         List<ScheduledFuture<?>> tasks = new ArrayList<>();
>>> 703:         final int DELAY = 100;
>> 
>> What do you think of trying to change this to `Utils.adjustTimeout(100)` so the env could change this depending on the factor used? This way may be the delay won't need to be as large.
>
> @myankelev The tasks are not expected to run, so the delay does not impact the duration of the test execution. The problem is rather that if they *do run* that the test fails, so if we move the delay further into the future, the test is less prone to failing spuriously.

I agree. This change is the only one that comes to mind to make spurious failure much less likely.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25394#discussion_r2103199492

From asemenyuk at openjdk.org  Thu May 22 19:53:22 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 22 May 2025 19:53:22 GMT
Subject: RFR: 8357171: Test tools/jpackage/windows/WinOSConditionTest.java
 fails for non administrator
Message-ID: <E2yYejdJ9lXyXOkgFXhRI1Ne6_Po0U-YWv8BT8PPd2E=.622cc346-3f44-46de-8bd1-3bbc55ace9f7@github.com>

- Allow to configure multiple expected installation exit codes for jpackage native packaging tests.
 - Adjusted the test to get skipped if executed in a restricted environment that doesn't allow per-user installations for non-administrators.

-------------

Commit messages:
 - 8357171: Test tools/jpackage/windows/WinOSConditionTest.java fails for non administrator

Changes: https://git.openjdk.org/jdk/pull/25400/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25400&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357171
  Stats: 30 lines in 2 files changed: 18 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/25400.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25400/head:pull/25400

PR: https://git.openjdk.org/jdk/pull/25400

From asemenyuk at openjdk.org  Thu May 22 19:53:22 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 22 May 2025 19:53:22 GMT
Subject: RFR: 8357171: Test tools/jpackage/windows/WinOSConditionTest.java
 fails for non administrator
In-Reply-To: <E2yYejdJ9lXyXOkgFXhRI1Ne6_Po0U-YWv8BT8PPd2E=.622cc346-3f44-46de-8bd1-3bbc55ace9f7@github.com>
References: <E2yYejdJ9lXyXOkgFXhRI1Ne6_Po0U-YWv8BT8PPd2E=.622cc346-3f44-46de-8bd1-3bbc55ace9f7@github.com>
Message-ID: <uoUAxF0WjMxyyyDQs3BXQyNKY9kEPpEWnRASXd40vg0=.36f53d24-b4be-43b1-9798-d8fc6f7d2d8a@github.com>

On Thu, 22 May 2025 19:39:04 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Allow to configure multiple expected installation exit codes for jpackage native packaging tests.
>  - Adjusted the test to get skipped if executed in a restricted environment that doesn't allow per-user installations for non-administrators.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25400#issuecomment-2902384922

From serb at openjdk.org  Thu May 22 20:04:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 22 May 2025 20:04:01 GMT
Subject: RFR: 8357401: BigDecimal: Constants ONE_TENTH and ONE_HALF are unused
 after JDK-8341402
Message-ID: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com>

Both fields were added by the [JDK-4851777](https://bugs.openjdk.org/browse/JDK-4851777):
see https://github.com/openjdk/jdk/commit/4045a8be07195acac7fb2faef0e6bf90edcaf9f8
And the usage were deleted by the [JDK-8341402](https://bugs.openjdk.org/browse/JDK-8341402):
see https://github.com/openjdk/jdk/commit/c4c3edfa964ef504f12971c5deef7c7355bdf325

-------------

Commit messages:
 - Merge branch 'openjdk:master' into bigd
 - unused ONE_TENTH and ONE_HALF

Changes: https://git.openjdk.org/jdk/pull/25339/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25339&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357401
  Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25339.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25339/head:pull/25339

PR: https://git.openjdk.org/jdk/pull/25339

From chen.l.liang at oracle.com  Thu May 22 20:06:14 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Thu, 22 May 2025 20:06:14 +0000
Subject: Missing throws declaration for NullPointerException in
 Proxy#getInvocationHandler
In-Reply-To: <2RhljdZeTpLum8FCZd7FjVqkQ0xaVJQGKC2-KYnObX6Jeij1T-DCTausYHVuZqBMK17_T26kaeS75Tr9qAdX7geh-pSfw6bQxTxayu5c6Ko=@protonmail.com>
References: <2RhljdZeTpLum8FCZd7FjVqkQ0xaVJQGKC2-KYnObX6Jeij1T-DCTausYHVuZqBMK17_T26kaeS75Tr9qAdX7geh-pSfw6bQxTxayu5c6Ko=@protonmail.com>
Message-ID: <SJ2PR10MB76692C585E363295BF90B411A299A@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hello, I have created https://bugs.openjdk.org/browse/JDK-8357597 for this.
Your analysis isn't quite correct - if you look at the method documentation, you would anticipate this to fail with an IllegalArgumentException instead of a NullPointerException. However, this mismatch has been there since 2006, so it's best to update the docs to match the actual longstanding behavior.
P.S. In the future, you can also report bugs via https://bugs.java.com/

Regard, Chen
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Steffen Nie?ing <zuniquex at protonmail.com>
Sent: Thursday, May 22, 2025 1:12 PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Missing throws declaration for NullPointerException in Proxy#getInvocationHandler

Hi,

recently I've come across the documentation of Proxy#getInvocationHandler(Object) and recognized that there's a missing throws declaration for a NullPointerException. The expression Proxy.getInvocationHandler(null) fails, because proxy.getClass() is called without asserting that proxy is not null.

I'd be happy to provide the JavaDoc update, if anyone would like to sponsor me the JBS issue for this one.

Cheers
Steffen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250522/2866d211/attachment.htm>

From bpb at openjdk.org  Thu May 22 20:10:50 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 May 2025 20:10:50 GMT
Subject: RFR: 8357401: BigDecimal: Constants ONE_TENTH and ONE_HALF are
 unused after JDK-8341402
In-Reply-To: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com>
References: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com>
Message-ID: <bzgxPHppC0i_tWkF07M8WmRp0of1A9KThYbDabgV9Vc=.3c49c172-7491-49ff-9345-16ba462ccd67@github.com>

On Wed, 21 May 2025 00:59:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Both fields were added by the [JDK-4851777](https://bugs.openjdk.org/browse/JDK-4851777):
> see https://github.com/openjdk/jdk/commit/4045a8be07195acac7fb2faef0e6bf90edcaf9f8
> And the usage were deleted by the [JDK-8341402](https://bugs.openjdk.org/browse/JDK-8341402):
> see https://github.com/openjdk/jdk/commit/c4c3edfa964ef504f12971c5deef7c7355bdf325

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25339#pullrequestreview-2862445385

From liach at openjdk.org  Thu May 22 20:10:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 May 2025 20:10:51 GMT
Subject: RFR: 8357401: BigDecimal: Constants ONE_TENTH and ONE_HALF are
 unused after JDK-8341402
In-Reply-To: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com>
References: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com>
Message-ID: <QmUPfQhUqT8dw0MtjOFEmZJ4rBf8X4N-CxwC5MkPTNs=.37a18415-6938-416b-a674-a17a8d2d3550@github.com>

On Wed, 21 May 2025 00:59:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Both fields were added by the [JDK-4851777](https://bugs.openjdk.org/browse/JDK-4851777):
> see https://github.com/openjdk/jdk/commit/4045a8be07195acac7fb2faef0e6bf90edcaf9f8
> And the usage were deleted by the [JDK-8341402](https://bugs.openjdk.org/browse/JDK-8341402):
> see https://github.com/openjdk/jdk/commit/c4c3edfa964ef504f12971c5deef7c7355bdf325

These are indeed unused.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25339#pullrequestreview-2862446799

From jrose at openjdk.org  Thu May 22 20:27:01 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 22 May 2025 20:27:01 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v8]
In-Reply-To: <PmF5hPmcrk43l3WpNEGxcCyu9zm-mamNvVod4TUMMZk=.223a6c62-a53f-4094-8f3b-2a094dc3425a@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
 <PmF5hPmcrk43l3WpNEGxcCyu9zm-mamNvVod4TUMMZk=.223a6c62-a53f-4094-8f3b-2a094dc3425a@github.com>
Message-ID: <SBZugkoc5UTL_IImQexEgGoMo4RbaFNb3vZaNp9-JIU=.6f0cefca-3b91-43fa-aad6-78246287835b@github.com>

On Thu, 15 May 2025 16:03:44 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
>> 
>> 
>> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
>> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
>> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
>> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
>> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright format correction

Nice!

There's a nicely written loop tail that handles power-of-two chunks from 32 bytes (stpq) down to a single byte.

Like many such tails, it is O(lg N), N being the max tail size, and that can be annoying when the loop tail is most or all of the work.

One thing that sometimes helps is a count leading zeroes followed by a multiway switch at the start, or just before the tail, to get started at the right place in the tail (its log-size cascade), for very small inputs.

This PR https://github.com/openjdk/jdk/pull/25383 uses clz in that way.

It also uses an overlapping-store technique to reduce an O(lg N) tail to an O(1) tail, which also depends on the clz step.

When atomicity is not an issue, the overlapping-store technique is faster on my MacBook M1.  It lets you (say) store 7 bytes in two cycles and no extra branches.  The downside is some bytes get stored twice (in the overlap), so it only works on unshared memory.

My rough notes on the relative performance of overlapping loads and stores are here FWIW:
https://cr.openjdk.org/~jrose/jvm/PartialMemoryWord.cpp

BTW, overlapping loads (properly bit-masked) are just as atomic as loads of individual bytes, and much faster.  But that's not the topic here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2902463076

From jrose at openjdk.org  Thu May 22 20:30:51 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 22 May 2025 20:30:51 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v5]
In-Reply-To: <kBtT8hpgfy9e9OBLI8_5S9PBsuVmqBuTB_NcoZIwoMA=.78786b50-55ab-4604-9dbd-87f27fcdc575@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <kBtT8hpgfy9e9OBLI8_5S9PBsuVmqBuTB_NcoZIwoMA=.78786b50-55ab-4604-9dbd-87f27fcdc575@github.com>
Message-ID: <IUJwXfxzGRw94q7rcOteE2rP966ajVnWvrSGqtn7Duo=.be0ab210-76ae-400a-ac62-526e5e14c012@github.com>

On Thu, 22 May 2025 11:52:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
>> 
>> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
>> 
>> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update benchmark to reflect new fill method

Related discussion at the hardware level:

https://github.com/openjdk/jdk/pull/25147#issuecomment-2902463076

I think I want to look into the VM, see if it can use overlapping reads and writes as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2902478627

From kevin.bourrillion at oracle.com  Thu May 22 20:33:15 2025
From: kevin.bourrillion at oracle.com (Kevin Bourrillion)
Date: Thu, 22 May 2025 20:33:15 +0000
Subject: Missing throws declaration for NullPointerException in
 Proxy#getInvocationHandler
In-Reply-To: <SJ2PR10MB76692C585E363295BF90B411A299A@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <2RhljdZeTpLum8FCZd7FjVqkQ0xaVJQGKC2-KYnObX6Jeij1T-DCTausYHVuZqBMK17_T26kaeS75Tr9qAdX7geh-pSfw6bQxTxayu5c6Ko=@protonmail.com>
 <SJ2PR10MB76692C585E363295BF90B411A299A@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <439853F6-BF71-437F-94BC-DA1E7E9A71A1@oracle.com>

I think Steffen is almost certainly right that this was an accidental omission. That omission results in the `@throws IAE` line being *interpreted* as also applying to null, but I doubt it was ever meant that way.

I think adding a `@throws NPE` is the right fix, and makes the class more consistent, and also preserves the ability to migrate the argument type to `Object!` in the future.



On May 22, 2025, at 1:06?PM, Chen Liang <chen.l.liang at oracle.com> wrote:

Hello, I have created https://bugs.openjdk.org/browse/JDK-8357597 for this.
Your analysis isn't quite correct - if you look at the method documentation, you would anticipate this to fail with an IllegalArgumentException instead of a NullPointerException. However, this mismatch has been there since 2006, so it's best to update the docs to match the actual longstanding behavior.
P.S. In the future, you can also report bugs via https://bugs.java.com/

Regard, Chen
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Steffen Nie?ing <zuniquex at protonmail.com>
Sent: Thursday, May 22, 2025 1:12 PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Missing throws declaration for NullPointerException in Proxy#getInvocationHandler

Hi,

recently I've come across the documentation of Proxy#getInvocationHandler(Object) and recognized that there's a missing throws declaration for a NullPointerException. The expression Proxy.getInvocationHandler(null) fails, because proxy.getClass() is called without asserting that proxy is not null.

I'd be happy to provide the JavaDoc update, if anyone would like to sponsor me the JBS issue for this one.

Cheers
Steffen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250522/53f66669/attachment-0001.htm>

From jlu at openjdk.org  Thu May 22 20:36:52 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 May 2025 20:36:52 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
Message-ID: <SoZ3agUUej7ri8CRCDEkbiB-wrZXhXp00yCqqQbumtU=.1035fe41-4f62-493a-aa15-fba1e7b0ba78@github.com>

On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects wording change suggestions

New wording is straightforward and looks good to me.

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25271#pullrequestreview-2862507794

From archie.cobbs at gmail.com  Thu May 22 20:58:03 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 22 May 2025 15:58:03 -0500
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v5]
In-Reply-To: <IUJwXfxzGRw94q7rcOteE2rP966ajVnWvrSGqtn7Duo=.be0ab210-76ae-400a-ac62-526e5e14c012@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <kBtT8hpgfy9e9OBLI8_5S9PBsuVmqBuTB_NcoZIwoMA=.78786b50-55ab-4604-9dbd-87f27fcdc575@github.com>
 <IUJwXfxzGRw94q7rcOteE2rP966ajVnWvrSGqtn7Duo=.be0ab210-76ae-400a-ac62-526e5e14c012@github.com>
Message-ID: <CANSoFxu6G=BaAs8HGHpijfBLRZ9T9tAGjDFT+GSEeNPmOwLUhQ@mail.gmail.com>

On Thu, May 22, 2025 at 3:31?PM John R Rose <jrose at openjdk.org> wrote:

> >   Update benchmark to reflect new fill method
>
> Related discussion at the hardware level:
>
> https://github.com/openjdk/jdk/pull/25147#issuecomment-2902463076
>

This discussion spurred me to ask a dumb question. Apologies in advance,
just trying to learn here...

If I do this:

import java.util.Arrays;
public class ArrayFiller {
    public static void main(String[] args) {
        while (true) {
            final byte[] array = new byte[1000000];
            Arrays.fill(array, (byte)0x42);
        }
    }
}

Will C2 compile Arrays.fill()
<https://github.com/openjdk/jdk/blob/139a05d05959a84541a29dfae6151f92ce579ae6/src/java.base/share/classes/java/util/Arrays.java#L3275-L3308>
into something that is more efficient than a byte-at-a-time loop like what
appears in the source code?

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250522/a15e1b6e/attachment.htm>

From prr at openjdk.org  Thu May 22 21:28:53 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 21:28:53 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
 <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
 <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>
 <bffWy8H4d6xnje0Gz_jIyv5jPBMuqp7S-iBFZTioTng=.7ee33246-76c2-470f-b608-894b5ba93988@github.com>
 <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com>
Message-ID: <2QcYZvy5pjx8J6Fi6j59uiHSfnqkp1yUHakx2qsxzKw=.d5720f94-adb8-4f86-aeed-e403c8e43066@github.com>

On Thu, 15 May 2025 12:33:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>>> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?
>> 
>> That seems unlikely. The pattern is used consistently in the French translations, where `Foo:` in the original is replaced with `Foo :` with a non-breaking space. I guess it is a French orthographic rule to have a space before the colon, and I understand why it really must be non-breaking in that case.
>
> FYI, the style guide for France [recommends](https://fr.wikipedia.org/wiki/Espace_ins%C3%A9cable#En_France):
> 
> - U+202F (Narrow No-Break Space NNBSP) preceding semicolon, question mark, and exclamation mark.
> - U+00A0 (No-Break Space NBSP) preceding colon.
> 
> Similar conventions are used in other French speaking countries.

> No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences.

> This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space.


I didn't say it reversed that entire changeset. I am saying that the previous changeset for L10N changed

the Java unicode escape to UTF-8 for the localised message string.

You propose restoring it to Java escape.


I wouldn't be surprised if the next message drop reverses what you reversed.

I don't know what tools the L10N team use but there's a chance it doesn't handle Java escapes

since that is very much a Java thing. So you are probably making the translation job harder.


So I am suggesting you leave all of the translation files as is.
Which might mean withdrawing this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2103421828

From prr at openjdk.org  Thu May 22 21:34:50 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 21:34:50 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <zS5WZR4Cen8tmwZk_Y4kSHU3wpLpMysoCv5WfF4yRUM=.4c035191-6fb5-46f2-ab11-f35701183529@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

Just speaking for the one client demo.
Someone else will need to review the other 98% of this PR

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25229#pullrequestreview-2862613813

From prr at openjdk.org  Thu May 22 21:45:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 21:45:52 GMT
Subject: RFR: 8356977: UTF-8 cleanups
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>

On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

src/java.desktop/share/classes/java/awt/MenuShortcut.java line 49:

> 47:  * For example, a menu shortcut for "Ctrl+cyrillic ef" is created by
> 48:  * <p>
> 49:  * <code>MenuShortcut ms = new MenuShortcut(KeyEvent.getExtendedKeyCodeForChar('?'), false);</code>

This is javadoc inJava SE specification. As is the Action case below.
I can't think of any actual harm from this change, so OK,  but I am not seeing why it is needed.

test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:

> 61: 
> 62:     private static final String INSTRUCTIONS =
> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "

I really don't like these tests being changed. It isn't part of the JDK build.
People compile these in all sorts of locales.
Please revert all the changes in the client tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2103439338
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2103431874

From d.ukhlov at gmail.com  Thu May 22 22:57:25 2025
From: d.ukhlov at gmail.com (Dmytro Ukhlov)
Date: Fri, 23 May 2025 01:57:25 +0300
Subject: Reducing Classloader's parallelLockMap memory consumption proposal
In-Reply-To: <8168f8c8-75c0-4158-b8d8-fcc4d495dced@oracle.com>
References: <CAGKffi85riNTzUT67O2jLRZgoHiX5t9=W5yRXXSoyDd-Rs6QMA@mail.gmail.com>
 <8168f8c8-75c0-4158-b8d8-fcc4d495dced@oracle.com>
Message-ID: <CAGKffi8=pfgrOfahZ+4hco+v_fU6WBpDoK40g4S8W0G_A87B4Q@mail.gmail.com>

Hello Alan,
Thank you for the useful information.

Jenkins's class loader topology is hierarchical. I believe Jenkins can
make its internal class loader implementations non-parallel capable.
However, the problem persists because Jenkins pipelines are built on
top of Groovy scripts. Running a pipeline requires the compilation and
execution of Groovy scripts at runtime.

When loading these dynamically generated classes (with unique names),
the GroovyClassLoader first tries to load them from the parent class
loader. As a result, a large number of lock objects are created
throughout the class loader chain, all the way down to the
PlatformClassLoader, which is parallel capable and cannot be modified.

Additionally, Groovy performs class lookups via class loading. For
example, if we have MyObject.name in a script, Groovy will attempt to
load MyObject, java.lang.MyObject, java.util.MyObject,
groovy.lang.MyObject, and so on.

To summarize:
The existing JDK java.lang.ClassLoader works well for traditional Java
applications, but it causes memory leaks when using dynamic class
loaders that load short-lived classes. It seems that we need a way to
determine whether a class can be loaded from the parent class loader
chain, and avoid calling parent.loadClass() if unnecessary - so as not
to accumulate entries in parallelLockMap.

If anyone has experience solving such issues, I would greatly
appreciate it if you could share your insights.

>
> On 20/05/2025 03:42, Dmytro Ukhlov wrote:
> > Hello!
> >
> > I created PR is scope of jenkins-core project:
> > https://github.com/jenkinsci/jenkins/pull/10659
> > Jira ticket: https://issues.jenkins.io/browse/JENKINS-75675
> >
> > In this PR i propped to override
> > protected Object getClassLoadingLock(String className)
> > method and use weak references for lock objects
> >
> > Jenkins is a plugable platform, each plugin has its own class loader
> > and its parallelLockMap may consume 10mb of RAM. As a result it might
> > have 2gb overhead if ~200 plugins installed.
> >
> > Jenkins maintainers ask me to consider making this improvement in base
>
> This is an issue for "parallel capable" class loaders, esp. those that
> don't directly delegate. I don't know what topology is used in the
> Jenkins plugin class loaders and whether these class loader need to
> parallel capable.
>
> Expunging entries isn't really feasible, at least not without changing
> the spec.
>
> JDK-8005233 [1] has a write-up from David Holmes on this topic and a
> prototype for "fully concurrent" class loaders. This work has been
> parked for several years. Maybe some day it will get dusted off and a
> JEP drafted (due to the significance).
>
> -Alan
>
> [1] https://bugs.openjdk.org/browse/JDK-8005233

From swen at openjdk.org  Thu May 22 23:37:59 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 22 May 2025 23:37:59 GMT
Subject: Integrated: 8353741: Eliminate table lookup in UUID.toString
In-Reply-To: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
References: <bj9SCN5k93BGpQzx1w7snZzvcd04VwkP4sYAXR3MFfI=.aa6bf9b0-effe-4087-81f5-8ae76a97034e@github.com>
Message-ID: <xm9CYR7_FnVgsS-C9PWjqUbWYptYI9FrAHADfycfmwQ=.2970543d-9e44-4177-b933-1a3695172d56@github.com>

On Mon, 6 Jan 2025 13:18:50 GMT, Shaojin Wen <swen at openjdk.org> 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.

This pull request has now been integrated.

Changeset: 796ec5e7
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/796ec5e7cfcfb20d76a3b48c0b369dc73250f7e4
Stats:     118 lines in 2 files changed: 87 ins; 27 del; 4 mod

8353741: Eliminate table lookup in UUID.toString

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/22928

From swen at openjdk.org  Fri May 23 02:03:48 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 23 May 2025 02:03:48 GMT
Subject: RFR: 8357081: Removed unused methods of HexDigits [v2]
In-Reply-To: <NmneRyd1Xg5PGjAiG1Pgq5dqkWMiE23LRjALLutkoyA=.912425d2-b549-40f7-bea2-46f2f869fa30@github.com>
References: <NmneRyd1Xg5PGjAiG1Pgq5dqkWMiE23LRjALLutkoyA=.912425d2-b549-40f7-bea2-46f2f869fa30@github.com>
Message-ID: <xTwgMQLRevZwr1ISpaDnqjumr4vfAMjvMaBgW3_g3GU=.da8dfc13-5a93-45a4-b4bd-7f3f7c90ce80@github.com>

> In HexDigits, getCharsLatin1 and getCharsUTF16 are no longer used, so remove these methods

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge remote-tracking branch 'upstream/master' into hexdigits_202505
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/util/HexDigits.java
 - remove unused code

-------------

Changes: https://git.openjdk.org/jdk/pull/25258/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25258&range=01
  Stats: 69 lines in 1 file changed: 0 ins; 69 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25258/head:pull/25258

PR: https://git.openjdk.org/jdk/pull/25258

From syan at openjdk.org  Fri May 23 03:25:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 23 May 2025 03:25:54 GMT
Subject: RFR: 8357285 : JSR166 Test case testShutdownNow_delayedTasks
 failed
In-Reply-To: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com>
References: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com>
Message-ID: <7bGhVY0UN6jkktKCsi5rw3qX9KbpFOSRTjAvTwR9jQU=.bf45d926-0720-4d74-a74f-b38622a45d8f@github.com>

On Thu, 22 May 2025 14:19:09 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Barring other effects, it is likely that this test just needs to have some longer timeouts to ensure that a stall isn't likely to fail the test case. The shouldn't have any impact on test execution duration, as the test looks at tasks which *have not executed yet*.

Hi, the test file `/test/jdk/java/util/concurrent/tck/ScheduledExecutorTest.java` seem do not have jtreg entry, is this test use for other jtreg tests. I found that this file has `main` function, how can I run this test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25394#issuecomment-2903135761

From smarks at openjdk.org  Fri May 23 03:49:51 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 23 May 2025 03:49:51 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
Message-ID: <4zSAcMMCamSOEtcAWTJBtBa3jRLIdf3DdOOAtbETxgs=.78a7086b-2ac9-4351-a001-4ec8ed83479b@github.com>

On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects wording change suggestions

I may be overthinking this, but let me just toss this out there to get people's opinions.

This changes the API of `jdk.internal.io.JdkConsoleProvider`. OK, this is an internal interface, so strictly speaking we can change it at will. But... do the IDEs use this to interface to implement their in-IDE terminal emulator? I'm not sure; maybe we should ask @lahodaj .

Well, the IDEs can probably easily adapt based on the JDK version. Or, if we want to be nice, we can leave the two-arg `console` method in place and have a default implementation for the three-arg `console` method that just calls the two-arg method with one of the charsets. Might not be worth it though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2903161425

From iklam at openjdk.org  Fri May 23 04:31:39 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 23 May 2025 04:31:39 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v12]
In-Reply-To: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
Message-ID: <4d8_PD1_wragYvfsjvrlwTubhP-Qeo1knf4inR5dWEM=.90cc62b2-1c80-4fbe-9413-afaed3d730a8@github.com>

> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
> 
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
> - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
> 
> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
> 
> Examples:
> 
> 
> # Create an AOT cache with a single command:
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> Hello World
> Temporary AOTConfiguration recorded: foo.aot.config
> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
> [...]
> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
> AOTCache creation is complete: foo.aot 10240000 bytes
> 
> # Create logging file for the AOT cache assembly phase
> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> 
> 
> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:

 - Fixed merge
 - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
 - @erikj79 comments -- makefile indentation
 - Fixed merge
 - @erikj79 comments
 - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
 - @vnkozlov comments
 - added info about JTREG/AOT_JDK testing
 - fixed whitespace
 - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
 - ... and 18 more: https://git.openjdk.org/jdk/compare/fdda7661...de16fdbd

-------------

Changes: https://git.openjdk.org/jdk/pull/24942/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=11
  Stats: 2107 lines in 26 files changed: 1564 ins; 459 del; 84 mod
  Patch: https://git.openjdk.org/jdk/pull/24942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942

PR: https://git.openjdk.org/jdk/pull/24942

From duke at openjdk.org  Fri May 23 04:33:36 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Fri, 23 May 2025 04:33:36 GMT
Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with
 exitValue = 1 [v3]
In-Reply-To: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
Message-ID: <g0uxm2yAHhLNZFmAEdZKlCGkmr56eBW4MS8bE8nxc8A=.ecc40181-2467-4506-939e-632afd297b1e@github.com>

> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1

PAWAN CHAWDHARY has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into 8354475
 - Update TestDockerMemoryMetricsSubgroup.java
   
   remove extra space
 - 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1

-------------

Changes: https://git.openjdk.org/jdk/pull/24930/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24930&range=02
  Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24930/head:pull/24930

PR: https://git.openjdk.org/jdk/pull/24930

From darcy at openjdk.org  Fri May 23 04:39:51 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 May 2025 04:39:51 GMT
Subject: RFR: 8357401: BigDecimal: Constants ONE_TENTH and ONE_HALF are
 unused after JDK-8341402
In-Reply-To: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com>
References: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com>
Message-ID: <-t5arb9h32offk8tW-m2Nj9twg-bz5bOlp_5a-TB4gI=.be05f1b6-e045-4c0f-bd28-224318685793@github.com>

On Wed, 21 May 2025 00:59:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Both fields were added by the [JDK-4851777](https://bugs.openjdk.org/browse/JDK-4851777):
> see https://github.com/openjdk/jdk/commit/4045a8be07195acac7fb2faef0e6bf90edcaf9f8
> And the usage were deleted by the [JDK-8341402](https://bugs.openjdk.org/browse/JDK-8341402):
> see https://github.com/openjdk/jdk/commit/c4c3edfa964ef504f12971c5deef7c7355bdf325

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25339#pullrequestreview-2863134181

From alan.bateman at oracle.com  Fri May 23 06:12:24 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Fri, 23 May 2025 07:12:24 +0100
Subject: Missing throws declaration for NullPointerException in
 Proxy#getInvocationHandler
In-Reply-To: <439853F6-BF71-437F-94BC-DA1E7E9A71A1@oracle.com>
References: <2RhljdZeTpLum8FCZd7FjVqkQ0xaVJQGKC2-KYnObX6Jeij1T-DCTausYHVuZqBMK17_T26kaeS75Tr9qAdX7geh-pSfw6bQxTxayu5c6Ko=@protonmail.com>
 <SJ2PR10MB76692C585E363295BF90B411A299A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <439853F6-BF71-437F-94BC-DA1E7E9A71A1@oracle.com>
Message-ID: <c95a80a5-fdbc-4a26-ad8f-4576043db68c@oracle.com>

On 22/05/2025 21:33, Kevin Bourrillion wrote:
> I think Steffen is almost certainly right that this was an accidental 
> omission. That omission results in the `@throws IAE` line being 
> *interpreted* as also applying to null, but I doubt it was ever meant 
> that way.
>
> I think adding a `@throws NPE` is the right fix, and makes the class 
> more consistent, and also preserves the ability to migrate the 
> argument type to `Object!` in the future.

As Chen notes, long standing behavior (since at least 2006) has been to 
throw NPE. Changing it to match an interpretation of the the IAE 
description will be noticed, maybe even break something. So yes, I think 
the NPE needs to be documented to align with the long standing behavior.

-Alan

From alanb at openjdk.org  Fri May 23 08:21:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 May 2025 08:21:58 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v8]
In-Reply-To: <-C0JVzsxoQlBvSZWfee6q1s18AkI0NVQVEMvEhkN5Og=.96872ba4-4d2e-450a-8c10-b789911b45fc@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <-C0JVzsxoQlBvSZWfee6q1s18AkI0NVQVEMvEhkN5Og=.96872ba4-4d2e-450a-8c10-b789911b45fc@github.com>
Message-ID: <Gh8p5Gwv5on4_WbiMwMctJ8Jxow8OTo5Ze2FNpbIlGU=.259a08ec-564b-4db2-b898-7d1f034dd10f@github.com>

On Thu, 22 May 2025 15:09:12 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge from JDK head
>  - Fix merge
>  - Fix merge
>  - Merge from https://github.com/openjdk/jdk
>  - ScopedValue::orElse() does not accept null as an argument.
>  - Remove unnecessary @since 25
>  - Remove unnecessary @enablePreview in some tests
>  - Since when?
>  - ScopedValue::orElse() does not accept null as an argument.
>  - 8355720: Implement JEP 506: Scoped Values
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/12efc1fe...460d82bd

CSR is approved, I think this update is ready to integrate.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24923#pullrequestreview-2863611886

From per-ake.minborg at oracle.com  Fri May 23 08:30:56 2025
From: per-ake.minborg at oracle.com (Per-Ake Minborg)
Date: Fri, 23 May 2025 08:30:56 +0000
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v5]
In-Reply-To: <CANSoFxu6G=BaAs8HGHpijfBLRZ9T9tAGjDFT+GSEeNPmOwLUhQ@mail.gmail.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <kBtT8hpgfy9e9OBLI8_5S9PBsuVmqBuTB_NcoZIwoMA=.78786b50-55ab-4604-9dbd-87f27fcdc575@github.com>
 <IUJwXfxzGRw94q7rcOteE2rP966ajVnWvrSGqtn7Duo=.be0ab210-76ae-400a-ac62-526e5e14c012@github.com>
 <CANSoFxu6G=BaAs8HGHpijfBLRZ9T9tAGjDFT+GSEeNPmOwLUhQ@mail.gmail.com>
Message-ID: <SA1PR10MB78327BD7408D6FCA32C29819DA98A@SA1PR10MB7832.namprd10.prod.outlook.com>

Hi Archie!

The C2 compiler can use automatic vectorization [1] to speed up such operations. You can watch my explanation of the concept in some of my recent presentations, e.g, [2]

Best, Per
YouTube<https://youtu.be/rXv2-lN5Xgk?t=1518>
Share your videos with friends, family, and the world
youtu.be

Automatic vectorization - Wikipedia<https://en.wikipedia.org/wiki/Automatic_vectorization>
Automatic vectorization, in parallel computing, is a special case of automatic parallelization, where a computer program is converted from a scalar implementation, which processes a single pair of operands at a time, to a vector implementation, which processes one operation on multiple pairs of operands at once. For example, modern conventional computers, including specialized supercomputers ...
en.wikipedia.org
[1] https://en.wikipedia.org/wiki/Automatic_vectorization
[2] https://youtu.be/rXv2-lN5Xgk?t=1518
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Archie Cobbs <archie.cobbs at gmail.com>
Sent: Thursday, May 22, 2025 10:58 PM
To: John R Rose <jrose at openjdk.org>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v5]

On Thu, May 22, 2025 at 3:31?PM John R Rose <jrose at openjdk.org<mailto:jrose at openjdk.org>> wrote:
>   Update benchmark to reflect new fill method

Related discussion at the hardware level:

https://github.com/openjdk/jdk/pull/25147#issuecomment-2902463076

This discussion spurred me to ask a dumb question. Apologies in advance, just trying to learn here...

If I do this:

import java.util.Arrays;
public class ArrayFiller {
    public static void main(String[] args) {
        while (true) {
            final byte[] array = new byte[1000000];
            Arrays.fill(array, (byte)0x42);
        }
    }
}

Will C2 compile Arrays.fill()<https://github.com/openjdk/jdk/blob/139a05d05959a84541a29dfae6151f92ce579ae6/src/java.base/share/classes/java/util/Arrays.java#L3275-L3308> into something that is more efficient than a byte-at-a-time loop like what appears in the source code?

Thanks,
-Archie

--
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250523/bcb1cb16/attachment-0001.htm>

From shade at openjdk.org  Fri May 23 09:10:13 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 23 May 2025 09:10:13 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v13]
In-Reply-To: <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>
Message-ID: <4qOq3AQt4RJI9yPvjXJSva2ZMyhqSOLqH3ERDX8csBg=.0ddce86f-eaba-41fd-9677-10e2090edaf1@github.com>

On Tue, 18 Feb 2025 14:33:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer.
>> 
>> We can migrate DBBs to use `java.lang.ref.Cleaner`.
>> 
>> There are two pecularities during this rewrite.
>> 
>> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it.
>> 
>> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us.
>> 
>> Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. This is why we need another way to check progress that involves checking if cleaner has acted.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `java/nio java/io`
>>  - [x] Linux AArch64 server fastdebug, `java/nio java/io`
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A bit more comments

Closing in favor of https://git.openjdk.org/jdk/pull/25289.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2903787453

From davidalayachew at gmail.com  Fri May 23 10:44:19 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 23 May 2025 06:44:19 -0400
Subject: Could someone answer this question about Gatherers?
Message-ID: <CAA9v-_MgFn1mFrfH+5Hh7+ymQQt=VS+rY8iapF+WHOHdjGeg8Q@mail.gmail.com>

Hello Core Libs Dev Team,

A post came up on StackOverflow recently that asked a question about
Gatherers --
https://stackoverflow.com/questions/79622707/why-doesnt-my-gatherer-short-circuit-the-stream-if-the-source-is-an-intstream

Just raising it here, as I think the only folks equipped to answer that
question are people already on this mailing list.

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250523/a32cc00a/attachment.htm>

From ssarathi at openjdk.org  Fri May 23 11:45:02 2025
From: ssarathi at openjdk.org (Sorna Sarathi N)
Date: Fri, 23 May 2025 11:45:02 GMT
Subject: RFR: 8357644: Add missing CPE statements
Message-ID: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com>

Adds missing classpath exception in a couple of files.

-------------

Commit messages:
 - Adding missing CPE

Changes: https://git.openjdk.org/jdk/pull/25413/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25413&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357644
  Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25413.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25413/head:pull/25413

PR: https://git.openjdk.org/jdk/pull/25413

From tvaleev at openjdk.org  Fri May 23 12:28:36 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Fri, 23 May 2025 12:28:36 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v4]
In-Reply-To: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
Message-ID: <n7RU1Hlm2BjJA1GovR1H_4Ibg-nDn45Jr2BaFrsqqew=.3940c815-60f6-4bc0-89e1-0469f395eca7@github.com>

> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
> 
> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
> 
> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Make min and max generic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25297/files
  - new: https://git.openjdk.org/jdk/pull/25297/files/b750c3fa..38f9eb71

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=02-03

  Stats: 15 lines in 2 files changed: 13 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25297.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25297/head:pull/25297

PR: https://git.openjdk.org/jdk/pull/25297

From viktor.klang at oracle.com  Fri May 23 12:56:33 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Fri, 23 May 2025 12:56:33 +0000
Subject: [External] : Could someone answer this question about Gatherers?
In-Reply-To: <CAA9v-_MgFn1mFrfH+5Hh7+ymQQt=VS+rY8iapF+WHOHdjGeg8Q@mail.gmail.com>
References: <CAA9v-_MgFn1mFrfH+5Hh7+ymQQt=VS+rY8iapF+WHOHdjGeg8Q@mail.gmail.com>
Message-ID: <MW4PR10MB577445B348C9A6F260B45694FF98A@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi David,

This definitely sounds like a bug, so I've opened: https://bugs.openjdk.org/browse/JDK-8357647

Thanks,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: David Alayachew <davidalayachew at gmail.com>
Sent: Friday, 23 May 2025 12:44
To: Viktor Klang <viktor.klang at oracle.com>; core-libs-dev <core-libs-dev at openjdk.org>
Subject: [External] : Could someone answer this question about Gatherers?

Hello Core Libs Dev Team,

A post came up on StackOverflow recently that asked a question about Gatherers -- https://stackoverflow.com/questions/79622707/why-doesnt-my-gatherer-short-circuit-the-stream-if-the-source-is-an-intstream<https://urldefense.com/v3/__https://stackoverflow.com/questions/79622707/why-doesnt-my-gatherer-short-circuit-the-stream-if-the-source-is-an-intstream__;!!ACWV5N9M2RV99hQ!KhxjMRzkOiiBNBaL_BG18YPs2hMlI1zI-y2lkZGQrJYHDCG0Zx14MAejks8opab_5tJD_M-o-lSxqLXHeeHWUuJtIS8$>

Just raising it here, as I think the only folks equipped to answer that question are people already on this mailing list.

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250523/c40700c8/attachment.htm>

From erikj at openjdk.org  Fri May 23 13:15:58 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 23 May 2025 13:15:58 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v12]
In-Reply-To: <4d8_PD1_wragYvfsjvrlwTubhP-Qeo1knf4inR5dWEM=.90cc62b2-1c80-4fbe-9413-afaed3d730a8@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
 <4d8_PD1_wragYvfsjvrlwTubhP-Qeo1knf4inR5dWEM=.90cc62b2-1c80-4fbe-9413-afaed3d730a8@github.com>
Message-ID: <7V06iTghjLDxbNUVkjjhLzZ8qNJ54W74R10Iy_HE6M8=.17c02df0-4cd6-4b9b-a7ad-d1404c17c817@github.com>

On Fri, 23 May 2025 04:31:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>> 
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
>> - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
>> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
>> 
>> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
>> 
>> Examples:
>> 
>> 
>> # Create an AOT cache with a single command:
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> Hello World
>> Temporary AOTConfiguration recorded: foo.aot.config
>> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
>> [...]
>> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
>> AOTCache creation is complete: foo.aot 10240000 bytes
>> 
>> # Create logging file for the AOT cache assembly phase
>> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
>> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
>> 
>> 
>> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Fixed merge
>  - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
>  - @erikj79 comments -- makefile indentation
>  - Fixed merge
>  - @erikj79 comments
>  - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
>  - @vnkozlov comments
>  - added info about JTREG/AOT_JDK testing
>  - fixed whitespace
>  - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/fdda7661...de16fdbd

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2864370912

From erikj at openjdk.org  Fri May 23 13:27:53 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 23 May 2025 13:27:53 GMT
Subject: RFR: 8357171: Test tools/jpackage/windows/WinOSConditionTest.java
 fails for non administrator
In-Reply-To: <E2yYejdJ9lXyXOkgFXhRI1Ne6_Po0U-YWv8BT8PPd2E=.622cc346-3f44-46de-8bd1-3bbc55ace9f7@github.com>
References: <E2yYejdJ9lXyXOkgFXhRI1Ne6_Po0U-YWv8BT8PPd2E=.622cc346-3f44-46de-8bd1-3bbc55ace9f7@github.com>
Message-ID: <AW-LKKWcOKTGBwuZGU-TPKPPQLnh90Ys2R3n3BjO2LQ=.91a0982d-f6f8-4fba-8cb8-12f85dcf6d39@github.com>

On Thu, 22 May 2025 19:39:04 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Allow to configure multiple expected installation exit codes for jpackage native packaging tests.
>  - Adjusted the test to get skipped if executed in a restricted environment that doesn't allow per-user installations for non-administrators.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25400#pullrequestreview-2864409725

From archie.cobbs at gmail.com  Fri May 23 13:38:31 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 23 May 2025 08:38:31 -0500
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v5]
In-Reply-To: <SA1PR10MB78327BD7408D6FCA32C29819DA98A@SA1PR10MB7832.namprd10.prod.outlook.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <kBtT8hpgfy9e9OBLI8_5S9PBsuVmqBuTB_NcoZIwoMA=.78786b50-55ab-4604-9dbd-87f27fcdc575@github.com>
 <IUJwXfxzGRw94q7rcOteE2rP966ajVnWvrSGqtn7Duo=.be0ab210-76ae-400a-ac62-526e5e14c012@github.com>
 <CANSoFxu6G=BaAs8HGHpijfBLRZ9T9tAGjDFT+GSEeNPmOwLUhQ@mail.gmail.com>
 <SA1PR10MB78327BD7408D6FCA32C29819DA98A@SA1PR10MB7832.namprd10.prod.outlook.com>
Message-ID: <CANSoFxuXZ_zXfVGymFAnxwhsnf1vohOzQ=+M4cj7U1HsqZ6nwA@mail.gmail.com>

Hi Per,

Thanks very much. Looks like there's lots of good info out there but I
didn't really know where to start so I appreciate the references.

-Archie


On Fri, May 23, 2025 at 3:31?AM Per-Ake Minborg <per-ake.minborg at oracle.com>
wrote:

> Hi Archie!
>
> The C2 compiler can use *automatic vectorization* [1] to speed up such
> operations. You can watch my explanation of the concept in some of my
> recent presentations, e.g, [2]
>
> Best, Per
> YouTube <https://youtu.be/rXv2-lN5Xgk?t=1518>
> Share your videos with friends, family, and the world
> youtu.be
>
> Automatic vectorization - Wikipedia
> <https://en.wikipedia.org/wiki/Automatic_vectorization>
> Automatic vectorization, in parallel computing, is a special case of
> automatic parallelization, where a computer program is converted from a
> scalar implementation, which processes a single pair of operands at a time,
> to a vector implementation, which processes one operation on multiple pairs
> of operands at once. For example, modern conventional computers, including
> specialized supercomputers ...
> en.wikipedia.org
> [1] https://en.wikipedia.org/wiki/Automatic_vectorization
> [2] https://youtu.be/rXv2-lN5Xgk?t=1518
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
> Archie Cobbs <archie.cobbs at gmail.com>
> *Sent:* Thursday, May 22, 2025 10:58 PM
> *To:* John R Rose <jrose at openjdk.org>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: RFR: 8357531: The `SegmentBulkOperations::fill` method can
> be improved using overlaps [v5]
>
> On Thu, May 22, 2025 at 3:31?PM John R Rose <jrose at openjdk.org> wrote:
>
> >   Update benchmark to reflect new fill method
>
> Related discussion at the hardware level:
>
> https://github.com/openjdk/jdk/pull/25147#issuecomment-2902463076
>
>
> This discussion spurred me to ask a dumb question. Apologies in advance,
> just trying to learn here...
>
> If I do this:
>
> import java.util.Arrays;
> public class ArrayFiller {
>     public static void main(String[] args) {
>         while (true) {
>             final byte[] array = new byte[1000000];
>             Arrays.fill(array, (byte)0x42);
>         }
>     }
> }
>
> Will C2 compile Arrays.fill()
> <https://github.com/openjdk/jdk/blob/139a05d05959a84541a29dfae6151f92ce579ae6/src/java.base/share/classes/java/util/Arrays.java#L3275-L3308>
> into something that is more efficient than a byte-at-a-time loop like what
> appears in the source code?
>
> Thanks,
> -Archie
>
> --
> Archie L. Cobbs
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250523/319af390/attachment.htm>

From asemenyuk at openjdk.org  Fri May 23 13:55:59 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 23 May 2025 13:55:59 GMT
Subject: Integrated: 8357171: Test
 tools/jpackage/windows/WinOSConditionTest.java fails for non administrator
In-Reply-To: <E2yYejdJ9lXyXOkgFXhRI1Ne6_Po0U-YWv8BT8PPd2E=.622cc346-3f44-46de-8bd1-3bbc55ace9f7@github.com>
References: <E2yYejdJ9lXyXOkgFXhRI1Ne6_Po0U-YWv8BT8PPd2E=.622cc346-3f44-46de-8bd1-3bbc55ace9f7@github.com>
Message-ID: <N5xreQ5hnBRw-UgsBeVh54O6E58RzxvWwhJ4MtESoIE=.4322abbf-cf87-42e0-837f-245d748dad86@github.com>

On Thu, 22 May 2025 19:39:04 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Allow to configure multiple expected installation exit codes for jpackage native packaging tests.
>  - Adjusted the test to get skipped if executed in a restricted environment that doesn't allow per-user installations for non-administrators.

This pull request has now been integrated.

Changeset: b07da7bc
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b07da7bcdcd4d1bba1f6e922d8e606bd73879052
Stats:     30 lines in 2 files changed: 18 ins; 0 del; 12 mod

8357171: Test tools/jpackage/windows/WinOSConditionTest.java fails for non administrator

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/25400

From jpai at openjdk.org  Fri May 23 13:57:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 23 May 2025 13:57:57 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v12]
In-Reply-To: <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com>
Message-ID: <geJoCywrJ-Kal6ZHkyUOdMw6BNNNw6Y1259jdeYboSc=.7ae0111a-921a-4472-9f85-4e5e3d731e91@github.com>

On Wed, 21 May 2025 23:30:18 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More tweaking...

This looks good to me. I would have prefered not changing the intial value of a the `readOnly` field to `true`, because that would mean one less thing to be concerned about. However, I am not too sure if it makes a practical difference. So what you have I think is OK. I'll think about it a bit more later and if anything shows up, I think we can address it. 

I think this enhancement deserves a release note, so I have added that label to the JBS issue. Instructions for creating a release note are available here https://openjdk.org/guide/#release-notes.

Thank you David for being patient with the back and forth discussions and reviews. Please wait for Alan and Lance to have a chance to look at the final state of this PR before integrating.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25178#pullrequestreview-2864523197

From lancea at openjdk.org  Fri May 23 14:24:52 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 23 May 2025 14:24:52 GMT
Subject: RFR: 8356629: Incorrect use of {@linkplain} in java.sql
In-Reply-To: <lHdtlZO7OsPQqd8SEBfLMyuxKBcwXAseIj3ZtGbguK8=.c41528ea-72be-4a3c-b0a4-733f6e95086c@github.com>
References: <lHdtlZO7OsPQqd8SEBfLMyuxKBcwXAseIj3ZtGbguK8=.c41528ea-72be-4a3c-b0a4-733f6e95086c@github.com>
Message-ID: <tRVOamuTPNAuGSaOGGuTYt84EBAvxjcnLulPQ1D51PA=.6d6628a8-47cd-407d-9712-ff4488c33a26@github.com>

On Sat, 17 May 2025 17:21:01 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this trivial patch to fix a javadoc bug.
> 
> TIA

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25286#pullrequestreview-2864609961

From weijun at openjdk.org  Fri May 23 14:31:52 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 23 May 2025 14:31:52 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base [v2]
In-Reply-To: <BxNtnccz3zlXcl_eEDKL0Z92RiSSvlvnNhb28tCh8zQ=.9a9d8fbf-8479-4078-9a00-2200b0fc3377@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
 <BxNtnccz3zlXcl_eEDKL0Z92RiSSvlvnNhb28tCh8zQ=.9a9d8fbf-8479-4078-9a00-2200b0fc3377@github.com>
Message-ID: <G8BGDogNzuXV8dPOHCFAIFiAt5Ppv5g6FAhb7-OyXKE=.57ac67b7-5c7a-48b0-8c7b-366b80ee67d3@github.com>

On Thu, 22 May 2025 15:18:43 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch to fix some `javadoc` bugs in `java.base`.
>> Certain `@link` tags used to refer to private fields instead of public APIs.
>> 
>> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to MethodType.java. <code>foo</code> markup should not be used

src/java.base/share/classes/javax/crypto/KEM.java line 711:

> 709:      * with the key encapsulation message so that the receiver is able to create
> 710:      * a matching decapsulator, it will be included as a byte array in the
> 711:      * {@link Encapsulated#params()} field inside the encapsulation output.

Good catch. The text must have been added before we changed `Encapsulated` from a record to a normal class. Now that `params` is a method instead of a record field, please consider rewriting the sentence to something like

it will be included as a byte array returned by the
{@link Encapsulated#params()} method within the
encapsulation output.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2104718909

From vklang at openjdk.org  Fri May 23 14:56:58 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 23 May 2025 14:56:58 GMT
Subject: RFR: 8357285 : JSR166 Test case testShutdownNow_delayedTasks
 failed
In-Reply-To: <7bGhVY0UN6jkktKCsi5rw3qX9KbpFOSRTjAvTwR9jQU=.bf45d926-0720-4d74-a74f-b38622a45d8f@github.com>
References: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com>
 <7bGhVY0UN6jkktKCsi5rw3qX9KbpFOSRTjAvTwR9jQU=.bf45d926-0720-4d74-a74f-b38622a45d8f@github.com>
Message-ID: <DM5dz2pfm04oEXIBngLdWBWlBQcpwASuA3ay54-JtZc=.9d7642fb-6835-48b2-8372-37c814c0d88b@github.com>

On Fri, 23 May 2025 03:22:59 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Barring other effects, it is likely that this test just needs to have some longer timeouts to ensure that a stall isn't likely to fail the test case. The shouldn't have any impact on test execution duration, as the test looks at tasks which *have not executed yet*.
>
> Hi, the test file `/test/jdk/java/util/concurrent/tck/ScheduledExecutorTest.java` seem do not have jtreg entry, is this test use for other jtreg tests. I found that this file has `main` function, how can I run this test.

@sendaoYan For simplicitly I typically execute the entire jdk_concurrent suite. You can get more granular if you want to, but it is trickier to get it done.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25394#issuecomment-2904700844

From vklang at openjdk.org  Fri May 23 14:56:58 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 23 May 2025 14:56:58 GMT
Subject: Integrated: 8357285 : JSR166 Test case testShutdownNow_delayedTasks
 failed
In-Reply-To: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com>
References: <8XqXXSu-TKBT1iGiXVrWTxAdLqbxU67DDLz7tKN6yx0=.30dbc7b5-9fcf-4959-ad9f-53464683d444@github.com>
Message-ID: <vfsvDw25b3Ab5df8TQKMkGqN0Py-kae1JStrFr2g7Go=.f89dc216-55fa-47c8-a0db-dc5f1831f798@github.com>

On Thu, 22 May 2025 14:19:09 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Barring other effects, it is likely that this test just needs to have some longer timeouts to ensure that a stall isn't likely to fail the test case. The shouldn't have any impact on test execution duration, as the test looks at tasks which *have not executed yet*.

This pull request has now been integrated.

Changeset: 6a078204
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6a07820483bcf3e9d7df27ee496db43675f1c002
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8357285: JSR166 Test case testShutdownNow_delayedTasks failed

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25394

From nbenalla at openjdk.org  Fri May 23 14:59:07 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 23 May 2025 14:59:07 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base [v3]
In-Reply-To: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
Message-ID: <ZV4YrCANI01Lj9XHvkjdb4InxXr-bsGjKLy2BaNWy5w=.356206aa-cb50-4348-b374-a19ae2ffcc19@github.com>

> Please review this patch to fix some `javadoc` bugs in `java.base`.
> Certain `@link` tags used to refer to private fields instead of public APIs.
> 
> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
> 
> TIA

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  update javadoc based on feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25287/files
  - new: https://git.openjdk.org/jdk/pull/25287/files/0653af94..daaed6c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25287&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25287&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25287.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25287/head:pull/25287

PR: https://git.openjdk.org/jdk/pull/25287

From weijun at openjdk.org  Fri May 23 15:06:52 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 23 May 2025 15:06:52 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base [v3]
In-Reply-To: <ZV4YrCANI01Lj9XHvkjdb4InxXr-bsGjKLy2BaNWy5w=.356206aa-cb50-4348-b374-a19ae2ffcc19@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
 <ZV4YrCANI01Lj9XHvkjdb4InxXr-bsGjKLy2BaNWy5w=.356206aa-cb50-4348-b374-a19ae2ffcc19@github.com>
Message-ID: <Dj7UqhJjXhFazTIjAIQcGFMSSevKeDpFYnpMWeLChu0=.3e17720c-c152-4dac-97b6-6ae7a60d5137@github.com>

On Fri, 23 May 2025 14:59:07 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch to fix some `javadoc` bugs in `java.base`.
>> Certain `@link` tags used to refer to private fields instead of public APIs.
>> 
>> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update javadoc based on feedback

The `KEM.java` change looks good to me. Thanks.

-------------

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25287#pullrequestreview-2864755280

From lancea at openjdk.org  Fri May 23 15:14:58 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 23 May 2025 15:14:58 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v12]
In-Reply-To: <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com>
Message-ID: <w33guHCrffQIGz3FfS9hWh5h4_GTgcwwNXGLN6RBQcw=.4a5e9639-a9e0-42bf-8d1e-0159f37eab8f@github.com>

On Wed, 21 May 2025 23:30:18 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More tweaking...

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1451:

> 1449:         }
> 1450:         int version;
> 1451:         if (o instanceof String) {

Any reason to not use:

> 
    if (o instanceof String s) {
        if (s.equals("runtime")) {
            version = Runtime.version().feature();
        } else else if (s.matches("^[1-9][0-9]*$")) { {
            version = Version.parse(s).feature();;
            }
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2104803699

From vklang at openjdk.org  Fri May 23 15:20:30 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 23 May 2025 15:20:30 GMT
Subject: RFR: 8357647 : Stream gatherers forward upstream size information to
 downstream
Message-ID: <RxzzF-SBFqP7iZ78Vdpk_t2RGt7smu6FiyeDlKSsO4Y=.e299e352-f6e6-4ec0-8d83-f4999b3e5b15@github.com>

While it could be argued that unbounded Spliterators should not report SIZED / SUBSIZED, GatherSink should report an unknown emission size, so switching to downstream.begin(-1) rather than downstream.begin(size).

Includes a regression test which yields an OOME if this change is omitted.

-------------

Commit messages:
 - No forced sequential needed
 - Amends GatherSink to propagate that the resulting output is unknown (-1) rather than passing on the upstream size

Changes: https://git.openjdk.org/jdk/pull/25418/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25418&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357647
  Stats: 40 lines in 2 files changed: 37 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25418.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25418/head:pull/25418

PR: https://git.openjdk.org/jdk/pull/25418

From viktor.klang at oracle.com  Fri May 23 15:26:08 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Fri, 23 May 2025 15:26:08 +0000
Subject: [External] : Could someone answer this question about Gatherers?
In-Reply-To: <MW4PR10MB577445B348C9A6F260B45694FF98A@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAA9v-_MgFn1mFrfH+5Hh7+ymQQt=VS+rY8iapF+WHOHdjGeg8Q@mail.gmail.com>
 <MW4PR10MB577445B348C9A6F260B45694FF98A@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <MW4PR10MB5774F58D3F75F5E6BD8EB462FF98A@MW4PR10MB5774.namprd10.prod.outlook.com>

I've opened a PR to prevent this from occurring: https://github.com/openjdk/jdk/pull/25418/files

However, there's an argument to be made that an unbounded Spliterator (as obtained by Random::ints(?)) should not report the SIZED and SUBSIZED characteristics, as it is indeed not sized. I'll open a separate Issue for that next week.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Viktor Klang <viktor.klang at oracle.com>
Sent: Friday, 23 May 2025 14:56
To: David Alayachew <davidalayachew at gmail.com>; core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: [External] : Could someone answer this question about Gatherers?

Hi David,

This definitely sounds like a bug, so I've opened: https://bugs.openjdk.org/browse/JDK-8357647

Thanks,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: David Alayachew <davidalayachew at gmail.com>
Sent: Friday, 23 May 2025 12:44
To: Viktor Klang <viktor.klang at oracle.com>; core-libs-dev <core-libs-dev at openjdk.org>
Subject: [External] : Could someone answer this question about Gatherers?

Hello Core Libs Dev Team,

A post came up on StackOverflow recently that asked a question about Gatherers -- https://stackoverflow.com/questions/79622707/why-doesnt-my-gatherer-short-circuit-the-stream-if-the-source-is-an-intstream<https://urldefense.com/v3/__https://stackoverflow.com/questions/79622707/why-doesnt-my-gatherer-short-circuit-the-stream-if-the-source-is-an-intstream__;!!ACWV5N9M2RV99hQ!KhxjMRzkOiiBNBaL_BG18YPs2hMlI1zI-y2lkZGQrJYHDCG0Zx14MAejks8opab_5tJD_M-o-lSxqLXHeeHWUuJtIS8$>

Just raising it here, as I think the only folks equipped to answer that question are people already on this mailing list.

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250523/10f20e44/attachment.htm>

From davidalayachew at gmail.com  Fri May 23 15:28:04 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 23 May 2025 11:28:04 -0400
Subject: [External] : Could someone answer this question about Gatherers?
In-Reply-To: <MW4PR10MB5774F58D3F75F5E6BD8EB462FF98A@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAA9v-_MgFn1mFrfH+5Hh7+ymQQt=VS+rY8iapF+WHOHdjGeg8Q@mail.gmail.com>
 <MW4PR10MB577445B348C9A6F260B45694FF98A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB5774F58D3F75F5E6BD8EB462FF98A@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_Mn4Qy1+L+=Gs97ARf8NxyOLur1+hMrZfo7LuOY2N=tpQ@mail.gmail.com>

Ty vm.

You don't think this has anything to do with my bug from 6 months ago,
where the parallel stream caused OOME, but the sequential ones
short-circuited correctly? I can pull up the thread if you don't recall.

On Fri, May 23, 2025, 11:26?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> I've opened a PR to prevent this from occurring:
> https://github.com/openjdk/jdk/pull/25418/files
>
> However, there's an argument to be made that an unbounded Spliterator (as
> obtained by Random::ints(?)) should not report the SIZED and SUBSIZED
> characteristics, as it is indeed not sized. I'll open a separate Issue for
> that next week.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
> Viktor Klang <viktor.klang at oracle.com>
> *Sent:* Friday, 23 May 2025 14:56
> *To:* David Alayachew <davidalayachew at gmail.com>; core-libs-dev <
> core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Could someone answer this question about
> Gatherers?
>
> Hi David,
>
> This definitely sounds like a bug, so I've opened:
> https://bugs.openjdk.org/browse/JDK-8357647
>
> Thanks,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
>
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Friday, 23 May 2025 12:44
> *To:* Viktor Klang <viktor.klang at oracle.com>; core-libs-dev <
> core-libs-dev at openjdk.org>
> *Subject:* [External] : Could someone answer this question about
> Gatherers?
>
> Hello Core Libs Dev Team,
>
> A post came up on StackOverflow recently that asked a question about
> Gatherers --
> https://stackoverflow.com/questions/79622707/why-doesnt-my-gatherer-short-circuit-the-stream-if-the-source-is-an-intstream
> <https://urldefense.com/v3/__https://stackoverflow.com/questions/79622707/why-doesnt-my-gatherer-short-circuit-the-stream-if-the-source-is-an-intstream__;!!ACWV5N9M2RV99hQ!KhxjMRzkOiiBNBaL_BG18YPs2hMlI1zI-y2lkZGQrJYHDCG0Zx14MAejks8opab_5tJD_M-o-lSxqLXHeeHWUuJtIS8$>
>
> Just raising it here, as I think the only folks equipped to answer that
> question are people already on this mailing list.
>
> Thank you for your time and help!
> David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250523/b4c7c8e6/attachment-0001.htm>

From liach at openjdk.org  Fri May 23 15:35:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 May 2025 15:35:51 GMT
Subject: RFR: 8357647 : Stream gatherers forward upstream size information
 to downstream
In-Reply-To: <RxzzF-SBFqP7iZ78Vdpk_t2RGt7smu6FiyeDlKSsO4Y=.e299e352-f6e6-4ec0-8d83-f4999b3e5b15@github.com>
References: <RxzzF-SBFqP7iZ78Vdpk_t2RGt7smu6FiyeDlKSsO4Y=.e299e352-f6e6-4ec0-8d83-f4999b3e5b15@github.com>
Message-ID: <NRR9HoViS9xOVDfy3FK1kUeEFoxbv_aVd6BszzB5umU=.34b30410-7903-4bf4-b498-2b7231443356@github.com>

On Fri, 23 May 2025 15:15:30 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> While it could be argued that unbounded Spliterators should not report SIZED / SUBSIZED, GatherSink should report an unknown emission size, so switching to downstream.begin(-1) rather than downstream.begin(size).
> 
> Includes a regression test which yields an OOME if this change is omitted.

Looks sensible; an integrator may push an arbitrary number of items to the downstream.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25418#pullrequestreview-2864843391

From rriggs at openjdk.org  Fri May 23 15:36:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 23 May 2025 15:36:57 GMT
Subject: RFR: 8357081: Removed unused methods of HexDigits [v2]
In-Reply-To: <xTwgMQLRevZwr1ISpaDnqjumr4vfAMjvMaBgW3_g3GU=.da8dfc13-5a93-45a4-b4bd-7f3f7c90ce80@github.com>
References: <NmneRyd1Xg5PGjAiG1Pgq5dqkWMiE23LRjALLutkoyA=.912425d2-b549-40f7-bea2-46f2f869fa30@github.com>
 <xTwgMQLRevZwr1ISpaDnqjumr4vfAMjvMaBgW3_g3GU=.da8dfc13-5a93-45a4-b4bd-7f3f7c90ce80@github.com>
Message-ID: <gddmsPUrqJGHhBcR8EKNFwv-62CR24p0d5NhcrBIdOM=.40720ef8-8898-4b84-b344-dd6c194a80dd@github.com>

On Fri, 23 May 2025 02:03:48 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In HexDigits, getCharsLatin1 and getCharsUTF16 are no longer used, so remove these methods
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into hexdigits_202505
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/util/HexDigits.java
>  - remove unused code

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25258#pullrequestreview-2864845707

From duke at openjdk.org  Fri May 23 15:56:02 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Fri, 23 May 2025 15:56:02 GMT
Subject: RFR: 8357647 : Stream gatherers forward upstream size information
 to downstream
In-Reply-To: <RxzzF-SBFqP7iZ78Vdpk_t2RGt7smu6FiyeDlKSsO4Y=.e299e352-f6e6-4ec0-8d83-f4999b3e5b15@github.com>
References: <RxzzF-SBFqP7iZ78Vdpk_t2RGt7smu6FiyeDlKSsO4Y=.e299e352-f6e6-4ec0-8d83-f4999b3e5b15@github.com>
Message-ID: <lO42K3pdaRoUIEyZsPTCnKsU6nZhfbJk5D75Yzzy1Ls=.8bcdef72-011a-4b1b-bd8e-3159c63c7814@github.com>

On Fri, 23 May 2025 15:15:30 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> While it could be argued that unbounded Spliterators should not report SIZED / SUBSIZED, GatherSink should report an unknown emission size, so switching to downstream.begin(-1) rather than downstream.begin(size).
> 
> Includes a regression test which yields an OOME if this change is omitted.

src/java.base/share/classes/java/util/stream/GathererOp.java line 153:

> 151:             if (initializer != Gatherer.defaultInitializer()) // Optimization
> 152:                 state = initializer.get();
> 153:             sink.begin(-1); // GathererOp does not know the size of the output

The Integrator of the SO question which motivated this PR _does_ know the size of the output. In general would it be worth to enhance Integrator with something like `default long estimateSize(long streamEstimate) { return -1; }` to allow Integrator implementations to weigh in?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25418#discussion_r2104886743

From liach at openjdk.org  Fri May 23 16:00:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 May 2025 16:00:52 GMT
Subject: RFR: 8357647 : Stream gatherers forward upstream size information
 to downstream
In-Reply-To: <lO42K3pdaRoUIEyZsPTCnKsU6nZhfbJk5D75Yzzy1Ls=.8bcdef72-011a-4b1b-bd8e-3159c63c7814@github.com>
References: <RxzzF-SBFqP7iZ78Vdpk_t2RGt7smu6FiyeDlKSsO4Y=.e299e352-f6e6-4ec0-8d83-f4999b3e5b15@github.com>
 <lO42K3pdaRoUIEyZsPTCnKsU6nZhfbJk5D75Yzzy1Ls=.8bcdef72-011a-4b1b-bd8e-3159c63c7814@github.com>
Message-ID: <XgnKgCwaKzs-8b1TzU4i7Q5LVh3cfekwzaXEg4E9ex0=.520fcdea-f996-4c9a-85da-983ab8fe14a7@github.com>

On Fri, 23 May 2025 15:53:22 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> While it could be argued that unbounded Spliterators should not report SIZED / SUBSIZED, GatherSink should report an unknown emission size, so switching to downstream.begin(-1) rather than downstream.begin(size).
>> 
>> Includes a regression test which yields an OOME if this change is omitted.
>
> src/java.base/share/classes/java/util/stream/GathererOp.java line 153:
> 
>> 151:             if (initializer != Gatherer.defaultInitializer()) // Optimization
>> 152:                 state = initializer.get();
>> 153:             sink.begin(-1); // GathererOp does not know the size of the output
> 
> The Integrator of the SO question which motivated this PR _does_ know the size of the output. In general would it be worth to enhance Integrator with something like `default long estimateSize(long streamEstimate) { return -1; }` to allow Integrator implementations to weigh in?

This sounds like `averageCharsPerByte` in `CharsetDecoder`. I first don't think we need the stream estimate for the integrater; also this probably deserves its own RFE instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25418#discussion_r2104898276

From rriggs at openjdk.org  Fri May 23 16:02:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 23 May 2025 16:02:52 GMT
Subject: RFR: 8357178: Simplify Class::componentType [v2]
In-Reply-To: <HtEqf_NTEWnVWPfHMCzPBwoBWIwAGrwCBYWWlZzWnTo=.e989ba16-68f9-40a5-a774-82dd6dc5d292@github.com>
References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com>
 <HtEqf_NTEWnVWPfHMCzPBwoBWIwAGrwCBYWWlZzWnTo=.e989ba16-68f9-40a5-a774-82dd6dc5d292@github.com>
Message-ID: <HkeQN05QhwZmFoNpSuCxHndmd7FOm7TKm4BjQDWuJFI=.d040161c-7d80-46dc-a8db-d7f8ce732c41@github.com>

On Mon, 19 May 2025 00:22:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `isArray` and null return is now redundant when `componentType` is changed to an explicit field.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   For parity with MT.descriptorString

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25280#pullrequestreview-2864932353

From vklang at openjdk.org  Fri May 23 16:08:52 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 23 May 2025 16:08:52 GMT
Subject: RFR: 8357647 : Stream gatherers forward upstream size information
 to downstream
In-Reply-To: <lO42K3pdaRoUIEyZsPTCnKsU6nZhfbJk5D75Yzzy1Ls=.8bcdef72-011a-4b1b-bd8e-3159c63c7814@github.com>
References: <RxzzF-SBFqP7iZ78Vdpk_t2RGt7smu6FiyeDlKSsO4Y=.e299e352-f6e6-4ec0-8d83-f4999b3e5b15@github.com>
 <lO42K3pdaRoUIEyZsPTCnKsU6nZhfbJk5D75Yzzy1Ls=.8bcdef72-011a-4b1b-bd8e-3159c63c7814@github.com>
Message-ID: <W5RMIS-7LR0lVLuRvidlM14nb7LNkDeX0i6tyKjl2qM=.d5b5f9ca-2f57-47d5-94c7-5f8b774b49d8@github.com>

On Fri, 23 May 2025 15:53:22 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> While it could be argued that unbounded Spliterators should not report SIZED / SUBSIZED, GatherSink should report an unknown emission size, so switching to downstream.begin(-1) rather than downstream.begin(size).
>> 
>> Includes a regression test which yields an OOME if this change is omitted.
>
> src/java.base/share/classes/java/util/stream/GathererOp.java line 153:
> 
>> 151:             if (initializer != Gatherer.defaultInitializer()) // Optimization
>> 152:                 state = initializer.get();
>> 153:             sink.begin(-1); // GathererOp does not know the size of the output
> 
> The Integrator of the SO question which motivated this PR _does_ know the size of the output. In general would it be worth to enhance Integrator with something like `default long estimateSize(long streamEstimate) { return -1; }` to allow Integrator implementations to weigh in?

@jdlib I guess that would depend on the definition of *value* and *cost* in this context.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25418#discussion_r2104911643

From vklang at openjdk.org  Fri May 23 16:08:52 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 23 May 2025 16:08:52 GMT
Subject: RFR: 8357647 : Stream gatherers forward upstream size information
 to downstream
In-Reply-To: <W5RMIS-7LR0lVLuRvidlM14nb7LNkDeX0i6tyKjl2qM=.d5b5f9ca-2f57-47d5-94c7-5f8b774b49d8@github.com>
References: <RxzzF-SBFqP7iZ78Vdpk_t2RGt7smu6FiyeDlKSsO4Y=.e299e352-f6e6-4ec0-8d83-f4999b3e5b15@github.com>
 <lO42K3pdaRoUIEyZsPTCnKsU6nZhfbJk5D75Yzzy1Ls=.8bcdef72-011a-4b1b-bd8e-3159c63c7814@github.com>
 <W5RMIS-7LR0lVLuRvidlM14nb7LNkDeX0i6tyKjl2qM=.d5b5f9ca-2f57-47d5-94c7-5f8b774b49d8@github.com>
Message-ID: <QfCyzKfgtzImsPg0T8gjLLRdEQNKdJZ0Xh19xbJOrm8=.d8997a8e-dee6-4757-91c2-2da1e785645d@github.com>

On Fri, 23 May 2025 16:04:50 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/stream/GathererOp.java line 153:
>> 
>>> 151:             if (initializer != Gatherer.defaultInitializer()) // Optimization
>>> 152:                 state = initializer.get();
>>> 153:             sink.begin(-1); // GathererOp does not know the size of the output
>> 
>> The Integrator of the SO question which motivated this PR _does_ know the size of the output. In general would it be worth to enhance Integrator with something like `default long estimateSize(long streamEstimate) { return -1; }` to allow Integrator implementations to weigh in?
>
> @jdlib I guess that would depend on the definition of *value* and *cost* in this context.

API modifications would definitely be its own thing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25418#discussion_r2104914259

From duke at openjdk.org  Fri May 23 16:10:03 2025
From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=)
Date: Fri, 23 May 2025 16:10:03 GMT
Subject: RFR: 8357597: Proxy.getInvocationHandler throws NullPointerException
 instead of IllegalArgumentException for null
Message-ID: <SAxS-e8fh7vXOoBnIxEC6X6fM5KdfM8YwCH5Bl3vdFc=.738ee4a2-f142-40c3-b967-7ffe01f8a258@github.com>

`Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE.

-------------

Commit messages:
 - 8357597: Add throws declaration for NPE

Changes: https://git.openjdk.org/jdk/pull/25419/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25419&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357597
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25419.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25419/head:pull/25419

PR: https://git.openjdk.org/jdk/pull/25419

From rriggs at openjdk.org  Fri May 23 16:15:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 23 May 2025 16:15:56 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v7]
In-Reply-To: <vfDsc33Hcmqn4buhdw7ZV-jVSMPUkrkNOcCTdkEulCU=.74cb83d5-f2d4-4bc3-96f6-e245ee7f3842@github.com>
References: <dm6o-XRNWecHjZeenCSRhAOEYI7L_mOOqfguvjlk_Bc=.cdb4e2e5-3500-48d5-8c05-749ff01f06f1@github.com>
 <vfDsc33Hcmqn4buhdw7ZV-jVSMPUkrkNOcCTdkEulCU=.74cb83d5-f2d4-4bc3-96f6-e245ee7f3842@github.com>
Message-ID: <b6nLCocfZjvViUBTNha5FiqEcAxLMFyBW1mHhSUB3hQ=.0845bd27-d9be-423c-ab9c-650ab2a5e827@github.com>

On Wed, 21 May 2025 21:31:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - More review updates
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>  - Move intrinsic to be a subsection; just one most common function of the annotation
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>  - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - Shorter first sentence
>  - Updates, thanks to John
>  - Refine validation and defensive copying
>  - 8355223: Improve documentation on @IntrinsicCandidate

The bulk of these comments belong in a design/rational doc for VM intrinsics, not in the javadoc of an annotation.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24777#pullrequestreview-2864975777

From duke at openjdk.org  Fri May 23 16:16:51 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Fri, 23 May 2025 16:16:51 GMT
Subject: RFR: 8357647 : Stream gatherers forward upstream size information
 to downstream
In-Reply-To: <QfCyzKfgtzImsPg0T8gjLLRdEQNKdJZ0Xh19xbJOrm8=.d8997a8e-dee6-4757-91c2-2da1e785645d@github.com>
References: <RxzzF-SBFqP7iZ78Vdpk_t2RGt7smu6FiyeDlKSsO4Y=.e299e352-f6e6-4ec0-8d83-f4999b3e5b15@github.com>
 <lO42K3pdaRoUIEyZsPTCnKsU6nZhfbJk5D75Yzzy1Ls=.8bcdef72-011a-4b1b-bd8e-3159c63c7814@github.com>
 <W5RMIS-7LR0lVLuRvidlM14nb7LNkDeX0i6tyKjl2qM=.d5b5f9ca-2f57-47d5-94c7-5f8b774b49d8@github.com>
 <QfCyzKfgtzImsPg0T8gjLLRdEQNKdJZ0Xh19xbJOrm8=.d8997a8e-dee6-4757-91c2-2da1e785645d@github.com>
Message-ID: <IFbWa1i5EZY-swHsFoMhkRw05sqAueKTWOCKzHHWj0E=.95c02b81-6433-451a-a293-3a8e42daab74@github.com>

On Fri, 23 May 2025 16:06:08 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> @jdlib I guess that would depend on the definition of *value* and *cost* in this context.
>
> API modifications would definitely be its own thing.

@viktorklang-ora, @liach I agree given the artificial starting point of the discussion - instead of a Gatherer the stackoverflow poster should have used `Stream.limit(long)` or `Random.ints(long streamSize, int , int)` to achieve the goal...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25418#discussion_r2104949317

From rriggs at openjdk.org  Fri May 23 16:18:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 23 May 2025 16:18:50 GMT
Subject: RFR: 8357597: Proxy.getInvocationHandler throws
 NullPointerException instead of IllegalArgumentException for null
In-Reply-To: <SAxS-e8fh7vXOoBnIxEC6X6fM5KdfM8YwCH5Bl3vdFc=.738ee4a2-f142-40c3-b967-7ffe01f8a258@github.com>
References: <SAxS-e8fh7vXOoBnIxEC6X6fM5KdfM8YwCH5Bl3vdFc=.738ee4a2-f142-40c3-b967-7ffe01f8a258@github.com>
Message-ID: <BxZCBYdCYwBbOLTjnRN8U3Mz381ML1c6ZfQNxuGXlyQ=.68a22ae2-5d90-4b10-a94d-5b21d4aa28ac@github.com>

On Fri, 23 May 2025 16:05:08 GMT, Steffen Nie?ing <duke at openjdk.org> wrote:

> `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE.

looks fine, will review the csr when its drafted.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25419#pullrequestreview-2864988003

From liach at openjdk.org  Fri May 23 16:21:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 May 2025 16:21:51 GMT
Subject: RFR: 8357597: Proxy.getInvocationHandler throws
 NullPointerException instead of IllegalArgumentException for null
In-Reply-To: <SAxS-e8fh7vXOoBnIxEC6X6fM5KdfM8YwCH5Bl3vdFc=.738ee4a2-f142-40c3-b967-7ffe01f8a258@github.com>
References: <SAxS-e8fh7vXOoBnIxEC6X6fM5KdfM8YwCH5Bl3vdFc=.738ee4a2-f142-40c3-b967-7ffe01f8a258@github.com>
Message-ID: <PUpPjFrw_h31XAH693BypOlMDCnjKyHFEmIW0IQBiq4=.9dbee07f-3fc0-4a6e-8e62-aa368e8877c8@github.com>

On Fri, 23 May 2025 16:05:08 GMT, Steffen Nie?ing <duke at openjdk.org> wrote:

> `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE.

I have created a CSR for this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25419#issuecomment-2905009702

From naoto at openjdk.org  Fri May 23 16:28:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 May 2025 16:28:53 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <4zSAcMMCamSOEtcAWTJBtBa3jRLIdf3DdOOAtbETxgs=.78a7086b-2ac9-4351-a001-4ec8ed83479b@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
 <4zSAcMMCamSOEtcAWTJBtBa3jRLIdf3DdOOAtbETxgs=.78a7086b-2ac9-4351-a001-4ec8ed83479b@github.com>
Message-ID: <EadaD3Jc9ldEB1m3p4jDElYAAldULkumK4c71RlUXTE=.c0dc165c-43c3-407e-9105-5ab082eea3b6@github.com>

On Fri, 23 May 2025 03:47:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> But... do the IDEs use this to interface to implement their in-IDE terminal emulator?

Can they even possibly do so?  `java.base`'s `module-info` exports `jdk.internal.io` only to `jdk.internal.le` and `jdk.jshell`, so I think no other modules can implement it and be loaded at runtime.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2905030550

From asemenyuk at openjdk.org  Fri May 23 16:33:55 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 23 May 2025 16:33:55 GMT
Subject: RFR: 8357644: Add missing CPE statements
In-Reply-To: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com>
References: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com>
Message-ID: <zRHS5EomPcywhHwehviPJrEMNQikgH5yX6n7VG5Wc-8=.48ac75c0-392a-4b8f-968b-10304b134375@github.com>

On Fri, 23 May 2025 11:40:24 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

> Adds missing classpath exception in a couple of files.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25413#pullrequestreview-2865019628

From chen.l.liang at oracle.com  Fri May 23 16:42:38 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Fri, 23 May 2025 16:42:38 +0000
Subject: [External] : Could someone answer this question about Gatherers?
In-Reply-To: <CAA9v-_Mn4Qy1+L+=Gs97ARf8NxyOLur1+hMrZfo7LuOY2N=tpQ@mail.gmail.com>
References: <CAA9v-_MgFn1mFrfH+5Hh7+ymQQt=VS+rY8iapF+WHOHdjGeg8Q@mail.gmail.com>
 <MW4PR10MB577445B348C9A6F260B45694FF98A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB5774F58D3F75F5E6BD8EB462FF98A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Mn4Qy1+L+=Gs97ARf8NxyOLur1+hMrZfo7LuOY2N=tpQ@mail.gmail.com>
Message-ID: <SJ2PR10MB76694AB1884375F2F263838CA298A@SJ2PR10MB7669.namprd10.prod.outlook.com>

Yes, please pull it up. We have a patch ready at https://github.com/openjdk/jdk/pull/25418, and I can test if this patch fixes your said bug.
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David Alayachew <davidalayachew at gmail.com>
Sent: Friday, May 23, 2025 10:28 AM
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: [External] : Could someone answer this question about Gatherers?

Ty vm.

You don't think this has anything to do with my bug from 6 months ago, where the parallel stream caused OOME, but the sequential ones short-circuited correctly? I can pull up the thread if you don't recall.

On Fri, May 23, 2025, 11:26?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
I've opened a PR to prevent this from occurring: https://github.com/openjdk/jdk/pull/25418/files

However, there's an argument to be made that an unbounded Spliterator (as obtained by Random::ints(?)) should not report the SIZED and SUBSIZED characteristics, as it is indeed not sized. I'll open a separate Issue for that next week.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Sent: Friday, 23 May 2025 14:56
To: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>; core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Could someone answer this question about Gatherers?

Hi David,

This definitely sounds like a bug, so I've opened: https://bugs.openjdk.org/browse/JDK-8357647

Thanks,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Friday, 23 May 2025 12:44
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>; core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: [External] : Could someone answer this question about Gatherers?

Hello Core Libs Dev Team,

A post came up on StackOverflow recently that asked a question about Gatherers -- https://stackoverflow.com/questions/79622707/why-doesnt-my-gatherer-short-circuit-the-stream-if-the-source-is-an-intstream<https://urldefense.com/v3/__https://stackoverflow.com/questions/79622707/why-doesnt-my-gatherer-short-circuit-the-stream-if-the-source-is-an-intstream__;!!ACWV5N9M2RV99hQ!KhxjMRzkOiiBNBaL_BG18YPs2hMlI1zI-y2lkZGQrJYHDCG0Zx14MAejks8opab_5tJD_M-o-lSxqLXHeeHWUuJtIS8$>

Just raising it here, as I think the only folks equipped to answer that question are people already on this mailing list.

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250523/dccec3a4/attachment-0001.htm>

From asemenyuk at openjdk.org  Fri May 23 16:45:01 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 23 May 2025 16:45:01 GMT
Subject: RFR: 8357644: Add missing CPE statements
In-Reply-To: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com>
References: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com>
Message-ID: <MQ3OyifpBY5BBGOyWXalx8zIVbakizLVBUYDosUqp2w=.2bffd39e-9036-4f14-8edd-945d8f9413ea@github.com>

On Fri, 23 May 2025 11:40:24 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

> Adds missing classpath exception in a couple of files.

Thank you for fixing this! My sincere apologies for the trouble.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25413#issuecomment-2905075388

From davidalayachew at gmail.com  Fri May 23 17:06:18 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 23 May 2025 13:06:18 -0400
Subject: [External] : Could someone answer this question about Gatherers?
In-Reply-To: <SJ2PR10MB76694AB1884375F2F263838CA298A@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CAA9v-_MgFn1mFrfH+5Hh7+ymQQt=VS+rY8iapF+WHOHdjGeg8Q@mail.gmail.com>
 <MW4PR10MB577445B348C9A6F260B45694FF98A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB5774F58D3F75F5E6BD8EB462FF98A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Mn4Qy1+L+=Gs97ARf8NxyOLur1+hMrZfo7LuOY2N=tpQ@mail.gmail.com>
 <SJ2PR10MB76694AB1884375F2F263838CA298A@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_Pt6yxtPBed_iBwNKRgfB07LyACL5vTik_V91BPvbH9tw@mail.gmail.com>

Sorry, I misremembered. What I was describing was not a bug, but a quirk of
streams, where they aggressively pre-fetch on parallel, but not when
sequential, causig an OOME on parallel streams.


Not that it helps, but here it is in case you want to read it anyways.

https://mail.openjdk.org/pipermail/core-libs-dev/2024-October/132207.html



On Fri, May 23, 2025, 12:48?PM Chen Liang <chen.l.liang at oracle.com> wrote:

> Yes, please pull it up. We have a patch ready at
> https://github.com/openjdk/jdk/pull/25418, and I can test if this patch
> fixes your said bug.
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Friday, May 23, 2025 10:28 AM
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Could someone answer this question about
> Gatherers?
>
> Ty vm.
>
> You don't think this has anything to do with my bug from 6 months ago,
> where the parallel stream caused OOME, but the sequential ones
> short-circuited correctly? I can pull up the thread if you don't recall.
>
> On Fri, May 23, 2025, 11:26?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> I've opened a PR to prevent this from occurring:
> https://github.com/openjdk/jdk/pull/25418/files
>
> However, there's an argument to be made that an unbounded Spliterator (as
> obtained by Random::ints(?)) should not report the SIZED and SUBSIZED
> characteristics, as it is indeed not sized. I'll open a separate Issue for
> that next week.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
> Viktor Klang <viktor.klang at oracle.com>
> *Sent:* Friday, 23 May 2025 14:56
> *To:* David Alayachew <davidalayachew at gmail.com>; core-libs-dev <
> core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Could someone answer this question about
> Gatherers?
>
> Hi David,
>
> This definitely sounds like a bug, so I've opened:
> https://bugs.openjdk.org/browse/JDK-8357647
>
> Thanks,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
>
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Friday, 23 May 2025 12:44
> *To:* Viktor Klang <viktor.klang at oracle.com>; core-libs-dev <
> core-libs-dev at openjdk.org>
> *Subject:* [External] : Could someone answer this question about
> Gatherers?
>
> Hello Core Libs Dev Team,
>
> A post came up on StackOverflow recently that asked a question about
> Gatherers --
> https://stackoverflow.com/questions/79622707/why-doesnt-my-gatherer-short-circuit-the-stream-if-the-source-is-an-intstream
> <https://urldefense.com/v3/__https://stackoverflow.com/questions/79622707/why-doesnt-my-gatherer-short-circuit-the-stream-if-the-source-is-an-intstream__;!!ACWV5N9M2RV99hQ!KhxjMRzkOiiBNBaL_BG18YPs2hMlI1zI-y2lkZGQrJYHDCG0Zx14MAejks8opab_5tJD_M-o-lSxqLXHeeHWUuJtIS8$>
>
> Just raising it here, as I think the only folks equipped to answer that
> question are people already on this mailing list.
>
> Thank you for your time and help!
> David Alayachew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250523/f4d4a655/attachment-0001.htm>

From smarks at openjdk.org  Fri May 23 17:20:58 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 23 May 2025 17:20:58 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <EadaD3Jc9ldEB1m3p4jDElYAAldULkumK4c71RlUXTE=.c0dc165c-43c3-407e-9105-5ab082eea3b6@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
 <4zSAcMMCamSOEtcAWTJBtBa3jRLIdf3DdOOAtbETxgs=.78a7086b-2ac9-4351-a001-4ec8ed83479b@github.com>
 <EadaD3Jc9ldEB1m3p4jDElYAAldULkumK4c71RlUXTE=.c0dc165c-43c3-407e-9105-5ab082eea3b6@github.com>
Message-ID: <t6Og1IesTuCW7yIUpSKEOWlP1V_E3S11pP0jEJTY-nM=.6458ee3c-0da0-42b4-878c-96e585727379@github.com>

On Fri, 23 May 2025 16:26:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Can they even possibly do so?

Sure, as far as I know, IntelliJ IDEA runs on its own version of the JDK, and it can easily be invoked or modified to allow use of those modules. I took a quick look at NetBeans and didn't see any references to `jdk.internal.io` though, so maybe I'm off base in thinking that they might be using it. I did have the impression that at least one of the IDEs had its own console provider implementation but this is anecdotal and I don't have any evidence of this.

No need to worry about this now, then. Sorry for the distraction.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2905196982

From smarks at openjdk.org  Fri May 23 17:25:54 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 23 May 2025 17:25:54 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
Message-ID: <3PAzs0ls7IGYZmW5m4VM-wIpr_vq080rwXCunwgwe78=.5a2669e4-201d-478d-9c0d-951770b315de@github.com>

On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects wording change suggestions

Marked as reviewed by smarks (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25271#pullrequestreview-2865165348

From jlahoda at openjdk.org  Fri May 23 17:25:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 23 May 2025 17:25:54 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <t6Og1IesTuCW7yIUpSKEOWlP1V_E3S11pP0jEJTY-nM=.6458ee3c-0da0-42b4-878c-96e585727379@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
 <4zSAcMMCamSOEtcAWTJBtBa3jRLIdf3DdOOAtbETxgs=.78a7086b-2ac9-4351-a001-4ec8ed83479b@github.com>
 <EadaD3Jc9ldEB1m3p4jDElYAAldULkumK4c71RlUXTE=.c0dc165c-43c3-407e-9105-5ab082eea3b6@github.com>
 <t6Og1IesTuCW7yIUpSKEOWlP1V_E3S11pP0jEJTY-nM=.6458ee3c-0da0-42b4-878c-96e585727379@github.com>
Message-ID: <ucXKAz0dqGAQH94a-LFwGAXHQOpyAqgw9DXOeZTECGw=.05160ac7-dfd9-44b0-acb0-8e70319731dd@github.com>

On Fri, 23 May 2025 17:18:40 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> > Can they even possibly do so?
> 
> Sure, as far as I know, IntelliJ IDEA runs on its own version of the JDK, and it can easily be invoked or modified to allow use of those modules. I took a quick look at NetBeans and didn't see any references to `jdk.internal.io` though, so maybe I'm off base in thinking that they might be using it. I did have the impression that at least one of the IDEs had its own console provider implementation but this is anecdotal and I don't have any evidence of this.

FWIW, I am not aware about NetBeans using JdkConsoleProvider.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2905211226

From naoto at openjdk.org  Fri May 23 17:30:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 May 2025 17:30:52 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
Message-ID: <EfgK6ACuxC_AgPZM2uN59XhWtcDBQm4nL1IKfcP4YUA=.ab538429-434b-4854-94bc-888c1a787c99@github.com>

On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects wording change suggestions

IntelliJ seems to be going with `-Djdk.console=jdk.internal.le` option, instead of hacking into the system: https://mastodon.online/@tagir_valeev/109981464706470933

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2905233081

From jlu at openjdk.org  Fri May 23 17:46:58 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 23 May 2025 17:46:58 GMT
Subject: RFR: 8357281: sun.util.Locale.LanguageTag should be immutable [v3]
In-Reply-To: <GYKBz2_hwn2fMhvNG_AJkhj7YoD1KdEzZ_DhdAFC44Y=.8974fb06-613f-4aa4-9235-a8cd5f2b2d03@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
 <GYKBz2_hwn2fMhvNG_AJkhj7YoD1KdEzZ_DhdAFC44Y=.8974fb06-613f-4aa4-9235-a8cd5f2b2d03@github.com>
Message-ID: <DXpZ88KKd-aG2ARyXq_A9iHgghI_Csqg6Qku_TxoEmI=.219c80b5-c77b-44ee-a48e-1d54c5ef03a4@github.com>

On Thu, 22 May 2025 17:51:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.
>
> Justin Lu has updated the pull request with a new target base 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:
> 
>  - extLangs -> extlangs
>  - Merge branch 'master' into JDK-8357281-LanguageTag
>  - review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors
>  - init

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25371#issuecomment-2905306305

From jlu at openjdk.org  Fri May 23 17:46:59 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 23 May 2025 17:46:59 GMT
Subject: Integrated: 8357281: sun.util.Locale.LanguageTag should be immutable
In-Reply-To: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
Message-ID: <vpc1qR0QFNm-o9A8gDj7SUibUY5xSuf7MgRD_RBswh4=.ffd3a29d-96d9-48e1-b9f4-bb390b81a44e@github.com>

On Wed, 21 May 2025 21:19:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.

This pull request has now been integrated.

Changeset: 2f530f89
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f530f89e0ee5ed5253125d0e9319b07103173f0
Stats:     191 lines in 3 files changed: 22 ins; 80 del; 89 mod

8357281: sun.util.Locale.LanguageTag should be immutable

Reviewed-by: naoto, liach

-------------

PR: https://git.openjdk.org/jdk/pull/25371

From serb at openjdk.org  Fri May 23 18:20:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 23 May 2025 18:20:56 GMT
Subject: Integrated: 8357401: BigDecimal: Constants ONE_TENTH and ONE_HALF are
 unused after JDK-8341402
In-Reply-To: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com>
References: <09muPqveyvWTAYI5KqUbMtiLWS33cAE7EfW6C9eqwSs=.a9136f96-e8fc-4b60-910f-29b20be91f62@github.com>
Message-ID: <KF8qxiwM9iiD096V3m0y1-tuzf7NSNEVVd8ia38GdZE=.064c0ea3-47a9-4c42-8f8a-e1eec26fcbbf@github.com>

On Wed, 21 May 2025 00:59:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Both fields were added by the [JDK-4851777](https://bugs.openjdk.org/browse/JDK-4851777):
> see https://github.com/openjdk/jdk/commit/4045a8be07195acac7fb2faef0e6bf90edcaf9f8
> And the usage were deleted by the [JDK-8341402](https://bugs.openjdk.org/browse/JDK-8341402):
> see https://github.com/openjdk/jdk/commit/c4c3edfa964ef504f12971c5deef7c7355bdf325

This pull request has now been integrated.

Changeset: 236e1b6d
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/236e1b6d529771f44218b6a4e2693e234e6a4e09
Stats:     10 lines in 1 file changed: 0 ins; 10 del; 0 mod

8357401: BigDecimal: Constants ONE_TENTH and ONE_HALF are unused after JDK-8341402

Reviewed-by: bpb, liach, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/25339

From naoto at openjdk.org  Fri May 23 18:36:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 May 2025 18:36:53 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <UgD8f9t5Y-SxmsFcK0oSUWk7hIzdnysuEkZb5lSWgts=.b873bc23-dcd6-4cae-b602-be9cbdcbeed4@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <Pup4nswVBdebz4T4tOR33WuL7iedobsLXh-FjSh4e6E=.7eb43d7b-4c9a-490e-9a1f-168fee7bdf9b@github.com>
 <ogXKGEuLuPNjbiKf2n8GLsIAUAgCqs6alj69rYqGMDU=.c72dc1a5-dfa2-44dc-a808-81162dec14b6@github.com>
 <gjZaymAsEf2eto9WZwSgSOCBVCy4n_3-CYUaIrGDaKI=.a6168cc0-d6b9-4685-97d9-82eba329680b@github.com>
 <RiE9-8g0F1QOLT3xhcxUIWC6CR_TcisqFwPX9omahWM=.f39c6e44-8378-4ed6-b0b9-5a5aa252cded@github.com>
 <UgD8f9t5Y-SxmsFcK0oSUWk7hIzdnysuEkZb5lSWgts=.b873bc23-dcd6-4cae-b602-be9cbdcbeed4@github.com>
Message-ID: <TjVVwUxD3apJksa99fXng1GHA47JW2lNYqZ8OmFZvkU=.83b4856a-8f74-488d-b4bb-440e86b1c06a@github.com>

On Wed, 21 May 2025 16:48:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Created jline/jline3#1282.
>
> Thanks!

JLine seems to incorporate the stdin encoding already, which is quick!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2105219623

From bpb at openjdk.org  Fri May 23 18:44:42 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 23 May 2025 18:44:42 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v26]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: <YzGSrFW7z3GSmzv2Pvmdq6PEIwR2KchNPd-X6ZUhmzs=.e218db04-f9bc-4473-a25f-5ef1e13f1358@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: "input reader specific" -> "reader specific"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/f9c732eb..1fc0cd3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=24-25

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 rriggs at openjdk.org  Fri May 23 19:00:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 23 May 2025 19:00:52 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v4]
In-Reply-To: <n7RU1Hlm2BjJA1GovR1H_4Ibg-nDn45Jr2BaFrsqqew=.3940c815-60f6-4bc0-89e1-0469f395eca7@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <n7RU1Hlm2BjJA1GovR1H_4Ibg-nDn45Jr2BaFrsqqew=.3940c815-60f6-4bc0-89e1-0469f395eca7@github.com>
Message-ID: <OkkymXyJdws4_Q5lKy1UayKoIkMB_yXA1flO9uNrhOY=.6c04512c-1a84-4e1b-b2f3-812d9b22d24f@github.com>

On Fri, 23 May 2025 12:28:36 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
>> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
>> 
>> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
>> 
>> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make min and max generic

src/java.base/share/classes/java/util/Comparator.java line 206:

> 204:      * @since 25
> 205:      */
> 206:     default <U extends T> U max(U a, U b) {

The parameter names are o1 and o2 in the `compare` method min and max build on. 
Though a and b are used in the class javadoc example and x and y are used in the spec description.
Can we be consistent in the API?  (o1, o2) perhaps.  Someday, the parameter names *may* be more significant.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2105250452

From bpb at openjdk.org  Fri May 23 19:46:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 23 May 2025 19:46:53 GMT
Subject: RFR: 8354450: A File should be invalid if an element of its name
 sequence ends with a space [v4]
In-Reply-To: <49Yvff-cNfqJxpzHD6NThf3zH46MivdDcKn0axoNEjc=.e5971545-10dc-4d56-b006-8e0409a179bc@github.com>
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
 <49Yvff-cNfqJxpzHD6NThf3zH46MivdDcKn0axoNEjc=.e5971545-10dc-4d56-b006-8e0409a179bc@github.com>
Message-ID: <IYd68GxHAIRncBR-5FL5uJAatSMVPPJPgHuPiEz2fbY=.b01f8e21-aab4-4c16-9a7f-67af4107e88a@github.com>

On Wed, 23 Apr 2025 21:50:46 GMT, Brian Burkhalter <bpb at openjdk.org> 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: Simplify test for " \" in path elements

`continue;`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24635#issuecomment-2905629157

From liach at openjdk.org  Fri May 23 19:55:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 May 2025 19:55:54 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v5]
In-Reply-To: <kBtT8hpgfy9e9OBLI8_5S9PBsuVmqBuTB_NcoZIwoMA=.78786b50-55ab-4604-9dbd-87f27fcdc575@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <kBtT8hpgfy9e9OBLI8_5S9PBsuVmqBuTB_NcoZIwoMA=.78786b50-55ab-4604-9dbd-87f27fcdc575@github.com>
Message-ID: <FMxEJ1ovJhtsYGInbaj_4egjdwcfujYTUXJmMcnGWek=.40e4d745-3e66-48a2-90fe-4183a114ae5d@github.com>

On Thu, 22 May 2025 11:52:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
>> 
>> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
>> 
>> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
>> 
>> This PR passes tier1, tier2, and tier3 on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update benchmark to reflect new fill method

Can we remove all meaningless `!Architecture.isLittleEndian()` calls and use the platform-specific endianness unsafe primitives instead? For compensation, we can add a check in each of fill2/fill3/fill4 that `assert value == Integer/Short/Long.reverseBytes(value)` if you think that is necessary.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2905651428

From aturbanov at openjdk.org  Fri May 23 20:39:52 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 23 May 2025 20:39:52 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v4]
In-Reply-To: <n7RU1Hlm2BjJA1GovR1H_4Ibg-nDn45Jr2BaFrsqqew=.3940c815-60f6-4bc0-89e1-0469f395eca7@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <n7RU1Hlm2BjJA1GovR1H_4Ibg-nDn45Jr2BaFrsqqew=.3940c815-60f6-4bc0-89e1-0469f395eca7@github.com>
Message-ID: <fapUpKyaRth2d7UyYx2pZPmG-2ohB0lzYrTy_26BNuA=.68493b43-a078-46bd-96af-66c1a90fea3f@github.com>

On Fri, 23 May 2025 12:28:36 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
>> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
>> 
>> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
>> 
>> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make min and max generic

src/java.base/share/classes/java/util/Comparator.java line 200:

> 198:      * @param   <U> the type of the arguments and the result.
> 199:      * @return  the larger of {@code a} and {@code b} according to this comparator.
> 200:      * @throws  ClassCastException if the collection contains elements that are

What 'collection' meaned here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2105386536

From liach at openjdk.org  Fri May 23 23:00:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 May 2025 23:00:55 GMT
Subject: RFR: 8357178: Simplify Class::componentType [v2]
In-Reply-To: <HtEqf_NTEWnVWPfHMCzPBwoBWIwAGrwCBYWWlZzWnTo=.e989ba16-68f9-40a5-a774-82dd6dc5d292@github.com>
References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com>
 <HtEqf_NTEWnVWPfHMCzPBwoBWIwAGrwCBYWWlZzWnTo=.e989ba16-68f9-40a5-a774-82dd6dc5d292@github.com>
Message-ID: <WNdkHWZZlQXwb_cRr140itGYFrk4pagRWDT67WAqLJM=.71c52292-3966-4830-955a-137a4b5984b2@github.com>

On Mon, 19 May 2025 00:22:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `isArray` and null return is now redundant when `componentType` is changed to an explicit field.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   For parity with MT.descriptorString

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25280#issuecomment-2905985750

From liach at openjdk.org  Fri May 23 23:00:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 May 2025 23:00:55 GMT
Subject: Integrated: 8357178: Simplify Class::componentType
In-Reply-To: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com>
References: <9NaQDdrNbIAVoEz2hzopz1eRJO-TsAMRc6NaZ-SWLKU=.c82f6b0b-9836-4e3d-a56b-60a91baefde5@github.com>
Message-ID: <WEddGgY4SKpfFRtTBn4pNcQoqUpqKLF_OiS9VjbrOYY=.920a3972-8238-4a82-bb2a-68c06c2a2bbe@github.com>

On Sat, 17 May 2025 02:15:42 GMT, Chen Liang <liach at openjdk.org> wrote:

> `isArray` and null return is now redundant when `componentType` is changed to an explicit field.

This pull request has now been integrated.

Changeset: 070c84cd
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/070c84cd22485a93a562a7639439fb056e840861
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8357178: Simplify Class::componentType

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/25280

From vlivanov at openjdk.org  Fri May 23 23:03:53 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 23 May 2025 23:03:53 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v6]
In-Reply-To: <lnDH0vCQvoIGjjsjeO7ukv8gpTfp1vWR8hOX-CXlFjA=.a859787f-bc16-40c2-9f9d-ae879e68dc25@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com>
 <ymq-cS14PaC1PpdKAzAZJwxdwtVTbSZtT-LNC21lW6Q=.f956592a-fd59-4bb5-a485-f4138942d290@github.com>
 <lnDH0vCQvoIGjjsjeO7ukv8gpTfp1vWR8hOX-CXlFjA=.a859787f-bc16-40c2-9f9d-ae879e68dc25@github.com>
Message-ID: <rHMm6DwsyFJIOTQRKO17T0VyOvaxUwxVpwWKw4mpIj8=.d2633532-bc82-4505-a14b-45b46798d4ff@github.com>

On Tue, 20 May 2025 22:14:42 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ref/Reference.java line 366:
>> 
>>> 364: 
>>> 365:     /* Implementation of unintrinsified get().  Making get() native may lead
>>> 366:      * C2 to sometimes prefer the native implementation over the intrinsic.
>> 
>> Can you share more details on this?
>
> See review thread slightly above here, specifically https://github.com/openjdk/jdk/pull/24315/files#r2094884157.
> I've looked at the intrinsics for Object.clone() and Object.hashCode(), but only enough to decide I
> understand the approach being taken here better than what's in those.

As I understand, `JDK-8271862` was about migrating to non-virtual intrinsic method.
In case of `Reference::get()`, you already have a virtual public method marked as `@IntrinsicCandidate`. And the patch doesn't change anything there.  So, unless I miss something, I believe the comment is misleading.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2105506789

From sherman at openjdk.org  Fri May 23 23:28:54 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 23 May 2025 23:28:54 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v12]
In-Reply-To: <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com>
Message-ID: <N9ttJx89WpqcbnaS-F1WgJIno4QNnPDocolTjvDvMYs=.1e335fc2-2922-46bf-8174-2f8a9372b0fa@github.com>

On Wed, 21 May 2025 23:30:18 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More tweaking...

Looks like I'm late to the party :-) My apologies if this has already been discussed a long time ago. My question is whether it's really necessary to restrict the 'read-only' flag to existing ZIP files only. I don't see any issue with allowing the creation of a new, empty ZIP file and marking it as read-only. Sure, it might be useless since it's just an empty zip file system, but that's up to the user.  Not a very strong opinion though.

283  *           <li>
284  *               If the value is {@code "readOnly"}, the file system is created
285  *               <em>read-only</em>, and {@link java.nio.file.FileSystem#isReadOnly()
286  *               isReadOnly()} will always return {@code true}. Creating a
287  *               <em>read-only</em> file system requires the underlying ZIP file to
288  *               already exist.
289  *               Specifying the {@code create} property as {@code true} with the
290  *               {@code accessMode} as {@code readOnly} will cause an {@code
291  *               IllegalArgumentException} to be thrown when creating the ZIP file
292  *               system.
293  *           </li>

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25178#issuecomment-2906012555

From amenkov at openjdk.org  Sat May 24 00:22:14 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 24 May 2025 00:22:14 GMT
Subject: RFR: 8357650: ThreadSnapshot to take snapshot of thread for thread
 dumps
Message-ID: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>

This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
The update has been split into parts to simplify reviewing.
The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.

Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
  sanity tier1 (this fix only)

-------------

Commit messages:
 - initial fix

Changes: https://git.openjdk.org/jdk/pull/25425/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25425&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357650
  Stats: 736 lines in 8 files changed: 733 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25425/head:pull/25425

PR: https://git.openjdk.org/jdk/pull/25425

From shaojin.wensj at alibaba-inc.com  Sat May 24 01:00:21 2025
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Sat, 24 May 2025 09:00:21 +0800
Subject: =?UTF-8?B?RGlnaXRMaXN0Ojp0b1N0cmluZyBtZXRob2QgY2F1c2luZyBpbmNvcnJlY3QgcmVzdWx0cyBk?=
 =?UTF-8?B?dXJpbmcgZGVidWdnaW5n?=
Message-ID: <f98c1028-e44b-4fac-bd97-ba9e74e0b7c9.shaojin.wensj@alibaba-inc.com>

When debugging getLong/getDouble/getDecimal of java.text.DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.
-
Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250524/ac7de28b/attachment.htm>

From swen at openjdk.org  Sat May 24 01:36:54 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 24 May 2025 01:36:54 GMT
Subject: RFR: 8354799: ZipInputStream doesn't verify CRC for ZIP entry with
 empty file data [v3]
In-Reply-To: <uSCkEpxPEocKZrI3TEo9oi5R-nzbhQOxg2t-FC0XR30=.1ddf943c-49f3-466f-aff5-f33fd1678004@github.com>
References: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
 <uSCkEpxPEocKZrI3TEo9oi5R-nzbhQOxg2t-FC0XR30=.1ddf943c-49f3-466f-aff5-f33fd1678004@github.com>
Message-ID: <Lg2SA59Msq02F_4peSWYqd7of_2-heOmd1XaY7wJHII=.539acd67-cd5e-46fd-868f-c83ab52c9545@github.com>

On Mon, 12 May 2025 11:27:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799?
>> 
>> `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix.
>> 
>> tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's suggestion - simplify argument creation, given just a handful number of argument values

test/jdk/java/util/zip/ZipInputStream/ZipInputStreamCRCCheck.java line 136:

> 134:         System.out.println("tampered the crc value"
> 135:                 + " from 0x" + Integer.toHexString(currentCRC)
> 136:                 + " to 0x" + Integer.toHexString(bb.position(crcOffset).getInt()));

Suggestion:

        System.out.format("tampered the crc value from 0x%x to 0x%x%n", currentCRC, bb.position(crcOffset).getInt());

The test code does not require high performance, we can System.out.format

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25116#discussion_r2105656655

From chen.l.liang at oracle.com  Sat May 24 02:26:57 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sat, 24 May 2025 02:26:57 +0000
Subject: DigitList::toString method causing incorrect results during
 debugging
In-Reply-To: <f98c1028-e44b-4fac-bd97-ba9e74e0b7c9.shaojin.wensj@alibaba-inc.com>
References: <f98c1028-e44b-4fac-bd97-ba9e74e0b7c9.shaojin.wensj@alibaba-inc.com>
Message-ID: <CH3PR10MB7677D857983C164D249F5A1AA29BA@CH3PR10MB7677.namprd10.prod.outlook.com>

Thanks for this report. This code is indeed very old - and probably back then, people thought sharing StringBuffer (which has since been migrated to StringBuilder) was a great idea.
I checked the use site of the temp buffer - it appears to me that in the lifecycle of a DigitList, that buffer is usually only created and used once, and the cache would actually be more of a penalty than an optimization if that is the case. In addition, I don't find any usage of toString of DigitList.
I think it should be fine to create a PR to end the sharing of these temp buffer - a patch that uses a new StringBuilder for DigitList.toString should be the safest, before I18N engineers can determine if we can remove the cache mechanism altogether.

Chen
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of wenshao <shaojin.wensj at alibaba-inc.com>
Sent: Friday, May 23, 2025 8:00 PM
To: core-libs-dev <core-libs-dev at openjdk.org>
Subject: DigitList::toString method causing incorrect results during debugging

When debugging getLong/getDouble/getDecimal of java.text.DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.

-
Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250524/2f3b1d08/attachment.htm>

From swen at openjdk.org  Sat May 24 02:46:00 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 24 May 2025 02:46:00 GMT
Subject: RFR: 8357681: Fixed the DigitList::toString method causing incorrect
 results during debugging
Message-ID: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>

When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.

-------------

Commit messages:
 - minimal change
 - remove tempBuilder

Changes: https://git.openjdk.org/jdk/pull/25288/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25288&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357681
  Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25288.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25288/head:pull/25288

PR: https://git.openjdk.org/jdk/pull/25288

From liach at openjdk.org  Sat May 24 03:02:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 24 May 2025 03:02:53 GMT
Subject: RFR: 8357681: Fixed the DigitList::toString method causing
 incorrect results during debugging
In-Reply-To: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
Message-ID: <EF4XQ38W4hJSm6g7V-XyF4QI09oH_z3cyDveeyilXvE=.e8edb28d-f370-4e2a-b916-268c97afff45@github.com>

On Sun, 18 May 2025 11:11:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.

This change looks reasonable to me. I couldn't find any direct usage of DigitList::toString.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25288#issuecomment-2906330880

From shaojin.wensj at alibaba-inc.com  Sat May 24 03:47:15 2025
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Sat, 24 May 2025 11:47:15 +0800
Subject: =?UTF-8?B?SW50ZWdlcjo6ZGlnaXRzIHNob3VsZCBiZSBkZWZpbmVkIGFzIGJ5dGVbXQ==?=
Message-ID: <c8bad838-af5e-4297-84ff-9eba4944ba92.shaojin.wensj@alibaba-inc.com>

Now Integer/Long uses Integer::digits to convert to byte, so we should define Integer::digits as byte[], which can avoid the conversion.
-
Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250524/5f4edef2/attachment.htm>

From kbarrett at openjdk.org  Sat May 24 04:59:51 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 24 May 2025 04:59:51 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v6]
In-Reply-To: <rHMm6DwsyFJIOTQRKO17T0VyOvaxUwxVpwWKw4mpIj8=.d2633532-bc82-4505-a14b-45b46798d4ff@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com>
 <ymq-cS14PaC1PpdKAzAZJwxdwtVTbSZtT-LNC21lW6Q=.f956592a-fd59-4bb5-a485-f4138942d290@github.com>
 <lnDH0vCQvoIGjjsjeO7ukv8gpTfp1vWR8hOX-CXlFjA=.a859787f-bc16-40c2-9f9d-ae879e68dc25@github.com>
 <rHMm6DwsyFJIOTQRKO17T0VyOvaxUwxVpwWKw4mpIj8=.d2633532-bc82-4505-a14b-45b46798d4ff@github.com>
Message-ID: <cskdHy0_3zFOp7bAI-zz6V-avY2vPIcnwIseaE0NrS8=.3c147c4d-78e9-4499-88d3-73fbb40560ab@github.com>

On Fri, 23 May 2025 23:01:02 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> See review thread slightly above here, specifically https://github.com/openjdk/jdk/pull/24315/files#r2094884157.
>> I've looked at the intrinsics for Object.clone() and Object.hashCode(), but only enough to decide I
>> understand the approach being taken here better than what's in those.
>
> As I understand, `JDK-8271862` was about migrating to non-virtual intrinsic method.
> In case of `Reference::get()`, you already have a virtual public method marked as `@IntrinsicCandidate`. And the patch doesn't change anything there.  So, unless I miss something, I believe the comment is misleading.

The comment is about why we have native `get0` at all, rather than just making
`get` also be native.

> [...] JDK-8271862 was about migrating to non-virtual intrinsic method.

That's not a correct summary of JDK-8271862. That change was about migrating
away from having a method that was all 3 of (1) intrinsic (2) native, and (3)
virtual. It split that method into two parts, and allocated the properties to
them in such a way that neither had all 3. There are several possible
allocations of the properties to the methods that would have worked. In this
case we already had all the machinary in place for `refersTo0` to be intrinsic
and native, so the allocation that didn't require a bunch of renaming for
consistency was to introduce `refersToImpl` to provide the virtual part.

For this PR we have a method that is already intrinsic and virtual. Of course,
we don't want to make it native too. Since we already have all the machinary
in place for `get` to be intrinsic and virtual, the allocation that didn't
require a bunch of renaming for consistency was to introduce native `get0` for
use as the non-intrinsic implementation of `get`. See also here:
https://github.com/openjdk/jdk/pull/24315#discussion_r2039137923

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2105706304

From stuefe at openjdk.org  Sat May 24 05:59:25 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 24 May 2025 05:59:25 GMT
Subject: RFR: 8357683: (process) SIGQUIT still blocked after JDK-8234262 with
 jdk.lang.Process.launchMechanism=FORK or VFORK
Message-ID: <4lcOGDk0oaJq6fR2RJZl9uQ_qkZFBCaw7Lz4LQhuccs=.91014969-a44b-48a1-982a-7ac3823ecf4e@github.com>

See bug description. We now unblock all signals in both FORK and POSIX_SPAWN launch modes. This fixes the problem and makes the behavior consistent across these two modes.

I left the VFORK mode alone since I believe the signal state is still shared with the parent. One more reason to get rid of this mode soon (it's deprecated with 25 and will be removed with 26)

The fix just moves the unblocking code from the jspawnhelper over to the child process function that is called for all three modes.

-----

Testing: I did various manual tests. I also tested that test/jdk/java/lang/ProcessBuilder/UnblockSignals.java succeeds with both POSIX_SPAWN and FORK mode now and that the behavior is unchanged (still broken) for VFORK mode.

ping @RogerRiggs I would like to get this still into JDK 25; the fix is small and clean enough to not worry me.

-------------

Commit messages:
 - unblock signals in fork mode

Changes: https://git.openjdk.org/jdk/pull/25428/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25428&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357683
  Stats: 30 lines in 3 files changed: 20 ins; 6 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25428.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25428/head:pull/25428

PR: https://git.openjdk.org/jdk/pull/25428

From alanb at openjdk.org  Sat May 24 06:31:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 24 May 2025 06:31:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v12]
In-Reply-To: <N9ttJx89WpqcbnaS-F1WgJIno4QNnPDocolTjvDvMYs=.1e335fc2-2922-46bf-8174-2f8a9372b0fa@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <3yhJMIdeMYvSuSooqqjfX59fOuIAce1QKtEcCWo8hLk=.c7ed89fc-90da-4485-b340-81bbe277ab07@github.com>
 <N9ttJx89WpqcbnaS-F1WgJIno4QNnPDocolTjvDvMYs=.1e335fc2-2922-46bf-8174-2f8a9372b0fa@github.com>
Message-ID: <sftaavZMojknfocwT6hizOUGksVGW4DxZzf0Pld3I-s=.fd48f535-5189-4f71-ae3c-0e7ae4082425@github.com>

On Fri, 23 May 2025 23:25:59 GMT, Xueming Shen <sherman at openjdk.org> wrote:

> Looks like I'm late to the party :-) My apologies if this has already been discussed a long time ago. My question is whether it's really necessary to restrict the 'read-only' flag to existing ZIP files only. I don't see any issue with allowing the creation of a new, empty ZIP file and marking it as read-only. Sure, it might be useless since it's just an empty zip file system, but that's up to the user. Not a very strong opinion though.

In the file system API, the "CREATE" option is specified to be ignored when opening a file for only reading. This means an I/O exception if the file doesn't exist. This was a pragmatic choice at the time that requires the full table of combinations and their outcome to see.

For zipfs, the doing the same, or rejecting having the env contain both create=true and accessMode=readOnly, is okay. We chatted with David about this recently and agreed that rejecting this combination makes the most sense. It means someone has opt'ed it for both options, which is different to the file system API where it defaults to "READ" if none of the read/write/append options are provided.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25178#issuecomment-2906503159

From chen.l.liang at oracle.com  Sat May 24 06:37:12 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sat, 24 May 2025 06:37:12 +0000
Subject: Integer::digits should be defined as byte[]
In-Reply-To: <c8bad838-af5e-4297-84ff-9eba4944ba92.shaojin.wensj@alibaba-inc.com>
References: <c8bad838-af5e-4297-84ff-9eba4944ba92.shaojin.wensj@alibaba-inc.com>
Message-ID: <CH3PR10MB76772BF7BE8B3223456AE6B4A29BA@CH3PR10MB7677.namprd10.prod.outlook.com>

I have one concern with byte conversion - now the arguments to StringUTF16.putChar is sign extended instead of zero extended. We need to ensure sign extension does not affect the intrinsics, maybe need static asserts to ensure all elements of the digit byte arrays are positive so we won't run into trouble with signed vs zero extension.

Once we can address this UTF16 risk, I think we are fine with the latin1 usages, and storing the digits as a byte array is indeed more memory efficient and is a good cleanup.

Regards,
Chen Liang
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of wenshao <shaojin.wensj at alibaba-inc.com>
Sent: Friday, May 23, 2025 10:47 PM
To: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Integer::digits should be defined as byte[]

Now Integer/Long uses Integer::digits to convert to byte, so we should define Integer::digits as byte[], which can avoid the conversion.

-
Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250524/00dd1329/attachment.htm>

From swen at openjdk.org  Sat May 24 07:12:31 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 24 May 2025 07:12:31 GMT
Subject: RFR: 8357685: Changing the type of Integer::digits from char[] to
 byte[]
Message-ID: <AmPJWWPyRS_K4NSNF-owbKNwxnmjuIYxvtzcGbHc8kE=.fdb3c265-0a41-4fc0-8078-36378422e2fa@github.com>

Integer::digits type can use byte[] instead of char[], which can reduce the conversion from char to byte in the process of Integer.toString. Using byte[] can also save memory.

-------------

Commit messages:
 - char[] -> byte[]

Changes: https://git.openjdk.org/jdk/pull/25426/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25426&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357685
  Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25426.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25426/head:pull/25426

PR: https://git.openjdk.org/jdk/pull/25426

From swen at openjdk.org  Sat May 24 07:19:24 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 24 May 2025 07:19:24 GMT
Subject: RFR: 8357685: Changing the type of Integer::digits from char[] to
 byte[] [v2]
In-Reply-To: <AmPJWWPyRS_K4NSNF-owbKNwxnmjuIYxvtzcGbHc8kE=.fdb3c265-0a41-4fc0-8078-36378422e2fa@github.com>
References: <AmPJWWPyRS_K4NSNF-owbKNwxnmjuIYxvtzcGbHc8kE=.fdb3c265-0a41-4fc0-8078-36378422e2fa@github.com>
Message-ID: <CxjW-nppciyh1wo9pqfo3N5k5pVvqeli6IFzMtNmqP4=.d14dc354-dcd7-459a-b0c9-3f731dfa548e@github.com>

> Integer::digits type can use byte[] instead of char[], which can reduce the conversion from char to byte in the process of Integer.toString. Using byte[] can also save memory.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  stable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25426/files
  - new: https://git.openjdk.org/jdk/pull/25426/files/c89694cb..3eb72204

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25426&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25426&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25426.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25426/head:pull/25426

PR: https://git.openjdk.org/jdk/pull/25426

From tvaleev at openjdk.org  Sat May 24 07:34:39 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 24 May 2025 07:34:39 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v5]
In-Reply-To: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
Message-ID: <Mb5G0tSGTV_8Xbsr9Cf0XzbZnwFd6y7N30geVuRuwv4=.7b74f612-d088-4508-a286-7e2a3f580a08@github.com>

> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
> 
> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
> 
> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Update exception description; update argument names

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25297/files
  - new: https://git.openjdk.org/jdk/pull/25297/files/38f9eb71..293b2c40

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=03-04

  Stats: 20 lines in 1 file changed: 2 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/25297.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25297/head:pull/25297

PR: https://git.openjdk.org/jdk/pull/25297

From tvaleev at openjdk.org  Sat May 24 07:34:39 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 24 May 2025 07:34:39 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v4]
In-Reply-To: <fapUpKyaRth2d7UyYx2pZPmG-2ohB0lzYrTy_26BNuA=.68493b43-a078-46bd-96af-66c1a90fea3f@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <n7RU1Hlm2BjJA1GovR1H_4Ibg-nDn45Jr2BaFrsqqew=.3940c815-60f6-4bc0-89e1-0469f395eca7@github.com>
 <fapUpKyaRth2d7UyYx2pZPmG-2ohB0lzYrTy_26BNuA=.68493b43-a078-46bd-96af-66c1a90fea3f@github.com>
Message-ID: <SJzCl13RX84FCRkhF5uNhRlAQ126K31fsiEDdcaNPCQ=.06cdf1f1-33c4-49ec-a94e-bc669ef9f556@github.com>

On Fri, 23 May 2025 20:37:05 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make min and max generic
>
> src/java.base/share/classes/java/util/Comparator.java line 200:
> 
>> 198:      * @param   <U> the type of the arguments and the result.
>> 199:      * @return  the larger of {@code a} and {@code b} according to this comparator.
>> 200:      * @throws  ClassCastException if the collection contains elements that are
> 
> What 'collection' meaned here?

Good catch, thank you. The description was copied from `Collections::max`, which is not so appropriate here. I think it's better to copy it from `Comparator::compare` (also, added `@throws NPE` for consistency).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2105747341

From tvaleev at openjdk.org  Sat May 24 07:34:40 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 24 May 2025 07:34:40 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v4]
In-Reply-To: <OkkymXyJdws4_Q5lKy1UayKoIkMB_yXA1flO9uNrhOY=.6c04512c-1a84-4e1b-b2f3-812d9b22d24f@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <n7RU1Hlm2BjJA1GovR1H_4Ibg-nDn45Jr2BaFrsqqew=.3940c815-60f6-4bc0-89e1-0469f395eca7@github.com>
 <OkkymXyJdws4_Q5lKy1UayKoIkMB_yXA1flO9uNrhOY=.6c04512c-1a84-4e1b-b2f3-812d9b22d24f@github.com>
Message-ID: <w-5bDWOmzxyQvKlLyxyCUr9NfD_XRE9ey2B_URN3LxU=.54df9396-0ef2-4f82-8f64-9ffcecdb9cfb@github.com>

On Fri, 23 May 2025 18:57:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make min and max generic
>
> src/java.base/share/classes/java/util/Comparator.java line 206:
> 
>> 204:      * @since 25
>> 205:      */
>> 206:     default <U extends T> U max(U a, U b) {
> 
> The parameter names are o1 and o2 in the `compare` method min and max build on. 
> Though a and b are used in the class javadoc example and x and y are used in the spec description.
> Can we be consistent in the API?  (o1, o2) perhaps.  Someday, the parameter names *may* be more significant.

Done, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2105746862

From stuefe at openjdk.org  Sat May 24 10:05:10 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 24 May 2025 10:05:10 GMT
Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(),
 use FD_CLOEXEC instead of close() [v2]
In-Reply-To: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
References: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
Message-ID: <1_5zQCiLjBsuUquWR3ucXwGQs_ZdqMVU70aMEBg9rTo=.ebb95bf5-4326-45c6-a374-b8ffac0da485@github.com>

> Hi, please consider the following patch.
> 
> This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc.
> 
> This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens).
> 
> Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409
> 
> This patch also fixes two subtle bugs:
> - we didn't check the return value of the close() inside closeAllFileDescriptors
> - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it)
> 
> ----
> 
> Testing:
> 
> We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC.
> 
> - in the parent JVM, the test opens a file in native code without FD_CLOEXEC
> - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open
> 
> I verified that the test correctly detects a broken implementation that leaks file descriptors. 
> 
> I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX).
> 
> I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green.

Thomas Stuefe has updated the pull request with a new target base 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 'openjdk:master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close-
 - close dir fd on fcntl error
 - Mark fds with cloexec, plus test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25301/files
  - new: https://git.openjdk.org/jdk/pull/25301/files/0e0d64a6..8543a5ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25301&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25301&range=00-01

  Stats: 45124 lines in 663 files changed: 30512 ins; 11063 del; 3549 mod
  Patch: https://git.openjdk.org/jdk/pull/25301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25301/head:pull/25301

PR: https://git.openjdk.org/jdk/pull/25301

From stuefe at openjdk.org  Sat May 24 10:15:44 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 24 May 2025 10:15:44 GMT
Subject: RFR: 8357683: (process) SIGQUIT still blocked after JDK-8234262
 with jdk.lang.Process.launchMechanism=FORK or VFORK [v2]
In-Reply-To: <4lcOGDk0oaJq6fR2RJZl9uQ_qkZFBCaw7Lz4LQhuccs=.91014969-a44b-48a1-982a-7ac3823ecf4e@github.com>
References: <4lcOGDk0oaJq6fR2RJZl9uQ_qkZFBCaw7Lz4LQhuccs=.91014969-a44b-48a1-982a-7ac3823ecf4e@github.com>
Message-ID: <PJ6kUa4lWZU68M6BPDEnV-bIz4oFr-r1cKE1gWmLGWY=.bfccefeb-3855-43ea-b64d-ba8774665efa@github.com>

> See bug description. We now unblock all signals in both FORK and POSIX_SPAWN launch modes. This fixes the problem and makes the behavior consistent across these two modes.
> 
> I left the VFORK mode alone since I believe the signal state is still shared with the parent. One more reason to get rid of this mode soon (it's deprecated with 25 and will be removed with 26)
> 
> The fix just moves the unblocking code from the jspawnhelper over to the child process function that is called for all three modes.
> 
> -----
> 
> Testing: I did various manual tests. I also tested that test/jdk/java/lang/ProcessBuilder/UnblockSignals.java succeeds with both POSIX_SPAWN and FORK mode now and that the behavior is unchanged (still broken) for VFORK mode.
> 
> ping @RogerRiggs I would like to get this still into JDK 25; the fix is small and clean enough to not worry me.

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8357683-process-SIGQUIT-still-blocked-after-JDK-8234262-with-jdk-lang-Process-launchMechanism=FORK-or-VFORK
 - unblock signals in fork mode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25428/files
  - new: https://git.openjdk.org/jdk/pull/25428/files/6e759200..0744f5b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25428&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25428&range=00-01

  Stats: 732 lines in 27 files changed: 298 ins; 297 del; 137 mod
  Patch: https://git.openjdk.org/jdk/pull/25428.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25428/head:pull/25428

PR: https://git.openjdk.org/jdk/pull/25428

From orionllmain at gmail.com  Sat May 24 10:35:59 2025
From: orionllmain at gmail.com (Zheka Kozlov)
Date: Sat, 24 May 2025 15:35:59 +0500
Subject: Finding max or min of exactly two objects
In-Reply-To: <CAE+3fja-oo=Yxxs9gQ9cTnCStYOBtf1oey3Dn6F2dNjbfievCg@mail.gmail.com>
References: <CAE+3fja-oo=Yxxs9gQ9cTnCStYOBtf1oey3Dn6F2dNjbfievCg@mail.gmail.com>
Message-ID: <CAF2POUfFAUKORa_eVnreMqNF8t0eW8xmt429YotZ7-i2nm3VLg@mail.gmail.com>

Collections.max(List.of(a, b))?

On Tue, May 13, 2025 at 7:12?PM Tagir Valeev <amaembo at gmail.com> wrote:

> The alternatives we have now:
> BinaryOperator.maxBy(Comparator.<T>naturalOrder()).apply(a, b);
> This speaks clearly about the intent (we'd like to get the maximum and we
> write 'maxBy') but very wordy.
>
> Stream.of(a, b).max(Comparator.naturalOrder()).get();
> Also clear and a little bit shorter, but has an unnecessary Optional
> in-between (we know that we have at least one element, so the result is
> always present) and we have to mention the comparator. Finally, it might be
> much less efficient than expected.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250524/ce87b329/attachment.htm>

From rgiulietti at openjdk.org  Sat May 24 11:33:50 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sat, 24 May 2025 11:33:50 GMT
Subject: RFR: 8357685: Change the type of Integer::digits from char[] to
 byte[] [v2]
In-Reply-To: <CxjW-nppciyh1wo9pqfo3N5k5pVvqeli6IFzMtNmqP4=.d14dc354-dcd7-459a-b0c9-3f731dfa548e@github.com>
References: <AmPJWWPyRS_K4NSNF-owbKNwxnmjuIYxvtzcGbHc8kE=.fdb3c265-0a41-4fc0-8078-36378422e2fa@github.com>
 <CxjW-nppciyh1wo9pqfo3N5k5pVvqeli6IFzMtNmqP4=.d14dc354-dcd7-459a-b0c9-3f731dfa548e@github.com>
Message-ID: <_CeVJknp399J9ellTJ3b_hYgqumGHNo9pyypvedtWIE=.c0d8e795-16dd-4b5f-a6bc-64284016c221@github.com>

On Sat, 24 May 2025 07:19:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Integer::digits type can use byte[] instead of char[], which can reduce the conversion from char to byte in the process of Integer.toString. Using byte[] can also save memory.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stable

@liach Chen, you were [concerned](https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/146655.html) that the fact that StringUTF16.putChar does sign extension might introduce errors.
I don't think there's any issue here, as all bytes are just ASCII.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25426#issuecomment-2906784048

From dl at openjdk.org  Sat May 24 11:39:01 2025
From: dl at openjdk.org (Doug Lea)
Date: Sat, 24 May 2025 11:39:01 GMT
Subject: RFR: 8357146: ForkJoinPool:schedule(*) does not throw
 RejectedExecutionException when pool is shutdown
Message-ID: <qnY_DbR3b52ILHFE9lxchxhF1mAiykq-QNd961efDiU=.8f497802-a9e1-41f6-951c-a56eb4a6ee6f@github.com>

Method startDelayScheduler should trap the ISE thrown by SharedThreadContainer.start and possibly re-try termination before eventually throwing RejectedExecutionException.

-------------

Commit messages:
 - undo wrong origin
 - Handle IllegalStateException from SharedThreadContainer.start
 - Reveert for master
 - Handle IllegalStateException thrown by SharedThreadContainer.start

Changes: https://git.openjdk.org/jdk/pull/25431/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25431&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357146
  Stats: 32 lines in 2 files changed: 25 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25431/head:pull/25431

PR: https://git.openjdk.org/jdk/pull/25431

From rgiulietti at openjdk.org  Sat May 24 11:48:50 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sat, 24 May 2025 11:48:50 GMT
Subject: RFR: 8357685: Change the type of Integer::digits from char[] to
 byte[] [v2]
In-Reply-To: <CxjW-nppciyh1wo9pqfo3N5k5pVvqeli6IFzMtNmqP4=.d14dc354-dcd7-459a-b0c9-3f731dfa548e@github.com>
References: <AmPJWWPyRS_K4NSNF-owbKNwxnmjuIYxvtzcGbHc8kE=.fdb3c265-0a41-4fc0-8078-36378422e2fa@github.com>
 <CxjW-nppciyh1wo9pqfo3N5k5pVvqeli6IFzMtNmqP4=.d14dc354-dcd7-459a-b0c9-3f731dfa548e@github.com>
Message-ID: <b7rt8AQitGbvQAqUtzle9mQJ-1XAJiMvFo64cWVIGUI=.7380fd24-029e-469f-bb61-7c088a4d53ba@github.com>

On Sat, 24 May 2025 07:19:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Integer::digits type can use byte[] instead of char[], which can reduce the conversion from char to byte in the process of Integer.toString. Using byte[] can also save memory.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stable

LGTM

@wenshao Please wait for @liach to chime in before integrating.

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25426#pullrequestreview-2866268850

From duke at openjdk.org  Sat May 24 14:21:51 2025
From: duke at openjdk.org (duke)
Date: Sat, 24 May 2025 14:21:51 GMT
Subject: RFR: 8357644: Add missing CPE statements
In-Reply-To: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com>
References: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com>
Message-ID: <-Mzt3yKum66jRPdxCy4z0c5biCuGrt8Rf-FFrcT6YN0=.2e4b8042-e224-4bf1-a385-00504073ef96@github.com>

On Fri, 23 May 2025 11:40:24 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

> Adds missing classpath exception in a couple of files.

@Sorna-Sarathi 
Your change (at version 1778c756b997c47938fff1bf15bb8c6b5b855af5) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25413#issuecomment-2906857408

From markus at headcrashing.eu  Sat May 24 14:37:15 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Sat, 24 May 2025 16:37:15 +0200
Subject: RFC: 8357183: Improving efficiency of Writer::append(CharSequence)
 and Writer::append(CharSequence, int, int) / Sub Task of 8356679: Using
 CharSequence::getChars internally
In-Reply-To: <SJ2PR10MB766968186EE02189D1D9039DA29DA@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <f4cf0270-eb00-4c52-99a4-8e8057bb2bc9@gmx.net>
 <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com>
 <f4330452-258c-42f8-a24b-9217da839892@headcrashing.eu>
 <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com>
 <b43e53d6-eb0b-4074-80e4-ca7bc0bf64f0@headcrashing.eu>
 <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com>
 <8b59d6d1-fcf8-4be8-93a2-8b5b434b2174@headcrashing.eu>
 <SJ2PR10MB766968186EE02189D1D9039DA29DA@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <e6a9e852-2dda-4e3f-9915-2d43c1b333f2@headcrashing.eu>

Chen,


thank you for your approval for a DRAFT PR.


Following your proposal, I have published a DRAFT PR at 
https://github.com/openjdk/jdk/pull/25432 so everybody can see what the 
actual intended code change looks like, and better focus on that actual 
code change and its risks and benefits. The intention of that DRAFT PR 
explicitly is NOT to request code reviews, but solely to serve as a 
publicly visible piece of code to support the ongoing discussion here on 
this mailing list.


TARGET VERSION: 26


As we are near to JDK 25 GA, the target is inclusion into JDK 26 or 
later, so no need to rush. Nevertheless, I would be happy if everybody 
comments ASAP (at least briefly) to keep this discussion alive.


PRELIMINARY RISK ANALYSIS: LOW


Given the changes at hand now, I have performed a brief corpus analysis 
using Github Copilot (using the public Code Repositories of OpenJDK 
itself, but also the repositories of Apache Foundation and Eclipse 
Foundation) to see if the proposed change implies REAL risk due to its 
change of behavior. The result was that Github Copilot was UNABLE to 
find at least one single Java class that would fail after the proposed 
change of this draft PR. While many classes extend Writer directly or 
indirectly, only few have (nor their super- nor subclasses) an 
implementation of the now skipped methods write(String) or write(String, 
int, int). Those that do have (nor their super- nor subclasses) are NOT 
receiving append(CharSequence) or append(CharSequence, int, int) calls, 
or they (or their super- or subclasses) implement write(String) or 
write(String, int, int) as an alias to append(CharSequence) or 
append(CharSequence, int, int) - hence they already explicitly do what 
the DRAFT PR proposes to do implicitly in future. So at least for this 
brief analysis, the ACTUAL risk to break existing code seems to be 
rather small actually (in contrast to the ASSUMED risk looking at 
"append" being there since JDK 5). NB: Having said that, one such class 
WAS actually found by Github Copilot, but I explicitly removed it from 
the search result, as I already knew it is still working correctly, as 
it is an internal "sun" class of OpenJDK which I have already visited 
manually in preparation of this PR.


NEXT STEPS


* Please anybody take note of the code change found in the DRAFT PR at 
https://github.com/openjdk/jdk/pull/25432 in the next few weeks to see 
if anything prevents us from turning this PR from the DRAFT state into 
the RFR state.


* Unless this discussion points us towards dropping the DRAFT PR, in the 
next weeks eventually I will open a CSR for approval of the behavior 
change, basing on the result of the attended brief corpus analysis.


Thanks everybody for sharing your comments!


-Markus



Am 18.05.2025 um 22:50 schrieb Chen Liang:
> Hi Markus,
> I think you can submit a draft PR - while some people here like Alan 
> Bateman use draft PRs to indicate "not ready for any review" and 
> discussions are not forwarded to the mailing lists, they are still 
> very useful for looking at the change set.
>
> Note that we are a few short weeks from RDP1 of 25 - while I also wish 
> improvements can be integrated into the JDK, there is no guarantee 
> that they will make 25, and we shouldn't rush changes in order to 
> catch up with a release train.
>
> Regards, Chen
> ------------------------------------------------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of 
> Markus KARG <markus at headcrashing.eu>
> *Sent:* Sunday, May 18, 2025 10:09 AM
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: RFC: 8356679: Using CharSequence::getChars internally
> Roger,
>
> thank you for your comments.
>
> Following your advice I have splitted the larger work of JDK-8356679
> into sub tasks.
>
> I would like to start with a first PR implementing the *foundational*
> work, i. e. optimizing Writer::append for efficiency (JDK-8357183). For
> convenience, attached below is a copy of the description.
>
> Comments Welcome!
>
> If everybody is fine with this, I would be happy to get some +1 to
> publish the PR for JDK-8357183!
>
> Am 14.05.2025 um 15:57 schrieb Roger Riggs:
> > Hi Markus,
> >
> > Starting out with the common case is a good idea for the first PR.
> >
> > I much prefer a PR with a single goal and that comes to a conclusion
> > and does not add new features or changes after the PR is submitted.
> > I tend to lose interest in PRs with lots of churn, it means I have to
> > re-review the bulk of it when there is a change and may wait days to
> > let it settle down before coming back to it.
> >
> > I tend to think the PR was not really ready to be reviewed if simple
> > issues and corrections have to be made frequently.
> > Do your own checking for typos and copyrights and simple refactoring
> > before opening the PR.
> > Quality before quantity or speed.
> >
> > I'm fine with separate Jira issues that clearly delineate a specific
> > scope and goal.
> >
> > The title of this issue (8356679) doesn't identify the real goal.
> > It seems to be to improve performance or memory usage, not just to use
> > a new API.
> >
> > These are my personal opinions about contributions and process.
> >
> > Regards, Roger
> >
> >
> > On 5/14/25 6:48 AM, Markus KARG wrote:
> >> Many of the modified classes derive from a common super class and
> >> share one needed common change (which is one of the points which are
> >> easy to see once you see all of those classes in a single PR, but
> >> hard to explain in plaint-text pre-PR mailing list threads), so at
> >> least those need to be discussed *together*. But to spare JBS and
> >> PRs, I can open the PR with just the first set of changes, and once
> >> we agree that this set is fine, I can push the next commit *in the
> >> same PR*. Otherwise we would need endless JBS, mailing list threads,
> >> and PRs, just to fixe a dozen internal code lines.
> >>
> >> Having said that, does the current state of this thread count as
> >> "reached common agreement to file a PR" or do I still have to wait
> >> until more people chime in?
> >>
> >> -Markus
> >>
> >>
> >> Am 13.05.2025 um 15:10 schrieb Roger Riggs:
> >>> Hi Markus,
> >>>
> >>> A main point was to avoid trying to do everything at once.
> >>> The PR comments become hard to follow and intermingled and it takes
> >>> longer to get agreement because of the thrash in the PR.
> >>>
> >>> Roger
> >>>
> >>> On 5/13/25 5:05 AM, Markus KARG wrote:
> >>>> Thank you, Roger.
> >>>>
> >>>> Actually the method helps in the "toString()" variants, too, as in
> >>>> some places we could *get rid* of "toString()" (which is more work
> >>>> than "just" a buffer due to the added compression complexity).
> >>>>
> >>>> In fact, I already took the time to rewrite *all* of them while
> >>>> waiting for the approval of this list posting. In *all* cases
> >>>> *less* buffering / copying is needed, and *less* "toString()"
> >>>> conversion (which is a copy under the hood) is needed. So if I
> >>>> would be allowed to show the code as a PR, it would be much easier
> >>>> to explain and discuss.
> >>>>
> >>>> A PR is the best place to discuss "how to code would change". In
> >>>> the worst case, let's drop it if we see that it is actually a bad
> >>>> thing.
> >>>>
> >>>> -Markus
> >>>>
> >>>>
> >>>> Am 12.05.2025 um 20:18 schrieb Roger Riggs:
> >>>>> Hi Markus,
> >>>>>
> >>>>> On the surface, its looks constructive.
> >>>>> I suspect that many of these cases will turn into discussions
> >>>>> about the right/best/better way to buffer the characters.
> >>>>> The getChars method only helps when extracting to a char array,
> >>>>> many of the current implementations create strings as the
> >>>>> intermediary. The advantage of the 1 character at a time technique
> >>>>> is not needing a (separated allocated) buffer.
> >>>>> Consider taking a few at a time before launching into the whole set.
> >>>>>
> >>>>> $.02, Roger
> >>>>>
> >>>>> On 5/11/25 2:45 AM, Markus KARG wrote:
> >>>>>> Dear Core Libs Team,
> >>>>>>
> >>>>>> I am hereby requesting comments on JDK-8356679.
> >>>>>>
> >>>>>> I would like to invest some time and set up a PR implementing
> >>>>>> Chen Liangs's proposal laid out in
> >>>>>> https://bugs.openjdk.org/browse/JDK-8356679. For your
> >>>>>> convenience, the text of that JBS is copied below. According to
> >>>>>> the Developer's Guide I do need to get broad agreement BEFORE
> >>>>>> filing a PR. Therefore, I kindly ask everybody to briefly show
> >>>>>> consent, so I may file a PR.
> >>>>>>
> >>>>>> Thanks
> >>>>>> -Markus
> >>>>>>
> >>>>>>
> >>>>>> Copy from https://bugs.openjdk.org/browse/JDK-8356679:
> >>>>>>
> >>>>>> Recently OpenJDK adopted the new method
> >>>>>> CharSequence::getChars(int, int, char[], int) for inclusion in
> >>>>>> Java 25. As a bulk reader method, it allows potentially improved
> >>>>>> efficiency over the previously available char-by-char reader
> >>>>>> method CharSequence::charAt(int).
> >>>>>>
> >>>>>> Chen Liang suggested on March 23rd on the core-lib-dev mailing
> >>>>>> list to use the new method within the internal source code of
> >>>>>> OpenJDK for the implementation of Appendables (see
> >>>>>> 
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html).
> >>>>>> The idea behind this is that the implementations might be more
> >>>>>> efficient then.
> >>>>>>
> >>>>>> A quick analysis of the OpenJDK source code identified (at least)
> >>>>>> the following classes which could potentially run more efficient
> >>>>>> when using CharSequence::getChars internally, thanks to bulk
> >>>>>> reading and / or prevention of internal copies / toString()
> >>>>>> conversions:
> >>>>>> * java.io.Writer
> >>>>>> * java.io.StringWriter
> >>>>>> * java.io.PrintWriter
> >>>>>> * java.io.BufferedWriter
> >>>>>> * java.io.CharArrayWriter
> >>>>>> * java.io.FileWriter
> >>>>>> * java.io.OutputStreamWriter
> >>>>>> * sun.nio.cs.StreamEncoder
> >>>>>> * java.io.PrintStream
> >>>>>> * java.nio.CharBuffer
> >>>>>>
> >>>>>> In the sense of "eat your own dog food", it makes sense to
> >>>>>> implement Chen's idea in (at least) those classes. Possibly more
> >>>>>> classes could get identified when taking a deeper look. Besides
> >>>>>> the potential efficiency improvements, it would be a good show
> >>>>>> case for the usage of the new API.
> >>>>>>
> >>>>>> The risk of this change should be low, as test coverage exists,
> >>>>>> and as the intended changes are solely internal to the
> >>>>>> implementation. No API will get changed. In some cases the
> >>>>>> JavaDocs will get slightly adapted where it currently exposes the
> >>>>>> actual implementation (to not lie in future).
> >>>>>>
> >>>>>
> >>>
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250524/400a15a6/attachment-0001.htm>

From ssarathi at openjdk.org  Sat May 24 15:08:58 2025
From: ssarathi at openjdk.org (Sorna Sarathi N)
Date: Sat, 24 May 2025 15:08:58 GMT
Subject: Integrated: 8357644: Add missing CPE statements
In-Reply-To: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com>
References: <5x45rlR_mNb2z9JRPVNR9U2OaNZxS7rmqRC8bGI68sA=.f3a5da66-5bc0-4201-b40b-9073851d8991@github.com>
Message-ID: <ylsBRlyKpZOpia59u0R4sowDsLIevvr7YiqmKzN4r14=.9f712146-0346-4ce8-a4cd-af58c0ebbc7a@github.com>

On Fri, 23 May 2025 11:40:24 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

> Adds missing classpath exception in a couple of files.

This pull request has now been integrated.

Changeset: 1f24a541
Author:    Sorna Sarathi N <ssarathi at openjdk.org>
Committer: Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f24a5414d735f9faaabd5b49f786419a40d9da5
Stats:     6 lines in 2 files changed: 4 ins; 0 del; 2 mod

8357644: Add missing CPE statements

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/25413

From alanb at openjdk.org  Sat May 24 15:59:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 24 May 2025 15:59:57 GMT
Subject: RFR: 8357146: ForkJoinPool:schedule(*) does not throw
 RejectedExecutionException when pool is shutdown
In-Reply-To: <qnY_DbR3b52ILHFE9lxchxhF1mAiykq-QNd961efDiU=.8f497802-a9e1-41f6-951c-a56eb4a6ee6f@github.com>
References: <qnY_DbR3b52ILHFE9lxchxhF1mAiykq-QNd961efDiU=.8f497802-a9e1-41f6-951c-a56eb4a6ee6f@github.com>
Message-ID: <HrY8oEMMeWz0u7KWhY6d3_AfjHiheP2GEfSED_LcdEA=.70dca138-1972-4ab5-90af-7ca41937742c@github.com>

On Sat, 24 May 2025 11:35:33 GMT, Doug Lea <dl at openjdk.org> wrote:

> Method startDelayScheduler should trap the ISE thrown by SharedThreadContainer.start and possibly re-try termination before eventually throwing RejectedExecutionException.

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3475:

> 3473:                     ds = delayScheduler = null;
> 3474:                     unlockRunState();
> 3475:                     tryTerminate(false, false);

This reset okay, and the schedule methods will throw REE. The change makes me wonder about the  OOME "unable to create new native thread" scenario, should the schedule methods propagate it or throw REE with the OOME as cause?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25431#discussion_r2105868632

From liach at openjdk.org  Sat May 24 16:06:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 24 May 2025 16:06:50 GMT
Subject: RFR: 8357685: Change the type of Integer::digits from char[] to
 byte[] [v2]
In-Reply-To: <CxjW-nppciyh1wo9pqfo3N5k5pVvqeli6IFzMtNmqP4=.d14dc354-dcd7-459a-b0c9-3f731dfa548e@github.com>
References: <AmPJWWPyRS_K4NSNF-owbKNwxnmjuIYxvtzcGbHc8kE=.fdb3c265-0a41-4fc0-8078-36378422e2fa@github.com>
 <CxjW-nppciyh1wo9pqfo3N5k5pVvqeli6IFzMtNmqP4=.d14dc354-dcd7-459a-b0c9-3f731dfa548e@github.com>
Message-ID: <eJoFdVKfGCXuF4IHazKq140hwGml_k-K3jvsuRR_fzE=.23e2ae34-5441-4667-9596-8c1971bd419a@github.com>

On Sat, 24 May 2025 07:19:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Integer::digits type can use byte[] instead of char[], which can reduce the conversion from char to byte in the process of Integer.toString. Using byte[] can also save memory.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stable

Just noted java compiler has lossy conversion warning, so if we have a >127 char literal in the array initializer, we would encounter a compile error. All good to me.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25426#pullrequestreview-2866371571

From swen at openjdk.org  Sat May 24 17:10:56 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 24 May 2025 17:10:56 GMT
Subject: Integrated: 8357081: Removed unused methods of HexDigits
In-Reply-To: <NmneRyd1Xg5PGjAiG1Pgq5dqkWMiE23LRjALLutkoyA=.912425d2-b549-40f7-bea2-46f2f869fa30@github.com>
References: <NmneRyd1Xg5PGjAiG1Pgq5dqkWMiE23LRjALLutkoyA=.912425d2-b549-40f7-bea2-46f2f869fa30@github.com>
Message-ID: <znd0Fo9tfQPjnX6gLHnizCS2IURPbVrQsXQn5ooP6XI=.92931ea3-fa8d-4da0-9ba8-3c2b1e2dcd38@github.com>

On Thu, 15 May 2025 22:03:22 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In HexDigits, getCharsLatin1 and getCharsUTF16 are no longer used, so remove these methods

This pull request has now been integrated.

Changeset: b0373537
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b037353734fd67f8898eb797a041bc1152a18178
Stats:     69 lines in 1 file changed: 0 ins; 69 del; 0 mod

8357081: Removed unused methods of HexDigits

Reviewed-by: rriggs, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/25258

From shaojin.wensj at alibaba-inc.com  Sat May 24 17:55:30 2025
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Sun, 25 May 2025 01:55:30 +0800
Subject: =?UTF-8?B?QWRkIEBTdGFibGUgdG8gamF2YS5sYW5nLkNoYXJhY3RlckRhdGFMYXRpbjEgYW5kIG90aGVy?=
 =?UTF-8?B?IENoYXJhY3RlckRhdGEgY2xhc3Nlcw==?=
Message-ID: <7ccc3056-c4a7-4c82-b66b-37547c2ce92f.shaojin.wensj@alibaba-inc.com>

Classes such as java.lang.CharacterDataXXX have multiple static final arrays, which will not be modified. We should add @Stable to provide information to the optimizer.
such as
```java
class CharacterData00 {
@Stable static final char[] X =
@Stable static final char[] Y =
@Stable static final int[] A =
@Stable static final char[] B =
}
```
-
Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250525/6796825a/attachment.htm>

From chen.l.liang at oracle.com  Sat May 24 23:16:17 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sat, 24 May 2025 23:16:17 +0000
Subject: Add @Stable to java.lang.CharacterDataLatin1 and other
 CharacterData classes
In-Reply-To: <7ccc3056-c4a7-4c82-b66b-37547c2ce92f.shaojin.wensj@alibaba-inc.com>
References: <7ccc3056-c4a7-4c82-b66b-37547c2ce92f.shaojin.wensj@alibaba-inc.com>
Message-ID: <SJ2PR10MB766972482EB6A8C5D947E61AA29BA@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hello Shaojin,
I think your proposal is reasonable. These arrays are never mutated. Meanwhile I see some declarations like int A[] in CharacterData00, would be nice if you can convert those declarations to like int[] A too.

Regards,
Chen
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of wenshao <shaojin.wensj at alibaba-inc.com>
Sent: Saturday, May 24, 2025 12:55 PM
To: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Add @Stable to java.lang.CharacterDataLatin1 and other CharacterData classes

Classes such as java.lang.CharacterDataXXX have multiple static final arrays, which will not be modified. We should add @Stable to provide information to the optimizer.

such as

```java
class CharacterData00 {
    @Stable static final char[] X =
    @Stable static final char[] Y =
    @Stable static final int[] A =
    @Stable static final char[] B =
}
```

-
Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250524/ed0a77ef/attachment.htm>

From liach at openjdk.org  Sun May 25 00:08:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 May 2025 00:08:32 GMT
Subject: RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes
In-Reply-To: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
Message-ID: <SkefXOgWvwBGHB9E7xwMVCCnTMjrFN1-f_mOuhdWr6E=.e4372b37-df4f-4162-aeac-adee53693d95@github.com>

On Sat, 24 May 2025 10:00:56 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, which will not be modified. We should add @Stable to provide information to the optimizer.

make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 1195:

> 1193:             result.append("  @Stable static final ");
> 1194:         result.append(atype);
> 1195:         result.append(" ").append(name).append("[");

While you are at it - when Csyntax == false, can we make it print `atype[] name` instead of `atype name[]`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25430#discussion_r2106007546

From swen at openjdk.org  Sun May 25 00:08:32 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 25 May 2025 00:08:32 GMT
Subject: RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes
In-Reply-To: <SkefXOgWvwBGHB9E7xwMVCCnTMjrFN1-f_mOuhdWr6E=.e4372b37-df4f-4162-aeac-adee53693d95@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
 <SkefXOgWvwBGHB9E7xwMVCCnTMjrFN1-f_mOuhdWr6E=.e4372b37-df4f-4162-aeac-adee53693d95@github.com>
Message-ID: <IyYM42Kj1ai1jpEKA0gjAKKbQ8L35PLr0W37aflOAnI=.250ed4b3-ad4f-43df-9827-8fb077edf1d2@github.com>

On Sat, 24 May 2025 23:04:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, which will not be modified. We should add @Stable to provide information to the optimizer.
>
> make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 1195:
> 
>> 1193:             result.append("  @Stable static final ");
>> 1194:         result.append(atype);
>> 1195:         result.append(" ").append(name).append("[");
> 
> While you are at it - when Csyntax == false, can we make it print `atype[] name` instead of `atype name[]`?

This will require more changes, and has no benefits other than better coding style.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25430#discussion_r2106030868

From swen at openjdk.org  Sun May 25 00:08:32 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 25 May 2025 00:08:32 GMT
Subject: RFR: 8357690: Add @Stable and final to java.lang.CharacterDataLatin1
 and other CharacterData classes
Message-ID: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>

Classes such as java.lang.CharacterDataXXX have multiple static final arrays, which will not be modified. We should add @Stable to provide information to the optimizer.

-------------

Commit messages:
 - sealed & final
 - add @Stable
 - stable

Changes: https://git.openjdk.org/jdk/pull/25430/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25430&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357690
  Stats: 31 lines in 10 files changed: 15 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25430/head:pull/25430

PR: https://git.openjdk.org/jdk/pull/25430

From liach at openjdk.org  Sun May 25 00:08:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 May 2025 00:08:32 GMT
Subject: RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes
In-Reply-To: <IyYM42Kj1ai1jpEKA0gjAKKbQ8L35PLr0W37aflOAnI=.250ed4b3-ad4f-43df-9827-8fb077edf1d2@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
 <SkefXOgWvwBGHB9E7xwMVCCnTMjrFN1-f_mOuhdWr6E=.e4372b37-df4f-4162-aeac-adee53693d95@github.com>
 <IyYM42Kj1ai1jpEKA0gjAKKbQ8L35PLr0W37aflOAnI=.250ed4b3-ad4f-43df-9827-8fb077edf1d2@github.com>
Message-ID: <CeCOd9mfG2XAQ8LLZFPRBlNwrcU7TZtFIbEh0u8RMvM=.7886f86c-7acc-4ebc-b245-8a623391fa7a@github.com>

On Sat, 24 May 2025 23:40:56 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 1195:
>> 
>>> 1193:             result.append("  @Stable static final ");
>>> 1194:         result.append(atype);
>>> 1195:         result.append(" ").append(name).append("[");
>> 
>> While you are at it - when Csyntax == false, can we make it print `atype[] name` instead of `atype name[]`?
>
> This will require more changes, and has no benefits other than better coding style.

Reasonable. These generated classes have a lot of code improvement opportunities that do not affect program semantics. We should handle those in a dedicated RFE.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25430#discussion_r2106038820

From liach at openjdk.org  Sun May 25 04:43:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 May 2025 04:43:55 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods [v3]
In-Reply-To: <SMAz5R1EFhePJhslGUGTDYdAPuPJGbfmn6t14cDpiXc=.950cf100-d65b-4fa4-8ae7-fe28d990b4f9@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
 <SMAz5R1EFhePJhslGUGTDYdAPuPJGbfmn6t14cDpiXc=.950cf100-d65b-4fa4-8ae7-fe28d990b4f9@github.com>
Message-ID: <zPUdIfuQMhGCj1KqpyQOPBDsz2n2s3RXypGeF_ried0=.54e79fee-a013-4ca3-b82a-f434e8955abb@github.com>

On Tue, 20 May 2025 02:11:34 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline.
>> 
>> The following is the output information of PrintInlining:
>> 
>>                 @ 9   java.lang.String::<init> (12 bytes)   inline (hot)
>> !m                 @ 1   java.nio.charset.Charset::defaultCharset (52 bytes)   inline (hot)
>> !                  @ 8   java.lang.String::<init> (852 bytes)   failed to inline: hot method too big
>> 
>> 
>> In Java code, the big method that cannot be inlined is the following constructor
>> 
>> 
>> String(Charset charset, byte[] bytes, int offset, int length) {}
>> 
>> The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   create method share variant val & coder

src/java.base/share/classes/java/lang/String.java line 569:

> 567:         }
> 568:         this.value = str.value;
> 569:         this.coder = str.coder;

Suggestion:

        this(str);

We have integrated flexible constructor bodies.

src/java.base/share/classes/java/lang/String.java line 646:

> 644:     }
> 645: 
> 646:     private static String create(Charset charset, byte[] bytes, int offset, int length) {

Should we call this "decode", as "create" feels too generic?

src/java.base/share/classes/java/lang/String.java line 703:

> 701:                 throw new Error(x);
> 702:             }
> 703:             if (COMPACT_STRINGS) {

Now we can call other constructors of String, so instead of having this manual handling of char[], we can call `return new String(ca, 0, caLen, null)`. Same for the `clen` version above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2106082898
PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2106082727
PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2106082563

From swen at openjdk.org  Sun May 25 04:50:08 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 25 May 2025 04:50:08 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods [v3]
In-Reply-To: <zPUdIfuQMhGCj1KqpyQOPBDsz2n2s3RXypGeF_ried0=.54e79fee-a013-4ca3-b82a-f434e8955abb@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
 <SMAz5R1EFhePJhslGUGTDYdAPuPJGbfmn6t14cDpiXc=.950cf100-d65b-4fa4-8ae7-fe28d990b4f9@github.com>
 <zPUdIfuQMhGCj1KqpyQOPBDsz2n2s3RXypGeF_ried0=.54e79fee-a013-4ca3-b82a-f434e8955abb@github.com>
Message-ID: <x09dICX4G9PvMqBIND9UPvgq0my4RLqv7dkjfX5tQ78=.2740a6c3-9f9e-46d2-b881-b03b0fafa7a4@github.com>

On Sun, 25 May 2025 04:40:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   create method share variant val & coder
>
> src/java.base/share/classes/java/lang/String.java line 569:
> 
>> 567:         }
>> 568:         this.value = str.value;
>> 569:         this.coder = str.coder;
> 
> Suggestion:
> 
>         this(str);
> 
> We have integrated flexible constructor bodies.

public String(String original) {
        this.value = original.value;
        this.coder = original.coder;
        this.hash = original.hash;
        this.hashIsZero = original.hashIsZero;
    }

this(str) It will lead to more operations, which are not necessary here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2106083905

From liach at openjdk.org  Sun May 25 05:24:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 May 2025 05:24:50 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods [v3]
In-Reply-To: <x09dICX4G9PvMqBIND9UPvgq0my4RLqv7dkjfX5tQ78=.2740a6c3-9f9e-46d2-b881-b03b0fafa7a4@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
 <SMAz5R1EFhePJhslGUGTDYdAPuPJGbfmn6t14cDpiXc=.950cf100-d65b-4fa4-8ae7-fe28d990b4f9@github.com>
 <zPUdIfuQMhGCj1KqpyQOPBDsz2n2s3RXypGeF_ried0=.54e79fee-a013-4ca3-b82a-f434e8955abb@github.com>
 <x09dICX4G9PvMqBIND9UPvgq0my4RLqv7dkjfX5tQ78=.2740a6c3-9f9e-46d2-b881-b03b0fafa7a4@github.com>
Message-ID: <r9DlGltSF1MUv-JVspNSympWw-Gvw1RGLX_BDeJvjQg=.520ae1f3-bd02-4670-b408-9a931d901589@github.com>

On Sun, 25 May 2025 04:47:35 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 569:
>> 
>>> 567:         }
>>> 568:         this.value = str.value;
>>> 569:         this.coder = str.coder;
>> 
>> Suggestion:
>> 
>>         this(str);
>> 
>> We have integrated flexible constructor bodies.
>
> public String(String original) {
>         this.value = original.value;
>         this.coder = original.coder;
>         this.hash = original.hash;
>         this.hashIsZero = original.hashIsZero;
>     }
> 
> this(str) It will lead to more operations, which are not necessary here.

You have shown C2 eliminates this string allocation. Maybe it eliminates these "more operations" too? Imo not worth maintaining separate logic here; this will be problematic when string fields change in the future and we may miss this site that need to update. The simple copy constructor has no issue with this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2106088896

From swen at openjdk.org  Sun May 25 05:53:10 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 25 May 2025 05:53:10 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods [v4]
In-Reply-To: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
Message-ID: <gQk5ziy06keARgbpuA_25gFtV-7CuJyVuOj2GF2nmYI=.63b1b96b-6766-4847-8f70-ef86160d00f4@github.com>

> Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline.
> 
> The following is the output information of PrintInlining:
> 
>                 @ 9   java.lang.String::<init> (12 bytes)   inline (hot)
> !m                 @ 1   java.nio.charset.Charset::defaultCharset (52 bytes)   inline (hot)
> !                  @ 8   java.lang.String::<init> (852 bytes)   failed to inline: hot method too big
> 
> 
> In Java code, the big method that cannot be inlined is the following constructor
> 
> 
> String(Charset charset, byte[] bytes, int offset, int length) {}
> 
> The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/String.java
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25290/files
  - new: https://git.openjdk.org/jdk/pull/25290/files/fab7728b..4fe4b89d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25290.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25290/head:pull/25290

PR: https://git.openjdk.org/jdk/pull/25290

From swen at openjdk.org  Sun May 25 06:18:55 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 25 May 2025 06:18:55 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods [v5]
In-Reply-To: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
Message-ID: <SXSbZFHFTlfs5pxo70riMeWwi_QGPxVUSmQoT45pwAQ=.da808822-b36a-42fc-aa57-b975828c75c1@github.com>

> Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline.
> 
> The following is the output information of PrintInlining:
> 
>                 @ 9   java.lang.String::<init> (12 bytes)   inline (hot)
> !m                 @ 1   java.nio.charset.Charset::defaultCharset (52 bytes)   inline (hot)
> !                  @ 8   java.lang.String::<init> (852 bytes)   failed to inline: hot method too big
> 
> 
> In Java code, the big method that cannot be inlined is the following constructor
> 
> 
> String(Charset charset, byte[] bytes, int offset, int length) {}
> 
> The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  from @liach

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25290/files
  - new: https://git.openjdk.org/jdk/pull/25290/files/4fe4b89d..58583b77

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25290.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25290/head:pull/25290

PR: https://git.openjdk.org/jdk/pull/25290

From swen at openjdk.org  Sun May 25 06:29:57 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 25 May 2025 06:29:57 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods [v3]
In-Reply-To: <zPUdIfuQMhGCj1KqpyQOPBDsz2n2s3RXypGeF_ried0=.54e79fee-a013-4ca3-b82a-f434e8955abb@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
 <SMAz5R1EFhePJhslGUGTDYdAPuPJGbfmn6t14cDpiXc=.950cf100-d65b-4fa4-8ae7-fe28d990b4f9@github.com>
 <zPUdIfuQMhGCj1KqpyQOPBDsz2n2s3RXypGeF_ried0=.54e79fee-a013-4ca3-b82a-f434e8955abb@github.com>
Message-ID: <RWcp2iVH2Snsyvoy3ojDVRtT0yn4fYWlmeescz9sn_I=.0a32ac9e-623e-4c9f-aa51-636aff68177e@github.com>

On Sun, 25 May 2025 04:39:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   create method share variant val & coder
>
> src/java.base/share/classes/java/lang/String.java line 703:
> 
>> 701:                 throw new Error(x);
>> 702:             }
>> 703:             if (COMPACT_STRINGS) {
> 
> Now we can call other constructors of String, so instead of having this manual handling of char[], we can call `return new String(ca, 0, caLen, null)`. Same for the `clen` version above.

private String(char[] value, int off, int len, Void sig) {
        if (len == 0) {
            this.value = "".value;
            this.coder = "".coder;
            return;
        }
        if (COMPACT_STRINGS) {
            byte[] val = StringUTF16.compress(value, off, len);
            this.coder = StringUTF16.coderFromArrayLen(val, len);
            this.value = val;
            return;
        }
        this.coder = UTF16;
        this.value = StringUTF16.toBytes(value, off, len);
    }


This constructor has additional processing logic for len == 0. 

ValueObject may be used here in the future. I think it is better to keep the original structure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2106099679

From stuefe at openjdk.org  Sun May 25 08:18:11 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 25 May 2025 08:18:11 GMT
Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(),
 use FD_CLOEXEC instead of close() [v3]
In-Reply-To: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
References: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
Message-ID: <-4h0JXxUpJFKnz2igmA0lWdfTmeyne_VuxaGGfegu5I=.a3d4185b-b0d4-464f-ac5b-03a6dd7ff43f@github.com>

> Hi, please consider the following patch.
> 
> This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc.
> 
> This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens).
> 
> Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409
> 
> This patch also fixes two subtle bugs:
> - we didn't check the return value of the close() inside closeAllFileDescriptors
> - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it)
> 
> ----
> 
> Testing:
> 
> We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC.
> 
> - in the parent JVM, the test opens a file in native code without FD_CLOEXEC
> - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open
> 
> I verified that the test correctly detects a broken implementation that leaks file descriptors. 
> 
> I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX).
> 
> I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green.

Thomas Stuefe has updated the pull request with a new target base 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 'openjdk:master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close-
 - Merge branch 'openjdk:master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close-
 - close dir fd on fcntl error
 - Mark fds with cloexec, plus test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25301/files
  - new: https://git.openjdk.org/jdk/pull/25301/files/8543a5ec..aef4e2bb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25301&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25301&range=01-02

  Stats: 75 lines in 3 files changed: 4 ins; 69 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25301/head:pull/25301

PR: https://git.openjdk.org/jdk/pull/25301

From dl at openjdk.org  Sun May 25 10:54:54 2025
From: dl at openjdk.org (Doug Lea)
Date: Sun, 25 May 2025 10:54:54 GMT
Subject: RFR: 8357146: ForkJoinPool:schedule(*) does not throw
 RejectedExecutionException when pool is shutdown
In-Reply-To: <HrY8oEMMeWz0u7KWhY6d3_AfjHiheP2GEfSED_LcdEA=.70dca138-1972-4ab5-90af-7ca41937742c@github.com>
References: <qnY_DbR3b52ILHFE9lxchxhF1mAiykq-QNd961efDiU=.8f497802-a9e1-41f6-951c-a56eb4a6ee6f@github.com>
 <HrY8oEMMeWz0u7KWhY6d3_AfjHiheP2GEfSED_LcdEA=.70dca138-1972-4ab5-90af-7ca41937742c@github.com>
Message-ID: <Fh5ZSHWv3DQqrdujk56S0WJT376WzEXGrk0P53-3BJo=.add09959-e7df-430e-bf6a-068e2efad023@github.com>

On Sat, 24 May 2025 15:57:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Method startDelayScheduler should trap the ISE thrown by SharedThreadContainer.start and possibly re-try termination before eventually throwing RejectedExecutionException.
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3475:
> 
>> 3473:                     ds = delayScheduler = null;
>> 3474:                     unlockRunState();
>> 3475:                     tryTerminate(false, false);
> 
> This reset okay, and the schedule methods will throw REE. The change makes me wonder about the  OOME "unable to create new native thread" scenario, should the schedule methods propagate it or throw REE with the OOME as cause?

OOME (not REE) is thrown if the creation fails in the try-finally, which seems best. But if start() throws OOME (or any other Error), I see that we should do the same back-out as with ISE, but rethrow it now vs rely on the the REE in schedule(). I'll adjust accordingly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25431#discussion_r2106162465

From liach at openjdk.org  Sun May 25 12:56:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 May 2025 12:56:52 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods [v3]
In-Reply-To: <RWcp2iVH2Snsyvoy3ojDVRtT0yn4fYWlmeescz9sn_I=.0a32ac9e-623e-4c9f-aa51-636aff68177e@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
 <SMAz5R1EFhePJhslGUGTDYdAPuPJGbfmn6t14cDpiXc=.950cf100-d65b-4fa4-8ae7-fe28d990b4f9@github.com>
 <zPUdIfuQMhGCj1KqpyQOPBDsz2n2s3RXypGeF_ried0=.54e79fee-a013-4ca3-b82a-f434e8955abb@github.com>
 <RWcp2iVH2Snsyvoy3ojDVRtT0yn4fYWlmeescz9sn_I=.0a32ac9e-623e-4c9f-aa51-636aff68177e@github.com>
Message-ID: <iZZr6m9SI8AT4JCvui2O5fzjshHwNEfAO1Mv2SPvrTw=.75413ac9-040d-45df-8761-9ce54130f1cc@github.com>

On Sun, 25 May 2025 06:27:14 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 703:
>> 
>>> 701:                 throw new Error(x);
>>> 702:             }
>>> 703:             if (COMPACT_STRINGS) {
>> 
>> Now we can call other constructors of String, so instead of having this manual handling of char[], we can call `return new String(ca, 0, caLen, null)`. Same for the `clen` version above.
>
> private String(char[] value, int off, int len, Void sig) {
>         if (len == 0) {
>             this.value = "".value;
>             this.coder = "".coder;
>             return;
>         }
>         if (COMPACT_STRINGS) {
>             byte[] val = StringUTF16.compress(value, off, len);
>             this.coder = StringUTF16.coderFromArrayLen(val, len);
>             this.value = val;
>             return;
>         }
>         this.coder = UTF16;
>         this.value = StringUTF16.toBytes(value, off, len);
>     }
> 
> 
> This constructor has additional processing logic for len == 0. 
> 
> ValueObject may be used here in the future. I think it is better to keep the original structure.

I thought this would both increase cleaniness and reduce code size of the decode method. @minborg What do you think? This also removes one of the switches on COMPACT_STRING.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2106193216

From nbenalla at openjdk.org  Sun May 25 12:59:55 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Sun, 25 May 2025 12:59:55 GMT
Subject: RFR: 8356629: Incorrect use of {@linkplain} in java.sql
In-Reply-To: <lHdtlZO7OsPQqd8SEBfLMyuxKBcwXAseIj3ZtGbguK8=.c41528ea-72be-4a3c-b0a4-733f6e95086c@github.com>
References: <lHdtlZO7OsPQqd8SEBfLMyuxKBcwXAseIj3ZtGbguK8=.c41528ea-72be-4a3c-b0a4-733f6e95086c@github.com>
Message-ID: <xA1dZY2_CQdHPi9YBkq5_izLfbUWpAV1i11AMX2vIWM=.e2cd698c-acaf-4a30-8de5-bd8e6fc740df@github.com>

On Sat, 17 May 2025 17:21:01 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this trivial patch to fix a javadoc bug.
> 
> TIA

Thanks for the review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25286#issuecomment-2907810545

From nbenalla at openjdk.org  Sun May 25 12:59:55 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Sun, 25 May 2025 12:59:55 GMT
Subject: Integrated: 8356629: Incorrect use of {@linkplain} in java.sql
In-Reply-To: <lHdtlZO7OsPQqd8SEBfLMyuxKBcwXAseIj3ZtGbguK8=.c41528ea-72be-4a3c-b0a4-733f6e95086c@github.com>
References: <lHdtlZO7OsPQqd8SEBfLMyuxKBcwXAseIj3ZtGbguK8=.c41528ea-72be-4a3c-b0a4-733f6e95086c@github.com>
Message-ID: <HVYhyf6L4QS77_rNRHcHXu5XBQjKfR-w9hir2aF8A_c=.1adf0a34-4f04-4a55-892a-d581c80005b4@github.com>

On Sat, 17 May 2025 17:21:01 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this trivial patch to fix a javadoc bug.
> 
> TIA

This pull request has now been integrated.

Changeset: b034710b
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b034710b2ae5fbfbe619abba86fef3b5a2d685e0
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8356629: Incorrect use of {@linkplain} in java.sql

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk/pull/25286

From chen.l.liang at oracle.com  Sun May 25 16:17:58 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sun, 25 May 2025 16:17:58 +0000
Subject: Add @Stable to java.lang.CharacterDataLatin1 and other
 CharacterData classes
In-Reply-To: <SJ2PR10MB766972482EB6A8C5D947E61AA29BA@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <7ccc3056-c4a7-4c82-b66b-37547c2ce92f.shaojin.wensj@alibaba-inc.com>
 <SJ2PR10MB766972482EB6A8C5D947E61AA29BA@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <SJ2PR10MB766908F3593FB8A3E3BB82E1A29AA@SJ2PR10MB7669.namprd10.prod.outlook.com>

On second thought, we should just focus on adding stable and final as you recommend - we should fix stylistic things with no semantic impact later.
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Chen Liang <chen.l.liang at oracle.com>
Sent: Saturday, May 24, 2025 6:16 PM
To: core-libs-dev <core-libs-dev at openjdk.org>; wenshao <shaojin.wensj at alibaba-inc.com>
Subject: Re: Add @Stable to java.lang.CharacterDataLatin1 and other CharacterData classes

Hello Shaojin,
I think your proposal is reasonable. These arrays are never mutated. Meanwhile I see some declarations like int A[] in CharacterData00, would be nice if you can convert those declarations to like int[] A too.

Regards,
Chen
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of wenshao <shaojin.wensj at alibaba-inc.com>
Sent: Saturday, May 24, 2025 12:55 PM
To: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Add @Stable to java.lang.CharacterDataLatin1 and other CharacterData classes

Classes such as java.lang.CharacterDataXXX have multiple static final arrays, which will not be modified. We should add @Stable to provide information to the optimizer.

such as

```java
class CharacterData00 {
    @Stable static final char[] X =
    @Stable static final char[] Y =
    @Stable static final int[] A =
    @Stable static final char[] B =
}
```

-
Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250525/22136f1b/attachment-0001.htm>

From swen at openjdk.org  Sun May 25 17:42:55 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 25 May 2025 17:42:55 GMT
Subject: Integrated: 8357685: Change the type of Integer::digits from char[] to
 byte[]
In-Reply-To: <AmPJWWPyRS_K4NSNF-owbKNwxnmjuIYxvtzcGbHc8kE=.fdb3c265-0a41-4fc0-8078-36378422e2fa@github.com>
References: <AmPJWWPyRS_K4NSNF-owbKNwxnmjuIYxvtzcGbHc8kE=.fdb3c265-0a41-4fc0-8078-36378422e2fa@github.com>
Message-ID: <cmmm0dC7Zk5wK8ZFNx__jKVTh4XbAMrB7t6-IKJNQHA=.a6405983-1326-4c95-bba1-b7c7b63769a4@github.com>

On Sat, 24 May 2025 02:30:16 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Integer::digits type can use byte[] instead of char[], which can reduce the conversion from char to byte in the process of Integer.toString. Using byte[] can also save memory.

This pull request has now been integrated.

Changeset: 4a4209ff
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4a4209ffef8f8d65054cbf46ebf8e169d100c0d8
Stats:     8 lines in 2 files changed: 1 ins; 0 del; 7 mod

8357685: Change the type of Integer::digits from char[] to byte[]

Reviewed-by: rgiulietti, liach

-------------

PR: https://git.openjdk.org/jdk/pull/25426

From shaojin.wensj at alibaba-inc.com  Sun May 25 23:57:33 2025
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Mon, 26 May 2025 07:57:33 +0800
Subject: =?UTF-8?B?QWRkIEBTdGFibGUgdG8gQmlnSW50ZWdlciBhbmQgQmlnRGVjaW1hbA==?=
Message-ID: <21b4abad-0321-408e-92c2-a87c1ee2e010.shaojin.wensj@alibaba-inc.com>

Some static final arrays of BigInteger and BigDecimal are stable and immutable. We should add @Stable to give the optimizer more information
-
Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250526/c22a4dca/attachment.htm>

From yujige at gmail.com  Mon May 26 01:07:45 2025
From: yujige at gmail.com (Jige Yu)
Date: Sun, 25 May 2025 18:07:45 -0700
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <MW4PR10MB5774EF4D4316B5BE46B29A0EFFF12@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774265B8728DA0641C48DBAFF152@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYut_G7TRSTr0hPVuxWAvJQ+25JyPBWB7PEtntamWq-E_A@mail.gmail.com>
 <MW4PR10MB5774AB9B6544E949383187F3FFEC2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvyRxcWv65v4+8KcRHys=jkbpfKZ3eK3ijTGKXR1UxNnA@mail.gmail.com>
 <MW4PR10MB5774986199F9EDF854A6D390FFEE2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtE-xwb9tBhjPvObeG9_03nXh1aRA10sO7ibEGkQavntw@mail.gmail.com>
 <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtAUfyUHOdmSeZ2Azny=RJU63FQozY2NxpYu-4xQYCRkA@mail.gmail.com>
 <MW4PR10MB5774B089653C902899FEBEAFFFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB5774BB2B60EE5A1F4B1A7306FFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvxZ0gpHJXW0ctuHwEGwfStfjmLvwV1CgSWrr8438rWPA@mail.gmail.com>
 <MW4PR10MB5774EF4D4316B5BE46B29A0EFFF12@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAKD1RYsJyHeEs1fc4DRTZKwDO_U4Pyjv45BQ5fvr6VbboaVCTQ@mail.gmail.com>

Thanks Viktor!

Sorry, I was giving myself more time to read the code, but then I lost
track.

If I'm reading the code right, the current behavior is that if the current
thread is interrupted, the mapConcurrent() would suppress the interruption
until all elements are processed? (It will then restore the interruption
bit)

Doesn't this break fail fast?

For example, I may have a mapConcurrent() called from within structured
concurrency, and that fans out to two operations:
?
scope.fork(() -> doA());
scope.fork(() -> doB());  // calls mapConcurrent() internally
scope.join().throwIfFailed();

If doA() fails, doB() will be cancelled (thread interrupted).

If mapConcurrent() ignores the interruption, and if doB has a long list to
process, it'll continue to consume system resources even when the caller no
longer needs the results, no?


On Fri, Feb 7, 2025 at 2:16?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> >Sorry, did the PR stop using Semaphore?
>
> No, not that PR. See:
> https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e
>
> The problem with interruption under parallel evaluation is that there is
> no general support for propagation of interruption in CountedCompleters.
> Adding support for such in (at least) GathererOp needs further study before
> contemplating making any changes to mapConcurrent()'s interruption policy.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
>
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Thursday, 6 February 2025 17:04
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Sorry, did the PR stop using Semaphore?
>
> I had naively thought that mapConcurrent() will keep a buffer of Future of
> all currently-running concurrent tasks (it can be a ConcurrentMap<TaskKey,
> Future> if we don't have to ensure FIFO).
>
> Upon interruption, the main thread can call .cancel(true) on all pending
> Futures; optionally join with the VTs (if we need to block until all VTs
> exit); then propagate exception.
>
> Upon completion, each task just removes itself from the ConcurrentMap.
>
> Just in case it adds anything.
>
>
>
> On Thu, Feb 6, 2025 at 6:47?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> After some more investigation it seems tractable to propagate interruption
> of the caller in sequential mode, but parallel mode will require much
> bigger considerations.
>
> I made a comment to that effect on the JBS issue:
> https://bugs.openjdk.org/browse/JDK-8349462?focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Viktor Klang <viktor.klang at oracle.com>
> *Sent:* Thursday, 6 February 2025 11:51
> *To:* Jige Yu <yujige at gmail.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> I think alignment in behavior between parallel Stream and mapConcurrent in
> terms of how interruptions are handled is a possible path forward.
>
> I decided to close the PR for now as I realized my parallel Stream example
> had misled me regarding its exception throwing, so I'll need to go back and
> refine the solution.
>
> It still seems solvable though.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Wednesday, 5 February 2025 19:20
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Oh good call!
>
> I forgot to check what parallel streams do upon interruption (didn't think
> they do any blocking calls, but at least the main thread must block).
>
> On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi Jige,
>
> I opened an issue to track the concern, and I have proposed a change which
> seems to align well with how parallel streams behave under caller thread
> interruption.
>
> I've opened the following PR for review:
> https://github.com/openjdk/jdk/pull/23467
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
>
> If you are able to make a local OpenJDK build with that solution you could
> check if it addresses your use-cases (or not).
>
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
> 8349462: Gatherers.mapConcurrent could support async interrupts by
> viktorklang-ora ? Pull Request #23467 ? openjdk/jdk
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
> This change is likely going to need some extra verbiage in the spec for
> mapConcurrent, and thus a CSR. This behavior aligns mapConcurrent with how
> parallel streams work in conjunction with interrup...
> github.com
> <https://urldefense.com/v3/__http://github.com__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89DBkMefT$>
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Wednesday, 5 February 2025 16:24
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Thanks Viktor!
>
> I understand the problem.
>
> The main reason I asked is because I want to understand how the core Java
> team thinks of throwing an unchecked exception.
>
> As explained above, I consider losing cancellability a big deal, a deal
> breaker even. And I thought throwing unchecked is more acceptable. Because
> the most common reason the mapConcurrent() VT can be interrupted is due to
> cancellation from a parent mapConcurrent(), or a parent Structured
> Concurrency scope. The cancellation could be either from an organic
> exception, or from the downstream not needing more elements, like maybe due
> to findFirst() already getting an element.
>
> In both cases, since the concurrent operation is already cancelled (result
> ignored), what exception pops up to the top level isn't that big of a deal
> (perhaps only a log record will be seen?)
>
> But if the core Java team considers it a bad idea, I would love to learn
> and adjust.
>
> On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi,
>
> The problem is that mapConcurrent cannot throw InterruptedException
> because that is a checked exception, so we cannot clear the interrupted
> flag and throw that exception.
>
> So the updated semantics is to not cut the stream short but instead run to
> completion, restoring the interruption flag.
>
> There exists a couple of alternatives to this approach which I am
> contemplating, but they need to be further explored before I consider
> moving forward with any of them.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 27 January 2025 17:00
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Thanks Viktor!
>
> It looks like the current fix ignores interruption.
>
> I want to make sure my concern of it defeating cancellation is heard and
> understood.
>
> The scenarios I worry about is for a mapConcurrent() that fans out to
> another method call, which internally calls mapConcurrent() as
> implementation detail.
>
> An example:
>
> List<RefundResponse> refundHelper(transaction) {
>   transaction.creditCardAccounts.stream()
>     .gather(mapConcurrent(acct -> service.refund(acct))
>     .toList();
> }
>
> transactions.stream()
>     .gather(mapConcurrent(transaction -> refundHelper(transaction));
>
>
> It seems undesirable that in such a case all the service.refund() calls
> become non cancellable, because the only way the outer mapConcurrent()
> cancels the refundHelper() calls is through Thread.interrupt() the virtual
> threads that call refundHelper(), which would then be disabled by the inner
> mapConcurrent().
>
> Does this example make sense to you? I can further explain if anything
> isn't clear.
>
> But I want to make sure the decision to disable interruption is deliberate
> judgement call that such nested mapConcurrent() is unlikely,or not
> important.
>
> Cheers,
>
>
>
> On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi!
>
> Please see: https://github.com/openjdk/jdk/pull/23100
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23100__;!!ACWV5N9M2RV99hQ!IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Sunday, 26 January 2025 23:03
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* [External] : Re: mapConcurrent() with InterruptedException
>
> Checking in on what you've found out, Viktor.
>
> From where we left off, I understand that you were looking at alternatives
> instead of silent truncation?
>
> Have you reached any conclusion?
>
> We touched on disallowing interruption during mapConcurrent(). I still
> have concerns with disabling cancellation, because it basically undoes this
> API note from the javadoc
> <https://cr.openjdk.org/~alanb/sc-20240503/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)>
> :
>
> API Note: In progress tasks will be attempted to be cancelled, on a
> best-effort basis, in situations where the downstream no longer wants to
> receive any more elements.
> In reality, people will use mapConcurrent() to fan out rpcs. Sometimes
> these rpcs are just a single blocking call; yet sometimes they may
> themselves be a Structured Concurrency scope, with 2 or 3 rpcs that
> constitute a single logical operation. Under two conditions, cancellation
> is imho important semantic:
>
>    1. The downstream code uses filter().findFirst(), and when it sees an
>    element, it will return and no longer needs the other pending rpcs to
>    complete. If cancellation is disabled, these unnecessary rpcs will waste
>    system resources.
>    2. One of the rpc throws and the Stream pipeline needs to propagate
>    the exception. Again, if the other rpcs cannot be cancelled, we'll have
>    many zombie rpcs.
>
> Zombie rpcs may or may not be a deal breaker, depending on the specific
> use case. But for a JDK library, losing cancellation would have a negative
> impact on usability.
>
> My 2c,
>
>
> On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi Ben,
>
> Thanks for raising these questions?getting feedback is crucial in the
> Preview stage of features.
>
> I wrote a reply to the Reddit thread so I'll just summarize here:
>
> It is important to note that *mapConcurrent()* is not a part of the
> Structured Concurrency JEPs, so it is not designed to join SC scopes.
>
> I'm currently experimenting with ignoring-but-restoring interrupts on the
> "calling thread" for *mapConcurrent()*, as well as capping
> work-in-progress to *maxConcurrency* (not only capping the concurrency
> but also the amount of completed-but-yet-to-be-pushed work). Both of these
> adjustments should increase predictability of behavior in the face of
> blocking operations with variable delays.
>
> Another adjustment I'm looking at right now is to harden/improve the
> cleanup to wait for concurrent tasks to acknowledge cancellation, so that
> once the finisher is done executing the VTs are known to have terminated.
>
> As for not preserving the encounter order, that would be a completely
> different thing, and I'd encourage you to experiment with that if that
> functionality would be interesting for your use-case(s).
>
> Again, thanks for your feedback!
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Jige
> Yu <yujige at gmail.com>
> *Sent:* Friday, 3 January 2025 17:53
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* mapConcurrent() with InterruptedException
>
> Hi Java Experts,
>
> I sent this email incorrectly to loom-dev@ and was told on Reddit that
> core-libs-dev is the right list.
>
> The question is about the behavior of mapConcurrent() when the thread is
> interrupted.
>
> Currently mapConcurrent()'s finisher phase will re-interrupt the thread,
> then stop at whatever element that has already been processed and return.
>
> This strikes me as a surprising behavior, because for example if I'm
> running:
>
>    Stream.of(1, 2, 3)
>         .gather(mapConcurrent(i -> i * 2))
>         .toList()
>
> and the thread is being interrupted, the result could be any of [2], [2,
> 4] or [2, 4, 6].
>
> Since thread interruption is cooperative, there is no guarantee that the
> thread being interrupted will just abort. It's quite possible that it'll
> keep going and then will use for example [2] as the result of doubling the
> list of [1, 2, 3], which is imho incorrect.
>
> In the Reddit
> <https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread,
> someone argued that interruption rarely happens so it's more of a
> theoretical issue. But interruption can easily happen in Structured
> Concurrency or in mapConcurrent() itself if any subtask has failed in order
> to cancel/interrupt the other ongoing tasks.
>
> There had been discussion about alternative strategies:
>
>    1. Don't respond to interruption and just keep running to completion.
>    2. Re-interrupt thread and wrap the InterruptedException in a standard
>    unchecked exception (StructuredConcurrencyInterruptedException?).
>
>
> I have concerns with option 1 because it disables cancellation propagation
> when mapConcurrent() itself is used in a subtask of a parent
> mapConcurrent() or in a StructuredConcurrencyScope.
>
> Both equivalent Future-composition async code, or C++'s fiber trees
> support cancellation propagation and imho it's a critical feature or else
> it's possible that a zombie thread is still sending RPCs long after the
> main thread has exited (failed, or falled back to some default action).
>
> My arguments for option 2:
>
>    1. InterruptedException is more error prone than traditional checked
>    exceptions for *users* to catch and handle. They can forget to
>    re-interrupt the thread. It's so confusing that even seasoned programmers
>    may not know they are *supposed to* re-interrupt the thread.
>    2. With Stream API using functional interfaces like Supplier,
>    Function, the option of just tacking on "throws IE" isn't available to many
>    users.
>    3. With Virtual Threads, it will be more acceptable, or even become
>    common to do blocking calls from a stream operation (including but
>    exclusive to mapConcurrent()). So the chance users are forced to deal with
>    IE will become substantially higher.
>    4. Other APIs such as the Structured Concurrency API have already
>    started wrapping system checked exceptions like ExecutionException,
>    TimeoutException in unchecked exceptions ( join()
>    <https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for
>    example).
>    5. Imho, exceptions that we'd rather users not catch and handle but
>    instead should mostly just propagate up as is, should be unchecked.
>
> There is also a side discussion
> <https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/comment/m4z4f8c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about
> whether mapConcurrent() is better off preserving input order or push to
> downstream as soon as an element is computed. I'd love to discuss that
> topic too but maybe it's better to start a separate thread?
>
> Thank you and cheers!
>
> Ben Yu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250525/512a20b9/attachment-0001.htm>

From jpai at openjdk.org  Mon May 26 05:46:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 May 2025 05:46:50 GMT
Subject: RFR: 8357597: Proxy.getInvocationHandler throws
 NullPointerException instead of IllegalArgumentException for null
In-Reply-To: <SAxS-e8fh7vXOoBnIxEC6X6fM5KdfM8YwCH5Bl3vdFc=.738ee4a2-f142-40c3-b967-7ffe01f8a258@github.com>
References: <SAxS-e8fh7vXOoBnIxEC6X6fM5KdfM8YwCH5Bl3vdFc=.738ee4a2-f142-40c3-b967-7ffe01f8a258@github.com>
Message-ID: <_L16HJaL2iFRPFnS4dyzoVSbAx5jofgsWdOfMqpFq3E=.cb5f0a1d-4269-4e95-a3f5-181242a8050e@github.com>

On Fri, 23 May 2025 16:05:08 GMT, Steffen Nie?ing <duke at openjdk.org> wrote:

> `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE.

The change looks OK to me. Please update the copyright year on the file from `1999, 2024,` to `1999, 2025,`.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25419#pullrequestreview-2867281818

From epeter at openjdk.org  Mon May 26 06:58:53 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 26 May 2025 06:58:53 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API
In-Reply-To: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
Message-ID: <H6yHtD4nQZuMyH51yIKg6gy7C3Vcu5Pr1npnj0Hp8pg=.1730e885-cd86-4140-bf47-8f914b604308@github.com>

On Fri, 9 May 2025 07:35:41 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]).
> 
> Two key areas require improvement:
> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance.
> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types  increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance.
> 
> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures.
> 
> Main changes:
> 1. Java-side API refactoring:
>    - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on
>      architectures like AArch64.
> 2. C2 compiler IR refactoring:
>    - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types.
> 3. Backend changes:
>    - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level.
> 
> Performance:
> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below:
> 
> Benchmark                                                 Mode   Cnt Unit    SIZE    Before      After    Gain
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  64    53682.012   52650.325  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  256   14484.252   14255.156  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  1024   3664.900    3595.615  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  4096    908.312     935.269  1.02
> GatherOperationsBenchmark.micr...

It seems reasonable. @jatin-bhateja should definitively look over this, or someone else from Intel who knows this code well :)

I'll launch some testing now :)

src/hotspot/share/opto/vectorIntrinsics.cpp line 1203:

> 1201: //                 Class<? extends Vector<Integer>> vectorIndexClass, int indexLength,
> 1202: //                 Object base, long offset,
> 1203: //                 W indexVector1, W index_vector2, W index_vector3, W index_vector4,

Are we doing a mix of `CamelCase` and `with_underscore` on purpose?

src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 495:

> 493:                   Class<? extends Vector<Integer>> vectorIndexClass,
> 494:                   int indexLength, Object base, long offset,
> 495:                   W indexVector1, W indexVector2, W indexVector3, W indexVector4,

Here  you went for all `camelCase`, just an observation :)

-------------

PR Review: https://git.openjdk.org/jdk/pull/25138#pullrequestreview-2867447489
PR Review Comment: https://git.openjdk.org/jdk/pull/25138#discussion_r2106674102
PR Review Comment: https://git.openjdk.org/jdk/pull/25138#discussion_r2106673987

From xgong at openjdk.org  Mon May 26 07:20:30 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 26 May 2025 07:20:30 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API
In-Reply-To: <H6yHtD4nQZuMyH51yIKg6gy7C3Vcu5Pr1npnj0Hp8pg=.1730e885-cd86-4140-bf47-8f914b604308@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <H6yHtD4nQZuMyH51yIKg6gy7C3Vcu5Pr1npnj0Hp8pg=.1730e885-cd86-4140-bf47-8f914b604308@github.com>
Message-ID: <UMEiDzSKk6sXCZ7LUzgmTZqXB5BFhvBmt-jw7ATzFAs=.6a12dc75-40ee-4bc4-8f1d-03a3bb7cba67@github.com>

On Mon, 26 May 2025 06:51:12 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]).
>> 
>> Two key areas require improvement:
>> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance.
>> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types  increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance.
>> 
>> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures.
>> 
>> Main changes:
>> 1. Java-side API refactoring:
>>    - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on
>>      architectures like AArch64.
>> 2. C2 compiler IR refactoring:
>>    - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types.
>> 3. Backend changes:
>>    - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level.
>> 
>> Performance:
>> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below:
>> 
>> Benchmark                                                 Mode   Cnt Unit    SIZE    Before      After    Gain
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  64    53682.012   52650.325  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  256   14484.252   14255.156  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  1024   3664.900    3595.615  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  4096    908.31...
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 1203:
> 
>> 1201: //                 Class<? extends Vector<Integer>> vectorIndexClass, int indexLength,
>> 1202: //                 Object base, long offset,
>> 1203: //                 W indexVector1, W index_vector2, W index_vector3, W index_vector4,
> 
> Are we doing a mix of `CamelCase` and `with_underscore` on purpose?

This would be a naming style issue. Thanks for pointing out. I will fix it once I update this PR. It should be aligned with definition in `VectorSupport.java`.

> src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 495:
> 
>> 493:                   Class<? extends Vector<Integer>> vectorIndexClass,
>> 494:                   int indexLength, Object base, long offset,
>> 495:                   W indexVector1, W indexVector2, W indexVector3, W indexVector4,
> 
> Here  you went for all `camelCase`, just an observation :)

Yeah, I choose to use `camelCase` style here to align with other parameter naming styles in this method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25138#discussion_r2106693179
PR Review Comment: https://git.openjdk.org/jdk/pull/25138#discussion_r2106692107

From alanb at openjdk.org  Mon May 26 07:22:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 07:22:49 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
Message-ID: <s4dKsfyuUa1cRaFNYJRe0hUrNQjppVQLLM80KYsGWhc=.b343fac6-9587-4313-b117-dbaf9fe6378b@github.com>

On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects wording change suggestions

Spec update and src changes looks good.  

I only skimmed through the test changes (not a detailed review) and they look reasonable. I assume you've done some "test repeat" jobs to ensure that any variance in the version of "expect" on test machines doesn't cause any issues.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25271#pullrequestreview-2867506507

From viktor.klang at oracle.com  Mon May 26 07:30:15 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 26 May 2025 07:30:15 +0000
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <CAKD1RYsJyHeEs1fc4DRTZKwDO_U4Pyjv45BQ5fvr6VbboaVCTQ@mail.gmail.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774265B8728DA0641C48DBAFF152@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYut_G7TRSTr0hPVuxWAvJQ+25JyPBWB7PEtntamWq-E_A@mail.gmail.com>
 <MW4PR10MB5774AB9B6544E949383187F3FFEC2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvyRxcWv65v4+8KcRHys=jkbpfKZ3eK3ijTGKXR1UxNnA@mail.gmail.com>
 <MW4PR10MB5774986199F9EDF854A6D390FFEE2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtE-xwb9tBhjPvObeG9_03nXh1aRA10sO7ibEGkQavntw@mail.gmail.com>
 <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtAUfyUHOdmSeZ2Azny=RJU63FQozY2NxpYu-4xQYCRkA@mail.gmail.com>
 <MW4PR10MB5774B089653C902899FEBEAFFFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB5774BB2B60EE5A1F4B1A7306FFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvxZ0gpHJXW0ctuHwEGwfStfjmLvwV1CgSWrr8438rWPA@mail.gmail.com>
 <MW4PR10MB5774EF4D4316B5BE46B29A0EFFF12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYsJyHeEs1fc4DRTZKwDO_U4Pyjv45BQ5fvr6VbboaVCTQ@mail.gmail.com>
Message-ID: <MW4PR10MB57743363CCA3306B316F3EEDFF65A@MW4PR10MB5774.namprd10.prod.outlook.com>

Yes, the updated Gatherers.mapConcurrent will continue under interruption until done, and then restore the interrupt status of the calling thread.

It cannot (reasonably) do anything else?if it were to throw InterruptedException, it couldn't since that is a checked exception and there's no tracking of checked exceptions throughout a Stream, and that is the specified behavior to handle thread interrupts (i.e. clear flag and throw InterruptedException, which is not possible in this case; or, make sure that interrupt status is maintained, which is possible in this case.

I have given it some more thought in the meantime, but I haven't arrived in something more satisfactory than that, yet.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com>
Sent: Monday, 26 May 2025 03:07
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Thanks Viktor!

Sorry, I was giving myself more time to read the code, but then I lost track.

If I'm reading the code right, the current behavior is that if the current thread is interrupted, the mapConcurrent() would suppress the interruption until all elements are processed? (It will then restore the interruption bit)

Doesn't this break fail fast?

For example, I may have a mapConcurrent() called from within structured concurrency, and that fans out to two operations:
?
scope.fork(() -> doA());
scope.fork(() -> doB());  // calls mapConcurrent() internally
scope.join().throwIfFailed();

If doA() fails, doB() will be cancelled (thread interrupted).

If mapConcurrent() ignores the interruption, and if doB has a long list to process, it'll continue to consume system resources even when the caller no longer needs the results, no?


On Fri, Feb 7, 2025 at 2:16?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>Sorry, did the PR stop using Semaphore?

No, not that PR. See: https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e<https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e__;!!ACWV5N9M2RV99hQ!OKfWrvJEDCkiHcT5b4a6gfeomZzZeq3jv6ir2vf2I5WWIhujtb-by_VuQFaAPDIuAA0qAwpTUjllXMPF$>

The problem with interruption under parallel evaluation is that there is no general support for propagation of interruption in CountedCompleters. Adding support for such in (at least) GathererOp needs further study before contemplating making any changes to mapConcurrent()'s interruption policy.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Thursday, 6 February 2025 17:04
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Sorry, did the PR stop using Semaphore?

I had naively thought that mapConcurrent() will keep a buffer of Future of all currently-running concurrent tasks (it can be a ConcurrentMap<TaskKey, Future> if we don't have to ensure FIFO).

Upon interruption, the main thread can call .cancel(true) on all pending Futures; optionally join with the VTs (if we need to block until all VTs exit); then propagate exception.

Upon completion, each task just removes itself from the ConcurrentMap.

Just in case it adds anything.



On Thu, Feb 6, 2025 at 6:47?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
After some more investigation it seems tractable to propagate interruption of the caller in sequential mode, but parallel mode will require much bigger considerations.

I made a comment to that effect on the JBS issue: https://bugs.openjdk.org/browse/JDK-8349462?focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Sent: Thursday, 6 February 2025 11:51
To: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

I think alignment in behavior between parallel Stream and mapConcurrent in terms of how interruptions are handled is a possible path forward.

I decided to close the PR for now as I realized my parallel Stream example had misled me regarding its exception throwing, so I'll need to go back and refine the solution.

It still seems solvable though.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Wednesday, 5 February 2025 19:20
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Oh good call!

I forgot to check what parallel streams do upon interruption (didn't think they do any blocking calls, but at least the main thread must block).

On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi Jige,

I opened an issue to track the concern, and I have proposed a change which seems to align well with how parallel streams behave under caller thread interruption.

I've opened the following PR for review:
https://github.com/openjdk/jdk/pull/23467<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>

If you are able to make a local OpenJDK build with that solution you could check if it addresses your use-cases (or not).
[https://opengraph.githubassets.com/00e04f8a63bde12217df087df7ef8edee563adf7e925d07c75bdeae092180094/openjdk/jdk/pull/23467]<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
8349462: Gatherers.mapConcurrent could support async interrupts by viktorklang-ora ? Pull Request #23467 ? openjdk/jdk<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
This change is likely going to need some extra verbiage in the spec for mapConcurrent, and thus a CSR. This behavior aligns mapConcurrent with how parallel streams work in conjunction with interrup...
github.com<https://urldefense.com/v3/__http://github.com__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89DBkMefT$>


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Wednesday, 5 February 2025 16:24
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Thanks Viktor!

I understand the problem.

The main reason I asked is because I want to understand how the core Java team thinks of throwing an unchecked exception.

As explained above, I consider losing cancellability a big deal, a deal breaker even. And I thought throwing unchecked is more acceptable. Because the most common reason the mapConcurrent() VT can be interrupted is due to cancellation from a parent mapConcurrent(), or a parent Structured Concurrency scope. The cancellation could be either from an organic exception, or from the downstream not needing more elements, like maybe due to findFirst() already getting an element.

In both cases, since the concurrent operation is already cancelled (result ignored), what exception pops up to the top level isn't that big of a deal (perhaps only a log record will be seen?)

But if the core Java team considers it a bad idea, I would love to learn and adjust.

On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi,

The problem is that mapConcurrent cannot throw InterruptedException because that is a checked exception, so we cannot clear the interrupted flag and throw that exception.

So the updated semantics is to not cut the stream short but instead run to completion, restoring the interruption flag.

There exists a couple of alternatives to this approach which I am contemplating, but they need to be further explored before I consider moving forward with any of them.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 27 January 2025 17:00
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Thanks Viktor!

It looks like the current fix ignores interruption.

I want to make sure my concern of it defeating cancellation is heard and understood.

The scenarios I worry about is for a mapConcurrent() that fans out to another method call, which internally calls mapConcurrent() as implementation detail.

An example:


List<RefundResponse> refundHelper(transaction) {
  transaction.creditCardAccounts.stream()
    .gather(mapConcurrent(acct -> service.refund(acct))
    .toList();
}

transactions.stream()
    .gather(mapConcurrent(transaction -> refundHelper(transaction));

It seems undesirable that in such a case all the service.refund() calls become non cancellable, because the only way the outer mapConcurrent() cancels the refundHelper() calls is through Thread.interrupt() the virtual threads that call refundHelper(), which would then be disabled by the inner mapConcurrent().

Does this example make sense to you? I can further explain if anything isn't clear.

But I want to make sure the decision to disable interruption is deliberate judgement call that such nested mapConcurrent() is unlikely,or not important.

Cheers,



On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi!

Please see: https://github.com/openjdk/jdk/pull/23100<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23100__;!!ACWV5N9M2RV99hQ!IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Sunday, 26 January 2025 23:03
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: [External] : Re: mapConcurrent() with InterruptedException

Checking in on what you've found out, Viktor.

From where we left off, I understand that you were looking at alternatives instead of silent truncation?

Have you reached any conclusion?

We touched on disallowing interruption during mapConcurrent(). I still have concerns with disabling cancellation, because it basically undoes this API note from the javadoc<https://cr.openjdk.org/~alanb/sc-20240503/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)>:


API Note:

In progress tasks will be attempted to be cancelled, on a best-effort basis, in situations where the downstream no longer wants to receive any more elements.
In reality, people will use mapConcurrent() to fan out rpcs. Sometimes these rpcs are just a single blocking call; yet sometimes they may themselves be a Structured Concurrency scope, with 2 or 3 rpcs that constitute a single logical operation. Under two conditions, cancellation is imho important semantic:

  1.  The downstream code uses filter().findFirst(), and when it sees an element, it will return and no longer needs the other pending rpcs to complete. If cancellation is disabled, these unnecessary rpcs will waste system resources.
  2.  One of the rpc throws and the Stream pipeline needs to propagate the exception. Again, if the other rpcs cannot be cancelled, we'll have many zombie rpcs.

Zombie rpcs may or may not be a deal breaker, depending on the specific use case. But for a JDK library, losing cancellation would have a negative impact on usability.

My 2c,


On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi Ben,

Thanks for raising these questions?getting feedback is crucial in the Preview stage of features.

I wrote a reply to the Reddit thread so I'll just summarize here:

It is important to note that mapConcurrent() is not a part of the Structured Concurrency JEPs, so it is not designed to join SC scopes.

I'm currently experimenting with ignoring-but-restoring interrupts on the "calling thread" for mapConcurrent(), as well as capping work-in-progress to maxConcurrency (not only capping the concurrency but also the amount of completed-but-yet-to-be-pushed work). Both of these adjustments should increase predictability of behavior in the face of blocking operations with variable delays.

Another adjustment I'm looking at right now is to harden/improve the cleanup to wait for concurrent tasks to acknowledge cancellation, so that once the finisher is done executing the VTs are known to have terminated.

As for not preserving the encounter order, that would be a completely different thing, and I'd encourage you to experiment with that if that functionality would be interesting for your use-case(s).

Again, thanks for your feedback!

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Friday, 3 January 2025 17:53
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: mapConcurrent() with InterruptedException

Hi Java Experts,

I sent this email incorrectly to loom-dev@ and was told on Reddit that core-libs-dev is the right list.

The question is about the behavior of mapConcurrent() when the thread is interrupted.

Currently mapConcurrent()'s finisher phase will re-interrupt the thread, then stop at whatever element that has already been processed and return.

This strikes me as a surprising behavior, because for example if I'm running:

   Stream.of(1, 2, 3)
        .gather(mapConcurrent(i -> i * 2))
        .toList()

and the thread is being interrupted, the result could be any of [2], [2, 4] or [2, 4, 6].

Since thread interruption is cooperative, there is no guarantee that the thread being interrupted will just abort. It's quite possible that it'll keep going and then will use for example [2] as the result of doubling the list of [1, 2, 3], which is imho incorrect.

In the Reddit<https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread, someone argued that interruption rarely happens so it's more of a theoretical issue. But interruption can easily happen in Structured Concurrency or in mapConcurrent() itself if any subtask has failed in order to cancel/interrupt the other ongoing tasks.

There had been discussion about alternative strategies:

  1.  Don't respond to interruption and just keep running to completion.
  2.  Re-interrupt thread and wrap the InterruptedException in a standard unchecked exception (StructuredConcurrencyInterruptedException?).

I have concerns with option 1 because it disables cancellation propagation when mapConcurrent() itself is used in a subtask of a parent mapConcurrent() or in a StructuredConcurrencyScope.

Both equivalent Future-composition async code, or C++'s fiber trees support cancellation propagation and imho it's a critical feature or else it's possible that a zombie thread is still sending RPCs long after the main thread has exited (failed, or falled back to some default action).

My arguments for option 2:

  1.  InterruptedException is more error prone than traditional checked exceptions for users to catch and handle. They can forget to re-interrupt the thread. It's so confusing that even seasoned programmers may not know they are supposed to re-interrupt the thread.
  2.  With Stream API using functional interfaces like Supplier, Function, the option of just tacking on "throws IE" isn't available to many users.
  3.  With Virtual Threads, it will be more acceptable, or even become common to do blocking calls from a stream operation (including but exclusive to mapConcurrent()). So the chance users are forced to deal with IE will become substantially higher.
  4.  Other APIs such as the Structured Concurrency API have already started wrapping system checked exceptions like ExecutionException, TimeoutException in unchecked exceptions ( join()<https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for example).
  5.  Imho, exceptions that we'd rather users not catch and handle but instead should mostly just propagate up as is, should be unchecked.

There is also a side discussion<https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/comment/m4z4f8c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about whether mapConcurrent() is better off preserving input order or push to downstream as soon as an element is computed. I'd love to discuss that topic too but maybe it's better to start a separate thread?

Thank you and cheers!

Ben Yu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250526/0dea3cea/attachment-0001.htm>

From mbaesken at openjdk.org  Mon May 26 07:45:38 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 26 May 2025 07:45:38 GMT
Subject: RFR: 8357561: BootstrapLoggerTest does not work on Ubuntu 24 with LANG
 de_DE.UTF-8
Message-ID: <O6WamnBOTS0CLGB8whhkHhosBhPoqUzMAorzWXWWOc0=.d07e26d6-4682-4fcd-a116-4a6bcc69c4c3@github.com>

On a 'german'  Ubuntu 24 (LANG="de_DE.UTF-8") the jtreg test
java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest fails with


FEIN: hi now!
java.lang.RuntimeException: System.err does not contain: FINE: hi now!
at BootstrapLoggerTest.main(BootstrapLoggerTest.java:231)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:565)
at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
at java.base/java.lang.Thread.run(Thread.java:1447)


The test (and some others in :tier1 as well) do not work with non en/US LANG, so they need an adjustment.

-------------

Commit messages:
 - JDK-8357561

Changes: https://git.openjdk.org/jdk/pull/25441/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25441&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357561
  Stats: 16 lines in 3 files changed: 12 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25441.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25441/head:pull/25441

PR: https://git.openjdk.org/jdk/pull/25441

From ihse at openjdk.org  Mon May 26 07:47:02 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 07:47:02 GMT
Subject: RFR: 8356977: UTF-8 cleanups
In-Reply-To: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
Message-ID: <lt8vg3M1QU-xbe_E0l4n1j9V9sM_0VsM8kOt11Mk1L0=.d6e6845c-ff78-45f2-8f8e-6a40b9e12ba1@github.com>

On Thu, 15 May 2025 18:30:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> test/jdk/sun/text/resources/LocaleDataTest.java line 106:
> 
>> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
>> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
>> 106:  *        LocaleNames/fr_FR/US=?tats-Unis
> 
> This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.

ISO-8859-1 does not sound good, and got me worried. But in fact it seems like the file is pure ASCII, and that is fine. 

However, if the file should ever be changed to include actual ISO-8859-1 encoding, this might break if tools assume it is UTF-8-encoding, since not all ISO-8859-1 encodings are valid UTF-8.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160

From mbaesken at openjdk.org  Mon May 26 08:16:03 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 26 May 2025 08:16:03 GMT
Subject: RFR: 8357561: BootstrapLoggerTest does not work on Ubuntu 24 with
 LANG de_DE.UTF-8 [v2]
In-Reply-To: <O6WamnBOTS0CLGB8whhkHhosBhPoqUzMAorzWXWWOc0=.d07e26d6-4682-4fcd-a116-4a6bcc69c4c3@github.com>
References: <O6WamnBOTS0CLGB8whhkHhosBhPoqUzMAorzWXWWOc0=.d07e26d6-4682-4fcd-a116-4a6bcc69c4c3@github.com>
Message-ID: <UXKCaM-CuwYwTgOkg6tg6qhvndQmYDSpf9WJk19YChE=.da37cc57-5430-48cd-9e1e-e6f4ca1d8907@github.com>

> On a 'german'  Ubuntu 24 (LANG="de_DE.UTF-8") the jtreg test
> java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest fails with
> 
> 
> FEIN: hi now!
> java.lang.RuntimeException: System.err does not contain: FINE: hi now!
> at BootstrapLoggerTest.main(BootstrapLoggerTest.java:231)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1447)
> 
> 
> The test (and some others in :tier1 as well) do not work with non en/US LANG, so they need an adjustment.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  adjust LocalizedLevelName too

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25441/files
  - new: https://git.openjdk.org/jdk/pull/25441/files/76db640f..ec6d03d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25441&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25441&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25441.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25441/head:pull/25441

PR: https://git.openjdk.org/jdk/pull/25441

From ihse at openjdk.org  Mon May 26 08:20:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:20:19 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Restore MenuShortcut.java
 - Restore LocaleDataTest.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25228/files
  - new: https://git.openjdk.org/jdk/pull/25228/files/9c904992..7184e685

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25228&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25228&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25228.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25228/head:pull/25228

PR: https://git.openjdk.org/jdk/pull/25228

From ihse at openjdk.org  Mon May 26 08:20:46 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:20:46 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>
Message-ID: <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>

On Thu, 22 May 2025 21:43:20 GMT, Phil Race <prr at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore MenuShortcut.java
>>  - Restore LocaleDataTest.java
>
> src/java.desktop/share/classes/java/awt/MenuShortcut.java line 49:
> 
>> 47:  * For example, a menu shortcut for "Ctrl+cyrillic ef" is created by
>> 48:  * <p>
>> 49:  * <code>MenuShortcut ms = new MenuShortcut(KeyEvent.getExtendedKeyCodeForChar('?'), false);</code>
> 
> This is javadoc inJava SE specification. As is the Action case below.
> I can't think of any actual harm from this change, so OK,  but I am not seeing why it is needed.

The resulting Javadoc html files will contain the same character before and after this fix, so there is no specification change. 

I did this since I thought it increased readability of the source code, but I can just as well revert it.

> test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:
> 
>> 61: 
>> 62:     private static final String INSTRUCTIONS =
>> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "
> 
> I really don't like these tests being changed. It isn't part of the JDK build.
> People compile these in all sorts of locales.
> Please revert all the changes in the client tests.

Just a clarification. What I did was convert curly quotes and an em dash to normal ASCII quotes and an ASCII hyphen, just as it is in all other `INSTRUCTIONS` in the tests. This is similar to what was done in JDK-8354273 and JDK-8354213, and should have been made as part of those PRs if I only had noticed this place by then.

The user's locale should not really matter. When have stringent locale requirements for building, and automatically setup the correct locale while building. I don't think the locale will matter at runtime either, but it n the rare case that it should matter, then pure ASCII would be prefer, wouldn't it?

Let me know if you still want me to revert it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106769659
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106791184

From ihse at openjdk.org  Mon May 26 08:21:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:21:16 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
Message-ID: <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>

On Mon, 26 May 2025 08:10:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java

test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java line 90:

> 88:                 printKey(e);
> 89:                 int keychar = e.getKeyChar();
> 90:                 if (keychar == 27) { // Escape character is 27 or \u001b

@prrace I think this is an actual bug. `\u0021` codes to `!`, and I don't think that is what was meant. Do you still want me to revert it?

test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java line 188:

> 186:                     +          "\"After\" lists.\n"
> 187:                     + "              Added printers are highlighted with "
> 188:                     +               "green color, removed ones \u2014 with "

@prrace This too seems like a bug, or rather a typo. The text currently reads `Added printers are highlighted with green color, removed ones ? with red color.`. The Em dash does not make any sense to me, and seems to be a copy paste error.

Do you still want me to revert it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106774492
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106778974

From ihse at openjdk.org  Mon May 26 08:24:36 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:24:36 GMT
Subject: RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <2QcYZvy5pjx8J6Fi6j59uiHSfnqkp1yUHakx2qsxzKw=.d5720f94-adb8-4f86-aeed-e403c8e43066@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
 <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
 <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>
 <bffWy8H4d6xnje0Gz_jIyv5jPBMuqp7S-iBFZTioTng=.7ee33246-76c2-470f-b608-894b5ba93988@github.com>
 <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com>
 <2QcYZvy5pjx8J6Fi6j59uiHSfnqkp1yUHakx2qsxzKw=.d5720f94-adb8-4f86-aeed-e403c8e43066@github.com>
Message-ID: <C8kpgkckLXbObd9FCCt4nkuI9QAc7A9qZHWZsj0Oaz4=.505c65b6-1685-47ef-a4d6-cc48982f6329@github.com>

On Thu, 22 May 2025 21:26:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> FYI, the style guide for France [recommends](https://fr.wikipedia.org/wiki/Espace_ins%C3%A9cable#En_France):
>> 
>> - U+202F (Narrow No-Break Space NNBSP) preceding semicolon, question mark, and exclamation mark.
>> - U+00A0 (No-Break Space NBSP) preceding colon.
>> 
>> Similar conventions are used in other French speaking countries.
>
>> No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences.
> 
>> This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space.
> 
> 
> I didn't say it reversed that entire changeset. I am saying that the previous changeset for L10N changed
> 
> the Java unicode escape to UTF-8 for the localised message string.
> 
> You propose restoring it to Java escape.
> 
> 
> I wouldn't be surprised if the next message drop reverses what you reversed.
> 
> I don't know what tools the L10N team use but there's a chance it doesn't handle Java escapes
> 
> since that is very much a Java thing. So you are probably making the translation job harder.
> 
> 
> So I am suggesting you leave all of the translation files as is.
> Which might mean withdrawing this PR.

Fair enough. This was meant to be an improvement in readability, not a hindrance for working efficiently. I'll withdraw this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2106804794

From ihse at openjdk.org  Mon May 26 08:24:38 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:24:38 GMT
Subject: Withdrawn: 8356980: Better handling of non-breaking space
In-Reply-To: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
Message-ID: <e4LLN-RARXr9ONGJ35PikxdOZFdsem63EHsN5ZlOr3I=.cd96d653-af8b-4868-b0e0-5c869835d66c@github.com>

On Wed, 14 May 2025 15:11:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences.
> 
> I have checked:
> * U+00A0 NO-BREAK SPACE (NBSP)
> * U+202F NARROW NO-BREAK SPACE (NNBSP)
> * U+2007 FIGURE SPACE
> * U+2060 WORD JOINER
> 
> In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25234

From ihse at openjdk.org  Mon May 26 08:25:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:25:07 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <-HdnkBjrOxo3jUA8jSYhmElKM55oIcSRYYgu70KPR8M=.24dfddf4-6890-4a61-9cef-85f1a2c1238a@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

@JoeWang-Java @naotoj Can you help review this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2908936863

From ihse at openjdk.org  Mon May 26 08:27:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:27:45 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <rtLeXcGYPjdVH16A5db5VvNl3AFbcqwVQYzbrrYZrZo=.5bdee26b-cc5f-4834-9cf3-f710cb34c0a0@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

@justin-curtis-lu Are these files handled by the translation team?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2908942083

From claes.redestad at oracle.com  Mon May 26 08:57:41 2025
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 26 May 2025 08:57:41 +0000
Subject: Add @Stable to java.lang.CharacterDataLatin1 and other
 CharacterData classes
In-Reply-To: <SJ2PR10MB766908F3593FB8A3E3BB82E1A29AA@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <7ccc3056-c4a7-4c82-b66b-37547c2ce92f.shaojin.wensj@alibaba-inc.com>
 <SJ2PR10MB766972482EB6A8C5D947E61AA29BA@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <SJ2PR10MB766908F3593FB8A3E3BB82E1A29AA@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <8F456C2E-99E6-46AE-890A-B1B72055026B@oracle.com>


> On second thought, we should just focus on adding stable and final as you recommend - we should fix stylistic things with no semantic impact later.

I?ll note that the code generator used to emit these CharacterData classes ? build.tools.generatecharacter.GenerateCharacter ? has legacy support to emit both Java and C code. This explain the choice to emit C-style arrays as a deliberate choice to simplify the code generator logic. 

I can?t find any use of this -c flag in our build or elsewhere though, so perhaps a little bit of clean up is in order. 

From alanb at openjdk.org  Mon May 26 09:32:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 09:32:45 GMT
Subject: RFR: 8357561: BootstrapLoggerTest does not work on Ubuntu 24 with
 LANG de_DE.UTF-8 [v2]
In-Reply-To: <UXKCaM-CuwYwTgOkg6tg6qhvndQmYDSpf9WJk19YChE=.da37cc57-5430-48cd-9e1e-e6f4ca1d8907@github.com>
References: <O6WamnBOTS0CLGB8whhkHhosBhPoqUzMAorzWXWWOc0=.d07e26d6-4682-4fcd-a116-4a6bcc69c4c3@github.com>
 <UXKCaM-CuwYwTgOkg6tg6qhvndQmYDSpf9WJk19YChE=.da37cc57-5430-48cd-9e1e-e6f4ca1d8907@github.com>
Message-ID: <cpuqGgGNCzKKF2J_2GeFChg3byiopML1oSxNAyrrAyA=.b378c08c-67dc-43ce-8326-aa8da546e3be@github.com>

On Mon, 26 May 2025 08:16:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On a 'german'  Ubuntu 24 (LANG="de_DE.UTF-8") the jtreg test
>> java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest fails with
>> 
>> 
>> FEIN: hi now!
>> java.lang.RuntimeException: System.err does not contain: FINE: hi now!
>> at BootstrapLoggerTest.main(BootstrapLoggerTest.java:231)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>> at java.base/java.lang.Thread.run(Thread.java:1447)
>> 
>> 
>> The test (and some others in :tier1 as well) do not work with non en/US LANG, so they need an adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust LocalizedLevelName too

test/jdk/java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest.java line 357:

> 355:         }
> 356:         LogStream.err.println(test.name() + ": PASSED");
> 357:         Locale.setDefault(savedLocale);

For othervm tests then I assume there is no need to restore. For tests that may run in the same VM as other tests when try-finally can be used to restore.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25441#discussion_r2106894148

From alan.bateman at oracle.com  Mon May 26 09:47:53 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Mon, 26 May 2025 10:47:53 +0100
Subject: RFC: 8357183: Improving efficiency of
 Writer::append(CharSequence) and Writer::append(CharSequence, int, int) / Sub
 Task of 8356679: Using CharSequence::getChars internally
In-Reply-To: <e6a9e852-2dda-4e3f-9915-2d43c1b333f2@headcrashing.eu>
References: <f4cf0270-eb00-4c52-99a4-8e8057bb2bc9@gmx.net>
 <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com>
 <f4330452-258c-42f8-a24b-9217da839892@headcrashing.eu>
 <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com>
 <b43e53d6-eb0b-4074-80e4-ca7bc0bf64f0@headcrashing.eu>
 <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com>
 <8b59d6d1-fcf8-4be8-93a2-8b5b434b2174@headcrashing.eu>
 <SJ2PR10MB766968186EE02189D1D9039DA29DA@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <e6a9e852-2dda-4e3f-9915-2d43c1b333f2@headcrashing.eu>
Message-ID: <3b5d20ae-ba24-4f55-ba04-8931821510df@oracle.com>



On 24/05/2025 15:37, Markus KARG wrote:
>
> Chen,
>
>
> thank you for your approval for a DRAFT PR.
>
>
> Following your proposal, I have published a DRAFT PR at 
> https://github.com/openjdk/jdk/pull/25432 so everybody can see what 
> the actual intended code change looks like, and better focus on that 
> actual code change and its risks and benefits. The intention of that 
> DRAFT PR explicitly is NOT to request code reviews, but solely to 
> serve as a publicly visible piece of code to support the ongoing 
> discussion here on this mailing list.
>
>
> TARGET VERSION: 26
>
>
> As we are near to JDK 25 GA, the target is inclusion into JDK 26 or 
> later, so no need to rush. Nevertheless, I would be happy if everybody 
> comments ASAP (at least briefly) to keep this discussion alive.
>
>
> PRELIMINARY RISK ANALYSIS: LOW
>

Writer was retrofitted to implement Appendable in JDK 5 with the 3-arg 
append documented to behave "in exactly the same as ..." the 
write(String) method. That's 20 years of subclasses that might be 
depending on this behavior. Also 20 years of subclasses that may depend 
on the 3-arg append calling the 1-arg append. So my initial reaction is 
that the risk may not be low and this proposal will require significant 
analysis of Writer implementations before the compatibility risk can be 
assessed.

-Alan

From dfuchs at openjdk.org  Mon May 26 10:04:07 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 26 May 2025 10:04:07 GMT
Subject: RFR: 8357561: BootstrapLoggerTest does not work on Ubuntu 24 with
 LANG de_DE.UTF-8 [v2]
In-Reply-To: <UXKCaM-CuwYwTgOkg6tg6qhvndQmYDSpf9WJk19YChE=.da37cc57-5430-48cd-9e1e-e6f4ca1d8907@github.com>
References: <O6WamnBOTS0CLGB8whhkHhosBhPoqUzMAorzWXWWOc0=.d07e26d6-4682-4fcd-a116-4a6bcc69c4c3@github.com>
 <UXKCaM-CuwYwTgOkg6tg6qhvndQmYDSpf9WJk19YChE=.da37cc57-5430-48cd-9e1e-e6f4ca1d8907@github.com>
Message-ID: <y7L9sFst1Xb-lFwJj2iSGB2ixdvQiDbNvndiiTkI5nI=.3e9f05c1-42ef-45bf-bda3-a061796de467@github.com>

On Mon, 26 May 2025 08:16:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On a 'german'  Ubuntu 24 (LANG="de_DE.UTF-8") the jtreg test
>> java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest fails with
>> 
>> 
>> FEIN: hi now!
>> java.lang.RuntimeException: System.err does not contain: FINE: hi now!
>> at BootstrapLoggerTest.main(BootstrapLoggerTest.java:231)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>> at java.base/java.lang.Thread.run(Thread.java:1447)
>> 
>> 
>> The test (and some others in :tier1 as well) do not work with non en/US LANG, so they need an adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust LocalizedLevelName too

Thanks for the patch!
Restoring to the savedLocale at the end of main is not strictly needed since tests run in /othervm mode, but it's not wrong to restore it either. LGTM. Give me some time to test these proposed changes in our CI.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25441#pullrequestreview-2867904187

From michaelm at openjdk.org  Mon May 26 10:31:39 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 26 May 2025 10:31:39 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@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 28 commits:

 - Merge branch 'master' into 8348986-exceptions
 - update
 - reduced number of new categories
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Review update
 - review update
 - Merge branch 'master' into 8348986-exceptions
 - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

-------------

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=10
  Stats: 912 lines in 42 files changed: 681 ins; 101 del; 130 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 pminborg at openjdk.org  Mon May 26 11:26:52 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 26 May 2025 11:26:52 GMT
Subject: RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes
In-Reply-To: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
Message-ID: <_DQFSQ_9pkAj4Rf9E-ONh4DavkQTg85zEEPSXS6ok7A=.183704c5-165e-4210-95fe-444fcea4da9e@github.com>

On Sat, 24 May 2025 10:00:56 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, these are immutable, We should add `@Stable` and final to provide information to the optimizer.

We could add '@Stable` to `static final char[][][] charMap` as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25430#issuecomment-2909388887

From dfuchs at openjdk.org  Mon May 26 11:33:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 26 May 2025 11:33:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
Message-ID: <GuDmDIXX3JwpsXgRXKZHcJo1pwarUx2mlzoLJbl6NaM=.8e831fee-49a7-4420-9c12-26e15db4f3b9@github.com>

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon <michaelm at openjdk.org> 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 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23929#pullrequestreview-2868122303

From pminborg at openjdk.org  Mon May 26 12:02:55 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 26 May 2025 12:02:55 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods [v3]
In-Reply-To: <iZZr6m9SI8AT4JCvui2O5fzjshHwNEfAO1Mv2SPvrTw=.75413ac9-040d-45df-8761-9ce54130f1cc@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
 <SMAz5R1EFhePJhslGUGTDYdAPuPJGbfmn6t14cDpiXc=.950cf100-d65b-4fa4-8ae7-fe28d990b4f9@github.com>
 <zPUdIfuQMhGCj1KqpyQOPBDsz2n2s3RXypGeF_ried0=.54e79fee-a013-4ca3-b82a-f434e8955abb@github.com>
 <RWcp2iVH2Snsyvoy3ojDVRtT0yn4fYWlmeescz9sn_I=.0a32ac9e-623e-4c9f-aa51-636aff68177e@github.com>
 <iZZr6m9SI8AT4JCvui2O5fzjshHwNEfAO1Mv2SPvrTw=.75413ac9-040d-45df-8761-9ce54130f1cc@github.com>
Message-ID: <_sTXM6OTeajXZgl0g4fqyuITxumngvoBxT1cDNyBCFw=.29df110c-305f-4c71-a369-9c56a799f247@github.com>

On Sun, 25 May 2025 12:54:03 GMT, Chen Liang <liach at openjdk.org> wrote:

>> private String(char[] value, int off, int len, Void sig) {
>>         if (len == 0) {
>>             this.value = "".value;
>>             this.coder = "".coder;
>>             return;
>>         }
>>         if (COMPACT_STRINGS) {
>>             byte[] val = StringUTF16.compress(value, off, len);
>>             this.coder = StringUTF16.coderFromArrayLen(val, len);
>>             this.value = val;
>>             return;
>>         }
>>         this.coder = UTF16;
>>         this.value = StringUTF16.toBytes(value, off, len);
>>     }
>> 
>> 
>> This constructor has additional processing logic for len == 0. 
>> 
>> ValueObject may be used here in the future. I think it is better to keep the original structure.
>
> I thought this would both increase cleaniness and reduce code size of the decode method. @minborg What do you think? This also removes one of the switches on COMPACT_STRING.

I think it is better to keep the code smaller rather than saving 0.2 ns for skipping the zero-length check, which might get optimized away anyhow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2107187594

From redestad at openjdk.org  Mon May 26 12:14:52 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 26 May 2025 12:14:52 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods [v3]
In-Reply-To: <_sTXM6OTeajXZgl0g4fqyuITxumngvoBxT1cDNyBCFw=.29df110c-305f-4c71-a369-9c56a799f247@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
 <SMAz5R1EFhePJhslGUGTDYdAPuPJGbfmn6t14cDpiXc=.950cf100-d65b-4fa4-8ae7-fe28d990b4f9@github.com>
 <zPUdIfuQMhGCj1KqpyQOPBDsz2n2s3RXypGeF_ried0=.54e79fee-a013-4ca3-b82a-f434e8955abb@github.com>
 <RWcp2iVH2Snsyvoy3ojDVRtT0yn4fYWlmeescz9sn_I=.0a32ac9e-623e-4c9f-aa51-636aff68177e@github.com>
 <iZZr6m9SI8AT4JCvui2O5fzjshHwNEfAO1Mv2SPvrTw=.75413ac9-040d-45df-8761-9ce54130f1cc@github.com>
 <_sTXM6OTeajXZgl0g4fqyuITxumngvoBxT1cDNyBCFw=.29df110c-305f-4c71-a369-9c56a799f247@github.com>
Message-ID: <-eqT0GnSEhjr0MDVe7ywxx1e5m4UUVYn4VmI_VJ3bYQ=.949b3b59-1790-45da-899a-6e09188941f1@github.com>

On Mon, 26 May 2025 12:00:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> I thought this would both increase cleaniness and reduce code size of the decode method. @minborg What do you think? This also removes one of the switches on COMPACT_STRING.
>
> I think it is better to keep the code smaller rather than saving 0.2 ns for skipping the zero-length check, which might get optimized away anyhow.

That zero-length check in `String(char[], int, int, Void)` was done as an optimization, too, so would be good if we leveraged it in paths that currently miss out for consistency. It was done maybe not so much for speed but to reduce memory and allocation pressure (empty `String`s are surprisingly common in many apps).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2107206228

From jpai at openjdk.org  Mon May 26 12:33:32 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 May 2025 12:33:32 GMT
Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies
 if Connection is subsequently closed
Message-ID: <VTKn99Us3UFmdorIHejMcIiqSL_Q_ma5Ju25cRbiOeQ=.e7655703-6c7c-487a-a98e-64339edd0197@github.com>

Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708?

As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen.

The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`.

A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces.

tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25.

-------------

Commit messages:
 - add test
 - 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed

Changes: https://git.openjdk.org/jdk/pull/25449/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25449&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357708
  Stats: 533 lines in 3 files changed: 440 ins; 58 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/25449.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25449/head:pull/25449

PR: https://git.openjdk.org/jdk/pull/25449

From nbenalla at openjdk.org  Mon May 26 12:44:01 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 26 May 2025 12:44:01 GMT
Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to
 private/protected types in java.base [v3]
In-Reply-To: <ZV4YrCANI01Lj9XHvkjdb4InxXr-bsGjKLy2BaNWy5w=.356206aa-cb50-4348-b374-a19ae2ffcc19@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
 <ZV4YrCANI01Lj9XHvkjdb4InxXr-bsGjKLy2BaNWy5w=.356206aa-cb50-4348-b374-a19ae2ffcc19@github.com>
Message-ID: <W-AqudctbSkZ6zNtSn0TC_ZMB5huGA_NIKyqfkqHmQo=.bb67eff3-f5ec-4f3c-8579-8014c871ca77@github.com>

On Fri, 23 May 2025 14:59:07 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch to fix some `javadoc` bugs in `java.base`.
>> Certain `@link` tags used to refer to private fields instead of public APIs.
>> 
>> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update javadoc based on feedback

All files have been reviewed. Thanks All!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25287#issuecomment-2909611326

From nbenalla at openjdk.org  Mon May 26 12:44:01 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 26 May 2025 12:44:01 GMT
Subject: Integrated: 8356632: Fix remaining {@link/@linkplain} tags with refer
 to private/protected types in java.base
In-Reply-To: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
References: <iwJQMPXRboQtcXPJA_Dm4nYrEHGvpz1WBqlxsJ9W1aQ=.5b28ede5-2e70-472c-841c-9be0e90cbffb@github.com>
Message-ID: <LWrM1KjboN8_atQM9_jbSW58HqQ4u3cjfIgTJ06SBvA=.8ffd59da-e73a-4e4f-910f-1071ea00e9f0@github.com>

On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to fix some `javadoc` bugs in `java.base`.
> Certain `@link` tags used to refer to private fields instead of public APIs.
> 
> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types.
> 
> TIA

This pull request has now been integrated.

Changeset: bd095896
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd095896dd6e3fccb932f3d9823008766e9ab18d
Stats:     12 lines in 5 files changed: 0 ins; 0 del; 12 mod

8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base

Reviewed-by: weijun, liach

-------------

PR: https://git.openjdk.org/jdk/pull/25287

From dl at openjdk.org  Mon May 26 12:54:06 2025
From: dl at openjdk.org (Doug Lea)
Date: Mon, 26 May 2025 12:54:06 GMT
Subject: RFR: 8357146: ForkJoinPool:schedule(*) does not throw
 RejectedExecutionException when pool is shutdown [v2]
In-Reply-To: <qnY_DbR3b52ILHFE9lxchxhF1mAiykq-QNd961efDiU=.8f497802-a9e1-41f6-951c-a56eb4a6ee6f@github.com>
References: <qnY_DbR3b52ILHFE9lxchxhF1mAiykq-QNd961efDiU=.8f497802-a9e1-41f6-951c-a56eb4a6ee6f@github.com>
Message-ID: <kvdgW3gHAkwg2EdNQLlnUE7OfK7opFYMgMnJ6z4yvFM=.b64540fd-4c43-410e-9f9c-e24b2a576b5e@github.com>

> Method startDelayScheduler should trap the ISE thrown by SharedThreadContainer.start and possibly re-try termination before eventually throwing RejectedExecutionException.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  rethrow Errors in startDelayScheduler

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25431/files
  - new: https://git.openjdk.org/jdk/pull/25431/files/eeb5119e..675aff74

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25431&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25431&range=00-01

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25431/head:pull/25431

PR: https://git.openjdk.org/jdk/pull/25431

From nbenalla at openjdk.org  Mon May 26 13:07:06 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 26 May 2025 13:07:06 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v4]
In-Reply-To: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
Message-ID: <Y-US_zsDrvpXFTDX_K06PCjmzy6GVc6Vra1zRUaO3CE=.bab51f96-780a-44b3-9416-7780435ed4c0@github.com>

> Get JDK 26 underway.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Update --release 25 symbol information for JDK 25 build 24
   The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
 - problem list some failing tests
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Update --release 25 symbol information for JDK 25 build 23
   The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
 - Update release date
 - Update --release 25 symbol information for JDK 25 build 21
   The macOS/AArch64 build 21 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
   
   # Conflicts:
   #	test/langtools/tools/javac/versions/Versions.java
 - ... and 4 more: https://git.openjdk.org/jdk/compare/bd095896...b79e5022

-------------

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=03
  Stats: 1823 lines in 58 files changed: 1734 ins; 16 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/25008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008

PR: https://git.openjdk.org/jdk/pull/25008

From swen at openjdk.org  Mon May 26 13:19:08 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 26 May 2025 13:19:08 GMT
Subject: RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes [v2]
In-Reply-To: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
Message-ID: <QfFJJ4dvvF4On-SP4TG837AIKICxgaQ1t_Nr8qTmPA8=.4b039e7a-4ff2-4254-87c9-7cd048c77304@github.com>

> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, these are immutable, We should add `@Stable` and final to provide information to the optimizer.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  add '@stabletostatic final char[][][] charMap`, from @minborg

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25430/files
  - new: https://git.openjdk.org/jdk/pull/25430/files/d5936dd5..d9f0e5e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25430&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25430&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25430/head:pull/25430

PR: https://git.openjdk.org/jdk/pull/25430

From swen at openjdk.org  Mon May 26 13:23:07 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 26 May 2025 13:23:07 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods [v6]
In-Reply-To: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
Message-ID: <tlCQlGmGPhnhTfrEn7klD1Ezah-NwsgNC8ytHiAJJUo=.46451eeb-a1e5-4a48-92a9-ccd0d635d057@github.com>

> Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline.
> 
> The following is the output information of PrintInlining:
> 
>                 @ 9   java.lang.String::<init> (12 bytes)   inline (hot)
> !m                 @ 1   java.nio.charset.Charset::defaultCharset (52 bytes)   inline (hot)
> !                  @ 8   java.lang.String::<init> (852 bytes)   failed to inline: hot method too big
> 
> 
> In Java code, the big method that cannot be inlined is the following constructor
> 
> 
> String(Charset charset, byte[] bytes, int offset, int length) {}
> 
> The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  from @liach

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25290/files
  - new: https://git.openjdk.org/jdk/pull/25290/files/58583b77..4f3eea73

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=04-05

  Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25290.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25290/head:pull/25290

PR: https://git.openjdk.org/jdk/pull/25290

From liach at openjdk.org  Mon May 26 14:58:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 May 2025 14:58:00 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods [v6]
In-Reply-To: <tlCQlGmGPhnhTfrEn7klD1Ezah-NwsgNC8ytHiAJJUo=.46451eeb-a1e5-4a48-92a9-ccd0d635d057@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
 <tlCQlGmGPhnhTfrEn7klD1Ezah-NwsgNC8ytHiAJJUo=.46451eeb-a1e5-4a48-92a9-ccd0d635d057@github.com>
Message-ID: <HoiFM2AWzrrxYq6JSe9lWuUWuN7lwJ3W1MvXJCw10Nw=.87d67a95-cce9-464f-b01f-d26c503a69aa@github.com>

On Mon, 26 May 2025 13:23:07 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline.
>> 
>> The following is the output information of PrintInlining:
>> 
>>                 @ 9   java.lang.String::<init> (12 bytes)   inline (hot)
>> !m                 @ 1   java.nio.charset.Charset::defaultCharset (52 bytes)   inline (hot)
>> !                  @ 8   java.lang.String::<init> (852 bytes)   failed to inline: hot method too big
>> 
>> 
>> In Java code, the big method that cannot be inlined is the following constructor
>> 
>> 
>> String(Charset charset, byte[] bytes, int offset, int length) {}
>> 
>> The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @liach

src/java.base/share/classes/java/lang/String.java line 661:

> 659:             // ascii
> 660:             if (ad.isASCIICompatible() && !StringCoding.hasNegatives(bytes, offset, length)) {
> 661:                 if (COMPACT_STRINGS) {

Replace this with `return iso88591(bytes, offset, length)`;

src/java.base/share/classes/java/lang/String.java line 673:

> 671:                     value = new byte[length];
> 672:                     ad.decodeToLatin1(bytes, offset, length, value);
> 673:                     coder = LATIN1;

With the other optimizations, you can make this `return new String(value, LATIN1)` and remove the `value` and `coder` local variable declarations.

src/java.base/share/classes/java/lang/String.java line 680:

> 678:                     char[] ca = new char[en];
> 679:                     int clen = ad.decode(bytes, offset, length, ca);
> 680:                     if (COMPACT_STRINGS) {

This can be `return new String(ca, 0, cLen, null);` too,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2107508429
PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2107510678
PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2107506207

From pminborg at openjdk.org  Mon May 26 15:08:52 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 26 May 2025 15:08:52 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v5]
In-Reply-To: <FMxEJ1ovJhtsYGInbaj_4egjdwcfujYTUXJmMcnGWek=.40e4d745-3e66-48a2-90fe-4183a114ae5d@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <kBtT8hpgfy9e9OBLI8_5S9PBsuVmqBuTB_NcoZIwoMA=.78786b50-55ab-4604-9dbd-87f27fcdc575@github.com>
 <FMxEJ1ovJhtsYGInbaj_4egjdwcfujYTUXJmMcnGWek=.40e4d745-3e66-48a2-90fe-4183a114ae5d@github.com>
Message-ID: <NEF9344-4sM6L4AkuGH45VMm09w0xBdWzKZE42AxYGQ=.fa89296a-139d-465a-8316-1b783079c3b1@github.com>

On Fri, 23 May 2025 19:52:50 GMT, Chen Liang <liach at openjdk.org> wrote:

> Can we remove all meaningless `!Architecture.isLittleEndian()` calls and use the platform-specific endianness unsafe primitives instead? For compensation, we can add a check in each of fill2/fill3/fill4 that `assert value == Integer/Short/Long.reverseBytes(value)` if you think that is necessary.

Let's take a look at that under a separate PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2910041204

From mchhipa at openjdk.org  Mon May 26 15:11:50 2025
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Mon, 26 May 2025 15:11:50 GMT
Subject: RFR: 8356443: Update open/test/jdk/TEST.groups manual test groups
 definitions with missing manual test
In-Reply-To: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com>
References: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com>
Message-ID: <9WV8wrYTbOPzYeRG13qM2D1YjqTzgzlQqqu9WYy_Uok=.77e6f0d3-442f-4b5a-9f5e-4c4c5e38bfa1@github.com>

On Wed, 21 May 2025 15:37:34 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test

LGTM

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25360#issuecomment-2910047397

From yujige at gmail.com  Mon May 26 15:31:06 2025
From: yujige at gmail.com (Jige Yu)
Date: Mon, 26 May 2025 08:31:06 -0700
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <MW4PR10MB57743363CCA3306B316F3EEDFF65A@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774265B8728DA0641C48DBAFF152@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYut_G7TRSTr0hPVuxWAvJQ+25JyPBWB7PEtntamWq-E_A@mail.gmail.com>
 <MW4PR10MB5774AB9B6544E949383187F3FFEC2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvyRxcWv65v4+8KcRHys=jkbpfKZ3eK3ijTGKXR1UxNnA@mail.gmail.com>
 <MW4PR10MB5774986199F9EDF854A6D390FFEE2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtE-xwb9tBhjPvObeG9_03nXh1aRA10sO7ibEGkQavntw@mail.gmail.com>
 <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtAUfyUHOdmSeZ2Azny=RJU63FQozY2NxpYu-4xQYCRkA@mail.gmail.com>
 <MW4PR10MB5774B089653C902899FEBEAFFFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB5774BB2B60EE5A1F4B1A7306FFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvxZ0gpHJXW0ctuHwEGwfStfjmLvwV1CgSWrr8438rWPA@mail.gmail.com>
 <MW4PR10MB5774EF4D4316B5BE46B29A0EFFF12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYsJyHeEs1fc4DRTZKwDO_U4Pyjv45BQ5fvr6VbboaVCTQ@mail.gmail.com>
 <MW4PR10MB57743363CCA3306B316F3EEDFF65A@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAKD1RYuPzVW+VHt_MzOrXW93iNv0A03JFSCV+yawCFeaLm=HsA@mail.gmail.com>

Yeah, I think I missed the task cancellation and the joining part.

When the mapConcurrent() thread is interrupted, it propagates the
cancellation to the child threads.

And if any of the children threads (running the user-provided Function)
receives that cancellation, it will still need to catch it and handle
interruption.

That means the interruption isn't swallowed. If the user code wants to
abort, they can always just throw an unchecked exception and catch it from
the caller of mapConcurrent().

That should do for most of the IO type work.

This makes sense.



On Mon, May 26, 2025 at 12:30?AM Viktor Klang <viktor.klang at oracle.com>
wrote:

> Yes, the updated Gatherers.mapConcurrent will continue under interruption
> until done, and then restore the interrupt status of the calling thread.
>
> It cannot (reasonably) do anything else?if it were to throw
> InterruptedException, it couldn't since that is a checked exception and
> there's no tracking of checked exceptions throughout a Stream, and that is
> the specified behavior to handle thread interrupts (i.e. clear flag and
> throw InterruptedException, which is not possible in this case; or, make
> sure that interrupt status is maintained, which is possible in this case.
>
> I have given it some more thought in the meantime, but I haven't arrived
> in something more satisfactory than that, yet.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 26 May 2025 03:07
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Thanks Viktor!
>
> Sorry, I was giving myself more time to read the code, but then I lost
> track.
>
> If I'm reading the code right, the current behavior is that if the current
> thread is interrupted, the mapConcurrent() would suppress the interruption
> until all elements are processed? (It will then restore the interruption
> bit)
>
> Doesn't this break fail fast?
>
> For example, I may have a mapConcurrent() called from within structured
> concurrency, and that fans out to two operations:
> ?
> scope.fork(() -> doA());
> scope.fork(() -> doB());  // calls mapConcurrent() internally
> scope.join().throwIfFailed();
>
> If doA() fails, doB() will be cancelled (thread interrupted).
>
> If mapConcurrent() ignores the interruption, and if doB has a long list to
> process, it'll continue to consume system resources even when the caller no
> longer needs the results, no?
>
>
> On Fri, Feb 7, 2025 at 2:16?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> >Sorry, did the PR stop using Semaphore?
>
> No, not that PR. See:
> https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e__;!!ACWV5N9M2RV99hQ!OKfWrvJEDCkiHcT5b4a6gfeomZzZeq3jv6ir2vf2I5WWIhujtb-by_VuQFaAPDIuAA0qAwpTUjllXMPF$>
>
> The problem with interruption under parallel evaluation is that there is
> no general support for propagation of interruption in CountedCompleters.
> Adding support for such in (at least) GathererOp needs further study before
> contemplating making any changes to mapConcurrent()'s interruption policy.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
>
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Thursday, 6 February 2025 17:04
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Sorry, did the PR stop using Semaphore?
>
> I had naively thought that mapConcurrent() will keep a buffer of Future of
> all currently-running concurrent tasks (it can be a ConcurrentMap<TaskKey,
> Future> if we don't have to ensure FIFO).
>
> Upon interruption, the main thread can call .cancel(true) on all pending
> Futures; optionally join with the VTs (if we need to block until all VTs
> exit); then propagate exception.
>
> Upon completion, each task just removes itself from the ConcurrentMap.
>
> Just in case it adds anything.
>
>
>
> On Thu, Feb 6, 2025 at 6:47?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> After some more investigation it seems tractable to propagate interruption
> of the caller in sequential mode, but parallel mode will require much
> bigger considerations.
>
> I made a comment to that effect on the JBS issue:
> https://bugs.openjdk.org/browse/JDK-8349462?focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Viktor Klang <viktor.klang at oracle.com>
> *Sent:* Thursday, 6 February 2025 11:51
> *To:* Jige Yu <yujige at gmail.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> I think alignment in behavior between parallel Stream and mapConcurrent in
> terms of how interruptions are handled is a possible path forward.
>
> I decided to close the PR for now as I realized my parallel Stream example
> had misled me regarding its exception throwing, so I'll need to go back and
> refine the solution.
>
> It still seems solvable though.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Wednesday, 5 February 2025 19:20
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Oh good call!
>
> I forgot to check what parallel streams do upon interruption (didn't think
> they do any blocking calls, but at least the main thread must block).
>
> On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi Jige,
>
> I opened an issue to track the concern, and I have proposed a change which
> seems to align well with how parallel streams behave under caller thread
> interruption.
>
> I've opened the following PR for review:
> https://github.com/openjdk/jdk/pull/23467
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
>
> If you are able to make a local OpenJDK build with that solution you could
> check if it addresses your use-cases (or not).
>
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
> 8349462: Gatherers.mapConcurrent could support async interrupts by
> viktorklang-ora ? Pull Request #23467 ? openjdk/jdk
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
> This change is likely going to need some extra verbiage in the spec for
> mapConcurrent, and thus a CSR. This behavior aligns mapConcurrent with how
> parallel streams work in conjunction with interrup...
> github.com
> <https://urldefense.com/v3/__http://github.com__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89DBkMefT$>
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Wednesday, 5 February 2025 16:24
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Thanks Viktor!
>
> I understand the problem.
>
> The main reason I asked is because I want to understand how the core Java
> team thinks of throwing an unchecked exception.
>
> As explained above, I consider losing cancellability a big deal, a deal
> breaker even. And I thought throwing unchecked is more acceptable. Because
> the most common reason the mapConcurrent() VT can be interrupted is due to
> cancellation from a parent mapConcurrent(), or a parent Structured
> Concurrency scope. The cancellation could be either from an organic
> exception, or from the downstream not needing more elements, like maybe due
> to findFirst() already getting an element.
>
> In both cases, since the concurrent operation is already cancelled (result
> ignored), what exception pops up to the top level isn't that big of a deal
> (perhaps only a log record will be seen?)
>
> But if the core Java team considers it a bad idea, I would love to learn
> and adjust.
>
> On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi,
>
> The problem is that mapConcurrent cannot throw InterruptedException
> because that is a checked exception, so we cannot clear the interrupted
> flag and throw that exception.
>
> So the updated semantics is to not cut the stream short but instead run to
> completion, restoring the interruption flag.
>
> There exists a couple of alternatives to this approach which I am
> contemplating, but they need to be further explored before I consider
> moving forward with any of them.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 27 January 2025 17:00
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Thanks Viktor!
>
> It looks like the current fix ignores interruption.
>
> I want to make sure my concern of it defeating cancellation is heard and
> understood.
>
> The scenarios I worry about is for a mapConcurrent() that fans out to
> another method call, which internally calls mapConcurrent() as
> implementation detail.
>
> An example:
>
> List<RefundResponse> refundHelper(transaction) {
>   transaction.creditCardAccounts.stream()
>     .gather(mapConcurrent(acct -> service.refund(acct))
>     .toList();
> }
>
> transactions.stream()
>     .gather(mapConcurrent(transaction -> refundHelper(transaction));
>
>
> It seems undesirable that in such a case all the service.refund() calls
> become non cancellable, because the only way the outer mapConcurrent()
> cancels the refundHelper() calls is through Thread.interrupt() the virtual
> threads that call refundHelper(), which would then be disabled by the inner
> mapConcurrent().
>
> Does this example make sense to you? I can further explain if anything
> isn't clear.
>
> But I want to make sure the decision to disable interruption is deliberate
> judgement call that such nested mapConcurrent() is unlikely,or not
> important.
>
> Cheers,
>
>
>
> On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi!
>
> Please see: https://github.com/openjdk/jdk/pull/23100
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23100__;!!ACWV5N9M2RV99hQ!IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Sunday, 26 January 2025 23:03
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* [External] : Re: mapConcurrent() with InterruptedException
>
> Checking in on what you've found out, Viktor.
>
> From where we left off, I understand that you were looking at alternatives
> instead of silent truncation?
>
> Have you reached any conclusion?
>
> We touched on disallowing interruption during mapConcurrent(). I still
> have concerns with disabling cancellation, because it basically undoes this
> API note from the javadoc
> <https://cr.openjdk.org/~alanb/sc-20240503/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)>
> :
>
> API Note: In progress tasks will be attempted to be cancelled, on a
> best-effort basis, in situations where the downstream no longer wants to
> receive any more elements.
> In reality, people will use mapConcurrent() to fan out rpcs. Sometimes
> these rpcs are just a single blocking call; yet sometimes they may
> themselves be a Structured Concurrency scope, with 2 or 3 rpcs that
> constitute a single logical operation. Under two conditions, cancellation
> is imho important semantic:
>
>    1. The downstream code uses filter().findFirst(), and when it sees an
>    element, it will return and no longer needs the other pending rpcs to
>    complete. If cancellation is disabled, these unnecessary rpcs will waste
>    system resources.
>    2. One of the rpc throws and the Stream pipeline needs to propagate
>    the exception. Again, if the other rpcs cannot be cancelled, we'll have
>    many zombie rpcs.
>
> Zombie rpcs may or may not be a deal breaker, depending on the specific
> use case. But for a JDK library, losing cancellation would have a negative
> impact on usability.
>
> My 2c,
>
>
> On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi Ben,
>
> Thanks for raising these questions?getting feedback is crucial in the
> Preview stage of features.
>
> I wrote a reply to the Reddit thread so I'll just summarize here:
>
> It is important to note that *mapConcurrent()* is not a part of the
> Structured Concurrency JEPs, so it is not designed to join SC scopes.
>
> I'm currently experimenting with ignoring-but-restoring interrupts on the
> "calling thread" for *mapConcurrent()*, as well as capping
> work-in-progress to *maxConcurrency* (not only capping the concurrency
> but also the amount of completed-but-yet-to-be-pushed work). Both of these
> adjustments should increase predictability of behavior in the face of
> blocking operations with variable delays.
>
> Another adjustment I'm looking at right now is to harden/improve the
> cleanup to wait for concurrent tasks to acknowledge cancellation, so that
> once the finisher is done executing the VTs are known to have terminated.
>
> As for not preserving the encounter order, that would be a completely
> different thing, and I'd encourage you to experiment with that if that
> functionality would be interesting for your use-case(s).
>
> Again, thanks for your feedback!
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Jige
> Yu <yujige at gmail.com>
> *Sent:* Friday, 3 January 2025 17:53
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* mapConcurrent() with InterruptedException
>
> Hi Java Experts,
>
> I sent this email incorrectly to loom-dev@ and was told on Reddit that
> core-libs-dev is the right list.
>
> The question is about the behavior of mapConcurrent() when the thread is
> interrupted.
>
> Currently mapConcurrent()'s finisher phase will re-interrupt the thread,
> then stop at whatever element that has already been processed and return.
>
> This strikes me as a surprising behavior, because for example if I'm
> running:
>
>    Stream.of(1, 2, 3)
>         .gather(mapConcurrent(i -> i * 2))
>         .toList()
>
> and the thread is being interrupted, the result could be any of [2], [2,
> 4] or [2, 4, 6].
>
> Since thread interruption is cooperative, there is no guarantee that the
> thread being interrupted will just abort. It's quite possible that it'll
> keep going and then will use for example [2] as the result of doubling the
> list of [1, 2, 3], which is imho incorrect.
>
> In the Reddit
> <https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread,
> someone argued that interruption rarely happens so it's more of a
> theoretical issue. But interruption can easily happen in Structured
> Concurrency or in mapConcurrent() itself if any subtask has failed in order
> to cancel/interrupt the other ongoing tasks.
>
> There had been discussion about alternative strategies:
>
>    1. Don't respond to interruption and just keep running to completion.
>    2. Re-interrupt thread and wrap the InterruptedException in a standard
>    unchecked exception (StructuredConcurrencyInterruptedException?).
>
>
> I have concerns with option 1 because it disables cancellation propagation
> when mapConcurrent() itself is used in a subtask of a parent
> mapConcurrent() or in a StructuredConcurrencyScope.
>
> Both equivalent Future-composition async code, or C++'s fiber trees
> support cancellation propagation and imho it's a critical feature or else
> it's possible that a zombie thread is still sending RPCs long after the
> main thread has exited (failed, or falled back to some default action).
>
> My arguments for option 2:
>
>    1. InterruptedException is more error prone than traditional checked
>    exceptions for *users* to catch and handle. They can forget to
>    re-interrupt the thread. It's so confusing that even seasoned programmers
>    may not know they are *supposed to* re-interrupt the thread.
>    2. With Stream API using functional interfaces like Supplier,
>    Function, the option of just tacking on "throws IE" isn't available to many
>    users.
>    3. With Virtual Threads, it will be more acceptable, or even become
>    common to do blocking calls from a stream operation (including but
>    exclusive to mapConcurrent()). So the chance users are forced to deal with
>    IE will become substantially higher.
>    4. Other APIs such as the Structured Concurrency API have already
>    started wrapping system checked exceptions like ExecutionException,
>    TimeoutException in unchecked exceptions ( join()
>    <https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for
>    example).
>    5. Imho, exceptions that we'd rather users not catch and handle but
>    instead should mostly just propagate up as is, should be unchecked.
>
> There is also a side discussion
> <https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/comment/m4z4f8c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about
> whether mapConcurrent() is better off preserving input order or push to
> downstream as soon as an element is computed. I'd love to discuss that
> topic too but maybe it's better to start a separate thread?
>
> Thank you and cheers!
>
> Ben Yu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250526/ee20826b/attachment-0001.htm>

From duke at openjdk.org  Mon May 26 15:48:10 2025
From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=)
Date: Mon, 26 May 2025 15:48:10 GMT
Subject: RFR: 8357597: Proxy.getInvocationHandler throws
 NullPointerException instead of IllegalArgumentException for null [v2]
In-Reply-To: <SAxS-e8fh7vXOoBnIxEC6X6fM5KdfM8YwCH5Bl3vdFc=.738ee4a2-f142-40c3-b967-7ffe01f8a258@github.com>
References: <SAxS-e8fh7vXOoBnIxEC6X6fM5KdfM8YwCH5Bl3vdFc=.738ee4a2-f142-40c3-b967-7ffe01f8a258@github.com>
Message-ID: <-nN-8KZpqRsFVBfpjP2hBRwBcpBnsNEM0ndHAb5xfF8=.95ec64f4-77b3-4d59-ace7-77ed2a93570a@github.com>

> `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE.

Steffen Nie?ing has updated the pull request incrementally with one additional commit since the last revision:

  8357597: Update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25419/files
  - new: https://git.openjdk.org/jdk/pull/25419/files/e70cb289..38854aa1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25419&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25419&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25419.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25419/head:pull/25419

PR: https://git.openjdk.org/jdk/pull/25419

From duke at openjdk.org  Mon May 26 15:48:10 2025
From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=)
Date: Mon, 26 May 2025 15:48:10 GMT
Subject: RFR: 8357597: Proxy.getInvocationHandler throws
 NullPointerException instead of IllegalArgumentException for null [v2]
In-Reply-To: <_L16HJaL2iFRPFnS4dyzoVSbAx5jofgsWdOfMqpFq3E=.cb5f0a1d-4269-4e95-a3f5-181242a8050e@github.com>
References: <SAxS-e8fh7vXOoBnIxEC6X6fM5KdfM8YwCH5Bl3vdFc=.738ee4a2-f142-40c3-b967-7ffe01f8a258@github.com>
 <_L16HJaL2iFRPFnS4dyzoVSbAx5jofgsWdOfMqpFq3E=.cb5f0a1d-4269-4e95-a3f5-181242a8050e@github.com>
Message-ID: <Cfu-qqfSKp429Wo5ZGpwWJxNf-TcGVrV6658lBYTBgk=.950a1905-4f23-4f72-85f1-ed49d5a966f9@github.com>

On Mon, 26 May 2025 05:43:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Steffen Nie?ing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357597: Update copyright year
>
> The change looks OK to me. Please update the copyright year on the file from `1999, 2024,` to `1999, 2025,`.

@jaikiran Thanks for spotting this. I've adjusted the copyright year.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25419#issuecomment-2910140949

From liach at openjdk.org  Mon May 26 15:50:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 May 2025 15:50:54 GMT
Subject: RFR: 8357597: Proxy.getInvocationHandler throws
 NullPointerException instead of IllegalArgumentException for null [v2]
In-Reply-To: <-nN-8KZpqRsFVBfpjP2hBRwBcpBnsNEM0ndHAb5xfF8=.95ec64f4-77b3-4d59-ace7-77ed2a93570a@github.com>
References: <SAxS-e8fh7vXOoBnIxEC6X6fM5KdfM8YwCH5Bl3vdFc=.738ee4a2-f142-40c3-b967-7ffe01f8a258@github.com>
 <-nN-8KZpqRsFVBfpjP2hBRwBcpBnsNEM0ndHAb5xfF8=.95ec64f4-77b3-4d59-ace7-77ed2a93570a@github.com>
Message-ID: <9KttBy25fwV50qY-52hO7oGuHnCORBYEmsCpvAN80fU=.6f0f90ba-9247-45bd-b1e5-7c45bdd3ae91@github.com>

On Mon, 26 May 2025 15:48:10 GMT, Steffen Nie?ing <duke at openjdk.org> wrote:

>> `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE.
>
> Steffen Nie?ing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357597: Update copyright year

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25419#pullrequestreview-2868803766

From alanb at openjdk.org  Mon May 26 15:52:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 15:52:55 GMT
Subject: RFR: 8357146: ForkJoinPool:schedule(*) does not throw
 RejectedExecutionException when pool is shutdown [v2]
In-Reply-To: <kvdgW3gHAkwg2EdNQLlnUE7OfK7opFYMgMnJ6z4yvFM=.b64540fd-4c43-410e-9f9c-e24b2a576b5e@github.com>
References: <qnY_DbR3b52ILHFE9lxchxhF1mAiykq-QNd961efDiU=.8f497802-a9e1-41f6-951c-a56eb4a6ee6f@github.com>
 <kvdgW3gHAkwg2EdNQLlnUE7OfK7opFYMgMnJ6z4yvFM=.b64540fd-4c43-410e-9f9c-e24b2a576b5e@github.com>
Message-ID: <X1jCdVQXWYN7lGYdPVsNAyXQaHzuB32pDWFt0UOvjR4=.65e49389-8084-472d-ae37-e9237beba644@github.com>

On Mon, 26 May 2025 12:54:06 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Method startDelayScheduler should trap the ISE thrown by SharedThreadContainer.start and possibly re-try termination before eventually throwing RejectedExecutionException.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rethrow Errors in startDelayScheduler

Latest version looks good, and Thread.start throwing OOME will be propagated.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25431#pullrequestreview-2868806444

From jpai at openjdk.org  Mon May 26 15:56:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 May 2025 15:56:55 GMT
Subject: RFR: 8357597: Proxy.getInvocationHandler throws
 NullPointerException instead of IllegalArgumentException for null [v2]
In-Reply-To: <-nN-8KZpqRsFVBfpjP2hBRwBcpBnsNEM0ndHAb5xfF8=.95ec64f4-77b3-4d59-ace7-77ed2a93570a@github.com>
References: <SAxS-e8fh7vXOoBnIxEC6X6fM5KdfM8YwCH5Bl3vdFc=.738ee4a2-f142-40c3-b967-7ffe01f8a258@github.com>
 <-nN-8KZpqRsFVBfpjP2hBRwBcpBnsNEM0ndHAb5xfF8=.95ec64f4-77b3-4d59-ace7-77ed2a93570a@github.com>
Message-ID: <NifnjxNQ03xNV3Paem8TxQha6dSD2CYXjunQhEsc274=.b6c17495-2416-4815-9508-6dfbd5b01552@github.com>

On Mon, 26 May 2025 15:48:10 GMT, Steffen Nie?ing <duke at openjdk.org> wrote:

>> `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE.
>
> Steffen Nie?ing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357597: Update copyright year

Thank you for the update. Looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25419#pullrequestreview-2868813762

From dfuchs at openjdk.org  Mon May 26 15:59:50 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 26 May 2025 15:59:50 GMT
Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP
 replies if Connection is subsequently closed
In-Reply-To: <VTKn99Us3UFmdorIHejMcIiqSL_Q_ma5Ju25cRbiOeQ=.e7655703-6c7c-487a-a98e-64339edd0197@github.com>
References: <VTKn99Us3UFmdorIHejMcIiqSL_Q_ma5Ju25cRbiOeQ=.e7655703-6c7c-487a-a98e-64339edd0197@github.com>
Message-ID: <Sd-PJhZYbfwz5SXfYnDKgw8Ie_HaHQWjwBKV93teijA=.f48ec2b6-91ad-476a-88ef-81c9188d1c07@github.com>

On Mon, 26 May 2025 12:28:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708?
> 
> As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen.
> 
> The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`.
> 
> A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces.
> 
> tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25.

src/java.naming/share/classes/com/sun/jndi/ldap/LdapRequest.java line 100:

> 98:         // Add a new reply to the queue of unprocessed replies.
> 99:         try {
> 100:             replies.put(ber);

So theoretically this could get into the queue after one of the two markers has already been put in the queue, since we no longer use the lock. The question is: is this a problem? I'd be tempted to say no - except that getReplyBer() will take the markers out of the queue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25449#discussion_r2107600300

From jpai at openjdk.org  Mon May 26 16:18:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 May 2025 16:18:50 GMT
Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP
 replies if Connection is subsequently closed
In-Reply-To: <Sd-PJhZYbfwz5SXfYnDKgw8Ie_HaHQWjwBKV93teijA=.f48ec2b6-91ad-476a-88ef-81c9188d1c07@github.com>
References: <VTKn99Us3UFmdorIHejMcIiqSL_Q_ma5Ju25cRbiOeQ=.e7655703-6c7c-487a-a98e-64339edd0197@github.com>
 <Sd-PJhZYbfwz5SXfYnDKgw8Ie_HaHQWjwBKV93teijA=.f48ec2b6-91ad-476a-88ef-81c9188d1c07@github.com>
Message-ID: <WUgd6zzvGoagacI1-dQaBcJj9ebL0vpqC28b7LElMx0=.7dfee186-fcee-49cf-ad42-afca69ffd154@github.com>

On Mon, 26 May 2025 15:57:17 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708?
>> 
>> As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen.
>> 
>> The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`.
>> 
>> A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces.
>> 
>> tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25.
>
> src/java.naming/share/classes/com/sun/jndi/ldap/LdapRequest.java line 100:
> 
>> 98:         // Add a new reply to the queue of unprocessed replies.
>> 99:         try {
>> 100:             replies.put(ber);
> 
> So theoretically this could get into the queue after one of the two markers has already been put in the queue, since we no longer use the lock. The question is: is this a problem? I'd be tempted to say no - except that getReplyBer() will take the markers out of the queue.

Hello Daniel,

> I'd be tempted to say no - except that getReplyBer() will take the markers out of the queue.

That's correct - the change intentionally removes the lock and also lets the close/cancel markers land into the queue so that if the `getReplyBer()` is already blocked in a `take()` or `poll()` call, then it will be unblocked and if it isn't yet blocked on those calls then a subsequent call will find these markers (which are distinct for close and cancel).

Adding these (distinct) markers will also allow for an ordered identifiable content in the queue - some replies followed by close/cancel marker or a close/cancel marker followed by replies.

Additionally, the `addRequest()`, `close()` and `cancel()` methods of this `LdapRequet` get called by a single thread managed by the `Connection` class, so there isn't expected to be concurrent calls across these methods. So, I think, removing the lock and letting the (distinct) markers end up in the queue makes this code in the `LdapRequest` simpler.

The `getReplyBer()` the implementation polls the ordered queue, so it find all replies that have arrived before the cancel/close marker is encountered. Once it encounters those markers it can then throw the relevant exception as per its current specified behaviour.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25449#discussion_r2107620182

From shade at openjdk.org  Mon May 26 16:41:24 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 26 May 2025 16:41:24 GMT
Subject: RFR: 8357797: Use StructuredTaskScopeImpl.ST_NEW for state init
Message-ID: <tei7v9cbMCJOwoU7limCQf8ljGQX0t40oz_B9qEwLRw=.6ccfe1f0-7b29-4b39-a982-7f079ec11aa0@github.com>

SonarCloud complains `ST_NEW` constant is not used. Looks to me the constructor implicitly relies on default value for `state`. It would be cleaner to initialize it explicitly

Additional testing:
 - [x] Linux x86_64 server fastdebug, `java/util/concurrent`

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/25452/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25452&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357797
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25452/head:pull/25452

PR: https://git.openjdk.org/jdk/pull/25452

From alanb at openjdk.org  Mon May 26 16:41:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 16:41:51 GMT
Subject: RFR: 8357647 : Stream gatherers forward upstream size information
 to downstream
In-Reply-To: <RxzzF-SBFqP7iZ78Vdpk_t2RGt7smu6FiyeDlKSsO4Y=.e299e352-f6e6-4ec0-8d83-f4999b3e5b15@github.com>
References: <RxzzF-SBFqP7iZ78Vdpk_t2RGt7smu6FiyeDlKSsO4Y=.e299e352-f6e6-4ec0-8d83-f4999b3e5b15@github.com>
Message-ID: <spKqak2HQ-94ieS-oUNeIzl7YR8OTMaT07VeGFL-YPU=.83a0a55e-248c-4ec4-9f74-680add391323@github.com>

On Fri, 23 May 2025 15:15:30 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> While it could be argued that unbounded Spliterators should not report SIZED / SUBSIZED, GatherSink should report an unknown emission size, so switching to downstream.begin(-1) rather than downstream.begin(size).
> 
> Includes a regression test which yields an OOME if this change is omitted.

Looks okay, I assume you'll bump the copyright headers before integration.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25418#pullrequestreview-2868874619

From alanb at openjdk.org  Mon May 26 16:44:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 16:44:52 GMT
Subject: RFR: 8353124: java/lang/Thread/virtual/stress/Skynet.java#Z times
 out on macosx-x64-debug
In-Reply-To: <F4TigL343CD7V_qcvCrTLizAF4NiV3kgQQzv6avwSuw=.44197229-be1a-4369-91a4-1fda34d8478f@github.com>
References: <F4TigL343CD7V_qcvCrTLizAF4NiV3kgQQzv6avwSuw=.44197229-be1a-4369-91a4-1fda34d8478f@github.com>
Message-ID: <U25v8Z_RfufY89Oe-1s_6v6lgrACKtu_Gf1xeL6g62U=.6f07b678-80fd-4607-9d68-5059158b08ed@github.com>

On Tue, 20 May 2025 15:25:52 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This is a simple test update which increases a timeout from 300s to 400 to account for slow mac os test machines.
> A repeat 50 test of :jdk_lang passes. I will run this a few more times before pushing, if the change is acceptable.
> 
> Thanks,
> Michael

test/jdk/java/lang/Thread/virtual/stress/Skynet.java line 35:

> 33:  * @requires vm.debug == true & vm.continuations
> 34:  * @requires vm.gc.Z
> 35:  * @run main/othervm/timeout=400 -XX:+UnlockDiagnosticVMOptions

Increasing the timeout is fine. There isn't anything in the bug report to suggest anything else.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25331#discussion_r2107643430

From alanb at openjdk.org  Mon May 26 16:49:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 16:49:51 GMT
Subject: RFR: 8357797: Use StructuredTaskScopeImpl.ST_NEW for state init
In-Reply-To: <tei7v9cbMCJOwoU7limCQf8ljGQX0t40oz_B9qEwLRw=.6ccfe1f0-7b29-4b39-a982-7f079ec11aa0@github.com>
References: <tei7v9cbMCJOwoU7limCQf8ljGQX0t40oz_B9qEwLRw=.6ccfe1f0-7b29-4b39-a982-7f079ec11aa0@github.com>
Message-ID: <FMNV8VLXG9LHbb7jhXzLziXxH_2jA10usOJV6eJMrAc=.66679e32-0028-44eb-a585-a043279b5875@github.com>

On Mon, 26 May 2025 16:37:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains `ST_NEW` constant is not used. Looks to me the constructor implicitly relies on default value for `state`. It would be cleaner to initialize it explicitly
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/util/concurrent`

src/java.base/share/classes/java/util/concurrent/StructuredTaskScopeImpl.java line 70:

> 68:         this.joiner = joiner;
> 69:         this.threadFactory = threadFactory;
> 70:         this.flock = ThreadFlock.open((name != null) ? name : Objects.toIdentityString(this));

Unnecessary but okay. Do you mind moving it to the end of constructor as the fields are initialized in order declaration order in this constructor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25452#discussion_r2107647128

From dfuchs at openjdk.org  Mon May 26 16:55:50 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 26 May 2025 16:55:50 GMT
Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP
 replies if Connection is subsequently closed
In-Reply-To: <WUgd6zzvGoagacI1-dQaBcJj9ebL0vpqC28b7LElMx0=.7dfee186-fcee-49cf-ad42-afca69ffd154@github.com>
References: <VTKn99Us3UFmdorIHejMcIiqSL_Q_ma5Ju25cRbiOeQ=.e7655703-6c7c-487a-a98e-64339edd0197@github.com>
 <Sd-PJhZYbfwz5SXfYnDKgw8Ie_HaHQWjwBKV93teijA=.f48ec2b6-91ad-476a-88ef-81c9188d1c07@github.com>
 <WUgd6zzvGoagacI1-dQaBcJj9ebL0vpqC28b7LElMx0=.7dfee186-fcee-49cf-ad42-afca69ffd154@github.com>
Message-ID: <CZdLQBjUl3_Zc7iYQy8wQu_S-oas7bAq_VJI61PV-XU=.c2be4d19-ec1a-4256-9878-19804be74566@github.com>

On Mon, 26 May 2025 16:16:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Additionally, the addRequest(), close() and cancel() methods of this LdapRequet get called by a single thread managed by the Connection class, so there isn't expected to be concurrent calls across these methods. 

I am not seeing that - close() is called by Connection.cleanup() which seems to be callable asynchronously.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25449#discussion_r2107652428

From msheppar at openjdk.org  Mon May 26 17:10:54 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 17:10:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
Message-ID: <d94-xQnF1ppR1_a0OxbNpFUlocFLhmMjth3QNkyb_Tw=.805108e3-04fc-4a96-9ad1-9fd08d8f1aa1@github.com>

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon <michaelm at openjdk.org> 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 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.

new file => copyright ?

Copyright (c) 2025,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107664521

From shade at openjdk.org  Mon May 26 17:16:01 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 26 May 2025 17:16:01 GMT
Subject: RFR: 8357798: ReverseOrderListView allocates Boolean boxes
Message-ID: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>

SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are allocating and using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the object allocation on common path to allow optional constant folding.

We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `java/util`

-------------

Commit messages:
 - A bit better comment
 - Better fix
 - Fix

Changes: https://git.openjdk.org/jdk/pull/25456/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25456&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357798
  Stats: 14 lines in 1 file changed: 11 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25456.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25456/head:pull/25456

PR: https://git.openjdk.org/jdk/pull/25456

From shade at openjdk.org  Mon May 26 17:17:30 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 26 May 2025 17:17:30 GMT
Subject: RFR: 8357797: Use StructuredTaskScopeImpl.ST_NEW for state init
 [v2]
In-Reply-To: <tei7v9cbMCJOwoU7limCQf8ljGQX0t40oz_B9qEwLRw=.6ccfe1f0-7b29-4b39-a982-7f079ec11aa0@github.com>
References: <tei7v9cbMCJOwoU7limCQf8ljGQX0t40oz_B9qEwLRw=.6ccfe1f0-7b29-4b39-a982-7f079ec11aa0@github.com>
Message-ID: <g3B4BRDBcOFJecRdUTQ-N4ksw1pE8Xi0nT0bGn_8PXc=.1898354b-49f9-412b-8fb9-9c939195f1bb@github.com>

> SonarCloud complains `ST_NEW` constant is not used. Looks to me the constructor implicitly relies on default value for `state`. It would be cleaner to initialize it explicitly
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/util/concurrent`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Move to the end

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25452/files
  - new: https://git.openjdk.org/jdk/pull/25452/files/711a3474..9518cb62

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25452&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25452&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25452/head:pull/25452

PR: https://git.openjdk.org/jdk/pull/25452

From shade at openjdk.org  Mon May 26 17:17:30 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 26 May 2025 17:17:30 GMT
Subject: RFR: 8357797: Use StructuredTaskScopeImpl.ST_NEW for state init
 [v2]
In-Reply-To: <FMNV8VLXG9LHbb7jhXzLziXxH_2jA10usOJV6eJMrAc=.66679e32-0028-44eb-a585-a043279b5875@github.com>
References: <tei7v9cbMCJOwoU7limCQf8ljGQX0t40oz_B9qEwLRw=.6ccfe1f0-7b29-4b39-a982-7f079ec11aa0@github.com>
 <FMNV8VLXG9LHbb7jhXzLziXxH_2jA10usOJV6eJMrAc=.66679e32-0028-44eb-a585-a043279b5875@github.com>
Message-ID: <bnMJOHAvs9LKOQuXUciq4D_pLBG4FvTVESYnr4GBZMM=.f7744b90-e908-4102-a812-625f62da8941@github.com>

On Mon, 26 May 2025 16:46:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move to the end
>
> src/java.base/share/classes/java/util/concurrent/StructuredTaskScopeImpl.java line 70:
> 
>> 68:         this.joiner = joiner;
>> 69:         this.threadFactory = threadFactory;
>> 70:         this.flock = ThreadFlock.open((name != null) ? name : Objects.toIdentityString(this));
> 
> Unnecessary but okay. Do you mind moving it to the end of constructor as the fields are initialized in order declaration order in this constructor.

Yeah, explicit use of `ST_NEW` avoids future accidents, e.g. if we ever introduce a new state that would have to shuffle states around. Moved to the end of constructor now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25452#discussion_r2107669807

From alanb at openjdk.org  Mon May 26 17:19:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 17:19:50 GMT
Subject: RFR: 8357797: Use StructuredTaskScopeImpl.ST_NEW for state init
 [v2]
In-Reply-To: <g3B4BRDBcOFJecRdUTQ-N4ksw1pE8Xi0nT0bGn_8PXc=.1898354b-49f9-412b-8fb9-9c939195f1bb@github.com>
References: <tei7v9cbMCJOwoU7limCQf8ljGQX0t40oz_B9qEwLRw=.6ccfe1f0-7b29-4b39-a982-7f079ec11aa0@github.com>
 <g3B4BRDBcOFJecRdUTQ-N4ksw1pE8Xi0nT0bGn_8PXc=.1898354b-49f9-412b-8fb9-9c939195f1bb@github.com>
Message-ID: <HfNNue6TCP9I55zbwkymKIrv9P1yPMxq0r_RWctV2ds=.eecb29a4-da5c-432d-b162-8ef6d05b4515@github.com>

On Mon, 26 May 2025 17:17:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> SonarCloud complains `ST_NEW` constant is not used. Looks to me the constructor implicitly relies on default value for `state`. It would be cleaner to initialize it explicitly
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `java/util/concurrent`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move to the end

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25452#pullrequestreview-2868916918

From msheppar at openjdk.org  Mon May 26 17:31:54 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 17:31:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
Message-ID: <VR7MqG42V4SmE5H9X3A7PciRmGTvLH9A2dcWgu4CKeo=.c6a68516-7e72-4a1c-9120-458993e2f74f@github.com>

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon <michaelm at openjdk.org> 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 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 130:

> 128:         public abstract String output();
> 129: 
> 130:         protected String output(boolean enhance) {

to help us simple folk getting into a tizzy over a public abstract and a protected method of the same name and overloaded to boot
suggest
refactor rename this method name to composeFilteredMessageText  or composeFilteredText or just compose

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107682303

From msheppar at openjdk.org  Mon May 26 17:42:59 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 17:42:59 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
Message-ID: <nrsNyrsu4t_9uZP9t_GCjRq6amD4YmolFdI3Da_P8To=.450cf3b6-8ee8-4450-9e03-2abe5b678eed@github.com>

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon <michaelm at openjdk.org> 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 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 58:

> 56:  *     public static SensitiveInfo filterUserName(String name)
> 57:  */
> 58: public final class Exceptions {

maybe a refactor rename to convey some of the semantics of the class e.g. ExceptionMessageFilter

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107691017

From raffaello.giulietti at oracle.com  Mon May 26 18:04:19 2025
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Mon, 26 May 2025 20:04:19 +0200
Subject: Add @Stable to BigInteger and BigDecimal
In-Reply-To: <21b4abad-0321-408e-92c2-a87c1ee2e010.shaojin.wensj@alibaba-inc.com>
References: <21b4abad-0321-408e-92c2-a87c1ee2e010.shaojin.wensj@alibaba-inc.com>
Message-ID: <505b67f5-a031-464e-861b-2438b004e5d8@oracle.com>

Depending on which static final arrays, this might be fine.

On 2025-05-26 01:57, wenshao wrote:
> Some static final arrays of BigInteger and BigDecimal are stable and 
> immutable. We should add @Stable to give the optimizer more information
> 
> -
> Shaojin Wen


From msheppar at openjdk.org  Mon May 26 18:15:56 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 18:15:56 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
Message-ID: <zOdLnzkbEVZk84LTjJ7V6rnpx7zAdrGoj5AHy4eGwrU=.a80f6e5f-5f0e-4c2c-936f-82f4cd22ba3e@github.com>

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon <michaelm at openjdk.org> 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 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

src/java.base/share/classes/java/net/HostPortrange.java line 73:

> 71: 
> 72:         // first separate string into two fields: hoststr, portstr
> 73:         String hoststr = null, portstr = null;

you could take the opportunity to update the HostPortrange constructor signature refactor rename
the parameter str to hostname  ;-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107715671

From rgiulietti at openjdk.org  Mon May 26 18:49:01 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 26 May 2025 18:49:01 GMT
Subject: RFR: 8357808: Add a command line option for specifying a counter in
 TestRandomFloatingDecimal
Message-ID: <lcy18pmUVn1YuGSjOgVodYQSphnq6mlnE-yAsrLlcso=.fa5e7943-f7ad-4f88-a7cd-8f46fe7bcf18@github.com>

Add a `-Dcount=N` command line option to specify the number of random samples per test (default is 10'000).

-------------

Commit messages:
 - 8357808: Add a command line option for specifying a counter in TestRandomFloatingDecimal

Changes: https://git.openjdk.org/jdk/pull/25460/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25460&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357808
  Stats: 25 lines in 1 file changed: 18 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25460.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25460/head:pull/25460

PR: https://git.openjdk.org/jdk/pull/25460

From rgiulietti at openjdk.org  Mon May 26 18:59:10 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 26 May 2025 18:59:10 GMT
Subject: RFR: 8357808: Add a command line option for specifying a counter
 in TestRandomFloatingDecimal [v2]
In-Reply-To: <lcy18pmUVn1YuGSjOgVodYQSphnq6mlnE-yAsrLlcso=.fa5e7943-f7ad-4f88-a7cd-8f46fe7bcf18@github.com>
References: <lcy18pmUVn1YuGSjOgVodYQSphnq6mlnE-yAsrLlcso=.fa5e7943-f7ad-4f88-a7cd-8f46fe7bcf18@github.com>
Message-ID: <tkWUZz38VqGvIfIDdWrye7bah6_QG9d3es_FpwTFU_s=.0a77fbb7-3754-4c30-bb60-37a529850b1d@github.com>

> Add a `-Dcount=N` command line option to specify the number of random samples per test (default is 10'000).

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Changed option name to "samples".

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25460/files
  - new: https://git.openjdk.org/jdk/pull/25460/files/982fd166..c95940a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25460&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25460&range=00-01

  Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/25460.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25460/head:pull/25460

PR: https://git.openjdk.org/jdk/pull/25460

From liach at openjdk.org  Mon May 26 19:03:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 May 2025 19:03:49 GMT
Subject: RFR: 8357798: ReverseOrderListView allocates Boolean boxes
In-Reply-To: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
Message-ID: <vn7qQZJ-OeSOdQbWjDrpsUcf0U2SMBhzi6aJ3QIh88o=.d1f36915-2ca5-4dce-984f-a75e06a565a9@github.com>

On Mon, 26 May 2025 17:08:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are allocating and using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the object allocation on common path to allow optional constant folding.
> 
> We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/util`

How is this an allocation? I examined `javap -c -p -v java.util.ReverseOrderListView` and confirmed this compiles to `Boolean.valueOf` in class files, which involves no new allocation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2910469082

From msheppar at openjdk.org  Mon May 26 19:09:53 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 19:09:53 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
Message-ID: <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com>

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon <michaelm at openjdk.org> 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 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253:

> 251:             return;
> 252:         enhancedSocketExceptionText = SecurityProperties.includedInExceptions("hostInfo");
> 253:         enhancedNonSocketExceptionText = SecurityProperties.includedInExceptions("hostInfoExclSocket")

This looks like the inverse of the previous use of a socket category, except this time it anything that not in Socket.

Consider the following: 
includeInException specifies the type of information that maybe included in an enhanced exception 
e.g. Hostname, IPAddress, PortNumber, UserDetails, Uri (including Urls), JarDetails, All
This defines an information policy 

developer are familiar with packages, so a second property specified the "domain" of application of an information policy:  enhancedException.packages specifies a list of packages where the includeInException information policy will apply

an empty list or the enhancedException.packages means freedom of information and the defined includedInException applies to all packages

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107759746

From swen at openjdk.org  Mon May 26 19:20:06 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 26 May 2025 19:20:06 GMT
Subject: RFR: 8357289: Break down the String constructor into smaller
 methods [v7]
In-Reply-To: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
References: <eQKqbsQRPJUSBquzrbgL2jsMtAUucb2BWppnGHgWBfM=.1471970f-3729-4e6a-834d-a69f4471b9d2@github.com>
Message-ID: <LN7-3o6mpt8SZPkTxiKvClVMbbYUh0KgpeCZzoA85Es=.0bf1ee8a-811b-4dcc-8326-cad5b07917a7@github.com>

> Through JVM Option +PrintInlining, we found that String has a constructor codeSize of 852, which is too large. This caused failed to inline.
> 
> The following is the output information of PrintInlining:
> 
>                 @ 9   java.lang.String::<init> (12 bytes)   inline (hot)
> !m                 @ 1   java.nio.charset.Charset::defaultCharset (52 bytes)   inline (hot)
> !                  @ 8   java.lang.String::<init> (852 bytes)   failed to inline: hot method too big
> 
> 
> In Java code, the big method that cannot be inlined is the following constructor
> 
> 
> String(Charset charset, byte[] bytes, int offset, int length) {}
> 
> The above String constructor is too large; break it down into smaller methods with a codeSize under 325 to allow them to be inlined by the C2.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  from @liach

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25290/files
  - new: https://git.openjdk.org/jdk/pull/25290/files/4f3eea73..77c7249e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25290&range=05-06

  Stats: 20 lines in 1 file changed: 0 ins; 15 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25290.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25290/head:pull/25290

PR: https://git.openjdk.org/jdk/pull/25290

From alanb at openjdk.org  Mon May 26 19:25:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 19:25:00 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
 <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com>
Message-ID: <vxqCvjWqjx0ehfLXKfZihnhgkl1PgzKTB3qsKytyPFg=.13c2be37-f450-4918-8ccf-3f3d151e49ec@github.com>

On Mon, 26 May 2025 19:06:56 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Merge branch 'master' into 8348986-exceptions
>>  - update
>>  - reduced number of new categories
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Review update
>>  - review update
>>  - Merge branch 'master' into 8348986-exceptions
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19
>
> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253:
> 
>> 251:             return;
>> 252:         enhancedSocketExceptionText = SecurityProperties.includedInExceptions("hostInfo");
>> 253:         enhancedNonSocketExceptionText = SecurityProperties.includedInExceptions("hostInfoExclSocket")
> 
> This looks like the inverse of the previous use of a socket category, except this time it anything that is not in Socket.
> 
> Consider the following: 
> includeInException specifies the type of information that maybe included in an enhanced exception 
> e.g. Hostname, IPAddress, PortNumber, UserDetails, Uri (including Urls), JarDetails, All
> This defines an information policy 
> 
> developer are familiar with packages, so a second property specified the "domain" of application of an information policy:  enhancedException.packages specifies a list of packages where the includeInException information policy will apply
> 
> an empty list or the enhancedException.packages means freedom of information and the defined includedInException applies to all packages

> This looks like the inverse of the previous use of a socket category, except this time it anything that not in Socket.

I think the PR has it right. No change to existing behavior. To opt-in and reveal more host information in exceptions then you can run it with configured to "hostInfo".  It does mean repurposing the name but it's a good name going forward.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107784068

From msheppar at openjdk.org  Mon May 26 20:24:50 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 20:24:50 GMT
Subject: RFR: 8353124: java/lang/Thread/virtual/stress/Skynet.java#Z times
 out on macosx-x64-debug
In-Reply-To: <F4TigL343CD7V_qcvCrTLizAF4NiV3kgQQzv6avwSuw=.44197229-be1a-4369-91a4-1fda34d8478f@github.com>
References: <F4TigL343CD7V_qcvCrTLizAF4NiV3kgQQzv6avwSuw=.44197229-be1a-4369-91a4-1fda34d8478f@github.com>
Message-ID: <3klPqRWuHRjTINe-m0HnznQ7nnhJPgXCE65elhZTPT8=.8e0210c8-de03-41e4-bb73-3b17828462e4@github.com>

On Tue, 20 May 2025 15:25:52 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This is a simple test update which increases a timeout from 300s to 400 to account for slow mac os test machines.
> A repeat 50 test of :jdk_lang passes. I will run this a few more times before pushing, if the change is acceptable.
> 
> Thanks,
> Michael

it takes typically between 4 and 8 minutes for the test to complete. The current jtreg timeout is 20 minutes
The important parts of the bug report are missing, that is the failure Handler details and in particular the jstack traces, thread dumps etc..
The failure handler was not fully run indicating that the JVM hand difficulty responding to various serviceability commands. 
If there are millions of virtual threads then providing those JVM details  could be difficult.

Allowing another 6 minutes could provide some extra time for the JVM to get through it shutdown work, if there was some impediment causing a delay in the termination of the othervm process, or a slow thread scheduling at the OS level.

Otherwise it will be 26 minutes timeout rather than 20 mins

This test has been recently run over 1000 times in a number test repeat runs with failure ... so its very much intermittent 

The fact that the process capture details were not obtained maybe indicative of a deeper issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25331#issuecomment-2910578033

From msheppar at openjdk.org  Mon May 26 20:42:54 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 20:42:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
Message-ID: <yGyzMVvXj8BRDHM0AdgLCNWUev8RnKaC3O9KN1iKTs0=.0b80c2b1-e312-4a5a-8ca3-19e1e2fb5266@github.com>

On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon <michaelm at openjdk.org> 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 28 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19

You could take a slightly more radical approach, and rather than applying a filter explicitly on the exception message, adopt
a builder pattern for the creation of the filter exceptions, for example 

 FilteredExceptionBuilder / EnhancedExceptionBuilder.

It might provide be more flexible and provide, encapsulating the filtering and policy application inside the builder.

EnhancedExceptionBuilder::class()
::exceptionMessage()
::port()
::hostname()
::userDetails()
::filterPolicy()

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2910598238

From msheppar at openjdk.org  Mon May 26 21:46:52 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 26 May 2025 21:46:52 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <vxqCvjWqjx0ehfLXKfZihnhgkl1PgzKTB3qsKytyPFg=.13c2be37-f450-4918-8ccf-3f3d151e49ec@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
 <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com>
 <vxqCvjWqjx0ehfLXKfZihnhgkl1PgzKTB3qsKytyPFg=.13c2be37-f450-4918-8ccf-3f3d151e49ec@github.com>
Message-ID: <l9KkAlQQv2glZfFUHGys-_X1ZOawNQ4wSIFPzWsJSmk=.1e08e7f2-71d1-41f1-82fa-7f7adee30fcd@github.com>

On Mon, 26 May 2025 19:22:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253:
>> 
>>> 251:             return;
>>> 252:         enhancedSocketExceptionText = SecurityProperties.includedInExceptions("hostInfo");
>>> 253:         enhancedNonSocketExceptionText = SecurityProperties.includedInExceptions("hostInfoExclSocket")
>> 
>> This looks like the inverse of the previous use of a socket category, except this time it anything that is not in Socket.
>> 
>> Consider the following: 
>> includeInException specifies the type of information that maybe included in an enhanced exception 
>> e.g. Hostname, IPAddress, PortNumber, UserDetails, Uri (including Urls), JarDetails, All
>> This defines an information policy 
>> 
>> developer are familiar with packages, so a second property specified the "domain" of application of an information policy:  enhancedException.packages specifies a list of packages where the includeInException information policy will apply
>> 
>> an empty list or the enhancedException.packages means freedom of information and the defined includedInException applies to all packages
>
>> This looks like the inverse of the previous use of a socket category, except this time it anything that not in Socket.
> 
> I think the PR has it right. No change to existing behavior. To opt-in and reveal more host information in exceptions then you can run it with configured to "hostInfo".  It does mean repurposing the name but it's a good name going forward.

The point I was raising, is that the socket etc category was dropped under the premise that it requires knowledge of the APIs used. 
But equally the setting hostInfoExclSocket suggests some knowledge of APIs is available, so there is a contradiction in the rationale presented above
Also the setting enhancedNonSocketExceptionText is inclusive of the setting enhancedSocketExceptionText, which adds further subtleties to the configuration, which was previously suggested should be avoided.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107873149

From liach at openjdk.org  Mon May 26 22:19:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 May 2025 22:19:50 GMT
Subject: RFR: 8357808: Add a command line option for specifying a counter
 in TestRandomFloatingDecimal [v2]
In-Reply-To: <tkWUZz38VqGvIfIDdWrye7bah6_QG9d3es_FpwTFU_s=.0a77fbb7-3754-4c30-bb60-37a529850b1d@github.com>
References: <lcy18pmUVn1YuGSjOgVodYQSphnq6mlnE-yAsrLlcso=.fa5e7943-f7ad-4f88-a7cd-8f46fe7bcf18@github.com>
 <tkWUZz38VqGvIfIDdWrye7bah6_QG9d3es_FpwTFU_s=.0a77fbb7-3754-4c30-bb60-37a529850b1d@github.com>
Message-ID: <BNwRfAJuwzEIDhFpleXhOBhQ_NJswVCk6DkkNtMxdPs=.11af21dd-c6bd-4156-8554-5f44b57d3a9c@github.com>

On Mon, 26 May 2025 18:59:10 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add a `-Dcount=N` command line option to specify the number of random samples per test (default is 10'000).
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed option name to "samples".

Looks reasonable.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25460#pullrequestreview-2869201038

From liach at openjdk.org  Mon May 26 22:28:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 May 2025 22:28:50 GMT
Subject: RFR: 8357681: Fixed the DigitList::toString method causing
 incorrect results during debugging
In-Reply-To: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
Message-ID: <huMphrE4OYzhSsAlqDG3T1vqophIUzLET8gduuCeQ5k=.e72c5faf-43df-4d21-b808-6c9b2f41bcd8@github.com>

On Sun, 18 May 2025 11:11:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.

This is a formatting-related class. Calling i18n devs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25288#issuecomment-2910708066

From dl at openjdk.org  Mon May 26 22:40:55 2025
From: dl at openjdk.org (Doug Lea)
Date: Mon, 26 May 2025 22:40:55 GMT
Subject: Integrated: 8357146: ForkJoinPool:schedule(*) does not throw
 RejectedExecutionException when pool is shutdown
In-Reply-To: <qnY_DbR3b52ILHFE9lxchxhF1mAiykq-QNd961efDiU=.8f497802-a9e1-41f6-951c-a56eb4a6ee6f@github.com>
References: <qnY_DbR3b52ILHFE9lxchxhF1mAiykq-QNd961efDiU=.8f497802-a9e1-41f6-951c-a56eb4a6ee6f@github.com>
Message-ID: <gdsaOX9PPBPCpYLcVNRpkqmni32v3C8qdK7RJNojqRM=.1c1e2499-3350-4812-bb45-9135e9e2c26a@github.com>

On Sat, 24 May 2025 11:35:33 GMT, Doug Lea <dl at openjdk.org> wrote:

> Method startDelayScheduler should trap the ISE thrown by SharedThreadContainer.start and possibly re-try termination before eventually throwing RejectedExecutionException.

This pull request has now been integrated.

Changeset: 2c034f57
Author:    Doug Lea <dl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2c034f57d6b4229aaf195fdd6efd016cf694855f
Stats:     34 lines in 2 files changed: 27 ins; 1 del; 6 mod

8357146: ForkJoinPool:schedule(*) does not throw RejectedExecutionException when pool is shutdown

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25431

From alanb at openjdk.org  Tue May 27 06:12:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 May 2025 06:12:53 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <l9KkAlQQv2glZfFUHGys-_X1ZOawNQ4wSIFPzWsJSmk=.1e08e7f2-71d1-41f1-82fa-7f7adee30fcd@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
 <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com>
 <vxqCvjWqjx0ehfLXKfZihnhgkl1PgzKTB3qsKytyPFg=.13c2be37-f450-4918-8ccf-3f3d151e49ec@github.com>
 <l9KkAlQQv2glZfFUHGys-_X1ZOawNQ4wSIFPzWsJSmk=.1e08e7f2-71d1-41f1-82fa-7f7adee30fcd@github.com>
Message-ID: <yPgX7-tnKUMHv-YOOhgSocI0KmdB3js_hgpIWhsPQy0=.94a4919d-ee0b-4778-9afc-f5d5e9ff87fd@github.com>

On Mon, 26 May 2025 21:44:32 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> The point I was raising, is that the socket etc category was dropped under the premise that it requires knowledge of the APIs used.

Right, what is now "hostInfoExclSocket" is a confusing category and not easy to explain to anyone. However it is the long standing default. If you relax the default then security people will complain. If you make it more strict then developers will complain as it makes troubleshooting harder. With the current proposal then nobody has to deal with this confusing named category. Instead, if you want reveal more exceptions then you run with the property set to hostInfo, a category that is much simpler to understand.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2108262111

From duke at openjdk.org  Tue May 27 07:07:54 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 27 May 2025 07:07:54 GMT
Subject: RFR: 8357798: ReverseOrderListView allocates Boolean boxes
In-Reply-To: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
Message-ID: <bRczIoJ8puaQ87X-_nYV9EI7ZnYCZeAD_sDb_qZ1j94=.4ec70f06-dcd9-4ef4-82c1-15acd78d0f98@github.com>

On Mon, 26 May 2025 17:08:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are allocating and using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the object allocation on common path to allow optional constant folding.
> 
> We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/util`

Well, this?does at?least make?`ReverseOrderListView` have?the?same layout?size as?before [JDK?8356080] and?no?longer grow?when `?XX:?UseCompressedOops` is?used.

--------------------------------------------------------------------------------

Also, shouldn?t?`ReverseOrderListView`?s `final`?fields already?be?trusted to?be?immutable?

[JDK?8356080]: https://bugs.openjdk.org/browse/JDK-8356080

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2911387045

From shade at openjdk.org  Tue May 27 07:38:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 27 May 2025 07:38:52 GMT
Subject: RFR: 8357798: ReverseOrderListView allocates Boolean boxes
In-Reply-To: <vn7qQZJ-OeSOdQbWjDrpsUcf0U2SMBhzi6aJ3QIh88o=.d1f36915-2ca5-4dce-984f-a75e06a565a9@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
 <vn7qQZJ-OeSOdQbWjDrpsUcf0U2SMBhzi6aJ3QIh88o=.d1f36915-2ca5-4dce-984f-a75e06a565a9@github.com>
Message-ID: <Y8jHUi0CzM8HbNdkmRVT1ypnMKrHP112eQbMLUPby4c=.49214fbf-ea2c-43ad-abb4-25a4fd857bf3@github.com>

On Mon, 26 May 2025 19:01:35 GMT, Chen Liang <liach at openjdk.org> wrote:

> How is this an allocation? I examined `javap -c -p -v java.util.ReverseOrderListView` and confirmed this compiles to `Boolean.valueOf` in class files, which involves no new allocation.

Yeah, I brain-fogged a little here. Still, it makes sense to avoid an _object_ when a primitive field would do.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2911481864

From alanb at openjdk.org  Tue May 27 07:47:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 May 2025 07:47:50 GMT
Subject: RFR: 8357798: ReverseOrderListView allocates Boolean boxes
In-Reply-To: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
Message-ID: <vSrC9F7UcRnRWdBwYk0QuxYsI-ZZNS6RD9ijriciSMY=.47afe22a-eaea-4afc-95f4-6f763cf9b30f@github.com>

On Mon, 26 May 2025 17:08:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the existence of the boxed object to allow optional constant folding.
> 
> We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/util`

Does SonarCloud scan source code or class files? I'm wondering if there is anything to feedback to them on this report.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2911514103

From shade at openjdk.org  Tue May 27 07:53:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 27 May 2025 07:53:56 GMT
Subject: RFR: 8357798: ReverseOrderListView allocates Boolean boxes
In-Reply-To: <vSrC9F7UcRnRWdBwYk0QuxYsI-ZZNS6RD9ijriciSMY=.47afe22a-eaea-4afc-95f4-6f763cf9b30f@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
 <vSrC9F7UcRnRWdBwYk0QuxYsI-ZZNS6RD9ijriciSMY=.47afe22a-eaea-4afc-95f4-6f763cf9b30f@github.com>
Message-ID: <2A7YzhkDJCiTzT0ZmaL6XkuhjcE-tJFn72O7COye3Ts=.8abec49d-db63-4a9c-988c-cee328c5e081@github.com>

On Tue, 27 May 2025 07:45:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Does SonarCloud scan source code or class files? I'm wondering if there is anything to feedback to them on this report.

I think both. But as I said, I misunderstood the report: it tells me we are using a boxed `Boolean`, likely unnecessarily -- which is true.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2911530334

From michaelm at openjdk.org  Tue May 27 08:16:32 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 27 May 2025 08:16:32 GMT
Subject: RFR: 8353124: java/lang/Thread/virtual/stress/Skynet.java#Z times
 out on macosx-x64-debug [v2]
In-Reply-To: <F4TigL343CD7V_qcvCrTLizAF4NiV3kgQQzv6avwSuw=.44197229-be1a-4369-91a4-1fda34d8478f@github.com>
References: <F4TigL343CD7V_qcvCrTLizAF4NiV3kgQQzv6avwSuw=.44197229-be1a-4369-91a4-1fda34d8478f@github.com>
Message-ID: <eg9tqvWHA6Yk4yjl0D9ya_s8m-ie2aSVbAbOs9KCz8s=.7ee22658-4c75-475b-8ed4-d250127da8d1@github.com>

> Hi,
> 
> This is a simple test update which increases a timeout from 300s to 400 to account for slow mac os test machines.
> A repeat 50 test of :jdk_lang passes. I will run this a few more times before pushing, if the change is acceptable.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  test update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25331/files
  - new: https://git.openjdk.org/jdk/pull/25331/files/58cdec19..90f5874b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25331&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25331&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25331.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25331/head:pull/25331

PR: https://git.openjdk.org/jdk/pull/25331

From alanb at openjdk.org  Tue May 27 08:19:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 May 2025 08:19:55 GMT
Subject: RFR: 8353124: java/lang/Thread/virtual/stress/Skynet.java#Z times
 out on macosx-x64-debug [v2]
In-Reply-To: <eg9tqvWHA6Yk4yjl0D9ya_s8m-ie2aSVbAbOs9KCz8s=.7ee22658-4c75-475b-8ed4-d250127da8d1@github.com>
References: <F4TigL343CD7V_qcvCrTLizAF4NiV3kgQQzv6avwSuw=.44197229-be1a-4369-91a4-1fda34d8478f@github.com>
 <eg9tqvWHA6Yk4yjl0D9ya_s8m-ie2aSVbAbOs9KCz8s=.7ee22658-4c75-475b-8ed4-d250127da8d1@github.com>
Message-ID: <GUZp-3dl3yKMAX3hTiwNpvDee5aWS9xhwbbQLU-8dbU=.6156c4da-67d5-4021-9fa3-ae75e56ebe9f@github.com>

On Tue, 27 May 2025 08:16:32 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This is a simple test update which increases a timeout from 300s to 400 to account for slow mac os test machines.
>> A repeat 50 test of :jdk_lang passes. I will run this a few more times before pushing, if the change is acceptable.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test update

Okay

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25331#pullrequestreview-2870130662

From michaelm at openjdk.org  Tue May 27 08:39:55 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 27 May 2025 08:39:55 GMT
Subject: Integrated: 8353124: java/lang/Thread/virtual/stress/Skynet.java#Z
 times out on macosx-x64-debug
In-Reply-To: <F4TigL343CD7V_qcvCrTLizAF4NiV3kgQQzv6avwSuw=.44197229-be1a-4369-91a4-1fda34d8478f@github.com>
References: <F4TigL343CD7V_qcvCrTLizAF4NiV3kgQQzv6avwSuw=.44197229-be1a-4369-91a4-1fda34d8478f@github.com>
Message-ID: <O3X-Pq8NH35WGz-t-PqEdqHF8aNT1eQjgxEBN6AIijU=.bf01412e-5654-426f-9656-f78011fdb280@github.com>

On Tue, 20 May 2025 15:25:52 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This is a simple test update which increases a timeout from 300s to 400 to account for slow mac os test machines.
> A repeat 50 test of :jdk_lang passes. I will run this a few more times before pushing, if the change is acceptable.
> 
> Thanks,
> Michael

This pull request has now been integrated.

Changeset: 7cb6e5eb
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7cb6e5eb3e004ad974a0c49e83014844f9f7cabb
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8353124: java/lang/Thread/virtual/stress/Skynet.java#Z times out on macosx-x64-debug

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25331

From shaojin.wensj at alibaba-inc.com  Tue May 27 08:54:02 2025
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Tue, 27 May 2025 16:54:02 +0800
Subject: =?UTF-8?B?QWRkIGBAU3RhYmxlYCB0byBCaWdJbnRlZ2VyIGFuZCBCaWdEZWNpbWFs?=
Message-ID: <26da8afe-646c-4043-bba6-71bb3f6ad68b.shaojin.wensj@alibaba-inc.com>

Some final arrays of BigInteger and BigDecimal are stable and immutable. We should add `@Stable` to give the optimizer more information
-
Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250527/b6db611d/attachment.htm>

From mbaesken at openjdk.org  Tue May 27 08:57:50 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 27 May 2025 08:57:50 GMT
Subject: RFR: 8357561: BootstrapLoggerTest does not work on Ubuntu 24 with
 LANG de_DE.UTF-8 [v2]
In-Reply-To: <UXKCaM-CuwYwTgOkg6tg6qhvndQmYDSpf9WJk19YChE=.da37cc57-5430-48cd-9e1e-e6f4ca1d8907@github.com>
References: <O6WamnBOTS0CLGB8whhkHhosBhPoqUzMAorzWXWWOc0=.d07e26d6-4682-4fcd-a116-4a6bcc69c4c3@github.com>
 <UXKCaM-CuwYwTgOkg6tg6qhvndQmYDSpf9WJk19YChE=.da37cc57-5430-48cd-9e1e-e6f4ca1d8907@github.com>
Message-ID: <Q3X6ygxBDbAnZsBIvY9ONswH4Rt4gl0y3YolTGdWqwc=.9330fc47-c999-47b9-a82a-2ada2d531b49@github.com>

On Mon, 26 May 2025 08:16:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On a 'german'  Ubuntu 24 (LANG="de_DE.UTF-8") the jtreg test
>> java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest fails with
>> 
>> 
>> FEIN: hi now!
>> java.lang.RuntimeException: System.err does not contain: FINE: hi now!
>> at BootstrapLoggerTest.main(BootstrapLoggerTest.java:231)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>> at java.base/java.lang.Thread.run(Thread.java:1447)
>> 
>> 
>> The test (and some others in :tier1 as well) do not work with non en/US LANG, so they need an adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust LocalizedLevelName too

Hi Daniel, thanks for the review !  how were the tests in your CI ?

Noticed some download errors in the GHA, seems this caused a lot of (unrelated) test errors .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25441#issuecomment-2911722135
PR Comment: https://git.openjdk.org/jdk/pull/25441#issuecomment-2911724854

From vklang at openjdk.org  Tue May 27 09:19:57 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 27 May 2025 09:19:57 GMT
Subject: Integrated: 8357647 : Stream gatherers forward upstream size
 information to downstream
In-Reply-To: <RxzzF-SBFqP7iZ78Vdpk_t2RGt7smu6FiyeDlKSsO4Y=.e299e352-f6e6-4ec0-8d83-f4999b3e5b15@github.com>
References: <RxzzF-SBFqP7iZ78Vdpk_t2RGt7smu6FiyeDlKSsO4Y=.e299e352-f6e6-4ec0-8d83-f4999b3e5b15@github.com>
Message-ID: <oba6WuLN-9-ZSgwu_lEJoa_LY3Q4UEdhkydhx3pA4SY=.d4b5e993-2969-4449-a88e-8f1de99c4eda@github.com>

On Fri, 23 May 2025 15:15:30 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> While it could be argued that unbounded Spliterators should not report SIZED / SUBSIZED, GatherSink should report an unknown emission size, so switching to downstream.begin(-1) rather than downstream.begin(size).
> 
> Includes a regression test which yields an OOME if this change is omitted.

This pull request has now been integrated.

Changeset: aea32ec5
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aea32ec5060a2e57947dc3e5d14613241e223ce4
Stats:     40 lines in 2 files changed: 37 ins; 1 del; 2 mod

8357647: Stream gatherers forward upstream size information to downstream

Reviewed-by: liach, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25418

From duke at openjdk.org  Tue May 27 09:28:19 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 27 May 2025 09:28:19 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v13]
In-Reply-To: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
Message-ID: <p6x9VRYgGE3ddjfopOTPbfkkoiocFPQofzTE25yHYek=.b7a75b8b-41fc-44fc-adb7-9d16739c9765@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Merge updates from master
 - More tweaking...
 - Tweaking exact wording.
 - Tweaking exact wording.
 - Don't use JUnit utils in TestNg.
 - Changes based on feedback
 - Changes based on feedback
 - Fixed test.
 - Changes based on review feedback.
 - Changes based on review feedback.
 - ... and 3 more: https://git.openjdk.org/jdk/compare/9c8b2f42...593c3a9b

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/92355287..593c3a9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=11-12

  Stats: 112295 lines in 2398 files changed: 65646 ins; 32848 del; 13801 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

PR: https://git.openjdk.org/jdk/pull/25178

From vklang at openjdk.org  Tue May 27 09:41:27 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 27 May 2025 09:41:27 GMT
Subject: RFR: 8356553 : Incorrect uses of {@link} in
 AbstractQueuedLongSynchronizer and AbstractQueuedSynchronizer
Message-ID: <DIYNj468OURl1lR6zApUxLChBOk_auF2nHZIguw0Cts=.a5878b91-7123-45fe-8c83-6bfdedf468b4@github.com>

I had to tweak the language a bit to better reflect the intent of the text.

-------------

Commit messages:
 - Updating the Javadoc of AQS and AQLS to link to a public version of the method

Changes: https://git.openjdk.org/jdk/pull/25462/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25462&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356553
  Stats: 24 lines in 2 files changed: 1 ins; 0 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/25462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25462/head:pull/25462

PR: https://git.openjdk.org/jdk/pull/25462

From jai.forums2013 at gmail.com  Tue May 27 09:44:06 2025
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 27 May 2025 15:14:06 +0530
Subject: Add `@Stable` to BigInteger and BigDecimal
In-Reply-To: <26da8afe-646c-4043-bba6-71bb3f6ad68b.shaojin.wensj@alibaba-inc.com>
References: <26da8afe-646c-4043-bba6-71bb3f6ad68b.shaojin.wensj@alibaba-inc.com>
Message-ID: <d5e8f879-3e7b-48f1-a7f3-764e3247aebd@gmail.com>

Is this a duplicate of what's already being discussed here 
https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/146692.html?

-Jaikiran

On 27/05/25 2:24 pm, wenshao wrote:
> Some final arrays of BigInteger and BigDecimal are stable and 
> immutable. We should add `@Stable` to give the optimizer more information
>
> -
> Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250527/546ee513/attachment.htm>

From shade at openjdk.org  Tue May 27 09:45:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 27 May 2025 09:45:56 GMT
Subject: RFR: 8357797: Use StructuredTaskScopeImpl.ST_NEW for state init
 [v2]
In-Reply-To: <g3B4BRDBcOFJecRdUTQ-N4ksw1pE8Xi0nT0bGn_8PXc=.1898354b-49f9-412b-8fb9-9c939195f1bb@github.com>
References: <tei7v9cbMCJOwoU7limCQf8ljGQX0t40oz_B9qEwLRw=.6ccfe1f0-7b29-4b39-a982-7f079ec11aa0@github.com>
 <g3B4BRDBcOFJecRdUTQ-N4ksw1pE8Xi0nT0bGn_8PXc=.1898354b-49f9-412b-8fb9-9c939195f1bb@github.com>
Message-ID: <DKrKgStyAjs713uZO70LuSel93-EBevaRGXQjzPlL-U=.407a3a5d-fcf9-45a6-8903-8b8154949f18@github.com>

On Mon, 26 May 2025 17:17:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> SonarCloud complains `ST_NEW` constant is not used. Looks to me the constructor implicitly relies on default value for `state`. It would be cleaner to initialize it explicitly
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `java/util/concurrent`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move to the end

Looks simple enough to me, and unlikely to cause conflicts/problems, so I am integrating now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25452#issuecomment-2911874358

From shade at openjdk.org  Tue May 27 09:45:57 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 27 May 2025 09:45:57 GMT
Subject: Integrated: 8357797: Use StructuredTaskScopeImpl.ST_NEW for state init
In-Reply-To: <tei7v9cbMCJOwoU7limCQf8ljGQX0t40oz_B9qEwLRw=.6ccfe1f0-7b29-4b39-a982-7f079ec11aa0@github.com>
References: <tei7v9cbMCJOwoU7limCQf8ljGQX0t40oz_B9qEwLRw=.6ccfe1f0-7b29-4b39-a982-7f079ec11aa0@github.com>
Message-ID: <NYtR0grJK7IvbJOM9bWee7i7_nq_j88N6BXUcmxikcA=.f3742a5e-7041-4aa1-8634-5bf929e1b231@github.com>

On Mon, 26 May 2025 16:37:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains `ST_NEW` constant is not used. Looks to me the constructor implicitly relies on default value for `state`. It would be cleaner to initialize it explicitly
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/util/concurrent`

This pull request has now been integrated.

Changeset: b9db99d7
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9db99d7f7e3720c7e34fbcd22ff9529054601f6
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8357797: Use StructuredTaskScopeImpl.ST_NEW for state init

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25452

From kbarrett at openjdk.org  Tue May 27 10:02:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 27 May 2025 10:02:55 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v7]
In-Reply-To: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
Message-ID: <_dk_yVITVE3bDKtFMBDvvjkgL8CylYo-m7X99EH9z1o=.c0a913a0-d25a-4205-9fcf-809172618a12@github.com>

> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - Merge branch 'master' into native-reference-get
 - Merge branch 'master' into native-reference-get
 - use new waitForRefProc, some tidying
 - Merge branch 'master' into native-reference-get
 - remove timeout by using waitForReferenceProcessing
 - make ill-timed gc in non-concurrent case less likely
 - fix test package use
 - add package decl to test
 - parameterized return type of native get0
 - test native method
 - ... and 1 more: https://git.openjdk.org/jdk/compare/ae6b12b7...4387e2fe

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24315/files
  - new: https://git.openjdk.org/jdk/pull/24315/files/6b4e4c76..4387e2fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=05-06

  Stats: 94918 lines in 1870 files changed: 55489 ins; 28462 del; 10967 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 aturbanov at openjdk.org  Tue May 27 10:04:54 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 27 May 2025 10:04:54 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v5]
In-Reply-To: <kBtT8hpgfy9e9OBLI8_5S9PBsuVmqBuTB_NcoZIwoMA=.78786b50-55ab-4604-9dbd-87f27fcdc575@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <kBtT8hpgfy9e9OBLI8_5S9PBsuVmqBuTB_NcoZIwoMA=.78786b50-55ab-4604-9dbd-87f27fcdc575@github.com>
Message-ID: <DTpVhPn8t_lpiKLN_fyDILYIiBFhB-b4X04SLY5XRcY=.959cf947-b4e7-486d-8c05-60d6fea5bcce@github.com>

On Thu, 22 May 2025 11:52:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
>> 
>> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
>> 
>> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
>> 
>> This PR passes tier1, tier2, and tier3 on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update benchmark to reflect new fill method

test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java line 53:

> 51: @State(Scope.Thread)
> 52: @OutputTimeUnit(TimeUnit.NANOSECONDS)
> 53: @Fork(value = 3, jvmArgs = { "--add-opens=java.base/jdk.internal.misc=ALL-UNNAMED","--add-opens=java.base/jdk.internal.foreign=ALL-UNNAMED"})

Suggestion:

@Fork(value = 3, jvmArgs = {"--add-opens=java.base/jdk.internal.misc=ALL-UNNAMED", "--add-opens=java.base/jdk.internal.foreign=ALL-UNNAMED"})

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25383#discussion_r2108774005

From markus at headcrashing.eu  Tue May 27 11:14:40 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Tue, 27 May 2025 13:14:40 +0200
Subject: RFC: 8357183: Improving efficiency of
 Writer::append(CharSequence) and Writer::append(CharSequence, int, int) / Sub
 Task of 8356679: Using CharSequence::getChars internally
In-Reply-To: <3b5d20ae-ba24-4f55-ba04-8931821510df@oracle.com>
References: <f4cf0270-eb00-4c52-99a4-8e8057bb2bc9@gmx.net>
 <5a75b255-8222-4e86-95f4-0ea346b0fae0@oracle.com>
 <f4330452-258c-42f8-a24b-9217da839892@headcrashing.eu>
 <36ba8110-b04f-47c6-937f-702ab4d3116c@oracle.com>
 <b43e53d6-eb0b-4074-80e4-ca7bc0bf64f0@headcrashing.eu>
 <729993b7-56e5-4604-9239-f6909d4b2796@oracle.com>
 <8b59d6d1-fcf8-4be8-93a2-8b5b434b2174@headcrashing.eu>
 <SJ2PR10MB766968186EE02189D1D9039DA29DA@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <e6a9e852-2dda-4e3f-9915-2d43c1b333f2@headcrashing.eu>
 <3b5d20ae-ba24-4f55-ba04-8931821510df@oracle.com>
Message-ID: <370a4f5a-4847-447b-ab28-cd2213015da3@headcrashing.eu>

>
> Writer was retrofitted to implement Appendable in JDK 5 with the 3-arg 
> append documented to behave "in exactly the same as ..." the 
> write(String) method. That's 20 years of subclasses that might be 
> depending on this behavior. Also 20 years of subclasses that may 
> depend on the 3-arg append calling the 1-arg append. So my initial 
> reaction is that the risk may not be low and this proposal will 
> require significant analysis of Writer implementations before the 
> compatibility risk can be assessed.
>
> -Alan

Nobody intends to hastily merge this. I already wrote (multiply) that an 
intensive analysis has to be performed and a KI? based analysis of 
Github WAS already performed.


From duke at openjdk.org  Tue May 27 11:30:40 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 27 May 2025 11:30:40 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v14]
In-Reply-To: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
Message-ID: <3SOzBKrNslFY6xVPq1TgAeX5eSiaPpy1Jo_VXjEqcE8=.2de6ca06-97ce-43cd-a4a1-3b2a39c95192@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Tweak wording again...

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/593c3a9b..3e93e53f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=12-13

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

PR: https://git.openjdk.org/jdk/pull/25178

From msheppar at openjdk.org  Tue May 27 11:30:52 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 27 May 2025 11:30:52 GMT
Subject: RFR: 8356443: Update open/test/jdk/TEST.groups manual test groups
 definitions with missing manual test
In-Reply-To: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com>
References: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com>
Message-ID: <2BJWUoiV5qr1LC0SYK64C2y1_X8hJTsNzI3MXvTf8qA=.884e686a-8724-4eb7-8178-9e632144dae0@github.com>

On Wed, 21 May 2025 15:37:34 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test

Marked as reviewed by msheppar (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25360#pullrequestreview-2870691165

From liach at openjdk.org  Tue May 27 11:35:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 May 2025 11:35:52 GMT
Subject: RFR: 8357798: ReverseOrderListView uses Boolean boxes after
 JDK-8356080
In-Reply-To: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
Message-ID: <RnchuRhP8NYc4AkCm6NOEv7qsmLI8dqDVD7DcNhXWew=.e638c700-b6f4-4a42-a876-346296b8b493@github.com>

On Mon, 26 May 2025 17:08:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the existence of the boxed object to allow optional constant folding.
> 
> We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/util`

If we do use byte, please add constant static final fields instead of magic that requires navigation from pass site to fields. Pinging @minborg too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2912178849

From duke at openjdk.org  Tue May 27 11:36:53 2025
From: duke at openjdk.org (duke)
Date: Tue, 27 May 2025 11:36:53 GMT
Subject: RFR: 8356443: Update open/test/jdk/TEST.groups manual test groups
 definitions with missing manual test
In-Reply-To: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com>
References: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com>
Message-ID: <1NzQLsy5gde9k1Lt7Tg4Npe9w6JhZ8qEeF1Fll1j6sE=.bd5f3774-b7fd-48ef-a7b3-a0e436f97604@github.com>

On Wed, 21 May 2025 15:37:34 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test

@serhiysachkov 
Your change (at version a977e3ca9cc40f0a2af2d8faaf5cfd8adace60f2) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25360#issuecomment-2912179884

From duke at openjdk.org  Tue May 27 11:40:57 2025
From: duke at openjdk.org (serhiysachkov)
Date: Tue, 27 May 2025 11:40:57 GMT
Subject: Integrated: 8356443: Update open/test/jdk/TEST.groups manual test
 groups definitions with missing manual test
In-Reply-To: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com>
References: <7lkI9ipZkX0tqZ8Ud7Dz6TLTnkTsa6lk7ivLd1ciyS4=.a091dc02-0464-4e8f-9129-f08629661a53@github.com>
Message-ID: <DqQ285FUlpyXnPQizYxYkPOp2MDpW31mQ7Xy70mcGCA=.ce82d905-e415-4e8d-9d68-d3aca535a09e@github.com>

On Wed, 21 May 2025 15:37:34 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test

This pull request has now been integrated.

Changeset: b4b11d77
Author:    Serhiy Sachkov <serhiy.sachkov at oracle.com>
Committer: Mark Sheppard <msheppar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b4b11d777137c21c8808bbba5bdf20a2b4ff5be6
Stats:     7 lines in 1 file changed: 3 ins; 2 del; 2 mod

8356443: Update open/test/jdk/TEST.groups manual test groups definitions with missing manual test

Reviewed-by: msheppar

-------------

PR: https://git.openjdk.org/jdk/pull/25360

From shade at openjdk.org  Tue May 27 12:02:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 27 May 2025 12:02:55 GMT
Subject: RFR: 8357798: ReverseOrderListView uses Boolean boxes after
 JDK-8356080
In-Reply-To: <RnchuRhP8NYc4AkCm6NOEv7qsmLI8dqDVD7DcNhXWew=.e638c700-b6f4-4a42-a876-346296b8b493@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
 <RnchuRhP8NYc4AkCm6NOEv7qsmLI8dqDVD7DcNhXWew=.e638c700-b6f4-4a42-a876-346296b8b493@github.com>
Message-ID: <ov2PGynMumVr45o5Ns1f1RU-Rm7N7Dz3t-XuB1eZt8s=.dad213ed-eb14-4660-bccd-f8d5a36f6e5a@github.com>

On Tue, 27 May 2025 11:33:28 GMT, Chen Liang <liach at openjdk.org> wrote:

> If we do use byte, please add constant static final fields instead of magic that requires navigation from pass site to fields. 

My initial version did this, and IMO it was worse off: https://github.com/openjdk/jdk/pull/25456/commits/06d3f7feb0565d8bc5f662e5696e10a56aeded37. Positive/negative maps to true/false pretty well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2912250157

From pminborg at openjdk.org  Tue May 27 12:03:41 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 12:03:41 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v6]
In-Reply-To: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
Message-ID: <-_-E4pvswblhrUiDwCgk8Rh9UiBRlmpsaqmCWjnx7gQ=.4b6598f9-eecf-4f35-b599-326fe4de8a88@github.com>

> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
> 
> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
> 
> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
> 
> This PR passes tier1, tier2, and tier3 on multiple platforms.

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 seven additional commits since the last revision:

 - Merge branch 'master' into fill-overlap
 - Update test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update benchmark to reflect new fill method
 - Simplify
 - Add case for long operations and break out methods
 - Correct typo in comment
 - Simplify the fill method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25383/files
  - new: https://git.openjdk.org/jdk/pull/25383/files/5c878bbd..d0cd7bbb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25383&range=04-05

  Stats: 57007 lines in 827 files changed: 38176 ins; 13844 del; 4987 mod
  Patch: https://git.openjdk.org/jdk/pull/25383.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25383/head:pull/25383

PR: https://git.openjdk.org/jdk/pull/25383

From pminborg at openjdk.org  Tue May 27 12:10:52 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 12:10:52 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v5]
In-Reply-To: <NEF9344-4sM6L4AkuGH45VMm09w0xBdWzKZE42AxYGQ=.fa89296a-139d-465a-8316-1b783079c3b1@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <kBtT8hpgfy9e9OBLI8_5S9PBsuVmqBuTB_NcoZIwoMA=.78786b50-55ab-4604-9dbd-87f27fcdc575@github.com>
 <FMxEJ1ovJhtsYGInbaj_4egjdwcfujYTUXJmMcnGWek=.40e4d745-3e66-48a2-90fe-4183a114ae5d@github.com>
 <NEF9344-4sM6L4AkuGH45VMm09w0xBdWzKZE42AxYGQ=.fa89296a-139d-465a-8316-1b783079c3b1@github.com>
Message-ID: <_3aObg-v3Yux4WGDVwd1hxFFtF3bQ7WgmVRaBySEXxo=.6b86e557-8abd-4fc6-b80b-653488242b55@github.com>

On Mon, 26 May 2025 15:06:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> > Can we remove all meaningless `!Architecture.isLittleEndian()` calls and use the platform-specific endianness unsafe primitives instead? For compensation, we can add a check in each of fill2/fill3/fill4 that `assert value == Integer/Short/Long.reverseBytes(value)` if you think that is necessary.
> 
> Let's take a look at that under a separate PR.

https://bugs.openjdk.org/browse/JDK-8357857

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-2912269520

From liach at openjdk.org  Tue May 27 12:16:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 May 2025 12:16:51 GMT
Subject: RFR: 8357798: ReverseOrderListView uses Boolean boxes after
 JDK-8356080
In-Reply-To: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
Message-ID: <KWZG97HjkBXKZ0jevedczf_cjU27MHt3N1lbLNRbFh0=.95fd8dc2-0e52-49b8-90ac-c442cd400215@github.com>

On Mon, 26 May 2025 17:08:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the existence of the boxed object to allow optional constant folding.
> 
> We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/util`

Sure, I think I will hear what per minborg prefers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2912286080

From pminborg at openjdk.org  Tue May 27 13:09:58 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 13:09:58 GMT
Subject: RFR: 8356706: Foreign tests timeout after passing on
 linux-x64-zero
In-Reply-To: <MNGWhQ48W8sGWxAwqdTwi85G1dtJnK7963u6gVEdUA8=.544a4427-811e-4020-bdb4-724529545773@github.com>
References: <MNGWhQ48W8sGWxAwqdTwi85G1dtJnK7963u6gVEdUA8=.544a4427-811e-4020-bdb4-724529545773@github.com>
Message-ID: <cclRaHyx0fSIVWpsYPw88AgCvT7u8jJWYSIMD-lSg2k=.955e84b3-c6e6-48e6-b4a9-079a9c198187@github.com>

On Thu, 15 May 2025 09:49:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR improves the robustness of tests on slow machines such as "zero" variants. The timeout was increased to 10 minutes for both tests. There are many combinations in `TestAccessModes`, so the test takes some time even on a fast machine. In `StdLibTest`, there are numerous native calls, and these can be much slower on "zero" machines. In the latter test class, I made some attempts to improve performance. On my M1 machine, the test was about 10% faster with the changes (but I only did one run, so this might be in the error margin).

I am closing this PR without integrating, as it has been fixed elsewhere (see issue)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25248#issuecomment-2912450694

From pminborg at openjdk.org  Tue May 27 13:09:58 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 13:09:58 GMT
Subject: Withdrawn: 8356706: Foreign tests timeout after passing on
 linux-x64-zero
In-Reply-To: <MNGWhQ48W8sGWxAwqdTwi85G1dtJnK7963u6gVEdUA8=.544a4427-811e-4020-bdb4-724529545773@github.com>
References: <MNGWhQ48W8sGWxAwqdTwi85G1dtJnK7963u6gVEdUA8=.544a4427-811e-4020-bdb4-724529545773@github.com>
Message-ID: <YwriflwvJuKQ3EnG2iU5h5aoYHBd8wAnAFi92p-sQ6I=.6198d54b-9e10-4f27-9caa-60f5011035f1@github.com>

On Thu, 15 May 2025 09:49:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR improves the robustness of tests on slow machines such as "zero" variants. The timeout was increased to 10 minutes for both tests. There are many combinations in `TestAccessModes`, so the test takes some time even on a fast machine. In `StdLibTest`, there are numerous native calls, and these can be much slower on "zero" machines. In the latter test class, I made some attempts to improve performance. On my M1 machine, the test was about 10% faster with the changes (but I only did one run, so this might be in the error margin).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25248

From dfuchs at openjdk.org  Tue May 27 13:36:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 May 2025 13:36:56 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v4]
In-Reply-To: <PivCKhB6vrzWB9DJMCIoyz3LjHiovmNXkPwEO_7SEvg=.7a64990e-1639-4fab-aab1-99f079fb0141@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <XGHmOr1Ln-imsvBG2Z0bfr9wYDO5pkl0r6hXnbQuzvI=.05a7a1a4-0f3a-41ca-be3c-c6c5264189e2@github.com>
 <PnCfACKzgUPJFmIl1jOToEJHjKVfNvQq8ZDYu9mgB4s=.48fc1387-134d-42a6-ae86-8a08e398a906@github.com>
 <3kUW3YQrrh5z2ZHea8beg7tgbzWX_wDH3_UWnLxNafE=.ad3a3955-6c95-4e9a-b448-6ecce423478c@github.com>
 <0ARoEDpYgpVgOK9JOqD-Fbc5FC6kC0Nj48TQMoV9cu8=.95a929fa-edc0-4401-b2e2-cb179511cb0f@github.com>
 <PivCKhB6vrzWB9DJMCIoyz3LjHiovmNXkPwEO_7SEvg=.7a64990e-1639-4fab-aab1-99f079fb0141@github.com>
Message-ID: <CwJXkMpFbb2Z1qd1Modo2yzPbflJvcDnbr-Dp7-K5TE=.c0db3169-c1c1-472d-b26d-dad1c340d952@github.com>

On Mon, 19 May 2025 12:24:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello David, I had another look at this code and after going through it, it looked like `readOnly` field can in fact be made `final` because of the refactoring changes that you did in this PR. I checked out your latest PR locally and here's the additional change I did:
>> 
>> 
>> diff --git a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
>> index e2fddd96fe8..f54b5360ac5 100644
>> --- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
>> +++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
>> @@ -110,8 +110,7 @@ class ZipFileSystem extends FileSystem {
>>      private final Path zfpath;
>>      final ZipCoder zc;
>>      private final ZipPath rootdir;
>> -    // Starts in readOnly (safe mode), but might be reset at the end of initialization.
>> -    private boolean readOnly = true;
>> +    private final boolean readOnly;
>>  
>>      // default time stamp for pseudo entries
>>      private final long zfsDefaultTimeStamp = System.currentTimeMillis();
>> @@ -227,11 +226,6 @@ static ZipAccessMode from(Object value) {
>>  
>>          // Determining a release version uses 'this' instance to read paths etc.
>>          Optional<Integer> multiReleaseVersion = determineReleaseVersion(env);
>> -
>> -        // Set the version-based lookup function for multi-release JARs.
>> -        this.entryLookup =
>> -                multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity());
>> -
>>          // We only allow read-write zip/jar files if they are not multi-release
>>          // JARs and the underlying file is writable.
>>          this.readOnly = forceReadOnly || multiReleaseVersion.isPresent() || !Files.isWritable(zfpath);
>> @@ -241,6 +235,10 @@ static ZipAccessMode from(Object value) {
>>                      : "the ZIP file is not writable";
>>              throw new IOException(reason);
>>          }
>> +        // Set the version-based lookup function for multi-release JARs.
>> +        this.entryLookup =
>> +                multiReleaseVersion.map(this::createVersionedLinks).orElse(Function.identity());
>> +
>>      }
>>  
>>      /**
>> 
>> 
>> 
>> 
>> With the refactoring changes you have done so far, we are now able to determine the ultimate value for `readOnly` before anything in the construction of `ZipFileSystem` would need access to it. Does this additional change look reasonable to you? I haven't run any tests against this change.
>> 
>> Making it `final` and having...
>
> On second thought, may be this isn't enough. I see that I missed the fact that `determineReleaseVersion()` requires access to `this`. Please leave this in the current form that you have in your PR. I need a few more moments to consider if anything needs to be changed.

final members are good! Alternatively if making it final is not an option you could consider replacing:

private boolean readOnly;

with

private boolean readWrite;

I  looked at where `readOnly` was used and there are not that many places, so inverting the flag might not be too intrusive.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2109210071

From alanb at openjdk.org  Tue May 27 14:01:19 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 May 2025 14:01:19 GMT
Subject: RFR: 8357145: CRC/Inflater/Deflater/Adler32 methods that take a
 ByteBuffer throw UOE if backed by shared memory segment
In-Reply-To: <Zks5m0BcfxrtFdXPJ4xcKApNAGbShsytTBut1nc6NCM=.52d25dbd-0145-4f11-bebd-f535e15c513a@github.com>
References: <Zks5m0BcfxrtFdXPJ4xcKApNAGbShsytTBut1nc6NCM=.52d25dbd-0145-4f11-bebd-f535e15c513a@github.com>
Message-ID: <K1gflAoGX1FHjxmo6c0ThG9DV1VzPU1AKGzhQyLY858=.c8b32873-0380-40b9-9f37-16bf1b04f74a@github.com>

On Tue, 20 May 2025 07:37:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to use ` JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` in the package `java.util.zip` so that `Buffer` instances backed by `MemorySegment` instances can be used.
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

Marked as reviewed by alanb (Reviewer).

I think the src changes are good. There are 13 methods across the 5 APIs that need tests for confined/shared/auto to ensure that we have all cases covered.  The tests in the PR are okay but I think we will need a follow-on JBS issue to cover all the cases and avoid surprises.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25321#pullrequestreview-2871212681
PR Comment: https://git.openjdk.org/jdk/pull/25321#issuecomment-2912622466

From aph at openjdk.org  Tue May 27 15:36:14 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 27 May 2025 15:36:14 GMT
Subject: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v8]
In-Reply-To: <PmF5hPmcrk43l3WpNEGxcCyu9zm-mamNvVod4TUMMZk=.223a6c62-a53f-4094-8f3b-2a094dc3425a@github.com>
References: <4LLR5zxDlX1kFvbC9wHErVh6IGD1fH3fponKnlSaICg=.62e5e428-f00b-4fc3-8f1d-973639eceac2@github.com>
 <PmF5hPmcrk43l3WpNEGxcCyu9zm-mamNvVod4TUMMZk=.223a6c62-a53f-4094-8f3b-2a094dc3425a@github.com>
Message-ID: <cvmYi_JYWnPsMSgijoyk6B-K1REFBSCqbfTdE1a6h5Y=.e821b41f-3678-4942-a833-c415a615f21e@github.com>

On Thu, 15 May 2025 16:03:44 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This intrinsic is generally faster than the current implementation for Panama segment operations for all writes larger than about 8 bytes in size, increasing to more than 2* the performance on larger memory blocks on Graviton 2, between "panama" (C2 generated, what we use now) and "unsafe" (this intrinsic).
>> 
>> 
>> Benchmark                       (aligned)  (size)  Mode  Cnt     Score    Error  Units
>> MemorySegmentFillUnsafe.panama       true  262143  avgt   10  7295.638 ?  0.422  ns/op
>> MemorySegmentFillUnsafe.panama      false  262143  avgt   10  8345.300 ? 80.161  ns/op
>> MemorySegmentFillUnsafe.unsafe       true  262143  avgt   10  2930.594 ?  0.180  ns/op
>> MemorySegmentFillUnsafe.unsafe      false  262143  avgt   10  3136.828 ?  0.232  ns/op
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright format correction

> One thing that sometimes helps is a count leading zeroes followed by a multiway switch at the start, or just before the tail, to get started at the right place in the tail (its log-size cascade), for very small inputs.
> 
> This PR #25383 uses clz in that way.
> 
> It also uses an overlapping-store technique to reduce an O(lg N) tail to an O(1) tail, which also depends on the clz step.

> My rough notes on the relative performance of overlapping loads and stores are here FWIW: https://cr.openjdk.org/~jrose/jvm/PartialMemoryWord.cpp

Mmm, interesting. I had a look at the M1 timings to see what might be going on, and I think it's because the processor can in each clock execute 8 instructions but only one taken branch. It can, however, execute two not-taken branches per clock. At present, if our block is 1 (mod 64) bytes long, then we have a string of 5 taken branches and 1 not-taken branch. 

However, I couldn't see anything in the JMH results. I realized on closer inspection that performance was very much limited by the C2-generated caller, which is doing far more work than the intrinsic itself. I eventually tweaked the benchmark to call the intrinsic 1000 times, and trivially converting us to ns.

I'm not keen on the overlapping-store technique in this case because the code gets IMHO unjustifiably complex, but also we would have different timing behaviour for differently aligned fill operations. This seems to me a bit much for something that should be fairly simple.

I did, however, implement the clz-optimized tail. It's great for very short strings (mod 64) but it's worse for the range 32...63 (mod 64). It's also missing the early exit from the log-size cascade, which short-circuits fills that are a whole number of words long.

I tried another thing, which was to have _two_ cascades: one of whole-word-sized stores, and one from 0 to 7 bytes. This was better for fills that are a whole number of words long and some other cases, but had its own timing spikes in a few places (e.g. 36 bytes.)

I measured the total time for arrays of size 1-128 bytes, and took the average throughput.

A: this PR, as checked in.   6.5 cycles/op, 1.8ns.
B: one clz-optimized tail.   6.9 cycles/op, 1.9ns.
C: two clz-optimized tails.  7.2 cycles/op, 2.0ns.

In conclusion: there isn't much in it. We could do better by keeping this code as short as possible, which would allow us to inline the whole thing into its caller rather than the palaver of a C-ABI call to the stub.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2913030626

From duke at openjdk.org  Tue May 27 15:38:15 2025
From: duke at openjdk.org (Edoardo Luppi)
Date: Tue, 27 May 2025 15:38:15 GMT
Subject: RFR: 8266013: Unexpected replacement character handling on
 stateful CharsetEncoder [v2]
In-Reply-To: <8MYxd4bq0m2zaz9_M8ty4OcFqCkzDGTcXcRLFbzKdoU=.58825ee2-dd9f-4690-8bdc-8d5955bb7d51@github.com>
References: <SoeZ13f8UIKlpsttywQzetNsNB6YjXdKNWOzPsnxDNA=.36e520b1-97a6-40aa-9f93-69265f54d553@github.com>
 <8MYxd4bq0m2zaz9_M8ty4OcFqCkzDGTcXcRLFbzKdoU=.58825ee2-dd9f-4690-8bdc-8d5955bb7d51@github.com>
Message-ID: <NwSIpRvx4tOynwQgJfO7LrFPL90NOcvcnIdXqROhrE4=.1f37bd6d-8b34-40ee-a30d-35df33f081c6@github.com>

On Fri, 30 Apr 2021 16:11:30 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> When an invalid character is converted by getBytes() method, the character is converted to replacement byte data.
>> Shift code (SO/SI) may not be added into right place by EBCDIC Mix charset.
>> EBCDIC Mix charset encoder is stateful encoder.
>> Shift code should be added by switching character set.
>> On x-IBM1364, "\u3000\uD800" should be converted to "\x0E\x40\x40\x0F\x6F", but "\x0E\x40\x40\x6F\x0F"
>> SI is not in right place.
>> 
>> Also ISO2022 related charsets use escape sequence to switch character set.
>> But same kind of issue is there.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266013: Unexpected replacement character handling on stateful CharsetEncoder

Hey! Any way this PR could be picked up again? It could be split into two parts, one for EBCDIC, and one for ISO.  
The EBCDIC part should be straightforward as it should not impact template files.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3719#issuecomment-2913031847

From nbenalla at openjdk.org  Tue May 27 15:53:51 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 27 May 2025 15:53:51 GMT
Subject: RFR: 8356553 : Incorrect uses of {@link} in
 AbstractQueuedLongSynchronizer and AbstractQueuedSynchronizer
In-Reply-To: <DIYNj468OURl1lR6zApUxLChBOk_auF2nHZIguw0Cts=.a5878b91-7123-45fe-8c83-6bfdedf468b4@github.com>
References: <DIYNj468OURl1lR6zApUxLChBOk_auF2nHZIguw0Cts=.a5878b91-7123-45fe-8c83-6bfdedf468b4@github.com>
Message-ID: <MUUKubOpiTGb8HMlRrSSIQYRp8tAcyNkMbRhNx_-Q9k=.ec0fc7e4-4bd3-42e9-ba1a-87b38d3e157b@github.com>

On Tue, 27 May 2025 09:35:51 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> I had to tweak the language a bit to better reflect the intent of the text.

Thanks for doing this! There are no longer any links to private types in `java.util.concurrent`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25462#issuecomment-2913093192

From naoto at openjdk.org  Tue May 27 16:03:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 May 2025 16:03:53 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <s4dKsfyuUa1cRaFNYJRe0hUrNQjppVQLLM80KYsGWhc=.b343fac6-9587-4313-b117-dbaf9fe6378b@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
 <s4dKsfyuUa1cRaFNYJRe0hUrNQjppVQLLM80KYsGWhc=.b343fac6-9587-4313-b117-dbaf9fe6378b@github.com>
Message-ID: <qTRaUStoqQ96XCdviWLKMhPpN4d4EjjVhTOIl-kktKM=.21f331ca-e8ad-484d-a570-f387e54dc308@github.com>

On Mon, 26 May 2025 07:18:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume you've done some "test repeat" jobs to ensure that any variance in the version of "expect" on test machines doesn't cause any issues.

Actually I have not. Thanks for reminding. So I ran this through our internal CI on Linux x64, macOS x64, and macOS AArch64. Across 10 tasks (i.e., machines), each with 30 repetitions, that?s a total of 900 test runs?all completed without failure.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2913132945

From rgiulietti at openjdk.org  Tue May 27 16:22:58 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 27 May 2025 16:22:58 GMT
Subject: RFR: 8356891: Some code simplifications in BigInteger [v22]
In-Reply-To: <u9D52c9WxdI9AWB_bPAz3I5nKirlkyddQjMdjkhZDTA=.5005597b-67fb-43a8-a9ee-eeeee3d0cc31@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <u9D52c9WxdI9AWB_bPAz3I5nKirlkyddQjMdjkhZDTA=.5005597b-67fb-43a8-a9ee-eeeee3d0cc31@github.com>
Message-ID: <6D8Ue6zaCiXkmqoEjxeugzD4cGKc6l_ks9pa9Monc-0=.3e9d38a4-4276-4090-aafb-9c8795eddf95@github.com>

On Wed, 21 May 2025 09:12:49 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct typo in comment

src/java.base/share/classes/java/math/BigInteger.java line 4547:

> 4545:      * If the source is trusted the copying may be skipped.
> 4546:      */
> 4547:     private static int[] stripLeadingZeroInts(int[] val, boolean trusted) {

I suggest to restore `trustedStripLeadingZeroInts()`, with an implementation that just invokes this one with `trusted` set to `true`.
And then restore the `trustedStripLeadingZeroInts()` invocations. The name is more intent-revealing and somewhat more conventional.

src/java.base/share/classes/java/math/BigInteger.java line 4732:

> 4730:         /* Allocate output array.  If all non-sign ints are 0x00, we must
> 4731:          * allocate space for one extra output int. */
> 4732:         for (i = a.length - 1; i >= keep && a[i] == 0; i--) // Skip trailing zeros

I think there's no need to check for `i >= keep`.
Suggestion:

        for (i = a.length - 1; a[i] == 0; i--) // Skip trailing zeros

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2109478579
PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2109510018

From henryjen at openjdk.org  Tue May 27 16:23:47 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 27 May 2025 16:23:47 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v15]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <R2XmRmH21H4_GJDcM6Vb1W5eieDnJL5k7jP3q5jbU6E=.384615d4-266c-49d7-8289-08446f77f190@github.com>

> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.

Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:

 - Merge remote-tracking branch 'openjdk/master' into open
 - Merge remote-tracking branch 'openjdk/master' into open
 - Minor tweaks
 - Assure >0 exit code and fix typos
 - Validator to take a file, use term JAR file
 - Mismatched order is considered invalid
 - Adapt review feedback
 - Address review feedback
 - Adjust message based on review feedback
 - Move all validation into EntryValidator, update the document
 - ... and 7 more: https://git.openjdk.org/jdk/compare/e7422102...2690e69f

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/bf82d668..2690e69f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=13-14

  Stats: 130765 lines in 2801 files changed: 79963 ins; 35168 del; 15634 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 joehw at openjdk.org  Tue May 27 16:27:56 2025
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 27 May 2025 16:27:56 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <L9gE2vcTtRmCj8sVb2Mf80vASRun10hEhdF8OJDXDQs=.f32fe500-e46b-4bab-b73c-b78f80723449@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

java.xml changes look good to me. But as you already asked, the translation team owns most of these files.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25229#pullrequestreview-2871771071

From jlu at openjdk.org  Tue May 27 16:34:52 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 27 May 2025 16:34:52 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <rtLeXcGYPjdVH16A5db5VvNl3AFbcqwVQYzbrrYZrZo=.5bdee26b-cc5f-4834-9cf3-f710cb34c0a0@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <rtLeXcGYPjdVH16A5db5VvNl3AFbcqwVQYzbrrYZrZo=.5bdee26b-cc5f-4834-9cf3-f710cb34c0a0@github.com>
Message-ID: <oD07jz4sbaXmrAQXxWt9B31R7oYM1rYfg30hH9d0-Kc=.f3b6cd24-8e2e-4e77-b9dd-4ea4511b64c5@github.com>

On Mon, 26 May 2025 08:25:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.
>
> @justin-curtis-lu Are these files handled by the translation team?

@magicus The ones under java.xml and jdk.jdi are updated by the translation team, I think it'd be best to remove those files from this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2913234396

From naoto at openjdk.org  Tue May 27 16:37:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 May 2025 16:37:56 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <lt8vg3M1QU-xbe_E0l4n1j9V9sM_0VsM8kOt11Mk1L0=.d6e6845c-ff78-45f2-8f8e-6a40b9e12ba1@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
 <lt8vg3M1QU-xbe_E0l4n1j9V9sM_0VsM8kOt11Mk1L0=.d6e6845c-ff78-45f2-8f8e-6a40b9e12ba1@github.com>
Message-ID: <rUvIFs4xs4inLQJ40ELv5mF0_MjWmQMrZ5VTSmltBnk=.80b73a56-2930-4ce3-ace5-c25766698954@github.com>

On Mon, 26 May 2025 07:44:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> test/jdk/sun/text/resources/LocaleDataTest.java line 106:
>> 
>>> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
>>> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
>>> 106:  *        LocaleNames/fr_FR/US=?tats-Unis
>> 
>> This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.
>
> ISO-8859-1 does not sound good, and got me worried. But in fact it seems like the file is pure ASCII, and that is fine. 
> 
> However, if the file should ever be changed to include actual ISO-8859-1 encoding, this might break if tools assume it is UTF-8-encoding, since not all ISO-8859-1 encodings are valid UTF-8.

Thanks. Filed an issue to change the encoding in the test to UTF-8: https://bugs.openjdk.org/browse/JDK-8357882

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2109668481

From naoto at openjdk.org  Tue May 27 16:52:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 May 2025 16:52:55 GMT
Subject: RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes [v2]
In-Reply-To: <QfFJJ4dvvF4On-SP4TG837AIKICxgaQ1t_Nr8qTmPA8=.4b039e7a-4ff2-4254-87c9-7cd048c77304@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
 <QfFJJ4dvvF4On-SP4TG837AIKICxgaQ1t_Nr8qTmPA8=.4b039e7a-4ff2-4254-87c9-7cd048c77304@github.com>
Message-ID: <RtSz5dpekriWi1a1aXKjsINDyfLslrfnSXoBJ2OGtRY=.c3949ca4-2457-441d-beb9-443d1ac69873@github.com>

On Mon, 26 May 2025 13:19:08 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, these are immutable, We should add `@Stable` and final to provide information to the optimizer.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add '@stabletostatic final char[][][] charMap`, from @minborg

Nice refactoring. 
As to C-style array rewrite, I am not so keen on that as they only appear in the generated source files, without any actual benefit.

src/java.base/share/classes/java/lang/CharacterData01.java.template line 30:

> 28: import jdk.internal.vm.annotation.Stable;
> 29: 
> 30: /** The CharacterData class encapsulates the large tables once found in

Taking this opportunity, I'd rectify the comment here (and in other templates too): `CharacterData` -> `CharacterData01`

-------------

PR Review: https://git.openjdk.org/jdk/pull/25430#pullrequestreview-2871829996
PR Review Comment: https://git.openjdk.org/jdk/pull/25430#discussion_r2109689029

From smarks at openjdk.org  Tue May 27 16:57:51 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 27 May 2025 16:57:51 GMT
Subject: RFR: 8357798: ReverseOrderListView uses Boolean boxes after
 JDK-8356080
In-Reply-To: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
Message-ID: <E_RJ4FAYJZfj11LnTeERHR2EdFVotx5F7OqKvqBzS18=.3d9bce74-c4fa-45f1-a63e-f9abca74be6b@github.com>

On Mon, 26 May 2025 17:08:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the existence of the boxed object to allow optional constant folding.
> 
> We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/util`

A bunch of things are going on here. First, yes, changing a `boolean` to `Boolean` in order to gain constant folding seems dubious, against a potential cost of a dependent load. I note further that the `Boolean` class itself has a private final boolean `value` field that itself isn't marked `@Stable` so do we really get constant folding here? Maybe we should look at the `Boolean` class instead?

The conversion to a positive/negative byte here is clever. It's probably a useful technique in some contexts. (Maybe it's worth applying inside the `Boolean` class itself.)

Here, however, it feels to me like the whole exercise is just fiddling around hoping to optimize something in the absence of an actual performance problem. Let's step back a bit and look at the context.

The reverse-ordered view is mostly intended as a temporary view into a backing list, for searching or copying in reverse. I doubt that anyone will do any highly performance-sensitive operations on such a list. If there is unnecessary overhead, it should be eliminated of course, but I don't really see that going on here.

The `modifiable` flag is used only for error checking in mutator methods. It's not checked at all for read-only methods. If the field's value is true, since it's `@Stable final`, this may allow for some constant folding if a mutation is done within an inner loop. As noted originally, the false stable value won't be constant folded. However if the value is false, the mutator methods always throw an exception. This occurs when somebody attempts a mutation operation on an unmodifiable list. From the collection API's point of view this is treated as a programming error. I claim that we don't really care much about the performance of such cases.

I think we should just revert this back to a primitive `boolean` field. I could go either way on it being `@Stable`. I don't think it helps much but maybe it doesn't hurt either.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2913291278

From jlu at openjdk.org  Tue May 27 17:00:50 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 27 May 2025 17:00:50 GMT
Subject: RFR: 8357681: Fixed the DigitList::toString method causing
 incorrect results during debugging
In-Reply-To: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
Message-ID: <SlVuKVaKBTltXCUo-8hmXtBrzws2qhp3nZpnU-gi_p0=.7c3ced55-044b-4650-b63d-e88794e72821@github.com>

On Sun, 18 May 2025 11:11:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.

Change looks good to me, since the previous code causes conflicts where `getStringBuilder` is called during debugging. Did not see any usages of `DigitList.toString()` by us as well.

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25288#pullrequestreview-2871861188

From naoto at openjdk.org  Tue May 27 17:03:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 May 2025 17:03:53 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <b0f0ldjIu6qI6gHCIZj-QuqZdUZ87_2s2znpk2gkmwY=.8d297170-8ec9-4710-9cea-be3b3fe9db03@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

Those TimeZoneNames* resource bundles are in fact leftovers from COMPAT locale provider removal. I am going to remove those files later so you can exclude them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2913310841

From duke at openjdk.org  Tue May 27 17:13:52 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Tue, 27 May 2025 17:13:52 GMT
Subject: RFR: 8357681: Fixed the DigitList::toString method causing
 incorrect results during debugging
In-Reply-To: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
Message-ID: <JLz-9Ki-8Rlw33Dj9qQ4OY43ezpxt-EvxGg01nFhkMA=.7137277f-3316-485a-9602-d22eb6a45d2b@github.com>

On Sun, 18 May 2025 11:11:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.

src/java.base/share/classes/java/text/DigitList.java line 787:

> 785:         }
> 786: 
> 787:         return "0." + new String(digits, 0, count) + "x10^" + decimalAt;

what about

        return new StringBuilder()
                .append("0.")
                .append(digits, 0, count)
                .append("x10^")
                .append(decimalAt)
                .toString();

to avoid the temporary string created by `new String(digits, 0, count)`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25288#discussion_r2109740606

From duke at openjdk.org  Tue May 27 17:17:00 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 27 May 2025 17:17:00 GMT
Subject: RFR: 8356891: Some code simplifications in BigInteger [v22]
In-Reply-To: <6D8Ue6zaCiXkmqoEjxeugzD4cGKc6l_ks9pa9Monc-0=.3e9d38a4-4276-4090-aafb-9c8795eddf95@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <u9D52c9WxdI9AWB_bPAz3I5nKirlkyddQjMdjkhZDTA=.5005597b-67fb-43a8-a9ee-eeeee3d0cc31@github.com>
 <6D8Ue6zaCiXkmqoEjxeugzD4cGKc6l_ks9pa9Monc-0=.3e9d38a4-4276-4090-aafb-9c8795eddf95@github.com>
Message-ID: <VxWxAWpL9HwDtlWUaFr9W9LeTHKEV_-iiTaoy6Nsxkk=.ba5656f0-8104-471e-917e-2613e2b92ae5@github.com>

On Tue, 27 May 2025 15:26:42 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct typo in comment
>
> src/java.base/share/classes/java/math/BigInteger.java line 4732:
> 
>> 4730:         /* Allocate output array.  If all non-sign ints are 0x00, we must
>> 4731:          * allocate space for one extra output int. */
>> 4732:         for (i = a.length - 1; i >= keep && a[i] == 0; i--) // Skip trailing zeros
> 
> I think there's no need to check for `i >= keep`.
> Suggestion:
> 
>         for (i = a.length - 1; a[i] == 0; i--) // Skip trailing zeros

@rgiulietti Because the method assumes that `a` represents a two's complement negative integer, so there is at least a sign bit?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2109745054

From naoto at openjdk.org  Tue May 27 17:20:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 May 2025 17:20:51 GMT
Subject: RFR: 8357681: Fixed the DigitList::toString method causing
 incorrect results during debugging
In-Reply-To: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
Message-ID: <bWkjUEQ7-oxryAzUfwMV49fQuVyilKtkpI1H8WNfO5M=.f76ec910-093b-49f4-a44e-324d5bc21126@github.com>

On Sun, 18 May 2025 11:11:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25288#pullrequestreview-2871923961

From rgiulietti at openjdk.org  Tue May 27 17:27:56 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 27 May 2025 17:27:56 GMT
Subject: RFR: 8356891: Some code simplifications in BigInteger [v22]
In-Reply-To: <VxWxAWpL9HwDtlWUaFr9W9LeTHKEV_-iiTaoy6Nsxkk=.ba5656f0-8104-471e-917e-2613e2b92ae5@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <u9D52c9WxdI9AWB_bPAz3I5nKirlkyddQjMdjkhZDTA=.5005597b-67fb-43a8-a9ee-eeeee3d0cc31@github.com>
 <6D8Ue6zaCiXkmqoEjxeugzD4cGKc6l_ks9pa9Monc-0=.3e9d38a4-4276-4090-aafb-9c8795eddf95@github.com>
 <VxWxAWpL9HwDtlWUaFr9W9LeTHKEV_-iiTaoy6Nsxkk=.ba5656f0-8104-471e-917e-2613e2b92ae5@github.com>
Message-ID: <T45nXqXF6hczpqRt7kiR4WGY0DQrH7FBMN4GbEeaC0k=.60025143-fa68-4899-a99a-d9b8d37bf523@github.com>

On Tue, 27 May 2025 17:14:32 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 4732:
>> 
>>> 4730:         /* Allocate output array.  If all non-sign ints are 0x00, we must
>>> 4731:          * allocate space for one extra output int. */
>>> 4732:         for (i = a.length - 1; i >= keep && a[i] == 0; i--) // Skip trailing zeros
>> 
>> I think there's no need to check for `i >= keep`.
>> Suggestion:
>> 
>>         for (i = a.length - 1; a[i] == 0; i--) // Skip trailing zeros
>
> @rgiulietti Because the method assumes that `a` represents a two's complement negative integer, so there is at least a sign bit?

There's only one usage of `makePositive(int[])`, and only when `a[0] < 0`.
And then there's the method comment that assumes a negative 2's complement number in `a`.

But if you don't feel sure, I don't mind keeping the line as it is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2109770395

From duke at openjdk.org  Tue May 27 17:34:28 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 27 May 2025 17:34:28 GMT
Subject: RFR: 8356891: Some code simplifications in BigInteger [v23]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <kN6UR1uSUN_3epxfOJ61Kw6e9r0zAXL886XLTf8jTH0=.95da8231-14c7-4558-9ac0-9138c926c621@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Removed needless condition
  
  Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/eb3834e3..60d3c1f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=21-22

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From duke at openjdk.org  Tue May 27 17:34:28 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 27 May 2025 17:34:28 GMT
Subject: RFR: 8356891: Some code simplifications in BigInteger [v22]
In-Reply-To: <T45nXqXF6hczpqRt7kiR4WGY0DQrH7FBMN4GbEeaC0k=.60025143-fa68-4899-a99a-d9b8d37bf523@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <u9D52c9WxdI9AWB_bPAz3I5nKirlkyddQjMdjkhZDTA=.5005597b-67fb-43a8-a9ee-eeeee3d0cc31@github.com>
 <6D8Ue6zaCiXkmqoEjxeugzD4cGKc6l_ks9pa9Monc-0=.3e9d38a4-4276-4090-aafb-9c8795eddf95@github.com>
 <VxWxAWpL9HwDtlWUaFr9W9LeTHKEV_-iiTaoy6Nsxkk=.ba5656f0-8104-471e-917e-2613e2b92ae5@github.com>
 <T45nXqXF6hczpqRt7kiR4WGY0DQrH7FBMN4GbEeaC0k=.60025143-fa68-4899-a99a-d9b8d37bf523@github.com>
Message-ID: <TRX5427p6P8VZQMdST34p8lZyaVxosml4kc15UDhbxQ=.450a652a-9768-451b-a3fe-1e39e86c3b41@github.com>

On Tue, 27 May 2025 17:25:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti Because the method assumes that `a` represents a two's complement negative integer, so there is at least a sign bit?
>
> There's only one usage of `makePositive(int[])`, and only when `a[0] < 0`.
> And then there's the method comment that assumes a negative 2's complement number in `a`.
> 
> But if you don't feel sure, I don't mind keeping the line as it is.

It respects the method's assumptions, so for me it's ok.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25166#discussion_r2109778137

From rriggs at openjdk.org  Tue May 27 17:49:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 May 2025 17:49:56 GMT
Subject: RFR: 8357597: Proxy.getInvocationHandler throws
 NullPointerException instead of IllegalArgumentException for null [v2]
In-Reply-To: <-nN-8KZpqRsFVBfpjP2hBRwBcpBnsNEM0ndHAb5xfF8=.95ec64f4-77b3-4d59-ace7-77ed2a93570a@github.com>
References: <SAxS-e8fh7vXOoBnIxEC6X6fM5KdfM8YwCH5Bl3vdFc=.738ee4a2-f142-40c3-b967-7ffe01f8a258@github.com>
 <-nN-8KZpqRsFVBfpjP2hBRwBcpBnsNEM0ndHAb5xfF8=.95ec64f4-77b3-4d59-ace7-77ed2a93570a@github.com>
Message-ID: <5paUfWbxkEViVHZk4cOZP8N2HThvp_4C7oO8mBp2Vy4=.ca1579d1-545d-4840-a397-54d8bf771dfa@github.com>

On Mon, 26 May 2025 15:48:10 GMT, Steffen Nie?ing <duke at openjdk.org> wrote:

>> `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE.
>
> Steffen Nie?ing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357597: Update copyright year

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25419#pullrequestreview-2872003596

From dfuchs at openjdk.org  Tue May 27 17:54:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 May 2025 17:54:56 GMT
Subject: RFR: 8357561: BootstrapLoggerTest does not work on Ubuntu 24 with
 LANG de_DE.UTF-8 [v2]
In-Reply-To: <UXKCaM-CuwYwTgOkg6tg6qhvndQmYDSpf9WJk19YChE=.da37cc57-5430-48cd-9e1e-e6f4ca1d8907@github.com>
References: <O6WamnBOTS0CLGB8whhkHhosBhPoqUzMAorzWXWWOc0=.d07e26d6-4682-4fcd-a116-4a6bcc69c4c3@github.com>
 <UXKCaM-CuwYwTgOkg6tg6qhvndQmYDSpf9WJk19YChE=.da37cc57-5430-48cd-9e1e-e6f4ca1d8907@github.com>
Message-ID: <7jjAK8UABWEhLqK3dvqavpicTv3b3sTeGfvV7VbpTO0=.703a1dc0-5244-485e-8c13-2133a28427c5@github.com>

On Mon, 26 May 2025 08:16:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On a 'german'  Ubuntu 24 (LANG="de_DE.UTF-8") the jtreg test
>> java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest fails with
>> 
>> 
>> FEIN: hi now!
>> java.lang.RuntimeException: System.err does not contain: FINE: hi now!
>> at BootstrapLoggerTest.main(BootstrapLoggerTest.java:231)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>> at java.base/java.lang.Thread.run(Thread.java:1447)
>> 
>> 
>> The test (and some others in :tier1 as well) do not work with non en/US LANG, so they need an adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust LocalizedLevelName too

Tests in the CI all passed. No regression observed. Approving the changes.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25441#pullrequestreview-2872018313

From rriggs at openjdk.org  Tue May 27 18:17:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 May 2025 18:17:52 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v5]
In-Reply-To: <Mb5G0tSGTV_8Xbsr9Cf0XzbZnwFd6y7N30geVuRuwv4=.7b74f612-d088-4508-a286-7e2a3f580a08@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <Mb5G0tSGTV_8Xbsr9Cf0XzbZnwFd6y7N30geVuRuwv4=.7b74f612-d088-4508-a286-7e2a3f580a08@github.com>
Message-ID: <ygN4rh4GpbsDl65Ak-Ahb2UHK2IPyiXw5ZoAzOvXX-U=.928dc4f3-3a70-439c-b4f3-ee730320c70f@github.com>

On Sat, 24 May 2025 07:34:39 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
>> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
>> 
>> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
>> 
>> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update exception description; update argument names

Re-reviewed the PR and CSR. Thanks for the updates. Looks good.
Set the fixVersion to 25 and Finalize or at least Proposed to start the CSR review.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25297#pullrequestreview-2872084315

From duke at openjdk.org  Tue May 27 18:22:51 2025
From: duke at openjdk.org (duke)
Date: Tue, 27 May 2025 18:22:51 GMT
Subject: RFR: 8357597: Proxy.getInvocationHandler throws
 NullPointerException instead of IllegalArgumentException for null [v2]
In-Reply-To: <-nN-8KZpqRsFVBfpjP2hBRwBcpBnsNEM0ndHAb5xfF8=.95ec64f4-77b3-4d59-ace7-77ed2a93570a@github.com>
References: <SAxS-e8fh7vXOoBnIxEC6X6fM5KdfM8YwCH5Bl3vdFc=.738ee4a2-f142-40c3-b967-7ffe01f8a258@github.com>
 <-nN-8KZpqRsFVBfpjP2hBRwBcpBnsNEM0ndHAb5xfF8=.95ec64f4-77b3-4d59-ace7-77ed2a93570a@github.com>
Message-ID: <B8ouWysR--NRQ4P61wTWpg7E3s7gsjLCE_CQc2D1qcU=.b56040c5-7355-47b9-a914-76b028a3829a@github.com>

On Mon, 26 May 2025 15:48:10 GMT, Steffen Nie?ing <duke at openjdk.org> wrote:

>> `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE.
>
> Steffen Nie?ing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357597: Update copyright year

@zUniQueX 
Your change (at version 38854aa14499888111e983a0cf367a6f7ab4cd38) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25419#issuecomment-2913512052

From tvaleev at openjdk.org  Tue May 27 18:26:02 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 27 May 2025 18:26:02 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v5]
In-Reply-To: <ygN4rh4GpbsDl65Ak-Ahb2UHK2IPyiXw5ZoAzOvXX-U=.928dc4f3-3a70-439c-b4f3-ee730320c70f@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <Mb5G0tSGTV_8Xbsr9Cf0XzbZnwFd6y7N30geVuRuwv4=.7b74f612-d088-4508-a286-7e2a3f580a08@github.com>
 <ygN4rh4GpbsDl65Ak-Ahb2UHK2IPyiXw5ZoAzOvXX-U=.928dc4f3-3a70-439c-b4f3-ee730320c70f@github.com>
Message-ID: <PlsnPqw1Ay8GQsg3DUYn5Ng2W7gh1LgEbpkPoS3ZRS0=.28d5b601-7d0a-4e95-975c-77ca21fdbfbc@github.com>

On Tue, 27 May 2025 18:15:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update exception description; update argument names
>
> Re-reviewed the PR and CSR. Thanks for the updates. Looks good.
> Set the fixVersion to 25 and Finalize or at least Proposed to start the CSR review.

@RogerRiggs thank you! I always forget that CSR should be moved forward by its author...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-2913519741

From pminborg at openjdk.org  Tue May 27 19:18:58 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 19:18:58 GMT
Subject: RFR: 8357145: CRC/Inflater/Deflater/Adler32 methods that take a
 ByteBuffer throw UOE if backed by shared memory segment
In-Reply-To: <Zks5m0BcfxrtFdXPJ4xcKApNAGbShsytTBut1nc6NCM=.52d25dbd-0145-4f11-bebd-f535e15c513a@github.com>
References: <Zks5m0BcfxrtFdXPJ4xcKApNAGbShsytTBut1nc6NCM=.52d25dbd-0145-4f11-bebd-f535e15c513a@github.com>
Message-ID: <aEGS21zXLgzSci8CjojHXkbFCHKXxYbX72rlmXwu-44=.80ded400-e267-41ea-8d78-3550616ba8b9@github.com>

On Tue, 20 May 2025 07:37:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to use ` JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` in the package `java.util.zip` so that `Buffer` instances backed by `MemorySegment` instances can be used.
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

Here is a JBS issue with follow-up testing @AlanBateman .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25321#issuecomment-2913696631

From pminborg at openjdk.org  Tue May 27 19:18:59 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 May 2025 19:18:59 GMT
Subject: Integrated: 8357145: CRC/Inflater/Deflater/Adler32 methods that take a
 ByteBuffer throw UOE if backed by shared memory segment
In-Reply-To: <Zks5m0BcfxrtFdXPJ4xcKApNAGbShsytTBut1nc6NCM=.52d25dbd-0145-4f11-bebd-f535e15c513a@github.com>
References: <Zks5m0BcfxrtFdXPJ4xcKApNAGbShsytTBut1nc6NCM=.52d25dbd-0145-4f11-bebd-f535e15c513a@github.com>
Message-ID: <7CwBp5ZESf59P-kePlnHmj9iBq6klbvAVk-sQpwdIE0=.0a4640bc-4df4-4009-943a-e3598cf76e5c@github.com>

On Tue, 20 May 2025 07:37:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to use ` JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` in the package `java.util.zip` so that `Buffer` instances backed by `MemorySegment` instances can be used.
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.

This pull request has now been integrated.

Changeset: da228e06
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da228e069359bbab0e5c54f8cb2e20d67693b87c
Stats:     51 lines in 7 files changed: 23 ins; 7 del; 21 mod

8357145: CRC/Inflater/Deflater/Adler32 methods that take a ByteBuffer throw UOE if backed by shared memory segment

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25321

From duke at openjdk.org  Tue May 27 19:21:45 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 27 May 2025 19:21:45 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v15]
In-Reply-To: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
Message-ID: <bKpaZY60SBN77rtuHLpr9Lj9ZyeoyAJ3RoQjtnrWuIQ=.8c21d06d-0f6e-4c2c-91e1-3dbc6c688d6c@github.com>

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Simplifying parsing of version parameter.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25178/files
  - new: https://git.openjdk.org/jdk/pull/25178/files/3e93e53f..fb8dd750

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25178&range=13-14

  Stats: 17 lines in 1 file changed: 0 ins; 9 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/25178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25178/head:pull/25178

PR: https://git.openjdk.org/jdk/pull/25178

From swen at openjdk.org  Tue May 27 19:26:51 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 27 May 2025 19:26:51 GMT
Subject: RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes [v2]
In-Reply-To: <RtSz5dpekriWi1a1aXKjsINDyfLslrfnSXoBJ2OGtRY=.c3949ca4-2457-441d-beb9-443d1ac69873@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
 <QfFJJ4dvvF4On-SP4TG837AIKICxgaQ1t_Nr8qTmPA8=.4b039e7a-4ff2-4254-87c9-7cd048c77304@github.com>
 <RtSz5dpekriWi1a1aXKjsINDyfLslrfnSXoBJ2OGtRY=.c3949ca4-2457-441d-beb9-443d1ac69873@github.com>
Message-ID: <h7xeH1Wq3RCo5p23gdh2391XTwiYE6y3OTjp8BDIM1Y=.7d03c6c1-d092-4a54-b763-ba04f73ab63c@github.com>

On Tue, 27 May 2025 16:50:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Nice refactoring. As to C-style array rewrite, I am not so keen on that as they only appear in the generated source files, without any actual benefit.

You and @cl4es both mentioned this, and I agree, but it should be another PR to remove it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25430#issuecomment-2913749558

From swen at openjdk.org  Tue May 27 19:32:33 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 27 May 2025 19:32:33 GMT
Subject: RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes [v3]
In-Reply-To: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
Message-ID: <6Fsxo4CXaVfTdKQ_DsbdIn3uQ0170SX98zdjbs5HL7o=.e296b38e-3390-40d2-937c-595ca509e884@github.com>

> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, these are immutable, We should add `@Stable` and final to provide information to the optimizer.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix comments, from @natoj

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25430/files
  - new: https://git.openjdk.org/jdk/pull/25430/files/d9f0e5e7..46b79333

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25430&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25430&range=01-02

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25430/head:pull/25430

PR: https://git.openjdk.org/jdk/pull/25430

From vyazici at openjdk.org  Tue May 27 19:33:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 27 May 2025 19:33:55 GMT
Subject: RFR: 8357681: Fixed the DigitList::toString method causing
 incorrect results during debugging
In-Reply-To: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
Message-ID: <GvXiOCW-GHsVGQp2cgvlXhKC6fbIfbVd9rsWsvINvPg=.36d618a3-5734-485c-afe7-496397fb2de3@github.com>

On Sun, 18 May 2025 11:11:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.

_Nit:_ Would it be an overkill to add a test (verifying `toString` doesn't spoil the content) to avoid falling on the same slippery slope (i.e., _"Let me optimize this by reusing the `SB`!"_) again?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25288#issuecomment-2913768494

From swen at openjdk.org  Tue May 27 19:38:51 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 27 May 2025 19:38:51 GMT
Subject: RFR: 8357681: Fixed the DigitList::toString method causing
 incorrect results during debugging
In-Reply-To: <JLz-9Ki-8Rlw33Dj9qQ4OY43ezpxt-EvxGg01nFhkMA=.7137277f-3316-485a-9602-d22eb6a45d2b@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
 <JLz-9Ki-8Rlw33Dj9qQ4OY43ezpxt-EvxGg01nFhkMA=.7137277f-3316-485a-9602-d22eb6a45d2b@github.com>
Message-ID: <5SvVx2xvFNZoxu4t0vVrwH2E09vwFe5ZZteeEh7cvlw=.84c38873-8623-4a99-93ba-c0dd4c24419a@github.com>

On Tue, 27 May 2025 17:11:41 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.
>
> src/java.base/share/classes/java/text/DigitList.java line 787:
> 
>> 785:         }
>> 786: 
>> 787:         return "0." + new String(digits, 0, count) + "x10^" + decimalAt;
> 
> what about
> 
>         return new StringBuilder()
>                 .append("0.")
>                 .append(digits, 0, count)
>                 .append("x10^")
>                 .append(decimalAt)
>                 .toString();
> 
> to avoid the temporary string created by `new String(digits, 0, count)`

Using the String concatenation operator looks cleaner.

In the core library, they are effectively the same, and JEP 280 Indify String Concatenation is not available in the core library.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25288#discussion_r2110047144

From swen at openjdk.org  Tue May 27 19:47:54 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 27 May 2025 19:47:54 GMT
Subject: RFR: 8357681: Fixed the DigitList::toString method causing
 incorrect results during debugging
In-Reply-To: <GvXiOCW-GHsVGQp2cgvlXhKC6fbIfbVd9rsWsvINvPg=.36d618a3-5734-485c-afe7-496397fb2de3@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
 <GvXiOCW-GHsVGQp2cgvlXhKC6fbIfbVd9rsWsvINvPg=.36d618a3-5734-485c-afe7-496397fb2de3@github.com>
Message-ID: <VpMiH0nUcC3wi8YJqV1sXxEVNyu4gZj6RkYYAHIYK7g=.8cd8089c-99ec-4a30-bee0-77adbbe1079b@github.com>

On Tue, 27 May 2025 19:31:44 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> _Nit:_ Would it be an overkill to add a test (verifying `toString` doesn't spoil the content) to avoid falling on the same slippery slope (i.e., _"Let me optimize this by reusing the `SB`!"_) again?

The original code that calls getStringBuilder() is this code:

    private StringBuilder tempBuilder;

    private StringBuilder getStringBuilder() {
        if (tempBuilder == null) {
            tempBuilder = new StringBuilder(MAX_COUNT);
        } else {
            tempBuilder.setLength(0);
        }
        return tempBuilder;
    }


This is a concurrency problem, which is triggered during the DEBUG process.

To test this concurrency problem, we need to build a concurrent competition test, which is not a simple task, so I did not add it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25288#issuecomment-2913802759

From duke at openjdk.org  Tue May 27 19:48:12 2025
From: duke at openjdk.org (Stefan Lobbenmeier)
Date: Tue, 27 May 2025 19:48:12 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v3]
In-Reply-To: <DQXva1P2kebCOQgybJccOGLgbyAwhCHDwo5o_Sec0BE=.bfd5ba3d-877b-47c0-83f7-02dbbcc82547@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <zkBr9MToIDhhJ-Y7pgPbNqumbE1YtA9dlHmnJUApP5k=.287f87b7-44f0-46de-a314-c44702f16a2f@github.com>
 <DQXva1P2kebCOQgybJccOGLgbyAwhCHDwo5o_Sec0BE=.bfd5ba3d-877b-47c0-83f7-02dbbcc82547@github.com>
Message-ID: <wOPZVUXiO5JK9JCqkU_0jJuN3gL7keWlfWmLd5NnOUc=.1dd2788a-b463-40fa-ab9a-707796bddce0@github.com>

On Wed, 21 May 2025 20:51:48 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   also use <package-dep-string> in other locations
>
> src/jdk.jpackage/share/man/jpackage.md line 426:
> 
>> 424: :   Menu group this application is placed in
>> 425: 
>> 426: <a id="option-linux-package-deps">`--linux-package-deps *package-dep-string*`</a>
> 
> Should it be "`--linux-package-deps *package-dep-string*`" -> "`--linux-package-deps` *package-dep-string*" similar to other options like `--linux-menu-group`. "``" around option only.

good catch, moved the backtick in 51ed08e

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23638#discussion_r2110062489

From duke at openjdk.org  Tue May 27 19:48:11 2025
From: duke at openjdk.org (Stefan Lobbenmeier)
Date: Tue, 27 May 2025 19:48:11 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v4]
In-Reply-To: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
Message-ID: <wWi_NL_McwvSGuBvHJVI5ie3U9lAV4rmoruJf91JDsg=.143f84ac-f8b8-44e9-8377-d94a69a993c7@github.com>

> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space
> 
> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372

Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:

  Correct backtick position

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23638/files
  - new: https://git.openjdk.org/jdk/pull/23638/files/91831e7e..51ed08e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23638&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23638&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23638/head:pull/23638

PR: https://git.openjdk.org/jdk/pull/23638

From swen at openjdk.org  Tue May 27 19:52:01 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 27 May 2025 19:52:01 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal
Message-ID: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>

Some static final arrays of BigInteger and BigDecimal are stable and immutable. We should add `@Stable` to give the optimizer more information

-------------

Commit messages:
 - BigInteger::mag add `@Stable`
 - add stable

Changes: https://git.openjdk.org/jdk/pull/25437/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25437&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357913
  Stats: 12 lines in 2 files changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25437.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25437/head:pull/25437

PR: https://git.openjdk.org/jdk/pull/25437

From duke at openjdk.org  Tue May 27 19:52:01 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 27 May 2025 19:52:01 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal
In-Reply-To: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
Message-ID: <Ikqt8HS9s3_5ZpeSIWjTy89q5wAbPiaffJR8dQfvd24=.2d0351be-f083-4b13-b156-e6c27f8a8166@github.com>

On Sun, 25 May 2025 22:35:56 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Some static final arrays of BigInteger and BigDecimal are stable and immutable. We should add `@Stable` to give the optimizer more information

Note?that `BigInteger.mag` should?probably also?be?made `@Stable` once?`BigInteger?.largePrime(?)` is?changed to?not?write to?`p.mag[?]`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25437#issuecomment-2909052698

From sparasa at openjdk.org  Tue May 27 19:59:54 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 27 May 2025 19:59:54 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v3]
In-Reply-To: <H3vvJxVRsOzXpLIAnz2vc3wU_Umd9IoyI1cgqYT6mq0=.79b289da-60f2-4f62-99bd-227e03e9df2b@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <H3vvJxVRsOzXpLIAnz2vc3wU_Umd9IoyI1cgqYT6mq0=.79b289da-60f2-4f62-99bd-227e03e9df2b@github.com>
Message-ID: <Y2Ne_JUjmtV3LHSRxRigX9mkY_fsQBU5OQJn6eS5CXw=.bb72ec4c-40af-4aa0-ab43-29e05a3b37b2@github.com>

On Tue, 6 May 2025 21:45:34 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs.
>> 
>> | Input range(s)                                  | Throughput with baseline (op/s) | Throughput with intrinsic (op/s) | Speedup |
>> | :-------------------------------------: | :----------------------------------: | :----------------------------------: | :---------: |
>> | [-2^(-1022), 2^(-1022)]                   | 6568                                             | 17678                                          | 2.69x       |
>> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932                                         | 200897                                        | 1.45x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add new set of cbrt micro-benchmarks

This PR looks good to me. I independently ran the correctness tests and performance benchmarks. 

Thanks,
Vamsi

-------------

Marked as reviewed by sparasa (Author).

PR Review: https://git.openjdk.org/jdk/pull/24470#pullrequestreview-2872425795

From rriggs at openjdk.org  Tue May 27 20:01:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 May 2025 20:01:52 GMT
Subject: RFR: 8334742: Change java.time month/day field types to 'byte'
 [v2]
In-Reply-To: <AUY5jIW8j9Su5dADRCUul9pql3xc1DtiNdrDPtCywC4=.7c91f6fd-db4b-4d87-8d89-3a022549330a@github.com>
References: <AZ0_rhZGLcX4I7NuxtGcP1pVzGAr7KXu8FObV6kMxZ8=.2b7d3dc8-1cf8-40d9-bef2-8164282e02e8@github.com>
 <AUY5jIW8j9Su5dADRCUul9pql3xc1DtiNdrDPtCywC4=.7c91f6fd-db4b-4d87-8d89-3a022549330a@github.com>
Message-ID: <63G95td2niDaQ-BWdk-DIJ6T6NJVapvrbmUD_Lp6Yys=.f966f91f-0d00-46d4-b48f-b67de8cd6090@github.com>

On Wed, 30 Apr 2025 20:38:59 GMT, Gautham Krishnan <duke at openjdk.org> wrote:

>> In the following classes, month and day values are stored in fields of type 'int' or 'short'. The range of allowed values is small enough that the type can be 'byte' instead.
>> 
>> java.time.YearMonth
>> java.time.MonthDay
>> java.time.LocalDate
>> java.time.chono.HijrahDate
>> 
>> Refactoring the type will give the JVM a little more layout flexibility, and will be especially useful when these classes become value classes.
>
> Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright header

Looks good

Passed CI tier 1-3.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24975#pullrequestreview-2872433491
PR Comment: https://git.openjdk.org/jdk/pull/24975#issuecomment-2913852479

From rriggs at openjdk.org  Tue May 27 20:10:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 May 2025 20:10:51 GMT
Subject: RFR: 8357681: Fixed the DigitList::toString method causing
 incorrect results during debugging
In-Reply-To: <VpMiH0nUcC3wi8YJqV1sXxEVNyu4gZj6RkYYAHIYK7g=.8cd8089c-99ec-4a30-bee0-77adbbe1079b@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
 <GvXiOCW-GHsVGQp2cgvlXhKC6fbIfbVd9rsWsvINvPg=.36d618a3-5734-485c-afe7-496397fb2de3@github.com>
 <VpMiH0nUcC3wi8YJqV1sXxEVNyu4gZj6RkYYAHIYK7g=.8cd8089c-99ec-4a30-bee0-77adbbe1079b@github.com>
Message-ID: <tn8O7WQtmagXZcCSCyGpzPboPQU4kQknSikSY7pE9tk=.569a4270-4757-42fc-8836-b94c1346ff87@github.com>

On Tue, 27 May 2025 19:44:55 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> To test this concurrency problem, we need to build a concurrent competition test, which is not a simple task, so I did not add it.

The label `noreg-hard` would be appropriate to indicate a test was not created due to difficulty.
That label though conflicts with the current label `noreg-trivial` implying there is an existing test and the change is not significant. It will look odd, but both labels make sense.
[OpenJDK Developers guide](https://openjdk.org/guide/#jbs-label-dictionary)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25288#issuecomment-2913885924

From asemenyuk at openjdk.org  Tue May 27 20:13:56 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 27 May 2025 20:13:56 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v4]
In-Reply-To: <wWi_NL_McwvSGuBvHJVI5ie3U9lAV4rmoruJf91JDsg=.143f84ac-f8b8-44e9-8377-d94a69a993c7@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <wWi_NL_McwvSGuBvHJVI5ie3U9lAV4rmoruJf91JDsg=.143f84ac-f8b8-44e9-8377-d94a69a993c7@github.com>
Message-ID: <eaXDmkrjc_e9YqtLjANQFDZf9qKxpC1yEwMAm_Oizws=.4859ecf7-422d-4a5d-a0a6-92a569977c61@github.com>

On Tue, 27 May 2025 19:48:11 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

>> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space
>> 
>> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372
>
> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct backtick position

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23638#pullrequestreview-2872461234

From almatvee at openjdk.org  Tue May 27 20:40:53 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 27 May 2025 20:40:53 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v4]
In-Reply-To: <wWi_NL_McwvSGuBvHJVI5ie3U9lAV4rmoruJf91JDsg=.143f84ac-f8b8-44e9-8377-d94a69a993c7@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <wWi_NL_McwvSGuBvHJVI5ie3U9lAV4rmoruJf91JDsg=.143f84ac-f8b8-44e9-8377-d94a69a993c7@github.com>
Message-ID: <2d9Qt0x8Qjl01eEOqsWyaimHF7NKDZls15FdT5ObPdk=.f6f36a8a-7732-47c2-b9d1-fa403642ef2d@github.com>

On Tue, 27 May 2025 19:48:11 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

>> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space
>> 
>> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372
>
> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct backtick position

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23638#pullrequestreview-2872563253

From duke at openjdk.org  Tue May 27 21:33:10 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 27 May 2025 21:33:10 GMT
Subject: RFR: 8356891: Some code simplifications in BigInteger [v24]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <1YpSteT00WSEH2VX4jKOvncSv8DGYTMIYsKzAsH5lhM=.2e72fd25-95e1-43a8-9ce6-4e730fe7550c@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Restored trustedStripLeadingZeroInts(int[])

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/60d3c1f9..44fbb81c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=22-23

  Stats: 17 lines in 1 file changed: 8 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From duke at openjdk.org  Tue May 27 21:42:37 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 27 May 2025 21:42:37 GMT
Subject: RFR: 8356891: Some code simplifications in BigInteger [v25]
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <RV4MfmfKevR6ReO5Y7-fYNKIm50RuLelHLRwVaR0w_E=.594ecb57-d7c9-47a5-bd5c-5fea947344ca@github.com>

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Restore calls to trustedStripLeadingZeroInts(int[])

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25166/files
  - new: https://git.openjdk.org/jdk/pull/25166/files/44fbb81c..d74354dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25166&range=23-24

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25166.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25166/head:pull/25166

PR: https://git.openjdk.org/jdk/pull/25166

From rriggs at openjdk.org  Tue May 27 22:03:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 May 2025 22:03:52 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v3]
In-Reply-To: <D2OwQlifY_F57s5ntpnVSYAMxZ8lacAyv03fME6O3ZM=.524387cc-ad76-4261-9269-8e2f08aeb6fb@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <Jm4ATGoFWP2a8HSBuwAglmdQS5fcBKBxt7TOklUQRjk=.b47ef4c7-26cd-4603-a074-76be89fa898c@github.com>
 <D2OwQlifY_F57s5ntpnVSYAMxZ8lacAyv03fME6O3ZM=.524387cc-ad76-4261-9269-8e2f08aeb6fb@github.com>
Message-ID: <my9K8CLlrz0magIzlGgxShOw4oG1D7khLcG0KB2C3aU=.50c780c7-2f35-425b-aa19-00905143e208@github.com>

On Tue, 20 May 2025 12:00:06 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/UUID.java line 195:
>> 
>>> 193:      *
>>> 194:      * @return A {@code UUID} generated from the current system time
>>> 195:      */
>> 
>> Seems like there should be a reference to the RFC somewhere here using the @spec javadoc tag.
>> 
>> And also in the class javadoc.
>
> spec updated in class javadoc to RFC 9562 which obsolete RFC 4122, @spec tag also added above the method.

I'd say "create" instead of "retrieve" in the first line comment. (Though that word is used in the other static factories).

The "sub-millisecond precision" can't be relied upon. Its the precision that gives the impression that it can be added to the millisecond value and get an exact time. But the nano-second value is read from a different clock and the bits being used from it may wrap-around in the time between the reads of the clocks.
The second description ("derived from") is makes fewer promises than the first-line comment.
An application should not use them for any purpose other than random.  And for that the buffer already contains random bytes.

An alternative is to capture the MS time and the nano-time on first use to compute an offset and then use only the nano-time plus/minus the offset to create the version 7 UUIDs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2110340184

From rriggs at openjdk.org  Tue May 27 22:03:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 May 2025 22:03:53 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v3]
In-Reply-To: <my9K8CLlrz0magIzlGgxShOw4oG1D7khLcG0KB2C3aU=.50c780c7-2f35-425b-aa19-00905143e208@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <Jm4ATGoFWP2a8HSBuwAglmdQS5fcBKBxt7TOklUQRjk=.b47ef4c7-26cd-4603-a074-76be89fa898c@github.com>
 <D2OwQlifY_F57s5ntpnVSYAMxZ8lacAyv03fME6O3ZM=.524387cc-ad76-4261-9269-8e2f08aeb6fb@github.com>
 <my9K8CLlrz0magIzlGgxShOw4oG1D7khLcG0KB2C3aU=.50c780c7-2f35-425b-aa19-00905143e208@github.com>
Message-ID: <lzUXzFFqnkDwu6nx8GudrrkgihJ9bYECt0gqbWSPOgg=.7f6488d7-5c7e-423a-879a-3f125245440c@github.com>

On Tue, 27 May 2025 21:44:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> spec updated in class javadoc to RFC 9562 which obsolete RFC 4122, @spec tag also added above the method.
>
> I'd say "create" instead of "retrieve" in the first line comment. (Though that word is used in the other static factories).
> 
> The "sub-millisecond precision" can't be relied upon. Its the precision that gives the impression that it can be added to the millisecond value and get an exact time. But the nano-second value is read from a different clock and the bits being used from it may wrap-around in the time between the reads of the clocks.
> The second description ("derived from") is makes fewer promises than the first-line comment.
> An application should not use them for any purpose other than random.  And for that the buffer already contains random bytes.
> 
> An alternative is to capture the MS time and the nano-time on first use to compute an offset and then use only the nano-time plus/minus the offset to create the version 7 UUIDs.

The `timestamp` method may mislead an app developer thinking its the time from the version 7 timestamp.
The first-line comment might make it more obvious if it says:
`The timestamp value associated with a version 1 UUID.`

The Unix Epoch time would be easier to use if a method was added to return it.
`long UnixEpochTimeNanos()`   (name subject to bike-shedding).
And throwing if it was not version 7.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2110368888

From yujige at gmail.com  Tue May 27 22:35:29 2025
From: yujige at gmail.com (Jige Yu)
Date: Tue, 27 May 2025 15:35:29 -0700
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <CAKD1RYuPzVW+VHt_MzOrXW93iNv0A03JFSCV+yawCFeaLm=HsA@mail.gmail.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774265B8728DA0641C48DBAFF152@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYut_G7TRSTr0hPVuxWAvJQ+25JyPBWB7PEtntamWq-E_A@mail.gmail.com>
 <MW4PR10MB5774AB9B6544E949383187F3FFEC2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvyRxcWv65v4+8KcRHys=jkbpfKZ3eK3ijTGKXR1UxNnA@mail.gmail.com>
 <MW4PR10MB5774986199F9EDF854A6D390FFEE2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtE-xwb9tBhjPvObeG9_03nXh1aRA10sO7ibEGkQavntw@mail.gmail.com>
 <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtAUfyUHOdmSeZ2Azny=RJU63FQozY2NxpYu-4xQYCRkA@mail.gmail.com>
 <MW4PR10MB5774B089653C902899FEBEAFFFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB5774BB2B60EE5A1F4B1A7306FFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvxZ0gpHJXW0ctuHwEGwfStfjmLvwV1CgSWrr8438rWPA@mail.gmail.com>
 <MW4PR10MB5774EF4D4316B5BE46B29A0EFFF12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYsJyHeEs1fc4DRTZKwDO_U4Pyjv45BQ5fvr6VbboaVCTQ@mail.gmail.com>
 <MW4PR10MB57743363CCA3306B316F3EEDFF65A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYuPzVW+VHt_MzOrXW93iNv0A03JFSCV+yawCFeaLm=HsA@mail.gmail.com>
Message-ID: <CAKD1RYtpahV4766wNodvcrSGFqJ6ereG1fUJFi-yEviOpLcb=Q@mail.gmail.com>

That said, I'm still curious. Have you considered propagating cancellation,
re-interrupting the current thread, and then throwing an unchecked
exception upon interruption? It's going to be the most fail-fast-compatible.

catch (IE interrupted) {
  cancel all pending futures
  Thread.currentThread().interrupt();
  throw new UncheckedInterruptedException();
}

What are the concerns against such practice?





On Mon, May 26, 2025 at 8:31?AM Jige Yu <yujige at gmail.com> wrote:

> Yeah, I think I missed the task cancellation and the joining part.
>
> When the mapConcurrent() thread is interrupted, it propagates the
> cancellation to the child threads.
>
> And if any of the children threads (running the user-provided Function)
> receives that cancellation, it will still need to catch it and handle
> interruption.
>
> That means the interruption isn't swallowed. If the user code wants to
> abort, they can always just throw an unchecked exception and catch it from
> the caller of mapConcurrent().
>
> That should do for most of the IO type work.
>
> This makes sense.
>
>
>
> On Mon, May 26, 2025 at 12:30?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
>> Yes, the updated Gatherers.mapConcurrent will continue under interruption
>> until done, and then restore the interrupt status of the calling thread.
>>
>> It cannot (reasonably) do anything else?if it were to throw
>> InterruptedException, it couldn't since that is a checked exception and
>> there's no tracking of checked exceptions throughout a Stream, and that is
>> the specified behavior to handle thread interrupts (i.e. clear flag and
>> throw InterruptedException, which is not possible in this case; or, make
>> sure that interrupt status is maintained, which is possible in this case.
>>
>> I have given it some more thought in the meantime, but I haven't arrived
>> in something more satisfactory than that, yet.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* Jige Yu <yujige at gmail.com>
>> *Sent:* Monday, 26 May 2025 03:07
>> *To:* Viktor Klang <viktor.klang at oracle.com>
>> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>>
>> Thanks Viktor!
>>
>> Sorry, I was giving myself more time to read the code, but then I lost
>> track.
>>
>> If I'm reading the code right, the current behavior is that if the
>> current thread is interrupted, the mapConcurrent() would suppress the
>> interruption until all elements are processed? (It will then restore the
>> interruption bit)
>>
>> Doesn't this break fail fast?
>>
>> For example, I may have a mapConcurrent() called from within structured
>> concurrency, and that fans out to two operations:
>> ?
>> scope.fork(() -> doA());
>> scope.fork(() -> doB());  // calls mapConcurrent() internally
>> scope.join().throwIfFailed();
>>
>> If doA() fails, doB() will be cancelled (thread interrupted).
>>
>> If mapConcurrent() ignores the interruption, and if doB has a long list
>> to process, it'll continue to consume system resources even when the caller
>> no longer needs the results, no?
>>
>>
>> On Fri, Feb 7, 2025 at 2:16?AM Viktor Klang <viktor.klang at oracle.com>
>> wrote:
>>
>> >Sorry, did the PR stop using Semaphore?
>>
>> No, not that PR. See:
>> https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e__;!!ACWV5N9M2RV99hQ!OKfWrvJEDCkiHcT5b4a6gfeomZzZeq3jv6ir2vf2I5WWIhujtb-by_VuQFaAPDIuAA0qAwpTUjllXMPF$>
>>
>> The problem with interruption under parallel evaluation is that there is
>> no general support for propagation of interruption in CountedCompleters.
>> Adding support for such in (at least) GathererOp needs further study before
>> contemplating making any changes to mapConcurrent()'s interruption policy.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>>
>> ------------------------------
>> *From:* Jige Yu <yujige at gmail.com>
>> *Sent:* Thursday, 6 February 2025 17:04
>> *To:* Viktor Klang <viktor.klang at oracle.com>
>> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>>
>> Sorry, did the PR stop using Semaphore?
>>
>> I had naively thought that mapConcurrent() will keep a buffer of Future
>> of all currently-running concurrent tasks (it can be a
>> ConcurrentMap<TaskKey, Future> if we don't have to ensure FIFO).
>>
>> Upon interruption, the main thread can call .cancel(true) on all pending
>> Futures; optionally join with the VTs (if we need to block until all VTs
>> exit); then propagate exception.
>>
>> Upon completion, each task just removes itself from the ConcurrentMap.
>>
>> Just in case it adds anything.
>>
>>
>>
>> On Thu, Feb 6, 2025 at 6:47?AM Viktor Klang <viktor.klang at oracle.com>
>> wrote:
>>
>> After some more investigation it seems tractable to propagate
>> interruption of the caller in sequential mode, but parallel mode will
>> require much bigger considerations.
>>
>> I made a comment to that effect on the JBS issue:
>> https://bugs.openjdk.org/browse/JDK-8349462?focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017
>>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* Viktor Klang <viktor.klang at oracle.com>
>> *Sent:* Thursday, 6 February 2025 11:51
>> *To:* Jige Yu <yujige at gmail.com>
>> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>>
>> I think alignment in behavior between parallel Stream and mapConcurrent
>> in terms of how interruptions are handled is a possible path forward.
>>
>> I decided to close the PR for now as I realized my parallel Stream
>> example had misled me regarding its exception throwing, so I'll need to go
>> back and refine the solution.
>>
>> It still seems solvable though.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* Jige Yu <yujige at gmail.com>
>> *Sent:* Wednesday, 5 February 2025 19:20
>> *To:* Viktor Klang <viktor.klang at oracle.com>
>> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>>
>> Oh good call!
>>
>> I forgot to check what parallel streams do upon interruption (didn't
>> think they do any blocking calls, but at least the main thread must block).
>>
>> On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang <viktor.klang at oracle.com>
>> wrote:
>>
>> Hi Jige,
>>
>> I opened an issue to track the concern, and I have proposed a change
>> which seems to align well with how parallel streams behave under caller
>> thread interruption.
>>
>> I've opened the following PR for review:
>> https://github.com/openjdk/jdk/pull/23467
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
>>
>> If you are able to make a local OpenJDK build with that solution you
>> could check if it addresses your use-cases (or not).
>>
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
>> 8349462: Gatherers.mapConcurrent could support async interrupts by
>> viktorklang-ora ? Pull Request #23467 ? openjdk/jdk
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
>> This change is likely going to need some extra verbiage in the spec for
>> mapConcurrent, and thus a CSR. This behavior aligns mapConcurrent with how
>> parallel streams work in conjunction with interrup...
>> github.com
>> <https://urldefense.com/v3/__http://github.com__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89DBkMefT$>
>>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* Jige Yu <yujige at gmail.com>
>> *Sent:* Wednesday, 5 February 2025 16:24
>> *To:* Viktor Klang <viktor.klang at oracle.com>
>> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>>
>> Thanks Viktor!
>>
>> I understand the problem.
>>
>> The main reason I asked is because I want to understand how the core Java
>> team thinks of throwing an unchecked exception.
>>
>> As explained above, I consider losing cancellability a big deal, a deal
>> breaker even. And I thought throwing unchecked is more acceptable. Because
>> the most common reason the mapConcurrent() VT can be interrupted is due to
>> cancellation from a parent mapConcurrent(), or a parent Structured
>> Concurrency scope. The cancellation could be either from an organic
>> exception, or from the downstream not needing more elements, like maybe due
>> to findFirst() already getting an element.
>>
>> In both cases, since the concurrent operation is already cancelled
>> (result ignored), what exception pops up to the top level isn't that big of
>> a deal (perhaps only a log record will be seen?)
>>
>> But if the core Java team considers it a bad idea, I would love to learn
>> and adjust.
>>
>> On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang <viktor.klang at oracle.com>
>> wrote:
>>
>> Hi,
>>
>> The problem is that mapConcurrent cannot throw InterruptedException
>> because that is a checked exception, so we cannot clear the interrupted
>> flag and throw that exception.
>>
>> So the updated semantics is to not cut the stream short but instead run
>> to completion, restoring the interruption flag.
>>
>> There exists a couple of alternatives to this approach which I am
>> contemplating, but they need to be further explored before I consider
>> moving forward with any of them.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* Jige Yu <yujige at gmail.com>
>> *Sent:* Monday, 27 January 2025 17:00
>> *To:* Viktor Klang <viktor.klang at oracle.com>
>> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>>
>> Thanks Viktor!
>>
>> It looks like the current fix ignores interruption.
>>
>> I want to make sure my concern of it defeating cancellation is heard and
>> understood.
>>
>> The scenarios I worry about is for a mapConcurrent() that fans out to
>> another method call, which internally calls mapConcurrent() as
>> implementation detail.
>>
>> An example:
>>
>> List<RefundResponse> refundHelper(transaction) {
>>   transaction.creditCardAccounts.stream()
>>     .gather(mapConcurrent(acct -> service.refund(acct))
>>     .toList();
>> }
>>
>> transactions.stream()
>>     .gather(mapConcurrent(transaction -> refundHelper(transaction));
>>
>>
>> It seems undesirable that in such a case all the service.refund() calls
>> become non cancellable, because the only way the outer mapConcurrent()
>> cancels the refundHelper() calls is through Thread.interrupt() the virtual
>> threads that call refundHelper(), which would then be disabled by the inner
>> mapConcurrent().
>>
>> Does this example make sense to you? I can further explain if anything
>> isn't clear.
>>
>> But I want to make sure the decision to disable interruption is
>> deliberate judgement call that such nested mapConcurrent() is unlikely,or
>> not important.
>>
>> Cheers,
>>
>>
>>
>> On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang <viktor.klang at oracle.com>
>> wrote:
>>
>> Hi!
>>
>> Please see: https://github.com/openjdk/jdk/pull/23100
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23100__;!!ACWV5N9M2RV99hQ!IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* Jige Yu <yujige at gmail.com>
>> *Sent:* Sunday, 26 January 2025 23:03
>> *To:* Viktor Klang <viktor.klang at oracle.com>
>> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>> *Subject:* [External] : Re: mapConcurrent() with InterruptedException
>>
>> Checking in on what you've found out, Viktor.
>>
>> From where we left off, I understand that you were looking at
>> alternatives instead of silent truncation?
>>
>> Have you reached any conclusion?
>>
>> We touched on disallowing interruption during mapConcurrent(). I still
>> have concerns with disabling cancellation, because it basically undoes this
>> API note from the javadoc
>> <https://cr.openjdk.org/~alanb/sc-20240503/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)>
>> :
>>
>> API Note: In progress tasks will be attempted to be cancelled, on a
>> best-effort basis, in situations where the downstream no longer wants to
>> receive any more elements.
>> In reality, people will use mapConcurrent() to fan out rpcs. Sometimes
>> these rpcs are just a single blocking call; yet sometimes they may
>> themselves be a Structured Concurrency scope, with 2 or 3 rpcs that
>> constitute a single logical operation. Under two conditions, cancellation
>> is imho important semantic:
>>
>>    1. The downstream code uses filter().findFirst(), and when it sees an
>>    element, it will return and no longer needs the other pending rpcs to
>>    complete. If cancellation is disabled, these unnecessary rpcs will waste
>>    system resources.
>>    2. One of the rpc throws and the Stream pipeline needs to propagate
>>    the exception. Again, if the other rpcs cannot be cancelled, we'll have
>>    many zombie rpcs.
>>
>> Zombie rpcs may or may not be a deal breaker, depending on the specific
>> use case. But for a JDK library, losing cancellation would have a negative
>> impact on usability.
>>
>> My 2c,
>>
>>
>> On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang <viktor.klang at oracle.com>
>> wrote:
>>
>> Hi Ben,
>>
>> Thanks for raising these questions?getting feedback is crucial in the
>> Preview stage of features.
>>
>> I wrote a reply to the Reddit thread so I'll just summarize here:
>>
>> It is important to note that *mapConcurrent()* is not a part of the
>> Structured Concurrency JEPs, so it is not designed to join SC scopes.
>>
>> I'm currently experimenting with ignoring-but-restoring interrupts on the
>> "calling thread" for *mapConcurrent()*, as well as capping
>> work-in-progress to *maxConcurrency* (not only capping the concurrency
>> but also the amount of completed-but-yet-to-be-pushed work). Both of these
>> adjustments should increase predictability of behavior in the face of
>> blocking operations with variable delays.
>>
>> Another adjustment I'm looking at right now is to harden/improve the
>> cleanup to wait for concurrent tasks to acknowledge cancellation, so that
>> once the finisher is done executing the VTs are known to have terminated.
>>
>> As for not preserving the encounter order, that would be a completely
>> different thing, and I'd encourage you to experiment with that if that
>> functionality would be interesting for your use-case(s).
>>
>> Again, thanks for your feedback!
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Jige
>> Yu <yujige at gmail.com>
>> *Sent:* Friday, 3 January 2025 17:53
>> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>> *Subject:* mapConcurrent() with InterruptedException
>>
>> Hi Java Experts,
>>
>> I sent this email incorrectly to loom-dev@ and was told on Reddit that
>> core-libs-dev is the right list.
>>
>> The question is about the behavior of mapConcurrent() when the thread is
>> interrupted.
>>
>> Currently mapConcurrent()'s finisher phase will re-interrupt the thread,
>> then stop at whatever element that has already been processed and return.
>>
>> This strikes me as a surprising behavior, because for example if I'm
>> running:
>>
>>    Stream.of(1, 2, 3)
>>         .gather(mapConcurrent(i -> i * 2))
>>         .toList()
>>
>> and the thread is being interrupted, the result could be any of [2], [2,
>> 4] or [2, 4, 6].
>>
>> Since thread interruption is cooperative, there is no guarantee that the
>> thread being interrupted will just abort. It's quite possible that it'll
>> keep going and then will use for example [2] as the result of doubling the
>> list of [1, 2, 3], which is imho incorrect.
>>
>> In the Reddit
>> <https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread,
>> someone argued that interruption rarely happens so it's more of a
>> theoretical issue. But interruption can easily happen in Structured
>> Concurrency or in mapConcurrent() itself if any subtask has failed in order
>> to cancel/interrupt the other ongoing tasks.
>>
>> There had been discussion about alternative strategies:
>>
>>    1. Don't respond to interruption and just keep running to completion.
>>    2. Re-interrupt thread and wrap the InterruptedException in a
>>    standard unchecked exception (StructuredConcurrencyInterruptedException?).
>>
>>
>> I have concerns with option 1 because it disables cancellation
>> propagation when mapConcurrent() itself is used in a subtask of a parent
>> mapConcurrent() or in a StructuredConcurrencyScope.
>>
>> Both equivalent Future-composition async code, or C++'s fiber trees
>> support cancellation propagation and imho it's a critical feature or else
>> it's possible that a zombie thread is still sending RPCs long after the
>> main thread has exited (failed, or falled back to some default action).
>>
>> My arguments for option 2:
>>
>>    1. InterruptedException is more error prone than traditional checked
>>    exceptions for *users* to catch and handle. They can forget to
>>    re-interrupt the thread. It's so confusing that even seasoned programmers
>>    may not know they are *supposed to* re-interrupt the thread.
>>    2. With Stream API using functional interfaces like Supplier,
>>    Function, the option of just tacking on "throws IE" isn't available to many
>>    users.
>>    3. With Virtual Threads, it will be more acceptable, or even become
>>    common to do blocking calls from a stream operation (including but
>>    exclusive to mapConcurrent()). So the chance users are forced to deal with
>>    IE will become substantially higher.
>>    4. Other APIs such as the Structured Concurrency API have already
>>    started wrapping system checked exceptions like ExecutionException,
>>    TimeoutException in unchecked exceptions ( join()
>>    <https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for
>>    example).
>>    5. Imho, exceptions that we'd rather users not catch and handle but
>>    instead should mostly just propagate up as is, should be unchecked.
>>
>> There is also a side discussion
>> <https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/comment/m4z4f8c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about
>> whether mapConcurrent() is better off preserving input order or push to
>> downstream as soon as an element is computed. I'd love to discuss that
>> topic too but maybe it's better to start a separate thread?
>>
>> Thank you and cheers!
>>
>> Ben Yu
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250527/b4ce351f/attachment-0001.htm>

From sviswanathan at openjdk.org  Tue May 27 23:43:53 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 27 May 2025 23:43:53 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v3]
In-Reply-To: <H3vvJxVRsOzXpLIAnz2vc3wU_Umd9IoyI1cgqYT6mq0=.79b289da-60f2-4f62-99bd-227e03e9df2b@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <H3vvJxVRsOzXpLIAnz2vc3wU_Umd9IoyI1cgqYT6mq0=.79b289da-60f2-4f62-99bd-227e03e9df2b@github.com>
Message-ID: <62SQLH6KGe8_w0LxmPSPW7C34v9-KFYliTk0RzMgJTs=.80886efd-7f4f-408c-8bbd-07af12ab9701@github.com>

On Tue, 6 May 2025 21:45:34 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The command to run all range specific micro-benchmarks is posted below.
>> 
>> `make test TEST="micro:CbrtPerf.CbrtPerfRanges"`
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs.
>> 
>> | Input range(s)                                  | Throughput with baseline (op/s) | Throughput with intrinsic (op/s) | Speedup |
>> | :-------------------------------------: | :----------------------------------: | :----------------------------------: | :---------: |
>> | [-2^(-1022), 2^(-1022)]                   | 6568                                             | 17678                                          | 2.69x       |
>> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932                                         | 200897                                        | 1.45x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add new set of cbrt micro-benchmarks

src/hotspot/cpu/x86/macroAssembler_x86.hpp line 1251:

> 1249:   void movapd(XMMRegister dst, Address src) { Assembler::movapd(dst, src); }
> 1250:   void movapd(XMMRegister dst, AddressLiteral src, Register rscratch = noreg);
> 1251: 

You could write it as:
using Assembler::movapd;
void movapd(XMMRegister dst, AddressLiteral src, Register rscratch = noreg);

src/hotspot/cpu/x86/macroAssembler_x86.hpp line 1323:

> 1321:   void unpckhpd(XMMRegister dst, XMMRegister src) { Assembler::unpckhpd(dst, src); }
> 1322:   void unpcklpd(XMMRegister dst, XMMRegister src) { Assembler::unpcklpd(dst, src); }
> 1323: 

Do we need these declarations here?

src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp line 43:

> 41: //
> 42: // Special cases:
> 43: //  cbrt(NaN) = quiet NaN, and raise invalid exception

No exception is raised so the comment needs to be corrected.

src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp line 226:

> 224:   __ andl(rcx, 248);
> 225:   __ lea(r8, ExternalAddress(rcp_table));
> 226:   __ movsd(xmm4, Address(r8, rcx, Address::times_1));

This address and other instructions using similar address could be written as  Address(rcx, r8, Address::times_1).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2110406675
PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2110426188
PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2110536680
PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2110535561

From syan at openjdk.org  Wed May 28 01:57:57 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 28 May 2025 01:57:57 GMT
Subject: RFR: 8357597: Proxy.getInvocationHandler throws
 NullPointerException instead of IllegalArgumentException for null [v2]
In-Reply-To: <-nN-8KZpqRsFVBfpjP2hBRwBcpBnsNEM0ndHAb5xfF8=.95ec64f4-77b3-4d59-ace7-77ed2a93570a@github.com>
References: <SAxS-e8fh7vXOoBnIxEC6X6fM5KdfM8YwCH5Bl3vdFc=.738ee4a2-f142-40c3-b967-7ffe01f8a258@github.com>
 <-nN-8KZpqRsFVBfpjP2hBRwBcpBnsNEM0ndHAb5xfF8=.95ec64f4-77b3-4d59-ace7-77ed2a93570a@github.com>
Message-ID: <Rb_fyBvXni7u4TFXhSkNjMGNcM_v09iiEAByhd0iOp4=.c1b0f2df-c8d5-441a-88d7-f8302c97452c@github.com>

On Mon, 26 May 2025 15:48:10 GMT, Steffen Nie?ing <duke at openjdk.org> wrote:

>> `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE.
>
> Steffen Nie?ing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357597: Update copyright year

GHA report several failures, most the test failures are static-jdk says `Unable to use shared archive`. I think the GHA test failures are unrelated to this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25419#issuecomment-2914645336

From duke at openjdk.org  Wed May 28 01:57:57 2025
From: duke at openjdk.org (Steffen =?UTF-8?B?Tmllw59pbmc=?=)
Date: Wed, 28 May 2025 01:57:57 GMT
Subject: Integrated: 8357597: Proxy.getInvocationHandler throws
 NullPointerException instead of IllegalArgumentException for null
In-Reply-To: <SAxS-e8fh7vXOoBnIxEC6X6fM5KdfM8YwCH5Bl3vdFc=.738ee4a2-f142-40c3-b967-7ffe01f8a258@github.com>
References: <SAxS-e8fh7vXOoBnIxEC6X6fM5KdfM8YwCH5Bl3vdFc=.738ee4a2-f142-40c3-b967-7ffe01f8a258@github.com>
Message-ID: <K1SEx_anRU51pMxCEZIgQWRxyOffS36YccpsoEJaXjI=.9defbfc2-e3e7-4391-9b8c-cfff35a120ef@github.com>

On Fri, 23 May 2025 16:05:08 GMT, Steffen Nie?ing <duke at openjdk.org> wrote:

> `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the specified argument is `null`. This PR adds the missing `throws` declaration for the NPE.

This pull request has now been integrated.

Changeset: 4cad4379
Author:    Steffen Nie?ing <zuniquex at protonmail.com>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4cad437956ff75a377adba8a760e19dc6cf7dc8d
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8357597: Proxy.getInvocationHandler throws NullPointerException instead of IllegalArgumentException for null

Reviewed-by: rriggs, jpai, liach

-------------

PR: https://git.openjdk.org/jdk/pull/25419

From smarks at openjdk.org  Wed May 28 02:28:03 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 28 May 2025 02:28:03 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v26]
In-Reply-To: <YzGSrFW7z3GSmzv2Pvmdq6PEIwR2KchNPd-X6ZUhmzs=.e218db04-f9bc-4473-a25f-5ef1e13f1358@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <YzGSrFW7z3GSmzv2Pvmdq6PEIwR2KchNPd-X6ZUhmzs=.e218db04-f9bc-4473-a25f-5ef1e13f1358@github.com>
Message-ID: <GrrM013TUyDCPzCiq2fp85lgBTbybtI4VajLrLFp9ys=.9e783152-450f-4066-9e34-48da26bd7b60@github.com>

On Fri, 23 May 2025 18:44:42 GMT, Brian Burkhalter <bpb at openjdk.org> 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: "input reader specific" -> "reader specific"

Changes all look good!

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24728#pullrequestreview-2873351582

From asemenyuk at openjdk.org  Wed May 28 03:28:50 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 28 May 2025 03:28:50 GMT
Subject: RFR: 8357930: Amendment for JDK-8333664
Message-ID: <ILdlyOHPrjsY0TZI5FGDdxf2Iecwvqq2M5w8oha3W8I=.d1258351-347d-4f4a-807d-50b72c3b82ca@github.com>

- Extract ExternalApplication interface from AppImageFile and add it to the model;
 - Move LauncherData.ModuleInfo class to the top level;
 - Add parent interface BundleSpec for Application and Package interfaces in the model;
 - Merge PackageWriter and ApplicationWriter into BundleCreator interface;
 - Add BundlingEnvironment, and BundlingOperation interfaces to the model;
 - Remove LauncherModularStartupInfoMixin.modulePath(). It is not being used;
 - Remove CollectionUtils.toSet();

Additionally, fix modifier order in TokenReplace.

-------------

Commit messages:
 - Fix copyright year
 - Fix modifier order
 - Fix a typo
 - Remove CollectionUtils.toSet()
 - Decouple LauncherData and LauncherData.ModuleInfo; Add ModuleInfo.fileLocation()
 - Add ExternalApplication, BundlingEnvironment, BundleSpec, and BundlingOperation to the model. Merge ApplicationWriter and PackageWriter into the new BundleCreator. Remove LauncherModularStartupInfoMixin.modulePath(). It is not being used.

Changes: https://git.openjdk.org/jdk/pull/25477/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25477&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357930
  Stats: 617 lines in 22 files changed: 342 ins; 234 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/25477.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25477/head:pull/25477

PR: https://git.openjdk.org/jdk/pull/25477

From mbaesken at openjdk.org  Wed May 28 05:56:56 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 May 2025 05:56:56 GMT
Subject: RFR: 8357561: BootstrapLoggerTest does not work on Ubuntu 24 with
 LANG de_DE.UTF-8 [v2]
In-Reply-To: <UXKCaM-CuwYwTgOkg6tg6qhvndQmYDSpf9WJk19YChE=.da37cc57-5430-48cd-9e1e-e6f4ca1d8907@github.com>
References: <O6WamnBOTS0CLGB8whhkHhosBhPoqUzMAorzWXWWOc0=.d07e26d6-4682-4fcd-a116-4a6bcc69c4c3@github.com>
 <UXKCaM-CuwYwTgOkg6tg6qhvndQmYDSpf9WJk19YChE=.da37cc57-5430-48cd-9e1e-e6f4ca1d8907@github.com>
Message-ID: <YvHBfV4mNI67H3Pb4mUwC_f0MPDOYo0UGufWRGCotm0=.ec296450-b599-408a-8121-27b6e86f8b8d@github.com>

On Mon, 26 May 2025 08:16:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On a 'german'  Ubuntu 24 (LANG="de_DE.UTF-8") the jtreg test
>> java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest fails with
>> 
>> 
>> FEIN: hi now!
>> java.lang.RuntimeException: System.err does not contain: FINE: hi now!
>> at BootstrapLoggerTest.main(BootstrapLoggerTest.java:231)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>> at java.base/java.lang.Thread.run(Thread.java:1447)
>> 
>> 
>> The test (and some others in :tier1 as well) do not work with non en/US LANG, so they need an adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust LocalizedLevelName too

Hi Daniel thanks for testing and for the review !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25441#issuecomment-2915030686

From mbaesken at openjdk.org  Wed May 28 05:56:57 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 May 2025 05:56:57 GMT
Subject: Integrated: 8357561: BootstrapLoggerTest does not work on Ubuntu 24
 with LANG de_DE.UTF-8
In-Reply-To: <O6WamnBOTS0CLGB8whhkHhosBhPoqUzMAorzWXWWOc0=.d07e26d6-4682-4fcd-a116-4a6bcc69c4c3@github.com>
References: <O6WamnBOTS0CLGB8whhkHhosBhPoqUzMAorzWXWWOc0=.d07e26d6-4682-4fcd-a116-4a6bcc69c4c3@github.com>
Message-ID: <lR58dySPNylVwMOjLLcLmgwM4OGcn2n39F-zg3gNT8Q=.2fcc8405-4178-43dc-ba96-4664702b8991@github.com>

On Mon, 26 May 2025 07:37:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On a 'german'  Ubuntu 24 (LANG="de_DE.UTF-8") the jtreg test
> java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest fails with
> 
> 
> FEIN: hi now!
> java.lang.RuntimeException: System.err does not contain: FINE: hi now!
> at BootstrapLoggerTest.main(BootstrapLoggerTest.java:231)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1447)
> 
> 
> The test (and some others in :tier1 as well) do not work with non en/US LANG, so they need an adjustment.

This pull request has now been integrated.

Changeset: 670ef8cc
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/670ef8cc52e6eb068ca6968142629abc1c424571
Stats:     18 lines in 4 files changed: 13 ins; 0 del; 5 mod

8357561: BootstrapLoggerTest does not work on Ubuntu 24 with LANG de_DE.UTF-8

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/25441

From almatvee at openjdk.org  Wed May 28 07:03:54 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 28 May 2025 07:03:54 GMT
Subject: RFR: 8357930: Amendment for JDK-8333664
In-Reply-To: <ILdlyOHPrjsY0TZI5FGDdxf2Iecwvqq2M5w8oha3W8I=.d1258351-347d-4f4a-807d-50b72c3b82ca@github.com>
References: <ILdlyOHPrjsY0TZI5FGDdxf2Iecwvqq2M5w8oha3W8I=.d1258351-347d-4f4a-807d-50b72c3b82ca@github.com>
Message-ID: <sBfAd_jLiuUqumIS21QNiONMpi2j4cQBViyu7OarTX4=.3dda6535-ceac-4864-a4e3-a4b41db6d60d@github.com>

On Wed, 28 May 2025 02:52:57 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Extract ExternalApplication interface from AppImageFile and add it to the model;
>  - Move LauncherData.ModuleInfo class to the top level;
>  - Add parent interface BundleSpec for Application and Package interfaces in the model;
>  - Merge PackageWriter and ApplicationWriter into BundleCreator interface;
>  - Add BundlingEnvironment, and BundlingOperation interfaces to the model;
>  - Remove LauncherModularStartupInfoMixin.modulePath(). It is not being used;
>  - Remove CollectionUtils.toSet();
> 
> Additionally, fix modifier order in TokenReplace.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/FromParams.java line 106:

> 104:             if (hasPredefinedAppImage(params)) {
> 105:                 final var appImageFile = PREDEFINED_APP_IMAGE_FILE.fetchFrom(params);
> 106:                 appBuilder.initFromExernalApplication(appImageFile, launcherInfo -> {

`Exernal` -> `External`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25477#discussion_r2111081544

From almatvee at openjdk.org  Wed May 28 07:16:30 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 28 May 2025 07:16:30 GMT
Subject: RFR: 8351369: [macos] Use --install-dir option with DMG packaging
Message-ID: <kzagV86LsE-55gtYItG-NVpkQwhj229GhyxEcnMS9ig=.7a5fbe15-004a-471d-a095-26c2b8147179@github.com>

- `--install-dir` option in DMG packaging is no longer ignored.
- Defaults are still the same: `/Applications` and `/Library/Java/JavaVirtualMachines`.
- If the installation directory doesn't exist, jpackage will try to create and delete it right after the DMG package is created.
- If jpackage was unable to create installation directory error will be thrown or if installation directory points to invalid location like file.
- It will be user responsibility to make sure installation directory exist on target machine, since DMG cannot create directories during drag and drop.
- Target directory in case of non-default installation dir will display full path. See image below for example.

![Screenshot 2025-05-28 at 12 07 53?AM](https://github.com/user-attachments/assets/fbcba07b-74a5-4276-90c3-5f8d2d0dcc16)

-------------

Commit messages:
 - 8351369: [macos] Use --install-dir option with DMG packaging

Changes: https://git.openjdk.org/jdk/pull/25481/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25481&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351369
  Stats: 182 lines in 5 files changed: 73 ins; 73 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/25481.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25481/head:pull/25481

PR: https://git.openjdk.org/jdk/pull/25481

From viktor.klang at oracle.com  Wed May 28 08:02:40 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 28 May 2025 08:02:40 +0000
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <CAKD1RYtpahV4766wNodvcrSGFqJ6ereG1fUJFi-yEviOpLcb=Q@mail.gmail.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774265B8728DA0641C48DBAFF152@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYut_G7TRSTr0hPVuxWAvJQ+25JyPBWB7PEtntamWq-E_A@mail.gmail.com>
 <MW4PR10MB5774AB9B6544E949383187F3FFEC2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvyRxcWv65v4+8KcRHys=jkbpfKZ3eK3ijTGKXR1UxNnA@mail.gmail.com>
 <MW4PR10MB5774986199F9EDF854A6D390FFEE2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtE-xwb9tBhjPvObeG9_03nXh1aRA10sO7ibEGkQavntw@mail.gmail.com>
 <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtAUfyUHOdmSeZ2Azny=RJU63FQozY2NxpYu-4xQYCRkA@mail.gmail.com>
 <MW4PR10MB5774B089653C902899FEBEAFFFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB5774BB2B60EE5A1F4B1A7306FFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvxZ0gpHJXW0ctuHwEGwfStfjmLvwV1CgSWrr8438rWPA@mail.gmail.com>
 <MW4PR10MB5774EF4D4316B5BE46B29A0EFFF12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYsJyHeEs1fc4DRTZKwDO_U4Pyjv45BQ5fvr6VbboaVCTQ@mail.gmail.com>
 <MW4PR10MB57743363CCA3306B316F3EEDFF65A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYuPzVW+VHt_MzOrXW93iNv0A03JFSCV+yawCFeaLm=HsA@mail.gmail.com>
 <CAKD1RYtpahV4766wNodvcrSGFqJ6ereG1fUJFi-yEviOpLcb=Q@mail.gmail.com>
Message-ID: <MW4PR10MB577459221CD425EFD5686426FF67A@MW4PR10MB5774.namprd10.prod.outlook.com>

It would seem to require a change to the Java Language Specification section 17.2.4

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com>
Sent: Wednesday, 28 May 2025 00:35
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

That said, I'm still curious. Have you considered propagating cancellation, re-interrupting the current thread, and then throwing an unchecked exception upon interruption? It's going to be the most fail-fast-compatible.

catch (IE interrupted) {
  cancel all pending futures
  Thread.currentThread().interrupt();
  throw new UncheckedInterruptedException();
}

What are the concerns against such practice?





On Mon, May 26, 2025 at 8:31?AM Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>> wrote:
Yeah, I think I missed the task cancellation and the joining part.

When the mapConcurrent() thread is interrupted, it propagates the cancellation to the child threads.

And if any of the children threads (running the user-provided Function) receives that cancellation, it will still need to catch it and handle interruption.

That means the interruption isn't swallowed. If the user code wants to abort, they can always just throw an unchecked exception and catch it from the caller of mapConcurrent().

That should do for most of the IO type work.

This makes sense.



On Mon, May 26, 2025 at 12:30?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Yes, the updated Gatherers.mapConcurrent will continue under interruption until done, and then restore the interrupt status of the calling thread.

It cannot (reasonably) do anything else?if it were to throw InterruptedException, it couldn't since that is a checked exception and there's no tracking of checked exceptions throughout a Stream, and that is the specified behavior to handle thread interrupts (i.e. clear flag and throw InterruptedException, which is not possible in this case; or, make sure that interrupt status is maintained, which is possible in this case.

I have given it some more thought in the meantime, but I haven't arrived in something more satisfactory than that, yet.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 26 May 2025 03:07
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Thanks Viktor!

Sorry, I was giving myself more time to read the code, but then I lost track.

If I'm reading the code right, the current behavior is that if the current thread is interrupted, the mapConcurrent() would suppress the interruption until all elements are processed? (It will then restore the interruption bit)

Doesn't this break fail fast?

For example, I may have a mapConcurrent() called from within structured concurrency, and that fans out to two operations:
?
scope.fork(() -> doA());
scope.fork(() -> doB());  // calls mapConcurrent() internally
scope.join().throwIfFailed();

If doA() fails, doB() will be cancelled (thread interrupted).

If mapConcurrent() ignores the interruption, and if doB has a long list to process, it'll continue to consume system resources even when the caller no longer needs the results, no?


On Fri, Feb 7, 2025 at 2:16?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>Sorry, did the PR stop using Semaphore?

No, not that PR. See: https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e<https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e__;!!ACWV5N9M2RV99hQ!OKfWrvJEDCkiHcT5b4a6gfeomZzZeq3jv6ir2vf2I5WWIhujtb-by_VuQFaAPDIuAA0qAwpTUjllXMPF$>

The problem with interruption under parallel evaluation is that there is no general support for propagation of interruption in CountedCompleters. Adding support for such in (at least) GathererOp needs further study before contemplating making any changes to mapConcurrent()'s interruption policy.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Thursday, 6 February 2025 17:04
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Sorry, did the PR stop using Semaphore?

I had naively thought that mapConcurrent() will keep a buffer of Future of all currently-running concurrent tasks (it can be a ConcurrentMap<TaskKey, Future> if we don't have to ensure FIFO).

Upon interruption, the main thread can call .cancel(true) on all pending Futures; optionally join with the VTs (if we need to block until all VTs exit); then propagate exception.

Upon completion, each task just removes itself from the ConcurrentMap.

Just in case it adds anything.



On Thu, Feb 6, 2025 at 6:47?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
After some more investigation it seems tractable to propagate interruption of the caller in sequential mode, but parallel mode will require much bigger considerations.

I made a comment to that effect on the JBS issue: https://bugs.openjdk.org/browse/JDK-8349462?focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Sent: Thursday, 6 February 2025 11:51
To: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

I think alignment in behavior between parallel Stream and mapConcurrent in terms of how interruptions are handled is a possible path forward.

I decided to close the PR for now as I realized my parallel Stream example had misled me regarding its exception throwing, so I'll need to go back and refine the solution.

It still seems solvable though.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Wednesday, 5 February 2025 19:20
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Oh good call!

I forgot to check what parallel streams do upon interruption (didn't think they do any blocking calls, but at least the main thread must block).

On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi Jige,

I opened an issue to track the concern, and I have proposed a change which seems to align well with how parallel streams behave under caller thread interruption.

I've opened the following PR for review:
https://github.com/openjdk/jdk/pull/23467<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>

If you are able to make a local OpenJDK build with that solution you could check if it addresses your use-cases (or not).
[https://opengraph.githubassets.com/00e04f8a63bde12217df087df7ef8edee563adf7e925d07c75bdeae092180094/openjdk/jdk/pull/23467]<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
8349462: Gatherers.mapConcurrent could support async interrupts by viktorklang-ora ? Pull Request #23467 ? openjdk/jdk<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
This change is likely going to need some extra verbiage in the spec for mapConcurrent, and thus a CSR. This behavior aligns mapConcurrent with how parallel streams work in conjunction with interrup...
github.com<https://urldefense.com/v3/__http://github.com__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89DBkMefT$>


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Wednesday, 5 February 2025 16:24
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Thanks Viktor!

I understand the problem.

The main reason I asked is because I want to understand how the core Java team thinks of throwing an unchecked exception.

As explained above, I consider losing cancellability a big deal, a deal breaker even. And I thought throwing unchecked is more acceptable. Because the most common reason the mapConcurrent() VT can be interrupted is due to cancellation from a parent mapConcurrent(), or a parent Structured Concurrency scope. The cancellation could be either from an organic exception, or from the downstream not needing more elements, like maybe due to findFirst() already getting an element.

In both cases, since the concurrent operation is already cancelled (result ignored), what exception pops up to the top level isn't that big of a deal (perhaps only a log record will be seen?)

But if the core Java team considers it a bad idea, I would love to learn and adjust.

On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi,

The problem is that mapConcurrent cannot throw InterruptedException because that is a checked exception, so we cannot clear the interrupted flag and throw that exception.

So the updated semantics is to not cut the stream short but instead run to completion, restoring the interruption flag.

There exists a couple of alternatives to this approach which I am contemplating, but they need to be further explored before I consider moving forward with any of them.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 27 January 2025 17:00
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Thanks Viktor!

It looks like the current fix ignores interruption.

I want to make sure my concern of it defeating cancellation is heard and understood.

The scenarios I worry about is for a mapConcurrent() that fans out to another method call, which internally calls mapConcurrent() as implementation detail.

An example:


List<RefundResponse> refundHelper(transaction) {
  transaction.creditCardAccounts.stream()
    .gather(mapConcurrent(acct -> service.refund(acct))
    .toList();
}

transactions.stream()
    .gather(mapConcurrent(transaction -> refundHelper(transaction));

It seems undesirable that in such a case all the service.refund() calls become non cancellable, because the only way the outer mapConcurrent() cancels the refundHelper() calls is through Thread.interrupt() the virtual threads that call refundHelper(), which would then be disabled by the inner mapConcurrent().

Does this example make sense to you? I can further explain if anything isn't clear.

But I want to make sure the decision to disable interruption is deliberate judgement call that such nested mapConcurrent() is unlikely,or not important.

Cheers,



On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi!

Please see: https://github.com/openjdk/jdk/pull/23100<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23100__;!!ACWV5N9M2RV99hQ!IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Sunday, 26 January 2025 23:03
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: [External] : Re: mapConcurrent() with InterruptedException

Checking in on what you've found out, Viktor.

From where we left off, I understand that you were looking at alternatives instead of silent truncation?

Have you reached any conclusion?

We touched on disallowing interruption during mapConcurrent(). I still have concerns with disabling cancellation, because it basically undoes this API note from the javadoc<https://cr.openjdk.org/~alanb/sc-20240503/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)>:


API Note:

In progress tasks will be attempted to be cancelled, on a best-effort basis, in situations where the downstream no longer wants to receive any more elements.
In reality, people will use mapConcurrent() to fan out rpcs. Sometimes these rpcs are just a single blocking call; yet sometimes they may themselves be a Structured Concurrency scope, with 2 or 3 rpcs that constitute a single logical operation. Under two conditions, cancellation is imho important semantic:

  1.  The downstream code uses filter().findFirst(), and when it sees an element, it will return and no longer needs the other pending rpcs to complete. If cancellation is disabled, these unnecessary rpcs will waste system resources.
  2.  One of the rpc throws and the Stream pipeline needs to propagate the exception. Again, if the other rpcs cannot be cancelled, we'll have many zombie rpcs.

Zombie rpcs may or may not be a deal breaker, depending on the specific use case. But for a JDK library, losing cancellation would have a negative impact on usability.

My 2c,


On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi Ben,

Thanks for raising these questions?getting feedback is crucial in the Preview stage of features.

I wrote a reply to the Reddit thread so I'll just summarize here:

It is important to note that mapConcurrent() is not a part of the Structured Concurrency JEPs, so it is not designed to join SC scopes.

I'm currently experimenting with ignoring-but-restoring interrupts on the "calling thread" for mapConcurrent(), as well as capping work-in-progress to maxConcurrency (not only capping the concurrency but also the amount of completed-but-yet-to-be-pushed work). Both of these adjustments should increase predictability of behavior in the face of blocking operations with variable delays.

Another adjustment I'm looking at right now is to harden/improve the cleanup to wait for concurrent tasks to acknowledge cancellation, so that once the finisher is done executing the VTs are known to have terminated.

As for not preserving the encounter order, that would be a completely different thing, and I'd encourage you to experiment with that if that functionality would be interesting for your use-case(s).

Again, thanks for your feedback!

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Friday, 3 January 2025 17:53
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: mapConcurrent() with InterruptedException

Hi Java Experts,

I sent this email incorrectly to loom-dev@ and was told on Reddit that core-libs-dev is the right list.

The question is about the behavior of mapConcurrent() when the thread is interrupted.

Currently mapConcurrent()'s finisher phase will re-interrupt the thread, then stop at whatever element that has already been processed and return.

This strikes me as a surprising behavior, because for example if I'm running:

   Stream.of(1, 2, 3)
        .gather(mapConcurrent(i -> i * 2))
        .toList()

and the thread is being interrupted, the result could be any of [2], [2, 4] or [2, 4, 6].

Since thread interruption is cooperative, there is no guarantee that the thread being interrupted will just abort. It's quite possible that it'll keep going and then will use for example [2] as the result of doubling the list of [1, 2, 3], which is imho incorrect.

In the Reddit<https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread, someone argued that interruption rarely happens so it's more of a theoretical issue. But interruption can easily happen in Structured Concurrency or in mapConcurrent() itself if any subtask has failed in order to cancel/interrupt the other ongoing tasks.

There had been discussion about alternative strategies:

  1.  Don't respond to interruption and just keep running to completion.
  2.  Re-interrupt thread and wrap the InterruptedException in a standard unchecked exception (StructuredConcurrencyInterruptedException?).

I have concerns with option 1 because it disables cancellation propagation when mapConcurrent() itself is used in a subtask of a parent mapConcurrent() or in a StructuredConcurrencyScope.

Both equivalent Future-composition async code, or C++'s fiber trees support cancellation propagation and imho it's a critical feature or else it's possible that a zombie thread is still sending RPCs long after the main thread has exited (failed, or falled back to some default action).

My arguments for option 2:

  1.  InterruptedException is more error prone than traditional checked exceptions for users to catch and handle. They can forget to re-interrupt the thread. It's so confusing that even seasoned programmers may not know they are supposed to re-interrupt the thread.
  2.  With Stream API using functional interfaces like Supplier, Function, the option of just tacking on "throws IE" isn't available to many users.
  3.  With Virtual Threads, it will be more acceptable, or even become common to do blocking calls from a stream operation (including but exclusive to mapConcurrent()). So the chance users are forced to deal with IE will become substantially higher.
  4.  Other APIs such as the Structured Concurrency API have already started wrapping system checked exceptions like ExecutionException, TimeoutException in unchecked exceptions ( join()<https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for example).
  5.  Imho, exceptions that we'd rather users not catch and handle but instead should mostly just propagate up as is, should be unchecked.

There is also a side discussion<https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/comment/m4z4f8c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about whether mapConcurrent() is better off preserving input order or push to downstream as soon as an element is computed. I'd love to discuss that topic too but maybe it's better to start a separate thread?

Thank you and cheers!

Ben Yu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250528/ea0956bf/attachment-0001.htm>

From rgiulietti at openjdk.org  Wed May 28 08:15:58 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 28 May 2025 08:15:58 GMT
Subject: Integrated: 8357808: Add a command line option for specifying a
 counter in TestRandomFloatingDecimal
In-Reply-To: <lcy18pmUVn1YuGSjOgVodYQSphnq6mlnE-yAsrLlcso=.fa5e7943-f7ad-4f88-a7cd-8f46fe7bcf18@github.com>
References: <lcy18pmUVn1YuGSjOgVodYQSphnq6mlnE-yAsrLlcso=.fa5e7943-f7ad-4f88-a7cd-8f46fe7bcf18@github.com>
Message-ID: <GjVhaJDNNARLruP40tiFoJ-TKQ112SEDgKOJdUzJHtY=.f3dca4b6-e04b-4d24-a15f-d914c1f43c50@github.com>

On Mon, 26 May 2025 18:44:58 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Add a `-Dcount=N` command line option to specify the number of random samples per test (default is 10'000).

This pull request has now been integrated.

Changeset: efeb050e
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/efeb050e00145da18f979fe17c22da2f736dbd41
Stats:     25 lines in 1 file changed: 18 ins; 0 del; 7 mod

8357808: Add a command line option for specifying a counter in TestRandomFloatingDecimal

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/25460

From pminborg at openjdk.org  Wed May 28 09:13:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 28 May 2025 09:13:03 GMT
Subject: RFR: 8357919: Arena::allocate returns segments with address zero if
 the segment length is zero after JDK-8345687
Message-ID: <jB2pCh8XxuXtFaf1exdYe1Sqv0txCrFJfTMBoZnyi68=.c40efc5e-910b-4496-9062-d7bb3db3659e@github.com>

After https://bugs.openjdk.org/browse/JDK-8345687 was integrated, zero-length segments always have an address of zero. This may cause problems in certain native methods that can receive segments and/or buffers derived from segments.

This PR also guards for overflow for extremely large allocation requests.

-------------

Commit messages:
 - Fix zero-length allocation

Changes: https://git.openjdk.org/jdk/pull/25485/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25485&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357919
  Stats: 28 lines in 2 files changed: 28 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25485.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25485/head:pull/25485

PR: https://git.openjdk.org/jdk/pull/25485

From aph at openjdk.org  Wed May 28 09:43:57 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 28 May 2025 09:43:57 GMT
Subject: Integrated: 8355022: Implement JEP 506: Scoped Values
In-Reply-To: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
Message-ID: <jyAtAbsUnBoPqw9O9MS0Ch9QpLy_tjDYPXWbbLrQmHQ=.2edb17a9-9892-4407-aacd-ef945fdcc319@github.com>

On Mon, 28 Apr 2025 14:32:04 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a null argument.

This pull request has now been integrated.

Changeset: 4e1878ca
Author:    Andrew Haley <aph at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e1878ca452d1e781eb61610a94064c0c4798073
Stats:     21 lines in 6 files changed: 3 ins; 12 del; 6 mod

8355022: Implement JEP 506: Scoped Values

Reviewed-by: liach, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/24923

From vklang at openjdk.org  Wed May 28 10:10:51 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 28 May 2025 10:10:51 GMT
Subject: RFR: 8356553 : Incorrect uses of {@link} in
 AbstractQueuedLongSynchronizer and AbstractQueuedSynchronizer
In-Reply-To: <MUUKubOpiTGb8HMlRrSSIQYRp8tAcyNkMbRhNx_-Q9k=.ec0fc7e4-4bd3-42e9-ba1a-87b38d3e157b@github.com>
References: <DIYNj468OURl1lR6zApUxLChBOk_auF2nHZIguw0Cts=.a5878b91-7123-45fe-8c83-6bfdedf468b4@github.com>
 <MUUKubOpiTGb8HMlRrSSIQYRp8tAcyNkMbRhNx_-Q9k=.ec0fc7e4-4bd3-42e9-ba1a-87b38d3e157b@github.com>
Message-ID: <IUS7KS0cBD80pZrwJuxzPEkvLCN8V8n71JUdkSPfVQg=.ba4e45f8-6a68-476a-a434-b7ac5858ff17@github.com>

On Tue, 27 May 2025 15:51:34 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I had to tweak the language a bit to better reflect the intent of the text.
>
> Thanks for doing this! There are no longer any links to private types in `java.util.concurrent`

Thanks @nizarbenalla !

@DougLea Do you think this modification is acceptable?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25462#issuecomment-2915747338

From mcimadamore at openjdk.org  Wed May 28 10:33:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 May 2025 10:33:54 GMT
Subject: RFR: 8357919: Arena::allocate returns segments with address zero
 if the segment length is zero after JDK-8345687
In-Reply-To: <jB2pCh8XxuXtFaf1exdYe1Sqv0txCrFJfTMBoZnyi68=.c40efc5e-910b-4496-9062-d7bb3db3659e@github.com>
References: <jB2pCh8XxuXtFaf1exdYe1Sqv0txCrFJfTMBoZnyi68=.c40efc5e-910b-4496-9062-d7bb3db3659e@github.com>
Message-ID: <8JVZE83GsCjXfGyaNIlR3BjfbGlkGsDi2AvRFjAxHAU=.77f12675-ad15-4705-b9bd-5bce1d36dc80@github.com>

On Wed, 28 May 2025 09:06:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> After https://bugs.openjdk.org/browse/JDK-8345687 was integrated, zero-length segments always have an address of zero. This may cause problems in certain native methods that can receive segments and/or buffers derived from segments.
> 
> This PR also guards for overflow for extremely large allocation requests.

Some history: https://github.com/openjdk/panama-foreign/pull/650

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25485#issuecomment-2915815875

From dl at openjdk.org  Wed May 28 10:35:53 2025
From: dl at openjdk.org (Doug Lea)
Date: Wed, 28 May 2025 10:35:53 GMT
Subject: RFR: 8356553 : Incorrect uses of {@link} in
 AbstractQueuedLongSynchronizer and AbstractQueuedSynchronizer
In-Reply-To: <DIYNj468OURl1lR6zApUxLChBOk_auF2nHZIguw0Cts=.a5878b91-7123-45fe-8c83-6bfdedf468b4@github.com>
References: <DIYNj468OURl1lR6zApUxLChBOk_auF2nHZIguw0Cts=.a5878b91-7123-45fe-8c83-6bfdedf468b4@github.com>
Message-ID: <ynRtPkstghzKZqyS9El0G6WvcOKJM7kv7V2qGZ84hjI=.a76ba3ba-74a2-4e28-a4b1-f6b0c4dbbcd1@github.com>

On Tue, 27 May 2025 09:35:51 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> I had to tweak the language a bit to better reflect the intent of the text.

This seems OK. Maybe needlessly pedantic, but OK :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25462#issuecomment-2915821182

From mcimadamore at openjdk.org  Wed May 28 10:37:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 May 2025 10:37:53 GMT
Subject: RFR: 8357919: Arena::allocate returns segments with address zero
 if the segment length is zero after JDK-8345687
In-Reply-To: <jB2pCh8XxuXtFaf1exdYe1Sqv0txCrFJfTMBoZnyi68=.c40efc5e-910b-4496-9062-d7bb3db3659e@github.com>
References: <jB2pCh8XxuXtFaf1exdYe1Sqv0txCrFJfTMBoZnyi68=.c40efc5e-910b-4496-9062-d7bb3db3659e@github.com>
Message-ID: <qdKa7aPsDsGLOyVTPHoudZ-uAVs-aV_xPJ1QJ7gm2Bk=.ae03015e-8a55-4328-9a42-1cf27e138ce4@github.com>

On Wed, 28 May 2025 09:06:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> After https://bugs.openjdk.org/browse/JDK-8345687 was integrated, zero-length segments always have an address of zero. This may cause problems in certain native methods that can receive segments and/or buffers derived from segments.
> 
> This PR also guards for overflow for extremely large allocation requests.

Very good catch -- and good thing you added more tests! In the PR I linked, it seems that a test has been added for this case -- but sadly that test doesn't check for `address() != 0` -- you have now fixed that -- thanks.

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25485#pullrequestreview-2874495380

From pminborg at openjdk.org  Wed May 28 11:00:55 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 28 May 2025 11:00:55 GMT
Subject: Integrated: 8357919: Arena::allocate returns segments with address
 zero if the segment length is zero after JDK-8345687
In-Reply-To: <jB2pCh8XxuXtFaf1exdYe1Sqv0txCrFJfTMBoZnyi68=.c40efc5e-910b-4496-9062-d7bb3db3659e@github.com>
References: <jB2pCh8XxuXtFaf1exdYe1Sqv0txCrFJfTMBoZnyi68=.c40efc5e-910b-4496-9062-d7bb3db3659e@github.com>
Message-ID: <AqAei26PZo3f60-JlkWm7kutjEomAyGLlAFLKhhgFAo=.7030e14b-a35c-43c4-ba4d-a0ad32bce504@github.com>

On Wed, 28 May 2025 09:06:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> After https://bugs.openjdk.org/browse/JDK-8345687 was integrated, zero-length segments always have an address of zero. This may cause problems in certain native methods that can receive segments and/or buffers derived from segments.
> 
> This PR also guards for overflow for extremely large allocation requests.

This pull request has now been integrated.

Changeset: 0671309d
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0671309de530822cc261e8251fc425c8aa3cc487
Stats:     28 lines in 2 files changed: 28 ins; 0 del; 0 mod

8357919: Arena::allocate returns segments with address zero if the segment length is zero after JDK-8345687

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/25485

From jpai at openjdk.org  Wed May 28 11:07:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 May 2025 11:07:57 GMT
Subject: RFR: 8357919: Arena::allocate returns segments with address zero
 if the segment length is zero after JDK-8345687
In-Reply-To: <jB2pCh8XxuXtFaf1exdYe1Sqv0txCrFJfTMBoZnyi68=.c40efc5e-910b-4496-9062-d7bb3db3659e@github.com>
References: <jB2pCh8XxuXtFaf1exdYe1Sqv0txCrFJfTMBoZnyi68=.c40efc5e-910b-4496-9062-d7bb3db3659e@github.com>
Message-ID: <qnIqYCCqsMViHfAzqg86JY_w1HUd5qzy9vYQPiwi86I=.524931ac-40bd-44ad-87be-ce9c2e16af49@github.com>

On Wed, 28 May 2025 09:06:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> After https://bugs.openjdk.org/browse/JDK-8345687 was integrated, zero-length segments always have an address of zero. This may cause problems in certain native methods that can receive segments and/or buffers derived from segments.
> 
> This PR also guards for overflow for extremely large allocation requests.

Thank you for investigating this issue and addressing it Per.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25485#issuecomment-2915902692

From michaelm at openjdk.org  Wed May 28 11:13:12 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 28 May 2025 11:13:12 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v12]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <P1UhwKclOZOB8wVg38pTcQ7ZqO71ZQAAitPucfs_t4o=.5a555883-1d19-43f3-9e19-b1797d594796@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 30 commits:

 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - update
 - reduced number of new categories
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Review update
 - ... and 20 more: https://git.openjdk.org/jdk/compare/0671309d...cf179f7d

-------------

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=11
  Stats: 912 lines in 42 files changed: 681 ins; 101 del; 130 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 nbenalla at openjdk.org  Wed May 28 11:16:53 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 28 May 2025 11:16:53 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v4]
In-Reply-To: <NZS8nG9pke2VR2jVtRZLeDMYst9ziR3FqvYdLxFOL14=.509579cd-046f-4c71-8cfa-952ffd787ca2@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
 <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
 <NZS8nG9pke2VR2jVtRZLeDMYst9ziR3FqvYdLxFOL14=.509579cd-046f-4c71-8cfa-952ffd787ca2@github.com>
Message-ID: <kJU-qnTMin0UfPHOcncu9cjt5dCCIfYRvckREpE46fw=.a93b3e4c-cae1-4400-a8e9-15901aa5afde@github.com>

On Thu, 8 May 2025 13:15:35 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> It is to accommodate the now longer list of --release values in the javac help output,the addition of ", 26".
>> 
>> Splitting the list of releases over two lines would be a better solution, but I didn't take that one when initially preparing the patch.
>
> I'll split the releases over  two lines in the next update. The line is a little too long.

Thinking about this again, could we represent the supported versions more concisely? like `8-26` or `from 8 to 26`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2111590538

From rgiulietti at openjdk.org  Wed May 28 11:31:55 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 28 May 2025 11:31:55 GMT
Subject: RFR: 8356891: Some code simplifications in BigInteger [v25]
In-Reply-To: <RV4MfmfKevR6ReO5Y7-fYNKIm50RuLelHLRwVaR0w_E=.594ecb57-d7c9-47a5-bd5c-5fea947344ca@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
 <RV4MfmfKevR6ReO5Y7-fYNKIm50RuLelHLRwVaR0w_E=.594ecb57-d7c9-47a5-bd5c-5fea947344ca@github.com>
Message-ID: <et6ejZ_sjDxtEK6m-VC_5xCukcHAtHYn-eh8G8mNO2s=.ded608a3-1e8f-40e2-a7e1-72273d4dcf65@github.com>

On Tue, 27 May 2025 21:42:37 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore calls to trustedStripLeadingZeroInts(int[])

LGTM.

Thanks for this cleanup.

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25166#pullrequestreview-2874639608

From michaelm at openjdk.org  Wed May 28 11:34:58 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 28 May 2025 11:34:58 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <d94-xQnF1ppR1_a0OxbNpFUlocFLhmMjth3QNkyb_Tw=.805108e3-04fc-4a96-9ad1-9fd08d8f1aa1@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
 <d94-xQnF1ppR1_a0OxbNpFUlocFLhmMjth3QNkyb_Tw=.805108e3-04fc-4a96-9ad1-9fd08d8f1aa1@github.com>
Message-ID: <Bu6wcccn3cfvlDuNu_L_zlPBD8tKrQJa-2gALdtWBvo=.b2a84461-3d41-4538-882f-01f387887b78@github.com>

On Mon, 26 May 2025 17:07:45 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Merge branch 'master' into 8348986-exceptions
>>  - update
>>  - reduced number of new categories
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Review update
>>  - review update
>>  - Merge branch 'master' into 8348986-exceptions
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19
>
> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> new file => copyright ?
> 
> Copyright (c) 2025,

The file isn't actually new, though webrev doesn't seem to realise that on this occasion (sometimes it does recognise name changes). It was previously named SocketExceptions. I presume we keep the existing header in that case?

> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 130:
> 
>> 128:         public abstract String output();
>> 129: 
>> 130:         protected String output(boolean enhance) {
> 
> to help us simple folk getting into a tizzy over a public abstract and a protected method of the same name and overloaded to boot
> suggest
> refactor rename this method name to composeFilteredMessageText  or composeFilteredText or just compose

Okay, I'll use one of those options, whichever fits best space wise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2111618040
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2111620553

From jpai at openjdk.org  Wed May 28 11:35:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 May 2025 11:35:01 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v15]
In-Reply-To: <R2XmRmH21H4_GJDcM6Vb1W5eieDnJL5k7jP3q5jbU6E=.384615d4-266c-49d7-8289-08446f77f190@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <R2XmRmH21H4_GJDcM6Vb1W5eieDnJL5k7jP3q5jbU6E=.384615d4-266c-49d7-8289-08446f77f190@github.com>
Message-ID: <dlxl8C_RYXiE2N1t6T2wIYGb1o5TNjNjKLl4PaLugKk=.6f0e6ec3-9985-44ae-9ee6-ca3c8e2d6b98@github.com>

On Tue, 27 May 2025 16:23:47 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Minor tweaks
>  - Assure >0 exit code and fix typos
>  - Validator to take a file, use term JAR file
>  - Mismatched order is considered invalid
>  - Adapt review feedback
>  - Address review feedback
>  - Adjust message based on review feedback
>  - Move all validation into EntryValidator, update the document
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/c5449eae...2690e69f

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 239:

> 237:         /**
> 238:          * Validation per entry observed.
> 239:          * Each entry must appeare at least once in the CEN or LOC.

Typo - should have been "appear"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2111620712

From michaelm at openjdk.org  Wed May 28 11:38:01 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 28 May 2025 11:38:01 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <nrsNyrsu4t_9uZP9t_GCjRq6amD4YmolFdI3Da_P8To=.450cf3b6-8ee8-4450-9e03-2abe5b678eed@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
 <nrsNyrsu4t_9uZP9t_GCjRq6amD4YmolFdI3Da_P8To=.450cf3b6-8ee8-4450-9e03-2abe5b678eed@github.com>
Message-ID: <EbqRLMAtkUaAjK5NMoZB-nsXuIDFS6MeuzirA985pHk=.13d13602-c91d-4105-821a-0ea06caca058@github.com>

On Mon, 26 May 2025 17:40:39 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Merge branch 'master' into 8348986-exceptions
>>  - update
>>  - reduced number of new categories
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Merge branch 'master' into 8348986-exceptions
>>  - Review update
>>  - review update
>>  - Merge branch 'master' into 8348986-exceptions
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19
>
> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 58:
> 
>> 56:  *     public static SensitiveInfo filterUserName(String name)
>> 57:  */
>> 58: public final class Exceptions {
> 
> maybe a refactor rename to convey some of the semantics of the class e.g. ExceptionMessageFilter

I see what you mean, but the class does more than just filter messages. It also generates new Exception objects from existing ones. Given that its original name was `SocketExceptions` and all we've done here is generalize it to work with other exception types, I think `Exceptions` is a reasonable name.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2111626402

From jpai at openjdk.org  Wed May 28 11:38:03 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 May 2025 11:38:03 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v15]
In-Reply-To: <R2XmRmH21H4_GJDcM6Vb1W5eieDnJL5k7jP3q5jbU6E=.384615d4-266c-49d7-8289-08446f77f190@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <R2XmRmH21H4_GJDcM6Vb1W5eieDnJL5k7jP3q5jbU6E=.384615d4-266c-49d7-8289-08446f77f190@github.com>
Message-ID: <rnKlvXRyXi9QDsx1w1lYr4ccaCSRo7JfCdcE6_Aqu38=.d2d72a2b-1a16-4550-846e-a169cb0bec87@github.com>

On Tue, 27 May 2025 16:23:47 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Minor tweaks
>  - Assure >0 exit code and fix typos
>  - Validator to take a file, use term JAR file
>  - Mismatched order is considered invalid
>  - Adapt review feedback
>  - Address review feedback
>  - Adjust message based on review feedback
>  - Move all validation into EntryValidator, update the document
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/7b533d89...2690e69f

The CSR has been approved and the current changes in this PR look good to me. 
There's a typo in a comment which I've added as a review comment.
There's a test-only addition where I don't fully understand the use of ISO_8859_1 charset. I haven't had a chance to look deeper at that but we can look into it separately at a later date since it doesn't directly relate to this enhancement nor does it introduce an issue.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24430#pullrequestreview-2874653370

From cstein at openjdk.org  Wed May 28 11:38:53 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 28 May 2025 11:38:53 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v4]
In-Reply-To: <kJU-qnTMin0UfPHOcncu9cjt5dCCIfYRvckREpE46fw=.a93b3e4c-cae1-4400-a8e9-15901aa5afde@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
 <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
 <NZS8nG9pke2VR2jVtRZLeDMYst9ziR3FqvYdLxFOL14=.509579cd-046f-4c71-8cfa-952ffd787ca2@github.com>
 <kJU-qnTMin0UfPHOcncu9cjt5dCCIfYRvckREpE46fw=.a93b3e4c-cae1-4400-a8e9-15901aa5afde@github.com>
Message-ID: <3Ins14V5M3PnLXVBHH3sgqydHdmtaxrAERYbfG7egLc=.5ec6d31c-f442-482c-9f50-aa67f8e0f454@github.com>

On Wed, 28 May 2025 11:14:22 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I'll split the releases over  two lines in the next update. The line is a little too long.
>
> Thinking about this again, could we represent the supported versions more concisely? like `8-26` or `from 8 to 26`.

Another variant:

        Supported releases:
            8, 9, 10, ..., 24, 25, 26

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2111627278

From pminborg at openjdk.org  Wed May 28 11:45:52 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 28 May 2025 11:45:52 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal
In-Reply-To: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
Message-ID: <Va6WZ1hZAH0daj-aNdLthdstRnDsXLVPC1QvCtOfMOY=.27245d55-3c83-4a72-b553-728c01033ab2@github.com>

On Sun, 25 May 2025 22:35:56 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Some static final arrays of BigInteger and BigDecimal are stable and immutable. We should add `@Stable` to give the optimizer more information

src/java.base/share/classes/java/math/BigDecimal.java line 4317:

> 4315:     };
> 4316: 
> 4317:     @Stable

This one is a bit dangerous as it can be reassigned. I think we should not mark this array @Stable unless we have analysed in detail the implications thereof.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25437#discussion_r2111639918

From vklang at openjdk.org  Wed May 28 11:56:51 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 28 May 2025 11:56:51 GMT
Subject: RFR: 8356553 : Incorrect uses of {@link} in
 AbstractQueuedLongSynchronizer and AbstractQueuedSynchronizer
In-Reply-To: <ynRtPkstghzKZqyS9El0G6WvcOKJM7kv7V2qGZ84hjI=.a76ba3ba-74a2-4e28-a4b1-f6b0c4dbbcd1@github.com>
References: <DIYNj468OURl1lR6zApUxLChBOk_auF2nHZIguw0Cts=.a5878b91-7123-45fe-8c83-6bfdedf468b4@github.com>
 <ynRtPkstghzKZqyS9El0G6WvcOKJM7kv7V2qGZ84hjI=.a76ba3ba-74a2-4e28-a4b1-f6b0c4dbbcd1@github.com>
Message-ID: <p3tsyCZE4hcTkXwGwHb4neOWsY0dmDzUjt5I3ylWJws=.3b799b76-bff7-47b7-b767-709f26852842@github.com>

On Wed, 28 May 2025 10:33:12 GMT, Doug Lea <dl at openjdk.org> wrote:

>> I had to tweak the language a bit to better reflect the intent of the text.
>
> This seems OK. Maybe needlessly pedantic, but OK :-)

@DougLea You know me. :) Thanks for having a look! :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25462#issuecomment-2916025390

From asemenyuk at openjdk.org  Wed May 28 12:24:48 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 28 May 2025 12:24:48 GMT
Subject: RFR: 8357930: Amendment for JDK-8333664 [v2]
In-Reply-To: <ILdlyOHPrjsY0TZI5FGDdxf2Iecwvqq2M5w8oha3W8I=.d1258351-347d-4f4a-807d-50b72c3b82ca@github.com>
References: <ILdlyOHPrjsY0TZI5FGDdxf2Iecwvqq2M5w8oha3W8I=.d1258351-347d-4f4a-807d-50b72c3b82ca@github.com>
Message-ID: <9E__aQfmH2Ke-y0N-tWZEwoOpnNs1yyShOb5-9GggLU=.8639e8b4-88ed-4466-9a6e-e621bd442bab@github.com>

> - Extract ExternalApplication interface from AppImageFile and add it to the model;
>  - Move LauncherData.ModuleInfo class to the top level;
>  - Add parent interface BundleSpec for Application and Package interfaces in the model;
>  - Merge PackageWriter and ApplicationWriter into BundleCreator interface;
>  - Add BundlingEnvironment, and BundlingOperation interfaces to the model;
>  - Remove LauncherModularStartupInfoMixin.modulePath(). It is not being used;
>  - Remove CollectionUtils.toSet();
> 
> Additionally, fix modifier order in TokenReplace.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25477/files
  - new: https://git.openjdk.org/jdk/pull/25477/files/0f202268..49004a30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25477&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25477&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25477.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25477/head:pull/25477

PR: https://git.openjdk.org/jdk/pull/25477

From asemenyuk at openjdk.org  Wed May 28 12:24:49 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 28 May 2025 12:24:49 GMT
Subject: RFR: 8357930: Amendment for JDK-8333664 [v2]
In-Reply-To: <sBfAd_jLiuUqumIS21QNiONMpi2j4cQBViyu7OarTX4=.3dda6535-ceac-4864-a4e3-a4b41db6d60d@github.com>
References: <ILdlyOHPrjsY0TZI5FGDdxf2Iecwvqq2M5w8oha3W8I=.d1258351-347d-4f4a-807d-50b72c3b82ca@github.com>
 <sBfAd_jLiuUqumIS21QNiONMpi2j4cQBViyu7OarTX4=.3dda6535-ceac-4864-a4e3-a4b41db6d60d@github.com>
Message-ID: <rQYzvZfXG7RDQ_iwuEVjr0AcmUtbTKG7QUzj85yWrwc=.79de7259-f38f-4d8e-b530-2d4ff0c4a3bd@github.com>

On Wed, 28 May 2025 06:57:15 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/FromParams.java line 106:
> 
>> 104:             if (hasPredefinedAppImage(params)) {
>> 105:                 final var appImageFile = PREDEFINED_APP_IMAGE_FILE.fetchFrom(params);
>> 106:                 appBuilder.initFromExernalApplication(appImageFile, launcherInfo -> {
> 
> `Exernal` -> `External`

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25477#discussion_r2111711313

From rriggs at openjdk.org  Wed May 28 12:31:00 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 28 May 2025 12:31:00 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v26]
In-Reply-To: <YzGSrFW7z3GSmzv2Pvmdq6PEIwR2KchNPd-X6ZUhmzs=.e218db04-f9bc-4473-a25f-5ef1e13f1358@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <YzGSrFW7z3GSmzv2Pvmdq6PEIwR2KchNPd-X6ZUhmzs=.e218db04-f9bc-4473-a25f-5ef1e13f1358@github.com>
Message-ID: <oFbEp_JnCGfbW6Jmk0ZdHvLw62Jv05VF4iJ7qmFO2NU=.c47ffae1-42e9-4f98-b64c-4fbd5ff0017e@github.com>

On Fri, 23 May 2025 18:44:42 GMT, Brian Burkhalter <bpb at openjdk.org> 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: "input reader specific" -> "reader specific"

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24728#pullrequestreview-2874820598

From epeter at openjdk.org  Wed May 28 12:31:59 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 28 May 2025 12:31:59 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v6]
In-Reply-To: <oDd6wkHsAQU3IUV3qCvjtqZ8BSHt7Qq2sx0Yy0Q8onc=.8e7db79c-15a5-4151-ac60-73f114433383@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <oDd6wkHsAQU3IUV3qCvjtqZ8BSHt7Qq2sx0Yy0Q8onc=.8e7db79c-15a5-4151-ac60-73f114433383@github.com>
Message-ID: <Di5SQQr4tO4H1VnO-GY1n8JLFtOcH3FID9sGvlRnF1Y=.04e918b6-2efb-426e-9d38-281c08ddc7d7@github.com>

On Wed, 14 May 2025 02:44:14 GMT, erifan <duke at openjdk.org> wrote:

>> This patch optimizes the following patterns:
>> For integer types:
>> 
>> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> 
>> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond.
>> 
>> For float and double types:
>> 
>> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> 
>> cond can be eq or ne.
>> 
>> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`:
>> 
>> Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>> testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>> testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>> testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>> testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>> testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>> testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>> testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>> testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>> testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
>> testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
>> testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
>> testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
>> testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
>> testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
>> testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
>> testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
>> testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
>> testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
>> testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
>> testCompareLTMaskNotInt		ops/s	16721...
>
> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Refactor the JTReg tests for compare.xor(maskAll)
>    
>    Also made a bit change to support pattern `VectorMask.fromLong()`.
>  - Merge branch 'master' into JDK-8354242
>  - Refactor code
>    
>    Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
>    optimization, making the code more modular.
>  - Merge branch 'master' into JDK-8354242
>  - Update the jtreg test
>  - Merge branch 'master' into JDK-8354242
>  - Addressed some review comments
>    
>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>    2. Improve code comments.
>  - Merge branch 'master' into JDK-8354242
>  - Merge branch 'master' into JDK-8354242
>  - 8354242: VectorAPI: combine vector not operation with compare
>    
>    This patch optimizes the following patterns:
>    For integer types:
>    ```
>    (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>        => (VectorMaskCmp src1 src2 ncond)
>    (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>        => (VectorMaskCmp src1 src2 ncond)
>    ```
>    cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>    negative comparison of cond.
>    
>    For float and double types:
>    ```
>    (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>    (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>    ```
>    cond can be eq or ne.
>    
>    Benchmarks on Nvidia Grace machine with 128-bit SVE2:
>    With option `-XX:UseSVE=2`:
>    ```
>    Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>    testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>    testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>    testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>    testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>    testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>    testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>    testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>    testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855...

@erifan Looks like you really improved things, nice work!
I have some more comments below :)

src/hotspot/share/opto/vectornode.cpp line 2213:

> 2211:   Node* in1 = in(1);
> 2212:   Node* in2 = in(2);
> 2213:   // Transformations for predicated IRs are not supported for now.

Suggestion:

  // Transformations for predicated vectors are not supported for now.

src/hotspot/share/opto/vectornode.cpp line 2215:

> 2213:   // Transformations for predicated IRs are not supported for now.
> 2214:   if (is_predicated_vector() || in1->is_predicated_vector() ||
> 2215:       in2->is_predicated_vector()) {

I would either put all on the same line, or all on separate lines.

src/hotspot/share/opto/vectornode.cpp line 2219:

> 2217:   }
> 2218: 
> 2219:   // XorV/XorVMask is commutative, swap VectorMaskCmp/Op_VectorMaskCast to in1.

Suggestion:

  // XorV/XorVMask is commutative, swap VectorMaskCmp/VectorMaskCast to in1.

Would look a little cleaner, and you did also not write `Op_VectorMaskCmp` either ;)

src/hotspot/share/opto/vectornode.cpp line 2225:

> 2223:   }
> 2224: 
> 2225:   const TypeVect* vmcast_vt = nullptr;

Suggestion:

  const TypeVect* vector_mask_cast_vt = nullptr;

I think it would not hurt to write it out. Otherwise, the reader always has to reconstruct that in their head.

src/hotspot/share/opto/vectornode.cpp line 2230:

> 2228:     vmcast_vt = in1->as_Vector()->vect_type();
> 2229:     in1 = in1->in(1);
> 2230:   }

Add a comment why you check `in1->outcnt() == 1`.

src/hotspot/share/opto/vectornode.cpp line 2233:

> 2231:   if (in2->Opcode() == Op_VectorMaskCast) {
> 2232:     in2 = in2->in(1);
> 2233:   }

Wow, this seems to be an addition that is not covered in the patterns you mention above, right?
But is that even necessary?
I suppose here `in2 = VectorMaskCast(all_ones_vector)`.
Would we not already want to transform this pattern in `VectorMaskCast::Ideal`, is that not possible and more powerful?

src/hotspot/share/opto/vectornode.cpp line 2244:

> 2242:   // BoolTest doesn't support unsigned comparisons.
> 2243:   BoolTest::mask neg_cond =
> 2244:       (BoolTest::mask) (((VectorMaskCmpNode*) in1)->get_predicate() ^ 4);

What is the hard-coded `^ 4` here? This whole line looks like we are looking at internals of the `VectorMaskCmpNode` or its predicate, and we should probably do that in some method there? Or maybe it should be part of the `BoolTest(::mask)` interface?

src/hotspot/share/opto/vectornode.cpp line 2251:

> 2249:                                       predicate_node, vt);
> 2250:   if (vmcast_vt != nullptr) {
> 2251:     // We optimized out an VectorMaskCast, and in order to ensure type

Suggestion:

    // We optimized out a VectorMaskCast, and in order to ensure type

src/hotspot/share/opto/vectornode.cpp line 2253:

> 2251:     // We optimized out an VectorMaskCast, and in order to ensure type
> 2252:     // correctness, we need to regenerate one. VectorMaskCast will be encoded as
> 2253:     // empty for types with the same size.

Suggestion:

    // a no-op (identity function) for types with the same size.

Or what do you mean by "empty"? `TOP`? All zeros?

test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 49:

> 47:     private static final VectorSpecies<Long> L_SPECIES = LongVector.SPECIES_MAX;
> 48:     private static final VectorSpecies<Float> F_SPECIES = FloatVector.SPECIES_MAX;
> 49:     private static final VectorSpecies<Double> D_SPECIES = DoubleVector.SPECIES_MAX;

@jatin-bhateja Do you think it is sufficient to only test on `MAX` sizes here?

test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 96:

> 94:         Generator<Long> lGen = RD.uniformLongs(Long.MIN_VALUE, Long.MAX_VALUE);
> 95:         Generator<Float> fGen = RD.uniformFloats(Float.MIN_VALUE, Float.MAX_VALUE);
> 96:         Generator<Double> dGen = RD.uniformDoubles(Double.MIN_VALUE, Double.MAX_VALUE);

Are you sure you only want to draw from the uniform distribution?
If you don't super care about the distribution, please just take `RD.ints/longs/floats/doubles()`.
That way, you get all sorts of distributions, and also some that include NaN values etc. I think that would be important for your float cmp cases, no?

test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 237:

> 235:     // Byte tests
> 236:     @Test
> 237:     @IR(counts = { IRNode.XOR_V_MASK, "= 0", IRNode.XOR_VB, "= 0" },

Could you still assert the presence of some other vectors, just to make sure we are indeed getting vectors here?

test/micro/org/openjdk/bench/jdk/incubator/vector/MaskCompareNotBenchmark.java line 49:

> 47:     private static final VectorSpecies<Long> L_SPECIES = LongVector.SPECIES_MAX;
> 48:     private static final VectorSpecies<Float> F_SPECIES = FloatVector.SPECIES_MAX;
> 49:     private static final VectorSpecies<Double> D_SPECIES = DoubleVector.SPECIES_MAX;

Are you taking `SPECIES_MAX` on purpose here, or could we take `SPECIES_PREFERRED` instead?
@jatin-bhateja What is the best to do in these tests? I suppose best would be to test with all vector lengths...

-------------

PR Review: https://git.openjdk.org/jdk/pull/24674#pullrequestreview-2874740189
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2111679899
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2111679178
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2111681447
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2111684880
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2111688348
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2111695428
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2111699396
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2111705378
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2111706856
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2111726416
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2111711829
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2111717556
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2111723220

From epeter at openjdk.org  Wed May 28 12:32:00 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 28 May 2025 12:32:00 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v6]
In-Reply-To: <Di5SQQr4tO4H1VnO-GY1n8JLFtOcH3FID9sGvlRnF1Y=.04e918b6-2efb-426e-9d38-281c08ddc7d7@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <oDd6wkHsAQU3IUV3qCvjtqZ8BSHt7Qq2sx0Yy0Q8onc=.8e7db79c-15a5-4151-ac60-73f114433383@github.com>
 <Di5SQQr4tO4H1VnO-GY1n8JLFtOcH3FID9sGvlRnF1Y=.04e918b6-2efb-426e-9d38-281c08ddc7d7@github.com>
Message-ID: <9u6hJ-WgnHLMaYBa8ViRdpUZY-bI2wOk-TCRKWJJdqk=.b3303f1f-da3b-4c2e-8f0c-a2e16ba9688e@github.com>

On Wed, 28 May 2025 12:14:56 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Refactor the JTReg tests for compare.xor(maskAll)
>>    
>>    Also made a bit change to support pattern `VectorMask.fromLong()`.
>>  - Merge branch 'master' into JDK-8354242
>>  - Refactor code
>>    
>>    Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
>>    optimization, making the code more modular.
>>  - Merge branch 'master' into JDK-8354242
>>  - Update the jtreg test
>>  - Merge branch 'master' into JDK-8354242
>>  - Addressed some review comments
>>    
>>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>>    2. Improve code comments.
>>  - Merge branch 'master' into JDK-8354242
>>  - Merge branch 'master' into JDK-8354242
>>  - 8354242: VectorAPI: combine vector not operation with compare
>>    
>>    This patch optimizes the following patterns:
>>    For integer types:
>>    ```
>>    (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    ```
>>    cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>>    negative comparison of cond.
>>    
>>    For float and double types:
>>    ```
>>    (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    ```
>>    cond can be eq or ne.
>>    
>>    Benchmarks on Nvidia Grace machine with 128-bit SVE2:
>>    With option `-XX:UseSVE=2`:
>>    ```
>>    Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>>    testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>>    testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>>    testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>>    testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>>    testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>>    testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>>    testCompareGEMaskNotByte	ops/s	7907615.16	4...
>
> src/hotspot/share/opto/vectornode.cpp line 2244:
> 
>> 2242:   // BoolTest doesn't support unsigned comparisons.
>> 2243:   BoolTest::mask neg_cond =
>> 2244:       (BoolTest::mask) (((VectorMaskCmpNode*) in1)->get_predicate() ^ 4);
> 
> What is the hard-coded `^ 4` here? This whole line looks like we are looking at internals of the `VectorMaskCmpNode` or its predicate, and we should probably do that in some method there? Or maybe it should be part of the `BoolTest(::mask)` interface?

Also: You now cast `(VectorMaskCmpNode*) in1` twice. Can we not do `as_VectorMaskCmp()`? Or could we at least cast it only once, and then use it as `in1_mask_cmp` instead?

> test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 237:
> 
>> 235:     // Byte tests
>> 236:     @Test
>> 237:     @IR(counts = { IRNode.XOR_V_MASK, "= 0", IRNode.XOR_VB, "= 0" },
> 
> Could you still assert the presence of some other vectors, just to make sure we are indeed getting vectors here?

Not testing for any present vectors makes me a little nervous: what if we just don't get any vectors because inlining fails or something else silly happens?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2111701943
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2111728478

From duke at openjdk.org  Wed May 28 12:52:00 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 28 May 2025 12:52:00 GMT
Subject: Integrated: 8356891: Some code simplifications in BigInteger
In-Reply-To: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
References: <1Q4fwdwWSGGItB2TXG5vESyGDBOkUwp3bVCVLNpifTY=.b74075f8-613a-4da8-9b76-23f35e36f5f4@github.com>
Message-ID: <im_4u_FStYHNVOF62QNeKJ_MQtmOXAaKWGPGAjzoiIU=.a6331291-421a-452b-88f2-3ec288890281@github.com>

On Sat, 10 May 2025 16:41:17 GMT, fabioromano1 <duke at openjdk.org> wrote:

> Some changes in `Biginteger`s' bit operations that increase the code readability and slightly optimize the execution time.

This pull request has now been integrated.

Changeset: c9e6c4d0
Author:    Fabio Romano <fabio19298 at gmail.com>
Committer: Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c9e6c4d0171ff6f419344f9341747c71416d4ec9
Stats:     162 lines in 1 file changed: 9 ins; 57 del; 96 mod

8356891: Some code simplifications in BigInteger

Reviewed-by: rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/25166

From kbarrett at openjdk.org  Wed May 28 13:19:45 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 28 May 2025 13:19:45 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v4]
In-Reply-To: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
Message-ID: <qWbIzDMRYqPdwzKSEJcSx-B4-qe0wZUnJQkslFl3Q6A=.d6425cf5-92b9-475e-9529-e92ac6c7060c@github.com>

> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
> use java.lang.ref.Cleaner.
> 
> This change is algorithmically similar to the two previous versions:
> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
> Bits::reserveMemory(). For both of those versions and this change, a thread
> calls that function and tries to reserve some space. If it fails, then it
> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
> cleaned. If reservation still fails, then it invokes the GC to try to
> deactivate more cleaners for cleaning. After that GC it keeps trying the
> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
> eventually either succeeding or giving up and throwing OOME.
> 
> Retaining that algorithmic approach is one of the goals of this change, since
> it has been successfully in use since JDK 9 (and was originally developed and
> extensively tested in JDK 8).
> 
> The key to this approach is having a way to determine that deactivated
> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
> threads help the reference processor until there was no available work.
> JDK-8156500 waits for the reference processor to quiesce, relying on its
> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
> to do this, which is why this change rolls its own Cleaner-like mechanism from
> the underlying primitives. Like JDK-6857566, this change has waiting threads
> help with cleaning references. This was a potentially undesirable feature of
> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
> became internal-only somewhere around that time as well.) That's not a concern
> here, as the cleaners involved are only from DBB, and we know what they look
> like.
> 
> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
> being done off the reference processing thread, as it may be expensive and
> slow down enqueuing other pending references. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
> 
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there is no available work whil...

Kim Barrett has updated the pull request with a new target base 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:

 - Merge branch 'master' into direct-buffer-cleaner
 - Merge branch 'master' into direct-buffer-cleaner
 - add description of BufferCleaner class
 - exception handling in cleaner for backward consistency
 - detabify
 - move jdk.internal.nio.Cleaner to sun.nio
 - copyrights
 - remove java.nio use of jdk.internal.ref.Cleaner
 - add micros from Shipilev

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25289/files
  - new: https://git.openjdk.org/jdk/pull/25289/files/be3312cb..13bf6c2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25289&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25289&range=02-03

  Stats: 63519 lines in 1098 files changed: 41921 ins; 15397 del; 6201 mod
  Patch: https://git.openjdk.org/jdk/pull/25289.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25289/head:pull/25289

PR: https://git.openjdk.org/jdk/pull/25289

From swen at openjdk.org  Wed May 28 13:39:40 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 28 May 2025 13:39:40 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal [v2]
In-Reply-To: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
Message-ID: <lp1xFhlZNmOPvbkAsqk1nWHA_edVtGbkbryGXZGwjTg=.e824710a-4cac-48ea-a65c-3ddabfa27a22@github.com>

> Some static final arrays of BigInteger and BigDecimal are stable and immutable. We should add `@Stable` to give the optimizer more information

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  bug fix, from @minborg

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25437/files
  - new: https://git.openjdk.org/jdk/pull/25437/files/9b5a430b..11e31614

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25437&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25437&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25437.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25437/head:pull/25437

PR: https://git.openjdk.org/jdk/pull/25437

From lancea at openjdk.org  Wed May 28 14:16:03 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 28 May 2025 14:16:03 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v15]
In-Reply-To: <R2XmRmH21H4_GJDcM6Vb1W5eieDnJL5k7jP3q5jbU6E=.384615d4-266c-49d7-8289-08446f77f190@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <R2XmRmH21H4_GJDcM6Vb1W5eieDnJL5k7jP3q5jbU6E=.384615d4-266c-49d7-8289-08446f77f190@github.com>
Message-ID: <9K-ioqtKQX7ZFka8tIm8IdzSUolbK2ggmO6wSpCLL4s=.9ee58d7e-3f97-464d-a63a-1458dec47170@github.com>

On Tue, 27 May 2025 16:23:47 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Minor tweaks
>  - Assure >0 exit code and fix typos
>  - Validator to take a file, use term JAR file
>  - Mismatched order is considered invalid
>  - Adapt review feedback
>  - Address review feedback
>  - Adjust message based on review feedback
>  - Move all validation into EntryValidator, update the document
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/5b580735...2690e69f

Thank you Henry on your efforts here.

I think you are in good shape overall

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24430#pullrequestreview-2875285938

From alanb at openjdk.org  Wed May 28 14:20:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 May 2025 14:20:51 GMT
Subject: RFR: 8356553 : Incorrect uses of {@link} in
 AbstractQueuedLongSynchronizer and AbstractQueuedSynchronizer
In-Reply-To: <DIYNj468OURl1lR6zApUxLChBOk_auF2nHZIguw0Cts=.a5878b91-7123-45fe-8c83-6bfdedf468b4@github.com>
References: <DIYNj468OURl1lR6zApUxLChBOk_auF2nHZIguw0Cts=.a5878b91-7123-45fe-8c83-6bfdedf468b4@github.com>
Message-ID: <GQFJ6PKNpGdZkzJaNQi-nXAWlWKSifLj1VFqiv_We2g=.eb992915-7d0f-4cf7-b56e-fe528b662928@github.com>

On Tue, 27 May 2025 09:35:51 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> I had to tweak the language a bit to better reflect the intent of the text.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25462#pullrequestreview-2875304114

From jpai at openjdk.org  Wed May 28 14:21:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 May 2025 14:21:58 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v22]
In-Reply-To: <NsUi0hSmRQuCsoexmT1aKMxirrIFmsjpdFQPV_6Dkm4=.58814ece-14ce-435a-a1c1-04a541ce3539@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <QV7xsYuqStjFgX4Mgdh_yKLkJOqQ3WQTt6j4KL9VB_g=.3642a513-7536-46fc-8188-65689ea83d41@github.com>
 <XhhlO7kp9gHxAH8FtiI7By4_KixYmqbDr6kKCbTmtXE=.afcdff58-ff7f-4ae8-9e2a-fb7153732125@github.com>
 <OFzwCUP8551ajdWuUCOGE3LM3aZ-niEocXo7couS1m0=.5113cf96-1d25-4efc-9c23-930b72330205@github.com>
 <uJD3_543RevQ83bhjZPKw4xLAHjPayk6TaF9_cbtDis=.4d22f0a0-250b-40e3-936c-fe45a6e31dd4@github.com>
 <8SJl_mDv3MuJGgTfW3pc4adoVxHpbwVyPEgD0n2nguM=.d9845fcc-cf54-46e8-b2af-a2ce16f4b991@github.com>
 <NsUi0hSmRQuCsoexmT1aKMxirrIFmsjpdFQPV_6Dkm4=.58814ece-14ce-435a-a1c1-04a541ce3539@github.com>
Message-ID: <djNHtnIx848cxAKd2PvAYJFxPqlJY6E4ayArLM1yUEE=.0627f5e8-f150-4e9d-9d84-eaece0df358c@github.com>

On Tue, 20 May 2025 17:32:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I see this has been changed to  "then some characters, but not all" but it doesn't flow very well. The original sentence, which was copied/modified from InputStream.readAllBytes, is much cleaner and I think I would prefer to go back to that.  Maybe Jai's issue could be address by dropping the first comma from the sentence?
>
> In 0880af2 reverted previous commit then removed first comma from the modified sentence.

Hello Brian, the updated text looks OK to me. It still takes me a second read to understand what it says and I think it due to the sentence reading like an instruction to implementations that they aren't allowed to throw I/O errors before any characters have been read from the stream:

> If an I/O error occurs reading from the stream then it may do so after some ...

But there's a precedence for this text (in the API docs of `java.nio.file.Files`) and others favour the current proposed/updated form, so it's OK with me to go ahead with this text.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2112043612

From vklang at openjdk.org  Wed May 28 14:26:04 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 28 May 2025 14:26:04 GMT
Subject: Integrated: 8356553 : Incorrect uses of {@link} in
 AbstractQueuedLongSynchronizer and AbstractQueuedSynchronizer
In-Reply-To: <DIYNj468OURl1lR6zApUxLChBOk_auF2nHZIguw0Cts=.a5878b91-7123-45fe-8c83-6bfdedf468b4@github.com>
References: <DIYNj468OURl1lR6zApUxLChBOk_auF2nHZIguw0Cts=.a5878b91-7123-45fe-8c83-6bfdedf468b4@github.com>
Message-ID: <UAI3X-6bMv0oofp_yMuYmNVeuRPXk9j0J4cwnDVfrQI=.184c7a4e-6749-42cf-9cd1-55c26d0bc073@github.com>

On Tue, 27 May 2025 09:35:51 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> I had to tweak the language a bit to better reflect the intent of the text.

This pull request has now been integrated.

Changeset: 18285fc1
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18285fc136e1a892ab54a705c1fa82e91325b06a
Stats:     24 lines in 2 files changed: 1 ins; 0 del; 23 mod

8356553: Incorrect uses of {@link} in AbstractQueuedLongSynchronizer and AbstractQueuedSynchronizer

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25462

From jpai at openjdk.org  Wed May 28 14:28:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 May 2025 14:28:07 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v26]
In-Reply-To: <YzGSrFW7z3GSmzv2Pvmdq6PEIwR2KchNPd-X6ZUhmzs=.e218db04-f9bc-4473-a25f-5ef1e13f1358@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <YzGSrFW7z3GSmzv2Pvmdq6PEIwR2KchNPd-X6ZUhmzs=.e218db04-f9bc-4473-a25f-5ef1e13f1358@github.com>
Message-ID: <w399uzTdShVCNlKJ6OfNZj1qUESmq7JE19efqqNXz2o=.7cacdbf4-c5ed-4108-bba9-13189266f536@github.com>

On Fri, 23 May 2025 18:44:42 GMT, Brian Burkhalter <bpb at openjdk.org> 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: "input reader specific" -> "reader specific"

This looks good to me. I just have a question about the test, which I've added inline as a review comment.

test/jdk/java/io/Reader/ReadAll.java line 54:

> 52: public class ReadAll {
> 53:     private static final String PHRASE =
> 54:         "Ange plein de gaiet?, connaissez-vous l'angoisse";

Would it be useful to have this (or some other) phrase contain some newline characters and also some whitespaces between a pair of newline characters? That then can exercise the case where the input being read by a `Reader` would consist of empty lines and lines with just whitespace characters. The way the inputs lines are constructed in `setup()`, it's possible that even in current form that scenario might get exercised but it's hard to be sure given the `Random` nature of that content generation.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24728#pullrequestreview-2875329630
PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2112052404

From henryjen at openjdk.org  Wed May 28 14:53:39 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 28 May 2025 14:53:39 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v16]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <otkR4SEwHoevAGCQ6Bfg25tIq40iHP2V9s_Pvj6S-Sk=.2179e6a0-8cb9-4cd9-b942-8f2262563401@github.com>

> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.

Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:

 - Merge remote-tracking branch 'openjdk/master' into open
 - Fix typo
 - Merge remote-tracking branch 'openjdk/master' into open
 - Merge remote-tracking branch 'openjdk/master' into open
 - Minor tweaks
 - Assure >0 exit code and fix typos
 - Validator to take a file, use term JAR file
 - Mismatched order is considered invalid
 - Adapt review feedback
 - Address review feedback
 - ... and 9 more: https://git.openjdk.org/jdk/compare/55443096...a0ebb6d6

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/2690e69f..a0ebb6d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=14-15

  Stats: 2813 lines in 126 files changed: 1269 ins; 1101 del; 443 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 lancea at openjdk.org  Wed May 28 15:22:58 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 28 May 2025 15:22:58 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v16]
In-Reply-To: <otkR4SEwHoevAGCQ6Bfg25tIq40iHP2V9s_Pvj6S-Sk=.2179e6a0-8cb9-4cd9-b942-8f2262563401@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <otkR4SEwHoevAGCQ6Bfg25tIq40iHP2V9s_Pvj6S-Sk=.2179e6a0-8cb9-4cd9-b942-8f2262563401@github.com>
Message-ID: <MgGgWNeaNBRkGMTDMVPzM4dssIuhAsinaZ7nha8T794=.e1c9fc18-cd7c-49de-8dcb-ff81645eedb2@github.com>

On Wed, 28 May 2025 14:53:39 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Fix typo
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Minor tweaks
>  - Assure >0 exit code and fix typos
>  - Validator to take a file, use term JAR file
>  - Mismatched order is considered invalid
>  - Adapt review feedback
>  - Address review feedback
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/3a5be830...a0ebb6d6

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24430#pullrequestreview-2875523868

From lmesnik at openjdk.org  Wed May 28 15:24:03 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 28 May 2025 15:24:03 GMT
Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with
 exitValue = 1 [v3]
In-Reply-To: <g0uxm2yAHhLNZFmAEdZKlCGkmr56eBW4MS8bE8nxc8A=.ecc40181-2467-4506-939e-632afd297b1e@github.com>
References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
 <g0uxm2yAHhLNZFmAEdZKlCGkmr56eBW4MS8bE8nxc8A=.ecc40181-2467-4506-939e-632afd297b1e@github.com>
Message-ID: <yl3OE6uSZ9EdepYmJu_Xa1U-ggIAEdZ_FyGjjV5ljBg=.85078e2c-601b-4d57-bde1-90171fa06e00@github.com>

On Fri, 23 May 2025 04:33:36 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

>> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1
>
> PAWAN CHAWDHARY has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into 8354475
>  - Update TestDockerMemoryMetricsSubgroup.java
>    
>    remove extra space
>  - 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24930#pullrequestreview-2875529614

From lancea at openjdk.org  Wed May 28 15:26:03 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 28 May 2025 15:26:03 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v15]
In-Reply-To: <bKpaZY60SBN77rtuHLpr9Lj9ZyeoyAJ3RoQjtnrWuIQ=.8c21d06d-0f6e-4c2c-91e1-3dbc6c688d6c@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <bKpaZY60SBN77rtuHLpr9Lj9ZyeoyAJ3RoQjtnrWuIQ=.8c21d06d-0f6e-4c2c-91e1-3dbc6c688d6c@github.com>
Message-ID: <TWCADvSgndCbKXn7BlNbA6dooIn9ZRdJExVCKgTxNXo=.bf441383-91e2-40f9-b4fc-d652bf8852d6@github.com>

On Tue, 27 May 2025 19:21:45 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplifying parsing of version parameter.

I think you are in good shape with your last set of changes David

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25178#pullrequestreview-2875534085

From duke at openjdk.org  Wed May 28 15:26:59 2025
From: duke at openjdk.org (duke)
Date: Wed, 28 May 2025 15:26:59 GMT
Subject: RFR: 8334742: Change java.time month/day field types to 'byte'
 [v2]
In-Reply-To: <AUY5jIW8j9Su5dADRCUul9pql3xc1DtiNdrDPtCywC4=.7c91f6fd-db4b-4d87-8d89-3a022549330a@github.com>
References: <AZ0_rhZGLcX4I7NuxtGcP1pVzGAr7KXu8FObV6kMxZ8=.2b7d3dc8-1cf8-40d9-bef2-8164282e02e8@github.com>
 <AUY5jIW8j9Su5dADRCUul9pql3xc1DtiNdrDPtCywC4=.7c91f6fd-db4b-4d87-8d89-3a022549330a@github.com>
Message-ID: <s7wJOMR-ScTN0jARROPecVvmZBcvQyorY0AfO8-AEwg=.ba32b193-eaa6-4087-a183-cc178b563fde@github.com>

On Wed, 30 Apr 2025 20:38:59 GMT, Gautham Krishnan <duke at openjdk.org> wrote:

>> In the following classes, month and day values are stored in fields of type 'int' or 'short'. The range of allowed values is small enough that the type can be 'byte' instead.
>> 
>> java.time.YearMonth
>> java.time.MonthDay
>> java.time.LocalDate
>> java.time.chono.HijrahDate
>> 
>> Refactoring the type will give the JVM a little more layout flexibility, and will be especially useful when these classes become value classes.
>
> Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright header

@gauthamkrishnanibm 
Your change (at version 148c3834c7e80d23d4d61be2829a2648bae1f121) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24975#issuecomment-2916751427

From bpb at openjdk.org  Wed May 28 15:27:04 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 28 May 2025 15:27:04 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v26]
In-Reply-To: <w399uzTdShVCNlKJ6OfNZj1qUESmq7JE19efqqNXz2o=.7cacdbf4-c5ed-4108-bba9-13189266f536@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <YzGSrFW7z3GSmzv2Pvmdq6PEIwR2KchNPd-X6ZUhmzs=.e218db04-f9bc-4473-a25f-5ef1e13f1358@github.com>
 <w399uzTdShVCNlKJ6OfNZj1qUESmq7JE19efqqNXz2o=.7cacdbf4-c5ed-4108-bba9-13189266f536@github.com>
Message-ID: <2K1rUZ8WwbJ_qNxI6y416I5jKG4GgBkSPM4lKhrweC0=.d7cae3c0-d841-4c38-9108-649a4d8ffae9@github.com>

On Wed, 28 May 2025 14:23:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354724: "input reader specific" -> "reader specific"
>
> test/jdk/java/io/Reader/ReadAll.java line 54:
> 
>> 52: public class ReadAll {
>> 53:     private static final String PHRASE =
>> 54:         "Ange plein de gaiet?, connaissez-vous l'angoisse";
> 
> Would it be useful to have this (or some other) phrase contain some newline characters and also some whitespaces between a pair of newline characters? That then can exercise the case where the input being read by a `Reader` would consist of empty lines and lines with just whitespace characters. The way the inputs lines are constructed in `setup()`, it's possible that even in current form that scenario might get exercised but it's hard to be sure given the `Random` nature of that content generation.

Thanks for the suggestion. I was thinking of another enhancement of the test anyway and can include this idea later in another request.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2112185060

From alanb at openjdk.org  Wed May 28 15:36:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 May 2025 15:36:58 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v26]
In-Reply-To: <YzGSrFW7z3GSmzv2Pvmdq6PEIwR2KchNPd-X6ZUhmzs=.e218db04-f9bc-4473-a25f-5ef1e13f1358@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <YzGSrFW7z3GSmzv2Pvmdq6PEIwR2KchNPd-X6ZUhmzs=.e218db04-f9bc-4473-a25f-5ef1e13f1358@github.com>
Message-ID: <NbkKl6FKTzyHyhlKZO7sww1krEBEii91rAyxmbM0ROI=.aec33b64-120e-4c2e-817d-381ecf30e03c@github.com>

On Fri, 23 May 2025 18:44:42 GMT, Brian Burkhalter <bpb at openjdk.org> 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: "input reader specific" -> "reader specific"

The two methods look good.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24728#pullrequestreview-2875571116

From duke at openjdk.org  Wed May 28 15:40:57 2025
From: duke at openjdk.org (Gautham Krishnan)
Date: Wed, 28 May 2025 15:40:57 GMT
Subject: Integrated: 8334742: Change java.time month/day field types to 'byte'
In-Reply-To: <AZ0_rhZGLcX4I7NuxtGcP1pVzGAr7KXu8FObV6kMxZ8=.2b7d3dc8-1cf8-40d9-bef2-8164282e02e8@github.com>
References: <AZ0_rhZGLcX4I7NuxtGcP1pVzGAr7KXu8FObV6kMxZ8=.2b7d3dc8-1cf8-40d9-bef2-8164282e02e8@github.com>
Message-ID: <17YnNT2fOIDp7izaRgC1YcksZ_NYp7CwT6dhNbuwnZY=.a5ed189c-f7ef-43c3-ad5c-1241b516088d@github.com>

On Wed, 30 Apr 2025 20:30:59 GMT, Gautham Krishnan <duke at openjdk.org> wrote:

> In the following classes, month and day values are stored in fields of type 'int' or 'short'. The range of allowed values is small enough that the type can be 'byte' instead.
> 
> java.time.YearMonth
> java.time.MonthDay
> java.time.LocalDate
> java.time.chono.HijrahDate
> 
> Refactoring the type will give the JVM a little more layout flexibility, and will be especially useful when these classes become value classes.

This pull request has now been integrated.

Changeset: 4ced4e73
Author:    gauthamkrishnanibm <gautham.k at ibm.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ced4e73fc0a517df826860839681004bb67e624
Stats:     17 lines in 4 files changed: 0 ins; 0 del; 17 mod

8334742: Change java.time month/day field types to 'byte'

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/24975

From jpai at openjdk.org  Wed May 28 15:44:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 May 2025 15:44:57 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v16]
In-Reply-To: <otkR4SEwHoevAGCQ6Bfg25tIq40iHP2V9s_Pvj6S-Sk=.2179e6a0-8cb9-4cd9-b942-8f2262563401@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <otkR4SEwHoevAGCQ6Bfg25tIq40iHP2V9s_Pvj6S-Sk=.2179e6a0-8cb9-4cd9-b942-8f2262563401@github.com>
Message-ID: <02AMYQvFlloCH8I4wcpHunxObA15KhVI9N4OHTtgczQ=.80e2abab-931d-4596-aa3f-a4892c3b9330@github.com>

On Wed, 28 May 2025 14:53:39 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Fix typo
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Minor tweaks
>  - Assure >0 exit code and fix typos
>  - Validator to take a file, use term JAR file
>  - Mismatched order is considered invalid
>  - Adapt review feedback
>  - Address review feedback
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/950811e8...a0ebb6d6

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24430#pullrequestreview-2875596948

From jpai at openjdk.org  Wed May 28 15:46:05 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 May 2025 15:46:05 GMT
Subject: RFR: 8354724: Methods in java.io.Reader to read all characters and
 all lines [v26]
In-Reply-To: <2K1rUZ8WwbJ_qNxI6y416I5jKG4GgBkSPM4lKhrweC0=.d7cae3c0-d841-4c38-9108-649a4d8ffae9@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <YzGSrFW7z3GSmzv2Pvmdq6PEIwR2KchNPd-X6ZUhmzs=.e218db04-f9bc-4473-a25f-5ef1e13f1358@github.com>
 <w399uzTdShVCNlKJ6OfNZj1qUESmq7JE19efqqNXz2o=.7cacdbf4-c5ed-4108-bba9-13189266f536@github.com>
 <2K1rUZ8WwbJ_qNxI6y416I5jKG4GgBkSPM4lKhrweC0=.d7cae3c0-d841-4c38-9108-649a4d8ffae9@github.com>
Message-ID: <wNs13dpUxqQJH5dnOjEGbUvmDPOVpkhODTC037PZN2I=.30b6f7e6-5c37-444c-ad3d-ca5ffdefb26e@github.com>

On Wed, 28 May 2025 15:23:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/io/Reader/ReadAll.java line 54:
>> 
>>> 52: public class ReadAll {
>>> 53:     private static final String PHRASE =
>>> 54:         "Ange plein de gaiet?, connaissez-vous l'angoisse";
>> 
>> Would it be useful to have this (or some other) phrase contain some newline characters and also some whitespaces between a pair of newline characters? That then can exercise the case where the input being read by a `Reader` would consist of empty lines and lines with just whitespace characters. The way the inputs lines are constructed in `setup()`, it's possible that even in current form that scenario might get exercised but it's hard to be sure given the `Random` nature of that content generation.
>
> Thanks for the suggestion. I was thinking of another enhancement of the test anyway and can include this idea later in another request.

That sounds fine to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2112224033

From duke at openjdk.org  Wed May 28 16:02:56 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Wed, 28 May 2025 16:02:56 GMT
Subject: Integrated: 8354475: TestDockerMemoryMetricsSubgroup.java fails with
 exitValue = 1
In-Reply-To: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
Message-ID: <p7Y4qVlvRmJSi8Hp8C41Y56om-umXo98sgluEUpszwo=.c9ffeb7f-4ae1-413e-b1b6-822c8c950242@github.com>

On Mon, 28 Apr 2025 15:51:44 GMT, PAWAN CHAWDHARY <duke at openjdk.org> wrote:

> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1

This pull request has now been integrated.

Changeset: e579cca6
Author:    PAWAN CHAWDHARY <pawan.chawdhary at oracle.com>
Committer: Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e579cca619147aa51563dc00f374e02db49e1238
Stats:     18 lines in 1 file changed: 18 ins; 0 del; 0 mod

8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1

Reviewed-by: lmesnik, mseledtsov

-------------

PR: https://git.openjdk.org/jdk/pull/24930

From almatvee at openjdk.org  Wed May 28 16:04:52 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 28 May 2025 16:04:52 GMT
Subject: RFR: 8357930: Amendment for JDK-8333664 [v2]
In-Reply-To: <9E__aQfmH2Ke-y0N-tWZEwoOpnNs1yyShOb5-9GggLU=.8639e8b4-88ed-4466-9a6e-e621bd442bab@github.com>
References: <ILdlyOHPrjsY0TZI5FGDdxf2Iecwvqq2M5w8oha3W8I=.d1258351-347d-4f4a-807d-50b72c3b82ca@github.com>
 <9E__aQfmH2Ke-y0N-tWZEwoOpnNs1yyShOb5-9GggLU=.8639e8b4-88ed-4466-9a6e-e621bd442bab@github.com>
Message-ID: <kUdSt5WDsg81Y27sxwFHHsNthRUwdPuP4ck8_8sxLxE=.930c6c35-3c94-47fb-96ef-1415eb5899fa@github.com>

On Wed, 28 May 2025 12:24:48 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Extract ExternalApplication interface from AppImageFile and add it to the model;
>>  - Move LauncherData.ModuleInfo class to the top level;
>>  - Add parent interface BundleSpec for Application and Package interfaces in the model;
>>  - Merge PackageWriter and ApplicationWriter into BundleCreator interface;
>>  - Add BundlingEnvironment, and BundlingOperation interfaces to the model;
>>  - Remove LauncherModularStartupInfoMixin.modulePath(). It is not being used;
>>  - Remove CollectionUtils.toSet();
>> 
>> Additionally, fix modifier order in TokenReplace.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25477#pullrequestreview-2875656950

From asemenyuk at openjdk.org  Wed May 28 16:22:02 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 28 May 2025 16:22:02 GMT
Subject: Integrated: 8357930: Amendment for JDK-8333664
In-Reply-To: <ILdlyOHPrjsY0TZI5FGDdxf2Iecwvqq2M5w8oha3W8I=.d1258351-347d-4f4a-807d-50b72c3b82ca@github.com>
References: <ILdlyOHPrjsY0TZI5FGDdxf2Iecwvqq2M5w8oha3W8I=.d1258351-347d-4f4a-807d-50b72c3b82ca@github.com>
Message-ID: <2PCVciSjcwuXfkGyEvvf0pl0gBBryFKk6P36PCah91I=.7df3c4b8-ac4a-4afd-baca-f9d340ea7cd5@github.com>

On Wed, 28 May 2025 02:52:57 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Extract ExternalApplication interface from AppImageFile and add it to the model;
>  - Move LauncherData.ModuleInfo class to the top level;
>  - Add parent interface BundleSpec for Application and Package interfaces in the model;
>  - Merge PackageWriter and ApplicationWriter into BundleCreator interface;
>  - Add BundlingEnvironment, and BundlingOperation interfaces to the model;
>  - Remove LauncherModularStartupInfoMixin.modulePath(). It is not being used;
>  - Remove CollectionUtils.toSet();
> 
> Additionally, fix modifier order in TokenReplace.

This pull request has now been integrated.

Changeset: 8949c074
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8949c07484bd2ea0ab1e5207d45e6ef3694b7428
Stats:     617 lines in 22 files changed: 342 ins; 234 del; 41 mod

8357930: Amendment for JDK-8333664

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/25477

From naoto at openjdk.org  Wed May 28 16:27:00 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 28 May 2025 16:27:00 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
Message-ID: <o98nfuStWFzGnsYs_OWnUtKShbwt_umJhvLFOy8b2us=.af181d42-02bf-4faf-bbde-030337376418@github.com>

On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects wording change suggestions

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2916925800

From naoto at openjdk.org  Wed May 28 16:27:02 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 28 May 2025 16:27:02 GMT
Subject: Integrated: 8356985: Use "stdin.encoding" in Console's read*() methods
In-Reply-To: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
Message-ID: <XG7OepWrg1ZJ-D3MrapN_1vqY2ja4cKYg0-pvsUKOK8=.f45e5c22-c5c6-4041-92b5-080c833bfcb7@github.com>

On Fri, 16 May 2025 18:11:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.

This pull request has now been integrated.

Changeset: b2a61a99
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b2a61a9972493d67d0f1a9f3f529c11e45838d5b
Stats:     301 lines in 11 files changed: 256 ins; 8 del; 37 mod

8356985: Use "stdin.encoding" in Console's read*() methods

Reviewed-by: jlu, smarks, alanb, vyazici

-------------

PR: https://git.openjdk.org/jdk/pull/25271

From iklam at openjdk.org  Wed May 28 16:47:46 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 28 May 2025 16:47:46 GMT
Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics [v13]
In-Reply-To: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
Message-ID: <SMo8Nycqs0pKI88YalpC9yM5golTC3K0Gh_YaFx3g9E=.3a758049-be90-40b6-b0c0-91f79de3f677@github.com>

> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
> 
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
> - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
> 
> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
> 
> Examples:
> 
> 
> # Create an AOT cache with a single command:
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> Hello World
> Temporary AOTConfiguration recorded: foo.aot.config
> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
> [...]
> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
> AOTCache creation is complete: foo.aot 10240000 bytes
> 
> # Create logging file for the AOT cache assembly phase
> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> 
> 
> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
 - Fixed merge
 - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
 - @erikj79 comments -- makefile indentation
 - Fixed merge
 - @erikj79 comments
 - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022
 - @vnkozlov comments
 - added info about JTREG/AOT_JDK testing
 - fixed whitespace
 - ... and 19 more: https://git.openjdk.org/jdk/compare/b2a61a99...a8ce491e

-------------

Changes: https://git.openjdk.org/jdk/pull/24942/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=12
  Stats: 2107 lines in 26 files changed: 1564 ins; 459 del; 84 mod
  Patch: https://git.openjdk.org/jdk/pull/24942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942

PR: https://git.openjdk.org/jdk/pull/24942

From jlu at openjdk.org  Wed May 28 17:04:07 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 28 May 2025 17:04:07 GMT
Subject: RFR: 8348328: Update IANA Language Subtag Registry to Version
 2025-05-15
Message-ID: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>

Please review this PR which updates the language subtag registry to Version 2025-05-15.

LanguageSubtagRegistryTest.java was updated with the preferred-values: `hnm`, `eko`, `luh`,`sjc`, `sqm`. A small change was also made to the test to improve the output as well.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/25503/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25503&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348328
  Stats: 143 lines in 2 files changed: 135 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25503.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25503/head:pull/25503

PR: https://git.openjdk.org/jdk/pull/25503

From cushon at openjdk.org  Wed May 28 17:13:41 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 28 May 2025 17:13:41 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v11]
In-Reply-To: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
Message-ID: <qlYT62TEeCz9YVp02zeuJCO30kAZyzBgV2ENjURIJrw=.44ab01cb-9fe3-45a4-af51-6468a0f625ab@github.com>

> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.

Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Update test/jdk/java/util/Collection/MOAT.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - Update copyright year
   
   and add the bug number to the modified test
 - Update unmodifiable map javadoc
 - Also throw UOE for mutators on keySet() and values()
   
   and add more test coverage to MOAT.
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - ... and 5 more: https://git.openjdk.org/jdk/compare/b2a61a99...785f728d

-------------

Changes: https://git.openjdk.org/jdk/pull/18522/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=10
  Stats: 86 lines in 3 files changed: 80 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18522/head:pull/18522

PR: https://git.openjdk.org/jdk/pull/18522

From duke at openjdk.org  Wed May 28 17:13:54 2025
From: duke at openjdk.org (kieran-farrell)
Date: Wed, 28 May 2025 17:13:54 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v3]
In-Reply-To: <lzUXzFFqnkDwu6nx8GudrrkgihJ9bYECt0gqbWSPOgg=.7f6488d7-5c7e-423a-879a-3f125245440c@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <Jm4ATGoFWP2a8HSBuwAglmdQS5fcBKBxt7TOklUQRjk=.b47ef4c7-26cd-4603-a074-76be89fa898c@github.com>
 <D2OwQlifY_F57s5ntpnVSYAMxZ8lacAyv03fME6O3ZM=.524387cc-ad76-4261-9269-8e2f08aeb6fb@github.com>
 <my9K8CLlrz0magIzlGgxShOw4oG1D7khLcG0KB2C3aU=.50c780c7-2f35-425b-aa19-00905143e208@github.com>
 <lzUXzFFqnkDwu6nx8GudrrkgihJ9bYECt0gqbWSPOgg=.7f6488d7-5c7e-423a-879a-3f125245440c@github.com>
Message-ID: <x-kg_zhXOYwXjNAnWysWQtxPWl8a2c-sOZQbhzyYBss=.3616b256-3dfe-40e1-ab16-a96cc5420069@github.com>

On Tue, 27 May 2025 21:59:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I'd say "create" instead of "retrieve" in the first line comment. (Though that word is used in the other static factories).
>> 
>> The "sub-millisecond precision" can't be relied upon. Its the precision that gives the impression that it can be added to the millisecond value and get an exact time. But the nano-second value is read from a different clock and the bits being used from it may wrap-around in the time between the reads of the clocks.
>> The second description ("derived from") is makes fewer promises than the first-line comment.
>> An application should not use them for any purpose other than random.  And for that the buffer already contains random bytes.
>> 
>> An alternative is to capture the MS time and the nano-time on first use to compute an offset and then use only the nano-time plus/minus the offset to create the version 7 UUIDs.
>
> The `timestamp` method may mislead an app developer thinking its the time from the version 7 timestamp.
> The first-line comment might make it more obvious if it says:
> `The timestamp value associated with a version 1 UUID.`
> 
> The Unix Epoch time would be easier to use if a method was added to return it.
> `long UnixEpochTimeNanos()`   (name subject to bike-shedding).
> And throwing if it was not version 7.

The first 48 bits need to be from the unix epoch time stamp in ms only to remain complaint. If I understand correctly, to be able to guarantee that the nsBits are actually time orderable, System.nanoTime() would have to be pinned to a point where System.currentTimeMillis() increments by 1ms (which doesnt seem possible). Otherwise any offset could be at any arbitrary point in a given millisecond and nsBits would wrap around from that.

I think the options are to either use the random only approach with ms precision or an guaranteed monotonic counter based approach and take the hit on performance.

I agree with updating to "create" from "retrieve" on the first line comment and also with the method name change to avoid confusion with UUIDv1, however to either unixEpochTimeNanos() or unixEpochTimeMillis() or otherwise depending on which implementation we settle on.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2112383140

From henryjen at openjdk.org  Wed May 28 17:26:01 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 28 May 2025 17:26:01 GMT
Subject: Integrated: 8345431: Improve jar --validate to detect duplicate or
 invalid entries
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <5syKoPg8rti1oBn5bVi8Um_6jZ493GNp6QudvhhhWwM=.6fa9cfbd-d91e-49c3-b6f5-1d7eebd84435@github.com>

On Fri, 4 Apr 2025 00:39:04 GMT, Henry Jen <henryjen at openjdk.org> 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.

This pull request has now been integrated.

Changeset: cd052c72
Author:    Henry Jen <henryjen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd052c72cdb62186e66c1d2ecf9216f3df61b242
Stats:     599 lines in 5 files changed: 584 ins; 3 del; 12 mod

8345431: Improve jar --validate to detect duplicate or invalid entries

Reviewed-by: lancea, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/24430

From yujige at gmail.com  Wed May 28 17:45:58 2025
From: yujige at gmail.com (Jige Yu)
Date: Wed, 28 May 2025 10:45:58 -0700
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <MW4PR10MB577459221CD425EFD5686426FF67A@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774265B8728DA0641C48DBAFF152@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYut_G7TRSTr0hPVuxWAvJQ+25JyPBWB7PEtntamWq-E_A@mail.gmail.com>
 <MW4PR10MB5774AB9B6544E949383187F3FFEC2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvyRxcWv65v4+8KcRHys=jkbpfKZ3eK3ijTGKXR1UxNnA@mail.gmail.com>
 <MW4PR10MB5774986199F9EDF854A6D390FFEE2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtE-xwb9tBhjPvObeG9_03nXh1aRA10sO7ibEGkQavntw@mail.gmail.com>
 <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtAUfyUHOdmSeZ2Azny=RJU63FQozY2NxpYu-4xQYCRkA@mail.gmail.com>
 <MW4PR10MB5774B089653C902899FEBEAFFFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB5774BB2B60EE5A1F4B1A7306FFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvxZ0gpHJXW0ctuHwEGwfStfjmLvwV1CgSWrr8438rWPA@mail.gmail.com>
 <MW4PR10MB5774EF4D4316B5BE46B29A0EFFF12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYsJyHeEs1fc4DRTZKwDO_U4Pyjv45BQ5fvr6VbboaVCTQ@mail.gmail.com>
 <MW4PR10MB57743363CCA3306B316F3EEDFF65A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYuPzVW+VHt_MzOrXW93iNv0A03JFSCV+yawCFeaLm=HsA@mail.gmail.com>
 <CAKD1RYtpahV4766wNodvcrSGFqJ6ereG1fUJFi-yEviOpLcb=Q@mail.gmail.com>
 <MW4PR10MB577459221CD425EFD5686426FF67A@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAKD1RYscAh46O77zw=S68DefM9Aonnn7DjCB_8YJ-eWTKSpNDQ@mail.gmail.com>

17.2.4 is specifically about the Object wait()/notify() API, yeah?

I've always had this confusion in my mind that I couldn't find an
authoritative source for: what was the point of checked
InterruptedException?

My naive observation has been two fold:

   1. In most cases, when possible, applications declare "throws IE" and
   let it propagate all the way up the call stack. This works exactly the same
   as if IE were unchecked.
   2. When the application is cornered into a Runnable, Function and cannot
   "throws IE", it has to catch(IE),  remember to re-interrupt the thread, and
   wrap in an unchecked. Except *it often forgets to re-interrupt*.

At the lowest level concurrent primitives (wait(), notify(), Semaphore), I
presume IE being an integral part of the API contract.

But at mid-level APIs (Future, mapConcurrent()), or high-level
applications, I've always been at a loss on why we needed the checked IE in
the first place.

IE used to happen when someone calls Future.cancel(true). Now with
structured concurrency, it can also be caused by a sibling task failing and
fail-fast.

But aside from the extra ceremony and the extra room for error (forgetting
to reinterrupt), what do we get from it? I was asking ChatGPT about
real-life scenarios where specifically catching and handling IE is
necessary but all ChatGPT gave me was cases where the code has to
re-interrupt, which would have been unnecessary if IE were unchecked and
didn't clear the interruption bit.

Would appreciate a pointer to code or authoritative discussion about this
matter.

Sorry for the tangent!


On Wed, May 28, 2025 at 1:03?AM Viktor Klang <viktor.klang at oracle.com>
wrote:

> It would seem to require a change to the Java Language Specification
> section 17.2.4
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Wednesday, 28 May 2025 00:35
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> That said, I'm still curious. Have you considered propagating
> cancellation, re-interrupting the current thread, and then throwing an
> unchecked exception upon interruption? It's going to be the most
> fail-fast-compatible.
>
> catch (IE interrupted) {
>   cancel all pending futures
>   Thread.currentThread().interrupt();
>   throw new UncheckedInterruptedException();
> }
>
> What are the concerns against such practice?
>
>
>
>
>
> On Mon, May 26, 2025 at 8:31?AM Jige Yu <yujige at gmail.com> wrote:
>
> Yeah, I think I missed the task cancellation and the joining part.
>
> When the mapConcurrent() thread is interrupted, it propagates the
> cancellation to the child threads.
>
> And if any of the children threads (running the user-provided Function)
> receives that cancellation, it will still need to catch it and handle
> interruption.
>
> That means the interruption isn't swallowed. If the user code wants to
> abort, they can always just throw an unchecked exception and catch it from
> the caller of mapConcurrent().
>
> That should do for most of the IO type work.
>
> This makes sense.
>
>
>
> On Mon, May 26, 2025 at 12:30?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Yes, the updated Gatherers.mapConcurrent will continue under interruption
> until done, and then restore the interrupt status of the calling thread.
>
> It cannot (reasonably) do anything else?if it were to throw
> InterruptedException, it couldn't since that is a checked exception and
> there's no tracking of checked exceptions throughout a Stream, and that is
> the specified behavior to handle thread interrupts (i.e. clear flag and
> throw InterruptedException, which is not possible in this case; or, make
> sure that interrupt status is maintained, which is possible in this case.
>
> I have given it some more thought in the meantime, but I haven't arrived
> in something more satisfactory than that, yet.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 26 May 2025 03:07
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Thanks Viktor!
>
> Sorry, I was giving myself more time to read the code, but then I lost
> track.
>
> If I'm reading the code right, the current behavior is that if the current
> thread is interrupted, the mapConcurrent() would suppress the interruption
> until all elements are processed? (It will then restore the interruption
> bit)
>
> Doesn't this break fail fast?
>
> For example, I may have a mapConcurrent() called from within structured
> concurrency, and that fans out to two operations:
> ?
> scope.fork(() -> doA());
> scope.fork(() -> doB());  // calls mapConcurrent() internally
> scope.join().throwIfFailed();
>
> If doA() fails, doB() will be cancelled (thread interrupted).
>
> If mapConcurrent() ignores the interruption, and if doB has a long list to
> process, it'll continue to consume system resources even when the caller no
> longer needs the results, no?
>
>
> On Fri, Feb 7, 2025 at 2:16?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> >Sorry, did the PR stop using Semaphore?
>
> No, not that PR. See:
> https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e__;!!ACWV5N9M2RV99hQ!OKfWrvJEDCkiHcT5b4a6gfeomZzZeq3jv6ir2vf2I5WWIhujtb-by_VuQFaAPDIuAA0qAwpTUjllXMPF$>
>
> The problem with interruption under parallel evaluation is that there is
> no general support for propagation of interruption in CountedCompleters.
> Adding support for such in (at least) GathererOp needs further study before
> contemplating making any changes to mapConcurrent()'s interruption policy.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
>
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Thursday, 6 February 2025 17:04
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Sorry, did the PR stop using Semaphore?
>
> I had naively thought that mapConcurrent() will keep a buffer of Future of
> all currently-running concurrent tasks (it can be a ConcurrentMap<TaskKey,
> Future> if we don't have to ensure FIFO).
>
> Upon interruption, the main thread can call .cancel(true) on all pending
> Futures; optionally join with the VTs (if we need to block until all VTs
> exit); then propagate exception.
>
> Upon completion, each task just removes itself from the ConcurrentMap.
>
> Just in case it adds anything.
>
>
>
> On Thu, Feb 6, 2025 at 6:47?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> After some more investigation it seems tractable to propagate interruption
> of the caller in sequential mode, but parallel mode will require much
> bigger considerations.
>
> I made a comment to that effect on the JBS issue:
> https://bugs.openjdk.org/browse/JDK-8349462?focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Viktor Klang <viktor.klang at oracle.com>
> *Sent:* Thursday, 6 February 2025 11:51
> *To:* Jige Yu <yujige at gmail.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> I think alignment in behavior between parallel Stream and mapConcurrent in
> terms of how interruptions are handled is a possible path forward.
>
> I decided to close the PR for now as I realized my parallel Stream example
> had misled me regarding its exception throwing, so I'll need to go back and
> refine the solution.
>
> It still seems solvable though.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Wednesday, 5 February 2025 19:20
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Oh good call!
>
> I forgot to check what parallel streams do upon interruption (didn't think
> they do any blocking calls, but at least the main thread must block).
>
> On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi Jige,
>
> I opened an issue to track the concern, and I have proposed a change which
> seems to align well with how parallel streams behave under caller thread
> interruption.
>
> I've opened the following PR for review:
> https://github.com/openjdk/jdk/pull/23467
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
>
> If you are able to make a local OpenJDK build with that solution you could
> check if it addresses your use-cases (or not).
>
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
> 8349462: Gatherers.mapConcurrent could support async interrupts by
> viktorklang-ora ? Pull Request #23467 ? openjdk/jdk
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
> This change is likely going to need some extra verbiage in the spec for
> mapConcurrent, and thus a CSR. This behavior aligns mapConcurrent with how
> parallel streams work in conjunction with interrup...
> github.com
> <https://urldefense.com/v3/__http://github.com__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89DBkMefT$>
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Wednesday, 5 February 2025 16:24
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Thanks Viktor!
>
> I understand the problem.
>
> The main reason I asked is because I want to understand how the core Java
> team thinks of throwing an unchecked exception.
>
> As explained above, I consider losing cancellability a big deal, a deal
> breaker even. And I thought throwing unchecked is more acceptable. Because
> the most common reason the mapConcurrent() VT can be interrupted is due to
> cancellation from a parent mapConcurrent(), or a parent Structured
> Concurrency scope. The cancellation could be either from an organic
> exception, or from the downstream not needing more elements, like maybe due
> to findFirst() already getting an element.
>
> In both cases, since the concurrent operation is already cancelled (result
> ignored), what exception pops up to the top level isn't that big of a deal
> (perhaps only a log record will be seen?)
>
> But if the core Java team considers it a bad idea, I would love to learn
> and adjust.
>
> On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi,
>
> The problem is that mapConcurrent cannot throw InterruptedException
> because that is a checked exception, so we cannot clear the interrupted
> flag and throw that exception.
>
> So the updated semantics is to not cut the stream short but instead run to
> completion, restoring the interruption flag.
>
> There exists a couple of alternatives to this approach which I am
> contemplating, but they need to be further explored before I consider
> moving forward with any of them.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 27 January 2025 17:00
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Thanks Viktor!
>
> It looks like the current fix ignores interruption.
>
> I want to make sure my concern of it defeating cancellation is heard and
> understood.
>
> The scenarios I worry about is for a mapConcurrent() that fans out to
> another method call, which internally calls mapConcurrent() as
> implementation detail.
>
> An example:
>
> List<RefundResponse> refundHelper(transaction) {
>   transaction.creditCardAccounts.stream()
>     .gather(mapConcurrent(acct -> service.refund(acct))
>     .toList();
> }
>
> transactions.stream()
>     .gather(mapConcurrent(transaction -> refundHelper(transaction));
>
>
> It seems undesirable that in such a case all the service.refund() calls
> become non cancellable, because the only way the outer mapConcurrent()
> cancels the refundHelper() calls is through Thread.interrupt() the virtual
> threads that call refundHelper(), which would then be disabled by the inner
> mapConcurrent().
>
> Does this example make sense to you? I can further explain if anything
> isn't clear.
>
> But I want to make sure the decision to disable interruption is deliberate
> judgement call that such nested mapConcurrent() is unlikely,or not
> important.
>
> Cheers,
>
>
>
> On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi!
>
> Please see: https://github.com/openjdk/jdk/pull/23100
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23100__;!!ACWV5N9M2RV99hQ!IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Sunday, 26 January 2025 23:03
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* [External] : Re: mapConcurrent() with InterruptedException
>
> Checking in on what you've found out, Viktor.
>
> From where we left off, I understand that you were looking at alternatives
> instead of silent truncation?
>
> Have you reached any conclusion?
>
> We touched on disallowing interruption during mapConcurrent(). I still
> have concerns with disabling cancellation, because it basically undoes this
> API note from the javadoc
> <https://cr.openjdk.org/~alanb/sc-20240503/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)>
> :
>
> API Note: In progress tasks will be attempted to be cancelled, on a
> best-effort basis, in situations where the downstream no longer wants to
> receive any more elements.
> In reality, people will use mapConcurrent() to fan out rpcs. Sometimes
> these rpcs are just a single blocking call; yet sometimes they may
> themselves be a Structured Concurrency scope, with 2 or 3 rpcs that
> constitute a single logical operation. Under two conditions, cancellation
> is imho important semantic:
>
>    1. The downstream code uses filter().findFirst(), and when it sees an
>    element, it will return and no longer needs the other pending rpcs to
>    complete. If cancellation is disabled, these unnecessary rpcs will waste
>    system resources.
>    2. One of the rpc throws and the Stream pipeline needs to propagate
>    the exception. Again, if the other rpcs cannot be cancelled, we'll have
>    many zombie rpcs.
>
> Zombie rpcs may or may not be a deal breaker, depending on the specific
> use case. But for a JDK library, losing cancellation would have a negative
> impact on usability.
>
> My 2c,
>
>
> On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi Ben,
>
> Thanks for raising these questions?getting feedback is crucial in the
> Preview stage of features.
>
> I wrote a reply to the Reddit thread so I'll just summarize here:
>
> It is important to note that *mapConcurrent()* is not a part of the
> Structured Concurrency JEPs, so it is not designed to join SC scopes.
>
> I'm currently experimenting with ignoring-but-restoring interrupts on the
> "calling thread" for *mapConcurrent()*, as well as capping
> work-in-progress to *maxConcurrency* (not only capping the concurrency
> but also the amount of completed-but-yet-to-be-pushed work). Both of these
> adjustments should increase predictability of behavior in the face of
> blocking operations with variable delays.
>
> Another adjustment I'm looking at right now is to harden/improve the
> cleanup to wait for concurrent tasks to acknowledge cancellation, so that
> once the finisher is done executing the VTs are known to have terminated.
>
> As for not preserving the encounter order, that would be a completely
> different thing, and I'd encourage you to experiment with that if that
> functionality would be interesting for your use-case(s).
>
> Again, thanks for your feedback!
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Jige
> Yu <yujige at gmail.com>
> *Sent:* Friday, 3 January 2025 17:53
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* mapConcurrent() with InterruptedException
>
> Hi Java Experts,
>
> I sent this email incorrectly to loom-dev@ and was told on Reddit that
> core-libs-dev is the right list.
>
> The question is about the behavior of mapConcurrent() when the thread is
> interrupted.
>
> Currently mapConcurrent()'s finisher phase will re-interrupt the thread,
> then stop at whatever element that has already been processed and return.
>
> This strikes me as a surprising behavior, because for example if I'm
> running:
>
>    Stream.of(1, 2, 3)
>         .gather(mapConcurrent(i -> i * 2))
>         .toList()
>
> and the thread is being interrupted, the result could be any of [2], [2,
> 4] or [2, 4, 6].
>
> Since thread interruption is cooperative, there is no guarantee that the
> thread being interrupted will just abort. It's quite possible that it'll
> keep going and then will use for example [2] as the result of doubling the
> list of [1, 2, 3], which is imho incorrect.
>
> In the Reddit
> <https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread,
> someone argued that interruption rarely happens so it's more of a
> theoretical issue. But interruption can easily happen in Structured
> Concurrency or in mapConcurrent() itself if any subtask has failed in order
> to cancel/interrupt the other ongoing tasks.
>
> There had been discussion about alternative strategies:
>
>    1. Don't respond to interruption and just keep running to completion.
>    2. Re-interrupt thread and wrap the InterruptedException in a standard
>    unchecked exception (StructuredConcurrencyInterruptedException?).
>
>
> I have concerns with option 1 because it disables cancellation propagation
> when mapConcurrent() itself is used in a subtask of a parent
> mapConcurrent() or in a StructuredConcurrencyScope.
>
> Both equivalent Future-composition async code, or C++'s fiber trees
> support cancellation propagation and imho it's a critical feature or else
> it's possible that a zombie thread is still sending RPCs long after the
> main thread has exited (failed, or falled back to some default action).
>
> My arguments for option 2:
>
>    1. InterruptedException is more error prone than traditional checked
>    exceptions for *users* to catch and handle. They can forget to
>    re-interrupt the thread. It's so confusing that even seasoned programmers
>    may not know they are *supposed to* re-interrupt the thread.
>    2. With Stream API using functional interfaces like Supplier,
>    Function, the option of just tacking on "throws IE" isn't available to many
>    users.
>    3. With Virtual Threads, it will be more acceptable, or even become
>    common to do blocking calls from a stream operation (including but
>    exclusive to mapConcurrent()). So the chance users are forced to deal with
>    IE will become substantially higher.
>    4. Other APIs such as the Structured Concurrency API have already
>    started wrapping system checked exceptions like ExecutionException,
>    TimeoutException in unchecked exceptions ( join()
>    <https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for
>    example).
>    5. Imho, exceptions that we'd rather users not catch and handle but
>    instead should mostly just propagate up as is, should be unchecked.
>
> There is also a side discussion
> <https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/comment/m4z4f8c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about
> whether mapConcurrent() is better off preserving input order or push to
> downstream as soon as an element is computed. I'd love to discuss that
> topic too but maybe it's better to start a separate thread?
>
> Thank you and cheers!
>
> Ben Yu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250528/63e0df5d/attachment-0001.htm>

From iris at openjdk.org  Wed May 28 17:47:50 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 28 May 2025 17:47:50 GMT
Subject: RFR: 8348328: Update IANA Language Subtag Registry to Version
 2025-05-15
In-Reply-To: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>
References: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>
Message-ID: <5GIrP4HoAjltFSJe49hO6N8AWpcK-S6aobf4DT9GtBc=.1ad6fa80-5d14-4d89-981a-4261799fc575@github.com>

On Wed, 28 May 2025 17:00:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the language subtag registry to Version 2025-05-15.
> 
> LanguageSubtagRegistryTest.java was updated with the preferred-values: `hnm`, `eko`, `luh`,`sjc`, `sqm`. A small change was also made to the test to improve the output as well.

Confirmed changes in lsrdata and test files correspond to those found in IANA Language Subtag Registry file dated 2025-05-15 as expected.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25503#pullrequestreview-2875936643

From jlahoda at openjdk.org  Wed May 28 18:23:50 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 28 May 2025 18:23:50 GMT
Subject: RFR: 8357955: java.lang.classfile.Signature.ArrayTypeSig.of IAE
 not thrown for dims > 255
In-Reply-To: <UFmthl6dN4rXfEwI26Kgw1LHmk-U-RpnpD_cgOYuy90=.9cad06f8-46b4-404b-9fbf-ef3a44a45fec@github.com>
References: <UFmthl6dN4rXfEwI26Kgw1LHmk-U-RpnpD_cgOYuy90=.9cad06f8-46b4-404b-9fbf-ef3a44a45fec@github.com>
Message-ID: <_1i2_emUglBDLEhrv5hzGe7yjXyk_v3JKPmRxgGYIfs=.e22d5fc9-7724-4ca6-8e7b-066e3face8d7@github.com>

On Wed, 28 May 2025 17:56:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> java.lang.classfile.Signature.ArrayTypeSig.of constraint check did not include dimensions of the given component if the component is an array.
> 
> This patch fixes the constraint check, corrects the @throws description and adds test of the subj.
> 
> Please review.
> 
> Thanks,
> Adam

Makes sense to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25506#pullrequestreview-2876029623

From duke at openjdk.org  Wed May 28 18:39:13 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Wed, 28 May 2025 18:39:13 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v4]
In-Reply-To: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
Message-ID: <72GCipLKeCWCG-4jsG5XhZKkTdVsWafEq_wA0oD-0mk=.c70af814-54fe-43d2-b7c9-72b845eb99d5@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
> 
> The command to run all range specific micro-benchmarks is posted below.
> 
> `make test TEST="micro:CbrtPerf.CbrtPerfRanges"`
> 
> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version.
> 
> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs.
> 
> | Input range(s)                                  | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
> | :-------------------------------------: | :-------------------------------: | :-------------------------------: | :---------: |
> | [-2^(-1022), 2^(-1022)]                   | 6568                                        | 17678                                      | 2.69x       |
> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932                                    | 200897                                    | 1.45x       |
> 
> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.

Mohamed Issa has updated the pull request incrementally with four additional commits since the last revision:

 - Remove comment mentioning invalid exception when NaN input is provided
 - Use rcx as base and r8 as index for address calculations in certain cbrt stub generator instructions
 - Remove unnecessary unpckhpd and unpcklpd definitions in macro-assembler header file
 - Remove unnecessary movapd definitions in macro-assembler header file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24470/files
  - new: https://git.openjdk.org/jdk/pull/24470/files/57412f0d..ff4d4f22

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24470&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24470&range=02-03

  Stats: 10 lines in 2 files changed: 0 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24470.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24470/head:pull/24470

PR: https://git.openjdk.org/jdk/pull/24470

From sviswanathan at openjdk.org  Wed May 28 18:39:13 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 28 May 2025 18:39:13 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v4]
In-Reply-To: <72GCipLKeCWCG-4jsG5XhZKkTdVsWafEq_wA0oD-0mk=.c70af814-54fe-43d2-b7c9-72b845eb99d5@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <72GCipLKeCWCG-4jsG5XhZKkTdVsWafEq_wA0oD-0mk=.c70af814-54fe-43d2-b7c9-72b845eb99d5@github.com>
Message-ID: <eJStgCQHuB9TUbgyAPo_h4HNK22AJb70aV4XmbElftw=.f4caccc2-a766-4ed1-bbf2-f60a9447ff09@github.com>

On Wed, 28 May 2025 18:36:38 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The command to run all range specific micro-benchmarks is posted below.
>> 
>> `make test TEST="micro:CbrtPerf.CbrtPerfRanges"`
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs.
>> 
>> | Input range(s)                                  | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
>> | :-------------------------------------: | :-------------------------------: | :-------------------------------: | :---------: |
>> | [-2^(-1022), 2^(-1022)]                   | 6568                                        | 17678                                      | 2.69x       |
>> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932                                    | 200897                                    | 1.45x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Remove comment mentioning invalid exception when NaN input is provided
>  - Use rcx as base and r8 as index for address calculations in certain cbrt stub generator instructions
>  - Remove unnecessary unpckhpd and unpcklpd definitions in macro-assembler header file
>  - Remove unnecessary movapd definitions in macro-assembler header file

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24470#pullrequestreview-2876071455

From duke at openjdk.org  Wed May 28 18:39:14 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Wed, 28 May 2025 18:39:14 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v3]
In-Reply-To: <62SQLH6KGe8_w0LxmPSPW7C34v9-KFYliTk0RzMgJTs=.80886efd-7f4f-408c-8bbd-07af12ab9701@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <H3vvJxVRsOzXpLIAnz2vc3wU_Umd9IoyI1cgqYT6mq0=.79b289da-60f2-4f62-99bd-227e03e9df2b@github.com>
 <62SQLH6KGe8_w0LxmPSPW7C34v9-KFYliTk0RzMgJTs=.80886efd-7f4f-408c-8bbd-07af12ab9701@github.com>
Message-ID: <8ArA3awbbtTvNZfaKvAdlv2oMcLP0cASBHr-VRK_-dc=.0fe37d63-7eb0-49d7-abf1-812e7be8dde8@github.com>

On Tue, 27 May 2025 22:30:17 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add new set of cbrt micro-benchmarks
>
> src/hotspot/cpu/x86/macroAssembler_x86.hpp line 1251:
> 
>> 1249:   void movapd(XMMRegister dst, Address src) { Assembler::movapd(dst, src); }
>> 1250:   void movapd(XMMRegister dst, AddressLiteral src, Register rscratch = noreg);
>> 1251: 
> 
> You could write it as:
> using Assembler::movapd;
> void movapd(XMMRegister dst, AddressLiteral src, Register rscratch = noreg);

Ok, this is updated now.

> src/hotspot/cpu/x86/macroAssembler_x86.hpp line 1323:
> 
>> 1321:   void unpckhpd(XMMRegister dst, XMMRegister src) { Assembler::unpckhpd(dst, src); }
>> 1322:   void unpcklpd(XMMRegister dst, XMMRegister src) { Assembler::unpcklpd(dst, src); }
>> 1323: 
> 
> Do we need these declarations here?

No, they were superfluous as cbrt stub generator could already access them. I removed them now.

> src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp line 43:
> 
>> 41: //
>> 42: // Special cases:
>> 43: //  cbrt(NaN) = quiet NaN, and raise invalid exception
> 
> No exception is raised so the comment needs to be corrected.

This is corrected now.

> src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp line 226:
> 
>> 224:   __ andl(rcx, 248);
>> 225:   __ lea(r8, ExternalAddress(rcp_table));
>> 226:   __ movsd(xmm4, Address(r8, rcx, Address::times_1));
> 
> This address and other instructions using similar address could be written as  Address(rcx, r8, Address::times_1).

Ok, I have changed the order, so rcx is viewed as base and r8 is viewed as index now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2112516974
PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2112518997
PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2112520793
PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2112520486

From naoto at openjdk.org  Wed May 28 18:57:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 28 May 2025 18:57:53 GMT
Subject: RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes [v3]
In-Reply-To: <6Fsxo4CXaVfTdKQ_DsbdIn3uQ0170SX98zdjbs5HL7o=.e296b38e-3390-40d2-937c-595ca509e884@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
 <6Fsxo4CXaVfTdKQ_DsbdIn3uQ0170SX98zdjbs5HL7o=.e296b38e-3390-40d2-937c-595ca509e884@github.com>
Message-ID: <OKanBhuFL1Bblty6O8jfKbNBQrWTeCq7kgXSmXOh_dM=.3dd8659d-ff9f-427f-86ac-277fbe74e8fd@github.com>

On Tue, 27 May 2025 19:32:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, these are immutable, We should add `@Stable` and final to provide information to the optimizer.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments, from @natoj

LGTM. Thanks for the changes.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25430#pullrequestreview-2876123518

From duke at openjdk.org  Wed May 28 19:24:52 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 28 May 2025 19:24:52 GMT
Subject: RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes [v3]
In-Reply-To: <6Fsxo4CXaVfTdKQ_DsbdIn3uQ0170SX98zdjbs5HL7o=.e296b38e-3390-40d2-937c-595ca509e884@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
 <6Fsxo4CXaVfTdKQ_DsbdIn3uQ0170SX98zdjbs5HL7o=.e296b38e-3390-40d2-937c-595ca509e884@github.com>
Message-ID: <QiIvCIqFDm8VveR2XA4pugfUfmkf5L_qjlHMedtIWb8=.a55ebde8-71ff-474e-b646-1e2d8f844389@github.com>

On Tue, 27 May 2025 19:32:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, these are immutable, We should add `@Stable` and final to provide information to the optimizer.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments, from @natoj

src/java.base/share/classes/java/lang/CharacterData00.java.template line 36:

> 34: 
> 35: final class CharacterData00 extends CharacterData {
> 36:     /* The character properties are currently encoded into 32 bits in the following manner:

Maybe?also add?the?table `B`?comment from?`GenerateCharacter` to?these?comments:
https://github.com/openjdk/jdk/blob/28f509317d477c5f4076658f9ae9995aa6c53631/make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java#L158-L171

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25430#discussion_r2112589819

From almatvee at openjdk.org  Wed May 28 19:38:41 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 28 May 2025 19:38:41 GMT
Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre-
 installation PKG scripts
Message-ID: <Ys6Vcv027kkBs3FO6TG-xImv4FTJApkZ2StvP1G9Neo=.ba3a7d54-a888-47b2-b769-59470773509f@github.com>

- Removed all code from pre- and post- installation PKG scripts.
- This code is not needed and PKG should create destination folder and set correct permissions.
- If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle.
- pre- and post- installation PKG scripts are kept as empty scripts, so user can override them if needed.
- `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$1` argument in scripts is same as `INSTALL_LOCATION`.
- I think code in these scripts are some legacy leftovers.

-------------

Commit messages:
 - 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts

Changes: https://git.openjdk.org/jdk/pull/25510/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25510&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356047
  Stats: 17 lines in 3 files changed: 0 ins; 17 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25510.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25510/head:pull/25510

PR: https://git.openjdk.org/jdk/pull/25510

From asemenyuk at openjdk.org  Wed May 28 20:02:56 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 28 May 2025 20:02:56 GMT
Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre-
 installation PKG scripts
In-Reply-To: <Ys6Vcv027kkBs3FO6TG-xImv4FTJApkZ2StvP1G9Neo=.ba3a7d54-a888-47b2-b769-59470773509f@github.com>
References: <Ys6Vcv027kkBs3FO6TG-xImv4FTJApkZ2StvP1G9Neo=.ba3a7d54-a888-47b2-b769-59470773509f@github.com>
Message-ID: <Gc9nYhCL4mPAhcdQbJGq4dH9Hb9UdCaDuNCS99E9v3M=.a0f42fb3-f726-424e-be8d-e5e954b41e05@github.com>

On Wed, 28 May 2025 19:32:47 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Removed all code from pre- and post- installation PKG scripts.
> - This code is not needed and PKG should create destination folder and set correct permissions.
> - If for some reason it is not happens, permissions issues should be fixed when jpackage prepares application bundle. PKG should keep all permissions unchanged when packaging and installing bundle.
> - pre- and post- installation PKG scripts are kept as empty scripts, so user can override them if needed.
> - `INSTALL_LOCATION` and `APP_LOCATION` substitution is removed, since `$1` argument in scripts is same as `INSTALL_LOCATION`.
> - I think code in these scripts are some legacy leftovers.

Why do we need empty scripts? It doesn't make sense. I'd remove them.

Also, if this area of jpackage is being revisited, then we need a couple of tests for custom PKG scripts.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25510#issuecomment-2917466837

From naoto at openjdk.org  Wed May 28 20:17:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 28 May 2025 20:17:51 GMT
Subject: RFR: 8348328: Update IANA Language Subtag Registry to Version
 2025-05-15
In-Reply-To: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>
References: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>
Message-ID: <PbaL47p0z6b2-BDkrkoMQQjxDZYYurDR8QB7oqZtzDg=.370ea60e-da54-4bf2-9fa4-873318fcc1f7@github.com>

On Wed, 28 May 2025 17:00:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the language subtag registry to Version 2025-05-15.
> 
> LanguageSubtagRegistryTest.java was updated with the preferred-values: `hnm`, `eko`, `luh`,`sjc`, `sqm`. A small change was also made to the test to improve the output as well.

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25503#pullrequestreview-2876307424

From swen at openjdk.org  Wed May 28 20:39:59 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 28 May 2025 20:39:59 GMT
Subject: Integrated: 8357681: Fixed the DigitList::toString method causing
 incorrect results during debugging
In-Reply-To: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
Message-ID: <MGZLJgfgPderAxpg81pC8ITmx_H8PtFEsCZQZVcdVFk=.db2454e9-f1dd-4543-860f-6eea597cd0f1@github.com>

On Sun, 18 May 2025 11:11:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.

This pull request has now been integrated.

Changeset: b7f0f480
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b7f0f480cefb7295bbd5f8830458b69baf2eaff6
Stats:     6 lines in 1 file changed: 0 ins; 5 del; 1 mod

8357681: Fixed the DigitList::toString method causing incorrect results during debugging

Reviewed-by: jlu, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/25288

From naoto at openjdk.org  Wed May 28 20:55:03 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 28 May 2025 20:55:03 GMT
Subject: RFR: 8357275: Locale.Builder.setLanguageTag should mention
 conversions made on language tag [v4]
In-Reply-To: <LH9qT9TNFE_IvRsRhE7az6ilAj_RC4j5SPbmZk-jnRI=.18c87588-a90e-4a75-b9c7-ac29df858fbe@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
 <LH9qT9TNFE_IvRsRhE7az6ilAj_RC4j5SPbmZk-jnRI=.18c87588-a90e-4a75-b9c7-ac29df858fbe@github.com>
Message-ID: <hQ8P2AMEt9FEqBUPtyDyLGkZlGuBEykqL3w7JKKTyU0=.45c367d6-d0fc-4c99-93d4-b05ba19a2f84@github.com>

On Wed, 21 May 2025 20:41:43 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSR review - clarify that 3 extlang subtags is not a JDK specific condition

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25309#pullrequestreview-2876400699

From prr at openjdk.org  Wed May 28 20:55:03 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 28 May 2025 20:55:03 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
 <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>
Message-ID: <Dq8Agr8pnvykN7oNGPzTQnNO77rhD_M8j1caxF-mY4M=.867b19b6-ce18-4656-b52b-4fd5ec84d834@github.com>

On Mon, 26 May 2025 07:55:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore MenuShortcut.java
>>  - Restore LocaleDataTest.java
>
> test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java line 90:
> 
>> 88:                 printKey(e);
>> 89:                 int keychar = e.getKeyChar();
>> 90:                 if (keychar == 27) { // Escape character is 27 or \u001b
> 
> @prrace I think this is an actual bug. `\u0021` codes to `!`, and I don't think that is what was meant. Do you still want me to revert it?

You are right, that's a typo. Keep your change.
And I don't know why the code uses literal 27 instead of KeyEvent.VK_ESCAPE .. but that's not your problem.

https://docs.oracle.com/en/java/javase/21/docs/api/constant-values.html#java.awt.event.KeyEvent.VK_ESCAPE

> test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java line 188:
> 
>> 186:                     +          "\"After\" lists.\n"
>> 187:                     + "              Added printers are highlighted with "
>> 188:                     +               "green color, removed ones \u2014 with "
> 
> @prrace This too seems like a bug, or rather a typo. The text currently reads `Added printers are highlighted with green color, removed ones ? with red color.`. The Em dash does not make any sense to me, and seems to be a copy paste error.
> 
> Do you still want me to revert it?

I agree. Keep your change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112722311
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112731040

From prr at openjdk.org  Wed May 28 20:55:04 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 28 May 2025 20:55:04 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>
 <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>
Message-ID: <BW-jmv0CMo_qRngDZcLpY3s8yH_WYkD_YyhGiDyDeVU=.5292f832-a0ab-4a8f-9792-6c8005697e45@github.com>

On Mon, 26 May 2025 08:07:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:
>> 
>>> 61: 
>>> 62:     private static final String INSTRUCTIONS =
>>> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "
>> 
>> I really don't like these tests being changed. It isn't part of the JDK build.
>> People compile these in all sorts of locales.
>> Please revert all the changes in the client tests.
>
> Just a clarification. What I did was convert curly quotes and an em dash to normal ASCII quotes and an ASCII hyphen, just as it is in all other `INSTRUCTIONS` in the tests. This is similar to what was done in JDK-8354273 and JDK-8354213, and should have been made as part of those PRs if I only had noticed this place by then.
> 
> The user's locale should not really matter. When have stringent locale requirements for building, and automatically setup the correct locale while building. I don't think the locale will matter at runtime either, but it n the rare case that it should matter, then pure ASCII would be prefer, wouldn't it?
> 
> Let me know if you still want me to revert it.

I'd like this reverted.
People *build* these tests in their local repos using javac and whatever their locale is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112728971

From rriggs at openjdk.org  Wed May 28 20:59:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 28 May 2025 20:59:51 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v3]
In-Reply-To: <x-kg_zhXOYwXjNAnWysWQtxPWl8a2c-sOZQbhzyYBss=.3616b256-3dfe-40e1-ab16-a96cc5420069@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <Jm4ATGoFWP2a8HSBuwAglmdQS5fcBKBxt7TOklUQRjk=.b47ef4c7-26cd-4603-a074-76be89fa898c@github.com>
 <D2OwQlifY_F57s5ntpnVSYAMxZ8lacAyv03fME6O3ZM=.524387cc-ad76-4261-9269-8e2f08aeb6fb@github.com>
 <my9K8CLlrz0magIzlGgxShOw4oG1D7khLcG0KB2C3aU=.50c780c7-2f35-425b-aa19-00905143e208@github.com>
 <lzUXzFFqnkDwu6nx8GudrrkgihJ9bYECt0gqbWSPOgg=.7f6488d7-5c7e-423a-879a-3f125245440c@github.com>
 <x-kg_zhXOYwXjNAnWysWQtxPWl8a2c-sOZQbhzyYBss=.3616b256-3dfe-40e1-ab16-a96cc5420069@github.com>
Message-ID: <aUqL8I-iZmufLfNiILoCu114WyvAoMGFlyWx2ffORds=.dabc7a33-80ab-45b8-a4e3-664303aaa120@github.com>

On Wed, 28 May 2025 17:11:31 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> The `timestamp` method may mislead an app developer thinking its the time from the version 7 timestamp.
>> The first-line comment might make it more obvious if it says:
>> `The timestamp value associated with a version 1 UUID.`
>> 
>> The Unix Epoch time would be easier to use if a method was added to return it.
>> `long UnixEpochTimeNanos()`   (name subject to bike-shedding).
>> And throwing if it was not version 7.
>
> The first 48 bits need to be from the unix epoch time stamp in ms only to remain complaint. If I understand correctly, to be able to guarantee that the nsBits are actually time orderable, System.nanoTime() would have to be pinned to a point where System.currentTimeMillis() increments by 1ms (which doesnt seem possible). Otherwise any offset could be at any arbitrary point in a given millisecond and nsBits would wrap around from that.
> 
> I think the options are to either use the random only approach with ms precision or an guaranteed monotonic counter based approach and take the hit on performance.
> 
> I agree with updating to "create" from "retrieve" on the first line comment and also with the method name change to avoid confusion with UUIDv1, however to either unixEpochTimeNanos() or unixEpochTimeMillis() or otherwise depending on which implementation we settle on.

We don't have a reliable sub-microsecond source across platforms, so can only be confident using random numbers for the low order bits. (and I don't expect a higher resolution monotonic clock to be available anytime soon).

Would the static factory method be more useful if it took the mstime as a parameter?
That would allow the caller to pick the time source.  For example,
`    UUID ts = UUID.timesteampUUID(System.currentTimeMillis());`
It would avoid locking into the System.currentTimeMillis() and allows the application to create UUIDs for whatever time meets its needs.

Adding a unixEpochTimeMillis() makes sense, re-assembling the time bits into the ms time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2112737649

From almatvee at openjdk.org  Wed May 28 21:42:50 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 28 May 2025 21:42:50 GMT
Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre-
 installation PKG scripts
In-Reply-To: <Gc9nYhCL4mPAhcdQbJGq4dH9Hb9UdCaDuNCS99E9v3M=.a0f42fb3-f726-424e-be8d-e5e954b41e05@github.com>
References: <Ys6Vcv027kkBs3FO6TG-xImv4FTJApkZ2StvP1G9Neo=.ba3a7d54-a888-47b2-b769-59470773509f@github.com>
 <Gc9nYhCL4mPAhcdQbJGq4dH9Hb9UdCaDuNCS99E9v3M=.a0f42fb3-f726-424e-be8d-e5e954b41e05@github.com>
Message-ID: <W34cIwIlPZjg1ixYMqq9OEEeOlJARF2QNqYHcUS7sqo=.4c449989-2435-46e4-9231-9dbd8c581191@github.com>

On Wed, 28 May 2025 20:00:20 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Why do we need empty scripts? It doesn't make sense. I'd remove them.

If we do not have empty scripts how user will override it?
https://docs.oracle.com/en/java/javase/24/jpackage/override-jpackage-resources.html#GUID-62412365-821D-4736-A20D-70F2D47136D8
>From our documentation we list such files with `--verbose` and placing them into Temp folder specified via `--temp`. For scripts we placing them under `Temp/scripts`. I am not sure how user will able to figure it out if we do not place template files under temp folder.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25510#issuecomment-2917680462

From igraves at openjdk.org  Wed May 28 21:57:25 2025
From: igraves at openjdk.org (Ian Graves)
Date: Wed, 28 May 2025 21:57:25 GMT
Subject: RFR: 8356634: VectorShape#largestShapeFor should have public access
Message-ID: <JavbxK-K4oPsdH53sMhVG1RCYBYlyOdZ_6wZCQm0uzk=.edfacd8d-88fb-485d-a86c-e9ac1571a09d@github.com>

VectorShape#largestShapeFor is referenced in existing JavaDoc but has been package-private. This propose change makes it public and adds documentation for it.

-------------

Commit messages:
 - Making VectorShape.largestShapeFor public and documenting

Changes: https://git.openjdk.org/jdk/pull/25513/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25513&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356634
  Stats: 12 lines in 1 file changed: 8 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25513/head:pull/25513

PR: https://git.openjdk.org/jdk/pull/25513

From iklam at openjdk.org  Wed May 28 22:15:02 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 28 May 2025 22:15:02 GMT
Subject: Integrated: 8355798: Implement JEP 514: Ahead-of-Time Command Line
 Ergonomics
In-Reply-To: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
References: <TIGdFbhPa8KeiZWBX5djV3P-AoG1taVOkrsGKliKszg=.e296a0fe-d0ff-4091-9c6f-bb9525fc3a2d@github.com>
Message-ID: <D1A3b6u8IZSeiuNjRSi0PgHVlHhaYZaU5Nbr2DMiSPU=.b00af116-17d4-44df-ad34-5edee54fcae3@github.com>

On Tue, 29 Apr 2025 04:50:42 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
> 
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow"
> - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache
> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options
> 
> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification.
> 
> Examples:
> 
> 
> # Create an AOT cache with a single command:
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> Hello World
> Temporary AOTConfiguration recorded: foo.aot.config
> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config
> [...]
> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot
> AOTCache creation is complete: foo.aot 10240000 bytes
> 
> # Create logging file for the AOT cache assembly phase
> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt
> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld
> 
> 
> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process).

This pull request has now been integrated.

Changeset: dede3532
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dede3532f7238d527fb89be41f1b8050bde02ee3
Stats:     2107 lines in 26 files changed: 1564 ins; 459 del; 84 mod

8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics

Reviewed-by: erikj, kvn, asmehra

-------------

PR: https://git.openjdk.org/jdk/pull/24942

From asemenyuk at openjdk.org  Wed May 28 22:51:51 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 28 May 2025 22:51:51 GMT
Subject: RFR: 8351369: [macos] Use --install-dir option with DMG packaging
In-Reply-To: <kzagV86LsE-55gtYItG-NVpkQwhj229GhyxEcnMS9ig=.7a5fbe15-004a-471d-a095-26c2b8147179@github.com>
References: <kzagV86LsE-55gtYItG-NVpkQwhj229GhyxEcnMS9ig=.7a5fbe15-004a-471d-a095-26c2b8147179@github.com>
Message-ID: <ZL8Yr8z1ySIcF8afE4ne54GjH30f3EhmDCDBGdmfo4M=.7949dac1-5600-472e-9dac-37681617b27d@github.com>

On Wed, 28 May 2025 07:11:36 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - `--install-dir` option in DMG packaging is no longer ignored.
> - Defaults are still the same: `/Applications` and `/Library/Java/JavaVirtualMachines`.
> - If the installation directory doesn't exist, jpackage will try to create and delete it right after the DMG package is created.
> - If jpackage was unable to create installation directory error will be thrown or if installation directory points to invalid location like file.
> - It will be user responsibility to make sure installation directory exist on target machine, since DMG cannot create directories during drag and drop.
> - Target directory in case of non-default installation dir will display full path. See image below for example.
> 
> ![Screenshot 2025-05-28 at 12 07 53?AM](https://github.com/user-attachments/assets/fbcba07b-74a5-4276-90c3-5f8d2d0dcc16)

Changes requested by asemenyuk (Reviewer).

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackageBuilder.java line 99:

> 97:                     }
> 98:                 } catch (Exception ex) {
> 99:                     Log.verbose(ex);

What is the point of this log statement? The error will be logged at the top level anyway

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackageBuilder.java line 101:

> 99:                     Log.verbose(ex);
> 100:                     throw new RuntimeException(ex);
> 101:                 }

This code should be in a separate function covered with unit tests.

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/model/MacDmgPackageMixin.java line 41:

> 39:      * @return Root of created install dir
> 40:      */
> 41:     Optional<Path> installDirDeleteRoot();

Why is this information a part of the model? Can't dmg packager figure it out on its own?

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties line 84:

> 82: message.setfile.dmg=Setting custom icon on DMG file skipped because 'SetFile' utility was not found. Installing Xcode with Command Line Tools should resolve this issue.
> 83: message.install-dir-invalid=Error: "--install-dir" value {0} is ivalid for DMG packaging. Make sure it is valid path to existing or non-existing directory.
> 84: message.install-dir-create=Error: Unable to create install dir {0}. Make sure you have sufficient permissions or create it manually. Exception: {1}

Are these error messages DMG-specific? If "yes", let's give them less vague names, like `message.dmg-install-dir-invalid`

test/jdk/tools/jpackage/share/InstallDirTest.java line 121:

> 119:         new PackageTest()
> 120:         .setExpectedExitCode(1)
> 121:         .excludeTypes(PackageType.MAC_PKG)

`.forTypes(PackageType.MAC_DMG)` would be more appropriate as the test applies to DMG and not to "all packages except of PKG". If we add another bundle type, `.excludedTypes(Package Type.MAC_PKG)` will become wrong.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25481#pullrequestreview-2876618289
PR Review Comment: https://git.openjdk.org/jdk/pull/25481#discussion_r2112872869
PR Review Comment: https://git.openjdk.org/jdk/pull/25481#discussion_r2112872246
PR Review Comment: https://git.openjdk.org/jdk/pull/25481#discussion_r2112875748
PR Review Comment: https://git.openjdk.org/jdk/pull/25481#discussion_r2112880614
PR Review Comment: https://git.openjdk.org/jdk/pull/25481#discussion_r2112879267

From psandoz at openjdk.org  Wed May 28 23:01:53 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 28 May 2025 23:01:53 GMT
Subject: RFR: 8356634: VectorShape#largestShapeFor should have public
 access
In-Reply-To: <JavbxK-K4oPsdH53sMhVG1RCYBYlyOdZ_6wZCQm0uzk=.edfacd8d-88fb-485d-a86c-e9ac1571a09d@github.com>
References: <JavbxK-K4oPsdH53sMhVG1RCYBYlyOdZ_6wZCQm0uzk=.edfacd8d-88fb-485d-a86c-e9ac1571a09d@github.com>
Message-ID: <1iha2PLsnHM5C_y4SsJ0A-MbtOPeTM0UhrRhb0GXfxc=.0baa8fce-ed8b-4004-8f4a-023a21af5e2e@github.com>

On Wed, 28 May 2025 21:22:30 GMT, Ian Graves <igraves at openjdk.org> wrote:

> VectorShape#largestShapeFor is referenced in existing JavaDoc but has been package-private. This propose change makes it public and adds documentation for it.

Can you add something to the method testVectorShape in test/jdk/jdk/incubator/vector/PreferredSpeciesTest.java?

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java line 218:

> 216:      * @return the largest vector shape supported by the platform
> 217:      * for {@code etype}
> 218:      * @throws IllegalArgumentException if no such vector shape exists

Suggestion:

     * @throws IllegalArgumentException if no such vector shape exists
     *         for the element type or the type is not a valid {@code ETYPE}.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25513#pullrequestreview-2876648963
PR Review Comment: https://git.openjdk.org/jdk/pull/25513#discussion_r2112895191

From asemenyuk at openjdk.org  Wed May 28 23:05:50 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 28 May 2025 23:05:50 GMT
Subject: RFR: 8351369: [macos] Use --install-dir option with DMG packaging
In-Reply-To: <kzagV86LsE-55gtYItG-NVpkQwhj229GhyxEcnMS9ig=.7a5fbe15-004a-471d-a095-26c2b8147179@github.com>
References: <kzagV86LsE-55gtYItG-NVpkQwhj229GhyxEcnMS9ig=.7a5fbe15-004a-471d-a095-26c2b8147179@github.com>
Message-ID: <SpjCWvKNqLfabotb1qN2T9hOwdaxbfQazG9x8Bra4D8=.ba947686-0014-46a1-8cde-e0bdce718c91@github.com>

On Wed, 28 May 2025 07:11:36 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> If the installation directory doesn't exist, jpackage will try to create and delete it right after the DMG package is created.

Is this absolutely necessary? Is there a better way?

It looks like you removed DMG-specific runtime installer tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25481#issuecomment-2917802142
PR Comment: https://git.openjdk.org/jdk/pull/25481#issuecomment-2917804346

From asemenyuk at openjdk.org  Wed May 28 23:12:56 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 28 May 2025 23:12:56 GMT
Subject: RFR: 8356047: [macos] jpackage produces confusing post- and pre-
 installation PKG scripts
In-Reply-To: <W34cIwIlPZjg1ixYMqq9OEEeOlJARF2QNqYHcUS7sqo=.4c449989-2435-46e4-9231-9dbd8c581191@github.com>
References: <Ys6Vcv027kkBs3FO6TG-xImv4FTJApkZ2StvP1G9Neo=.ba3a7d54-a888-47b2-b769-59470773509f@github.com>
 <Gc9nYhCL4mPAhcdQbJGq4dH9Hb9UdCaDuNCS99E9v3M=.a0f42fb3-f726-424e-be8d-e5e954b41e05@github.com>
 <W34cIwIlPZjg1ixYMqq9OEEeOlJARF2QNqYHcUS7sqo=.4c449989-2435-46e4-9231-9dbd8c581191@github.com>
Message-ID: <CuISNGIABAqGlRSz0SlQMC1zJ4UASDvdVJr7Xd9Nd00=.78c1ae6d-4314-4caa-9d02-26f038c5be77@github.com>

On Wed, 28 May 2025 21:40:08 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> If we do not have empty scripts how user will override it?

What is the problem with this? By default, PKG will not have scripts. If they place them in the resource directory, jpackage will use them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25510#issuecomment-2917812280

From msheppar at openjdk.org  Wed May 28 23:16:54 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 28 May 2025 23:16:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v12]
In-Reply-To: <P1UhwKclOZOB8wVg38pTcQ7ZqO71ZQAAitPucfs_t4o=.5a555883-1d19-43f3-9e19-b1797d594796@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <P1UhwKclOZOB8wVg38pTcQ7ZqO71ZQAAitPucfs_t4o=.5a555883-1d19-43f3-9e19-b1797d594796@github.com>
Message-ID: <P23_pU8TmA_8hfRaL_8cAkId_C0PXgwZiYLR0TZfhq0=.0bc74355-0ef8-417f-b1a6-adc35755841a@github.com>

On Wed, 28 May 2025 11:13:12 GMT, Michael McMahon <michaelm at openjdk.org> 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 30 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - ... and 20 more: https://git.openjdk.org/jdk/compare/0671309d...cf179f7d

her are few file with IOException, UnknownHostException and MalformedURLException, which are worth reviewing form Exception that may have been missed

open/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java
Ln 562



open/src/java.base/share/classes/sun/security/x509/IPAddressName.java

open/src/java.base/share/classes/sun/security/x509/URIName.java

open/src/java.base/share/classes/sun/security/x509/RDN.java

open/src/java.base/share/classes/java/util/jar/JarFile.java


UnknownHostException

open/src/java.base/share/classes/sun/nio/ch/SocketAdaptor.java

open/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java


MalformedURLException

open/src/java.base/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java

open/src/java.base/share/classes/java/net/URL.java  ? Invalid port

open/src/java.naming/share/classes/com/sun/jndi/ldap/LdapURL.java

open/src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java

open/src/java.rmi/share/classes/java/rmi/Naming.java

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2917817454

From swen at openjdk.org  Thu May 29 01:00:52 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 29 May 2025 01:00:52 GMT
Subject: RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes [v3]
In-Reply-To: <QiIvCIqFDm8VveR2XA4pugfUfmkf5L_qjlHMedtIWb8=.a55ebde8-71ff-474e-b646-1e2d8f844389@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
 <6Fsxo4CXaVfTdKQ_DsbdIn3uQ0170SX98zdjbs5HL7o=.e296b38e-3390-40d2-937c-595ca509e884@github.com>
 <QiIvCIqFDm8VveR2XA4pugfUfmkf5L_qjlHMedtIWb8=.a55ebde8-71ff-474e-b646-1e2d8f844389@github.com>
Message-ID: <KWq-_5aInoF_pvsx-9tzfLPjp-kroxbM8I885MyLASA=.9262f283-4361-4177-939b-69bdb9368305@github.com>

On Wed, 28 May 2025 19:20:08 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix comments, from @natoj
>
> src/java.base/share/classes/java/lang/CharacterData00.java.template line 36:
> 
>> 34: 
>> 35: final class CharacterData00 extends CharacterData {
>> 36:     /* The character properties are currently encoded into 32 bits in the following manner:
> 
> Maybe?also add?the?table `B`?comment from?`GenerateCharacter` to?these?comments: <https://github.com/openjdk/jdk/blob/28f509317d477c5f4076658f9ae9995aa6c53631/make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java#L158-L171>

That's right, but it should be a separate PR

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25430#discussion_r2112986499

From vlivanov at openjdk.org  Thu May 29 01:16:52 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 29 May 2025 01:16:52 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v6]
In-Reply-To: <cskdHy0_3zFOp7bAI-zz6V-avY2vPIcnwIseaE0NrS8=.3c147c4d-78e9-4499-88d3-73fbb40560ab@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com>
 <ymq-cS14PaC1PpdKAzAZJwxdwtVTbSZtT-LNC21lW6Q=.f956592a-fd59-4bb5-a485-f4138942d290@github.com>
 <lnDH0vCQvoIGjjsjeO7ukv8gpTfp1vWR8hOX-CXlFjA=.a859787f-bc16-40c2-9f9d-ae879e68dc25@github.com>
 <rHMm6DwsyFJIOTQRKO17T0VyOvaxUwxVpwWKw4mpIj8=.d2633532-bc82-4505-a14b-45b46798d4ff@github.com>
 <cskdHy0_3zFOp7bAI-zz6V-avY2vPIcnwIseaE0NrS8=.3c147c4d-78e9-4499-88d3-73fbb40560ab@github.com>
Message-ID: <wQkKLSTJsvldZxWleQpPTv_9N1ugC067-gv5LUVTdPI=.8917db0c-0653-48f5-acc2-e040a61f650a@github.com>

On Sat, 24 May 2025 04:57:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> As I understand, `JDK-8271862` was about migrating to non-virtual intrinsic method.
>> In case of `Reference::get()`, you already have a virtual public method marked as `@IntrinsicCandidate`. And the patch doesn't change anything there.  So, unless I miss something, I believe the comment is misleading.
>
> The comment is about why we have native `get0` at all, rather than just making
> `get` also be native.
> 
>> [...] JDK-8271862 was about migrating to non-virtual intrinsic method.
> 
> That's not a correct summary of JDK-8271862. That change was about migrating
> away from having a method that was all 3 of (1) intrinsic (2) native, and (3)
> virtual. It split that method into two parts, and allocated the properties to
> them in such a way that neither had all 3. There are several possible
> allocations of the properties to the methods that would have worked. In this
> case we already had all the machinary in place for `refersTo0` to be intrinsic
> and native, so the allocation that didn't require a bunch of renaming for
> consistency was to introduce `refersToImpl` to provide the virtual part.
> 
> For this PR we have a method that is already intrinsic and virtual. Of course,
> we don't want to make it native too. Since we already have all the machinary
> in place for `get` to be intrinsic and virtual, the allocation that didn't
> require a bunch of renaming for consistency was to introduce native `get0` for
> use as the non-intrinsic implementation of `get`. See also here:
> https://github.com/openjdk/jdk/pull/24315#discussion_r2039137923

The current limitation of intrinsics support in C1/C2 is that intrinsics are always applied in the context of some method (as part of inlining). If a method is at the root of the compilation, it is never intrinsified.

The problem with virtual intrinsic methods is that when devirtualization fails, the call site ends up permanently calling into non-intrinsified version. That's what `refersTo0` initially suffered (fixed by JDK-8271862). `Reference::refersTo0` was virtual intrinsic method (no intrinsic when no inlining, hence call into native) and once it was untangled (virtual `refersToImpl` calls non-virtual intrinsic  method `refersTo0`) intrinsification happens reliably in the context of `refersToImpl`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2112996693

From xgong at openjdk.org  Thu May 29 01:47:56 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 29 May 2025 01:47:56 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v6]
In-Reply-To: <Di5SQQr4tO4H1VnO-GY1n8JLFtOcH3FID9sGvlRnF1Y=.04e918b6-2efb-426e-9d38-281c08ddc7d7@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <oDd6wkHsAQU3IUV3qCvjtqZ8BSHt7Qq2sx0Yy0Q8onc=.8e7db79c-15a5-4151-ac60-73f114433383@github.com>
 <Di5SQQr4tO4H1VnO-GY1n8JLFtOcH3FID9sGvlRnF1Y=.04e918b6-2efb-426e-9d38-281c08ddc7d7@github.com>
Message-ID: <PSAOxtbUtgWE5qIjFqSrfKkr40Ig4grY7-GUVB3NRDE=.3047e122-7362-48bf-b428-4c9577bc9f6f@github.com>

On Wed, 28 May 2025 12:26:31 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Refactor the JTReg tests for compare.xor(maskAll)
>>    
>>    Also made a bit change to support pattern `VectorMask.fromLong()`.
>>  - Merge branch 'master' into JDK-8354242
>>  - Refactor code
>>    
>>    Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
>>    optimization, making the code more modular.
>>  - Merge branch 'master' into JDK-8354242
>>  - Update the jtreg test
>>  - Merge branch 'master' into JDK-8354242
>>  - Addressed some review comments
>>    
>>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>>    2. Improve code comments.
>>  - Merge branch 'master' into JDK-8354242
>>  - Merge branch 'master' into JDK-8354242
>>  - 8354242: VectorAPI: combine vector not operation with compare
>>    
>>    This patch optimizes the following patterns:
>>    For integer types:
>>    ```
>>    (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    ```
>>    cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>>    negative comparison of cond.
>>    
>>    For float and double types:
>>    ```
>>    (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    ```
>>    cond can be eq or ne.
>>    
>>    Benchmarks on Nvidia Grace machine with 128-bit SVE2:
>>    With option `-XX:UseSVE=2`:
>>    ```
>>    Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>>    testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>>    testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>>    testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>>    testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>>    testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>>    testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>>    testCompareGEMaskNotByte	ops/s	7907615.16	4...
>
> test/micro/org/openjdk/bench/jdk/incubator/vector/MaskCompareNotBenchmark.java line 49:
> 
>> 47:     private static final VectorSpecies<Long> L_SPECIES = LongVector.SPECIES_MAX;
>> 48:     private static final VectorSpecies<Float> F_SPECIES = FloatVector.SPECIES_MAX;
>> 49:     private static final VectorSpecies<Double> D_SPECIES = DoubleVector.SPECIES_MAX;
> 
> Are you taking `SPECIES_MAX` on purpose here, or could we take `SPECIES_PREFERRED` instead?
> @jatin-bhateja What is the best to do in these tests? I suppose best would be to test with all vector lengths...

Thanks for pointing out this @eme64 ! Per my understanding, `SPECIES_MAX` is almost the same with `SPECIES_PREFERRED` in this case which are all specified to the max vector size of a hardware. Since the max vector size is different on different architectures, not all vector lengths are supported to be intrinsified on a specified architecture like AArch64, especially the SVE arch with different vector register size. Hence, just testing the max species makes sense to me as this is a mid-end common transformation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2113020416

From asemenyuk at openjdk.org  Thu May 29 02:51:51 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 29 May 2025 02:51:51 GMT
Subject: RFR: 8351369: [macos] Use --install-dir option with DMG packaging
In-Reply-To: <ZL8Yr8z1ySIcF8afE4ne54GjH30f3EhmDCDBGdmfo4M=.7949dac1-5600-472e-9dac-37681617b27d@github.com>
References: <kzagV86LsE-55gtYItG-NVpkQwhj229GhyxEcnMS9ig=.7a5fbe15-004a-471d-a095-26c2b8147179@github.com>
 <ZL8Yr8z1ySIcF8afE4ne54GjH30f3EhmDCDBGdmfo4M=.7949dac1-5600-472e-9dac-37681617b27d@github.com>
Message-ID: <295sVL5aWn8f5is2AyKBUpaohGuJKekozOwoa1j-zXs=.fbba5120-90b8-4730-878e-5fd6a4eba6fe@github.com>

On Wed, 28 May 2025 22:30:25 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - `--install-dir` option in DMG packaging is no longer ignored.
>> - Defaults are still the same: `/Applications` and `/Library/Java/JavaVirtualMachines`.
>> - If the installation directory doesn't exist, jpackage will try to create and delete it right after the DMG package is created.
>> - If jpackage was unable to create installation directory error will be thrown or if installation directory points to invalid location like file.
>> - It will be user responsibility to make sure installation directory exist on target machine, since DMG cannot create directories during drag and drop.
>> - Target directory in case of non-default installation dir will display full path. See image below for example.
>> 
>> ![Screenshot 2025-05-28 at 12 07 53?AM](https://github.com/user-attachments/assets/fbcba07b-74a5-4276-90c3-5f8d2d0dcc16)
>
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackageBuilder.java line 101:
> 
>> 99:                     Log.verbose(ex);
>> 100:                     throw new RuntimeException(ex);
>> 101:                 }
> 
> This code should be in a separate function covered with unit tests.
> 
> The core of this code is a general-purpose function that takes a path as input, finds the first nonexistent path component, and creates it as a directory. It should be a part of PathUtils. Probably without creating a directory part. Something like `Optional<Path> PathUtils.findFirstNonExistingComponent(Path path)`.

Another issue with this code is that it creates a directory during the configuration phase. Files/directories should be created at the packaging phase. Another reason to move it into MacDmgPackager.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25481#discussion_r2113071605

From david.holmes at oracle.com  Thu May 29 05:19:39 2025
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 29 May 2025 15:19:39 +1000
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <CAKD1RYscAh46O77zw=S68DefM9Aonnn7DjCB_8YJ-eWTKSpNDQ@mail.gmail.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtAUfyUHOdmSeZ2Azny=RJU63FQozY2NxpYu-4xQYCRkA@mail.gmail.com>
 <MW4PR10MB5774B089653C902899FEBEAFFFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB5774BB2B60EE5A1F4B1A7306FFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvxZ0gpHJXW0ctuHwEGwfStfjmLvwV1CgSWrr8438rWPA@mail.gmail.com>
 <MW4PR10MB5774EF4D4316B5BE46B29A0EFFF12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYsJyHeEs1fc4DRTZKwDO_U4Pyjv45BQ5fvr6VbboaVCTQ@mail.gmail.com>
 <MW4PR10MB57743363CCA3306B316F3EEDFF65A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYuPzVW+VHt_MzOrXW93iNv0A03JFSCV+yawCFeaLm=HsA@mail.gmail.com>
 <CAKD1RYtpahV4766wNodvcrSGFqJ6ereG1fUJFi-yEviOpLcb=Q@mail.gmail.com>
 <MW4PR10MB577459221CD425EFD5686426FF67A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYscAh46O77zw=S68DefM9Aonnn7DjCB_8YJ-eWTKSpNDQ@mail.gmail.com>
Message-ID: <3f9e1798-2edb-47b9-9d33-b455055dbcf5@oracle.com>

On 29/05/2025 3:45 am, Jige Yu wrote:
> 17.2.4 is specifically about the Object wait()/notify() API, yeah?
> 
> I've always had this confusion in my mind that I couldn't find an 
> authoritative source for: what was the point of checked 
> InterruptedException?

Interruption and IE provide a limited capability for task cancellation. 
As such any method that calls a method that can throw IE has to be aware 
that the method can do that, and by having IE be checked, they are 
forced to confront the question: how do I respond to cancellation? As 
Doug Lea describes in his book there are a few ways to respond to this 
cancellation notice depending on the semantics of the method involved:

- make cancellation part of your own API, declare and rethrow any IE 
should encounter (and your caller then has to make the choice)
- absorb cancellation into your general API contract and catch the IE 
and throw a more semantically specific exception
- handle low-level cancellation by catching the IE and doing whatever 
logic is appropriate

David
-----

> My naive observation has been two fold:
> 
>  1. In most cases, when possible, applications declare "throws IE" and
>     let it propagate all the way up the call stack. This works exactly
>     the same as if IE were unchecked.
>  2. When the application is cornered into a Runnable, Function?and
>     cannot "throws IE", it has to catch(IE),? remember to re-interrupt
>     the thread, and wrap in an unchecked. Except *it often forgets to
>     re-interrupt*.
> 
> At the lowest level concurrent primitives (wait(), notify(), Semaphore), 
> I presume IE being an integral part of the API contract.
> 
> But at mid-level APIs (Future, mapConcurrent()), or high-level 
> applications, I've always been at a loss on why we needed the checked IE 
> in the first place.
> 
> IE used to happen when someone calls Future.cancel(true). Now with 
> structured concurrency, it can also be caused by a sibling task failing 
> and fail-fast.
> 
> But aside from the extra ceremony and the extra room for error 
> (forgetting to reinterrupt), what do we get from it? I was asking 
> ChatGPT about real-life scenarios where specifically catching and 
> handling IE is necessary but all ChatGPT gave me was cases where the 
> code has to re-interrupt, which would have been unnecessary if IE were 
> unchecked and didn't clear the interruption bit.
> 
> Would appreciate a pointer to code or authoritative discussion about 
> this matter.
> 
> Sorry for the tangent!
> 
> 
> On Wed, May 28, 2025 at 1:03?AM Viktor Klang <viktor.klang at oracle.com 
> <mailto:viktor.klang at oracle.com>> wrote:
> 
>     It would seem to require a change to the Java Language Specification
>     section 17.2.4
> 
>     Cheers,
>     ?
> 
>     *
>     *
>     *Viktor Klang*
>     Software Architect, Java Platform Group
>     Oracle
>     ------------------------------------------------------------------------
>     *From:* Jige Yu <yujige at gmail.com <mailto:yujige at gmail.com>>
>     *Sent:* Wednesday, 28 May 2025 00:35
>     *To:* Viktor Klang <viktor.klang at oracle.com
>     <mailto:viktor.klang at oracle.com>>
>     *Cc:* core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org>
>     <core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org>>
>     *Subject:* Re: [External] : Re: mapConcurrent() with
>     InterruptedException
>     That said, I'm still curious. Have you considered propagating
>     cancellation, re-interrupting the current thread, and then throwing
>     an unchecked exception upon interruption? It's going to be the most
>     fail-fast-compatible.
> 
>     catch (IE interrupted) {
>      ? cancel all pending futures
>      ? Thread.currentThread().interrupt();
>      ? throw new UncheckedInterruptedException();
>     }
> 
>     What are the concerns against?such practice?
> 
> 
> 
> 
> 
>     On Mon, May 26, 2025 at 8:31?AM Jige Yu <yujige at gmail.com
>     <mailto:yujige at gmail.com>> wrote:
> 
>         Yeah, I think I missed the task cancellation and the joining part.
> 
>         When the mapConcurrent() thread is interrupted, it propagates
>         the cancellation to the child threads.
> 
>         And if any of the children threads (running the user-provided
>         Function) receives that cancellation, it will still need to
>         catch it and handle interruption.
> 
>         That means the interruption isn't swallowed. If the user code
>         wants to abort, they can always just throw an unchecked
>         exception and catch it from the caller of mapConcurrent().
> 
>         That should do for most of the IO type work.
> 
>         This makes sense.
> 
> 
> 
>         On Mon, May 26, 2025 at 12:30?AM Viktor Klang
>         <viktor.klang at oracle.com <mailto:viktor.klang at oracle.com>> wrote:
> 
>             Yes, the updated Gatherers.mapConcurrent will continue under
>             interruption until done, and then restore the interrupt
>             status of the calling thread.
> 
>             It cannot (reasonably) do anything else?if it were to throw
>             InterruptedException, it couldn't since that is a checked
>             exception and there's no tracking of checked exceptions
>             throughout a Stream, and that is the specified behavior to
>             handle thread interrupts (i.e. clear flag and throw
>             InterruptedException, which is not possible in this case;
>             or, make sure that interrupt status is maintained, which is
>             possible in this case.
> 
>             I have given it some more thought in the meantime, but I
>             haven't arrived in something more satisfactory than that, yet.
> 
>             Cheers,
>             ?
> 
>             *
>             *
>             *Viktor Klang*
>             Software Architect, Java Platform Group
>             Oracle
>             ------------------------------------------------------------------------
>             *From:* Jige Yu <yujige at gmail.com <mailto:yujige at gmail.com>>
>             *Sent:* Monday, 26 May 2025 03:07
>             *To:* Viktor Klang <viktor.klang at oracle.com
>             <mailto:viktor.klang at oracle.com>>
>             *Cc:* core-libs-dev at openjdk.org <mailto:core-libs-
>             dev at openjdk.org> <core-libs-dev at openjdk.org <mailto:core-
>             libs-dev at openjdk.org>>
>             *Subject:* Re: [External] : Re: mapConcurrent() with
>             InterruptedException
>             Thanks Viktor!
> 
>             Sorry, I was giving myself more time to read the code, but
>             then I lost track.
> 
>             If I'm reading the code right, the current behavior is that
>             if the current thread is interrupted, the mapConcurrent()
>             would suppress?the interruption until all elements are
>             processed? (It will then restore the interruption bit)
> 
>             Doesn't this break fail fast?
> 
>             For example, I may have a mapConcurrent() called from within
>             structured concurrency, and that fans out to two operations:
>             ?
>             scope.fork(() -> doA());
>             scope.fork(() -> doB());? // calls mapConcurrent() internally
>             scope.join().throwIfFailed();
> 
>             If doA() fails, doB() will be cancelled (thread interrupted).
> 
>             If mapConcurrent() ignores the interruption, and if doB has
>             a long list to process, it'll continue to consume system
>             resources even when the caller no longer needs?the results, no?
> 
> 
>             On Fri, Feb 7, 2025 at 2:16?AM Viktor Klang
>             <viktor.klang at oracle.com <mailto:viktor.klang at oracle.com>>
>             wrote:
> 
>                  >Sorry, did the PR stop using Semaphore?
> 
>                 No, not that PR. See: https://github.com/openjdk/jdk/
>                 commit/450636ae28b84ded083b6861c6cba85fbf87e16e
>                 <https://urldefense.com/v3/__https://github.com/openjdk/
>                 jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e__;!!
>                 ACWV5N9M2RV99hQ!
>                 OKfWrvJEDCkiHcT5b4a6gfeomZzZeq3jv6ir2vf2I5WWIhujtb-
>                 by_VuQFaAPDIuAA0qAwpTUjllXMPF$>
> 
>                 The problem with interruption under parallel evaluation
>                 is that there is no general support for propagation of
>                 interruption in CountedCompleters. Adding support for
>                 such in (at least) GathererOp needs further study before
>                 contemplating making any changes to mapConcurrent()'s
>                 interruption policy.
> 
>                 Cheers,
>                 ?
> 
>                 *
>                 *
>                 *Viktor Klang*
>                 Software Architect, Java Platform Group
>                 Oracle
> 
>                 ------------------------------------------------------------------------
>                 *From:*?Jige Yu <yujige at gmail.com <mailto:yujige at gmail.com>>
>                 *Sent:*?Thursday, 6 February 2025 17:04
>                 *To:*?Viktor Klang <viktor.klang at oracle.com
>                 <mailto:viktor.klang at oracle.com>>
>                 *Cc:* core-libs-dev at openjdk.org <mailto:core-libs-
>                 dev at openjdk.org> <core-libs-dev at openjdk.org
>                 <mailto:core-libs-dev at openjdk.org>>
>                 *Subject:*?Re: [External] : Re: mapConcurrent() with
>                 InterruptedException
>                 Sorry, did the PR stop using Semaphore?
> 
>                 I had naively thought that mapConcurrent() will keep a
>                 buffer of Future of all currently-running concurrent
>                 tasks (it can be a ConcurrentMap<TaskKey, Future> if we
>                 don't have to ensure FIFO).
> 
>                 Upon interruption, the main thread can
>                 call .cancel(true) on all pending Futures; optionally
>                 join with the VTs (if we need to block until all VTs
>                 exit); then propagate exception.
> 
>                 Upon completion, each task just removes itself from the
>                 ConcurrentMap.
> 
>                 Just in case it adds anything.
> 
> 
> 
>                 On Thu, Feb 6, 2025 at 6:47?AM Viktor Klang
>                 <viktor.klang at oracle.com
>                 <mailto:viktor.klang at oracle.com>> wrote:
> 
>                     After some more investigation it seems tractable to
>                     propagate interruption of the caller in sequential
>                     mode, but parallel mode will require much bigger
>                     considerations.
> 
>                     I made a comment to that effect on the JBS issue:
>                     https://bugs.openjdk.org/browse/JDK-8349462?
>                     focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017 <https://bugs.openjdk.org/browse/JDK-8349462?focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017>
> 
> 
>                     Cheers,
>                     ?
> 
>                     *
>                     *
>                     *Viktor Klang*
>                     Software Architect, Java Platform Group
>                     Oracle
>                     ------------------------------------------------------------------------
>                     *From:*?Viktor Klang <viktor.klang at oracle.com
>                     <mailto:viktor.klang at oracle.com>>
>                     *Sent:*?Thursday, 6 February 2025 11:51
>                     *To:*?Jige Yu <yujige at gmail.com
>                     <mailto:yujige at gmail.com>>
>                     *Cc:* core-libs-dev at openjdk.org <mailto:core-libs-
>                     dev at openjdk.org>?<core-libs-dev at openjdk.org
>                     <mailto:core-libs-dev at openjdk.org>>
>                     *Subject:*?Re: [External] : Re: mapConcurrent() with
>                     InterruptedException
>                     I think alignment in behavior between parallel
>                     Stream and mapConcurrent in terms of how
>                     interruptions are handled is a possible path forward.
> 
>                     I decided to close the PR for now as I realized my
>                     parallel Stream example had misled me regarding its
>                     exception throwing, so I'll need to go back and
>                     refine the solution.
> 
>                     It still seems solvable though.
> 
>                     Cheers,
>                     ?
> 
>                     *
>                     *
>                     *Viktor Klang*
>                     Software Architect, Java Platform Group
>                     Oracle
>                     ------------------------------------------------------------------------
>                     *From:*?Jige Yu <yujige at gmail.com
>                     <mailto:yujige at gmail.com>>
>                     *Sent:*?Wednesday, 5 February 2025 19:20
>                     *To:*?Viktor Klang <viktor.klang at oracle.com
>                     <mailto:viktor.klang at oracle.com>>
>                     *Cc:* core-libs-dev at openjdk.org <mailto:core-libs-
>                     dev at openjdk.org>?<core-libs-dev at openjdk.org
>                     <mailto:core-libs-dev at openjdk.org>>
>                     *Subject:*?Re: [External] : Re: mapConcurrent() with
>                     InterruptedException
>                     Oh good call!
> 
>                     I forgot to check what parallel streams do upon
>                     interruption (didn't think they do any blocking
>                     calls, but at least the main thread must block).
> 
>                     On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang
>                     <viktor.klang at oracle.com
>                     <mailto:viktor.klang at oracle.com>> wrote:
> 
>                         Hi Jige,
> 
>                         I opened an issue to track the concern, and I
>                         have proposed a change which seems to align well
>                         with how parallel streams behave under caller
>                         thread interruption.
> 
>                         I've opened the following PR for review:
>                         https://github.com/openjdk/jdk/pull/23467
>                         <https://urldefense.com/v3/__https://github.com/
>                         openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!
>                         M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
> 
>                         If you are able to make a local OpenJDK build
>                         with that solution you could check if it
>                         addresses your use-cases (or not).
>                         <https://urldefense.com/v3/__https://github.com/
>                         openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!
>                         M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
>                         	
>                         8349462: Gatherers.mapConcurrent could support
>                         async interrupts by viktorklang-ora ? Pull
>                         Request #23467 ? openjdk/jdk <https://
>                         urldefense.com/v3/__https://github.com/openjdk/
>                         jdk/pull/23467__;!!ACWV5N9M2RV99hQ!
>                         M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
>                         This change is likely going to need some extra
>                         verbiage in the spec for mapConcurrent, and thus
>                         a CSR. This behavior aligns mapConcurrent with
>                         how parallel streams work in conjunction with
>                         interrup...
>                         github.com <https://urldefense.com/v3/__http://
>                         github.com__;!!ACWV5N9M2RV99hQ!
>                         M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89DBkMefT$>
> 
> 
> 
>                         Cheers,
>                         ?
> 
>                         *
>                         *
>                         *Viktor Klang*
>                         Software Architect, Java Platform Group
>                         Oracle
>                         ------------------------------------------------------------------------
>                         *From:*?Jige Yu <yujige at gmail.com
>                         <mailto:yujige at gmail.com>>
>                         *Sent:*?Wednesday, 5 February 2025 16:24
>                         *To:*?Viktor Klang <viktor.klang at oracle.com
>                         <mailto:viktor.klang at oracle.com>>
>                         *Cc:* core-libs-dev at openjdk.org <mailto:core-
>                         libs-dev at openjdk.org>?<core-libs-dev at openjdk.org
>                         <mailto:core-libs-dev at openjdk.org>>
>                         *Subject:*?Re: [External] : Re: mapConcurrent()
>                         with InterruptedException
>                         Thanks Viktor!
> 
>                         I understand?the problem.
> 
>                         The main?reason I asked is because I want to
>                         understand how the core Java team thinks of
>                         throwing an unchecked exception.
> 
>                         As explained above, I consider losing
>                         cancellability a big deal, a deal breaker even.
>                         And I thought throwing unchecked is more
>                         acceptable. Because the most common reason the
>                         mapConcurrent() VT can be interrupted is due to
>                         cancellation from a parent mapConcurrent(), or a
>                         parent Structured Concurrency scope. The
>                         cancellation could be either from an organic
>                         exception, or from the downstream not needing
>                         more elements, like maybe due to findFirst()
>                         already getting an element.
> 
>                         In both cases, since the concurrent operation is
>                         already cancelled (result ignored), what
>                         exception pops up to the top level isn't that
>                         big of a deal (perhaps only a log record will be
>                         seen?)
> 
>                         But if the core Java team considers it a bad
>                         idea, I would love to learn and adjust.
> 
>                         On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang
>                         <viktor.klang at oracle.com
>                         <mailto:viktor.klang at oracle.com>> wrote:
> 
>                             Hi,
> 
>                             The problem is that mapConcurrent cannot
>                             throw InterruptedException because that is a
>                             checked exception, so we cannot clear the
>                             interrupted flag and throw that exception.
> 
>                             So the updated semantics is to not cut the
>                             stream short but instead run to completion,
>                             restoring the interruption flag.
> 
>                             There exists a couple of alternatives to
>                             this approach which I am contemplating, but
>                             they need to be further explored before I
>                             consider moving forward with any of them.
> 
>                             Cheers,
>                             ?
> 
>                             *
>                             *
>                             *Viktor Klang*
>                             Software Architect, Java Platform Group
>                             Oracle
>                             ------------------------------------------------------------------------
>                             *From:*?Jige Yu <yujige at gmail.com
>                             <mailto:yujige at gmail.com>>
>                             *Sent:*?Monday, 27 January 2025 17:00
>                             *To:*?Viktor Klang <viktor.klang at oracle.com
>                             <mailto:viktor.klang at oracle.com>>
>                             *Cc:* core-libs-dev at openjdk.org
>                             <mailto:core-libs-dev at openjdk.org>?<core-
>                             libs-dev at openjdk.org <mailto:core-libs-
>                             dev at openjdk.org>>
>                             *Subject:*?Re: [External] : Re:
>                             mapConcurrent() with InterruptedException
>                             Thanks Viktor!
> 
>                             It looks like the current fix ignores
>                             interruption.
> 
>                             I want to make sure my concern of it
>                             defeating cancellation is heard and understood.
> 
>                             The scenarios I worry about is for a
>                             mapConcurrent() that fans out to another
>                             method call, which internally calls
>                             mapConcurrent() as implementation detail.
> 
>                             An example:
> 
>                             List<RefundResponse>
>                             refundHelper(transaction)
>                             { ?transaction.creditCardAccounts.stream()  
>                              ?.gather(mapConcurrent(acct ->
>                             service.refund(acct)) ? ?.toList(); }
>                             transactions.stream()  
>                              ?.gather(mapConcurrent(transaction ->
>                             refundHelper(transaction));
> 
> 
>                             It seems undesirable?that in such a case all
>                             the service.refund() calls become non
>                             cancellable, because the only way the outer
>                             mapConcurrent() cancels the refundHelper()
>                             calls is through Thread.interrupt() the
>                             virtual threads that call refundHelper(),
>                             which would then be disabled by the inner
>                             mapConcurrent().
> 
>                             Does this example make sense to you? I can
>                             further explain if anything isn't clear.
> 
>                             But I want to make sure the decision to
>                             disable interruption is deliberate judgement
>                             call that such nested mapConcurrent() is
>                             unlikely,or not important.
> 
>                             Cheers,
> 
> 
> 
>                             On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang
>                             <viktor.klang at oracle.com
>                             <mailto:viktor.klang at oracle.com>> wrote:
> 
>                                 Hi!
> 
>                                 Please see: https://github.com/openjdk/
>                                 jdk/pull/23100 <https://urldefense.com/
>                                 v3/__https://github.com/openjdk/jdk/
>                                 pull/23100__;!!ACWV5N9M2RV99hQ!
>                                 IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>
> 
>                                 Cheers,
>                                 ?
> 
>                                 *
>                                 *
>                                 *Viktor Klang*
>                                 Software Architect, Java Platform Group
>                                 Oracle
>                                 ------------------------------------------------------------------------
>                                 *From:*?Jige Yu <yujige at gmail.com
>                                 <mailto:yujige at gmail.com>>
>                                 *Sent:*?Sunday, 26 January 2025 23:03
>                                 *To:*?Viktor Klang
>                                 <viktor.klang at oracle.com
>                                 <mailto:viktor.klang at oracle.com>>
>                                 *Cc:* core-libs-dev at openjdk.org
>                                 <mailto:core-libs-
>                                 dev at openjdk.org>?<core-libs-
>                                 dev at openjdk.org <mailto:core-libs-
>                                 dev at openjdk.org>>
>                                 *Subject:*?[External] : Re:
>                                 mapConcurrent() with InterruptedException
>                                 Checking in on what you've found out,
>                                 Viktor.
> 
>                                  From where we left off, I understand
>                                 that you were looking at alternatives
>                                 instead of silent truncation?
> 
>                                 Have you reached any conclusion?
> 
>                                 We touched on disallowing interruption
>                                 during mapConcurrent(). I still have
>                                 concerns with disabling cancellation,
>                                 because it basically undoes this API
>                                 note from the javadoc <https://
>                                 cr.openjdk.org/~alanb/sc-20240503/
>                                 java.base/java/util/stream/
>                                 Gatherers.html#mapConcurrent(int,java.util.function.Function)>:
> 
>                                 API Note:
> 
>                                     In progress tasks will be attempted
>                                     to be cancelled, on a best-effort
>                                     basis, in situations where the
>                                     downstream no longer wants to
>                                     receive any more elements.
> 
>                                 In reality, people will use
>                                 mapConcurrent() to fan out rpcs.
>                                 Sometimes these rpcs are just a single
>                                 blocking call; yet sometimes they may
>                                 themselves be a Structured Concurrency
>                                 scope, with 2 or 3 rpcs that constitute
>                                 a single logical operation. Under two
>                                 conditions, cancellation is imho
>                                 important semantic:
> 
>                                  1. The downstream code uses
>                                     filter().findFirst(), and when it
>                                     sees an element, it will return and
>                                     no longer needs the other pending
>                                     rpcs to complete. If cancellation is
>                                     disabled, these unnecessary?rpcs
>                                     will waste system resources.
>                                  2. One of the rpc throws and the Stream
>                                     pipeline needs to propagate the
>                                     exception. Again, if the other rpcs
>                                     cannot be cancelled, we'll have many
>                                     zombie rpcs.
> 
>                                 Zombie rpcs may or may not be a deal
>                                 breaker, depending on the specific use
>                                 case. But for a JDK library, losing
>                                 cancellation would have a negative
>                                 impact on usability.
> 
>                                 My 2c,
> 
> 
>                                 On Fri, Jan 3, 2025 at 9:18?AM Viktor
>                                 Klang <viktor.klang at oracle.com
>                                 <mailto:viktor.klang at oracle.com>> wrote:
> 
>                                     Hi Ben,
> 
>                                     Thanks for raising these questions?
>                                     getting feedback is crucial in the
>                                     Preview stage of features.
> 
>                                     I wrote a reply to the Reddit thread
>                                     so I'll just summarize here:
> 
>                                     It is important to note that /
>                                     mapConcurrent()/?is not a part of
>                                     the Structured Concurrency JEPs, so
>                                     it is not designed to join SC scopes.
> 
>                                     I'm currently experimenting with
>                                     ignoring-but-restoring interrupts on
>                                     the "calling thread" for /
>                                     mapConcurrent()/, as well as capping
>                                     work-in-progress to /
>                                     maxConcurrency/?(not only capping
>                                     the concurrency but also the amount
>                                     of completed-but-yet-to-be-pushed
>                                     work). Both of these adjustments
>                                     should increase predictability of
>                                     behavior in the face of blocking
>                                     operations with variable delays.
> 
>                                     Another adjustment I'm looking at
>                                     right now is to harden/improve the
>                                     cleanup to wait for concurrent tasks
>                                     to acknowledge cancellation, so that
>                                     once the finisher is done executing
>                                     the VTs are known to have terminated.
> 
>                                     As for not preserving the encounter
>                                     order, that would be a completely
>                                     different thing, and I'd encourage
>                                     you to experiment with that if that
>                                     functionality would be interesting
>                                     for your use-case(s).
> 
>                                     Again, thanks for your feedback!
> 
>                                     Cheers,
>                                     ?
> 
>                                     *
>                                     *
>                                     *Viktor Klang*
>                                     Software Architect, Java Platform Group
>                                     Oracle
>                                     ------------------------------------------------------------------------
>                                     *From:*?core-libs-dev <core-libs-
>                                     dev-retn at openjdk.org <mailto:core-
>                                     libs-dev-retn at openjdk.org>> on
>                                     behalf of Jige Yu <yujige at gmail.com
>                                     <mailto:yujige at gmail.com>>
>                                     *Sent:*?Friday, 3 January 2025 17:53
>                                     *To:* core-libs-dev at openjdk.org
>                                     <mailto:core-libs-
>                                     dev at openjdk.org>?<core-libs-
>                                     dev at openjdk.org <mailto:core-libs-
>                                     dev at openjdk.org>>
>                                     *Subject:*?mapConcurrent() with
>                                     InterruptedException
>                                     Hi Java Experts,
> 
>                                     I sent this email incorrectly to
>                                     loom-dev@ and was told on Reddit
>                                     that core-libs-dev is the right list.
> 
>                                     The question is about the behavior
>                                     of mapConcurrent() when the thread
>                                     is interrupted.
> 
>                                     Currently mapConcurrent()'s finisher
>                                     phase will re-interrupt?the thread,
>                                     then stop at whatever element that
>                                     has already been processed and return.
> 
>                                     This strikes me as a surprising
>                                     behavior, because for example if I'm
>                                     running:
> 
>                                      ? ?Stream.of(1, 2, 3)
>                                      ? ? ? ? .gather(mapConcurrent(i ->
>                                     i * 2))
>                                      ? ? ? ? .toList()
> 
>                                     and the thread is being interrupted,
>                                     the result could be any of [2], [2,
>                                     4] or [2, 4, 6].
> 
>                                     Since thread interruption is
>                                     cooperative, there is no guarantee
>                                     that the thread being interrupted
>                                     will just abort. It's quite possible
>                                     that it'll keep going and then will
>                                     use for example [2] as the result of
>                                     doubling the list of [1, 2, 3],
>                                     which is imho incorrect.
> 
>                                     In the Reddit <https://
>                                     urldefense.com/v3/__https://
>                                     www.reddit.com/r/java/
>                                     comments/1hr8xyu/
>                                     observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$>?thread, someone argued that interruption rarely happens so it's more of a theoretical issue. But interruption can easily happen in Structured Concurrency or in mapConcurrent() itself if any subtask has failed in order to cancel/interrupt the other ongoing tasks.
> 
>                                     There had been discussion about
>                                     alternative strategies:
> 
>                                      1. Don't respond to interruption
>                                         and just keep running to completion.
>                                      2. Re-interrupt thread and wrap the
>                                         InterruptedException in a
>                                         standard unchecked exception
>                                         (StructuredConcurrencyInterruptedException?).
> 
> 
>                                     I have concerns with option 1
>                                     because it disables cancellation
>                                     propagation when mapConcurrent()
>                                     itself is used in a subtask of a
>                                     parent mapConcurrent() or in a
>                                     StructuredConcurrencyScope.
> 
>                                     Both equivalent Future-composition
>                                     async code, or C++'s?fiber trees
>                                     support cancellation propagation and
>                                     imho it's a critical feature or else
>                                     it's possible that a zombie thread
>                                     is still sending RPCs long after the
>                                     main thread has exited (failed, or
>                                     falled back to some default action).
> 
>                                     My arguments for option 2:
> 
>                                      1. InterruptedException is more
>                                         error prone than traditional
>                                         checked exceptions for
>                                         *users*?to catch and handle.
>                                         They can forget to re-interrupt
>                                         the thread. It's so confusing
>                                         that even seasoned programmers
>                                         may not know they are *supposed
>                                         to*?re-interrupt the thread.
>                                      2. With Stream API using functional
>                                         interfaces like Supplier,
>                                         Function, the option of just
>                                         tacking on "throws IE" isn't
>                                         available to many users.
>                                      3. With Virtual Threads, it will be
>                                         more acceptable, or even become
>                                         common to do blocking calls from
>                                         a stream operation (including
>                                         but exclusive to
>                                         mapConcurrent()). So the chance
>                                         users are forced to deal with IE
>                                         will become substantially higher.
>                                      4. Other APIs such as the
>                                         Structured Concurrency API have
>                                         already started wrapping system
>                                         checked exceptions like
>                                         ExecutionException,
>                                         TimeoutException in unchecked
>                                         exceptions ( join() <https://
>                                         urldefense.com/v3/__https://
>                                         download.java.net/java/
>                                         early_access/loom/docs/api/
>                                         java.base/java/util/concurrent/
>                                         StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$>?for example).
>                                      5. Imho, exceptions that we'd
>                                         rather users not catch and
>                                         handle but instead should mostly
>                                         just propagate up as is, should
>                                         be unchecked.
> 
>                                     There is also a side discussion
>                                     <https://urldefense.com/v3/
>                                     __https://www.reddit.com/r/java/
>                                     comments/1hr8xyu/comment/m4z4f8c/?
>                                     utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$>?about whether mapConcurrent() is better off preserving input order or push to downstream as soon as an element is computed. I'd love to discuss that topic too but maybe it's better to start a separate thread?
> 
>                                     Thank you and cheers!
> 
>                                     Ben Yu
> 


From asotona at openjdk.org  Thu May 29 07:05:58 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 29 May 2025 07:05:58 GMT
Subject: RFR: 8357955: java.lang.classfile.Signature.ArrayTypeSig.of IAE
 not thrown for dims > 255
In-Reply-To: <UFmthl6dN4rXfEwI26Kgw1LHmk-U-RpnpD_cgOYuy90=.9cad06f8-46b4-404b-9fbf-ef3a44a45fec@github.com>
References: <UFmthl6dN4rXfEwI26Kgw1LHmk-U-RpnpD_cgOYuy90=.9cad06f8-46b4-404b-9fbf-ef3a44a45fec@github.com>
Message-ID: <VkeTmHmmCVnxH7Z-d6jk86NW3lSUUnP8-7lWrh02fXU=.ba4973b4-3c9a-482c-a6be-4782aa9d34ff@github.com>

On Wed, 28 May 2025 17:56:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> java.lang.classfile.Signature.ArrayTypeSig.of constraint check did not include dimensions of the given component if the component is an array.
> 
> This patch fixes the constraint check, corrects the @throws description and adds test of the subj.
> 
> Please review.
> 
> Thanks,
> Adam

Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25506#issuecomment-2918510609

From asotona at openjdk.org  Thu May 29 07:05:59 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 29 May 2025 07:05:59 GMT
Subject: Integrated: 8357955: java.lang.classfile.Signature.ArrayTypeSig.of IAE
 not thrown for dims > 255
In-Reply-To: <UFmthl6dN4rXfEwI26Kgw1LHmk-U-RpnpD_cgOYuy90=.9cad06f8-46b4-404b-9fbf-ef3a44a45fec@github.com>
References: <UFmthl6dN4rXfEwI26Kgw1LHmk-U-RpnpD_cgOYuy90=.9cad06f8-46b4-404b-9fbf-ef3a44a45fec@github.com>
Message-ID: <g_GjEFSfRliG8QKXsejUOVPIEXKyQMITh5fcbgDRPk8=.05c4b2f1-15ec-4466-a7a1-098c9b53edd7@github.com>

On Wed, 28 May 2025 17:56:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> java.lang.classfile.Signature.ArrayTypeSig.of constraint check did not include dimensions of the given component if the component is an array.
> 
> This patch fixes the constraint check, corrects the @throws description and adds test of the subj.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: d43f588d
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d43f588db1b39724da2823b73fe09f8609fd8e48
Stats:     24 lines in 2 files changed: 19 ins; 2 del; 3 mod

8357955: java.lang.classfile.Signature.ArrayTypeSig.of IAE not thrown for dims > 255

Reviewed-by: jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/25506

From duke at openjdk.org  Thu May 29 07:57:56 2025
From: duke at openjdk.org (erifan)
Date: Thu, 29 May 2025 07:57:56 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v6]
In-Reply-To: <9u6hJ-WgnHLMaYBa8ViRdpUZY-bI2wOk-TCRKWJJdqk=.b3303f1f-da3b-4c2e-8f0c-a2e16ba9688e@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <oDd6wkHsAQU3IUV3qCvjtqZ8BSHt7Qq2sx0Yy0Q8onc=.8e7db79c-15a5-4151-ac60-73f114433383@github.com>
 <Di5SQQr4tO4H1VnO-GY1n8JLFtOcH3FID9sGvlRnF1Y=.04e918b6-2efb-426e-9d38-281c08ddc7d7@github.com>
 <9u6hJ-WgnHLMaYBa8ViRdpUZY-bI2wOk-TCRKWJJdqk=.b3303f1f-da3b-4c2e-8f0c-a2e16ba9688e@github.com>
Message-ID: <WWv5dtJhaETpblalKdNVW3en9M6rpmDM7aCP_XloaYU=.893365f9-ebfd-4d86-bf27-62be0bdd590e@github.com>

On Wed, 28 May 2025 12:16:23 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/share/opto/vectornode.cpp line 2244:
>> 
>>> 2242:   // BoolTest doesn't support unsigned comparisons.
>>> 2243:   BoolTest::mask neg_cond =
>>> 2244:       (BoolTest::mask) (((VectorMaskCmpNode*) in1)->get_predicate() ^ 4);
>> 
>> What is the hard-coded `^ 4` here? This whole line looks like we are looking at internals of the `VectorMaskCmpNode` or its predicate, and we should probably do that in some method there? Or maybe it should be part of the `BoolTest(::mask)` interface?
>
> Also: You now cast `(VectorMaskCmpNode*) in1` twice. Can we not do `as_VectorMaskCmp()`? Or could we at least cast it only once, and then use it as `in1_mask_cmp` instead?

> What is the hard-coded ^ 4 here?

This is to negate the comparison condition. We can't use `BoolTest::negate()` here because the comparison condition may be **unsigned** comparison. Since there's already a `negate()` function in `BoolTest`, so I tend to add a new function `get_negative_predicate` for this into class `VectorMaskCmpNode`.

> Also: You now cast (VectorMaskCmpNode*) in1 twice. Can we not do as_VectorMaskCmp()? Or could we at least cast it only once, and then use it as in1_mask_cmp instead?

For the first cast, I think you mean

  if (in1->Opcode() != Op_VectorMaskCmp ||
      in1->outcnt() > 1 ||
      !((VectorMaskCmpNode*) in1)->predicate_can_be_negated() ||
      !VectorNode::is_all_ones_vector(in2)) {
    return nullptr;
  }

To remove one cast, then we have to split the above `if` because `in1` may not be a `VectorMaskCmpNode`.

  if (in1->Opcode() != Op_VectorMaskCmp) {
    return nullptr;
  }
  VectorMaskCmpNode* in1_as_mask_cmp = (VectorMaskCmpNode*) in1;
  if (in1->outcnt() > 1 ||
      !in1_as_mask_cmp->predicate_can_be_negated() ||
      !VectorNode::is_all_ones_vector(in2)) {
    return nullptr;
  }
 BoolTest::mask neg_cond = (BoolTest::mask) (in1_as_mask_cmp->get_predicate() ^ 4);

Does this look better to you ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2113423376

From duke at openjdk.org  Thu May 29 08:02:56 2025
From: duke at openjdk.org (erifan)
Date: Thu, 29 May 2025 08:02:56 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v6]
In-Reply-To: <Di5SQQr4tO4H1VnO-GY1n8JLFtOcH3FID9sGvlRnF1Y=.04e918b6-2efb-426e-9d38-281c08ddc7d7@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <oDd6wkHsAQU3IUV3qCvjtqZ8BSHt7Qq2sx0Yy0Q8onc=.8e7db79c-15a5-4151-ac60-73f114433383@github.com>
 <Di5SQQr4tO4H1VnO-GY1n8JLFtOcH3FID9sGvlRnF1Y=.04e918b6-2efb-426e-9d38-281c08ddc7d7@github.com>
Message-ID: <ANJVx2XVfd0JhiyYI1Ny1S9G6kvlYgVlA2hw30_BdzE=.88d7eba0-dc16-4d63-9b09-cd01abad03c4@github.com>

On Wed, 28 May 2025 12:12:50 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Refactor the JTReg tests for compare.xor(maskAll)
>>    
>>    Also made a bit change to support pattern `VectorMask.fromLong()`.
>>  - Merge branch 'master' into JDK-8354242
>>  - Refactor code
>>    
>>    Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
>>    optimization, making the code more modular.
>>  - Merge branch 'master' into JDK-8354242
>>  - Update the jtreg test
>>  - Merge branch 'master' into JDK-8354242
>>  - Addressed some review comments
>>    
>>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>>    2. Improve code comments.
>>  - Merge branch 'master' into JDK-8354242
>>  - Merge branch 'master' into JDK-8354242
>>  - 8354242: VectorAPI: combine vector not operation with compare
>>    
>>    This patch optimizes the following patterns:
>>    For integer types:
>>    ```
>>    (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    ```
>>    cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>>    negative comparison of cond.
>>    
>>    For float and double types:
>>    ```
>>    (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    ```
>>    cond can be eq or ne.
>>    
>>    Benchmarks on Nvidia Grace machine with 128-bit SVE2:
>>    With option `-XX:UseSVE=2`:
>>    ```
>>    Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>>    testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>>    testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>>    testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>>    testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>>    testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>>    testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>>    testCompareGEMaskNotByte	ops/s	7907615.16	4...
>
> src/hotspot/share/opto/vectornode.cpp line 2233:
> 
>> 2231:   if (in2->Opcode() == Op_VectorMaskCast) {
>> 2232:     in2 = in2->in(1);
>> 2233:   }
> 
> Wow, this seems to be an addition that is not covered in the patterns you mention above, right?
> But is that even necessary?
> I suppose here `in2 = VectorMaskCast(all_ones_vector)`.
> Would we not already want to transform this pattern in `VectorMaskCast::Ideal`, is that not possible and more powerful?

Oh yeah, I forgot to mention it in the above comment and commit message. 

Yes, this is for `in2 = VectorMaskCast(all_ones_vector)`.  I agree it's better to do this transformation in `VectorMaskCast::Ideal`. I'll remove this code change and do the `VectorMaskCast` optimization later. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2113430734

From duke at openjdk.org  Thu May 29 08:06:54 2025
From: duke at openjdk.org (erifan)
Date: Thu, 29 May 2025 08:06:54 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v6]
In-Reply-To: <9f_-MMP_SSYInzCTUc5scRzKOKN1jj4VcnGEYWoOF14=.2eca7e44-d1df-4e57-a513-d8ddaddc9ea2@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <oDd6wkHsAQU3IUV3qCvjtqZ8BSHt7Qq2sx0Yy0Q8onc=.8e7db79c-15a5-4151-ac60-73f114433383@github.com>
 <9f_-MMP_SSYInzCTUc5scRzKOKN1jj4VcnGEYWoOF14=.2eca7e44-d1df-4e57-a513-d8ddaddc9ea2@github.com>
Message-ID: <4a5PBPvkJGne0xghQtU2_IGLvh5ZLcTxr21zICMTuC8=.1f2697d9-e96e-4421-b07d-2f372f54f079@github.com>

On Fri, 16 May 2025 07:40:53 GMT, erifan <duke at openjdk.org> wrote:

>> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Refactor the JTReg tests for compare.xor(maskAll)
>>    
>>    Also made a bit change to support pattern `VectorMask.fromLong()`.
>>  - Merge branch 'master' into JDK-8354242
>>  - Refactor code
>>    
>>    Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
>>    optimization, making the code more modular.
>>  - Merge branch 'master' into JDK-8354242
>>  - Update the jtreg test
>>  - Merge branch 'master' into JDK-8354242
>>  - Addressed some review comments
>>    
>>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>>    2. Improve code comments.
>>  - Merge branch 'master' into JDK-8354242
>>  - Merge branch 'master' into JDK-8354242
>>  - 8354242: VectorAPI: combine vector not operation with compare
>>    
>>    This patch optimizes the following patterns:
>>    For integer types:
>>    ```
>>    (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    ```
>>    cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>>    negative comparison of cond.
>>    
>>    For float and double types:
>>    ```
>>    (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    ```
>>    cond can be eq or ne.
>>    
>>    Benchmarks on Nvidia Grace machine with 128-bit SVE2:
>>    With option `-XX:UseSVE=2`:
>>    ```
>>    Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>>    testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>>    testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>>    testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>>    testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>>    testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>>    testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>>    testCompareGEMaskNotByte	ops/s	7907615.16	4...
>
> Hi, I have updated the code and I'll file the patch to convert `VectorMask.fromLong(SPECIES, -1)` to `maskAll()` soon, I'll cover this test case in that patch. Would you please help review the patch again, thanks!

> @erifan Looks like you really improved things, nice work! I have some more comments below :)

I will modify the code according to your suggestions and commit again after all the test passes locally. Thanks for you careful review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-2918641646

From jbhateja at openjdk.org  Thu May 29 08:38:53 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 29 May 2025 08:38:53 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v4]
In-Reply-To: <72GCipLKeCWCG-4jsG5XhZKkTdVsWafEq_wA0oD-0mk=.c70af814-54fe-43d2-b7c9-72b845eb99d5@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <72GCipLKeCWCG-4jsG5XhZKkTdVsWafEq_wA0oD-0mk=.c70af814-54fe-43d2-b7c9-72b845eb99d5@github.com>
Message-ID: <kPx9NqOgNJPStCsPd4PtRhfbQeEXi5xbefvSjCHoPSY=.aa26a490-8f90-4e17-8c9e-cde0c25a9fbb@github.com>

On Wed, 28 May 2025 18:39:13 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The command to run all range specific micro-benchmarks is posted below.
>> 
>> `make test TEST="micro:CbrtPerf.CbrtPerfRanges"`
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs.
>> 
>> | Input range(s)                                  | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
>> | :-------------------------------------: | :-------------------------------: | :-------------------------------: | :---------: |
>> | [-2^(-1022), 2^(-1022)]                   | 6568                                        | 17678                                      | 2.69x       |
>> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932                                    | 200897                                    | 1.45x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Remove comment mentioning invalid exception when NaN input is provided
>  - Use rcx as base and r8 as index for address calculations in certain cbrt stub generator instructions
>  - Remove unnecessary unpckhpd and unpcklpd definitions in macro-assembler header file
>  - Remove unnecessary movapd definitions in macro-assembler header file

Patch looks good to me,  some comment included.

src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp line 185:

> 183: 
> 184: #define __ _masm->
> 185: 

Original Intel libm inline sequence uses hexadecimal constants, I would have preferred to use them as it is to maintain 1:1 mapping b/w instruction sequence.

test/micro/org/openjdk/bench/java/lang/CbrtPerf.java line 56:

> 54:     public static class CbrtPerfRanges {
> 55:         public static int cbrtInputCount = 2048;
> 56: 

Please create separate CbrtPerfSpecialValues for +/- 0.0 and +/- Infinity and NaN values.
I understand that handling special cases in intrinsic may impact general case performance but its ok to have atleast micro for it.

test/micro/org/openjdk/bench/java/lang/CbrtPerf.java line 114:

> 112:         public static final double constDouble512 = 512.0;
> 113: 
> 114:         @Benchmark

Baseline:-
Benchmark                                     (cbrtRangeIndex)   Mode  Cnt        Score   Error   Units
CbrtPerf.CbrtPerfConstant.cbrtConstDouble0                 N/A  thrpt    2  2673018.356          ops/ms
CbrtPerf.CbrtPerfConstant.cbrtConstDouble1                 N/A  thrpt    2  2684233.593          ops/ms
CbrtPerf.CbrtPerfConstant.cbrtConstDouble27                N/A  thrpt    2  2684250.835          ops/ms
CbrtPerf.CbrtPerfConstant.cbrtConstDouble512               N/A  thrpt    2  2683616.321          ops/ms
Withopt:-
Benchmark                                     (cbrtRangeIndex)   Mode  Cnt       Score   Error   Units
CbrtPerf.CbrtPerfConstant.cbrtConstDouble0                 N/A  thrpt    2   284575.292          ops/ms
CbrtPerf.CbrtPerfConstant.cbrtConstDouble1                 N/A  thrpt    2   162876.035          ops/ms
CbrtPerf.CbrtPerfConstant.cbrtConstDouble27                N/A  thrpt    2   163227.835          ops/ms
CbrtPerf.CbrtPerfConstant.cbrtConstDouble512               N/A  thrpt    2   162998.844          ops/ms


There is approximaely 10x performance improvement by disabling intrinsic for compile time constant inputs.
I have created a follow up JBS to track it. https://bugs.openjdk.org/browse/JDK-8358039

-------------

PR Review: https://git.openjdk.org/jdk/pull/24470#pullrequestreview-2877492755
PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2113462482
PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2113484695
PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2113472992

From michaelm at openjdk.org  Thu May 29 09:02:56 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 29 May 2025 09:02:56 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v12]
In-Reply-To: <P23_pU8TmA_8hfRaL_8cAkId_C0PXgwZiYLR0TZfhq0=.0bc74355-0ef8-417f-b1a6-adc35755841a@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <P1UhwKclOZOB8wVg38pTcQ7ZqO71ZQAAitPucfs_t4o=.5a555883-1d19-43f3-9e19-b1797d594796@github.com>
 <P23_pU8TmA_8hfRaL_8cAkId_C0PXgwZiYLR0TZfhq0=.0bc74355-0ef8-417f-b1a6-adc35755841a@github.com>
Message-ID: <Baew1rh4CURyWBtnLgNuFHrTZNgxN5YK0oCFJpG9UOI=.00f12b97-d48d-480c-a416-770220936e39@github.com>

On Wed, 28 May 2025 23:13:21 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> here are a few files with IOException, UnknownHostException and MalformedURLException, which are worth reviewing for Exception that may have been missed
> 
> IOEXception:
> 
> open/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java Ln 562
> 
> open/src/java.base/share/classes/sun/security/x509/IPAddressName.java
> 
> open/src/java.base/share/classes/sun/security/x509/URIName.java
> 
> open/src/java.base/share/classes/sun/security/x509/RDN.java
> 
> open/src/java.base/share/classes/java/util/jar/JarFile.java
> 
> UnknownHostException
> 
> open/src/java.base/share/classes/sun/nio/ch/SocketAdaptor.java
> 
> open/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java
> 
> MalformedURLException
> 
> open/src/java.base/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java
> 
> open/src/java.base/share/classes/java/net/URL.java ? Invalid port
> 
> open/src/java.naming/share/classes/com/sun/jndi/ldap/LdapURL.java
> 
> open/src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java
> 
> open/src/java.rmi/share/classes/java/rmi/Naming.java

Thanks, I will take another look at all these cases and update any that I agree need to be included.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2918771547

From michaelm at openjdk.org  Thu May 29 09:02:55 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 29 May 2025 09:02:55 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v11]
In-Reply-To: <yGyzMVvXj8BRDHM0AdgLCNWUev8RnKaC3O9KN1iKTs0=.0b80c2b1-e312-4a5a-8ca3-19e1e2fb5266@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <sW3GdlLD79bnN2CDuhXR4_V7xS9rxQsmp_Np7PzJCVg=.cb5be3f2-1aa1-47ce-86ca-569f1478103b@github.com>
 <yGyzMVvXj8BRDHM0AdgLCNWUev8RnKaC3O9KN1iKTs0=.0b80c2b1-e312-4a5a-8ca3-19e1e2fb5266@github.com>
Message-ID: <mdD2ZTgb3Q0wHEk0-NhZtPOeZ-dz0EFld4FEShRehOU=.be92da99-2f81-4c00-861a-8116cc0d04ae@github.com>

On Mon, 26 May 2025 20:39:51 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> You could take a slightly more radical approach, and rather than applying a filter explicitly on the exception message, adopt a builder pattern for the creation of the filter exceptions, for example
> 
> FilteredExceptionBuilder / EnhancedExceptionBuilder.
> 
> It might provide be more flexible and provide, encapsulating the filtering and policy application inside the builder.
> 
> EnhancedExceptionBuilder::class() ::exceptionMessage() ::port() ::hostname() ::userDetails() ::filterPolicy()

We've been through so many iterations at this stage, that I think what we've landed on is reasonable and probably most importantly, concise such that it's not overly intrusive at the call sites.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2918770154

From jwaters at openjdk.org  Thu May 29 09:03:55 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 29 May 2025 09:03:55 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v4]
In-Reply-To: <72GCipLKeCWCG-4jsG5XhZKkTdVsWafEq_wA0oD-0mk=.c70af814-54fe-43d2-b7c9-72b845eb99d5@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <72GCipLKeCWCG-4jsG5XhZKkTdVsWafEq_wA0oD-0mk=.c70af814-54fe-43d2-b7c9-72b845eb99d5@github.com>
Message-ID: <cTPAVD5xnYDItBLloQQRf1T1dF6rc9LmMLlcSXXGfj4=.ad19da34-6dd1-4f38-91f1-3f7dacdb5e10@github.com>

On Wed, 28 May 2025 18:39:13 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The command to run all range specific micro-benchmarks is posted below.
>> 
>> `make test TEST="micro:CbrtPerf.CbrtPerfRanges"`
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs.
>> 
>> | Input range(s)                                  | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
>> | :-------------------------------------: | :-------------------------------: | :-------------------------------: | :---------: |
>> | [-2^(-1022), 2^(-1022)]                   | 6568                                        | 17678                                      | 2.69x       |
>> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932                                    | 200897                                    | 1.45x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Remove comment mentioning invalid exception when NaN input is provided
>  - Use rcx as base and r8 as index for address calculations in certain cbrt stub generator instructions
>  - Remove unnecessary unpckhpd and unpcklpd definitions in macro-assembler header file
>  - Remove unnecessary movapd definitions in macro-assembler header file

src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp line 49:

> 47: /******************************************************************************/
> 48: 
> 49: ATTRIBUTE_ALIGNED(4) static const juint _SIG_MASK[] =

ATTRIBUTE_ALIGNED expands to alignas, I suggest using that directly instead

src/hotspot/cpu/x86/templateInterpreterGenerator_x86_64.cpp line 503:

> 501: 
> 502:   return entry_point;
> 503: }

Is the newline removal intentional?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2113530767
PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2113529587

From aph at openjdk.org  Thu May 29 09:54:57 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 29 May 2025 09:54:57 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v6]
In-Reply-To: <-_-E4pvswblhrUiDwCgk8Rh9UiBRlmpsaqmCWjnx7gQ=.4b6598f9-eecf-4f35-b599-326fe4de8a88@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <-_-E4pvswblhrUiDwCgk8Rh9UiBRlmpsaqmCWjnx7gQ=.4b6598f9-eecf-4f35-b599-326fe4de8a88@github.com>
Message-ID: <OFDIn3eiGsANwA-Rp_gVpSZdRgeYnEAqYbs_ttBh5jQ=.0369806c-e8b9-43c8-8ec4-b8242701bbb8@github.com>

On Tue, 27 May 2025 12:03:41 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
>> 
>> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
>> 
>> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
>> 
>> This PR passes tier1, tier2, and tier3 on multiple platforms.
>
> 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into fill-overlap
>  - Update test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update benchmark to reflect new fill method
>  - Simplify
>  - Add case for long operations and break out methods
>  - Correct typo in comment
>  - Simplify the fill method

test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java line 98:

> 96:     }
> 97: 
> 98:     @Fork(value = 3, jvmArgs = {"-Djava.lang.foreign.native.threshold.power.fill=0"})

Why did you remove this line? It's essential for correct `Unsafe` results.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25383#discussion_r2113610553

From duke at openjdk.org  Thu May 29 11:43:07 2025
From: duke at openjdk.org (ExE Boss)
Date: Thu, 29 May 2025 11:43:07 GMT
Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip
 compressing for UTF16 strings [v5]
In-Reply-To: <k312dbptTPXpbWXXIFxWO3m7aNyzl6nQW3EQqmnAG18=.921430fc-9776-4df1-82eb-ca01ecb22822@github.com>
References: <h_1D_TJUlhh5bvGYW-ZJEPH5dRr3T7zQFQOF6s_4Of4=.1586c0ba-79f2-4089-84eb-80a0dea39adb@github.com>
 <k312dbptTPXpbWXXIFxWO3m7aNyzl6nQW3EQqmnAG18=.921430fc-9776-4df1-82eb-ca01ecb22822@github.com>
Message-ID: <7dYJWyFFE7YFZzUZ7toxkKQFrq5sz7Bxv2vWx4z4qbc=.413ff7c7-9879-40e6-b5c6-85a4509426d9@github.com>

On Wed, 23 Mar 2022 00:35:14 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> If AbstractStringBuilder only grow, the inflated value which has been encoded in UTF16 can't be compressed. 
>> toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress().
>> 
>> java.io.BufferedRead::readLine() is a case that StringBuilder grows only. 
>> 
>> In microbench, we expect to see that allocation/op reduces 20%.  The initial capacity of StringBuilder is S in bytes. When it encounters the 1st character that can't be encoded in LATIN1, it inflates and allocate a new array of 2*S. `toString()` will try to compress that value so it need to allocate S bytes. The last step allocates 2*S bytes because it has to copy the string.  so it requires to allocate 5 * S bytes in total.  By skipping the failed compression, it only allocates 4 * S bytes.  that's 20%. In real execution, we observe 16% allocation reduction, tracked by JMH GC profiler `gc.alloc.rate.norm `.  I think it's because HotSpot can't track all allocations. 
>> 
>> Not only allocation drops, the runtime performance(ns/op) also increases from 3.34% to 18.91%. 
>> 
>> Before: 
>> 
>> $$make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm $HOME/Devel/jdk_baseline/bin/java" 
>> 
>> Benchmark                                                               (MIXED_SIZE)  Mode  Cnt     Score     Error   Units
>> StringBuilders.toStringWithMixedChars                                            128  avgt   15   649.846 ?  76.291   ns/op
>> StringBuilders.toStringWithMixedChars:?gc.alloc.rate                             128  avgt   15   872.855 ? 128.259  MB/sec
>> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm                        128  avgt   15   880.121 ?   0.050    B/op
>> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space                    128  avgt   15   707.730 ? 194.421  MB/sec
>> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm               128  avgt   15   706.602 ?  94.504    B/op
>> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space                128  avgt   15     0.001 ?   0.002  MB/sec
>> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm           128  avgt   15     0.001 ?   0.001    B/op
>> StringBuilders.toStringWithMixedChars:?gc.count                                  128  avgt   15   113.000            counts
>> StringBuilders.toStringWithMixedChars:?gc.time                                   ...
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewording the comment of 'maybeLatin1'.

This?introduced a?bug where?the?following now?incorrectly returns?`false` with?`?XX:?+CompactStrings` as?it?produces an?inflated `String` containing?only Latin1?characters:

new StringBuilder()
	// insert Latin1 sub-slice "foo" of UTF-16 string:
	.insert(0, "foo \uF000", 0, 3)
	.toString()
	.equals("foo");


Such a?`String` can?cause many?weird?bugs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7671#issuecomment-2919134074

From kbarrett at openjdk.org  Thu May 29 13:10:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 29 May 2025 13:10:52 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v6]
In-Reply-To: <wQkKLSTJsvldZxWleQpPTv_9N1ugC067-gv5LUVTdPI=.8917db0c-0653-48f5-acc2-e040a61f650a@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com>
 <ymq-cS14PaC1PpdKAzAZJwxdwtVTbSZtT-LNC21lW6Q=.f956592a-fd59-4bb5-a485-f4138942d290@github.com>
 <lnDH0vCQvoIGjjsjeO7ukv8gpTfp1vWR8hOX-CXlFjA=.a859787f-bc16-40c2-9f9d-ae879e68dc25@github.com>
 <rHMm6DwsyFJIOTQRKO17T0VyOvaxUwxVpwWKw4mpIj8=.d2633532-bc82-4505-a14b-45b46798d4ff@github.com>
 <cskdHy0_3zFOp7bAI-zz6V-avY2vPIcnwIseaE0NrS8=.3c147c4d-78e9-4499-88d3-73fbb40560ab@github.com>
 <wQkKLSTJsvldZxWleQpPTv_9N1ugC067-gv5LUVTdPI=.8917db0c-0653-48f5-acc2-e040a61f650a@github.com>
Message-ID: <DOmW1DiflE8ovJmLEHeU8S8laqzbcy1gjqfRsJaMyUU=.8bca0d18-8ffa-402d-af96-66236f6b84c2@github.com>

On Thu, 29 May 2025 01:14:30 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> The comment is about why we have native `get0` at all, rather than just making
>> `get` also be native.
>> 
>>> [...] JDK-8271862 was about migrating to non-virtual intrinsic method.
>> 
>> That's not a correct summary of JDK-8271862. That change was about migrating
>> away from having a method that was all 3 of (1) intrinsic (2) native, and (3)
>> virtual. It split that method into two parts, and allocated the properties to
>> them in such a way that neither had all 3. There are several possible
>> allocations of the properties to the methods that would have worked. In this
>> case we already had all the machinary in place for `refersTo0` to be intrinsic
>> and native, so the allocation that didn't require a bunch of renaming for
>> consistency was to introduce `refersToImpl` to provide the virtual part.
>> 
>> For this PR we have a method that is already intrinsic and virtual. Of course,
>> we don't want to make it native too. Since we already have all the machinary
>> in place for `get` to be intrinsic and virtual, the allocation that didn't
>> require a bunch of renaming for consistency was to introduce native `get0` for
>> use as the non-intrinsic implementation of `get`. See also here:
>> https://github.com/openjdk/jdk/pull/24315#discussion_r2039137923
>
> The current limitation of intrinsics support in C1/C2 is that intrinsics are always applied in the context of some method (as part of inlining). If a method is at the root of the compilation, it is never intrinsified.
> 
> The problem with virtual intrinsic methods is that when devirtualization fails, the call site ends up permanently calling into non-intrinsified version. That's what `refersTo0` initially suffered (fixed by JDK-8271862). `Reference::refersTo0` was virtual intrinsic method (no intrinsic when no inlining, hence call into native) and once it was untangled (virtual `refersToImpl` calls non-virtual intrinsic  method `refersTo0`) intrinsification happens reliably in the context of `refersToImpl`.

We already have this to address that issue for the specific case of Reference.get:
https://github.com/openjdk/jdk/blob/4cf729cfac57c9aec692a52c1f3f95f2403e7958/src/hotspot/share/opto/compile.cpp#L786-L792
I think if we made the non-virtual native method be the intrinsic then we
could remove that special handling? Maybe that's a good enough reason to cover
the cost of renaming churn. Or maybe that's better done as a later cleanup?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2113909448

From nbenalla at openjdk.org  Thu May 29 13:42:34 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 29 May 2025 13:42:34 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v5]
In-Reply-To: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
Message-ID: <4gJngunxPmVPKGxIz_EFt0SMiFg4n2kMhzq2adsxuKU=.92733483-1132-456c-8fe3-85af89a105de@github.com>

> Get JDK 26 underway.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Update --release 25 symbol information for JDK 25 build 24
   The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
 - problem list some failing tests
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Update --release 25 symbol information for JDK 25 build 23
   The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
 - Update release date
 - ... and 6 more: https://git.openjdk.org/jdk/compare/4cf729cf...6b0ce8b6

-------------

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=04
  Stats: 1823 lines in 58 files changed: 1734 ins; 16 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/25008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008

PR: https://git.openjdk.org/jdk/pull/25008

From rriggs at openjdk.org  Thu May 29 14:21:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 29 May 2025 14:21:54 GMT
Subject: RFR: 8357683: (process) SIGQUIT still blocked after JDK-8234262
 with jdk.lang.Process.launchMechanism=FORK or VFORK [v2]
In-Reply-To: <PJ6kUa4lWZU68M6BPDEnV-bIz4oFr-r1cKE1gWmLGWY=.bfccefeb-3855-43ea-b64d-ba8774665efa@github.com>
References: <4lcOGDk0oaJq6fR2RJZl9uQ_qkZFBCaw7Lz4LQhuccs=.91014969-a44b-48a1-982a-7ac3823ecf4e@github.com>
 <PJ6kUa4lWZU68M6BPDEnV-bIz4oFr-r1cKE1gWmLGWY=.bfccefeb-3855-43ea-b64d-ba8774665efa@github.com>
Message-ID: <-MgHTaqd3dqLKT6g0aNqTlcoG26drN5YYnmSURxZ5vY=.f574869b-a0fe-4298-9d31-d337384be191@github.com>

On Sat, 24 May 2025 10:15:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> See bug description. We now unblock all signals in both FORK and POSIX_SPAWN launch modes. This fixes the problem and makes the behavior consistent across these two modes.
>> 
>> I left the VFORK mode alone since I believe the signal state is still shared with the parent. One more reason to get rid of this mode soon (it's deprecated with 25 and will be removed with 26)
>> 
>> The fix just moves the unblocking code from the jspawnhelper over to the child process function that is called for all three modes.
>> 
>> -----
>> 
>> Testing: I did various manual tests. I also tested that test/jdk/java/lang/ProcessBuilder/UnblockSignals.java succeeds with both POSIX_SPAWN and FORK mode now and that the behavior is unchanged (still broken) for VFORK mode.
>> 
>> ping @RogerRiggs I would like to get this still into JDK 25; the fix is small and clean enough to not worry me.
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8357683-process-SIGQUIT-still-blocked-after-JDK-8234262-with-jdk-lang-Process-launchMechanism=FORK-or-VFORK
>  - unblock signals in fork mode

Looks fine; will run some tests in the CI before approving.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25428#issuecomment-2919556500

From michaelm at openjdk.org  Thu May 29 14:35:11 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 29 May 2025 14:35:11 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v13]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <uRKRZz5rqge9owi2Y3EaLR6u4mV47rzThn_BgcqY1p4=.d757cf7f-93cd-4c93-8066-963535c1c2d8@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 incrementally with one additional commit since the last revision:

  Additional callsites identified by Mark S.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/cf179f7d..34f20c9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=11-12

  Stats: 79 lines in 9 files changed: 27 ins; 0 del; 52 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 bpb at openjdk.org  Thu May 29 15:24:07 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 29 May 2025 15:24:07 GMT
Subject: Integrated: 8354724: Methods in java.io.Reader to read all characters
 and all lines
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: <YRO5SZF7fZ3FeU3SZvg2YGVeV21ZKXyzgd4_P0y4ADU=.034786da-4504-4613-beac-6a3b2df0a082@github.com>

On Thu, 17 Apr 2025 16:18:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Implement the requested methods and add a test thereof.

This pull request has now been integrated.

Changeset: 79aff26c
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79aff26c2880922b92863911d8a5a035ba9a1e75
Stats:     247 lines in 2 files changed: 247 ins; 0 del; 0 mod

8354724: Methods in java.io.Reader to read all characters and all lines

Reviewed-by: rriggs, smarks, jpai, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/24728

From coleenp at openjdk.org  Thu May 29 15:50:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 May 2025 15:50:54 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v5]
In-Reply-To: <4gJngunxPmVPKGxIz_EFt0SMiFg4n2kMhzq2adsxuKU=.92733483-1132-456c-8fe3-85af89a105de@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <4gJngunxPmVPKGxIz_EFt0SMiFg4n2kMhzq2adsxuKU=.92733483-1132-456c-8fe3-85af89a105de@github.com>
Message-ID: <oIv_bpXjTGEX1E8uH7xSeklJlxq9I3guFzqsN3pUxA4=.cdc58dd4-bcbd-4619-b0c4-05423d517a10@github.com>

On Thu, 29 May 2025 13:42:34 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 24
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - problem list some failing tests
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 23
>    The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - Update release date
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4cf729cf...6b0ce8b6

Hotspot changes look good.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2878772498

From igraves at openjdk.org  Thu May 29 16:05:06 2025
From: igraves at openjdk.org (Ian Graves)
Date: Thu, 29 May 2025 16:05:06 GMT
Subject: RFR: 8356634: VectorShape#largestShapeFor should have public
 access [v2]
In-Reply-To: <JavbxK-K4oPsdH53sMhVG1RCYBYlyOdZ_6wZCQm0uzk=.edfacd8d-88fb-485d-a86c-e9ac1571a09d@github.com>
References: <JavbxK-K4oPsdH53sMhVG1RCYBYlyOdZ_6wZCQm0uzk=.edfacd8d-88fb-485d-a86c-e9ac1571a09d@github.com>
Message-ID: <HQ1PQFdgEoioc3j0TkZ39w-TiemFh7j3EP2d0ItEtkI=.8963b31c-551e-4cc2-9511-4fa1dc4057b8@github.com>

> VectorShape#largestShapeFor is referenced in existing JavaDoc but has been package-private. This propose change makes it public and adds documentation for it.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Tweaking doc language.
  
  Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25513/files
  - new: https://git.openjdk.org/jdk/pull/25513/files/1e59fcab..a00420b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25513&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25513&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25513/head:pull/25513

PR: https://git.openjdk.org/jdk/pull/25513

From igraves at openjdk.org  Thu May 29 16:15:07 2025
From: igraves at openjdk.org (Ian Graves)
Date: Thu, 29 May 2025 16:15:07 GMT
Subject: RFR: 8356634: VectorShape#largestShapeFor should have public
 access [v3]
In-Reply-To: <JavbxK-K4oPsdH53sMhVG1RCYBYlyOdZ_6wZCQm0uzk=.edfacd8d-88fb-485d-a86c-e9ac1571a09d@github.com>
References: <JavbxK-K4oPsdH53sMhVG1RCYBYlyOdZ_6wZCQm0uzk=.edfacd8d-88fb-485d-a86c-e9ac1571a09d@github.com>
Message-ID: <68kNOGuTnK3oEticNnm-_a4q_-OvtsJwScfYmfchZhc=.8349d860-8208-499c-b356-2cf3945f53e5@github.com>

> VectorShape#largestShapeFor is referenced in existing JavaDoc but has been package-private. This propose change makes it public and adds documentation for it.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Fixing tabbing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25513/files
  - new: https://git.openjdk.org/jdk/pull/25513/files/a00420b2..8b3f6fc4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25513&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25513&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25513/head:pull/25513

PR: https://git.openjdk.org/jdk/pull/25513

From asemenyuk at openjdk.org  Thu May 29 16:24:30 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 29 May 2025 16:24:30 GMT
Subject: RFR: 8358017: Various enhancements of jpackage test helpers
Message-ID: <ZAdN-mYCPpLqwnA02zY5Ge2b6cxtNicRow9LJNTlMT8=.2eab053c-566a-4beb-8789-5514fcb5d104@github.com>

Various enhancements of jpackage test helpers:
 - Can run fa tests when JAVA_TOOL_OPTIONS env variable contains `--module-path` option. This change makes support for `jpackage.test.clear-app-launcher-java-env-vars` system property redundant.
 - Rework JUnitAdapter to make it run jpackage TestInstance objects as JUnit5 DynamicTest tests. This integrates jpackage test runs in IDEs (Verified with Eclipse IDE).
 - Make jpackage tests fail fast when they are executed by JUnit test runner.
 - Applied `./bin/blessed-modifier-order.sh` script on jpackage test helpers.
 - Support loading jpackage tests from a custom classloader.
 - Add support for using a custom ToolProvider implementation of jpackage with JPackageCommand.

The last two features are not currently in use. They were picked from the work-in-progress [JDK-8333727](https://bugs.openjdk.org/browse/JDK-8333727).

-------------

Commit messages:
 - Fix modifier order
 - Update copyright year
 - Can configure what ToolProvider to use with JPackageCommand
 - Support loading tests from a custom classloader
 - Rework JUnitAdapter to make it run jpackage TestInstance objects as JUnit5 DynamicTest tests. Additionally make the fields of TestInstance.TestDesc class final. Make jpackage tests fail fast when they are executed by JUnit. Add TKit.runAdhocTest() methods. Make JUnitAdapter use them.
 - Can run fa tests when JAVA_TOOL_OPTIONS variable is set.

Changes: https://git.openjdk.org/jdk/pull/25479/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25479&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358017
  Stats: 199 lines in 13 files changed: 120 ins; 27 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/25479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25479/head:pull/25479

PR: https://git.openjdk.org/jdk/pull/25479

From asemenyuk at openjdk.org  Thu May 29 16:24:30 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 29 May 2025 16:24:30 GMT
Subject: RFR: 8358017: Various enhancements of jpackage test helpers
In-Reply-To: <ZAdN-mYCPpLqwnA02zY5Ge2b6cxtNicRow9LJNTlMT8=.2eab053c-566a-4beb-8789-5514fcb5d104@github.com>
References: <ZAdN-mYCPpLqwnA02zY5Ge2b6cxtNicRow9LJNTlMT8=.2eab053c-566a-4beb-8789-5514fcb5d104@github.com>
Message-ID: <yMyG3_m5xM9BmMaQmwSu4cV8wLpjr5ho3RFHR28QRe8=.9637e275-491d-4e88-b281-22e324df14e6@github.com>

On Wed, 28 May 2025 03:35:40 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Various enhancements of jpackage test helpers:
>  - Can run fa tests when JAVA_TOOL_OPTIONS env variable contains `--module-path` option. This change makes support for `jpackage.test.clear-app-launcher-java-env-vars` system property redundant.
>  - Rework JUnitAdapter to make it run jpackage TestInstance objects as JUnit5 DynamicTest tests. This integrates jpackage test runs in IDEs (Verified with Eclipse IDE).
>  - Make jpackage tests fail fast when they are executed by JUnit test runner.
>  - Applied `./bin/blessed-modifier-order.sh` script on jpackage test helpers.
>  - Support loading jpackage tests from a custom classloader.
>  - Add support for using a custom ToolProvider implementation of jpackage with JPackageCommand.
> 
> The last two features are not currently in use. They were picked from the work-in-progress [JDK-8333727](https://bugs.openjdk.org/browse/JDK-8333727).

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25479#issuecomment-2918165230

From jlu at openjdk.org  Thu May 29 17:03:57 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 May 2025 17:03:57 GMT
Subject: RFR: 8348328: Update IANA Language Subtag Registry to Version
 2025-05-15
In-Reply-To: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>
References: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>
Message-ID: <5TsTuCq4JDRI1NCn965lkEVG0i8UApEq23_yJur1550=.2dfc6eae-b637-4a80-bd06-68587fd36d88@github.com>

On Wed, 28 May 2025 17:00:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the language subtag registry to Version 2025-05-15.
> 
> LanguageSubtagRegistryTest.java was updated with the preferred-values: `hnm`, `eko`, `luh`,`sjc`, `sqm`. A small change was also made to the test to improve the output as well.

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25503#issuecomment-2920015564

From jlu at openjdk.org  Thu May 29 17:03:58 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 May 2025 17:03:58 GMT
Subject: Integrated: 8348328: Update IANA Language Subtag Registry to Version
 2025-05-15
In-Reply-To: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>
References: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>
Message-ID: <WzLg3fwM_bpPMWrzzCxE6MHw3lPWoAgwXrFAdZYtykY=.f47f1553-7897-4594-b770-7f8b069ce490@github.com>

On Wed, 28 May 2025 17:00:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the language subtag registry to Version 2025-05-15.
> 
> LanguageSubtagRegistryTest.java was updated with the preferred-values: `hnm`, `eko`, `luh`,`sjc`, `sqm`. A small change was also made to the test to improve the output as well.

This pull request has now been integrated.

Changeset: f3188682
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f318868268f32934a2f0c4e26a6c75360d8e74b1
Stats:     143 lines in 2 files changed: 135 ins; 1 del; 7 mod

8348328: Update IANA Language Subtag Registry to Version 2025-05-15

Reviewed-by: iris, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/25503

From duke at openjdk.org  Thu May 29 17:07:59 2025
From: duke at openjdk.org (kieran-farrell)
Date: Thu, 29 May 2025 17:07:59 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v3]
In-Reply-To: <aUqL8I-iZmufLfNiILoCu114WyvAoMGFlyWx2ffORds=.dabc7a33-80ab-45b8-a4e3-664303aaa120@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <Jm4ATGoFWP2a8HSBuwAglmdQS5fcBKBxt7TOklUQRjk=.b47ef4c7-26cd-4603-a074-76be89fa898c@github.com>
 <D2OwQlifY_F57s5ntpnVSYAMxZ8lacAyv03fME6O3ZM=.524387cc-ad76-4261-9269-8e2f08aeb6fb@github.com>
 <my9K8CLlrz0magIzlGgxShOw4oG1D7khLcG0KB2C3aU=.50c780c7-2f35-425b-aa19-00905143e208@github.com>
 <lzUXzFFqnkDwu6nx8GudrrkgihJ9bYECt0gqbWSPOgg=.7f6488d7-5c7e-423a-879a-3f125245440c@github.com>
 <x-kg_zhXOYwXjNAnWysWQtxPWl8a2c-sOZQbhzyYBss=.3616b256-3dfe-40e1-ab16-a96cc5420069@github.com>
 <aUqL8I-iZmufLfNiILoCu114WyvAoMGFlyWx2ffORds=.dabc7a33-80ab-45b8-a4e3-664303aaa120@github.com>
Message-ID: <nFrlWMsRo9X2bGxY2a-HpLe_JL-rKshIhR7C9MS71rM=.1f10fd62-3442-43e0-9b2e-e5a723a5be30@github.com>

On Wed, 28 May 2025 20:57:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The first 48 bits need to be from the unix epoch time stamp in ms only to remain complaint. If I understand correctly, to be able to guarantee that the nsBits are actually time orderable, System.nanoTime() would have to be pinned to a point where System.currentTimeMillis() increments by 1ms (which doesnt seem possible). Otherwise any offset could be at any arbitrary point in a given millisecond and nsBits would wrap around from that.
>> 
>> I think the options are to either use the random only approach with ms precision or an guaranteed monotonic counter based approach and take the hit on performance.
>> 
>> I agree with updating to "create" from "retrieve" on the first line comment and also with the method name change to avoid confusion with UUIDv1, however to either unixEpochTimeNanos() or unixEpochTimeMillis() or otherwise depending on which implementation we settle on.
>
> We don't have a reliable sub-microsecond source across platforms, so can only be confident using random numbers for the low order bits. (and I don't expect a higher resolution monotonic clock to be available anytime soon).
> 
> Would the static factory method be more useful if it took the mstime as a parameter?
> That would allow the caller to pick the time source.  For example,
> `    UUID ts = UUID.timesteampUUID(System.currentTimeMillis());`
> It would avoid locking into the System.currentTimeMillis() and allows the application to create UUIDs for whatever time meets its needs.
> 
> Adding a unixEpochTimeMillis() makes sense, re-assembling the time bits into the ms time.

In terms of using another clock it could open up possiblities of passing non complaint time formats to the method, but maybe thats something that could be mostly prevented with input validation and clear documentation i.e. ?timestamp must be Unix time in milliseconds.? As far as I know all other standard Java methods that gives the current time in milliseconds ultimately delegates to System.currentTimeMillis(). 

Maybe there would be a use case in generating UUIDs by passing compliant timestamps for entries created in the past, like updating a database to use UUIDv7?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2114384770

From dfuchs at openjdk.org  Thu May 29 17:10:04 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 May 2025 17:10:04 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v13]
In-Reply-To: <uRKRZz5rqge9owi2Y3EaLR6u4mV47rzThn_BgcqY1p4=.d757cf7f-93cd-4c93-8066-963535c1c2d8@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <uRKRZz5rqge9owi2Y3EaLR6u4mV47rzThn_BgcqY1p4=.d757cf7f-93cd-4c93-8066-963535c1c2d8@github.com>
Message-ID: <PdyBqRPpPYWVC7U-oXwgLdmgeLHcETvNhOPiGA3z9b4=.b31032de-4e42-4c9c-a994-bf0e2a279ccc@github.com>

On Thu, 29 May 2025 14:35:11 GMT, Michael McMahon <michaelm at openjdk.org> 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:
> 
>   Additional callsites identified by Mark S.

src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 566:

> 564:                                         filterNonSocketInfo(url.getHost())
> 565:                                             .prefixWith("should be <")
> 566:                                             .suffixWith(">")));

Suggestion:

        throw new IOException(formatMsg("Wrong HTTPS hostname%s",
                                        filterNonSocketInfo(url.getHost())
                                            .prefixWith(": should be <")
                                            .suffixWith(">")));

src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 560:

> 558:         if (isa.isUnresolved()) {
> 559:             throw new UnknownHostException(
> 560:                 formatMsg("%s", filterNonSocketInfo(isa.getHostName())));

Suggestion:

                formatMsg(filterNonSocketInfo(isa.getHostName())));

src/java.base/share/classes/sun/nio/ch/SocketAdaptor.java line 99:

> 97:             close();
> 98:             throw new UnknownHostException(
> 99:                 formatMsg("%s", filterNonSocketInfo(remote.toString())));

Suggestion:

            throw new UnknownHostException(
                formatMsg(filterNonSocketInfo(remote.toString())));

src/java.naming/share/classes/com/sun/jndi/ldap/LdapURL.java line 125:

> 123:     protected MalformedURLException newInvalidURISchemeException(String uri) {
> 124:         return new MalformedURLException(formatMsg("Not an LDAP URL: %s",
> 125:                                                    filterNonSocketInfo(uri)));

Suggestion:

        return new MalformedURLException(formatMsg("Not an LDAP URL%s",
                                                   filterNonSocketInfo(uri).prefixWith(": ")));

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 238:

> 236: 
> 237:     private MalformedURLException newMalformedURLException(String prefix, String msg) {
> 238:         return new MalformedURLException(formatMsg(prefix + " %s", filterNonSocketInfo(msg)));

Suggestion:

        return new MalformedURLException(prefix + formatMsg(filterNonSocketInfo(msg).withPrefix(prefix.isEmpty()? "" : ": "));

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 250:

> 248:                 URI u = new URI(uri);
> 249:                 scheme = u.getScheme();
> 250:                 if (scheme == null) throw newMalformedURLException("Invalid URI:", uri);

Suggestion:

                if (scheme == null) throw newMalformedURLException("Invalid URI", uri);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 262:

> 260:                     if (!hostport.equals(auth)) {
> 261:                         // throw if we have user info or regname
> 262:                         throw newMalformedURLException("unsupported authority:", auth);

Suggestion:

                        throw newMalformedURLException("unsupported authority", auth);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 271:

> 269:                 if (u.getRawFragment() != null) {
> 270:                     if (!acceptsFragment()) {
> 271:                         throw newMalformedURLException("URI fragments not supported:", uri);

Suggestion:

                        throw newMalformedURLException("URI fragments not supported", uri);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 308:

> 306:         int fmark = uri.indexOf('#');
> 307:         if (i < 0 || slash > 0 && i > slash || qmark > 0 && i > qmark || fmark > 0 && i > fmark) {
> 308:             throw newMalformedURLException("Invalid URI:", uri);

Suggestion:

            throw newMalformedURLException("Invalid URI", uri);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 312:

> 310:         if (fmark > -1) {
> 311:             if (!acceptsFragment()) {
> 312:                 throw newMalformedURLException("URI fragments not supported:", uri);

Suggestion:

                throw newMalformedURLException("URI fragments not supported", uri);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 358:

> 356:                     String ui = u.getRawUserInfo();
> 357:                     if (ui != null) {
> 358:                         throw newMalformedURLException("user info not supported in authority:", ui);

Suggestion:

                        throw newMalformedURLException("user info not supported in authority", ui);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 361:

> 359:                     }
> 360:                     if (!"/".equals(p)) {
> 361:                         throw newMalformedURLException("invalid authority:", auth);

Suggestion:

                        throw newMalformedURLException("invalid authority", auth);

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 364:

> 362:                     }
> 363:                     if (q != null) {
> 364:                         throw newMalformedURLException("invalid trailing characters in authority: ?", q);

Suggestion:

                        throw new MalformedURLException("invalid trailing characters in authority: ?" + formatMsg(filterNonSocketInfo(q)));

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 374:

> 372:                         // throw if we have user info or regname
> 373:                         throw newMalformedURLException("Authority component is not server-based, " +
> 374:                                               "or contains user info. Unsupported authority:", auth);

Suggestion:

                                              "or contains user info. Unsupported authority", auth);

src/java.rmi/share/classes/java/rmi/Naming.java line 227:

> 225: 
> 226:     private static MalformedURLException newMalformedURLException(String prefix, String msg) {
> 227:         return new MalformedURLException(formatMsg(prefix + " %s", filterNonSocketInfo(msg)));

Suggestion:

        return new MalformedURLException(prefix + formatMsg(filterNonSocketInfo(msg).prefixWith(": "));

src/java.rmi/share/classes/java/rmi/Naming.java line 250:

> 248:              */
> 249:             MalformedURLException mue = newMalformedURLException(
> 250:                 "invalid URL String:", str);

Suggestion:

                "invalid URL String", str);

src/java.rmi/share/classes/java/rmi/Naming.java line 282:

> 280:         if (uri.isOpaque()) {
> 281:             throw newMalformedURLException(
> 282:                 "not a hierarchical URL:", str);

Suggestion:

                "not a hierarchical URL", str);

src/java.rmi/share/classes/java/rmi/Naming.java line 286:

> 284:         if (uri.getFragment() != null) {
> 285:             throw newMalformedURLException(
> 286:                 "invalid character, '#', in URL name:", str);

Suggestion:

                "invalid character, '#', in URL name", str);

src/java.rmi/share/classes/java/rmi/Naming.java line 289:

> 287:         } else if (uri.getQuery() != null) {
> 288:             throw newMalformedURLException(
> 289:                 "invalid character, '?', in URL name:", str);

Suggestion:

                "invalid character, '?', in URL name", str);

src/java.rmi/share/classes/java/rmi/Naming.java line 292:

> 290:         } else if (uri.getUserInfo() != null) {
> 291:             throw newMalformedURLException(
> 292:                 "invalid character, '@', in URL host:", str);

Suggestion:

                "invalid character, '@', in URL host", str);

src/java.rmi/share/classes/java/rmi/Naming.java line 296:

> 294:         String scheme = uri.getScheme();
> 295:         if (scheme != null && !scheme.equals("rmi")) {
> 296:             throw newMalformedURLException("invalid URL scheme:", str);

Suggestion:

            throw new MalformedURLException(formatMsg("invalid URL scheme%s", filterNonSocketInfo(str).prefixWith(": ").replaceWith(": rmi"));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114314118
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114338001
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114341371
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114325981
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114336092
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114343715
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114344189
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114344732
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114349684
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114360771
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114361269
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114361808
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114372438
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114373811
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114380353
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114381257
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114381615
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114381991
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114382430
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114382678
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114383025

From asemenyuk at openjdk.org  Thu May 29 17:22:50 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 29 May 2025 17:22:50 GMT
Subject: RFR: 8358017: Various enhancements of jpackage test helpers
In-Reply-To: <ZAdN-mYCPpLqwnA02zY5Ge2b6cxtNicRow9LJNTlMT8=.2eab053c-566a-4beb-8789-5514fcb5d104@github.com>
References: <ZAdN-mYCPpLqwnA02zY5Ge2b6cxtNicRow9LJNTlMT8=.2eab053c-566a-4beb-8789-5514fcb5d104@github.com>
Message-ID: <F7kxgRGp2y0l-ElMzqGvOB_Q-xy3eSgWV1Tk6V_BKOY=.7328f2af-feba-4abe-8034-d98a70c2dbb7@github.com>

On Wed, 28 May 2025 03:35:40 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Various enhancements of jpackage test helpers:
>  - Can run fa tests when JAVA_TOOL_OPTIONS env variable contains `--module-path` option. This change makes support for `jpackage.test.clear-app-launcher-java-env-vars` system property redundant.
>  - Rework JUnitAdapter to make it run jpackage TestInstance objects as JUnit5 DynamicTest tests. This integrates jpackage test runs in IDEs (Verified with Eclipse IDE).
>  - Make jpackage tests fail fast when they are executed by JUnit test runner.
>  - Applied `./bin/blessed-modifier-order.sh` script on jpackage test helpers.
>  - Support loading jpackage tests from a custom classloader.
>  - Add support for using a custom ToolProvider implementation of jpackage with JPackageCommand.
> 
> The last two features are not currently in use. They were picked from the work-in-progress [JDK-8333727](https://bugs.openjdk.org/browse/JDK-8333727).

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25479#issuecomment-2920063699

From naoto at openjdk.org  Thu May 29 17:24:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 May 2025 17:24:25 GMT
Subject: RFR: 8357882: Use UTF-8 encoded data in LocaleDataTest
Message-ID: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>

Test refactoring stemmed from the discussion at https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160. The test is now based on UTF-8 instead of ISO-8859-1

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/25524/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25524&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357882
  Stats: 4205 lines in 2 files changed: 0 ins; 101 del; 4104 mod
  Patch: https://git.openjdk.org/jdk/pull/25524.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25524/head:pull/25524

PR: https://git.openjdk.org/jdk/pull/25524

From jlu at openjdk.org  Thu May 29 17:38:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 May 2025 17:38:53 GMT
Subject: RFR: 8357882: Use UTF-8 encoded data in LocaleDataTest
In-Reply-To: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>
References: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>
Message-ID: <zQWfRYBmu0ASScYOeo3qVB-qNV648vh6Bgkjs16TDpc=.797454f6-050b-48de-b50c-087f7e4e3002@github.com>

On Thu, 29 May 2025 17:20:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Test refactoring stemmed from the discussion at https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160. The test is now based on UTF-8 instead of ISO-8859-1

Test change looks good. Skimmed the data change, which also looks to be converted correctly.

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25524#pullrequestreview-2879093984

From jlu at openjdk.org  Thu May 29 17:41:56 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 May 2025 17:41:56 GMT
Subject: Integrated: 8357275: Locale.Builder.setLanguageTag should mention
 conversions made on language tag
In-Reply-To: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
Message-ID: <wyyIY4-PeDbEW7jda_3G8lBkA5KZHKbEe55N5ujXK3U=.35c05f11-7874-46da-97b0-39b1102660f7@github.com>

On Mon, 19 May 2025 20:56:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.

This pull request has now been integrated.

Changeset: e509997f
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e509997fe87a09513b8f79d303cc69392d2cb7b0
Stats:     13 lines in 1 file changed: 9 ins; 0 del; 4 mod

8357275: Locale.Builder.setLanguageTag should mention conversions made on language tag

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/25309

From smarks at openjdk.org  Thu May 29 18:27:02 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 29 May 2025 18:27:02 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method specifications
Message-ID: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>

For a full explanation, see the bug report [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015).

This PR includes three related changes:
* New overrides in SequencedMap view collection implementations, which improve their behavior.
* Update to `@implSpec` clauses to reflect this behavior (which was previously ill-specified).
* Update to a test which relied on unspecified behavior.

-------------

Commit messages:
 - Update @implSpecs of SequencedMap view methods.
 - Update SequencedMap views to use SequencedMap methods instead of inheriting

Changes: https://git.openjdk.org/jdk/pull/25515/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25515&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358015
  Stats: 69 lines in 3 files changed: 59 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25515.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25515/head:pull/25515

PR: https://git.openjdk.org/jdk/pull/25515

From rriggs at openjdk.org  Thu May 29 18:33:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 29 May 2025 18:33:52 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v3]
In-Reply-To: <nFrlWMsRo9X2bGxY2a-HpLe_JL-rKshIhR7C9MS71rM=.1f10fd62-3442-43e0-9b2e-e5a723a5be30@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <Jm4ATGoFWP2a8HSBuwAglmdQS5fcBKBxt7TOklUQRjk=.b47ef4c7-26cd-4603-a074-76be89fa898c@github.com>
 <D2OwQlifY_F57s5ntpnVSYAMxZ8lacAyv03fME6O3ZM=.524387cc-ad76-4261-9269-8e2f08aeb6fb@github.com>
 <my9K8CLlrz0magIzlGgxShOw4oG1D7khLcG0KB2C3aU=.50c780c7-2f35-425b-aa19-00905143e208@github.com>
 <lzUXzFFqnkDwu6nx8GudrrkgihJ9bYECt0gqbWSPOgg=.7f6488d7-5c7e-423a-879a-3f125245440c@github.com>
 <x-kg_zhXOYwXjNAnWysWQtxPWl8a2c-sOZQbhzyYBss=.3616b256-3dfe-40e1-ab16-a96cc5420069@github.com>
 <aUqL8I-iZmufLfNiILoCu114WyvAoMGFlyWx2ffORds=.dabc7a33-80ab-45b8-a4e3-664303aaa120@github.com>
 <nFrlWMsRo9X2bGxY2a-HpLe_JL-rKshIhR7C9MS71rM=.1f10fd62-3442-43e0-9b2e-e5a723a5be30@github.com>
Message-ID: <MptKp5DYOARdsRle8U6QpR4Hvd5aS6fGhRbDoi_1h5s=.d06f5ed7-ebcd-47af-a7f8-82fdaaee0a12@github.com>

On Thu, 29 May 2025 17:05:23 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> We don't have a reliable sub-microsecond source across platforms, so can only be confident using random numbers for the low order bits. (and I don't expect a higher resolution monotonic clock to be available anytime soon).
>> 
>> Would the static factory method be more useful if it took the mstime as a parameter?
>> That would allow the caller to pick the time source.  For example,
>> `    UUID ts = UUID.timesteampUUID(System.currentTimeMillis());`
>> It would avoid locking into the System.currentTimeMillis() and allows the application to create UUIDs for whatever time meets its needs.
>> 
>> Adding a unixEpochTimeMillis() makes sense, re-assembling the time bits into the ms time.
>
> In terms of using another clock it could open up possiblities of passing non complaint time formats to the method, but maybe thats something that could be mostly prevented with input validation and clear documentation i.e. ?timestamp must be Unix time in milliseconds.? As far as I know all other standard Java methods that gives the current time in milliseconds ultimately delegates to System.currentTimeMillis(). 
> 
> Maybe there would be a use case in generating UUIDs by passing compliant timestamps for entries created in the past, like updating a database to use UUIDv7?

RFC 9562 does not indicate any relation between the timestamp value and the "current" time.
So yes, document it as the Unix Epoch, milliseconds since 1970. 
There could be plenty of use cases for creating a UUID from some other source of time, like the timestamp of a file or a time field in a database.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2114523897

From joehw at openjdk.org  Thu May 29 18:37:51 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 29 May 2025 18:37:51 GMT
Subject: RFR: 8357882: Use UTF-8 encoded data in LocaleDataTest
In-Reply-To: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>
References: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>
Message-ID: <e6Y46iDdjto8PBSh_c_oUa8Vh0iVasJ8YzazPM8E7z8=.30300c2d-8fd2-415b-8f01-d65f0ee6a3e9@github.com>

On Thu, 29 May 2025 17:20:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Test refactoring stemmed from the discussion at https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160. The test is now based on UTF-8 instead of ISO-8859-1

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25524#pullrequestreview-2879251465

From vlivanov at openjdk.org  Thu May 29 18:47:54 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 29 May 2025 18:47:54 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v6]
In-Reply-To: <DOmW1DiflE8ovJmLEHeU8S8laqzbcy1gjqfRsJaMyUU=.8bca0d18-8ffa-402d-af96-66236f6b84c2@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com>
 <ymq-cS14PaC1PpdKAzAZJwxdwtVTbSZtT-LNC21lW6Q=.f956592a-fd59-4bb5-a485-f4138942d290@github.com>
 <lnDH0vCQvoIGjjsjeO7ukv8gpTfp1vWR8hOX-CXlFjA=.a859787f-bc16-40c2-9f9d-ae879e68dc25@github.com>
 <rHMm6DwsyFJIOTQRKO17T0VyOvaxUwxVpwWKw4mpIj8=.d2633532-bc82-4505-a14b-45b46798d4ff@github.com>
 <cskdHy0_3zFOp7bAI-zz6V-avY2vPIcnwIseaE0NrS8=.3c147c4d-78e9-4499-88d3-73fbb40560ab@github.com>
 <wQkKLSTJsvldZxWleQpPTv_9N1ugC067-gv5LUVTdPI=.8917db0c-0653-48f5-acc2-e040a61f650a@github.com>
 <DOmW1DiflE8ovJmLEHeU8S8laqzbcy1gjqfRsJaMyUU=.8bca0d18-8ffa-402d-af96-66236f6b84c2@github.com>
Message-ID: <_99Geoayi09Ey7YT7qWw4pjMqbVUNxfKpFBwwI_EbHg=.e81158ae-813c-4015-94d6-4404eb756394@github.com>

On Thu, 29 May 2025 13:08:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> The current limitation of intrinsics support in C1/C2 is that intrinsics are always applied in the context of some method (as part of inlining). If a method is at the root of the compilation, it is never intrinsified.
>> 
>> The problem with virtual intrinsic methods is that when devirtualization fails, the call site ends up permanently calling into non-intrinsified version. That's what `refersTo0` initially suffered (fixed by JDK-8271862). `Reference::refersTo0` was virtual intrinsic method (no intrinsic when no inlining, hence call into native) and once it was untangled (virtual `refersToImpl` calls non-virtual intrinsic  method `refersTo0`) intrinsification happens reliably in the context of `refersToImpl`.
>
> We already have this to address that issue for the specific case of Reference.get:
> https://github.com/openjdk/jdk/blob/4cf729cfac57c9aec692a52c1f3f95f2403e7958/src/hotspot/share/opto/compile.cpp#L786-L792
> I think if we made the non-virtual native method be the intrinsic then we
> could remove that special handling? Maybe that's a good enough reason to cover
> the cost of renaming churn. Or maybe that's better done as a later cleanup?

Yes, I find it much cleaner when intrinsic is non-virtual.

> Or maybe that's better done as a later cleanup?

Up to you. I'm fine with the current PR if you remove the comment referring to C2.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2114543162

From rriggs at openjdk.org  Thu May 29 18:47:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 29 May 2025 18:47:55 GMT
Subject: RFR: 8357683: (process) SIGQUIT still blocked after JDK-8234262
 with jdk.lang.Process.launchMechanism=FORK or VFORK [v2]
In-Reply-To: <PJ6kUa4lWZU68M6BPDEnV-bIz4oFr-r1cKE1gWmLGWY=.bfccefeb-3855-43ea-b64d-ba8774665efa@github.com>
References: <4lcOGDk0oaJq6fR2RJZl9uQ_qkZFBCaw7Lz4LQhuccs=.91014969-a44b-48a1-982a-7ac3823ecf4e@github.com>
 <PJ6kUa4lWZU68M6BPDEnV-bIz4oFr-r1cKE1gWmLGWY=.bfccefeb-3855-43ea-b64d-ba8774665efa@github.com>
Message-ID: <OsU0IJD6NLNWzvS5UZyCghbx-pZZhDbxffDojXRXTT0=.c955aafc-878b-478e-8467-2e67f858d620@github.com>

On Sat, 24 May 2025 10:15:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> See bug description. We now unblock all signals in both FORK and POSIX_SPAWN launch modes. This fixes the problem and makes the behavior consistent across these two modes.
>> 
>> I left the VFORK mode alone since I believe the signal state is still shared with the parent. One more reason to get rid of this mode soon (it's deprecated with 25 and will be removed with 26)
>> 
>> The fix just moves the unblocking code from the jspawnhelper over to the child process function that is called for all three modes.
>> 
>> -----
>> 
>> Testing: I did various manual tests. I also tested that test/jdk/java/lang/ProcessBuilder/UnblockSignals.java succeeds with both POSIX_SPAWN and FORK mode now and that the behavior is unchanged (still broken) for VFORK mode.
>> 
>> ping @RogerRiggs I would like to get this still into JDK 25; the fix is small and clean enough to not worry me.
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8357683-process-SIGQUIT-still-blocked-after-JDK-8234262-with-jdk-lang-Process-launchMechanism=FORK-or-VFORK
>  - unblock signals in fork mode

Passes the CI and no problems are expected under normal launching mechanisms.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25428#pullrequestreview-2879276283

From vlivanov at openjdk.org  Thu May 29 18:47:55 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 29 May 2025 18:47:55 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v6]
In-Reply-To: <_99Geoayi09Ey7YT7qWw4pjMqbVUNxfKpFBwwI_EbHg=.e81158ae-813c-4015-94d6-4404eb756394@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com>
 <ymq-cS14PaC1PpdKAzAZJwxdwtVTbSZtT-LNC21lW6Q=.f956592a-fd59-4bb5-a485-f4138942d290@github.com>
 <lnDH0vCQvoIGjjsjeO7ukv8gpTfp1vWR8hOX-CXlFjA=.a859787f-bc16-40c2-9f9d-ae879e68dc25@github.com>
 <rHMm6DwsyFJIOTQRKO17T0VyOvaxUwxVpwWKw4mpIj8=.d2633532-bc82-4505-a14b-45b46798d4ff@github.com>
 <cskdHy0_3zFOp7bAI-zz6V-avY2vPIcnwIseaE0NrS8=.3c147c4d-78e9-4499-88d3-73fbb40560ab@github.com>
 <wQkKLSTJsvldZxWleQpPTv_9N1ugC067-gv5LUVTdPI=.8917db0c-0653-48f5-acc2-e040a61f650a@github.com>
 <DOmW1DiflE8ovJmLEHeU8S8laqzbcy1gjqfRsJaMyUU=.8bca0d18-8ffa-402d-af96-66236f6b84c2@github.com>
 <_99Geoayi09Ey7YT7qWw4pjMqbVUNxfKpFBwwI_EbHg=.e81158ae-813c-4015-94d6-4404eb756394@github.com>
Message-ID: <ZS11BbUZhXvjekz9J6Nx0YdmsRy4vi8Xc4LUc-60I_w=.d0f276f4-f023-4414-9fc2-8000ffa4e0c1@github.com>

On Thu, 29 May 2025 18:43:31 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> We already have this to address that issue for the specific case of Reference.get:
>> https://github.com/openjdk/jdk/blob/4cf729cfac57c9aec692a52c1f3f95f2403e7958/src/hotspot/share/opto/compile.cpp#L786-L792
>> I think if we made the non-virtual native method be the intrinsic then we
>> could remove that special handling? Maybe that's a good enough reason to cover
>> the cost of renaming churn. Or maybe that's better done as a later cleanup?
>
> Yes, I find it much cleaner when intrinsic is non-virtual.
> 
>> Or maybe that's better done as a later cleanup?
> 
> Up to you. I'm fine with the current PR if you remove the comment referring to C2.

FTR the special case in `compile.cpp` you referred to is not used right now because there are no stand-alone compilations of `Reference::get` happening (I believe because it is also intrinsified in interpreter).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2114545824

From duke at openjdk.org  Thu May 29 18:56:11 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Thu, 29 May 2025 18:56:11 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v5]
In-Reply-To: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
Message-ID: <GE6s8raLeTlcMDb0coe89QbMYSPqWtjjkr_puB8hcx8=.d4911eb3-3201-441b-81a9-b476ea5b64c9@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
> 
> The command to run all range specific micro-benchmarks is posted below.
> 
> `make test TEST="micro:CbrtPerf.CbrtPerfRanges"`
> 
> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version.
> 
> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs.
> 
> | Input range(s)                                  | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
> | :-------------------------------------: | :-------------------------------: | :-------------------------------: | :---------: |
> | [-2^(-1022), 2^(-1022)]                   | 6568                                        | 17678                                      | 2.69x       |
> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932                                    | 200897                                    | 1.45x       |
> 
> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.

Mohamed Issa has updated the pull request incrementally with two additional commits since the last revision:

 - Add newline back to templateInterpreterGenerator_x86_64.cpp source file
 - Add special case values to cbrt micro-benchmark set

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24470/files
  - new: https://git.openjdk.org/jdk/pull/24470/files/ff4d4f22..233e0188

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24470&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24470&range=03-04

  Stats: 40 lines in 2 files changed: 39 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24470.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24470/head:pull/24470

PR: https://git.openjdk.org/jdk/pull/24470

From duke at openjdk.org  Thu May 29 18:56:12 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Thu, 29 May 2025 18:56:12 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v4]
In-Reply-To: <cTPAVD5xnYDItBLloQQRf1T1dF6rc9LmMLlcSXXGfj4=.ad19da34-6dd1-4f38-91f1-3f7dacdb5e10@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <72GCipLKeCWCG-4jsG5XhZKkTdVsWafEq_wA0oD-0mk=.c70af814-54fe-43d2-b7c9-72b845eb99d5@github.com>
 <cTPAVD5xnYDItBLloQQRf1T1dF6rc9LmMLlcSXXGfj4=.ad19da34-6dd1-4f38-91f1-3f7dacdb5e10@github.com>
Message-ID: <CE7DC_l4IRgh8ia7JFugTpN7E55hce7YBJpxlVnOreE=.e35a487c-ddb8-4893-b80c-64aa7d25f455@github.com>

On Thu, 29 May 2025 09:01:05 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Mohamed Issa has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Remove comment mentioning invalid exception when NaN input is provided
>>  - Use rcx as base and r8 as index for address calculations in certain cbrt stub generator instructions
>>  - Remove unnecessary unpckhpd and unpcklpd definitions in macro-assembler header file
>>  - Remove unnecessary movapd definitions in macro-assembler header file
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp line 49:
> 
>> 47: /******************************************************************************/
>> 48: 
>> 49: ATTRIBUTE_ALIGNED(4) static const juint _SIG_MASK[] =
> 
> ATTRIBUTE_ALIGNED expands to alignas, I suggest using that directly instead

The ATTRIBUTE_ALIGNED micro is used in other stub generator files. Should all of those be changed to alignas as well?

Is the suggestion to change just for code readability?

> src/hotspot/cpu/x86/templateInterpreterGenerator_x86_64.cpp line 503:
> 
>> 501: 
>> 502:   return entry_point;
>> 503: }
> 
> Is the newline removal intentional?

It wasn't intentional. Thanks for spotting that. I added it back.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2114557661
PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2114553562

From duke at openjdk.org  Thu May 29 18:56:12 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Thu, 29 May 2025 18:56:12 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v4]
In-Reply-To: <kPx9NqOgNJPStCsPd4PtRhfbQeEXi5xbefvSjCHoPSY=.aa26a490-8f90-4e17-8c9e-cde0c25a9fbb@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <72GCipLKeCWCG-4jsG5XhZKkTdVsWafEq_wA0oD-0mk=.c70af814-54fe-43d2-b7c9-72b845eb99d5@github.com>
 <kPx9NqOgNJPStCsPd4PtRhfbQeEXi5xbefvSjCHoPSY=.aa26a490-8f90-4e17-8c9e-cde0c25a9fbb@github.com>
Message-ID: <eJbb5hzhM27dVuc7MD6kqvlLReNHthJNiRXttkPwzQo=.bb1151a7-959a-4f56-8ebf-bde8126ea5d4@github.com>

On Thu, 29 May 2025 08:21:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Mohamed Issa has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Remove comment mentioning invalid exception when NaN input is provided
>>  - Use rcx as base and r8 as index for address calculations in certain cbrt stub generator instructions
>>  - Remove unnecessary unpckhpd and unpcklpd definitions in macro-assembler header file
>>  - Remove unnecessary movapd definitions in macro-assembler header file
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp line 185:
> 
>> 183: 
>> 184: #define __ _masm->
>> 185: 
> 
> Original Intel libm inline sequence uses hexadecimal constants, I would have preferred to use them as it is to maintain 1:1 mapping b/w instruction sequence.

The assembly reference code used for this implementation uses decimal constants.

> test/micro/org/openjdk/bench/java/lang/CbrtPerf.java line 56:
> 
>> 54:     public static class CbrtPerfRanges {
>> 55:         public static int cbrtInputCount = 2048;
>> 56: 
> 
> Please create separate CbrtPerfSpecialValues for +/- 0.0 and +/- Infinity and NaN values.
> I understand that handling special cases in intrinsic may impact general case performance but its ok to have atleast micro for it.

Ok, I added this to the new set of micro-benchmarks. I kept them as variable values.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2114551009
PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2114552717

From jlu at openjdk.org  Thu May 29 19:06:01 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 May 2025 19:06:01 GMT
Subject: RFR: 8358089: GenerateKeyList.java COMPAT removal update
Message-ID: <FHqDrBv0LPDDAtIbhtieILpmn2aVEfq8XtJ5Afnbc6s=.13cbef12-e19c-4ea5-8254-dbc9f4a56b97@github.com>

Please review this PR which updates the test tool `GenerateKeyList.java` after the COMPAT locale data removal.

`LocaleDataTest.java` may optionally use the `GenerateKeyList.java` tool; the latter requires similar bundle name changes that were made to the former in https://bugs.openjdk.org/browse/JDK-8357075.

Additionally, the CollationData bundle name needs to be adjusted to properly retrieve its contents. This was not previously exposed because `LocaleData.cldr` does not contain any CollationData entries.

We may also want to consider moving `GenerateKeyList.java` into the same space as `LocaleDataTest.java`.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/25527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25527&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358089
  Stats: 19 lines in 2 files changed: 7 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/25527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25527/head:pull/25527

PR: https://git.openjdk.org/jdk/pull/25527

From prr at openjdk.org  Thu May 29 19:08:54 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 29 May 2025 19:08:54 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
Message-ID: <dVw-4Yl3AI2y1kYAwY1rgjjRrqCSiIVv2UN-UHuJtB0=.81a20509-7795-4ad7-b7c9-f42970d65318@github.com>

On Mon, 26 May 2025 08:20:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java

Approving client changes

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25228#pullrequestreview-2879326497

From bpb at openjdk.org  Thu May 29 19:10:46 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 29 May 2025 19:10:46 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v14]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <6JakAvYfDIFLQHI8MwxCjvEl-4MR4rQmJzJNGytPQIw=.689b5a9f-c0c6-4dea-8e6b-b668b999e8c0@github.com>

> 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 14 commits:

 - Merge
 - Merge
 - 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
 - ... and 4 more: https://git.openjdk.org/jdk/compare/79aff26c...95ce13fb

-------------

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=13
  Stats: 1540 lines in 93 files changed: 774 ins; 668 del; 98 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 duke at openjdk.org  Thu May 29 19:48:53 2025
From: duke at openjdk.org (ExE Boss)
Date: Thu, 29 May 2025 19:48:53 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications
In-Reply-To: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
Message-ID: <q8Dqv_CIAVnQD-dx1Ykk4Dqa-ALHXAFOO5gtjtDJkSc=.bf889821-c934-4d1c-ba6d-b53d39930ecc@github.com>

On Thu, 29 May 2025 00:21:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> For a full explanation, see the bug report [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015).
> 
> This PR includes three related changes:
> * New overrides in SequencedMap view collection implementations, which improve their behavior.
> * Update to `@implSpec` clauses to reflect this behavior (which was previously ill-specified).
> * Update to a test which relied on unspecified behavior.

src/java.base/share/classes/java/util/AbstractMap.java line 881:

> 879:         UnsupportedOperationException uoe() { return new UnsupportedOperationException(); }
> 880:         // convert null entry return values into NSEE
> 881:         <T> T nsee(T entry) {

This?method can?be?static:
Suggestion:

        static <T> T nsee(T entry) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25515#discussion_r2114636544

From swen at openjdk.org  Thu May 29 20:12:58 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 29 May 2025 20:12:58 GMT
Subject: Integrated: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes
In-Reply-To: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
Message-ID: <7onUACDyYrLjYSMiewPjLvMtTiID2M4ADzDal-6AiXY=.24cfeec5-1a33-428d-a752-cbbd9a57d738@github.com>

On Sat, 24 May 2025 10:00:56 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, these are immutable, We should add `@Stable` and final to provide information to the optimizer.

This pull request has now been integrated.

Changeset: 727412d1
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/727412d1b5f0764363ebd2ff600d4b7f0c99bb9b
Stats:     39 lines in 10 files changed: 15 ins; 0 del; 24 mod

8357690: Add @Stable and final to java.lang.CharacterDataLatin1 and other CharacterData classes

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/25430

From jlu at openjdk.org  Thu May 29 21:19:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 May 2025 21:19:31 GMT
Subject: RFR: 8358089: Remove the GenerateKeyList.java test tool [v2]
In-Reply-To: <FHqDrBv0LPDDAtIbhtieILpmn2aVEfq8XtJ5Afnbc6s=.13cbef12-e19c-4ea5-8254-dbc9f4a56b97@github.com>
References: <FHqDrBv0LPDDAtIbhtieILpmn2aVEfq8XtJ5Afnbc6s=.13cbef12-e19c-4ea5-8254-dbc9f4a56b97@github.com>
Message-ID: <ZaMD7yGGqrfuB0pNrC9lbb2A0ciAE9X7wnp5l8vi800=.17f42c84-207d-4801-a5b5-3f82ecef784b@github.com>

> Please review this PR which removes the test tool `GenerateKeyList.java` after the COMPAT locale data removal.
> 
> `LocaleDataTest.java` may optionally use the `GenerateKeyList.java` tool. However, this tool is manually used and was primarily used for COMPAT data. There is no longer any point to keep it, and it can always be retrieved via the VCS if needed.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect some corrections

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25527/files
  - new: https://git.openjdk.org/jdk/pull/25527/files/f4313c47..807486d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25527&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25527&range=00-01

  Stats: 98 lines in 2 files changed: 0 ins; 97 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25527/head:pull/25527

PR: https://git.openjdk.org/jdk/pull/25527

From jlu at openjdk.org  Thu May 29 21:19:32 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 May 2025 21:19:32 GMT
Subject: RFR: 8358089: Remove the GenerateKeyList.java test tool [v2]
In-Reply-To: <ZaMD7yGGqrfuB0pNrC9lbb2A0ciAE9X7wnp5l8vi800=.17f42c84-207d-4801-a5b5-3f82ecef784b@github.com>
References: <FHqDrBv0LPDDAtIbhtieILpmn2aVEfq8XtJ5Afnbc6s=.13cbef12-e19c-4ea5-8254-dbc9f4a56b97@github.com>
 <ZaMD7yGGqrfuB0pNrC9lbb2A0ciAE9X7wnp5l8vi800=.17f42c84-207d-4801-a5b5-3f82ecef784b@github.com>
Message-ID: <sk_f1pftfLq8F2QSugSn2KeD-BwufHs0Ppav3Wx1d6k=.1149574f-7e84-4bba-8d88-be630bb98391@github.com>

On Thu, 29 May 2025 21:15:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes the test tool `GenerateKeyList.java` after the COMPAT locale data removal.
>> 
>> `LocaleDataTest.java` may optionally use the `GenerateKeyList.java` tool. However, this tool is manually used and was primarily used for COMPAT data. There is no longer any point to keep it, and it can always be retrieved via the VCS if needed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect some corrections

test/jdk/sun/text/resources/LocaleDataTest.java line 333:

> 331:                     || rbName.equals("TimeZoneNames")) {
> 332:                 fullName = UTIL_RESOURCES_PACKAGE + "." + rbName;
> 333:             } else if (rbName.equals("CollationData")) {

CLDR does not define CollationData, so this type of check actually needs to be removed, since we should not be including any CLDR data in the LocaleData.cldr file in the first place.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25527#discussion_r2114760076

From almatvee at openjdk.org  Thu May 29 21:29:53 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 29 May 2025 21:29:53 GMT
Subject: RFR: 8358017: Various enhancements of jpackage test helpers
In-Reply-To: <ZAdN-mYCPpLqwnA02zY5Ge2b6cxtNicRow9LJNTlMT8=.2eab053c-566a-4beb-8789-5514fcb5d104@github.com>
References: <ZAdN-mYCPpLqwnA02zY5Ge2b6cxtNicRow9LJNTlMT8=.2eab053c-566a-4beb-8789-5514fcb5d104@github.com>
Message-ID: <3JC4pbwXGddHPXQYIb-sr3O7qwRfYjt3h5qon5f3_vs=.63ff054a-8c39-46b4-b2f6-5e50acf02cad@github.com>

On Wed, 28 May 2025 03:35:40 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Various enhancements of jpackage test helpers:
>  - Can run fa tests when JAVA_TOOL_OPTIONS env variable contains `--module-path` option. This change makes support for `jpackage.test.clear-app-launcher-java-env-vars` system property redundant.
>  - Rework JUnitAdapter to make it run jpackage TestInstance objects as JUnit5 DynamicTest tests. This integrates jpackage test runs in IDEs (Verified with Eclipse IDE).
>  - Make jpackage tests fail fast when they are executed by JUnit test runner.
>  - Applied `./bin/blessed-modifier-order.sh` script on jpackage test helpers.
>  - Support loading jpackage tests from a custom classloader.
>  - Add support for using a custom ToolProvider implementation of jpackage with JPackageCommand.
> 
> The last two features are not currently in use. They were picked from the work-in-progress [JDK-8333727](https://bugs.openjdk.org/browse/JDK-8333727).

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25479#pullrequestreview-2879654342

From naoto at openjdk.org  Thu May 29 21:38:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 May 2025 21:38:50 GMT
Subject: RFR: 8358089: Remove the GenerateKeyList.java test tool [v2]
In-Reply-To: <ZaMD7yGGqrfuB0pNrC9lbb2A0ciAE9X7wnp5l8vi800=.17f42c84-207d-4801-a5b5-3f82ecef784b@github.com>
References: <FHqDrBv0LPDDAtIbhtieILpmn2aVEfq8XtJ5Afnbc6s=.13cbef12-e19c-4ea5-8254-dbc9f4a56b97@github.com>
 <ZaMD7yGGqrfuB0pNrC9lbb2A0ciAE9X7wnp5l8vi800=.17f42c84-207d-4801-a5b5-3f82ecef784b@github.com>
Message-ID: <qHJ_yazI9DwpKFoizz1PU3Ybb1cZY3V2spi0xm67oao=.e8b53805-37fc-4883-9deb-9f4708818339@github.com>

On Thu, 29 May 2025 21:19:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes the test tool `GenerateKeyList.java` after the COMPAT locale data removal.
>> 
>> `LocaleDataTest.java` may optionally use the `GenerateKeyList.java` tool. However, this tool is manually used and was primarily used for COMPAT data. There is no longer any point to keep it, and it can always be retrieved via the VCS if needed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect some corrections

LGTM. The manual tool hasn't been used and it does not cope with CLDR. Removing the tool would be appropriate.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25527#pullrequestreview-2879670600

From asemenyuk at openjdk.org  Thu May 29 21:47:55 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 29 May 2025 21:47:55 GMT
Subject: Integrated: 8358017: Various enhancements of jpackage test helpers
In-Reply-To: <ZAdN-mYCPpLqwnA02zY5Ge2b6cxtNicRow9LJNTlMT8=.2eab053c-566a-4beb-8789-5514fcb5d104@github.com>
References: <ZAdN-mYCPpLqwnA02zY5Ge2b6cxtNicRow9LJNTlMT8=.2eab053c-566a-4beb-8789-5514fcb5d104@github.com>
Message-ID: <1yaM6DUJDbF4HZtpj5tHgnJKtRrJH-3wXxR8a9XeaG0=.0235ffc1-4033-41ef-ba48-b156f6f8544f@github.com>

On Wed, 28 May 2025 03:35:40 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Various enhancements of jpackage test helpers:
>  - Can run fa tests when JAVA_TOOL_OPTIONS env variable contains `--module-path` option. This change makes support for `jpackage.test.clear-app-launcher-java-env-vars` system property redundant.
>  - Rework JUnitAdapter to make it run jpackage TestInstance objects as JUnit5 DynamicTest tests. This integrates jpackage test runs in IDEs (Verified with Eclipse IDE).
>  - Make jpackage tests fail fast when they are executed by JUnit test runner.
>  - Applied `./bin/blessed-modifier-order.sh` script on jpackage test helpers.
>  - Support loading jpackage tests from a custom classloader.
>  - Add support for using a custom ToolProvider implementation of jpackage with JPackageCommand.
> 
> The last two features are not currently in use. They were picked from the work-in-progress [JDK-8333727](https://bugs.openjdk.org/browse/JDK-8333727).

This pull request has now been integrated.

Changeset: a05f9dea
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a05f9dea18ec812abad1dbe0084c0c58384a9076
Stats:     199 lines in 13 files changed: 120 ins; 27 del; 52 mod

8358017: Various enhancements of jpackage test helpers

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/25479

From igraves at openjdk.org  Thu May 29 21:52:30 2025
From: igraves at openjdk.org (Ian Graves)
Date: Thu, 29 May 2025 21:52:30 GMT
Subject: RFR: 8356634: VectorShape#largestShapeFor should have public
 access [v4]
In-Reply-To: <JavbxK-K4oPsdH53sMhVG1RCYBYlyOdZ_6wZCQm0uzk=.edfacd8d-88fb-485d-a86c-e9ac1571a09d@github.com>
References: <JavbxK-K4oPsdH53sMhVG1RCYBYlyOdZ_6wZCQm0uzk=.edfacd8d-88fb-485d-a86c-e9ac1571a09d@github.com>
Message-ID: <4wQpGI-g5Da4om2A8cl2me2VWvH5ig-Dd6-XWhHApWk=.d2603fa0-bf22-445c-a254-bea6a02a8b0b@github.com>

> VectorShape#largestShapeFor is referenced in existing JavaDoc but has been package-private. This propose change makes it public and adds documentation for it.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Adding test coverage

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25513/files
  - new: https://git.openjdk.org/jdk/pull/25513/files/8b3f6fc4..097bd9dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25513&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25513&range=02-03

  Stats: 43 lines in 1 file changed: 42 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25513/head:pull/25513

PR: https://git.openjdk.org/jdk/pull/25513

From igraves at openjdk.org  Thu May 29 22:03:29 2025
From: igraves at openjdk.org (Ian Graves)
Date: Thu, 29 May 2025 22:03:29 GMT
Subject: RFR: 8356634: VectorShape#largestShapeFor should have public
 access [v5]
In-Reply-To: <JavbxK-K4oPsdH53sMhVG1RCYBYlyOdZ_6wZCQm0uzk=.edfacd8d-88fb-485d-a86c-e9ac1571a09d@github.com>
References: <JavbxK-K4oPsdH53sMhVG1RCYBYlyOdZ_6wZCQm0uzk=.edfacd8d-88fb-485d-a86c-e9ac1571a09d@github.com>
Message-ID: <kVx02Equ01JYZJKDfwDATTPusQHG6SjGouqOGaWkfQ0=.447d2808-4f3d-42c2-ac2f-8b7d7fcb7203@github.com>

> VectorShape#largestShapeFor is referenced in existing JavaDoc but has been package-private. This propose change makes it public and adds documentation for it.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Updating copyrights

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25513/files
  - new: https://git.openjdk.org/jdk/pull/25513/files/097bd9dd..90066a23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25513&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25513&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25513/head:pull/25513

PR: https://git.openjdk.org/jdk/pull/25513

From igraves at openjdk.org  Thu May 29 22:03:29 2025
From: igraves at openjdk.org (Ian Graves)
Date: Thu, 29 May 2025 22:03:29 GMT
Subject: RFR: 8356634: VectorShape#largestShapeFor should have public
 access [v4]
In-Reply-To: <4wQpGI-g5Da4om2A8cl2me2VWvH5ig-Dd6-XWhHApWk=.d2603fa0-bf22-445c-a254-bea6a02a8b0b@github.com>
References: <JavbxK-K4oPsdH53sMhVG1RCYBYlyOdZ_6wZCQm0uzk=.edfacd8d-88fb-485d-a86c-e9ac1571a09d@github.com>
 <4wQpGI-g5Da4om2A8cl2me2VWvH5ig-Dd6-XWhHApWk=.d2603fa0-bf22-445c-a254-bea6a02a8b0b@github.com>
Message-ID: <D1S4OFuk6nOdBxRAwXBnKH7_ZNEWazs8yjhHB3DvHTs=.af19eba4-197e-4c8d-a768-0519a0ea62d4@github.com>

On Thu, 29 May 2025 21:52:30 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> VectorShape#largestShapeFor is referenced in existing JavaDoc but has been package-private. This propose change makes it public and adds documentation for it.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding test coverage

Added test coverage for this method based on its codepath and the *MaxVector shape path for consistency.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25513#issuecomment-2920681247

From jlu at openjdk.org  Thu May 29 22:04:03 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 May 2025 22:04:03 GMT
Subject: RFR: 8358095: Cleanup tests with explicit locale provider set to only
 CLDR
Message-ID: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>

Please review this PR which cleans up some i18n tests.

There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 

As this change is trivial cleanup, bug IDs are not updated in this change.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/25532/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25532&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358095
  Stats: 40 lines in 21 files changed: 0 ins; 1 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/25532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25532/head:pull/25532

PR: https://git.openjdk.org/jdk/pull/25532

From bpb at openjdk.org  Thu May 29 22:14:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 29 May 2025 22:14:53 GMT
Subject: RFR: 8358095: Cleanup tests with explicit locale provider set to
 only CLDR
In-Reply-To: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
Message-ID: <3JZoZQCj83-RwLWCtteqEOha_MKEuMAzLAlAuoTVm-k=.957d4703-17f5-4da4-ad56-dad50b694e26@github.com>

On Thu, 29 May 2025 21:59:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which cleans up some i18n tests.
> 
> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
> 
> As this change is trivial cleanup, bug IDs are not updated in this change.

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25532#pullrequestreview-2879728852

From duke at openjdk.org  Thu May 29 22:33:52 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Thu, 29 May 2025 22:33:52 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v4]
In-Reply-To: <kPx9NqOgNJPStCsPd4PtRhfbQeEXi5xbefvSjCHoPSY=.aa26a490-8f90-4e17-8c9e-cde0c25a9fbb@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <72GCipLKeCWCG-4jsG5XhZKkTdVsWafEq_wA0oD-0mk=.c70af814-54fe-43d2-b7c9-72b845eb99d5@github.com>
 <kPx9NqOgNJPStCsPd4PtRhfbQeEXi5xbefvSjCHoPSY=.aa26a490-8f90-4e17-8c9e-cde0c25a9fbb@github.com>
Message-ID: <TKma1AJWRWYjH4SZ4N2CTukn1yXtu_wfACG0dTbTRFg=.e2e27f2c-e4cc-4bf8-9a04-2985dc007002@github.com>

On Thu, 29 May 2025 08:36:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Mohamed Issa has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Remove comment mentioning invalid exception when NaN input is provided
>>  - Use rcx as base and r8 as index for address calculations in certain cbrt stub generator instructions
>>  - Remove unnecessary unpckhpd and unpcklpd definitions in macro-assembler header file
>>  - Remove unnecessary movapd definitions in macro-assembler header file
>
> Patch looks good to me,  some comment included.

@jatin-bhateja Please let me know if there's anything else to address.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2920726222

From yujige at gmail.com  Thu May 29 22:44:44 2025
From: yujige at gmail.com (Jige Yu)
Date: Thu, 29 May 2025 15:44:44 -0700
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <3f9e1798-2edb-47b9-9d33-b455055dbcf5@oracle.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtAUfyUHOdmSeZ2Azny=RJU63FQozY2NxpYu-4xQYCRkA@mail.gmail.com>
 <MW4PR10MB5774B089653C902899FEBEAFFFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB5774BB2B60EE5A1F4B1A7306FFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvxZ0gpHJXW0ctuHwEGwfStfjmLvwV1CgSWrr8438rWPA@mail.gmail.com>
 <MW4PR10MB5774EF4D4316B5BE46B29A0EFFF12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYsJyHeEs1fc4DRTZKwDO_U4Pyjv45BQ5fvr6VbboaVCTQ@mail.gmail.com>
 <MW4PR10MB57743363CCA3306B316F3EEDFF65A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYuPzVW+VHt_MzOrXW93iNv0A03JFSCV+yawCFeaLm=HsA@mail.gmail.com>
 <CAKD1RYtpahV4766wNodvcrSGFqJ6ereG1fUJFi-yEviOpLcb=Q@mail.gmail.com>
 <MW4PR10MB577459221CD425EFD5686426FF67A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYscAh46O77zw=S68DefM9Aonnn7DjCB_8YJ-eWTKSpNDQ@mail.gmail.com>
 <3f9e1798-2edb-47b9-9d33-b455055dbcf5@oracle.com>
Message-ID: <CAKD1RYtcmwqDbF+i6DEXJKvAnZ-WcCc7xrEK_tRygKucpDMxtw@mail.gmail.com>

Yeah. I can see these distinctions and guidelines being useful for callers
of the low-level concurrency primitive methods (semaphore etc.)

But at a higher level, in the application code, does anyone know of a
plausible scenario where being forced to catch IE is useful? It seems like
you either always propagate it up, or you have to catch it and risk
forgetting to re-interrupt the thread. And, *there is not much useful thing
you can do* that's different from other types of exceptions.

That's why I think it may be reasonable for mapConcurrent() to:

- absorb cancellation into the API contract and catch the IE
and throw a more semantically specific exception (an unchecked exception
indicating the mapConcurrent() has been interrupted).

Thinking from two typical ways of IE scenarios:

   - mapConcurrent() is wrapped in a Future, and the future is canceled -
   if you've canceled it, the unchecked exception shouldn't bother you.
   - mapConcurrent() is inside an outer mapConcurrent(), or inside an outer
   structured concurrency scope - in either case, interruption happens because
   a sibling task has failed to trigger the fail-fast cancellation. Checked
   exceptions work fine too.

I can't see harm being done for either case, compared to letting it keep
running through all elements (what if the stream is infinite or very very
long?)

On Wed, May 28, 2025 at 10:19?PM David Holmes <david.holmes at oracle.com>
wrote:

> On 29/05/2025 3:45 am, Jige Yu wrote:
> > 17.2.4 is specifically about the Object wait()/notify() API, yeah?
> >
> > I've always had this confusion in my mind that I couldn't find an
> > authoritative source for: what was the point of checked
> > InterruptedException?
>
> Interruption and IE provide a limited capability for task cancellation.
> As such any method that calls a method that can throw IE has to be aware
> that the method can do that, and by having IE be checked, they are
> forced to confront the question: how do I respond to cancellation? As
> Doug Lea describes in his book there are a few ways to respond to this
> cancellation notice depending on the semantics of the method involved:
>
> - make cancellation part of your own API, declare and rethrow any IE
> should encounter (and your caller then has to make the choice)
> - absorb cancellation into your general API contract and catch the IE
> and throw a more semantically specific exception
> - handle low-level cancellation by catching the IE and doing whatever
> logic is appropriate
>
> David
> -----
>
> > My naive observation has been two fold:
> >
> >  1. In most cases, when possible, applications declare "throws IE" and
> >     let it propagate all the way up the call stack. This works exactly
> >     the same as if IE were unchecked.
> >  2. When the application is cornered into a Runnable, Function and
> >     cannot "throws IE", it has to catch(IE),  remember to re-interrupt
> >     the thread, and wrap in an unchecked. Except *it often forgets to
> >     re-interrupt*.
> >
> > At the lowest level concurrent primitives (wait(), notify(), Semaphore),
> > I presume IE being an integral part of the API contract.
> >
> > But at mid-level APIs (Future, mapConcurrent()), or high-level
> > applications, I've always been at a loss on why we needed the checked IE
> > in the first place.
> >
> > IE used to happen when someone calls Future.cancel(true). Now with
> > structured concurrency, it can also be caused by a sibling task failing
> > and fail-fast.
> >
> > But aside from the extra ceremony and the extra room for error
> > (forgetting to reinterrupt), what do we get from it? I was asking
> > ChatGPT about real-life scenarios where specifically catching and
> > handling IE is necessary but all ChatGPT gave me was cases where the
> > code has to re-interrupt, which would have been unnecessary if IE were
> > unchecked and didn't clear the interruption bit.
> >
> > Would appreciate a pointer to code or authoritative discussion about
> > this matter.
> >
> > Sorry for the tangent!
> >
> >
> > On Wed, May 28, 2025 at 1:03?AM Viktor Klang <viktor.klang at oracle.com
> > <mailto:viktor.klang at oracle.com>> wrote:
> >
> >     It would seem to require a change to the Java Language Specification
> >     section 17.2.4
> >
> >     Cheers,
> >     ?
> >
> >     *
> >     *
> >     *Viktor Klang*
> >     Software Architect, Java Platform Group
> >     Oracle
> >
>  ------------------------------------------------------------------------
> >     *From:* Jige Yu <yujige at gmail.com <mailto:yujige at gmail.com>>
> >     *Sent:* Wednesday, 28 May 2025 00:35
> >     *To:* Viktor Klang <viktor.klang at oracle.com
> >     <mailto:viktor.klang at oracle.com>>
> >     *Cc:* core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org>
> >     <core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org>>
> >     *Subject:* Re: [External] : Re: mapConcurrent() with
> >     InterruptedException
> >     That said, I'm still curious. Have you considered propagating
> >     cancellation, re-interrupting the current thread, and then throwing
> >     an unchecked exception upon interruption? It's going to be the most
> >     fail-fast-compatible.
> >
> >     catch (IE interrupted) {
> >        cancel all pending futures
> >        Thread.currentThread().interrupt();
> >        throw new UncheckedInterruptedException();
> >     }
> >
> >     What are the concerns against such practice?
> >
> >
> >
> >
> >
> >     On Mon, May 26, 2025 at 8:31?AM Jige Yu <yujige at gmail.com
> >     <mailto:yujige at gmail.com>> wrote:
> >
> >         Yeah, I think I missed the task cancellation and the joining
> part.
> >
> >         When the mapConcurrent() thread is interrupted, it propagates
> >         the cancellation to the child threads.
> >
> >         And if any of the children threads (running the user-provided
> >         Function) receives that cancellation, it will still need to
> >         catch it and handle interruption.
> >
> >         That means the interruption isn't swallowed. If the user code
> >         wants to abort, they can always just throw an unchecked
> >         exception and catch it from the caller of mapConcurrent().
> >
> >         That should do for most of the IO type work.
> >
> >         This makes sense.
> >
> >
> >
> >         On Mon, May 26, 2025 at 12:30?AM Viktor Klang
> >         <viktor.klang at oracle.com <mailto:viktor.klang at oracle.com>>
> wrote:
> >
> >             Yes, the updated Gatherers.mapConcurrent will continue under
> >             interruption until done, and then restore the interrupt
> >             status of the calling thread.
> >
> >             It cannot (reasonably) do anything else?if it were to throw
> >             InterruptedException, it couldn't since that is a checked
> >             exception and there's no tracking of checked exceptions
> >             throughout a Stream, and that is the specified behavior to
> >             handle thread interrupts (i.e. clear flag and throw
> >             InterruptedException, which is not possible in this case;
> >             or, make sure that interrupt status is maintained, which is
> >             possible in this case.
> >
> >             I have given it some more thought in the meantime, but I
> >             haven't arrived in something more satisfactory than that,
> yet.
> >
> >             Cheers,
> >             ?
> >
> >             *
> >             *
> >             *Viktor Klang*
> >             Software Architect, Java Platform Group
> >             Oracle
> >
>  ------------------------------------------------------------------------
> >             *From:* Jige Yu <yujige at gmail.com <mailto:yujige at gmail.com>>
> >             *Sent:* Monday, 26 May 2025 03:07
> >             *To:* Viktor Klang <viktor.klang at oracle.com
> >             <mailto:viktor.klang at oracle.com>>
> >             *Cc:* core-libs-dev at openjdk.org <mailto:core-libs-
> >             dev at openjdk.org> <core-libs-dev at openjdk.org <mailto:core-
> >             libs-dev at openjdk.org>>
> >             *Subject:* Re: [External] : Re: mapConcurrent() with
> >             InterruptedException
> >             Thanks Viktor!
> >
> >             Sorry, I was giving myself more time to read the code, but
> >             then I lost track.
> >
> >             If I'm reading the code right, the current behavior is that
> >             if the current thread is interrupted, the mapConcurrent()
> >             would suppress the interruption until all elements are
> >             processed? (It will then restore the interruption bit)
> >
> >             Doesn't this break fail fast?
> >
> >             For example, I may have a mapConcurrent() called from within
> >             structured concurrency, and that fans out to two operations:
> >             ?
> >             scope.fork(() -> doA());
> >             scope.fork(() -> doB());  // calls mapConcurrent() internally
> >             scope.join().throwIfFailed();
> >
> >             If doA() fails, doB() will be cancelled (thread interrupted).
> >
> >             If mapConcurrent() ignores the interruption, and if doB has
> >             a long list to process, it'll continue to consume system
> >             resources even when the caller no longer needs the results,
> no?
> >
> >
> >             On Fri, Feb 7, 2025 at 2:16?AM Viktor Klang
> >             <viktor.klang at oracle.com <mailto:viktor.klang at oracle.com>>
> >             wrote:
> >
> >                  >Sorry, did the PR stop using Semaphore?
> >
> >                 No, not that PR. See: https://github.com/openjdk/jdk/
> >                 commit/450636ae28b84ded083b6861c6cba85fbf87e16e
> >                 <https://urldefense.com/v3/__https://github.com/openjdk/
> >                 jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e__;!!
> >                 ACWV5N9M2RV99hQ!
> >                 OKfWrvJEDCkiHcT5b4a6gfeomZzZeq3jv6ir2vf2I5WWIhujtb-
> >                 by_VuQFaAPDIuAA0qAwpTUjllXMPF$>
> >
> >                 The problem with interruption under parallel evaluation
> >                 is that there is no general support for propagation of
> >                 interruption in CountedCompleters. Adding support for
> >                 such in (at least) GathererOp needs further study before
> >                 contemplating making any changes to mapConcurrent()'s
> >                 interruption policy.
> >
> >                 Cheers,
> >                 ?
> >
> >                 *
> >                 *
> >                 *Viktor Klang*
> >                 Software Architect, Java Platform Group
> >                 Oracle
> >
> >
>  ------------------------------------------------------------------------
> >                 *From:* Jige Yu <yujige at gmail.com <mailto:
> yujige at gmail.com>>
> >                 *Sent:* Thursday, 6 February 2025 17:04
> >                 *To:* Viktor Klang <viktor.klang at oracle.com
> >                 <mailto:viktor.klang at oracle.com>>
> >                 *Cc:* core-libs-dev at openjdk.org <mailto:core-libs-
> >                 dev at openjdk.org> <core-libs-dev at openjdk.org
> >                 <mailto:core-libs-dev at openjdk.org>>
> >                 *Subject:* Re: [External] : Re: mapConcurrent() with
> >                 InterruptedException
> >                 Sorry, did the PR stop using Semaphore?
> >
> >                 I had naively thought that mapConcurrent() will keep a
> >                 buffer of Future of all currently-running concurrent
> >                 tasks (it can be a ConcurrentMap<TaskKey, Future> if we
> >                 don't have to ensure FIFO).
> >
> >                 Upon interruption, the main thread can
> >                 call .cancel(true) on all pending Futures; optionally
> >                 join with the VTs (if we need to block until all VTs
> >                 exit); then propagate exception.
> >
> >                 Upon completion, each task just removes itself from the
> >                 ConcurrentMap.
> >
> >                 Just in case it adds anything.
> >
> >
> >
> >                 On Thu, Feb 6, 2025 at 6:47?AM Viktor Klang
> >                 <viktor.klang at oracle.com
> >                 <mailto:viktor.klang at oracle.com>> wrote:
> >
> >                     After some more investigation it seems tractable to
> >                     propagate interruption of the caller in sequential
> >                     mode, but parallel mode will require much bigger
> >                     considerations.
> >
> >                     I made a comment to that effect on the JBS issue:
> >                     https://bugs.openjdk.org/browse/JDK-8349462?
> >
>  focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017
> <
> https://bugs.openjdk.org/browse/JDK-8349462?focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017
> >
> >
> >
> >                     Cheers,
> >                     ?
> >
> >                     *
> >                     *
> >                     *Viktor Klang*
> >                     Software Architect, Java Platform Group
> >                     Oracle
> >
>  ------------------------------------------------------------------------
> >                     *From:* Viktor Klang <viktor.klang at oracle.com
> >                     <mailto:viktor.klang at oracle.com>>
> >                     *Sent:* Thursday, 6 February 2025 11:51
> >                     *To:* Jige Yu <yujige at gmail.com
> >                     <mailto:yujige at gmail.com>>
> >                     *Cc:* core-libs-dev at openjdk.org <mailto:core-libs-
> >                     dev at openjdk.org> <core-libs-dev at openjdk.org
> >                     <mailto:core-libs-dev at openjdk.org>>
> >                     *Subject:* Re: [External] : Re: mapConcurrent() with
> >                     InterruptedException
> >                     I think alignment in behavior between parallel
> >                     Stream and mapConcurrent in terms of how
> >                     interruptions are handled is a possible path forward.
> >
> >                     I decided to close the PR for now as I realized my
> >                     parallel Stream example had misled me regarding its
> >                     exception throwing, so I'll need to go back and
> >                     refine the solution.
> >
> >                     It still seems solvable though.
> >
> >                     Cheers,
> >                     ?
> >
> >                     *
> >                     *
> >                     *Viktor Klang*
> >                     Software Architect, Java Platform Group
> >                     Oracle
> >
>  ------------------------------------------------------------------------
> >                     *From:* Jige Yu <yujige at gmail.com
> >                     <mailto:yujige at gmail.com>>
> >                     *Sent:* Wednesday, 5 February 2025 19:20
> >                     *To:* Viktor Klang <viktor.klang at oracle.com
> >                     <mailto:viktor.klang at oracle.com>>
> >                     *Cc:* core-libs-dev at openjdk.org <mailto:core-libs-
> >                     dev at openjdk.org> <core-libs-dev at openjdk.org
> >                     <mailto:core-libs-dev at openjdk.org>>
> >                     *Subject:* Re: [External] : Re: mapConcurrent() with
> >                     InterruptedException
> >                     Oh good call!
> >
> >                     I forgot to check what parallel streams do upon
> >                     interruption (didn't think they do any blocking
> >                     calls, but at least the main thread must block).
> >
> >                     On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang
> >                     <viktor.klang at oracle.com
> >                     <mailto:viktor.klang at oracle.com>> wrote:
> >
> >                         Hi Jige,
> >
> >                         I opened an issue to track the concern, and I
> >                         have proposed a change which seems to align well
> >                         with how parallel streams behave under caller
> >                         thread interruption.
> >
> >                         I've opened the following PR for review:
> >                         https://github.com/openjdk/jdk/pull/23467
> >                         <https://urldefense.com/v3/__https://github.com/
> >                         openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!
> >
>  M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
> >
> >                         If you are able to make a local OpenJDK build
> >                         with that solution you could check if it
> >                         addresses your use-cases (or not).
> >                         <https://urldefense.com/v3/__https://github.com/
> >                         openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!
> >
>  M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
> >
> >                         8349462: Gatherers.mapConcurrent could support
> >                         async interrupts by viktorklang-ora ? Pull
> >                         Request #23467 ? openjdk/jdk <https://
> >                         urldefense.com/v3/__https://github.com/openjdk/
> >                         jdk/pull/23467__;!!ACWV5N9M2RV99hQ!
> >
>  M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
> >                         This change is likely going to need some extra
> >                         verbiage in the spec for mapConcurrent, and thus
> >                         a CSR. This behavior aligns mapConcurrent with
> >                         how parallel streams work in conjunction with
> >                         interrup...
> >                         github.com <https://urldefense.com/v3/__http://
> >                         github.com__;!!ACWV5N9M2RV99hQ!
> >
>  M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89DBkMefT$>
> >
> >
> >
> >                         Cheers,
> >                         ?
> >
> >                         *
> >                         *
> >                         *Viktor Klang*
> >                         Software Architect, Java Platform Group
> >                         Oracle
> >
>  ------------------------------------------------------------------------
> >                         *From:* Jige Yu <yujige at gmail.com
> >                         <mailto:yujige at gmail.com>>
> >                         *Sent:* Wednesday, 5 February 2025 16:24
> >                         *To:* Viktor Klang <viktor.klang at oracle.com
> >                         <mailto:viktor.klang at oracle.com>>
> >                         *Cc:* core-libs-dev at openjdk.org <mailto:core-
> >                         libs-dev at openjdk.org> <core-libs-dev at openjdk.org
> >                         <mailto:core-libs-dev at openjdk.org>>
> >                         *Subject:* Re: [External] : Re: mapConcurrent()
> >                         with InterruptedException
> >                         Thanks Viktor!
> >
> >                         I understand the problem.
> >
> >                         The main reason I asked is because I want to
> >                         understand how the core Java team thinks of
> >                         throwing an unchecked exception.
> >
> >                         As explained above, I consider losing
> >                         cancellability a big deal, a deal breaker even.
> >                         And I thought throwing unchecked is more
> >                         acceptable. Because the most common reason the
> >                         mapConcurrent() VT can be interrupted is due to
> >                         cancellation from a parent mapConcurrent(), or a
> >                         parent Structured Concurrency scope. The
> >                         cancellation could be either from an organic
> >                         exception, or from the downstream not needing
> >                         more elements, like maybe due to findFirst()
> >                         already getting an element.
> >
> >                         In both cases, since the concurrent operation is
> >                         already cancelled (result ignored), what
> >                         exception pops up to the top level isn't that
> >                         big of a deal (perhaps only a log record will be
> >                         seen?)
> >
> >                         But if the core Java team considers it a bad
> >                         idea, I would love to learn and adjust.
> >
> >                         On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang
> >                         <viktor.klang at oracle.com
> >                         <mailto:viktor.klang at oracle.com>> wrote:
> >
> >                             Hi,
> >
> >                             The problem is that mapConcurrent cannot
> >                             throw InterruptedException because that is a
> >                             checked exception, so we cannot clear the
> >                             interrupted flag and throw that exception.
> >
> >                             So the updated semantics is to not cut the
> >                             stream short but instead run to completion,
> >                             restoring the interruption flag.
> >
> >                             There exists a couple of alternatives to
> >                             this approach which I am contemplating, but
> >                             they need to be further explored before I
> >                             consider moving forward with any of them.
> >
> >                             Cheers,
> >                             ?
> >
> >                             *
> >                             *
> >                             *Viktor Klang*
> >                             Software Architect, Java Platform Group
> >                             Oracle
> >
>  ------------------------------------------------------------------------
> >                             *From:* Jige Yu <yujige at gmail.com
> >                             <mailto:yujige at gmail.com>>
> >                             *Sent:* Monday, 27 January 2025 17:00
> >                             *To:* Viktor Klang <viktor.klang at oracle.com
> >                             <mailto:viktor.klang at oracle.com>>
> >                             *Cc:* core-libs-dev at openjdk.org
> >                             <mailto:core-libs-dev at openjdk.org> <core-
> >                             libs-dev at openjdk.org <mailto:core-libs-
> >                             dev at openjdk.org>>
> >                             *Subject:* Re: [External] : Re:
> >                             mapConcurrent() with InterruptedException
> >                             Thanks Viktor!
> >
> >                             It looks like the current fix ignores
> >                             interruption.
> >
> >                             I want to make sure my concern of it
> >                             defeating cancellation is heard and
> understood.
> >
> >                             The scenarios I worry about is for a
> >                             mapConcurrent() that fans out to another
> >                             method call, which internally calls
> >                             mapConcurrent() as implementation detail.
> >
> >                             An example:
> >
> >                             List<RefundResponse>
> >                             refundHelper(transaction)
> >                             {  transaction.creditCardAccounts.stream()
> >                               .gather(mapConcurrent(acct ->
> >                             service.refund(acct))    .toList(); }
> >                             transactions.stream()
> >                               .gather(mapConcurrent(transaction ->
> >                             refundHelper(transaction));
> >
> >
> >                             It seems undesirable that in such a case all
> >                             the service.refund() calls become non
> >                             cancellable, because the only way the outer
> >                             mapConcurrent() cancels the refundHelper()
> >                             calls is through Thread.interrupt() the
> >                             virtual threads that call refundHelper(),
> >                             which would then be disabled by the inner
> >                             mapConcurrent().
> >
> >                             Does this example make sense to you? I can
> >                             further explain if anything isn't clear.
> >
> >                             But I want to make sure the decision to
> >                             disable interruption is deliberate judgement
> >                             call that such nested mapConcurrent() is
> >                             unlikely,or not important.
> >
> >                             Cheers,
> >
> >
> >
> >                             On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang
> >                             <viktor.klang at oracle.com
> >                             <mailto:viktor.klang at oracle.com>> wrote:
> >
> >                                 Hi!
> >
> >                                 Please see: https://github.com/openjdk/
> >                                 jdk/pull/23100 <https://urldefense.com/
> >                                 v3/__https://github.com/openjdk/jdk/
> >                                 pull/23100__;!!ACWV5N9M2RV99hQ!
> >
>  IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>
> >
> >                                 Cheers,
> >                                 ?
> >
> >                                 *
> >                                 *
> >                                 *Viktor Klang*
> >                                 Software Architect, Java Platform Group
> >                                 Oracle
> >
>  ------------------------------------------------------------------------
> >                                 *From:* Jige Yu <yujige at gmail.com
> >                                 <mailto:yujige at gmail.com>>
> >                                 *Sent:* Sunday, 26 January 2025 23:03
> >                                 *To:* Viktor Klang
> >                                 <viktor.klang at oracle.com
> >                                 <mailto:viktor.klang at oracle.com>>
> >                                 *Cc:* core-libs-dev at openjdk.org
> >                                 <mailto:core-libs-
> >                                 dev at openjdk.org> <core-libs-
> >                                 dev at openjdk.org <mailto:core-libs-
> >                                 dev at openjdk.org>>
> >                                 *Subject:* [External] : Re:
> >                                 mapConcurrent() with InterruptedException
> >                                 Checking in on what you've found out,
> >                                 Viktor.
> >
> >                                  From where we left off, I understand
> >                                 that you were looking at alternatives
> >                                 instead of silent truncation?
> >
> >                                 Have you reached any conclusion?
> >
> >                                 We touched on disallowing interruption
> >                                 during mapConcurrent(). I still have
> >                                 concerns with disabling cancellation,
> >                                 because it basically undoes this API
> >                                 note from the javadoc <https://
> >                                 cr.openjdk.org/~alanb/sc-20240503/
> >                                 java.base/java/util/stream/
> >
>  Gatherers.html#mapConcurrent(int,java.util.function.Function)>:
> >
> >                                 API Note:
> >
> >                                     In progress tasks will be attempted
> >                                     to be cancelled, on a best-effort
> >                                     basis, in situations where the
> >                                     downstream no longer wants to
> >                                     receive any more elements.
> >
> >                                 In reality, people will use
> >                                 mapConcurrent() to fan out rpcs.
> >                                 Sometimes these rpcs are just a single
> >                                 blocking call; yet sometimes they may
> >                                 themselves be a Structured Concurrency
> >                                 scope, with 2 or 3 rpcs that constitute
> >                                 a single logical operation. Under two
> >                                 conditions, cancellation is imho
> >                                 important semantic:
> >
> >                                  1. The downstream code uses
> >                                     filter().findFirst(), and when it
> >                                     sees an element, it will return and
> >                                     no longer needs the other pending
> >                                     rpcs to complete. If cancellation is
> >                                     disabled, these unnecessary rpcs
> >                                     will waste system resources.
> >                                  2. One of the rpc throws and the Stream
> >                                     pipeline needs to propagate the
> >                                     exception. Again, if the other rpcs
> >                                     cannot be cancelled, we'll have many
> >                                     zombie rpcs.
> >
> >                                 Zombie rpcs may or may not be a deal
> >                                 breaker, depending on the specific use
> >                                 case. But for a JDK library, losing
> >                                 cancellation would have a negative
> >                                 impact on usability.
> >
> >                                 My 2c,
> >
> >
> >                                 On Fri, Jan 3, 2025 at 9:18?AM Viktor
> >                                 Klang <viktor.klang at oracle.com
> >                                 <mailto:viktor.klang at oracle.com>> wrote:
> >
> >                                     Hi Ben,
> >
> >                                     Thanks for raising these questions?
> >                                     getting feedback is crucial in the
> >                                     Preview stage of features.
> >
> >                                     I wrote a reply to the Reddit thread
> >                                     so I'll just summarize here:
> >
> >                                     It is important to note that /
> >                                     mapConcurrent()/ is not a part of
> >                                     the Structured Concurrency JEPs, so
> >                                     it is not designed to join SC scopes.
> >
> >                                     I'm currently experimenting with
> >                                     ignoring-but-restoring interrupts on
> >                                     the "calling thread" for /
> >                                     mapConcurrent()/, as well as capping
> >                                     work-in-progress to /
> >                                     maxConcurrency/ (not only capping
> >                                     the concurrency but also the amount
> >                                     of completed-but-yet-to-be-pushed
> >                                     work). Both of these adjustments
> >                                     should increase predictability of
> >                                     behavior in the face of blocking
> >                                     operations with variable delays.
> >
> >                                     Another adjustment I'm looking at
> >                                     right now is to harden/improve the
> >                                     cleanup to wait for concurrent tasks
> >                                     to acknowledge cancellation, so that
> >                                     once the finisher is done executing
> >                                     the VTs are known to have terminated.
> >
> >                                     As for not preserving the encounter
> >                                     order, that would be a completely
> >                                     different thing, and I'd encourage
> >                                     you to experiment with that if that
> >                                     functionality would be interesting
> >                                     for your use-case(s).
> >
> >                                     Again, thanks for your feedback!
> >
> >                                     Cheers,
> >                                     ?
> >
> >                                     *
> >                                     *
> >                                     *Viktor Klang*
> >                                     Software Architect, Java Platform
> Group
> >                                     Oracle
> >
>  ------------------------------------------------------------------------
> >                                     *From:* core-libs-dev <core-libs-
> >                                     dev-retn at openjdk.org <mailto:core-
> >                                     libs-dev-retn at openjdk.org>> on
> >                                     behalf of Jige Yu <yujige at gmail.com
> >                                     <mailto:yujige at gmail.com>>
> >                                     *Sent:* Friday, 3 January 2025 17:53
> >                                     *To:* core-libs-dev at openjdk.org
> >                                     <mailto:core-libs-
> >                                     dev at openjdk.org> <core-libs-
> >                                     dev at openjdk.org <mailto:core-libs-
> >                                     dev at openjdk.org>>
> >                                     *Subject:* mapConcurrent() with
> >                                     InterruptedException
> >                                     Hi Java Experts,
> >
> >                                     I sent this email incorrectly to
> >                                     loom-dev@ and was told on Reddit
> >                                     that core-libs-dev is the right list.
> >
> >                                     The question is about the behavior
> >                                     of mapConcurrent() when the thread
> >                                     is interrupted.
> >
> >                                     Currently mapConcurrent()'s finisher
> >                                     phase will re-interrupt the thread,
> >                                     then stop at whatever element that
> >                                     has already been processed and
> return.
> >
> >                                     This strikes me as a surprising
> >                                     behavior, because for example if I'm
> >                                     running:
> >
> >                                         Stream.of(1, 2, 3)
> >                                              .gather(mapConcurrent(i ->
> >                                     i * 2))
> >                                              .toList()
> >
> >                                     and the thread is being interrupted,
> >                                     the result could be any of [2], [2,
> >                                     4] or [2, 4, 6].
> >
> >                                     Since thread interruption is
> >                                     cooperative, there is no guarantee
> >                                     that the thread being interrupted
> >                                     will just abort. It's quite possible
> >                                     that it'll keep going and then will
> >                                     use for example [2] as the result of
> >                                     doubling the list of [1, 2, 3],
> >                                     which is imho incorrect.
> >
> >                                     In the Reddit <https://
> >                                     urldefense.com/v3/__https://
> >                                     www.reddit.com/r/java/
> >                                     comments/1hr8xyu/
> >
>  observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread,
> someone argued that interruption rarely happens so it's more of a
> theoretical issue. But interruption can easily happen in Structured
> Concurrency or in mapConcurrent() itself if any subtask has failed in order
> to cancel/interrupt the other ongoing tasks.
> >
> >                                     There had been discussion about
> >                                     alternative strategies:
> >
> >                                      1. Don't respond to interruption
> >                                         and just keep running to
> completion.
> >                                      2. Re-interrupt thread and wrap the
> >                                         InterruptedException in a
> >                                         standard unchecked exception
> >
>  (StructuredConcurrencyInterruptedException?).
> >
> >
> >                                     I have concerns with option 1
> >                                     because it disables cancellation
> >                                     propagation when mapConcurrent()
> >                                     itself is used in a subtask of a
> >                                     parent mapConcurrent() or in a
> >                                     StructuredConcurrencyScope.
> >
> >                                     Both equivalent Future-composition
> >                                     async code, or C++'s fiber trees
> >                                     support cancellation propagation and
> >                                     imho it's a critical feature or else
> >                                     it's possible that a zombie thread
> >                                     is still sending RPCs long after the
> >                                     main thread has exited (failed, or
> >                                     falled back to some default action).
> >
> >                                     My arguments for option 2:
> >
> >                                      1. InterruptedException is more
> >                                         error prone than traditional
> >                                         checked exceptions for
> >                                         *users* to catch and handle.
> >                                         They can forget to re-interrupt
> >                                         the thread. It's so confusing
> >                                         that even seasoned programmers
> >                                         may not know they are *supposed
> >                                         to* re-interrupt the thread.
> >                                      2. With Stream API using functional
> >                                         interfaces like Supplier,
> >                                         Function, the option of just
> >                                         tacking on "throws IE" isn't
> >                                         available to many users.
> >                                      3. With Virtual Threads, it will be
> >                                         more acceptable, or even become
> >                                         common to do blocking calls from
> >                                         a stream operation (including
> >                                         but exclusive to
> >                                         mapConcurrent()). So the chance
> >                                         users are forced to deal with IE
> >                                         will become substantially higher.
> >                                      4. Other APIs such as the
> >                                         Structured Concurrency API have
> >                                         already started wrapping system
> >                                         checked exceptions like
> >                                         ExecutionException,
> >                                         TimeoutException in unchecked
> >                                         exceptions ( join() <https://
> >                                         urldefense.com/v3/__https://
> >                                         download.java.net/java/
> >                                         early_access/loom/docs/api/
> >                                         java.base/java/util/concurrent/
> >
>  StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for
> example).
> >                                      5. Imho, exceptions that we'd
> >                                         rather users not catch and
> >                                         handle but instead should mostly
> >                                         just propagate up as is, should
> >                                         be unchecked.
> >
> >                                     There is also a side discussion
> >                                     <https://urldefense.com/v3/
> >                                     __https://www.reddit.com/r/java/
> >                                     comments/1hr8xyu/comment/m4z4f8c/?
> >
>  utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about
> whether mapConcurrent() is better off preserving input order or push to
> downstream as soon as an element is computed. I'd love to discuss that
> topic too but maybe it's better to start a separate thread?
> >
> >                                     Thank you and cheers!
> >
> >                                     Ben Yu
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250529/c7ddda87/attachment-0001.htm>

From naoto at openjdk.org  Thu May 29 22:49:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 May 2025 22:49:50 GMT
Subject: RFR: 8358095: Cleanup tests with explicit locale provider set to
 only CLDR
In-Reply-To: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
Message-ID: <H833y1iYUJmwjy2iCAya5NJ_PeA7HQ0AoWVjWCP8Qx0=.69d825a3-6926-458d-9c94-96291d8fa7d4@github.com>

On Thu, 29 May 2025 21:59:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which cleans up some i18n tests.
> 
> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
> 
> As this change is trivial cleanup, bug IDs are not updated in this change.

Probably we can remove `/othervm` from those `@run` directives?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25532#issuecomment-2920752452

From jlu at openjdk.org  Fri May 30 00:20:26 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 May 2025 00:20:26 GMT
Subject: RFR: 8358095: Cleanup tests with explicit locale provider set to
 only CLDR [v2]
In-Reply-To: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
Message-ID: <7iPhlactV6aDx8v6qI2AckiFZ-Iy2xae2_LkqUo_xWA=.b2d2c937-e78d-433e-99fb-c0c9817c47f9@github.com>

> Please review this PR which cleans up some i18n tests.
> 
> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
> 
> As this change is trivial cleanup, bug IDs are not updated in this change.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect review: strip othervm mode + cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25532/files
  - new: https://git.openjdk.org/jdk/pull/25532/files/23cb3a2d..2eb1edd5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25532&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25532&range=00-01

  Stats: 71 lines in 20 files changed: 0 ins; 51 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/25532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25532/head:pull/25532

PR: https://git.openjdk.org/jdk/pull/25532

From bpb at openjdk.org  Fri May 30 00:20:26 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 00:20:26 GMT
Subject: RFR: 8358095: Cleanup tests with explicit locale provider set to
 only CLDR [v2]
In-Reply-To: <7iPhlactV6aDx8v6qI2AckiFZ-Iy2xae2_LkqUo_xWA=.b2d2c937-e78d-433e-99fb-c0c9817c47f9@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
 <7iPhlactV6aDx8v6qI2AckiFZ-Iy2xae2_LkqUo_xWA=.b2d2c937-e78d-433e-99fb-c0c9817c47f9@github.com>
Message-ID: <pwtZUjrj85GoB0-hEeRdqMlqNnuupA8wklaq7GW3MWA=.c4884409-8cf2-405f-97df-131de7b8b317@github.com>

On Fri, 30 May 2025 00:17:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which cleans up some i18n tests.
>> 
>> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
>> 
>> As this change is trivial cleanup, bug IDs are not updated in this change.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review: strip othervm mode + cleanup

Cleanup looks good.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25532#pullrequestreview-2879883888

From jlu at openjdk.org  Fri May 30 00:20:27 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 May 2025 00:20:27 GMT
Subject: RFR: 8358095: Cleanup tests with explicit locale provider set to
 only CLDR
In-Reply-To: <H833y1iYUJmwjy2iCAya5NJ_PeA7HQ0AoWVjWCP8Qx0=.69d825a3-6926-458d-9c94-96291d8fa7d4@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
 <H833y1iYUJmwjy2iCAya5NJ_PeA7HQ0AoWVjWCP8Qx0=.69d825a3-6926-458d-9c94-96291d8fa7d4@github.com>
Message-ID: <uZE39hZcCwJPaopzUj6jTkVoYPnNdxLCo695xNUpYoQ=.d30f39cf-7eb9-479a-a9d5-81d3c824addc@github.com>

On Thu, 29 May 2025 22:47:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR which cleans up some i18n tests.
>> 
>> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
>> 
>> As this change is trivial cleanup, bug IDs are not updated in this change.
>
> Probably we can remove `/othervm` from those `@run` directives?

@naotoj Right, no more reason to run these tests in a separate JVM. Fixed in [2eb1edd](https://github.com/openjdk/jdk/pull/25532/commits/2eb1edd560b51d7fae92f5f859629d7fb5b5df23); that commit also includes some other minor cleanup.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25532#issuecomment-2920863235

From naoto at openjdk.org  Fri May 30 00:43:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 May 2025 00:43:52 GMT
Subject: RFR: 8358095: Cleanup tests with explicit locale provider set to
 only CLDR [v2]
In-Reply-To: <7iPhlactV6aDx8v6qI2AckiFZ-Iy2xae2_LkqUo_xWA=.b2d2c937-e78d-433e-99fb-c0c9817c47f9@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
 <7iPhlactV6aDx8v6qI2AckiFZ-Iy2xae2_LkqUo_xWA=.b2d2c937-e78d-433e-99fb-c0c9817c47f9@github.com>
Message-ID: <Sz9onzoO82lM0V_GtJlZX5J9301FawxSP_EzKg_MOTA=.d76c3339-c504-4c08-875a-7f55db86ff1c@github.com>

On Fri, 30 May 2025 00:20:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which cleans up some i18n tests.
>> 
>> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
>> 
>> As this change is trivial cleanup, bug IDs are not updated in this change.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review: strip othervm mode + cleanup

test/jdk/java/util/TimeZone/Bug8167143.java line 102:

> 100:             case "testCompat":
> 101:                 testImplicitCompatLocales();
> 102:                 break;

The method name is deceiving, but the test still has value because it tests the internal `FALLBACK` provider. In fact, functions for `BreakIterator` and `Collator` should be fully functional from that provider, as `CLDR` provider does not provide those. Maybe renaming `Compat` to `Fallback` would be appropriate.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25532#discussion_r2114948613

From liach at openjdk.org  Fri May 30 01:33:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 May 2025 01:33:59 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v11]
In-Reply-To: <qlYT62TEeCz9YVp02zeuJCO30kAZyzBgV2ENjURIJrw=.44ab01cb-9fe3-45a4-af51-6468a0f625ab@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
 <qlYT62TEeCz9YVp02zeuJCO30kAZyzBgV2ENjURIJrw=.44ab01cb-9fe3-45a4-af51-6468a0f625ab@github.com>
Message-ID: <80zHlzRZjXsszgvNxex1QXSfwByc8IrT_g7SSizKaqc=.e5d9de30-ab93-49dc-8e99-5b30406c4bfe@github.com>

On Wed, 28 May 2025 17:13:41 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Update test/jdk/java/util/Collection/MOAT.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Update copyright year
>    
>    and add the bug number to the modified test
>  - Update unmodifiable map javadoc
>  - Also throw UOE for mutators on keySet() and values()
>    
>    and add more test coverage to MOAT.
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/b2a61a99...785f728d

For some reason the lines you've added for UOE in MOAT are failing; can you check?

I have reviewed the CSR for you. Maybe us, Per Minborg, and Stuart Marks can work together to get the two significant collection changes into early 26 and broadcast on quality discuss list, as otherwise corpus analysis provides little useful information on the compatibility impact.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2920978415

From almatvee at openjdk.org  Fri May 30 01:45:41 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 30 May 2025 01:45:41 GMT
Subject: RFR: 8351369: [macos] Use --install-dir option with DMG packaging
 [v2]
In-Reply-To: <kzagV86LsE-55gtYItG-NVpkQwhj229GhyxEcnMS9ig=.7a5fbe15-004a-471d-a095-26c2b8147179@github.com>
References: <kzagV86LsE-55gtYItG-NVpkQwhj229GhyxEcnMS9ig=.7a5fbe15-004a-471d-a095-26c2b8147179@github.com>
Message-ID: <LfhHoqtdMGGawqRgtl5V8aaGqBJv61YmjG-gvY-7fhk=.05eb4c23-c885-424d-85d7-f393cab77391@github.com>

> - `--install-dir` option in DMG packaging is no longer ignored.
> - Defaults are still the same: `/Applications` and `/Library/Java/JavaVirtualMachines`.
> - It will be user responsibility to make sure installation directory exist on target machine, since DMG cannot create directories during drag and drop.
> - Target directory in case of non-default installation dir will display full path. See image below for example.
> 
> ![Screenshot 2025-05-28 at 12 07 53?AM](https://github.com/user-attachments/assets/fbcba07b-74a5-4276-90c3-5f8d2d0dcc16)

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8351369: [macos] Use --install-dir option with DMG packaging [v2]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25481/files
  - new: https://git.openjdk.org/jdk/pull/25481/files/e18deafc..437dcbd2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25481&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25481&range=00-01

  Stats: 166 lines in 6 files changed: 50 ins; 84 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/25481.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25481/head:pull/25481

PR: https://git.openjdk.org/jdk/pull/25481

From almatvee at openjdk.org  Fri May 30 01:45:41 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 30 May 2025 01:45:41 GMT
Subject: RFR: 8351369: [macos] Use --install-dir option with DMG packaging
In-Reply-To: <SpjCWvKNqLfabotb1qN2T9hOwdaxbfQazG9x8Bra4D8=.ba947686-0014-46a1-8cde-e0bdce718c91@github.com>
References: <kzagV86LsE-55gtYItG-NVpkQwhj229GhyxEcnMS9ig=.7a5fbe15-004a-471d-a095-26c2b8147179@github.com>
 <SpjCWvKNqLfabotb1qN2T9hOwdaxbfQazG9x8Bra4D8=.ba947686-0014-46a1-8cde-e0bdce718c91@github.com>
Message-ID: <W0d35wePTGIaAgHZXMrEkIJIMVEgEistvHI4JYdp40w=.11fd03b7-a6a2-4704-9ec1-1bc7d12e724f@github.com>

On Wed, 28 May 2025 23:01:30 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> If the installation directory doesn't exist, jpackage will try to create and delete it right after the DMG package is created.

> Is this absolutely necessary? Is there a better way?

Yes, there is better way. I just figure it out. AppleScript alias command cannot create links to non-existing locations, but shell `ln` command can create it. I updated script to use shell to create link. Most code I added is gone. Can you re-review it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25481#issuecomment-2920992419

From almatvee at openjdk.org  Fri May 30 01:45:41 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 30 May 2025 01:45:41 GMT
Subject: RFR: 8351369: [macos] Use --install-dir option with DMG packaging
In-Reply-To: <kzagV86LsE-55gtYItG-NVpkQwhj229GhyxEcnMS9ig=.7a5fbe15-004a-471d-a095-26c2b8147179@github.com>
References: <kzagV86LsE-55gtYItG-NVpkQwhj229GhyxEcnMS9ig=.7a5fbe15-004a-471d-a095-26c2b8147179@github.com>
Message-ID: <Dgx_b9v4eRvTifTtfyUaxbpC1TEmEjVQECj_wZ8osw0=.d1d635d7-e555-44a2-9710-8d2194237acd@github.com>

On Wed, 28 May 2025 07:11:36 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - `--install-dir` option in DMG packaging is no longer ignored.
> - Defaults are still the same: `/Applications` and `/Library/Java/JavaVirtualMachines`.
> - It will be user responsibility to make sure installation directory exist on target machine, since DMG cannot create directories during drag and drop.
> - Target directory in case of non-default installation dir will display full path. See image below for example.
> 
> ![Screenshot 2025-05-28 at 12 07 53?AM](https://github.com/user-attachments/assets/fbcba07b-74a5-4276-90c3-5f8d2d0dcc16)

8351369: [macos] Use --install-dir option with DMG packaging [v2]
 - Fixed is changed to use shell script to create links.
 - Previous fix is no longer relevant and was removed.
 - All code review comments before v2 is no longer relevant.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25481#issuecomment-2920995248

From duke at openjdk.org  Fri May 30 01:50:58 2025
From: duke at openjdk.org (duke)
Date: Fri, 30 May 2025 01:50:58 GMT
Subject: Withdrawn: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms
In-Reply-To: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
Message-ID: <JxsPCUykiMwkBi3N1rzhO6fwYHlHruF5zMX2fni3oow=.25de0784-0cf4-4d99-b280-9f81f18e30ef@github.com>

On Thu, 3 Apr 2025 18:47:43 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> 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.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24424

From asemenyuk at openjdk.org  Fri May 30 02:11:56 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 30 May 2025 02:11:56 GMT
Subject: RFR: 8351369: [macos] Use --install-dir option with DMG packaging
 [v2]
In-Reply-To: <LfhHoqtdMGGawqRgtl5V8aaGqBJv61YmjG-gvY-7fhk=.05eb4c23-c885-424d-85d7-f393cab77391@github.com>
References: <kzagV86LsE-55gtYItG-NVpkQwhj229GhyxEcnMS9ig=.7a5fbe15-004a-471d-a095-26c2b8147179@github.com>
 <LfhHoqtdMGGawqRgtl5V8aaGqBJv61YmjG-gvY-7fhk=.05eb4c23-c885-424d-85d7-f393cab77391@github.com>
Message-ID: <cRnRJUwLHkdOtb2c7zGQYFfGuPUOAUh2HF0OMhc3lsY=.a557a1e5-b35b-47cb-944b-fdcfef81f41c@github.com>

On Fri, 30 May 2025 01:45:41 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - `--install-dir` option in DMG packaging is no longer ignored.
>> - Defaults are still the same: `/Applications` and `/Library/Java/JavaVirtualMachines`.
>> - It will be user responsibility to make sure installation directory exist on target machine, since DMG cannot create directories during drag and drop.
>> - Target directory in case of non-default installation dir will display full path. See image below for example.
>> 
>> ![Screenshot 2025-05-28 at 12 07 53?AM](https://github.com/user-attachments/assets/fbcba07b-74a5-4276-90c3-5f8d2d0dcc16)
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8351369: [macos] Use --install-dir option with DMG packaging [v2]

Marked as reviewed by asemenyuk (Reviewer).

The fix looks neat and clean ?. Thank you!

-------------

PR Review: https://git.openjdk.org/jdk/pull/25481#pullrequestreview-2880017354
PR Comment: https://git.openjdk.org/jdk/pull/25481#issuecomment-2921035472

From cushon at openjdk.org  Fri May 30 02:26:28 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 30 May 2025 02:26:28 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v12]
In-Reply-To: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
Message-ID: <b7mZ75tXnVDfJAyGKQQyUwZF40WGoWVx1spoLdY1NV4=.6b031eea-2fc6-4040-a762-6823255d0823@github.com>

> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Update for Stable Values

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18522/files
  - new: https://git.openjdk.org/jdk/pull/18522/files/785f728d..264a7b08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=10-11

  Stats: 33 lines in 2 files changed: 32 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18522/head:pull/18522

PR: https://git.openjdk.org/jdk/pull/18522

From cushon at openjdk.org  Fri May 30 02:26:28 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 30 May 2025 02:26:28 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v11]
In-Reply-To: <80zHlzRZjXsszgvNxex1QXSfwByc8IrT_g7SSizKaqc=.e5d9de30-ab93-49dc-8e99-5b30406c4bfe@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
 <qlYT62TEeCz9YVp02zeuJCO30kAZyzBgV2ENjURIJrw=.44ab01cb-9fe3-45a4-af51-6468a0f625ab@github.com>
 <80zHlzRZjXsszgvNxex1QXSfwByc8IrT_g7SSizKaqc=.e5d9de30-ab93-49dc-8e99-5b30406c4bfe@github.com>
Message-ID: <e3MivsEbC85A8GS1zNhWyHAahMxdO_KKXjeSDJjGD10=.7e64e52f-b055-4783-aad2-c771ca6bfe5f@github.com>

On Fri, 30 May 2025 01:31:12 GMT, Chen Liang <liach at openjdk.org> wrote:

> For some reason the lines you've added for UOE in MOAT are failing; can you check?

This was due to the merge with https://github.com/openjdk/jdk/commit/fbc4691bfa11f31601fd89d05da63e689343e214, I resolved the conflict in the test but missed that the change adds a new `AbstractImmutableMap` implementation, and the `keySet` doesn't throw UOE on modifications. I have an initial changes that has MOAT passing again, but that part may require more thought.

> I have reviewed the CSR for you. Maybe us, Per Minborg, and Stuart Marks can work together to get the two significant collection changes into early 26 and broadcast on quality discuss list, as otherwise corpus analysis provides little useful information on the compatibility impact.

Thanks, that sounds great!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2921055604

From liach at openjdk.org  Fri May 30 02:36:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 May 2025 02:36:51 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications
In-Reply-To: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
Message-ID: <YvprZuG2_lOwGt6H-9pcOgg_SNHw85U6utbxqOAZSj8=.a072cd58-0b55-4742-a461-da6c7390476b@github.com>

On Thu, 29 May 2025 00:21:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> For a full explanation, see the bug report [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015).
> 
> This PR includes three related changes:
> * New overrides in SequencedMap view collection implementations, which improve their behavior.
> * Update to `@implSpec` clauses to reflect this behavior (which was previously ill-specified).
> * Update to a test which relied on unspecified behavior.

src/java.base/share/classes/java/util/AbstractMap.java line 881:

> 879:         UnsupportedOperationException uoe() { return new UnsupportedOperationException(); }
> 880:         // convert null entry return values into NSEE
> 881:         <T> T nsee(T entry) {

Suggestion:

        <T extends Map.Entry<?, ?>> T nsee(T entry) {

So we don't accidentally use this on map keys or values.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25515#discussion_r2115040750

From almatvee at openjdk.org  Fri May 30 03:09:57 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 30 May 2025 03:09:57 GMT
Subject: Integrated: 8351369: [macos] Use --install-dir option with DMG
 packaging
In-Reply-To: <kzagV86LsE-55gtYItG-NVpkQwhj229GhyxEcnMS9ig=.7a5fbe15-004a-471d-a095-26c2b8147179@github.com>
References: <kzagV86LsE-55gtYItG-NVpkQwhj229GhyxEcnMS9ig=.7a5fbe15-004a-471d-a095-26c2b8147179@github.com>
Message-ID: <fKY46sBD4LJ1r3Z0qxTQ2wk3zhxUAKoqOv_CxG5uxGg=.a72f9494-ed7b-4c65-b56a-ff8c69f52095@github.com>

On Wed, 28 May 2025 07:11:36 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - `--install-dir` option in DMG packaging is no longer ignored.
> - Defaults are still the same: `/Applications` and `/Library/Java/JavaVirtualMachines`.
> - It will be user responsibility to make sure installation directory exist on target machine, since DMG cannot create directories during drag and drop.
> - Target directory in case of non-default installation dir will display full path. See image below for example.
> 
> ![Screenshot 2025-05-28 at 12 07 53?AM](https://github.com/user-attachments/assets/fbcba07b-74a5-4276-90c3-5f8d2d0dcc16)

This pull request has now been integrated.

Changeset: fd51b039
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fd51b03910ba90ca1c46a4204b8940421338e22e
Stats:     57 lines in 5 files changed: 5 ins; 39 del; 13 mod

8351369: [macos] Use --install-dir option with DMG packaging

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/25481

From cushon at openjdk.org  Fri May 30 03:59:37 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 30 May 2025 03:59:37 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v13]
In-Reply-To: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
Message-ID: <ZAYVna3A7n3vOx2GOfXjWyk_eJjkWfRtDY6T6ZxYjdo=.410084d1-4f90-48e9-85a4-73eb5d1ed201@github.com>

> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Add an implementation comment to AbstractImmutableMap

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18522/files
  - new: https://git.openjdk.org/jdk/pull/18522/files/264a7b08..25a90c8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=11-12

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18522/head:pull/18522

PR: https://git.openjdk.org/jdk/pull/18522

From smarks at openjdk.org  Fri May 30 04:23:55 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 30 May 2025 04:23:55 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v11]
In-Reply-To: <e3MivsEbC85A8GS1zNhWyHAahMxdO_KKXjeSDJjGD10=.7e64e52f-b055-4783-aad2-c771ca6bfe5f@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
 <qlYT62TEeCz9YVp02zeuJCO30kAZyzBgV2ENjURIJrw=.44ab01cb-9fe3-45a4-af51-6468a0f625ab@github.com>
 <80zHlzRZjXsszgvNxex1QXSfwByc8IrT_g7SSizKaqc=.e5d9de30-ab93-49dc-8e99-5b30406c4bfe@github.com>
 <e3MivsEbC85A8GS1zNhWyHAahMxdO_KKXjeSDJjGD10=.7e64e52f-b055-4783-aad2-c771ca6bfe5f@github.com>
Message-ID: <-CogplhO9R_2nYsRRhV1mFWADNbMYZIV-21uyoK5oIk=.08d0dfe2-3334-4791-a601-1450170124d2@github.com>

On Fri, 30 May 2025 02:23:17 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> I have reviewed the CSR for you. Maybe us, Per Minborg, and Stuart Marks can work together to get the two significant collection changes into early 26 and broadcast on quality discuss list, as otherwise corpus analysis provides little useful information on the compatibility impact.

We haven't yet determined that corpus analysis has provided little useful information. Frankly, I think we've hardly tried. I've talked to @minborg about working with him on a compatibility analysis that will cover this PR as well as [JDK-8316493](https://bugs.openjdk.org/browse/JDK-8316493) (remove caching fields in AbstractMap).

After that, though, posting through various channels such as the Quality Outreach program will certainly be necessary.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2921186255

From liach at openjdk.org  Fri May 30 05:31:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 May 2025 05:31:50 GMT
Subject: RFR: 8357798: ReverseOrderListView uses Boolean boxes after
 JDK-8356080
In-Reply-To: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
Message-ID: <XTgJXJgOky-kOrkRguh4IbZ-HEsGVhsHcpJxeHJZHgo=.50afd8c3-dc71-4be5-a1db-47549b36c58a@github.com>

On Mon, 26 May 2025 17:08:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the existence of the boxed object to allow optional constant folding.
> 
> We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/util`

Indeed, I think we don't particularly need this stableness. For lack of `@Stable` on boolean: `java.lang` is a trusted package, so all final fields are considered constant foldable even if the value is the default value. If a field is `@Stable`, the stable mechanism takes over, and the stable mechanism refuses to trust zero bit pattern values.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2921273777

From jwaters at openjdk.org  Fri May 30 05:40:54 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 30 May 2025 05:40:54 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v4]
In-Reply-To: <CE7DC_l4IRgh8ia7JFugTpN7E55hce7YBJpxlVnOreE=.e35a487c-ddb8-4893-b80c-64aa7d25f455@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <72GCipLKeCWCG-4jsG5XhZKkTdVsWafEq_wA0oD-0mk=.c70af814-54fe-43d2-b7c9-72b845eb99d5@github.com>
 <cTPAVD5xnYDItBLloQQRf1T1dF6rc9LmMLlcSXXGfj4=.ad19da34-6dd1-4f38-91f1-3f7dacdb5e10@github.com>
 <CE7DC_l4IRgh8ia7JFugTpN7E55hce7YBJpxlVnOreE=.e35a487c-ddb8-4893-b80c-64aa7d25f455@github.com>
Message-ID: <g4W5HTytRF9PwMzzPsB5JugHocIUWpD80VK6XG5az7s=.0df493bd-13d9-497a-a23a-2c8dd80b05a6@github.com>

On Thu, 29 May 2025 18:52:51 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp line 49:
>> 
>>> 47: /******************************************************************************/
>>> 48: 
>>> 49: ATTRIBUTE_ALIGNED(4) static const juint _SIG_MASK[] =
>> 
>> ATTRIBUTE_ALIGNED expands to alignas, I suggest using that directly instead
>
> The ATTRIBUTE_ALIGNED macro is used in other stub generator files. Should all of those be changed to alignas as well? If so, would it best to make those changes in a separate PR?
> 
> Also, is the suggestion to change just for code readability?

There's no need to change the other files, that would be out of scope for this Pull Request. Yes, it's just a suggestion for readability, it can be ignored if you deem it as not necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2115174843

From xgong at openjdk.org  Fri May 30 08:17:53 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 30 May 2025 08:17:53 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API
In-Reply-To: <yYd0dXTCX-TXZpluDy9iktVQWeLifmY5GG_GNHkH9lU=.c414c05b-af7e-4b67-8f0f-9ba39696c82a@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <z9_9NOdQqxNvv_l0VxjGD4Xc-baboKUmbY5NGbXdAHw=.f8486a40-5d28-4f9c-913e-8155baadbec2@github.com>
 <t1DdwodJEC_7OWaci1nCnC6LZVV62x5flDo7rjzYcoM=.91f68c49-f044-43e3-8bba-67a2bd5a5800@github.com>
 <yYd0dXTCX-TXZpluDy9iktVQWeLifmY5GG_GNHkH9lU=.c414c05b-af7e-4b67-8f0f-9ba39696c82a@github.com>
Message-ID: <TPRwd9SD38ISkoXoJJRu0qMqx6_KU3USw1yPxpbUKVM=.f64594dd-b92b-4453-b7d2-f6b3ebb14a83@github.com>

On Tue, 20 May 2025 05:40:04 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > @XiaohongGong Thanks for splitting this one out, and for investigating the regressions here.
> > Putting the permalink here, fixed to the current change (the link you pasted will always refer to the newest, which may later on point to the wrong line when lines above are inserted / deleted):
> > https://github.com/openjdk/jdk/blob/7077535c0b0a6ea0a2a167f9135b1504a3d71fb3/src/hotspot/share/opto/loopnode.cpp#L1659-L1661
> > 
> > I wonder if we should just use `Node::uncast` there? But I'm quite unsure about that.
> 
> Sounds good to me. I will have a deep investigation for it. Thanks!

Hi @eme64  @jatin-bhateja,  I'v created a PR https://github.com/openjdk/jdk/pull/25539 to fix this issue. With this change, the performance regression can be fixed as well.  Could you please take a look at that change and help to run the test on different X86 machines?   Thanks a lot!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2921574716

From michaelm at openjdk.org  Fri May 30 09:01:39 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 09:01:39 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v14]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <pUfglxcMEvXttRaI8rASxa75JI0HVHTATct7tYPm-zI=.80721996-2a07-4ed0-861e-da5cf021bdff@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 incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/34f20c9a..cf5233c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=12-13

  Stats: 21 lines in 6 files changed: 0 ins; 0 del; 21 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 michaelm at openjdk.org  Fri May 30 09:01:39 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 09:01:39 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v13]
In-Reply-To: <uRKRZz5rqge9owi2Y3EaLR6u4mV47rzThn_BgcqY1p4=.d757cf7f-93cd-4c93-8066-963535c1c2d8@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <uRKRZz5rqge9owi2Y3EaLR6u4mV47rzThn_BgcqY1p4=.d757cf7f-93cd-4c93-8066-963535c1c2d8@github.com>
Message-ID: <F1Awcr4qDnApE7VJu2PJAqhh51UTiLTZYU_VIdEahDw=.c6d106ab-58cb-41c3-a8d8-01f50029f222@github.com>

On Thu, 29 May 2025 14:35:11 GMT, Michael McMahon <michaelm at openjdk.org> 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:
> 
>   Additional callsites identified by Mark S.

Thanks for the suggestions. I have committed all of them except for two. One, I will modify in another way.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2921687319

From michaelm at openjdk.org  Fri May 30 09:39:36 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 09:39:36 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v15]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <SWMHobTYknTDr0j80FUjeapmOd8elYQBX_qaguE0Q9c=.49d40218-e4f8-4514-a278-d41f253c428c@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 34 commits:

 - typo in suggestions and other issues
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - Additional callsites identified by Mark S.
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - update
 - reduced number of new categories
 - Merge branch 'master' into 8348986-exceptions
 - ... and 24 more: https://git.openjdk.org/jdk/compare/e33eeeea...462ee011

-------------

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=14
  Stats: 984 lines in 47 files changed: 711 ins; 101 del; 172 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 michaelm at openjdk.org  Fri May 30 10:32:57 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 10:32:57 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v15]
In-Reply-To: <SWMHobTYknTDr0j80FUjeapmOd8elYQBX_qaguE0Q9c=.49d40218-e4f8-4514-a278-d41f253c428c@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <SWMHobTYknTDr0j80FUjeapmOd8elYQBX_qaguE0Q9c=.49d40218-e4f8-4514-a278-d41f253c428c@github.com>
Message-ID: <P96m60ysmbCYcE3X7wab62zI3WsIiPGnaJtVxE-awLo=.59112bf2-ede7-428f-a407-b77b7101983e@github.com>

On Fri, 30 May 2025 09:39:36 GMT, Michael McMahon <michaelm at openjdk.org> 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 34 commits:
> 
>  - typo in suggestions and other issues
>  - Merge branch 'master' into 8348986-exceptions
>  - Apply suggestions from code review
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - Additional callsites identified by Mark S.
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - update
>  - reduced number of new categories
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/e33eeeea...462ee011

The last change to java.net.HostPortrange (renaming the constructor parameter) has caused a problem. The parameter is hiding a field of the same name. I need to fix that now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2921954327

From alanb at openjdk.org  Fri May 30 10:40:29 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 10:40:29 GMT
Subject: RFR: 8357637: Native resources cached in thread locals not released
 when FJP common pool threads clears thread locals
Message-ID: <VkaaMk0C7JSAVllqHevQxu7Fvf0QruJOJikxzgmERs0=.a80e982f-1de0-4b5d-a7ee-adbb40b94aa8@github.com>

A ForkJoinPool can be created with worker threads that clear thread locals between tasks, thus avoiding a build up of thread locals left behind by tasks executed in the pool. The common pool does this. Erasing thread locals (by writing null to Thread.threadLocals) grinds with thread locals that keep native memory alive, esp. when there isn't a Cleaner or other means to free the memory.

For the JDK, this is currently an issue for the NIO direct buffer cache. If a task running on a thread in the common pool does socket or network channel I/O then it can leak when the task terminates. Prior to JDK 24 each buffer in the cache had a cleaner, as if allocated by ByteBuffer.allocateDirect, so it had some chance of being released. The changes in [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882) mean there is no longer is cleaner for buffers in the cache.

The options in the short term are to restore the cleaner, register a clearer for the buffer cache, have the FJP resetThreadLocals special case "terminating thread locals", or move the terminating thread locals to a different TL map. Viktor Klang, Doug Lea, and I discussed this topic recently and agreed the best short term approach is to split the map. As terminating thread locals are for platform threads then the map can be in the Thread.FieldHolder and avoid adding another field to Thread. Medium to long term require further thought in this area, including seeing what might be useful (and safe) to expose.

Testing 1-5. Performance testing ongoing.

-------------

Commit messages:
 - Remove stray file
 - Update
 - Merge branch 'master' into JDK-8357637
 - Merge branch 'master' into JDK-8357637
 - Merge branch 'master' into JDK-8357637
 - Cleanup/review feedback
 - Merge branch 'master' into JDK-8357637
 - Merge branch 'master' into JDK-8357637
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/25457/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25457&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357637
  Stats: 149 lines in 9 files changed: 89 ins; 37 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/25457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25457/head:pull/25457

PR: https://git.openjdk.org/jdk/pull/25457

From vklang at openjdk.org  Fri May 30 10:40:30 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 30 May 2025 10:40:30 GMT
Subject: RFR: 8357637: Native resources cached in thread locals not
 released when FJP common pool threads clears thread locals
In-Reply-To: <VkaaMk0C7JSAVllqHevQxu7Fvf0QruJOJikxzgmERs0=.a80e982f-1de0-4b5d-a7ee-adbb40b94aa8@github.com>
References: <VkaaMk0C7JSAVllqHevQxu7Fvf0QruJOJikxzgmERs0=.a80e982f-1de0-4b5d-a7ee-adbb40b94aa8@github.com>
Message-ID: <tNCAImpW0_h1IWxdxC7HBUfpzDvIKuU0Z_nkGMnVjoo=.499ef476-fa35-4c16-8dfa-e919f92c77ad@github.com>

On Mon, 26 May 2025 17:16:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A ForkJoinPool can be created with worker threads that clear thread locals between tasks, thus avoiding a build up of thread locals left behind by tasks executed in the pool. The common pool does this. Erasing thread locals (by writing null to Thread.threadLocals) grinds with thread locals that keep native memory alive, esp. when there isn't a Cleaner or other means to free the memory.
> 
> For the JDK, this is currently an issue for the NIO direct buffer cache. If a task running on a thread in the common pool does socket or network channel I/O then it can leak when the task terminates. Prior to JDK 24 each buffer in the cache had a cleaner, as if allocated by ByteBuffer.allocateDirect, so it had some chance of being released. The changes in [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882) mean there is no longer is cleaner for buffers in the cache.
> 
> The options in the short term are to restore the cleaner, register a clearer for the buffer cache, have the FJP resetThreadLocals special case "terminating thread locals", or move the terminating thread locals to a different TL map. Viktor Klang, Doug Lea, and I discussed this topic recently and agreed the best short term approach is to split the map. As terminating thread locals are for platform threads then the map can be in the Thread.FieldHolder and avoid adding another field to Thread. Medium to long term require further thought in this area, including seeing what might be useful (and safe) to expose.
> 
> Testing 1-5. Performance testing ongoing.

@AlanBateman I think this approach is a good step in the right direction here.

src/java.base/share/classes/java/lang/InheritableThreadLocal.java line 95:

> 93:     void createMap(Thread t, T firstValue) {
> 94:         var map = new ThreadLocalMap(this, firstValue);
> 95:         t.setInheritableThreadLocals(map);

Stylistic suggestion:

Suggestion:

        t.setInheritableThreadLocals(new ThreadLocalMap(this, firstValue));

src/java.base/share/classes/java/lang/Thread.java line 246:

> 244:         volatile boolean daemon;
> 245:         volatile int threadStatus;
> 246:         ThreadLocal.ThreadLocalMap terminatingThreadLocals;

I think it's worth documenting the memory safety aspects of this field.

src/java.base/share/classes/java/lang/ThreadLocal.java line 284:

> 282:      */
> 283:     ThreadLocalMap getMap(Thread t) {
> 284:         if (this instanceof TerminatingThreadLocal<T>) {

Would it make sense to override `getMap` in TerminatingThreadLocal instead?

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 549:

> 547:     void removeCarrierThreadLocal(CarrierThreadLocal<?> local);
> 548: 
> 549:     /**

Copyright update?

src/java.base/share/classes/jdk/internal/misc/TerminatingThreadLocal.java line 82:

> 80:      */
> 81:     public static void register(TerminatingThreadLocal<?> tl) {
> 82:         if (tl != REGISTRY) {

Would this happen in any well-behaved application? If not, might be better to throw an exception? ?

src/java.base/share/classes/jdk/internal/misc/TerminatingThreadLocal.java line 96:

> 94: 
> 95:     /**
> 96:      * A per-terminating-thread registry of TerminatingThreadLocal(s) that have been

Perhaps "A per-platform-thread registry ..."?

src/java.base/share/classes/sun/nio/ch/IOVecWrapper.java line 83:

> 81:             if (wrapper != null) {
> 82:                 wrapper.vecArray.free();
> 83:                 cache[0] = null;

Perhaps null it out before calling free()? (in case free() fails)

test/jdk/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java line 194:

> 192:                 assertNull(tl.get());
> 193:                 assertEquals(ttl.get(), ttlValue);
> 194:             } catch (Exception ex) {

Perhaps safer with catching Throwable?if there are any Errors thrown.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25457#issuecomment-2916569305
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2112057817
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2109017596
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2109025118
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2112062254
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2115588231
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2109416867
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2109418667
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2112066646

From duke at openjdk.org  Fri May 30 10:40:30 2025
From: duke at openjdk.org (ExE Boss)
Date: Fri, 30 May 2025 10:40:30 GMT
Subject: RFR: 8357637: Native resources cached in thread locals not
 released when FJP common pool threads clears thread locals
In-Reply-To: <tNCAImpW0_h1IWxdxC7HBUfpzDvIKuU0Z_nkGMnVjoo=.499ef476-fa35-4c16-8dfa-e919f92c77ad@github.com>
References: <VkaaMk0C7JSAVllqHevQxu7Fvf0QruJOJikxzgmERs0=.a80e982f-1de0-4b5d-a7ee-adbb40b94aa8@github.com>
 <tNCAImpW0_h1IWxdxC7HBUfpzDvIKuU0Z_nkGMnVjoo=.499ef476-fa35-4c16-8dfa-e919f92c77ad@github.com>
Message-ID: <mi0YBAgBfJm2l9n9F7MIELh-MB581NbmvNEb3huLDiw=.4e441e92-e374-48f4-961f-687f89862bdb@github.com>

On Tue, 27 May 2025 12:14:16 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> A ForkJoinPool can be created with worker threads that clear thread locals between tasks, thus avoiding a build up of thread locals left behind by tasks executed in the pool. The common pool does this. Erasing thread locals (by writing null to Thread.threadLocals) grinds with thread locals that keep native memory alive, esp. when there isn't a Cleaner or other means to free the memory.
>> 
>> For the JDK, this is currently an issue for the NIO direct buffer cache. If a task running on a thread in the common pool does socket or network channel I/O then it can leak when the task terminates. Prior to JDK 24 each buffer in the cache had a cleaner, as if allocated by ByteBuffer.allocateDirect, so it had some chance of being released. The changes in [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882) mean there is no longer is cleaner for buffers in the cache.
>> 
>> The options in the short term are to restore the cleaner, register a clearer for the buffer cache, have the FJP resetThreadLocals special case "terminating thread locals", or move the terminating thread locals to a different TL map. Viktor Klang, Doug Lea, and I discussed this topic recently and agreed the best short term approach is to split the map. As terminating thread locals are for platform threads then the map can be in the Thread.FieldHolder and avoid adding another field to Thread. Medium to long term require further thought in this area, including seeing what might be useful (and safe) to expose.
>> 
>> Testing 1-5. Performance testing ongoing.
>
> src/java.base/share/classes/java/lang/ThreadLocal.java line 284:
> 
>> 282:      */
>> 283:     ThreadLocalMap getMap(Thread t) {
>> 284:         if (this instanceof TerminatingThreadLocal<T>) {
> 
> Would it make sense to override `getMap` in TerminatingThreadLocal instead?

`TerminatingThreadLocal` is?located in?the?`jdk.internal.misc` package, so?that?s?not a?possibility without?introducing `module?protected` visibility, which?was?decided against?during?development of?**Project?Jigsaw**, as?it?would further?complicate the?already?complex method?resolution?rules.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2111405993

From alanb at openjdk.org  Fri May 30 10:40:30 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 10:40:30 GMT
Subject: RFR: 8357637: Native resources cached in thread locals not
 released when FJP common pool threads clears thread locals
In-Reply-To: <tNCAImpW0_h1IWxdxC7HBUfpzDvIKuU0Z_nkGMnVjoo=.499ef476-fa35-4c16-8dfa-e919f92c77ad@github.com>
References: <VkaaMk0C7JSAVllqHevQxu7Fvf0QruJOJikxzgmERs0=.a80e982f-1de0-4b5d-a7ee-adbb40b94aa8@github.com>
 <tNCAImpW0_h1IWxdxC7HBUfpzDvIKuU0Z_nkGMnVjoo=.499ef476-fa35-4c16-8dfa-e919f92c77ad@github.com>
Message-ID: <eGWAkRadz0DR9o6R7Ag0kZOwkFDqh3WHIAL2S4oWsqs=.c27884bd-398d-4ff5-974f-0ae7247d5b97@github.com>

On Wed, 28 May 2025 14:27:40 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> A ForkJoinPool can be created with worker threads that clear thread locals between tasks, thus avoiding a build up of thread locals left behind by tasks executed in the pool. The common pool does this. Erasing thread locals (by writing null to Thread.threadLocals) grinds with thread locals that keep native memory alive, esp. when there isn't a Cleaner or other means to free the memory.
>> 
>> For the JDK, this is currently an issue for the NIO direct buffer cache. If a task running on a thread in the common pool does socket or network channel I/O then it can leak when the task terminates. Prior to JDK 24 each buffer in the cache had a cleaner, as if allocated by ByteBuffer.allocateDirect, so it had some chance of being released. The changes in [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882) mean there is no longer is cleaner for buffers in the cache.
>> 
>> The options in the short term are to restore the cleaner, register a clearer for the buffer cache, have the FJP resetThreadLocals special case "terminating thread locals", or move the terminating thread locals to a different TL map. Viktor Klang, Doug Lea, and I discussed this topic recently and agreed the best short term approach is to split the map. As terminating thread locals are for platform threads then the map can be in the Thread.FieldHolder and avoid adding another field to Thread. Medium to long term require further thought in this area, including seeing what might be useful (and safe) to expose.
>> 
>> Testing 1-5. Performance testing ongoing.
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 549:
> 
>> 547:     void removeCarrierThreadLocal(CarrierThreadLocal<?> local);
>> 548: 
>> 549:     /**
> 
> Copyright update?

It's already up to date so no change.

> src/java.base/share/classes/jdk/internal/misc/TerminatingThreadLocal.java line 82:
> 
>> 80:      */
>> 81:     public static void register(TerminatingThreadLocal<?> tl) {
>> 82:         if (tl != REGISTRY) {
> 
> Would this happen in any well-behaved application? If not, might be better to throw an exception? ?

It's just a consequence of the registry being a ttl, we either check it here or in set, it's more local here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2115634840
PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2115633931

From alanb at openjdk.org  Fri May 30 10:43:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 10:43:55 GMT
Subject: RFR: 8357637: Native resources cached in thread locals not
 released when FJP common pool threads clears thread locals
In-Reply-To: <tNCAImpW0_h1IWxdxC7HBUfpzDvIKuU0Z_nkGMnVjoo=.499ef476-fa35-4c16-8dfa-e919f92c77ad@github.com>
References: <VkaaMk0C7JSAVllqHevQxu7Fvf0QruJOJikxzgmERs0=.a80e982f-1de0-4b5d-a7ee-adbb40b94aa8@github.com>
 <tNCAImpW0_h1IWxdxC7HBUfpzDvIKuU0Z_nkGMnVjoo=.499ef476-fa35-4c16-8dfa-e919f92c77ad@github.com>
Message-ID: <zEZKNgcV_d4Y6CIwuKKdHMZXBhxOK5Zvr5JXPqSTfx8=.dd00e0ae-858c-4b48-8d5a-f2db1c1c45f1@github.com>

On Tue, 27 May 2025 12:10:19 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> A ForkJoinPool can be created with worker threads that clear thread locals between tasks, thus avoiding a build up of thread locals left behind by tasks executed in the pool. The common pool does this. Erasing thread locals (by writing null to Thread.threadLocals) grinds with thread locals that keep native memory alive, esp. when there isn't a Cleaner or other means to free the memory.
>> 
>> For the JDK, this is currently an issue for the NIO direct buffer cache. If a task running on a thread in the common pool does socket or network channel I/O then it can leak when the task terminates. Prior to JDK 24 each buffer in the cache had a cleaner, as if allocated by ByteBuffer.allocateDirect, so it had some chance of being released. The changes in [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882) mean there is no longer is cleaner for buffers in the cache.
>> 
>> The options in the short term are to restore the cleaner, register a clearer for the buffer cache, have the FJP resetThreadLocals special case "terminating thread locals", or move the terminating thread locals to a different TL map. Viktor Klang, Doug Lea, and I discussed this topic recently and agreed the best short term approach is to split the map. As terminating thread locals are for platform threads then the map can be in the Thread.FieldHolder and avoid adding another field to Thread. Medium to long term require further thought in this area, including seeing what might be useful (and safe) to expose.
>> 
>> Testing 1-5. Performance testing ongoing.
>
> src/java.base/share/classes/java/lang/Thread.java line 246:
> 
>> 244:         volatile boolean daemon;
>> 245:         volatile int threadStatus;
>> 246:         ThreadLocal.ThreadLocalMap terminatingThreadLocals;
> 
> I think it's worth documenting the memory safety aspects of this field.

Comment added to make it clear that it is maintained by the TL class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2115642472

From michaelm at openjdk.org  Fri May 30 10:44:11 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 10:44:11 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v16]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <BvjJ2qOTgXQznUOi2ImMfEkHRcEoN6OXFNen4g9A23s=.c3c6599f-407f-40d6-9055-c09555064b0f@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 incrementally with one additional commit since the last revision:

  Fixed problem with j.n.HostPortRange

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/462ee011..3eec6c03

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=14-15

  Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 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  Fri May 30 10:47:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 10:47:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v16]
In-Reply-To: <BvjJ2qOTgXQznUOi2ImMfEkHRcEoN6OXFNen4g9A23s=.c3c6599f-407f-40d6-9055-c09555064b0f@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <BvjJ2qOTgXQznUOi2ImMfEkHRcEoN6OXFNen4g9A23s=.c3c6599f-407f-40d6-9055-c09555064b0f@github.com>
Message-ID: <VYoQ0Q223Fc-URXr9oD7NgN5L8Sg9b0o7uUnS5OD3X4=.bc219762-0d1c-4df3-9c8b-d27c7f854aee@github.com>

On Fri, 30 May 2025 10:44:11 GMT, Michael McMahon <michaelm at openjdk.org> 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:
> 
>   Fixed problem with j.n.HostPortRange

src/java.base/share/classes/sun/net/www/protocol/jmod/Handler.java line 50:

> 48:         if (index == -1)
> 49:             throw new MalformedURLException(
> 50:                 formatMsg("no !/ found in url spec%s", filterJarName(s).prefixWith(": ")));

JMOD files can only be used at compile time and link time. So I think you can drop the changes jmod stream handler.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2115650070

From duke at openjdk.org  Fri May 30 10:48:20 2025
From: duke at openjdk.org (kieran-farrell)
Date: Fri, 30 May 2025 10:48:20 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v4]
In-Reply-To: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
Message-ID: <1gOicbq5qevD2Tk0pCRhf5PbNt7hr8qoN7y3j2S-Tgk=.df896664-eae3-4f15-8a7c-d0ce48ea2404@github.com>

> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
> 
> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
> 
> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
> 
> 
> - random-byte-only - 99.8%
> - higher-precision - 3.5%
> - counter-based - 0%
> 
> 
> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
> 
> - random-byte-only   143.487 ? 10.932  ns/op
> - higher-precision      149.651 ?  8.438 ns/op
> - counter-based         245.036 ?  2.943  ns/op
> 
> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.

kieran-farrell has updated the pull request incrementally with four additional commits since the last revision:

 - update test
 - update test
 - updates
 - update method to lsb and msb with arraybytes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25303/files
  - new: https://git.openjdk.org/jdk/pull/25303/files/c7efd528..33d8ccbf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=02-03

  Stats: 80 lines in 2 files changed: 51 ins; 4 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/25303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303

PR: https://git.openjdk.org/jdk/pull/25303

From duke at openjdk.org  Fri May 30 11:07:53 2025
From: duke at openjdk.org (kieran-farrell)
Date: Fri, 30 May 2025 11:07:53 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v4]
In-Reply-To: <MptKp5DYOARdsRle8U6QpR4Hvd5aS6fGhRbDoi_1h5s=.d06f5ed7-ebcd-47af-a7f8-82fdaaee0a12@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <Jm4ATGoFWP2a8HSBuwAglmdQS5fcBKBxt7TOklUQRjk=.b47ef4c7-26cd-4603-a074-76be89fa898c@github.com>
 <D2OwQlifY_F57s5ntpnVSYAMxZ8lacAyv03fME6O3ZM=.524387cc-ad76-4261-9269-8e2f08aeb6fb@github.com>
 <my9K8CLlrz0magIzlGgxShOw4oG1D7khLcG0KB2C3aU=.50c780c7-2f35-425b-aa19-00905143e208@github.com>
 <lzUXzFFqnkDwu6nx8GudrrkgihJ9bYECt0gqbWSPOgg=.7f6488d7-5c7e-423a-879a-3f125245440c@github.com>
 <x-kg_zhXOYwXjNAnWysWQtxPWl8a2c-sOZQbhzyYBss=.3616b256-3dfe-40e1-ab16-a96cc5420069@github.com>
 <aUqL8I-iZmufLfNiILoCu114WyvAoMGFlyWx2ffORds=.dabc7a33-80ab-45b8-a4e3-664303aaa120@github.com>
 <nFrlWMsRo9X2bGxY2a-HpLe_JL-rKshIhR7C9MS71rM=.1f10fd62-3442-43e0-9b2e-e5a723a5be30@github.com>
 <MptKp5DYOARdsRle8U6QpR4Hvd5aS6fGhRbDoi_1h5s=.d06f5ed7-ebcd-47af-a7f8-82fdaaee0a12@github.com>
Message-ID: <PBKHTv9QrR2AYK9G48k7hBnPUNlOnD6ItKr4I7rssdY=.ce3d3973-56a1-4c75-917e-edabf7df38ee@github.com>

On Thu, 29 May 2025 18:30:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> In terms of using another clock it could open up possiblities of passing non complaint time formats to the method, but maybe thats something that could be mostly prevented with input validation and clear documentation i.e. ?timestamp must be Unix time in milliseconds.? As far as I know all other standard Java methods that gives the current time in milliseconds ultimately delegates to System.currentTimeMillis(). 
>> 
>> Maybe there would be a use case in generating UUIDs by passing compliant timestamps for entries created in the past, like updating a database to use UUIDv7?
>
> RFC 9562 does not indicate any relation between the timestamp value and the "current" time.
> So yes, document it as the Unix Epoch, milliseconds since 1970. 
> There could be plenty of use cases for creating a UUID from some other source of time, like the timestamp of a file or a time field in a database.

Latest update:

- changed to millis + randomByte allocation implementation
- updated method to take user provided timestamp
- added API which delegates to method with current timestamp if no user input provided
- validated user input (this is far from fool proof, but prevents negative time values and some other time formats)
- updated method name to unixEpochTimeMillis
- added a note with ref to rfc to make user aware of time format required for rfc compliance
- added test coverage

Updated benchmark:


Benchmark                          Mode  Cnt    Score    Error  Units
UUIDBenchmark.unixEpochTimeMillis  avgt   25  138.076 ? 11.438  ns/op

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2115691663

From vyazici at openjdk.org  Fri May 30 11:12:15 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 30 May 2025 11:12:15 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
Message-ID: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>

Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.

`stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

-------------

Commit messages:
 - Revert more superfluous changes
 - Fix code typo
 - Discard changes unrelated with core libraries
 - Revert superfluous changes
 - Revert changes to 3rd parties in `com/sun/org/apache`
 - Revert `PandocFilter` changes
 - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations

Changes: https://git.openjdk.org/jdk/pull/25544/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25544&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357995
  Stats: 65 lines in 15 files changed: 16 ins; 7 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/25544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25544/head:pull/25544

PR: https://git.openjdk.org/jdk/pull/25544

From kbarrett at openjdk.org  Fri May 30 11:27:51 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 30 May 2025 11:27:51 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v6]
In-Reply-To: <ZS11BbUZhXvjekz9J6Nx0YdmsRy4vi8Xc4LUc-60I_w=.d0f276f4-f023-4414-9fc2-8000ffa4e0c1@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com>
 <ymq-cS14PaC1PpdKAzAZJwxdwtVTbSZtT-LNC21lW6Q=.f956592a-fd59-4bb5-a485-f4138942d290@github.com>
 <lnDH0vCQvoIGjjsjeO7ukv8gpTfp1vWR8hOX-CXlFjA=.a859787f-bc16-40c2-9f9d-ae879e68dc25@github.com>
 <rHMm6DwsyFJIOTQRKO17T0VyOvaxUwxVpwWKw4mpIj8=.d2633532-bc82-4505-a14b-45b46798d4ff@github.com>
 <cskdHy0_3zFOp7bAI-zz6V-avY2vPIcnwIseaE0NrS8=.3c147c4d-78e9-4499-88d3-73fbb40560ab@github.com>
 <wQkKLSTJsvldZxWleQpPTv_9N1ugC067-gv5LUVTdPI=.8917db0c-0653-48f5-acc2-e040a61f650a@github.com>
 <DOmW1DiflE8ovJmLEHeU8S8laqzbcy1gjqfRsJaMyUU=.8bca0d18-8ffa-402d-af96-66236f6b84c2@github.com>
 <_99Geoayi09Ey7YT7qWw4pjMqbVUNxfKpFBwwI_EbHg=.e81158ae-813c-4015-94d6-4404eb756394@github.com>
 <ZS11BbUZhXvjekz9J6Nx0YdmsRy4vi8Xc4LUc-60I_w=.d0f276f4-f023-4414-9fc2-8000ffa4e0c1@github.com>
Message-ID: <wIIM4tKR9hV6IpgsQN6YWxG8DTw8Ua-vl5fAYDpKsw8=.38c3e194-dc26-44bc-bf56-29957fe2361f@github.com>

On Thu, 29 May 2025 18:45:20 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Yes, I find it much cleaner when intrinsic is non-virtual.
>> 
>>> Or maybe that's better done as a later cleanup?
>> 
>> Up to you. I'm fine with the current PR if you remove the comment referring to C2.
>
> FTR the special case in `compile.cpp` you referred to is not used right now because there are no stand-alone compilations of `Reference::get` happening (I believe because it is also intrinsified in interpreter).

Much of the point of this change is to let us later remove the interpreter/c1
intrinsics for this function. I think what you are saying is that might be
tricky if `get()` is the intrinsic. So maybe I should just go ahead now with
making the native `get0()` be the intrinsic. I'll take a look at it and see
how widespread the renaming changes are.

If `get0()` is the intrinsic, then I think that referenced snippet from the
Compile ctor can go away? Rather than being changed to refer to the get0
intrinsic.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2115737025

From vyazici at openjdk.org  Fri May 30 12:02:37 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 30 May 2025 12:02:37 GMT
Subject: RFR: 8357821: Revert incorrectly named JavaLangAccess::unchecked*
 methods
Message-ID: <tDzMTU2VeD_fIb5s8gweKAF1fnz5p6y7kWgGkWcpMAY=.749b0bce-e6e0-490f-a6eb-f584c3f7166f@github.com>

Reverts certain [JDK-8353197](https://bugs.openjdk.org/browse/JDK-8353197) (which implements JavaDoc improvement and precautionary naming for certain unsafe methods in `jdk.internal.access.JavaLangAccess`) changes that are found to be incorrect. See the JBS issue for details on the followed evaluation process.

-------------

Commit messages:
 - Revert incorrect JLA renamings

Changes: https://git.openjdk.org/jdk/pull/25545/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25545&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357821
  Stats: 25 lines in 12 files changed: 0 ins; 6 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/25545.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25545/head:pull/25545

PR: https://git.openjdk.org/jdk/pull/25545

From vklang at openjdk.org  Fri May 30 12:20:26 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 30 May 2025 12:20:26 GMT
Subject: RFR: 8358151 : Harden JSR166 Test case testShutdownNow_delayedTasks
Message-ID: <FBGiqy8ENgXWOL9R7S_2eGFH_gCXHhnnBpm_4uN1TlA=.d43496b9-7f1d-4d0a-a8f0-2dd826874f41@github.com>

Bumping the (synthetic) delays to 100 seconds to ensure that they don't run prior to shutdown being finished.

-------------

Commit messages:
 - Harmonizing delay for *_delayedTasks() to 100 seconds to avoid spurious failures

Changes: https://git.openjdk.org/jdk/pull/25548/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25548&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358151
  Stats: 10 lines in 2 files changed: 4 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25548.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25548/head:pull/25548

PR: https://git.openjdk.org/jdk/pull/25548

From vklang at openjdk.org  Fri May 30 12:29:53 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 30 May 2025 12:29:53 GMT
Subject: RFR: 8357637: Native resources cached in thread locals not
 released when FJP common pool threads clears thread locals
In-Reply-To: <VkaaMk0C7JSAVllqHevQxu7Fvf0QruJOJikxzgmERs0=.a80e982f-1de0-4b5d-a7ee-adbb40b94aa8@github.com>
References: <VkaaMk0C7JSAVllqHevQxu7Fvf0QruJOJikxzgmERs0=.a80e982f-1de0-4b5d-a7ee-adbb40b94aa8@github.com>
Message-ID: <-jJFOjTCpG8BFv11gZ8M63PhLH4izukA5Hx2EfaCdxo=.612568ac-26fc-4a2d-b07a-e2c502cdd7c2@github.com>

On Mon, 26 May 2025 17:16:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A ForkJoinPool can be created with worker threads that clear thread locals between tasks, thus avoiding a build up of thread locals left behind by tasks executed in the pool. The common pool does this. Erasing thread locals (by writing null to Thread.threadLocals) grinds with thread locals that keep native memory alive, esp. when there isn't a Cleaner or other means to free the memory.
> 
> For the JDK, this is currently an issue for the NIO direct buffer cache. If a task running on a thread in the common pool does socket or network channel I/O then it can leak when the task terminates. Prior to JDK 24 each buffer in the cache had a cleaner, as if allocated by ByteBuffer.allocateDirect, so it had some chance of being released. The changes in [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882) mean there is no longer is cleaner for buffers in the cache.
> 
> The options in the short term are to restore the cleaner, register a clearer for the buffer cache, have the FJP resetThreadLocals special case "terminating thread locals", or move the terminating thread locals to a different TL map. Viktor Klang, Doug Lea, and I discussed this topic recently and agreed the best short term approach is to split the map. As terminating thread locals are for platform threads then the map can be in the Thread.FieldHolder and avoid adding another field to Thread. Medium to long term require further thought in this area, including seeing what might be useful (and safe) to expose.
> 
> Testing 1-5. Performance testing ongoing.

Great work on this one, Alan.

I presume this has gone through the needed tiers for testing?

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25457#pullrequestreview-2881204899

From alanb at openjdk.org  Fri May 30 13:30:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 13:30:55 GMT
Subject: RFR: 8354450: A File should be invalid if an element of its name
 sequence ends with a space [v4]
In-Reply-To: <49Yvff-cNfqJxpzHD6NThf3zH46MivdDcKn0axoNEjc=.e5971545-10dc-4d56-b006-8e0409a179bc@github.com>
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
 <49Yvff-cNfqJxpzHD6NThf3zH46MivdDcKn0axoNEjc=.e5971545-10dc-4d56-b006-8e0409a179bc@github.com>
Message-ID: <dTTkjNs6iy8b7LtwxDY_9_fjmK7dXfo3W0Me56K0EpY=.0db10e0b-7f10-4937-bba2-2ce346f2037c@github.com>

On Wed, 23 Apr 2025 21:50:46 GMT, Brian Burkhalter <bpb at openjdk.org> 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: Simplify test for " \" in path elements

I think this one is okay. We will need a release note to document the behavior change.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24635#pullrequestreview-2881369907

From mullan at openjdk.org  Fri May 30 13:34:58 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 30 May 2025 13:34:58 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v16]
In-Reply-To: <BvjJ2qOTgXQznUOi2ImMfEkHRcEoN6OXFNen4g9A23s=.c3c6599f-407f-40d6-9055-c09555064b0f@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <BvjJ2qOTgXQznUOi2ImMfEkHRcEoN6OXFNen4g9A23s=.c3c6599f-407f-40d6-9055-c09555064b0f@github.com>
Message-ID: <QgV6ixHQPTp0NebQMaKsAl0XczpOvWTO8pRTt-ANCXQ=.d0742c1d-7830-4237-aa29-0c4ac56613d3@github.com>

On Fri, 30 May 2025 10:44:11 GMT, Michael McMahon <michaelm at openjdk.org> 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:
> 
>   Fixed problem with j.n.HostPortRange

src/java.base/share/conf/security/java.security line 1282:

> 1280: # Exception messages may include potentially sensitive information such as file
> 1281: # names, host names, or port numbers. By default, socket related exceptions
> 1282: # have this information restricted (meaning the sensitive details are removed).

I found the "By default ..." sentence a little confusing, since other categories are also restricted by default. My initial thought is to just remove this sentence, as reading further will make it more clear that the hostInfoExclSocket category is the only one that is not restricted by default. Alternatively, you could flip the meaning of this sentence and say which exceptions are **not** restricted by default.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2115938656

From stuefe at openjdk.org  Fri May 30 13:42:58 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 30 May 2025 13:42:58 GMT
Subject: RFR: 8357683: (process) SIGQUIT still blocked after JDK-8234262
 with jdk.lang.Process.launchMechanism=FORK or VFORK [v2]
In-Reply-To: <-MgHTaqd3dqLKT6g0aNqTlcoG26drN5YYnmSURxZ5vY=.f574869b-a0fe-4298-9d31-d337384be191@github.com>
References: <4lcOGDk0oaJq6fR2RJZl9uQ_qkZFBCaw7Lz4LQhuccs=.91014969-a44b-48a1-982a-7ac3823ecf4e@github.com>
 <PJ6kUa4lWZU68M6BPDEnV-bIz4oFr-r1cKE1gWmLGWY=.bfccefeb-3855-43ea-b64d-ba8774665efa@github.com>
 <-MgHTaqd3dqLKT6g0aNqTlcoG26drN5YYnmSURxZ5vY=.f574869b-a0fe-4298-9d31-d337384be191@github.com>
Message-ID: <Nash6PpjouiQlISz5hHlBGr7qH1NRzjgRvu84h6pDHo=.db2e6bf8-cece-4498-9ec3-9f266868ae8c@github.com>

On Thu, 29 May 2025 14:18:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8357683-process-SIGQUIT-still-blocked-after-JDK-8234262-with-jdk-lang-Process-launchMechanism=FORK-or-VFORK
>>  - unblock signals in fork mode
>
> Looks fine; will run some tests in the CI before approving.

Thank you, @RogerRiggs

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25428#issuecomment-2922428895

From stuefe at openjdk.org  Fri May 30 13:42:59 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 30 May 2025 13:42:59 GMT
Subject: Integrated: 8357683: (process) SIGQUIT still blocked after JDK-8234262
 with jdk.lang.Process.launchMechanism=FORK or VFORK
In-Reply-To: <4lcOGDk0oaJq6fR2RJZl9uQ_qkZFBCaw7Lz4LQhuccs=.91014969-a44b-48a1-982a-7ac3823ecf4e@github.com>
References: <4lcOGDk0oaJq6fR2RJZl9uQ_qkZFBCaw7Lz4LQhuccs=.91014969-a44b-48a1-982a-7ac3823ecf4e@github.com>
Message-ID: <cFbSAYogVMPSkXvA2YjYES4wr-qUZ-PZlo4_cDMbwRc=.483a0224-33f8-429a-8626-361a446f9795@github.com>

On Sat, 24 May 2025 05:49:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> See bug description. We now unblock all signals in both FORK and POSIX_SPAWN launch modes. This fixes the problem and makes the behavior consistent across these two modes.
> 
> I left the VFORK mode alone since I believe the signal state is still shared with the parent. One more reason to get rid of this mode soon (it's deprecated with 25 and will be removed with 26)
> 
> The fix just moves the unblocking code from the jspawnhelper over to the child process function that is called for all three modes.
> 
> -----
> 
> Testing: I did various manual tests. I also tested that test/jdk/java/lang/ProcessBuilder/UnblockSignals.java succeeds with both POSIX_SPAWN and FORK mode now and that the behavior is unchanged (still broken) for VFORK mode.
> 
> ping @RogerRiggs I would like to get this still into JDK 25; the fix is small and clean enough to not worry me.

This pull request has now been integrated.

Changeset: ae3d96a4
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ae3d96a4ec87262bc2f01d87fe91daa5d0d3966f
Stats:     30 lines in 3 files changed: 20 ins; 6 del; 4 mod

8357683: (process) SIGQUIT still blocked after JDK-8234262 with jdk.lang.Process.launchMechanism=FORK or VFORK

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/25428

From weijun at openjdk.org  Fri May 30 13:46:51 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 30 May 2025 13:46:51 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <bDqDySX1BG1Y7OOoTeFjpGVoUhOOB5tb8PiaYOaYqas=.6fe24483-812e-4761-8fd7-2dadfe97d69d@github.com>

On Fri, 30 May 2025 11:07:30 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

Have you thought about creating a helper method for this purpose even if it's internal? At least, for the tests you can create one in `/test/lib`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2922441338

From vyazici at openjdk.org  Fri May 30 14:01:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 30 May 2025 14:01:55 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: <bDqDySX1BG1Y7OOoTeFjpGVoUhOOB5tb8PiaYOaYqas=.6fe24483-812e-4761-8fd7-2dadfe97d69d@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <bDqDySX1BG1Y7OOoTeFjpGVoUhOOB5tb8PiaYOaYqas=.6fe24483-812e-4761-8fd7-2dadfe97d69d@github.com>
Message-ID: <E9b9UD8T3CZoDC8h06KoWMmmFikmVjRpmltbpnCcbpM=.7dd730d3-e0b6-4318-87d3-29ba4152bd04@github.com>

On Fri, 30 May 2025 13:44:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Have you thought about creating a helper method for this purpose even if it's internal? At least, for the tests you can create one in `/test/lib`.

Required changes are pretty minimal ? passing `System.getProperty("stdin.encoding")` as an argument to the ctor. I doubt adding an extra layer of indirection (plus the need for changes in `@build` and `@library` tags) will worth it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2922477202

From rriggs at openjdk.org  Fri May 30 14:06:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 30 May 2025 14:06:29 GMT
Subject: RFR: 8357823: Changes in StringBuilder (JDK-8351443) caused a 1-3%
 regression in biojava
Message-ID: <EqrJvAzbQYoe6SnQhsy9_KmtAhqJI4jGMaHOztKb0n8=.99ee9a06-04d4-499b-976c-74da3314f4b5@github.com>

Comment out assertions added in JDK-8351443 from AbstractStringBuilder.ensureCapacityNewCoder that increase the codesize, preventing some inlining, and reducing performance

       assert coder == newCoder || newCoder == UTF16 : "bad new coder UTF16 -> LATIN1";
       assert count <= newCapacity : "count exceeds new capacity";

-------------

Commit messages:
 - 8357823: Changes in StringBuilder (JDK-8351443) caused a 1-3% regression in biojava

Changes: https://git.openjdk.org/jdk/pull/25550/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25550&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357823
  Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25550/head:pull/25550

PR: https://git.openjdk.org/jdk/pull/25550

From alanb at openjdk.org  Fri May 30 14:08:02 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 14:08:02 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v15]
In-Reply-To: <bKpaZY60SBN77rtuHLpr9Lj9ZyeoyAJ3RoQjtnrWuIQ=.8c21d06d-0f6e-4c2c-91e1-3dbc6c688d6c@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <bKpaZY60SBN77rtuHLpr9Lj9ZyeoyAJ3RoQjtnrWuIQ=.8c21d06d-0f6e-4c2c-91e1-3dbc6c688d6c@github.com>
Message-ID: <v1tfGyIADrQUtO8Q0-RFN3ee9kyL0JaoGdImK4lbsic=.680eaae3-ce2a-491c-9bfc-22bc297efb19@github.com>

On Tue, 27 May 2025 19:21:45 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplifying parsing of version parameter.

API docs + update to ZipFileSystem looks good. Test coverage looks good too.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25178#pullrequestreview-2881470041

From alanb at openjdk.org  Fri May 30 14:27:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 14:27:51 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <sa8L4ZBywxveDtzE7b5VbcdXy3cLvh3INzrIKv4ja7s=.01a87615-dc77-4022-a52a-2e6225b83f8f@github.com>

On Fri, 30 May 2025 11:07:30 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

test/jdk/com/sun/tools/attach/Application.java line 40:

> 38: 
> 39:         try (BufferedReader br = new BufferedReader(new InputStreamReader(
> 40:                 System.in, System.getProperty("stdin.encoding")))) {

This "application" is launched by the test so connected to the parent process rather than the console.

test/jdk/java/lang/ProcessHandle/JavaChild.java line 315:

> 313:                         // children and wait for each to exit
> 314:                         sendResult(action, "start");
> 315:                         try (Reader reader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));

I didn't study the test closely but I think this is another case where a child process is launched so System.in is connected to the parent rather than the console.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2116027806
PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2116031061

From jpai at openjdk.org  Fri May 30 14:37:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 30 May 2025 14:37:52 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications
In-Reply-To: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
Message-ID: <ko-_7VW-GjnQeNrq52gGF91R7pdLffG0hcu62tjRkWI=.56fafc4b-d6ec-4c2c-be6c-6bcacceb8b09@github.com>

On Thu, 29 May 2025 00:21:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> For a full explanation, see the bug report [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015).
> 
> This PR includes three related changes:
> * New overrides in SequencedMap view collection implementations, which improve their behavior.
> * Update to `@implSpec` clauses to reflect this behavior (which was previously ill-specified).
> * Update to a test which relied on unspecified behavior.

Overall this looks good to me. I just have a small question about the newly introduced text.

The copyright years on BasicMap.java and SequencedMap.java will need a update before integrating.

src/java.base/share/classes/java/util/SequencedMap.java line 271:

> 269:      * Its {@link SequencedSet#getFirst getFirst} and {@link SequencedSet#getLast getLast}
> 270:      * methods are implemented in terms of the {@link #firstEntry firstEntry} and {@link
> 271:      * #lastEntry lastEntry} methods of this class, respectively. Its {@link

Hello Stuart, some parts of this and other updated method docs use "this interface", "this map", "this class". Was it intentional to use "this class" in this newly added text?

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25515#pullrequestreview-2881559356
PR Review Comment: https://git.openjdk.org/jdk/pull/25515#discussion_r2116044744

From jpai at openjdk.org  Fri May 30 14:40:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 30 May 2025 14:40:50 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications
In-Reply-To: <ko-_7VW-GjnQeNrq52gGF91R7pdLffG0hcu62tjRkWI=.56fafc4b-d6ec-4c2c-be6c-6bcacceb8b09@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
 <ko-_7VW-GjnQeNrq52gGF91R7pdLffG0hcu62tjRkWI=.56fafc4b-d6ec-4c2c-be6c-6bcacceb8b09@github.com>
Message-ID: <8mVKzQ7NxFGFVdGLfpG3vGyDRaY4lHBfCNFHd5bwntg=.849ed26b-8e15-4bc6-aef7-c167743b7901@github.com>

On Fri, 30 May 2025 14:35:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I just have a small question about the newly introduced text.

I just realized one other thing - the updated BasicMap.java fixes an issue in an existing test. Do we already have tests that might cover the new proposed semantics of these methods on the returned Set/Collection from the `SequencedMap.sequencedEntrySet/sequencedKeySet/sequenceValues`? Or should those be added?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25515#issuecomment-2922578991

From michaelm at openjdk.org  Fri May 30 14:52:56 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 14:52:56 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v16]
In-Reply-To: <QgV6ixHQPTp0NebQMaKsAl0XczpOvWTO8pRTt-ANCXQ=.d0742c1d-7830-4237-aa29-0c4ac56613d3@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <BvjJ2qOTgXQznUOi2ImMfEkHRcEoN6OXFNen4g9A23s=.c3c6599f-407f-40d6-9055-c09555064b0f@github.com>
 <QgV6ixHQPTp0NebQMaKsAl0XczpOvWTO8pRTt-ANCXQ=.d0742c1d-7830-4237-aa29-0c4ac56613d3@github.com>
Message-ID: <pE3PvNRbEjNabwqaeHhR7XW6CUx8D3A3OBLSEmTT1Os=.5f6be752-907e-42da-9a99-92583720c862@github.com>

On Fri, 30 May 2025 13:32:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed problem with j.n.HostPortRange
>
> src/java.base/share/conf/security/java.security line 1282:
> 
>> 1280: # Exception messages may include potentially sensitive information such as file
>> 1281: # names, host names, or port numbers. By default, socket related exceptions
>> 1282: # have this information restricted (meaning the sensitive details are removed).
> 
> I found the "By default ..." sentence a little confusing, since other categories are also restricted by default. My initial thought is to just remove this sentence, as reading further will make it more clear that the hostInfoExclSocket category is the only one that is not restricted by default. Alternatively, you could flip the meaning of this sentence and say which exceptions are **not** restricted by default.

Fair point. I think we can make this clearer with a small addition. I propose to add the following sentence after the one starting "By default ..."

# Exception messages relating to Jar files and exceptions containing user
# identity information are also restricted by default.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2116074735

From alanb at openjdk.org  Fri May 30 15:37:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 May 2025 15:37:51 GMT
Subject: RFR: 8358151 : Harden JSR166 Test case
 testShutdownNow_delayedTasks
In-Reply-To: <FBGiqy8ENgXWOL9R7S_2eGFH_gCXHhnnBpm_4uN1TlA=.d43496b9-7f1d-4d0a-a8f0-2dd826874f41@github.com>
References: <FBGiqy8ENgXWOL9R7S_2eGFH_gCXHhnnBpm_4uN1TlA=.d43496b9-7f1d-4d0a-a8f0-2dd826874f41@github.com>
Message-ID: <HB4SX9lyTTDXks6ReUabtsp0oMHmFRCjskQG1m5sEZU=.fbba3078-5393-4422-a79d-c9f5ae24bfc3@github.com>

On Fri, 30 May 2025 12:16:15 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Bumping the (synthetic) delays to 100 seconds to ensure that they don't run prior to shutdown being finished.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25548#pullrequestreview-2881721078

From bpb at openjdk.org  Fri May 30 16:14:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 16:14:54 GMT
Subject: RFR: 8354450: A File should be invalid if an element of its name
 sequence ends with a space [v4]
In-Reply-To: <dTTkjNs6iy8b7LtwxDY_9_fjmK7dXfo3W0Me56K0EpY=.0db10e0b-7f10-4937-bba2-2ce346f2037c@github.com>
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
 <49Yvff-cNfqJxpzHD6NThf3zH46MivdDcKn0axoNEjc=.e5971545-10dc-4d56-b006-8e0409a179bc@github.com>
 <dTTkjNs6iy8b7LtwxDY_9_fjmK7dXfo3W0Me56K0EpY=.0db10e0b-7f10-4937-bba2-2ce346f2037c@github.com>
Message-ID: <gjLi7TsRe0TDAFLlP_zKSzZu-_toYg0-fs_jiaJan3s=.7745703c-cb5b-4eac-ad06-684a2f82706c@github.com>

On Fri, 30 May 2025 13:28:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> We will need a release note to document the behavior change.

Will do.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24635#issuecomment-2922804844

From rriggs at openjdk.org  Fri May 30 16:33:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 30 May 2025 16:33:52 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v4]
In-Reply-To: <1gOicbq5qevD2Tk0pCRhf5PbNt7hr8qoN7y3j2S-Tgk=.df896664-eae3-4f15-8a7c-d0ce48ea2404@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <1gOicbq5qevD2Tk0pCRhf5PbNt7hr8qoN7y3j2S-Tgk=.df896664-eae3-4f15-8a7c-d0ce48ea2404@github.com>
Message-ID: <Pb9pSNK33kspu8cmoBgLs0b7ugBdYxFE6rUQM6iZ8OA=.8f5cd6e5-deda-42bb-b418-1a4ee2afe91a@github.com>

On Fri, 30 May 2025 10:48:20 GMT, kieran-farrell <duke at openjdk.org> wrote:

>> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
>> 
>> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
>> 
>> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
>> 
>> 
>> - random-byte-only - 99.8%
>> - higher-precision - 3.5%
>> - counter-based - 0%
>> 
>> 
>> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
>> 
>> - random-byte-only   143.487 ? 10.932  ns/op
>> - higher-precision      149.651 ?  8.438 ns/op
>> - counter-based         245.036 ?  2.943  ns/op
>> 
>> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.
>
> kieran-farrell has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - update test
>  - update test
>  - updates
>  - update method to lsb and msb with arraybytes

src/java.base/share/classes/java/util/UUID.java line 195:

> 193:      * @return a {@code UUID} generated with the current Unix timestamp
> 194:      *
> 195:      * @spec RFC 9562

The sections of the RFC describing the required monotonicity seem to require measures be taken in case of leap seconds and other clock setting cases.  System.currentTimeMillis() does not ensure a monotonic time.
Something using `nanoTime` could do better since nanoTime is monotonic.

  // Record a fixed point in nano-time corresponding to a fix point in System.currentTimeMillis()
  // and use the delta from the current nano-time as the current nano-time.
  private static final long ORIGIN_MS = System.currentTimeMillis();
  private static final long ORIGIN_NS = System.nanoTime();
  
  private static long monotonicMS() {
      return  ORIGIN_MS + (System.nanoTime() - ORIGIN_NS) / 1_000_000;
  }

src/java.base/share/classes/java/util/UUID.java line 226:

> 224:         if (timestamp < 0 || (timestamp >>> 48) != 0) {
> 225:             throw new IllegalArgumentException("Timestamp must be a 48-bit Unix Epoch time in milliseconds.");
> 226:         }

Sadly, the RFC does not make any provision for times before 1/1/1970, so there is an incomplete mapping between epochTime in other contexts that allows negative values to represent earlier times.
The test for positive 48 bits could be as simple as:
Suggestion:

        if (timestamp >> 48) != 0) {
            throw new IllegalArgumentException("Timestamp must be an unsigned 48-bit Unix Epoch time in milliseconds.");
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2116209786
PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2116189540

From jlu at openjdk.org  Fri May 30 17:02:12 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 May 2025 17:02:12 GMT
Subject: RFR: 8358095: Cleanup tests with explicit locale provider set to
 only CLDR [v3]
In-Reply-To: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
Message-ID: <5cqPWaioFUDsw2wn7U5eCC-YlWAoVx0R7zhSJHzNETY=.8b6e93da-1b95-402c-84dc-c5ba15269160@github.com>

> Please review this PR which cleans up some i18n tests.
> 
> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
> 
> As this change is trivial cleanup, bug IDs are not updated in this change.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  re-add testCompat to Bug8167143.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25532/files
  - new: https://git.openjdk.org/jdk/pull/25532/files/2eb1edd5..d8da7744

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25532&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25532&range=01-02

  Stats: 47 lines in 1 file changed: 47 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25532/head:pull/25532

PR: https://git.openjdk.org/jdk/pull/25532

From jlu at openjdk.org  Fri May 30 17:02:12 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 May 2025 17:02:12 GMT
Subject: RFR: 8358095: Cleanup tests with explicit locale provider set to
 only CLDR [v3]
In-Reply-To: <Sz9onzoO82lM0V_GtJlZX5J9301FawxSP_EzKg_MOTA=.d76c3339-c504-4c08-875a-7f55db86ff1c@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
 <7iPhlactV6aDx8v6qI2AckiFZ-Iy2xae2_LkqUo_xWA=.b2d2c937-e78d-433e-99fb-c0c9817c47f9@github.com>
 <Sz9onzoO82lM0V_GtJlZX5J9301FawxSP_EzKg_MOTA=.d76c3339-c504-4c08-875a-7f55db86ff1c@github.com>
Message-ID: <IkJAmSbqaUBaBs-Y3a2kp8EQNShZSzeVruZshs-fMTI=.a1a17e8d-5f8d-4f3e-b584-780acd055ba0@github.com>

On Fri, 30 May 2025 00:41:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   re-add testCompat to Bug8167143.java
>
> test/jdk/java/util/TimeZone/Bug8167143.java line 102:
> 
>> 100:             case "testCompat":
>> 101:                 testImplicitCompatLocales();
>> 102:                 break;
> 
> The method name is deceiving, but the test still has value because it tests the internal `FALLBACK` provider. In fact, functions for `BreakIterator` and `Collator` should be fully functional from that provider, as `CLDR` provider does not provide those. Maybe renaming `Compat` to `Fallback` would be appropriate.

The run invocation for `testCompat` was removed from the Jtreg header in [JDK-8174269](https://bugs.openjdk.org/browse/JDK-8174269). So since then, that test was not run, which was why I removed it. I tried re-adding this test as part of the run directives, and it fails. (I presume that's why it was removed after COMPAT removal.)

It is testing the JRE provider, we can repurpose the test to check the FALLBACK provider, but we would only expect the implicit locales for BreakIteratorProvider and CollatorProvider (as you said). I filed [JDK-8358170](https://bugs.openjdk.org/browse/JDK-8358170) because I think this change would be out of scope for this issue. I simply reverted the removal in the https://github.com/openjdk/jdk/pull/25532/commits/d8da77440d6ed63dee6444dda549279cc15ae918.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25532#discussion_r2116268074

From jlu at openjdk.org  Fri May 30 17:15:55 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 May 2025 17:15:55 GMT
Subject: Integrated: 8358089: Remove the GenerateKeyList.java test tool
In-Reply-To: <FHqDrBv0LPDDAtIbhtieILpmn2aVEfq8XtJ5Afnbc6s=.13cbef12-e19c-4ea5-8254-dbc9f4a56b97@github.com>
References: <FHqDrBv0LPDDAtIbhtieILpmn2aVEfq8XtJ5Afnbc6s=.13cbef12-e19c-4ea5-8254-dbc9f4a56b97@github.com>
Message-ID: <vzxvhxByNasEYCn-Wh94USAwKo_ZIe8us-JnNtTRIFw=.cc6e7218-e906-4b0b-a667-c5fd23fe9bc1@github.com>

On Thu, 29 May 2025 19:01:04 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes the test tool `GenerateKeyList.java` after the COMPAT locale data removal.
> 
> `LocaleDataTest.java` may optionally use the `GenerateKeyList.java` tool. However, this tool is manually used and was primarily used for COMPAT data. There is no longer any point to keep it, and it can always be retrieved via the VCS if needed.

This pull request has now been integrated.

Changeset: 81464cd1
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81464cd1141ebdf0cdde22e7388b97224d810f4a
Stats:     90 lines in 1 file changed: 0 ins; 90 del; 0 mod

8358089: Remove the GenerateKeyList.java test tool

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/25527

From jbhateja at openjdk.org  Fri May 30 17:22:53 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 30 May 2025 17:22:53 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v4]
In-Reply-To: <eJbb5hzhM27dVuc7MD6kqvlLReNHthJNiRXttkPwzQo=.bb1151a7-959a-4f56-8ebf-bde8126ea5d4@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <72GCipLKeCWCG-4jsG5XhZKkTdVsWafEq_wA0oD-0mk=.c70af814-54fe-43d2-b7c9-72b845eb99d5@github.com>
 <kPx9NqOgNJPStCsPd4PtRhfbQeEXi5xbefvSjCHoPSY=.aa26a490-8f90-4e17-8c9e-cde0c25a9fbb@github.com>
 <eJbb5hzhM27dVuc7MD6kqvlLReNHthJNiRXttkPwzQo=.bb1151a7-959a-4f56-8ebf-bde8126ea5d4@github.com>
Message-ID: <v7r6P6Vbx5tR4sIwy5mwub6ev0OnG1n3HipHuJe-qVc=.f1ce37ed-1218-4f0a-89ab-f4b5c7fdbbf8@github.com>

On Thu, 29 May 2025 18:49:28 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/lang/CbrtPerf.java line 56:
>> 
>>> 54:     public static class CbrtPerfRanges {
>>> 55:         public static int cbrtInputCount = 2048;
>>> 56: 
>> 
>> Please create separate CbrtPerfSpecialValues for +/- 0.0 and +/- Infinity and NaN values.
>> I understand that handling special cases in intrinsic may impact general case performance but its ok to have atleast micro for it.
>
> Ok, I added this to the new set of micro-benchmarks. I kept them as variable values.

With Intrinsic Disabled:-

Benchmark                                              Mode  Cnt        Score   Error   Units
CbrtPerf.CbrtPerfSpecialValues.cbrtDouble0            thrpt    2  1343559.770          ops/ms
CbrtPerf.CbrtPerfSpecialValues.cbrtDoubleInf          thrpt    2   881930.283          ops/ms
CbrtPerf.CbrtPerfSpecialValues.cbrtDoubleNaN          thrpt    2   973307.409          ops/ms
CbrtPerf.CbrtPerfSpecialValues.cbrtDoubleNegative0    thrpt    2  1342454.046          ops/ms
CbrtPerf.CbrtPerfSpecialValues.cbrtDoubleNegativeInf  thrpt    2   880169.071          ops/ms

With Intrinsic Enabled:-

Benchmark                                              Mode  Cnt       Score   Error   Units
CbrtPerf.CbrtPerfSpecialValues.cbrtDouble0            thrpt    2  293228.991          ops/ms
CbrtPerf.CbrtPerfSpecialValues.cbrtDoubleInf          thrpt    2  329190.573          ops/ms
CbrtPerf.CbrtPerfSpecialValues.cbrtDoubleNaN          thrpt    2  334625.414          ops/ms
CbrtPerf.CbrtPerfSpecialValues.cbrtDoubleNegative0    thrpt    2  270939.709          ops/ms
CbrtPerf.CbrtPerfSpecialValues.cbrtDoubleNegativeInf  thrpt    2  328087.618          ops/ms


As expected, optimized intrinsic penalizes special case performance to optimize generic case control paths. Have you tried adding these special checks and measuring the impact on performance?  Alternatively, we can create a follow up JBS to address it later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2116295936

From naoto at openjdk.org  Fri May 30 17:26:57 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 May 2025 17:26:57 GMT
Subject: RFR: 8357882: Use UTF-8 encoded data in LocaleDataTest
In-Reply-To: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>
References: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>
Message-ID: <-bMo8IZCQV09yozAd6myBZFxrv7Ccov5peGrg2wFNcM=.5a0a63ce-1fe7-4986-b991-3d146c98e319@github.com>

On Thu, 29 May 2025 17:20:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Test refactoring stemmed from the discussion at https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160. The test is now based on UTF-8 instead of ISO-8859-1

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25524#issuecomment-2922945653

From naoto at openjdk.org  Fri May 30 17:26:57 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 May 2025 17:26:57 GMT
Subject: Integrated: 8357882: Use UTF-8 encoded data in LocaleDataTest
In-Reply-To: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>
References: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>
Message-ID: <_Eu-yQoXURBs4_MKCMyp6uQ10vGZ1jHoBk2Nfn3A000=.af1bf3e9-b25b-489a-b2ed-ce6ac3e8c46b@github.com>

On Thu, 29 May 2025 17:20:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Test refactoring stemmed from the discussion at https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160. The test is now based on UTF-8 instead of ISO-8859-1

This pull request has now been integrated.

Changeset: 4fa4f151
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4fa4f15122213afea5cb25166c3b36a1c395b06c
Stats:     4205 lines in 2 files changed: 0 ins; 101 del; 4104 mod

8357882: Use UTF-8 encoded data in LocaleDataTest

Reviewed-by: jlu, joehw

-------------

PR: https://git.openjdk.org/jdk/pull/25524

From mullan at openjdk.org  Fri May 30 17:35:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 30 May 2025 17:35:54 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v16]
In-Reply-To: <pE3PvNRbEjNabwqaeHhR7XW6CUx8D3A3OBLSEmTT1Os=.5f6be752-907e-42da-9a99-92583720c862@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <BvjJ2qOTgXQznUOi2ImMfEkHRcEoN6OXFNen4g9A23s=.c3c6599f-407f-40d6-9055-c09555064b0f@github.com>
 <QgV6ixHQPTp0NebQMaKsAl0XczpOvWTO8pRTt-ANCXQ=.d0742c1d-7830-4237-aa29-0c4ac56613d3@github.com>
 <pE3PvNRbEjNabwqaeHhR7XW6CUx8D3A3OBLSEmTT1Os=.5f6be752-907e-42da-9a99-92583720c862@github.com>
Message-ID: <f8m8PjPiFHbTl_iC58jZRmiL3f7QGCvpKnWHLp96m6o=.891a55c7-0e96-4b64-ad91-934b2d9d3f6e@github.com>

On Fri, 30 May 2025 14:50:28 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/conf/security/java.security line 1282:
>> 
>>> 1280: # Exception messages may include potentially sensitive information such as file
>>> 1281: # names, host names, or port numbers. By default, socket related exceptions
>>> 1282: # have this information restricted (meaning the sensitive details are removed).
>> 
>> I found the "By default ..." sentence a little confusing, since other categories are also restricted by default. My initial thought is to just remove this sentence, as reading further will make it more clear that the hostInfoExclSocket category is the only one that is not restricted by default. Alternatively, you could flip the meaning of this sentence and say which exceptions are **not** restricted by default.
>
> Fair point. I think we can make this clearer with a small addition. I propose to add the following sentence after the one starting "By default ..."
> 
> # Exception messages relating to Jar files and exceptions containing user
> # identity information are also restricted by default.

I would change "Jar" to "JAR" as I think that is the more common form and used in other places in this file. Looks fine otherwise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2116314192

From naoto at openjdk.org  Fri May 30 17:41:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 May 2025 17:41:52 GMT
Subject: RFR: 8358095: Cleanup tests with explicit locale provider set to
 only CLDR [v3]
In-Reply-To: <5cqPWaioFUDsw2wn7U5eCC-YlWAoVx0R7zhSJHzNETY=.8b6e93da-1b95-402c-84dc-c5ba15269160@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
 <5cqPWaioFUDsw2wn7U5eCC-YlWAoVx0R7zhSJHzNETY=.8b6e93da-1b95-402c-84dc-c5ba15269160@github.com>
Message-ID: <CdZ_XhCpu2KbDxdYArjtxVQWDk3X2lfb2A8HvDAntBA=.eb4dfece-f90f-47a2-9bd5-a620a026e7bc@github.com>

On Fri, 30 May 2025 17:02:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which cleans up some i18n tests.
>> 
>> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
>> 
>> As this change is trivial cleanup, bug IDs are not updated in this change.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-add testCompat to Bug8167143.java

LGTM. Thanks for taking care of the testCompat with another issue.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25532#pullrequestreview-2882000850

From jbhateja at openjdk.org  Fri May 30 17:58:55 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 30 May 2025 17:58:55 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v5]
In-Reply-To: <GE6s8raLeTlcMDb0coe89QbMYSPqWtjjkr_puB8hcx8=.d4911eb3-3201-441b-81a9-b476ea5b64c9@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <GE6s8raLeTlcMDb0coe89QbMYSPqWtjjkr_puB8hcx8=.d4911eb3-3201-441b-81a9-b476ea5b64c9@github.com>
Message-ID: <k6su39c38xIXp-JnEl5EZaGUeUGWQidxR2QlL6NeV5M=.6ee048ca-9aa9-4b4a-bd86-77485e6b4dcc@github.com>

On Thu, 29 May 2025 18:56:11 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The command to run all range specific micro-benchmarks is posted below.
>> 
>> `make test TEST="micro:CbrtPerf.CbrtPerfRanges"`
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs.
>> 
>> | Input range(s)                                  | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
>> | :-------------------------------------: | :-------------------------------: | :-------------------------------: | :---------: |
>> | [-2^(-1022), 2^(-1022)]                   | 6568                                        | 17678                                      | 2.69x       |
>> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932                                    | 200897                                    | 1.45x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add newline back to templateInterpreterGenerator_x86_64.cpp source file
>  - Add special case values to cbrt micro-benchmark set

LGTM,  we have already created follow up JBSs for known limiations.

-------------

Marked as reviewed by jbhateja (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24470#pullrequestreview-2882036242

From bpb at openjdk.org  Fri May 30 18:01:52 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 18:01:52 GMT
Subject: RFR: 8358095: Cleanup tests with explicit locale provider set to
 only CLDR [v3]
In-Reply-To: <5cqPWaioFUDsw2wn7U5eCC-YlWAoVx0R7zhSJHzNETY=.8b6e93da-1b95-402c-84dc-c5ba15269160@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
 <5cqPWaioFUDsw2wn7U5eCC-YlWAoVx0R7zhSJHzNETY=.8b6e93da-1b95-402c-84dc-c5ba15269160@github.com>
Message-ID: <W44J_ijq5-l-iwIYPgbU1d-vSowvt10Klj_jMU5H89Q=.031ddf6c-86ee-4851-a269-cdef68c8f508@github.com>

On Fri, 30 May 2025 17:02:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which cleans up some i18n tests.
>> 
>> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
>> 
>> As this change is trivial cleanup, bug IDs are not updated in this change.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-add testCompat to Bug8167143.java

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25532#pullrequestreview-2882040739

From duke at openjdk.org  Fri May 30 18:43:53 2025
From: duke at openjdk.org (duke)
Date: Fri, 30 May 2025 18:43:53 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v5]
In-Reply-To: <GE6s8raLeTlcMDb0coe89QbMYSPqWtjjkr_puB8hcx8=.d4911eb3-3201-441b-81a9-b476ea5b64c9@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <GE6s8raLeTlcMDb0coe89QbMYSPqWtjjkr_puB8hcx8=.d4911eb3-3201-441b-81a9-b476ea5b64c9@github.com>
Message-ID: <twUlp2jG-yahclPgfANuQfNC-oNmVXuygRaewNhVHRA=.7fb5cce1-4ab9-4ac2-a606-d5a30e35659a@github.com>

On Thu, 29 May 2025 18:56:11 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The command to run all range specific micro-benchmarks is posted below.
>> 
>> `make test TEST="micro:CbrtPerf.CbrtPerfRanges"`
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs.
>> 
>> | Input range(s)                                  | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
>> | :-------------------------------------: | :-------------------------------: | :-------------------------------: | :---------: |
>> | [-2^(-1022), 2^(-1022)]                   | 6568                                        | 17678                                      | 2.69x       |
>> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932                                    | 200897                                    | 1.45x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add newline back to templateInterpreterGenerator_x86_64.cpp source file
>  - Add special case values to cbrt micro-benchmark set

@missa-prime 
Your change (at version 233e0188c7637cdc08bb4bebd8cb4721ccc352d1) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2923150761

From sviswanathan at openjdk.org  Fri May 30 19:05:55 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 30 May 2025 19:05:55 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v5]
In-Reply-To: <GE6s8raLeTlcMDb0coe89QbMYSPqWtjjkr_puB8hcx8=.d4911eb3-3201-441b-81a9-b476ea5b64c9@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <GE6s8raLeTlcMDb0coe89QbMYSPqWtjjkr_puB8hcx8=.d4911eb3-3201-441b-81a9-b476ea5b64c9@github.com>
Message-ID: <hwyI3EUmwW6G2T7CyqbBuW4hP9bcSiQ5sZHbQSc3sGQ=.e40be297-f036-4616-a7fb-cd0b8b6895c5@github.com>

On Thu, 29 May 2025 18:56:11 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The command to run all range specific micro-benchmarks is posted below.
>> 
>> `make test TEST="micro:CbrtPerf.CbrtPerfRanges"`
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs.
>> 
>> | Input range(s)                                  | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
>> | :-------------------------------------: | :-------------------------------: | :-------------------------------: | :---------: |
>> | [-2^(-1022), 2^(-1022)]                   | 6568                                        | 17678                                      | 2.69x       |
>> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932                                    | 200897                                    | 1.45x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add newline back to templateInterpreterGenerator_x86_64.cpp source file
>  - Add special case values to cbrt micro-benchmark set

src/hotspot/cpu/x86/assembler_x86.cpp line 2879:

> 2877:   emit_operand(dst, src, 0);
> 2878: }
> 2879: 

One more change is needed. We need to set address attributes here, as movapd has Address as one of the input:
 attributes.set_address_attributes(/* tuple_type */ EVEX_FVM, /* input_size_in_bits */ EVEX_NObit);
This should be done before call to simd_prefix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2116482247

From duke at openjdk.org  Fri May 30 19:34:16 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Fri, 30 May 2025 19:34:16 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v6]
In-Reply-To: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
Message-ID: <sZVVm3lr1byp_brwwk80CWNovJIKZ4Mc_RvcRNIBBEI=.4f9e6ca0-108f-4e11-9e0c-f4b5bcf32482@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
> 
> The command to run all range specific micro-benchmarks is posted below.
> 
> `make test TEST="micro:CbrtPerf.CbrtPerfRanges"`
> 
> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version.
> 
> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs.
> 
> | Input range(s)                                  | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
> | :-------------------------------------: | :-------------------------------: | :-------------------------------: | :---------: |
> | [-2^(-1022), 2^(-1022)]                   | 6568                                        | 17678                                      | 2.69x       |
> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932                                    | 200897                                    | 1.45x       |
> 
> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.

Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:

  Set address attributes in movapd assembly instruction function definition

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24470/files
  - new: https://git.openjdk.org/jdk/pull/24470/files/233e0188..c931222c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24470&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24470&range=04-05

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24470.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24470/head:pull/24470

PR: https://git.openjdk.org/jdk/pull/24470

From vlivanov at openjdk.org  Fri May 30 19:33:55 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 30 May 2025 19:33:55 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v6]
In-Reply-To: <wIIM4tKR9hV6IpgsQN6YWxG8DTw8Ua-vl5fAYDpKsw8=.38c3e194-dc26-44bc-bf56-29957fe2361f@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com>
 <ymq-cS14PaC1PpdKAzAZJwxdwtVTbSZtT-LNC21lW6Q=.f956592a-fd59-4bb5-a485-f4138942d290@github.com>
 <lnDH0vCQvoIGjjsjeO7ukv8gpTfp1vWR8hOX-CXlFjA=.a859787f-bc16-40c2-9f9d-ae879e68dc25@github.com>
 <rHMm6DwsyFJIOTQRKO17T0VyOvaxUwxVpwWKw4mpIj8=.d2633532-bc82-4505-a14b-45b46798d4ff@github.com>
 <cskdHy0_3zFOp7bAI-zz6V-avY2vPIcnwIseaE0NrS8=.3c147c4d-78e9-4499-88d3-73fbb40560ab@github.com>
 <wQkKLSTJsvldZxWleQpPTv_9N1ugC067-gv5LUVTdPI=.8917db0c-0653-48f5-acc2-e040a61f650a@github.com>
 <DOmW1DiflE8ovJmLEHeU8S8laqzbcy1gjqfRsJaMyUU=.8bca0d18-8ffa-402d-af96-66236f6b84c2@github.com>
 <_99Geoayi09Ey7YT7qWw4pjMqbVUNxfKpFBwwI_EbHg=.e81158ae-813c-4015-94d6-4404eb756394@github.com>
 <ZS11BbUZhXvjekz9J6Nx0YdmsRy4vi8Xc4LUc-60I_w=.d0f276f4-f023-4414-9fc2-8000ffa4e0c1@github.com>
 <wIIM4tKR9hV6IpgsQN6YWxG8DTw8Ua-vl5f
 AYDpKsw8=.38c3e194-dc26-44bc-bf56-29957fe2361f@github.com>
Message-ID: <OO52OkYR36yZwZgtvR6vpVsIz6FzeZeLmmaxnle4fTo=.9a912443-0cd1-4cba-9233-fad8a2e59e21@github.com>

On Fri, 30 May 2025 11:25:01 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> If get0() is the intrinsic, then I think that referenced snippet from the
Compile ctor can go away? 

Yes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2116517383

From duke at openjdk.org  Fri May 30 19:34:16 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Fri, 30 May 2025 19:34:16 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v5]
In-Reply-To: <hwyI3EUmwW6G2T7CyqbBuW4hP9bcSiQ5sZHbQSc3sGQ=.e40be297-f036-4616-a7fb-cd0b8b6895c5@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <GE6s8raLeTlcMDb0coe89QbMYSPqWtjjkr_puB8hcx8=.d4911eb3-3201-441b-81a9-b476ea5b64c9@github.com>
 <hwyI3EUmwW6G2T7CyqbBuW4hP9bcSiQ5sZHbQSc3sGQ=.e40be297-f036-4616-a7fb-cd0b8b6895c5@github.com>
Message-ID: <BEb4vhrs7UEZN4-31--4HokPd_5x4zwotTqOb0hu_B4=.b684bf8d-5a95-4899-8133-c09cad01ab7f@github.com>

On Fri, 30 May 2025 19:03:00 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Mohamed Issa has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add newline back to templateInterpreterGenerator_x86_64.cpp source file
>>  - Add special case values to cbrt micro-benchmark set
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 2879:
> 
>> 2877:   emit_operand(dst, src, 0);
>> 2878: }
>> 2879: 
> 
> One more change is needed. We need to set address attributes here, as movapd has Address as one of the input:
> `attributes.set_address_attributes(/* tuple_type */ EVEX_FVM, /* input_size_in_bits */ EVEX_NObit);`
> This should be done before call to simd_prefix.

I added the change and re-ran the tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2116518295

From michaelm at openjdk.org  Fri May 30 20:50:37 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 20:50:37 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v17]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <kvmaa0cxCoqK7HE2kVuAIUDf4O_qDGucd7gd7Xje2bQ=.83fe5bdf-26e2-4672-b899-b0a6b61f508b@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 incrementally with one additional commit since the last revision:

  doc update to java.security

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/3eec6c03..5970c2b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=15-16

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 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 michaelm at openjdk.org  Fri May 30 20:58:11 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 30 May 2025 20:58:11 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v18]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <FNrGMio3jb29ipNfsDQi7WkE4YTdV57DePH2cfJ_jx8=.a2ff9393-5a98-4e58-a806-cc9055d87b13@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 incrementally with two additional commits since the last revision:

 - doc update to java.security
 - removed jmod/Handler change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/5970c2b3..4aad0141

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=16-17

  Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 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 psandoz at openjdk.org  Fri May 30 21:09:51 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 30 May 2025 21:09:51 GMT
Subject: RFR: 8356634: VectorShape#largestShapeFor should have public
 access [v5]
In-Reply-To: <kVx02Equ01JYZJKDfwDATTPusQHG6SjGouqOGaWkfQ0=.447d2808-4f3d-42c2-ac2f-8b7d7fcb7203@github.com>
References: <JavbxK-K4oPsdH53sMhVG1RCYBYlyOdZ_6wZCQm0uzk=.edfacd8d-88fb-485d-a86c-e9ac1571a09d@github.com>
 <kVx02Equ01JYZJKDfwDATTPusQHG6SjGouqOGaWkfQ0=.447d2808-4f3d-42c2-ac2f-8b7d7fcb7203@github.com>
Message-ID: <WZp8Srf2J9meKPKiRQVCJjZGyHF7DA3Pts5REgrrtqE=.69feca51-9af7-4ce1-a5bf-d5c55819abac@github.com>

On Thu, 29 May 2025 22:03:29 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> VectorShape#largestShapeFor is referenced in existing JavaDoc but has been package-private. This propose change makes it public and adds documentation for it.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyrights

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25513#pullrequestreview-2882536087

From igraves at openjdk.org  Fri May 30 21:13:54 2025
From: igraves at openjdk.org (Ian Graves)
Date: Fri, 30 May 2025 21:13:54 GMT
Subject: Integrated: 8356634: VectorShape#largestShapeFor should have public
 access
In-Reply-To: <JavbxK-K4oPsdH53sMhVG1RCYBYlyOdZ_6wZCQm0uzk=.edfacd8d-88fb-485d-a86c-e9ac1571a09d@github.com>
References: <JavbxK-K4oPsdH53sMhVG1RCYBYlyOdZ_6wZCQm0uzk=.edfacd8d-88fb-485d-a86c-e9ac1571a09d@github.com>
Message-ID: <6mxmUNQtnUPb02yLgQWdThfL45W9TyfvoeaoJgfsCXw=.9a7c0529-2c53-4841-9e6d-c109aebfc0e4@github.com>

On Wed, 28 May 2025 21:22:30 GMT, Ian Graves <igraves at openjdk.org> wrote:

> VectorShape#largestShapeFor is referenced in existing JavaDoc but has been package-private. This propose change makes it public and adds documentation for it.

This pull request has now been integrated.

Changeset: 09301c1d
Author:    Ian Graves <igraves at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/09301c1dc03a44e5c56a91303de81ba01dabfe71
Stats:     57 lines in 2 files changed: 51 ins; 0 del; 6 mod

8356634: VectorShape#largestShapeFor should have public access

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/25513

From sviswanathan at openjdk.org  Fri May 30 21:22:54 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 30 May 2025 21:22:54 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v6]
In-Reply-To: <sZVVm3lr1byp_brwwk80CWNovJIKZ4Mc_RvcRNIBBEI=.4f9e6ca0-108f-4e11-9e0c-f4b5bcf32482@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <sZVVm3lr1byp_brwwk80CWNovJIKZ4Mc_RvcRNIBBEI=.4f9e6ca0-108f-4e11-9e0c-f4b5bcf32482@github.com>
Message-ID: <tulSz8KsGI1NK8vsnhg53XpRIBZBBl33VI__BYsnC-4=.510a2ff6-a7d0-4f3f-a122-cbc1672ae52c@github.com>

On Fri, 30 May 2025 19:34:16 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The command to run all range specific micro-benchmarks is posted below.
>> 
>> `make test TEST="micro:CbrtPerf.CbrtPerfRanges"`
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs.
>> 
>> | Input range(s)                                  | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
>> | :-------------------------------------: | :-------------------------------: | :-------------------------------: | :---------: |
>> | [-2^(-1022), 2^(-1022)]                   | 6568                                        | 17678                                      | 2.69x       |
>> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932                                    | 200897                                    | 1.45x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set address attributes in movapd assembly instruction function definition

Marked as reviewed by sviswanathan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24470#pullrequestreview-2882583269

From duke at openjdk.org  Fri May 30 21:27:59 2025
From: duke at openjdk.org (duke)
Date: Fri, 30 May 2025 21:27:59 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v6]
In-Reply-To: <sZVVm3lr1byp_brwwk80CWNovJIKZ4Mc_RvcRNIBBEI=.4f9e6ca0-108f-4e11-9e0c-f4b5bcf32482@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <sZVVm3lr1byp_brwwk80CWNovJIKZ4Mc_RvcRNIBBEI=.4f9e6ca0-108f-4e11-9e0c-f4b5bcf32482@github.com>
Message-ID: <JYnyjMf8eQkmAfPaGvvGeKA7J1QUwoDoNSnU9y9T1IA=.8f58962a-793e-43c4-a5e3-e3310e914364@github.com>

On Fri, 30 May 2025 19:34:16 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The command to run all range specific micro-benchmarks is posted below.
>> 
>> `make test TEST="micro:CbrtPerf.CbrtPerfRanges"`
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs.
>> 
>> | Input range(s)                                  | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
>> | :-------------------------------------: | :-------------------------------: | :-------------------------------: | :---------: |
>> | [-2^(-1022), 2^(-1022)]                   | 6568                                        | 17678                                      | 2.69x       |
>> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932                                    | 200897                                    | 1.45x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set address attributes in movapd assembly instruction function definition

@missa-prime 
Your change (at version c931222c7d40f296de14585d6c902552a1e66f5a) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2923531486

From duke at openjdk.org  Fri May 30 21:39:52 2025
From: duke at openjdk.org (ExE Boss)
Date: Fri, 30 May 2025 21:39:52 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal [v2]
In-Reply-To: <lp1xFhlZNmOPvbkAsqk1nWHA_edVtGbkbryGXZGwjTg=.e824710a-4cac-48ea-a65c-3ddabfa27a22@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
 <lp1xFhlZNmOPvbkAsqk1nWHA_edVtGbkbryGXZGwjTg=.e824710a-4cac-48ea-a65c-3ddabfa27a22@github.com>
Message-ID: <VxyY6tC-siH_6C0HrNpIIvBJ-tPlmJKEqSW7ioK51m8=.b85fd988-3ac6-416a-a7fd-8cdca298b8af@github.com>

On Wed, 28 May 2025 13:39:40 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Some static final arrays of BigInteger and BigDecimal are stable and immutable. We should add `@Stable` to give the optimizer more information
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bug fix, from @minborg

src/java.base/share/classes/java/math/BigInteger.java line 192:

> 190:      * zero-length mag array.
> 191:      */
> 192:     @Stable

`BigInteger.mag` gets?written?to a?few?times during?computation in?`BigInteger?.largePrime(?)`:
https://github.com/openjdk/jdk/blob/db340e54f83cf7bf72abb94c9cf9cdac007ed38a/src/java.base/share/classes/java/math/BigInteger.java#L886-L887
https://github.com/openjdk/jdk/blob/db340e54f83cf7bf72abb94c9cf9cdac007ed38a/src/java.base/share/classes/java/math/BigInteger.java#L895-L898

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25437#discussion_r2116698333

From duke at openjdk.org  Fri May 30 21:49:59 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Fri, 30 May 2025 21:49:59 GMT
Subject: Integrated: 8353686: Optimize Math.cbrt for x86 64 bit platforms
In-Reply-To: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
Message-ID: <vexMWrsY7erB5EEMYlBXXCZxtY5z98zurXgacL8oBlU=.e87fa776-9af5-4815-8643-576016565c83@github.com>

On Sun, 6 Apr 2025 03:48:22 GMT, Mohamed Issa <duke at openjdk.org> wrote:

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
> 
> The command to run all range specific micro-benchmarks is posted below.
> 
> `make test TEST="micro:CbrtPerf.CbrtPerfRanges"`
> 
> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version.
> 
> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs.
> 
> | Input range(s)                                  | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
> | :-------------------------------------: | :-------------------------------: | :-------------------------------: | :---------: |
> | [-2^(-1022), 2^(-1022)]                   | 6568                                        | 17678                                      | 2.69x       |
> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932                                    | 200897                                    | 1.45x       |
> 
> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.

This pull request has now been integrated.

Changeset: 0df8c968
Author:    Mohamed Issa <mohamed.issa at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0df8c9684b8782ef830e2bd425217864c3f51784
Stats:     649 lines in 27 files changed: 637 ins; 1 del; 11 mod

8353686: Optimize Math.cbrt for x86 64 bit platforms

Reviewed-by: sviswanathan, sparasa, jbhateja

-------------

PR: https://git.openjdk.org/jdk/pull/24470

From swen at openjdk.org  Fri May 30 22:07:06 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 30 May 2025 22:07:06 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal [v3]
In-Reply-To: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
Message-ID: <98Ars6Qebvn48y6VXmJUmWnL2TlFUPlvhrjkKVB2MvM=.8b3d7ad7-7f9e-4e82-8189-3767ed5e1188@github.com>

> Some static final arrays of BigInteger and BigDecimal are stable and immutable. We should add `@Stable` to give the optimizer more information

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  BigInteger::mag remove Stable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25437/files
  - new: https://git.openjdk.org/jdk/pull/25437/files/11e31614..4e9be2c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25437&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25437&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25437.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25437/head:pull/25437

PR: https://git.openjdk.org/jdk/pull/25437

From swen at openjdk.org  Fri May 30 22:23:52 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 30 May 2025 22:23:52 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal [v2]
In-Reply-To: <VxyY6tC-siH_6C0HrNpIIvBJ-tPlmJKEqSW7ioK51m8=.b85fd988-3ac6-416a-a7fd-8cdca298b8af@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
 <lp1xFhlZNmOPvbkAsqk1nWHA_edVtGbkbryGXZGwjTg=.e824710a-4cac-48ea-a65c-3ddabfa27a22@github.com>
 <VxyY6tC-siH_6C0HrNpIIvBJ-tPlmJKEqSW7ioK51m8=.b85fd988-3ac6-416a-a7fd-8cdca298b8af@github.com>
Message-ID: <_TTbaqxnk9iDRAkGkRp3YFGsuTX87abbtfEP2X3iqlE=.af987502-4705-4273-bbb5-8505d3534fda@github.com>

On Fri, 30 May 2025 21:36:52 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   bug fix, from @minborg
>
> src/java.base/share/classes/java/math/BigInteger.java line 192:
> 
>> 190:      * zero-length mag array.
>> 191:      */
>> 192:     @Stable
> 
> `BigInteger.mag` gets?written?to a?few?times during?computation in?`BigInteger?.largePrime(?)`: <https://github.com/openjdk/jdk/blob/db340e54f83cf7bf72abb94c9cf9cdac007ed38a/src/java.base/share/classes/java/math/BigInteger.java#L886-L887><https://github.com/openjdk/jdk/blob/db340e54f83cf7bf72abb94c9cf9cdac007ed38a/src/java.base/share/classes/java/math/BigInteger.java#L895-L898>

BigInteger is an object that is considered immutable, but its field mag is actually changed. This is incredible and should be fixed here. It is easy to make mistakes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25437#discussion_r2116798328

From smarks at openjdk.org  Fri May 30 22:42:55 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 30 May 2025 22:42:55 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications
In-Reply-To: <YvprZuG2_lOwGt6H-9pcOgg_SNHw85U6utbxqOAZSj8=.a072cd58-0b55-4742-a461-da6c7390476b@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
 <YvprZuG2_lOwGt6H-9pcOgg_SNHw85U6utbxqOAZSj8=.a072cd58-0b55-4742-a461-da6c7390476b@github.com>
Message-ID: <4faSWDqiU2cLVcamZplKIYILnPNPrGPAO-k29SAZJmg=.b737ccfc-db5f-4f62-9d1a-a0de6a1b1b7f@github.com>

On Fri, 30 May 2025 02:33:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> For a full explanation, see the bug report [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015).
>> 
>> This PR includes three related changes:
>> * New overrides in SequencedMap view collection implementations, which improve their behavior.
>> * Update to `@implSpec` clauses to reflect this behavior (which was previously ill-specified).
>> * Update to a test which relied on unspecified behavior.
>
> src/java.base/share/classes/java/util/AbstractMap.java line 881:
> 
>> 879:         UnsupportedOperationException uoe() { return new UnsupportedOperationException(); }
>> 880:         // convert null entry return values into NSEE
>> 881:         <T> T nsee(T entry) {
> 
> Suggestion:
> 
>         <T extends Map.Entry<?, ?>> T nsee(T entry) {
> 
> So we don't accidentally use this on map keys or values.

Reasonable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25515#discussion_r2116830360

From smarks at openjdk.org  Fri May 30 22:42:53 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 30 May 2025 22:42:53 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications
In-Reply-To: <q8Dqv_CIAVnQD-dx1Ykk4Dqa-ALHXAFOO5gtjtDJkSc=.bf889821-c934-4d1c-ba6d-b53d39930ecc@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
 <q8Dqv_CIAVnQD-dx1Ykk4Dqa-ALHXAFOO5gtjtDJkSc=.bf889821-c934-4d1c-ba6d-b53d39930ecc@github.com>
Message-ID: <pa-1TLvASBKE7MHoFgpiDLIfNeAo8pFdUcX4dv485WI=.2771af18-201d-4ebb-9079-9126f155c0d9@github.com>

On Thu, 29 May 2025 19:44:20 GMT, ExE Boss <duke at openjdk.org> wrote:

>> For a full explanation, see the bug report [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015).
>> 
>> This PR includes three related changes:
>> * New overrides in SequencedMap view collection implementations, which improve their behavior.
>> * Update to `@implSpec` clauses to reflect this behavior (which was previously ill-specified).
>> * Update to a test which relied on unspecified behavior.
>
> src/java.base/share/classes/java/util/AbstractMap.java line 881:
> 
>> 879:         UnsupportedOperationException uoe() { return new UnsupportedOperationException(); }
>> 880:         // convert null entry return values into NSEE
>> 881:         <T> T nsee(T entry) {
> 
> This?method can?be?static:
> Suggestion:
> 
>         static <T> T nsee(T entry) {

Huh, unqualified call to inherited static method. I guess that's ok.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25515#discussion_r2116830124

From liach at openjdk.org  Fri May 30 22:44:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 May 2025 22:44:51 GMT
Subject: RFR: 8357823: Changes in StringBuilder (JDK-8351443) caused a 1-3%
 regression in biojava
In-Reply-To: <EqrJvAzbQYoe6SnQhsy9_KmtAhqJI4jGMaHOztKb0n8=.99ee9a06-04d4-499b-976c-74da3314f4b5@github.com>
References: <EqrJvAzbQYoe6SnQhsy9_KmtAhqJI4jGMaHOztKb0n8=.99ee9a06-04d4-499b-976c-74da3314f4b5@github.com>
Message-ID: <T97QMfZUlMX9TAaEhM9q5kL33nbB1O8BM3tpbfU2ppY=.8c939ab9-206a-4f04-80ae-de9a0d06c410@github.com>

On Fri, 30 May 2025 14:01:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Comment out assertions added in JDK-8351443 from AbstractStringBuilder.ensureCapacityNewCoder that increase the codesize, preventing some inlining, and reducing performance
> 
>        assert coder == newCoder || newCoder == UTF16 : "bad new coder UTF16 -> LATIN1";
>        assert count <= newCapacity : "count exceeds new capacity";

In javap output, BCI 0-28 and 59-81 are the two assertions. Total code size is 125, and the no-assertion size is 75. Is there any hotspot limit in these two number reached as a result of these two assertions?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25550#issuecomment-2923667909

From smarks at openjdk.org  Fri May 30 22:48:52 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 30 May 2025 22:48:52 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications
In-Reply-To: <ko-_7VW-GjnQeNrq52gGF91R7pdLffG0hcu62tjRkWI=.56fafc4b-d6ec-4c2c-be6c-6bcacceb8b09@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
 <ko-_7VW-GjnQeNrq52gGF91R7pdLffG0hcu62tjRkWI=.56fafc4b-d6ec-4c2c-be6c-6bcacceb8b09@github.com>
Message-ID: <6mQp01NOcgsM058nvgcbZDUGCmu6HyBuht9dVEm2EEs=.f71ac6bd-852b-43ce-ac87-f8fb0fdf6f12@github.com>

On Fri, 30 May 2025 14:33:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> For a full explanation, see the bug report [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015).
>> 
>> This PR includes three related changes:
>> * New overrides in SequencedMap view collection implementations, which improve their behavior.
>> * Update to `@implSpec` clauses to reflect this behavior (which was previously ill-specified).
>> * Update to a test which relied on unspecified behavior.
>
> src/java.base/share/classes/java/util/SequencedMap.java line 271:
> 
>> 269:      * Its {@link SequencedSet#getFirst getFirst} and {@link SequencedSet#getLast getLast}
>> 270:      * methods are implemented in terms of the {@link #firstEntry firstEntry} and {@link
>> 271:      * #lastEntry lastEntry} methods of this class, respectively. Its {@link
> 
> Hello Stuart, some parts of this and other updated method docs use "this interface", "this map", "this class". Was it intentional to use "this class" in this newly added text?

Good point. The other `@implSpec` clauses here all say "this interface" so I'll change the newly added "this class" to "this interface" in order to try to avoid confusion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25515#discussion_r2116834181

From smarks at openjdk.org  Fri May 30 23:13:50 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 30 May 2025 23:13:50 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications
In-Reply-To: <8mVKzQ7NxFGFVdGLfpG3vGyDRaY4lHBfCNFHd5bwntg=.849ed26b-8e15-4bc6-aef7-c167743b7901@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
 <ko-_7VW-GjnQeNrq52gGF91R7pdLffG0hcu62tjRkWI=.56fafc4b-d6ec-4c2c-be6c-6bcacceb8b09@github.com>
 <8mVKzQ7NxFGFVdGLfpG3vGyDRaY4lHBfCNFHd5bwntg=.849ed26b-8e15-4bc6-aef7-c167743b7901@github.com>
Message-ID: <-ywNsPqPnBJJt6U30ytoYA85hAhfahq64FlKNpiT-0Y=.eb36e7d0-8bf4-42a5-bfeb-f5de8dbbc967@github.com>

On Fri, 30 May 2025 14:38:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Overall this looks good to me. I just have a small question about the newly introduced text.
>> 
>> The copyright years on BasicMap.java and SequencedMap.java will need a update before integrating.
>
>> I just have a small question about the newly introduced text.
> 
> I just realized one other thing - the updated BasicMap.java fixes an issue in an existing test. Do we already have tests that might cover the new proposed semantics of these methods on the returned Set/Collection from the `SequencedMap.sequencedEntrySet/sequencedKeySet/sequenceValues`? Or should those be added?

@jaikiran

> Do we already have tests that might cover the new proposed semantics of these methods on the returned Set/Collection from the SequencedMap.sequencedEntrySet/sequencedKeySet/sequenceValues?

Good question. There are several existing tests in BasicMap.java; see checkKeySet, checkValues, and checkEntrySet. There is also a set of tests starting at testKeySetRemoves and following which test removals on several variations of the map views, and also other mutator methods. I don't see anything obvious missing, but that doesn't mean everything is actually tested! Probably at some point it would be good to do a comprehensive analysis of the collections tests and see if they can be unified. We should probably take a look at the test coverage report too. But this is all about functional testing, in the sense of: starting from this state and performing this operation, do we get the right results and side effects? (This is mostly _state verification_.)

The stuff in `@implSpec` that specifies *how* something is done might not be tested. In this case the implementation was done using method A and the `@implSpec` modified to require method B. The test made some unwarranted assumptions about the behavior of method A (which actually was unspecified) that in fact was not supported by method B; and so the test failed. Otherwise I probably wouldn't have noticed this. In general I don't think we don't do much _behavior_ verification in the JDK. If we do it's pretty ad hoc. In this case the question is, is there a test that verifies that a particular method is implemented by calling method B? I don't think so.

The terms _state verification_ and _behavior verification_ come from here:

https://martinfowler.com/articles/mocksArentStubs.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25515#issuecomment-2923697259

From smarks at openjdk.org  Sat May 31 00:47:16 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 31 May 2025 00:47:16 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications [v2]
In-Reply-To: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
Message-ID: <8gPP7kpzcCSz8A4o0eCUrDhJRqC_atLNvhu87K3wF_Y=.2a49957a-f2bb-40a5-a091-97d634e06457@github.com>

> For a full explanation, see the bug report [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015).
> 
> This PR includes three related changes:
> * New overrides in SequencedMap view collection implementations, which improve their behavior.
> * Update to `@implSpec` clauses to reflect this behavior (which was previously ill-specified).
> * Update to a test which relied on unspecified behavior.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Tweak nsee() declaration; adjust specs per suggestion; update copyrights.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25515/files
  - new: https://git.openjdk.org/jdk/pull/25515/files/ee8f784e..ff9fe9ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25515&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25515&range=00-01

  Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25515.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25515/head:pull/25515

PR: https://git.openjdk.org/jdk/pull/25515

From epeter at openjdk.org  Sat May 31 11:02:00 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Sat, 31 May 2025 11:02:00 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v4]
In-Reply-To: <TKma1AJWRWYjH4SZ4N2CTukn1yXtu_wfACG0dTbTRFg=.e2e27f2c-e4cc-4bf8-9a04-2985dc007002@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <72GCipLKeCWCG-4jsG5XhZKkTdVsWafEq_wA0oD-0mk=.c70af814-54fe-43d2-b7c9-72b845eb99d5@github.com>
 <kPx9NqOgNJPStCsPd4PtRhfbQeEXi5xbefvSjCHoPSY=.aa26a490-8f90-4e17-8c9e-cde0c25a9fbb@github.com>
 <TKma1AJWRWYjH4SZ4N2CTukn1yXtu_wfACG0dTbTRFg=.e2e27f2c-e4cc-4bf8-9a04-2985dc007002@github.com>
Message-ID: <jXKLVg4kNAire2Uydf62b7kCXKF9hLsRNfDtEQmvSdw=.09a866b9-57d2-423c-9d54-166da1ca1205@github.com>

On Thu, 29 May 2025 22:30:57 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> Patch looks good to me,  some comment included.
>
> @jatin-bhateja Please let me know if there's anything else to address.

@missa-prime The patch looks reasonable. It would have been nice if we (from Oracle) could have tested it before integration, especially this close to RDP1 for JDK25. Just for next time. If there are issues with it now, you risk that it gets backed out, and you have to redo it, and it does not make it into JDK25.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2924944778

From jpai at openjdk.org  Sat May 31 12:58:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 31 May 2025 12:58:51 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications [v2]
In-Reply-To: <8gPP7kpzcCSz8A4o0eCUrDhJRqC_atLNvhu87K3wF_Y=.2a49957a-f2bb-40a5-a091-97d634e06457@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
 <8gPP7kpzcCSz8A4o0eCUrDhJRqC_atLNvhu87K3wF_Y=.2a49957a-f2bb-40a5-a091-97d634e06457@github.com>
Message-ID: <6IA24vwG6uodVg2oR2vVskCl8sjOPnivX5yEU2Oot0Y=.bfdf4ad8-bec0-4fd6-94ab-56647ddbc362@github.com>

On Sat, 31 May 2025 00:47:16 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> For a full explanation, see the bug report [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015).
>> 
>> This PR includes three related changes:
>> * New overrides in SequencedMap view collection implementations, which improve their behavior.
>> * Update to `@implSpec` clauses to reflect this behavior (which was previously ill-specified).
>> * Update to a test which relied on unspecified behavior.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak nsee() declaration; adjust specs per suggestion; update copyrights.

Hello Stuart, thank you for the updates. These look good to me.

As for the testing, you are right that behaviour testing where method A calls B and such isn't usually tested in the JDK. I think that's fine. I was unclear about what testing I was talking about in my previous comment. I was mostly curious whether we had tests to verify that the `getFirst()/getLast()` `EntrySet` returned through a `SequencedMap.sequencedEntrySet()` does indeed prevent a `setValue()` call.

I had a look at the existing `BasicMap.java` and it does appear that we already have tests to verify that behaviour (the method `checkUnmodifiableEntry()`). So I think this change has the necessary test coverage.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25515#pullrequestreview-2884063760

From egahlin at openjdk.org  Sat May 31 13:18:44 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sat, 31 May 2025 13:18:44 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
Message-ID: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>

Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).

Testing: test/jdk/jdk/jfr

Thanks
Erik

-------------

Commit messages:
 - Consistent annotation
 - Fix typos
 - Fix whitespace
 - Initial

Changes: https://git.openjdk.org/jdk/pull/25559/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351594
  Stats: 1230 lines in 37 files changed: 1028 ins; 87 del; 115 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From jpai at openjdk.org  Sat May 31 13:25:32 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 31 May 2025 13:25:32 GMT
Subject: RFR: 8358218: Problemlist
 jdk/incubator/vector/PreferredSpeciesTest.java#id0
Message-ID: <QsMSNRQcqMrWBf1yZ-g3x4GHJuHp8Pn-lzy6y6mM8pw=.df134150-1916-4e21-a488-04f2044f2744@github.com>

Can I please get a review of this change which fixes the problem listing entry for the `jdk/incubator/vector/PreferredSpeciesTest.java#id0` test which has been failing in our CI?

tier1 testing with this change is currently in progress to verify that this test is excluded from execution. I'll integrate this once that completes.

-------------

Commit messages:
 - 8358218: Problemlist jdk/incubator/vector/PreferredSpeciesTest.java#id0

Changes: https://git.openjdk.org/jdk/pull/25564/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25564&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358218
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25564.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25564/head:pull/25564

PR: https://git.openjdk.org/jdk/pull/25564

From igraves at openjdk.org  Sat May 31 13:25:32 2025
From: igraves at openjdk.org (Ian Graves)
Date: Sat, 31 May 2025 13:25:32 GMT
Subject: RFR: 8358218: Problemlist
 jdk/incubator/vector/PreferredSpeciesTest.java#id0
In-Reply-To: <QsMSNRQcqMrWBf1yZ-g3x4GHJuHp8Pn-lzy6y6mM8pw=.df134150-1916-4e21-a488-04f2044f2744@github.com>
References: <QsMSNRQcqMrWBf1yZ-g3x4GHJuHp8Pn-lzy6y6mM8pw=.df134150-1916-4e21-a488-04f2044f2744@github.com>
Message-ID: <D-KgZjIteBvynLfzd3-lKbJtzdgnPu0OqxJXW1XemxU=.4da4480a-16ec-4b84-9f16-eaf7a9673f6e@github.com>

On Sat, 31 May 2025 13:14:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the problem listing entry for the `jdk/incubator/vector/PreferredSpeciesTest.java#id0` test which has been failing in our CI?
> 
> tier1 testing with this change is currently in progress to verify that this test is excluded from execution. I'll integrate this once that completes.

Looks good. Thanks @jaikiran

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25564#issuecomment-2925175196

From tvaleev at openjdk.org  Sat May 31 14:19:09 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 31 May 2025 14:19:09 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v6]
In-Reply-To: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
Message-ID: <2Z9xNzKsRpHZ7zzJ76JvCsV2zZHDpUftGEOedX_cd_o=.7ac6eb1a-af40-4ab3-9711-2c54876cf6b5@github.com>

> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
> 
> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
> 
> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Update @since tag to version 26, as it's too late to fit this change into 25

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25297/files
  - new: https://git.openjdk.org/jdk/pull/25297/files/293b2c40..a2788651

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25297.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25297/head:pull/25297

PR: https://git.openjdk.org/jdk/pull/25297

From jpai at openjdk.org  Sat May 31 15:21:49 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 31 May 2025 15:21:49 GMT
Subject: RFR: 8358218: Problemlist
 jdk/incubator/vector/PreferredSpeciesTest.java#id0
In-Reply-To: <QsMSNRQcqMrWBf1yZ-g3x4GHJuHp8Pn-lzy6y6mM8pw=.df134150-1916-4e21-a488-04f2044f2744@github.com>
References: <QsMSNRQcqMrWBf1yZ-g3x4GHJuHp8Pn-lzy6y6mM8pw=.df134150-1916-4e21-a488-04f2044f2744@github.com>
Message-ID: <fjs6p15MLG-jmF69cLMgcZXua86blG9RdbvIF_MuSVI=.e6284954-bcd9-41bc-9e76-76d1b4c4a2d6@github.com>

On Sat, 31 May 2025 13:14:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the problem listing entry for the `jdk/incubator/vector/PreferredSpeciesTest.java#id0` test which has been failing in our CI?
> 
> tier1 testing with this change is currently in progress to verify that this test is excluded from execution. I'll integrate this once that completes.

Thank you Ian for the review. tier1 and tier3 testing of this problem listing change went fine in our CI and I've verified that this test no longer executes.

This PR will need an approval for a Reviewer (capital R). To help prevent tier1 failures in the CI, I'll mark this PR as "integrate delegate" so that once approved, it can then be integrated by any Committer or Reviewer (https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/integrate)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25564#issuecomment-2925323586

From psandoz at openjdk.org  Sat May 31 16:28:50 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Sat, 31 May 2025 16:28:50 GMT
Subject: RFR: 8358218: Problemlist
 jdk/incubator/vector/PreferredSpeciesTest.java#id0
In-Reply-To: <QsMSNRQcqMrWBf1yZ-g3x4GHJuHp8Pn-lzy6y6mM8pw=.df134150-1916-4e21-a488-04f2044f2744@github.com>
References: <QsMSNRQcqMrWBf1yZ-g3x4GHJuHp8Pn-lzy6y6mM8pw=.df134150-1916-4e21-a488-04f2044f2744@github.com>
Message-ID: <0ssGbY_ujlC-lFJZN8XUUwxLMDOXl6OZ2TBMyxktQdE=.c608a591-9ac6-41be-b65f-9db7d183fe9d@github.com>

On Sat, 31 May 2025 13:14:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the problem listing entry for the `jdk/incubator/vector/PreferredSpeciesTest.java#id0` test which has been failing in our CI?
> 
> tier1 testing with this change is currently in progress to verify that this test is excluded from execution. I'll integrate this once that completes.

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25564#pullrequestreview-2884302439

From igraves at openjdk.org  Sat May 31 16:32:01 2025
From: igraves at openjdk.org (Ian Graves)
Date: Sat, 31 May 2025 16:32:01 GMT
Subject: RFR: 8358217: jdk/incubator/vector/PreferredSpeciesTest.java#id0
 failures - expected [128] but found [256]
Message-ID: <3e872OAhOzIPD2H_NVh3BdB_ea2LIFemxzAoJ7bZ190=.6e962666-502b-428e-a3a4-452cfbddb8ad@github.com>

Removing incorrect assumptions and assertions from a breaking test related to https://bugs.openjdk.org/browse/JDK-8358218

-------------

Commit messages:
 - Removing incorrect assumptions from test

Changes: https://git.openjdk.org/jdk/pull/25565/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25565&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358217
  Stats: 13 lines in 2 files changed: 0 ins; 13 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25565/head:pull/25565

PR: https://git.openjdk.org/jdk/pull/25565

From igraves at openjdk.org  Sat May 31 16:32:01 2025
From: igraves at openjdk.org (Ian Graves)
Date: Sat, 31 May 2025 16:32:01 GMT
Subject: RFR: 8358217: jdk/incubator/vector/PreferredSpeciesTest.java#id0
 failures - expected [128] but found [256]
In-Reply-To: <3e872OAhOzIPD2H_NVh3BdB_ea2LIFemxzAoJ7bZ190=.6e962666-502b-428e-a3a4-452cfbddb8ad@github.com>
References: <3e872OAhOzIPD2H_NVh3BdB_ea2LIFemxzAoJ7bZ190=.6e962666-502b-428e-a3a4-452cfbddb8ad@github.com>
Message-ID: <GPVMHINPOvR74GM2ng1ehUm9w7LJuoWOQpSsJ0cGvmg=.08da61b2-ba73-4c30-82c9-11d2c0874006@github.com>

On Sat, 31 May 2025 16:18:59 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Removing incorrect assumptions and assertions from a breaking test related to https://bugs.openjdk.org/browse/JDK-8358218

The original test made an incorrect assumption about *MaxVector sizes that doesn't hold across every platform. The assertion based on this is now removed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25565#issuecomment-2925399904

From jpai at openjdk.org  Sat May 31 16:33:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 31 May 2025 16:33:55 GMT
Subject: RFR: 8358218: Problemlist
 jdk/incubator/vector/PreferredSpeciesTest.java#id0
In-Reply-To: <QsMSNRQcqMrWBf1yZ-g3x4GHJuHp8Pn-lzy6y6mM8pw=.df134150-1916-4e21-a488-04f2044f2744@github.com>
References: <QsMSNRQcqMrWBf1yZ-g3x4GHJuHp8Pn-lzy6y6mM8pw=.df134150-1916-4e21-a488-04f2044f2744@github.com>
Message-ID: <e-SfPdAwEe5i6ysNxklsDonkhCRH4SC_IoCgFmwyqd4=.2d74ede6-ba4b-4d3c-aa56-7f0906e60f26@github.com>

On Sat, 31 May 2025 13:14:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the problem listing entry for the `jdk/incubator/vector/PreferredSpeciesTest.java#id0` test which has been failing in our CI?
> 
> tier1 testing with this change is currently in progress to verify that this test is excluded from execution. I'll integrate this once that completes.

Thank you Paul for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25564#issuecomment-2925410387

From jpai at openjdk.org  Sat May 31 16:33:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 31 May 2025 16:33:55 GMT
Subject: Integrated: 8358218: Problemlist
 jdk/incubator/vector/PreferredSpeciesTest.java#id0
In-Reply-To: <QsMSNRQcqMrWBf1yZ-g3x4GHJuHp8Pn-lzy6y6mM8pw=.df134150-1916-4e21-a488-04f2044f2744@github.com>
References: <QsMSNRQcqMrWBf1yZ-g3x4GHJuHp8Pn-lzy6y6mM8pw=.df134150-1916-4e21-a488-04f2044f2744@github.com>
Message-ID: <KK1xRiv5dFOqGmSZPnlAiA-Vx6zDdzmhejzEjaSjQas=.2cd0d3a0-7ff5-45d9-8b8c-d303277d21e2@github.com>

On Sat, 31 May 2025 13:14:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the problem listing entry for the `jdk/incubator/vector/PreferredSpeciesTest.java#id0` test which has been failing in our CI?
> 
> tier1 testing with this change is currently in progress to verify that this test is excluded from execution. I'll integrate this once that completes.

This pull request has now been integrated.

Changeset: a3f9e222
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3f9e222632d29982ef1463e6c391d5896524705
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8358218: Problemlist jdk/incubator/vector/PreferredSpeciesTest.java#id0

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/25564

From igraves at openjdk.org  Sat May 31 17:27:30 2025
From: igraves at openjdk.org (Ian Graves)
Date: Sat, 31 May 2025 17:27:30 GMT
Subject: RFR: 8358217: jdk/incubator/vector/PreferredSpeciesTest.java#id0
 failures - expected [128] but found [256] [v2]
In-Reply-To: <3e872OAhOzIPD2H_NVh3BdB_ea2LIFemxzAoJ7bZ190=.6e962666-502b-428e-a3a4-452cfbddb8ad@github.com>
References: <3e872OAhOzIPD2H_NVh3BdB_ea2LIFemxzAoJ7bZ190=.6e962666-502b-428e-a3a4-452cfbddb8ad@github.com>
Message-ID: <4IACB2JbB8Dik4VZTQA-68HoODNpfA25v1bBiMD4feM=.2ddc0a45-d1fe-424a-9d2d-99d628cc4c3c@github.com>

> Removing incorrect assumptions and assertions from a breaking test related to https://bugs.openjdk.org/browse/JDK-8358218

Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge remote-tracking branch 'upstream/master' into JDK-8358217
 - Removing incorrect assumptions from test

-------------

Changes: https://git.openjdk.org/jdk/pull/25565/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25565&range=01
  Stats: 13 lines in 2 files changed: 0 ins; 13 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25565/head:pull/25565

PR: https://git.openjdk.org/jdk/pull/25565

From cushon at openjdk.org  Sat May 31 19:22:53 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Sat, 31 May 2025 19:22:53 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v11]
In-Reply-To: <-CogplhO9R_2nYsRRhV1mFWADNbMYZIV-21uyoK5oIk=.08d0dfe2-3334-4791-a601-1450170124d2@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
 <qlYT62TEeCz9YVp02zeuJCO30kAZyzBgV2ENjURIJrw=.44ab01cb-9fe3-45a4-af51-6468a0f625ab@github.com>
 <80zHlzRZjXsszgvNxex1QXSfwByc8IrT_g7SSizKaqc=.e5d9de30-ab93-49dc-8e99-5b30406c4bfe@github.com>
 <e3MivsEbC85A8GS1zNhWyHAahMxdO_KKXjeSDJjGD10=.7e64e52f-b055-4783-aad2-c771ca6bfe5f@github.com>
 <-CogplhO9R_2nYsRRhV1mFWADNbMYZIV-21uyoK5oIk=.08d0dfe2-3334-4791-a601-1450170124d2@github.com>
Message-ID: <l3GkLs1y1G_913fdLQa2_1CiuuoHRKUevbm-quNDuS4=.ca5cca0f-3551-480f-bfca-aa790a0fcdd5@github.com>

On Fri, 30 May 2025 04:21:26 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> [JDK-8316493](https://bugs.openjdk.org/browse/JDK-8316493) (remove caching fields in AbstractMap)

I tested that one over Google's codebase, and unlike this change where there was no observable compatibility impact, I did see some breakages related to JDK-8316493. I left [a comment in the CSR](https://bugs.openjdk.org/browse/JDK-8316583?focusedId=14785229&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14785229).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2925618911

From mgronlun at openjdk.org  Sat May 31 20:15:50 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 20:15:50 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <Pb7W24qpASuvcdw8ElmNW-RubVkddYTqvzDQPGCvvrw=.6bec04d0-5dc0-493f-8ebd-d1595f3c4946@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/Throttle.java line 39:

> 37:  * example, {@code "100/s"}).
> 38:  * <p>
> 39:  * If the event class annotated with {@code Throttle} are filtered by other

"is filtered"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118216821

From mgronlun at openjdk.org  Sat May 31 20:19:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 20:19:51 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <99eWsd--g2GrdhR2r9_HY7JMWK2RZJZ7ahwatYCvXU4=.50bb0e3f-5ee2-41b7-bf66-0d83e8d08c52@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/ClassInspector.java line 148:

> 146:             return true;
> 147:         }
> 148:         if (superClass != null) {

Does this also need to search superClass's super?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118221175

From mgronlun at openjdk.org  Sat May 31 21:12:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 21:12:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <vKdKE5fLsvlLISgHCtv-hd4fsDPY9ziU6odImrFsAGM=.441615c8-e981-46fd-9a37-39218703002e@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 256:

> 254:             // }
> 255:             getEventConfiguration(codeBuilder);
> 256:             codeBuilder.aload(0);

Can issue a dup() here if you want to avoid the second aload(0).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118257554

From mgronlun at openjdk.org  Sat May 31 21:17:50 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 21:17:50 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <Dbuu94cHaFlQPlttifkqqPt53bkI1_7PouvQlThOw40=.f7a88efa-c25a-408d-8fc8-4d4ac6d74898@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 257:

> 255:             getEventConfiguration(codeBuilder);
> 256:             codeBuilder.aload(0);
> 257:             getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_START_TIME);

In native,we use the endTime for duration events? Is there a need to synchronize the two?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118261907

From mgronlun at openjdk.org  Sat May 31 21:27:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 21:27:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <o_6aEWGcuMA1YtNY7EhcwJalOJpRE5kuF1KxVLnJiuM=.ae6ae3bb-162b-4776-b2a9-e0c4dcb0d482@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 261:

> 259:             getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_DURATION);
> 260:             Bytecode.invokevirtual(codeBuilder, TYPE_EVENT_CONFIGURATION, METHOD_THROTTLE);
> 261:             int result = codeBuilder.allocateLocal(TypeKind.LONG);

Do we really need to store the result in a local? Can't we just dup it on the expression stack and store it directly into the field after another aload, or dup? Perhaps dup twice to then issue the mask operation?

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 590:

> 588:     private void setDuration(CodeBuilder codeBuilder, Consumer<CodeBuilder> expression) {
> 589:         codeBuilder.aload(0);
> 590:         expression.accept(codeBuilder);

dont know what expression.accept() does, but does it really consume the this pointer? I see its pushed again (aload(0)) if its throttled below?

src/jdk.jfr/share/classes/jdk/jfr/internal/event/EventConfiguration.java line 59:

> 57:     // static boolean shouldThrottleCommit(long timestamp)
> 58:     public boolean shouldThrottleCommit(long timestamp) {
> 59:         return throttler.sample(timestamp);

Can we assert on isEnabled?

src/jdk.jfr/share/classes/jdk/jfr/internal/event/EventConfiguration.java line 77:

> 75:             return rawDuration;
> 76:         }
> 77:         long endTime = startTime + rawDuration;

I see now that you are using endTime as well, nice.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118272073
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118272829
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118277498
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118279057

From mgronlun at openjdk.org  Sat May 31 21:38:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 21:38:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <i-9qmnjV-4cag2uwXDkuIsfyZKhgx8vm_wJHJinIz1Y=.8b8466a6-8e87-4327-87ee-b3fdb6591af2@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 62:

> 60:     // Not synchronized in fast path, but uses volatile reads.
> 61:     public boolean sample(long ticks) {
> 62:         if (disabled) {

This volatile load is somewhat disappointing. Do you think it is needed? What happens if it is read without happens-before? It just creates an event that will most likely get discarded by the recorder engine on reset (if its set on setting update). If it's set to disabled, then the recorder engine has most likely stopped already, so the event will be discarded. Event settings are set with no visibility guarantees as to exact when they apply, so it should not really matter when it goes to disabled.

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 74:

> 72:                 }
> 73:             }
> 74:             return activeWindow.sample();

In native, a ticks value outside of the window is not returned true.

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 76:

> 74:             return activeWindow.sample();
> 75:         }
> 76:         return current.sample();

This could result in sampling in an already expired window.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118281909
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118282232
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118283830