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