From hgreule at openjdk.org  Sun Jun  1 06:08:29 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Sun, 1 Jun 2025 06:08:29 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file
Message-ID: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>

This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.

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

Commit messages:
 - fix
 - test

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

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

From alanb at openjdk.org  Sun Jun  1 06:20:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 1 Jun 2025 06:20:59 GMT
Subject: Integrated: 8357637: Native resources cached in thread locals not
 released when FJP common pool threads clears thread locals
In-Reply-To: <VkaaMk0C7JSAVllqHevQxu7Fvf0QruJOJikxzgmERs0=.a80e982f-1de0-4b5d-a7ee-adbb40b94aa8@github.com>
References: <VkaaMk0C7JSAVllqHevQxu7Fvf0QruJOJikxzgmERs0=.a80e982f-1de0-4b5d-a7ee-adbb40b94aa8@github.com>
Message-ID: <R_aijAcNNvARThZlUpiUcu5v9cW1xljdl0EfBa6NB8M=.bbfa0656-bed9-410f-92c2-3f77ca519d62@github.com>

On Mon, 26 May 2025 17:16:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A ForkJoinPool can be created with worker threads that clear thread locals between tasks, thus avoiding a build up of thread locals left behind by tasks executed in the pool. The common pool does this. Erasing thread locals (by writing null to Thread.threadLocals) grinds with thread locals that keep native memory alive, esp. when there isn't a Cleaner or other means to free the memory.
> 
> For the JDK, this is currently an issue for the NIO direct buffer cache. If a task running on a thread in the common pool does socket or network channel I/O then it can leak when the task terminates. Prior to JDK 24 each buffer in the cache had a cleaner, as if allocated by ByteBuffer.allocateDirect, so it had some chance of being released. The changes in [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882) mean there is no longer is cleaner for buffers in the cache.
> 
> The options in the short term are to restore the cleaner, register a clearer for the buffer cache, have the FJP resetThreadLocals special case "terminating thread locals", or move the terminating thread locals to a different TL map. Viktor Klang, Doug Lea, and I discussed this topic recently and agreed the best short term approach is to split the map. As terminating thread locals are for platform threads then the map can be in the Thread.FieldHolder and avoid adding another field to Thread. Medium to long term require further thought in this area, including seeing what might be useful (and safe) to expose.
> 
> Testing 1-5. Performance testing ongoing.

This pull request has now been integrated.

Changeset: ac9af69e
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac9af69eee9636ff98c2b60224964e518aebb421
Stats:     149 lines in 9 files changed: 89 ins; 37 del; 23 mod

8357637: Native resources cached in thread locals not released when FJP common pool threads clears thread locals

Reviewed-by: vklang

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

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

From syan at openjdk.org  Sun Jun  1 09:24:52 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 1 Jun 2025 09:24:52 GMT
Subject: RFR: 8358217: jdk/incubator/vector/PreferredSpeciesTest.java#id0
 failures - expected [128] but found [256] [v2]
In-Reply-To: <4IACB2JbB8Dik4VZTQA-68HoODNpfA25v1bBiMD4feM=.2ddc0a45-d1fe-424a-9d2d-99d628cc4c3c@github.com>
References: <3e872OAhOzIPD2H_NVh3BdB_ea2LIFemxzAoJ7bZ190=.6e962666-502b-428e-a3a4-452cfbddb8ad@github.com>
 <4IACB2JbB8Dik4VZTQA-68HoODNpfA25v1bBiMD4feM=.2ddc0a45-d1fe-424a-9d2d-99d628cc4c3c@github.com>
Message-ID: <T1ZIdBzSZdNN46gmXTx-WIam3LxmVu7ghlJ3T1wgnGU=.110a42a6-197e-4519-9848-07dde967caba@github.com>

On Sat, 31 May 2025 17:27:30 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> Removing incorrect assumptions and assertions from a breaking test related to https://bugs.openjdk.org/browse/JDK-8358218
>
> Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8358217
>  - Removing incorrect assumptions from test

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25565#pullrequestreview-2885374307

From egahlin at openjdk.org  Sun Jun  1 13:12:00 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 1 Jun 2025 13:12:00 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <Pb7W24qpASuvcdw8ElmNW-RubVkddYTqvzDQPGCvvrw=.6bec04d0-5dc0-493f-8ebd-d1595f3c4946@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Pb7W24qpASuvcdw8ElmNW-RubVkddYTqvzDQPGCvvrw=.6bec04d0-5dc0-493f-8ebd-d1595f3c4946@github.com>
Message-ID: <KxlQQTym19WULE3miG6oD_hV6Zh4mSlw1zRHCswk0Eg=.82623696-1fac-4294-a187-07956c424814@github.com>

On Sat, 31 May 2025 20:13:01 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> src/jdk.jfr/share/classes/jdk/jfr/Throttle.java line 39:
> 
>> 37:  * example, {@code "100/s"}).
>> 38:  * <p>
>> 39:  * If the event class annotated with {@code Throttle} are filtered by other
> 
> "is filtered"

Will fix

> src/jdk.jfr/share/classes/jdk/jfr/internal/ClassInspector.java line 148:
> 
>> 146:             return true;
>> 147:         }
>> 148:         if (superClass != null) {
> 
> Does this also need to search superClass's super?

The annotation is inherited so  superClass's super will be included.

> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 256:
> 
>> 254:             // }
>> 255:             getEventConfiguration(codeBuilder);
>> 256:             codeBuilder.aload(0);
> 
> Can issue a dup() here if you want to avoid the second aload(0).

I don't think it will work because the result of the first getField (startTime) will be on the stack, when we issue the next getField (duration).

> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 257:
> 
>> 255:             getEventConfiguration(codeBuilder);
>> 256:             codeBuilder.aload(0);
>> 257:             getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_START_TIME);
> 
> In native,we use the endTime for duration events? Is there a need to synchronize the two?

The duration is added later, in throttle. There is no this.endTime field to read here.

> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 590:
> 
>> 588:     private void setDuration(CodeBuilder codeBuilder, Consumer<CodeBuilder> expression) {
>> 589:         codeBuilder.aload(0);
>> 590:         expression.accept(codeBuilder);
> 
> dont know what expression.accept() does, but does it really consume the this pointer? I see its pushed again (aload(0)) if its throttled below?

We need "this" on stack before the arguments are loaded in expression which is to be used at the end of the method by putfield

> src/jdk.jfr/share/classes/jdk/jfr/internal/event/EventConfiguration.java line 59:
> 
>> 57:     // static boolean shouldThrottleCommit(long timestamp)
>> 58:     public boolean shouldThrottleCommit(long timestamp) {
>> 59:         return throttler.sample(timestamp);
> 
> Can we assert on isEnabled?

Between the time of the enabled() check and this method, the state may change, so it could lead to false positives in testing.

> src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 62:
> 
>> 60:     // Not synchronized in fast path, but uses volatile reads.
>> 61:     public boolean sample(long ticks) {
>> 62:         if (disabled) {
> 
> This volatile load is somewhat disappointing. Do you think it is needed? What happens if it is read without happens-before? It just creates an event that will most likely get discarded by the recorder engine on reset (if its set on setting update). If it's set to disabled, then the recorder engine has most likely stopped already, so the event will be discarded. Event settings are set with no visibility guarantees as to exact when they apply, so it should not really matter when it goes to disabled.

I think we can skip it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119136217
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119135926
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119135820
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119134807
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119134400
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119132932
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119136976

From mgronlun at openjdk.org  Sun Jun  1 19:05:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 19:05:53 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <e6_OvsZFxNg64ypSkFBoDjvls1ijTSSdXgWS0Xx0VTU=.0a41a851-5870-47fd-866b-e52414125574@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 130:

> 128:     }
> 129: 
> 130:     private long amortizedDebt(ThrottlerWindow expired) {

amortizeDept (in the present) - like this is the value we will be using to amortize (in the future)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119457164

From yujige at gmail.com  Sun Jun  1 19:08:42 2025
From: yujige at gmail.com (Jige Yu)
Date: Sun, 1 Jun 2025 12:08:42 -0700
Subject: Should mapConcurrent() respect time order instead of input order?
Message-ID: <CAKD1RYuoK07OvAn02v4qq74Q1QDfpQpf=t0J0VT-s1zi4iKRnA@mail.gmail.com>

It seems like for most people, input order isn't that important for
concurrent work, and concurrent results being in non-deterministic order is
often expected.

If mapConcurrent() just respect output encounter order:

It'll be able to achieve *higher throughput* if an early task is slow, For
example, with concurrency=2, and if the first task takes 10 minutes to run,
mapConcurrent() would only be able to process 2 tasks within the first 10
minutes; whereas with encounter order, the first task being slow doesn't
block the 3rd - 100th elements from being processed and output.

mapConcurrent() can be used to implement useful concurrent semantics, for
example to *support race* semantics. Imagine if I need to send request to
10 candidate backends and take whichever that succeeds first, I'd be able
to do:

backends.stream()
    .gather(mapConcurrent(
        backend -> {
          try {
            return backend.fetchOrder();
           } catch (RpcException e) {
             return null; // failed to fetch but not fatal
           }
        })
        .filter(Objects::notNull)
        .findFirst(); // first success then cancel the rest


Cheers,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250601/ad1e5d31/attachment-0001.htm>

From mgronlun at openjdk.org  Sun Jun  1 19:10:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 19:10:51 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <FEIE0-ddPBZ6gsmBek0zuu2lPmoaQLWsz8h-BfMk5fM=.17498c82-6f01-46f6-b22d-1d63a2b011a2@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 148:

> 146:         return nextGeometric(adjustBoundary(projectProbability), randomGenerator.nextDouble());
> 147:     }
> 148:      double projectPopulationSize(ThrottlerWindow expired) {

not private?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119459623

From mgronlun at openjdk.org  Sun Jun  1 19:18:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 19:18:54 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <RlRa2RB5v1Qm646gChkE1yYwCT8WcKm10nqp2sdgMVk=.071fc361-fe53-43aa-9eeb-9ae1d62388e4@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 142:

> 140:     private long deriveSamplingInterval(double sampleSize, ThrottlerWindow expired) {
> 141:         double populationSize = projectPopulationSize(expired);
> 142:         if (adjustBoundary(populationSize) <= adjustBoundary(sampleSize)) {

Do you need all these adjustBoundary() calls? It only checks if a double value is 0 or 1. Population and sample sizes will be much larger.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119471003

From mgronlun at openjdk.org  Sun Jun  1 19:25:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 19:25:51 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <mldyqnpMWfzVdJXfKIrPjo4IUM4GBepsN-oCqS8ycfU=.9704ab37-e319-4289-ad1f-9e0dde646602@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottlerWindow.java line 49:

> 47:         measuredPopulationSize.set(0);
> 48:         endTicks = JVM.counterTime() +
> 49:         JVMSupport.nanosToTicks(1_000_000L * parameters.windowDurationMillis);

indent to make it clear it assigns.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119475462

From egahlin at openjdk.org  Sun Jun  1 20:56:50 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 1 Jun 2025 20:56:50 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <sdD_sCKqgIH47ozZr_JLBa38whUshwsAYpPhlb8YVbQ=.4dc670bc-2efd-4d73-a92b-982d40483d55@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Some reviewer feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/73943e7a..d0097506

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

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

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

From egahlin at openjdk.org  Sun Jun  1 21:10:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 1 Jun 2025 21:10:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <o_6aEWGcuMA1YtNY7EhcwJalOJpRE5kuF1KxVLnJiuM=.ae6ae3bb-162b-4776-b2a9-e0c4dcb0d482@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <o_6aEWGcuMA1YtNY7EhcwJalOJpRE5kuF1KxVLnJiuM=.ae6ae3bb-162b-4776-b2a9-e0c4dcb0d482@github.com>
Message-ID: <alGBSpA2d3llrqNVFIf8r5jDHTM517LXhzVO_r5XK3E=.28742e7a-e306-46d4-9533-683fdb8e80a4@github.com>

On Sat, 31 May 2025 21:20:17 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some reviewer feedback
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 261:
> 
>> 259:             getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_DURATION);
>> 260:             Bytecode.invokevirtual(codeBuilder, TYPE_EVENT_CONFIGURATION, METHOD_THROTTLE);
>> 261:             int result = codeBuilder.allocateLocal(TypeKind.LONG);
> 
> Do we really need to store the result in a local? Can't we just dup it on the expression stack and store it directly into the field after another aload, or dup? Perhaps dup twice to then issue the mask operation?

We could do an aload(0) at the beginning, before getEventConfiguration(codeBuilder), to have "this" for putfield(duration) later, but then we would need to do a getfield(this.duration) to have it on the stack for the mask.

We can't do a dup() on duration because we need "this" on the stack to store it in this.duration. I thought using a local variable would be faster than accessing this.duration. It also reduces the chance of the value being changed by another thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119593028

From liach at openjdk.org  Mon Jun  2 00:59:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Jun 2025 00:59:58 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file
In-Reply-To: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
Message-ID: <mgexeHo_EQZG4VII-fp7HjtfGQ6H5RkYnvSXeBlBDnw=.b1516902-2df4-4b14-a3af-63a81182bc90@github.com>

On Sun, 1 Jun 2025 04:53:46 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.

I recommend we fallback to use CFFV.latest() explicitly for now. FYI we will likely add a new CFFV for all preview features, which we will likely use as the default if we encounter an old preview class file. We can then swap latest() with that preview cffv.

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

PR Comment: https://git.openjdk.org/jdk/pull/25569#issuecomment-2928241509

From dholmes at openjdk.org  Mon Jun  2 02:11:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Jun 2025 02:11:57 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v6]
In-Reply-To: <sZVVm3lr1byp_brwwk80CWNovJIKZ4Mc_RvcRNIBBEI=.4f9e6ca0-108f-4e11-9e0c-f4b5bcf32482@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <sZVVm3lr1byp_brwwk80CWNovJIKZ4Mc_RvcRNIBBEI=.4f9e6ca0-108f-4e11-9e0c-f4b5bcf32482@github.com>
Message-ID: <Vua0yenFp1sDiTmOChgBc5fvYCdoByDo82MwLo1ikBI=.82d2bbe5-eb46-4cf8-acdc-6e7af56a325e@github.com>

On Fri, 30 May 2025 19:34:16 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The command to run all range specific micro-benchmarks is posted below.
>> 
>> `make test TEST="micro:CbrtPerf.CbrtPerfRanges"`
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides a major uplift of 169% when very small inputs are used and a more modest uplift of 45% for all other inputs.
>> 
>> | Input range(s)                                  | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
>> | :-------------------------------------: | :-------------------------------: | :-------------------------------: | :---------: |
>> | [-2^(-1022), 2^(-1022)]                   | 6568                                        | 17678                                      | 2.69x       |
>> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932                                    | 200897                                    | 1.45x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set address attributes in movapd assembly instruction function definition

This change also broke most of the non-x86 platforms, due to the new intrinsic not being implemented on those platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2928415483

From duke at openjdk.org  Mon Jun  2 03:52:07 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Mon, 2 Jun 2025 03:52:07 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v6]
In-Reply-To: <Vua0yenFp1sDiTmOChgBc5fvYCdoByDo82MwLo1ikBI=.82d2bbe5-eb46-4cf8-acdc-6e7af56a325e@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <sZVVm3lr1byp_brwwk80CWNovJIKZ4Mc_RvcRNIBBEI=.4f9e6ca0-108f-4e11-9e0c-f4b5bcf32482@github.com>
 <Vua0yenFp1sDiTmOChgBc5fvYCdoByDo82MwLo1ikBI=.82d2bbe5-eb46-4cf8-acdc-6e7af56a325e@github.com>
Message-ID: <CJ6XTFRmKm7TsbS74Vb1viZQDP9YqiZPUZOGFJYJ_cs=.37f559f3-d1c5-48d8-9b89-f103d1b1b053@github.com>

On Mon, 2 Jun 2025 02:08:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This change also broke most of the non-x86 platforms, due to the new intrinsic not being implemented on those platforms.

When you say "most of the non-x86 platforms", are you referring to the ones with processor types listed below?

1. jdk/src/hotspot/cpu/**arm**
2. jdk/src/hotspot/cpu/**ppc**
3. jdk/src/hotspot/cpu/**s390**

I don't see a cbrt intrinsic implementation in the non-x86 platforms. However, the ones listed above appear to get to the _ShouldNotReachHere_ error state if a particular intrinsic isn't found in `TemplateInterpreterGenerator::generate_math_entry` (`templateInterpreterGenerator_*.cpp`). It looks like aarch64 and riscv don't take that route and would fall back to the default cbrt implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2928618217

From dholmes at openjdk.org  Mon Jun  2 04:44:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Jun 2025 04:44:57 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v6]
In-Reply-To: <CJ6XTFRmKm7TsbS74Vb1viZQDP9YqiZPUZOGFJYJ_cs=.37f559f3-d1c5-48d8-9b89-f103d1b1b053@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <sZVVm3lr1byp_brwwk80CWNovJIKZ4Mc_RvcRNIBBEI=.4f9e6ca0-108f-4e11-9e0c-f4b5bcf32482@github.com>
 <Vua0yenFp1sDiTmOChgBc5fvYCdoByDo82MwLo1ikBI=.82d2bbe5-eb46-4cf8-acdc-6e7af56a325e@github.com>
 <CJ6XTFRmKm7TsbS74Vb1viZQDP9YqiZPUZOGFJYJ_cs=.37f559f3-d1c5-48d8-9b89-f103d1b1b053@github.com>
Message-ID: <Ncc03SW7hV4CiyaaSbqb1yn1YtvVP3cWkYr8b0n33v0=.2ebaa5ec-4af4-455a-8a57-8883bf4339e9@github.com>

On Mon, 2 Jun 2025 03:49:42 GMT, Mohamed Issa <duke at openjdk.org> wrote:

> When you say "most of the non-x86 platforms", are you referring to the ones with processor types listed below?

Yes - 3 of the 5 non-x86 platforms.

> It looks like aarch64 and riscv don't take that route and would fall back to the default cbrt implementation.

I was wondering why Aarch64 didn't fail. I guess the other platforms may use this to detect new intrinsics being added.

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

PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2928722575

From hgreule at openjdk.org  Mon Jun  2 06:12:51 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 2 Jun 2025 06:12:51 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file
In-Reply-To: <mgexeHo_EQZG4VII-fp7HjtfGQ6H5RkYnvSXeBlBDnw=.b1516902-2df4-4b14-a3af-63a81182bc90@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <mgexeHo_EQZG4VII-fp7HjtfGQ6H5RkYnvSXeBlBDnw=.b1516902-2df4-4b14-a3af-63a81182bc90@github.com>
Message-ID: <XclSyIJ-nDMEkUri-wrYeBj2VM0yZvjTjZwCOJ9dR78=.38b60551-9b38-49dc-b36f-b7e3f43b4d1f@github.com>

On Mon, 2 Jun 2025 00:56:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> I recommend we fallback to use CFFV.latest() explicitly for now. FYI we will likely add a new CFFV for all preview features, which we will likely use as the default if we encounter an old preview class file. We can then swap latest() with that preview cffv.

Okay, sounds good. I guess that should be done in https://github.com/openjdk/jdk/blob/c5a1543ee3e68775f09ca29fb07efd9aebfdb33e/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java#L120-L123 directly? And also for both cases returning `null`?

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

PR Comment: https://git.openjdk.org/jdk/pull/25569#issuecomment-2928964395

From jbhateja at openjdk.org  Mon Jun  2 07:44:58 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 2 Jun 2025 07:44:58 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API
In-Reply-To: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
Message-ID: <qFN8lzbD_FVx8mz-aJ1ClRf2joSJImF4UifJsJPcyr8=.71ad3923-0975-4bfb-8bad-3ef1c2fcbe8e@github.com>

On Fri, 9 May 2025 07:35:41 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]).
> 
> Two key areas require improvement:
> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance.
> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types  increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance.
> 
> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures.
> 
> Main changes:
> 1. Java-side API refactoring:
>    - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on
>      architectures like AArch64.
> 2. C2 compiler IR refactoring:
>    - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types.
> 3. Backend changes:
>    - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level.
> 
> Performance:
> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below:
> 
> Benchmark                                                 Mode   Cnt Unit    SIZE    Before      After    Gain
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  64    53682.012   52650.325  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  256   14484.252   14255.156  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  1024   3664.900    3595.615  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  4096    908.312     935.269  1.02
> GatherOperationsBenchmark.micr...

Hi @XiaohongGong ,
Looks good to me, thanks again for this re-factor !!

Best Regards,
Jatin

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

Marked as reviewed by jbhateja (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25138#pullrequestreview-2887157235

From shade at openjdk.org  Mon Jun  2 08:27:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 08:27:53 GMT
Subject: RFR: 8358151 : Harden JSR166 Test case
 testShutdownNow_delayedTasks
In-Reply-To: <FBGiqy8ENgXWOL9R7S_2eGFH_gCXHhnnBpm_4uN1TlA=.d43496b9-7f1d-4d0a-a8f0-2dd826874f41@github.com>
References: <FBGiqy8ENgXWOL9R7S_2eGFH_gCXHhnnBpm_4uN1TlA=.d43496b9-7f1d-4d0a-a8f0-2dd826874f41@github.com>
Message-ID: <kexbmvAVhxy_SC_VpRdP6Bj3yCckt2qJHZe3F60p-eY=.ce9819d1-92ce-4a79-9395-f1e6e725ec9f@github.com>

On Fri, 30 May 2025 12:16:15 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Bumping the (synthetic) delays to 100 seconds to ensure that they don't run prior to shutdown being finished.

Looks fine, thanks.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25548#pullrequestreview-2887292860

From vyazici at openjdk.org  Mon Jun  2 09:02:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 09:02:56 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <sdD_sCKqgIH47ozZr_JLBa38whUshwsAYpPhlb8YVbQ=.4dc670bc-2efd-4d73-a92b-982d40483d55@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <sdD_sCKqgIH47ozZr_JLBa38whUshwsAYpPhlb8YVbQ=.4dc670bc-2efd-4d73-a92b-982d40483d55@github.com>
Message-ID: <uXeoMZ7n-Nb_hygLGtFpWwGR8W8ooZmHvVqBQmdzQWo=.22bb4db5-88f3-4b2a-a348-5162d84d0427@github.com>

On Sun, 1 Jun 2025 20:56:50 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some reviewer feedback

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 30:

> 28: import java.util.concurrent.locks.ReentrantLock;
> 29: import jdk.jfr.internal.PlatformEventType;
> 30: public final class Throttler {

**Disclaimer:** I am a passer-by and I don't possess a deep JFR experience.

Throttling (aka. rate limiting) is a pretty much non-trivial functionality. Shall we

- Revamp the JavaDoc and document the used algorithm?
- Have a dedicated test for `Throttler`? (I see that the newly added `TestThrottle` tests `@Throttle`, hence it also covers `Throttler`. Though there I could not see any verification based on the time[stamp] of events.)

### References

- Resilience4j:
  - [AtomicRateLimiter](https://github.com/resilience4j/resilience4j/blob/master/resilience4j-ratelimiter/src/main/java/io/github/resilience4j/ratelimiter/internal/AtomicRateLimiter.java)
  - [AtomicRateLimiterTest](https://github.com/resilience4j/resilience4j/blob/master/resilience4j-ratelimiter/src/test/java/io/github/resilience4j/ratelimiter/internal/AtomicRateLimiterTest.java)
- Guava:
  - [RateLimiter](https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/RateLimiter.java)
  - [RateLimiterTest](https://github.com/google/guava/blob/master/guava-tests/test/com/google/common/util/concurrent/RateLimiterTest.java)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2120496703

From vklang at openjdk.org  Mon Jun  2 09:24:57 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 2 Jun 2025 09:24:57 GMT
Subject: Integrated: 8358151 : Harden JSR166 Test case
 testShutdownNow_delayedTasks
In-Reply-To: <FBGiqy8ENgXWOL9R7S_2eGFH_gCXHhnnBpm_4uN1TlA=.d43496b9-7f1d-4d0a-a8f0-2dd826874f41@github.com>
References: <FBGiqy8ENgXWOL9R7S_2eGFH_gCXHhnnBpm_4uN1TlA=.d43496b9-7f1d-4d0a-a8f0-2dd826874f41@github.com>
Message-ID: <hn92M7VNLuDhvJZiwuwd8yczrt4e-ATKk7Fi-99s4N4=.936ebc83-b697-4202-8f08-42f6c4bfa61b@github.com>

On Fri, 30 May 2025 12:16:15 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Bumping the (synthetic) delays to 100 seconds to ensure that they don't run prior to shutdown being finished.

This pull request has now been integrated.

Changeset: 83cb0c6d
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83cb0c6de5988de526545d0926c2c6ef60efc1c7
Stats:     10 lines in 2 files changed: 4 ins; 0 del; 6 mod

8358151: Harden JSR166 Test case testShutdownNow_delayedTasks

Reviewed-by: alanb, shade

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

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

From viktor.klang at oracle.com  Mon Jun  2 09:33:17 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 2 Jun 2025 09:33:17 +0000
Subject: Should mapConcurrent() respect time order instead of input order?
In-Reply-To: <CAKD1RYuoK07OvAn02v4qq74Q1QDfpQpf=t0J0VT-s1zi4iKRnA@mail.gmail.com>
References: <CAKD1RYuoK07OvAn02v4qq74Q1QDfpQpf=t0J0VT-s1zi4iKRnA@mail.gmail.com>
Message-ID: <MW4PR10MB5774AED3EC215ED5AB3AD52CFF62A@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi!

In a similar vein to the built-in Collectors,
the built-in Gatherers provide solutions to common stream-related problems, but also, they also serve as "inspiration" for developers for what is possible to implement using Gatherers.

If someone, for performance reasons, and with a use-case which does not require encounter-order, want to take advantage of that combination of circumstances, it is definitely possible to implement your own Gatherer which has that behavior.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Jige Yu <yujige at gmail.com>
Sent: Sunday, 1 June 2025 21:08
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Should mapConcurrent() respect time order instead of input order?

It seems like for most people, input order isn't that important for concurrent work, and concurrent results being in non-deterministic order is often expected.

If mapConcurrent() just respect output encounter order:

It'll be able to achieve higher throughput if an early task is slow, For example, with concurrency=2, and if the first task takes 10 minutes to run, mapConcurrent() would only be able to process 2 tasks within the first 10 minutes; whereas with encounter order, the first task being slow doesn't block the 3rd - 100th elements from being processed and output.

mapConcurrent() can be used to implement useful concurrent semantics, for example to support race semantics. Imagine if I need to send request to 10 candidate backends and take whichever that succeeds first, I'd be able to do:

backends.stream()
    .gather(mapConcurrent(
        backend -> {
          try {
            return backend.fetchOrder();
           } catch (RpcException e) {
             return null; // failed to fetch but not fatal
           }
        })
        .filter(Objects::notNull)
        .findFirst(); // first success then cancel the rest

Cheers,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250602/3fae5a17/attachment-0001.htm>

From egahlin at openjdk.org  Mon Jun  2 10:02:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 2 Jun 2025 10:02:53 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <uXeoMZ7n-Nb_hygLGtFpWwGR8W8ooZmHvVqBQmdzQWo=.22bb4db5-88f3-4b2a-a348-5162d84d0427@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <sdD_sCKqgIH47ozZr_JLBa38whUshwsAYpPhlb8YVbQ=.4dc670bc-2efd-4d73-a92b-982d40483d55@github.com>
 <uXeoMZ7n-Nb_hygLGtFpWwGR8W8ooZmHvVqBQmdzQWo=.22bb4db5-88f3-4b2a-a348-5162d84d0427@github.com>
Message-ID: <Vm8I6uPuFb9c9HvLs2k2AlmzzND58RLMNQSzaUJtIdY=.ed8d5612-b376-4ff3-9335-7286d5f1423c@github.com>

On Mon, 2 Jun 2025 08:59:57 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some reviewer feedback
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 30:
> 
>> 28: import java.util.concurrent.locks.ReentrantLock;
>> 29: import jdk.jfr.internal.PlatformEventType;
>> 30: public final class Throttler {
> 
> **Disclaimer:** I am a passer-by and I don't possess a deep JFR experience.
> 
> Throttling (aka. rate limiting) is a pretty much non-trivial functionality. Shall we
> 
> - Revamp the JavaDoc and document the used algorithm?
> - Have a dedicated test for `Throttler`? (I see that the newly added `TestThrottle` tests `@Throttle`, hence it also covers `Throttler`. Though there I could not see any verification based on the time[stamp] of events.)
> 
> ### References
> 
> - Resilience4j:
>   - [AtomicRateLimiter](https://github.com/resilience4j/resilience4j/blob/master/resilience4j-ratelimiter/src/main/java/io/github/resilience4j/ratelimiter/internal/AtomicRateLimiter.java)
>   - [AtomicRateLimiterTest](https://github.com/resilience4j/resilience4j/blob/master/resilience4j-ratelimiter/src/test/java/io/github/resilience4j/ratelimiter/internal/AtomicRateLimiterTest.java)
> - Guava:
>   - [RateLimiter](https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/RateLimiter.java)
>   - [RateLimiterTest](https://github.com/google/guava/blob/master/guava-tests/test/com/google/common/util/concurrent/RateLimiterTest.java)

I don't think we want to write the algorithm in the specification. It would make it harder for us to make adjustments in the future. The contract is x events per time unit without details on how JFR adapts the sampling. The algorithm is the same one used by the jdk.ObjectAllocationSample event, which has been in use since JDK 16, but implemented in native code and with a gtest:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/jfr/support/jfrAdaptiveSampler.cpp
 
The code in the PR is a method per method port of that code. It's hard to write stable tests that include timestamps. We have tried that in the past for other settings/events, but it only resulted in false positives.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2120643350

From mgronlun at openjdk.org  Mon Jun  2 10:14:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 10:14:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <KxlQQTym19WULE3miG6oD_hV6Zh4mSlw1zRHCswk0Eg=.82623696-1fac-4294-a187-07956c424814@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Pb7W24qpASuvcdw8ElmNW-RubVkddYTqvzDQPGCvvrw=.6bec04d0-5dc0-493f-8ebd-d1595f3c4946@github.com>
 <KxlQQTym19WULE3miG6oD_hV6Zh4mSlw1zRHCswk0Eg=.82623696-1fac-4294-a187-07956c424814@github.com>
Message-ID: <nh7gTI3xUYTtMZigep1TusR2Pzu1QSdZ-zYjoMA00fs=.2ba97d70-8644-4975-8df0-96af982fc49c@github.com>

On Sun, 1 Jun 2025 13:07:50 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 256:
>> 
>>> 254:             // }
>>> 255:             getEventConfiguration(codeBuilder);
>>> 256:             codeBuilder.aload(0);
>> 
>> Can issue a dup() here if you want to avoid the second aload(0).
>
> I don't think it will work because the result of the first getField (startTime) will be on the stack, when we issue the next getField (duration).

No big deal, we can look into the details later.

>> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 261:
>> 
>>> 259:             getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_DURATION);
>>> 260:             Bytecode.invokevirtual(codeBuilder, TYPE_EVENT_CONFIGURATION, METHOD_THROTTLE);
>>> 261:             int result = codeBuilder.allocateLocal(TypeKind.LONG);
>> 
>> Do we really need to store the result in a local? Can't we just dup it on the expression stack and store it directly into the field after another aload, or dup? Perhaps dup twice to then issue the mask operation?
>
> We could do an aload(0) at the beginning, before getEventConfiguration(codeBuilder), to have "this" for putfield(duration) later, but then we would need to do a getfield(this.duration) to have it on the stack for the mask.
> 
> We can't do a dup() on duration because we need "this" on the stack to store it in this.duration. I thought using a local variable would be faster than accessing this.duration. It also reduces the chance of the value being changed by another thread.

No big deal, we can look into this later if the need arises.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2120675164
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2120676832

From epeter at openjdk.org  Mon Jun  2 10:50:54 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 2 Jun 2025 10:50:54 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API
In-Reply-To: <TPRwd9SD38ISkoXoJJRu0qMqx6_KU3USw1yPxpbUKVM=.f64594dd-b92b-4453-b7d2-f6b3ebb14a83@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <z9_9NOdQqxNvv_l0VxjGD4Xc-baboKUmbY5NGbXdAHw=.f8486a40-5d28-4f9c-913e-8155baadbec2@github.com>
 <t1DdwodJEC_7OWaci1nCnC6LZVV62x5flDo7rjzYcoM=.91f68c49-f044-43e3-8bba-67a2bd5a5800@github.com>
 <yYd0dXTCX-TXZpluDy9iktVQWeLifmY5GG_GNHkH9lU=.c414c05b-af7e-4b67-8f0f-9ba39696c82a@github.com>
 <TPRwd9SD38ISkoXoJJRu0qMqx6_KU3USw1yPxpbUKVM=.f64594dd-b92b-4453-b7d2-f6b3ebb14a83@github.com>
Message-ID: <ofWKcjk43ywNUep86q0nRhxJIoBgw-UTriVuN_ltvXM=.b939958c-82c5-45e8-ab18-8555b59e86e8@github.com>

On Fri, 30 May 2025 08:15:22 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> @XiaohongGong Thanks for splitting this one out, and for investigating the regressions here.
>>> 
>>> Putting the permalink here, fixed to the current change (the link you pasted will always refer to the newest, which may later on point to the wrong line when lines above are inserted / deleted):
>>> 
>>> https://github.com/openjdk/jdk/blob/7077535c0b0a6ea0a2a167f9135b1504a3d71fb3/src/hotspot/share/opto/loopnode.cpp#L1659-L1661
>>> 
>>> I wonder if we should just use `Node::uncast` there? But I'm quite unsure about that.
>> 
>> Sounds good to me. I will have a deep investigation for it. Thanks!
>> 
>> 
>> 
>>> > Yes, I also observed such regression.
>>> > It would be nice if you proactively mentioned regressions, so it does not have to be pointed out by reviewers.
>>> 
>>> For me, it could be ok to fix it in a follow-up patch. I think we are too close to RDP1 for JDK25 now anyway, and so we could push this patch here into JDK26, and then we have enough time in JDK26 to investigate the regression. Even better would be if we could do the other patch first, so we never even encounter a regression.
>> 
>> Sounds good to me. Thanks!
>
>> > @XiaohongGong Thanks for splitting this one out, and for investigating the regressions here.
>> > Putting the permalink here, fixed to the current change (the link you pasted will always refer to the newest, which may later on point to the wrong line when lines above are inserted / deleted):
>> > https://github.com/openjdk/jdk/blob/7077535c0b0a6ea0a2a167f9135b1504a3d71fb3/src/hotspot/share/opto/loopnode.cpp#L1659-L1661
>> > 
>> > I wonder if we should just use `Node::uncast` there? But I'm quite unsure about that.
>> 
>> Sounds good to me. I will have a deep investigation for it. Thanks!
> 
> Hi @eme64  @jatin-bhateja,  I'v created a PR https://github.com/openjdk/jdk/pull/25539 to fix this issue. With this change, the performance regression can be fixed as well.  Could you please take a look at that change and help to run the test on different X86 machines?   Thanks a lot!

@XiaohongGong I reviewed https://github.com/openjdk/jdk/pull/25539. Since it is a relatively simple patch, I suggest that we integrate that one first, and come back to this here later. Is that ok for you?

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

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2930007655

From pminborg at openjdk.org  Mon Jun  2 12:19:52 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 2 Jun 2025 12:19:52 GMT
Subject: RFR: 8357823: Changes in StringBuilder (JDK-8351443) caused a 1-3%
 regression in biojava
In-Reply-To: <EqrJvAzbQYoe6SnQhsy9_KmtAhqJI4jGMaHOztKb0n8=.99ee9a06-04d4-499b-976c-74da3314f4b5@github.com>
References: <EqrJvAzbQYoe6SnQhsy9_KmtAhqJI4jGMaHOztKb0n8=.99ee9a06-04d4-499b-976c-74da3314f4b5@github.com>
Message-ID: <wc5faSby1ZvSEpt55LkvhevUM4SWaZeXcw2EerrAb8M=.6a4cfe80-d1d3-495b-a65c-85b937ec9482@github.com>

On Fri, 30 May 2025 14:01:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Comment out assertions added in JDK-8351443 from AbstractStringBuilder.ensureCapacityNewCoder that increase the codesize, preventing some inlining, and reducing performance
> 
>        assert coder == newCoder || newCoder == UTF16 : "bad new coder UTF16 -> LATIN1";
>        assert count <= newCapacity : "count exceeds new capacity";

Using this proposed patch, did we see any improvements in BioJava?

Did we consider adding `@ForceInline` for `ensureCapacityNewCoder()`?

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

PR Comment: https://git.openjdk.org/jdk/pull/25550#issuecomment-2930400282
PR Comment: https://git.openjdk.org/jdk/pull/25550#issuecomment-2930403548

From pminborg at openjdk.org  Mon Jun  2 12:47:56 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 2 Jun 2025 12:47:56 GMT
Subject: RFR: 8357821: Revert incorrectly named JavaLangAccess::unchecked*
 methods
In-Reply-To: <tDzMTU2VeD_fIb5s8gweKAF1fnz5p6y7kWgGkWcpMAY=.749b0bce-e6e0-490f-a6eb-f584c3f7166f@github.com>
References: <tDzMTU2VeD_fIb5s8gweKAF1fnz5p6y7kWgGkWcpMAY=.749b0bce-e6e0-490f-a6eb-f584c3f7166f@github.com>
Message-ID: <Ecny_2ISwpmrmUpPcQWYWbq4cbOVddCUuJ-2ginZg9U=.a6e70e27-3b09-45e5-98bf-14de181c52aa@github.com>

On Fri, 30 May 2025 11:57:39 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Reverts certain [JDK-8353197](https://bugs.openjdk.org/browse/JDK-8353197) (which implements JavaDoc improvement and precautionary naming for certain unsafe methods in `jdk.internal.access.JavaLangAccess`) changes that are found to be incorrect. See the JBS issue for details on the followed evaluation process.

The changes look good to me. I wonder if we should add that implementations of the affected method *shall* do bounds checking to reduce the likelihood of a new/updated native implementation miss that?

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

PR Comment: https://git.openjdk.org/jdk/pull/25545#issuecomment-2930516107

From liach at openjdk.org  Mon Jun  2 13:00:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Jun 2025 13:00:51 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file
In-Reply-To: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
Message-ID: <_pcPENDOo2UK1hUIaUEe39a4uP94xmkHCJRXT3VNCRE=.46e88a2e-7c78-44d0-8d5d-3fe297b36238@github.com>

On Sun, 1 Jun 2025 04:53:46 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.

That sounds right.

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

PR Comment: https://git.openjdk.org/jdk/pull/25569#issuecomment-2930578390

From pminborg at openjdk.org  Mon Jun  2 13:24:00 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 2 Jun 2025 13:24:00 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v6]
In-Reply-To: <OFDIn3eiGsANwA-Rp_gVpSZdRgeYnEAqYbs_ttBh5jQ=.0369806c-e8b9-43c8-8ec4-b8242701bbb8@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <-_-E4pvswblhrUiDwCgk8Rh9UiBRlmpsaqmCWjnx7gQ=.4b6598f9-eecf-4f35-b599-326fe4de8a88@github.com>
 <OFDIn3eiGsANwA-Rp_gVpSZdRgeYnEAqYbs_ttBh5jQ=.0369806c-e8b9-43c8-8ec4-b8242701bbb8@github.com>
Message-ID: <WPYk6PbYu-8q0dTpFZJQnEWLCAPZRVhDUTZCLx7tZgM=.18a15abd-7f20-41a6-a535-f07d31b2fe17@github.com>

On Thu, 29 May 2025 09:52:34 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' into fill-overlap
>>  - Update test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update benchmark to reflect new fill method
>>  - Simplify
>>  - Add case for long operations and break out methods
>>  - Correct typo in comment
>>  - Simplify the fill method
>
> test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java line 98:
> 
>> 96:     }
>> 97: 
>> 98:     @Fork(value = 3, jvmArgs = {"-Djava.lang.foreign.native.threshold.power.fill=0"})
> 
> Why did you remove this line? It's essential for correct `Unsafe` results.

The reason  I removed it is that it no longer works this way. For small segments, Java code will be used unconditionally. It is only for larger (>=32 bytes) we check this property. So, now the benchmark directly invokes the branch that calls Unsafe (`SCOPED_MEMORY_ACCESS::setMemory`). I hope this clarifies things.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25383#discussion_r2121136632

From shade at openjdk.org  Mon Jun  2 13:26:36 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 13:26:36 GMT
Subject: RFR: 8357798: ReverseOrderListView uses Boolean boxes after
 JDK-8356080 [v2]
In-Reply-To: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
Message-ID: <PhT14YEIl64GPW-wEdPuompsEyae4v7Dsy8VWQXVWrY=.3bd44848-f58a-41e4-9be6-fd115279e951@github.com>

> SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the existence of the boxed object to allow optional constant folding.
> 
> We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/util`

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

 - Just drop back to boolean
 - Merge branch 'master' into JDK-8357798-reverse-order-list-boxes
 - A bit better comment
 - Better fix
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25456/files
  - new: https://git.openjdk.org/jdk/pull/25456/files/288b13ee..842b8dea

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

  Stats: 56428 lines in 840 files changed: 30803 ins; 15851 del; 9774 mod
  Patch: https://git.openjdk.org/jdk/pull/25456.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25456/head:pull/25456

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

From shade at openjdk.org  Mon Jun  2 13:26:36 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 13:26:36 GMT
Subject: RFR: 8357798: ReverseOrderListView uses Boolean boxes after
 JDK-8356080
In-Reply-To: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
Message-ID: <OtIpoLbp2ze61htDTO1LFRHhGrwAi5fO5IhyPL1AFt8=.3fb30227-495e-4bbe-9157-92ad830774f8@github.com>

On Mon, 26 May 2025 17:08:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the existence of the boxed object to allow optional constant folding.
> 
> We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/util`

All right, reverting back to `boolean` makes much more sense. Did so in new commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2930707437

From cstein at openjdk.org  Mon Jun  2 13:52:15 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 2 Jun 2025 13:52:15 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with trailing
 comment
Message-ID: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>

Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign.

The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files):

Use the number sign `#` in the argument file to identify comments.
All characters following the `#` are ignored until the end of line.

There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters.

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

Commit messages:
 - 8357862: Java argument file is parsed unexpectedly with trailing comment

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

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

From cstein at openjdk.org  Mon Jun  2 13:52:16 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 2 Jun 2025 13:52:16 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment
In-Reply-To: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
Message-ID: <tO_z8q0cawzrkDP_z__sUZbM2sWejgIHdwksIbFboUI=.1b657729-6541-4310-9117-d4f7f0d75a7a@github.com>

On Mon, 2 Jun 2025 13:46:23 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign.
> 
> The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files):
> 
> Use the number sign `#` in the argument file to identify comments.
> All characters following the `#` are ignored until the end of line.
> 
> There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters.

src/java.base/share/native/libjli/args.c line 276:

> 274:                     }
> 275:                     pctx->cptr = nextc + 1;
> 276:                     return token;

This code duplicates a large part of the block of the previous case. Perhaps an internal helper method could be extracted?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2121214111

From yujige at gmail.com  Mon Jun  2 14:29:13 2025
From: yujige at gmail.com (Jige Yu)
Date: Mon, 2 Jun 2025 07:29:13 -0700
Subject: Should mapConcurrent() respect time order instead of input order?
In-Reply-To: <CAKD1RYtLy_yC+L5+q1YOkbEvUis5LJ-tJNJDbyoptq8A=+W3eg@mail.gmail.com>
References: <CAKD1RYuoK07OvAn02v4qq74Q1QDfpQpf=t0J0VT-s1zi4iKRnA@mail.gmail.com>
 <MW4PR10MB5774AED3EC215ED5AB3AD52CFF62A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtLy_yC+L5+q1YOkbEvUis5LJ-tJNJDbyoptq8A=+W3eg@mail.gmail.com>
Message-ID: <CAKD1RYuksGCWsqj6cnu3aoHqkzAepLeNHsGSX_nCi2QryJaGMQ@mail.gmail.com>

Sorry. Forgot to copy to the mailing list.

On Mon, Jun 2, 2025 at 7:27?AM Jige Yu <yujige at gmail.com> wrote:

> Thanks Viktor!
>
> I was thinking from my own experience that I wouldn't have automatically
> assumed that a concurrent fanout library would by default preserve input
> order.
>
> And I think wanting high throughput with real-life utilities like race
> would be more commonly useful.
>
> But I could be wrong.
>
> Regardless, mapConcurrent() can do both, no?
>
> Even if it by default preserves input order, when I explicitly called
> stream.unordered(), could mapConcurrent() respect that and in return
> achieve higher throughput with support for race?
>
>
>
> On Mon, Jun 2, 2025 at 2:33?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
>> Hi!
>>
>> In a similar vein to the built-in Collectors,
>> the built-in Gatherers provide solutions to common stream-related
>> problems, but also, they also serve as "inspiration" for developers for
>> what is possible to implement using Gatherers.
>>
>> If someone, for performance reasons, and with a use-case which does not
>> require encounter-order, want to take advantage of that combination of
>> circumstances, it is definitely possible to implement your own Gatherer
>> which has that behavior.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Jige
>> Yu <yujige at gmail.com>
>> *Sent:* Sunday, 1 June 2025 21:08
>> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>> *Subject:* Should mapConcurrent() respect time order instead of input
>> order?
>>
>> It seems like for most people, input order isn't that important for
>> concurrent work, and concurrent results being in non-deterministic order is
>> often expected.
>>
>> If mapConcurrent() just respect output encounter order:
>>
>> It'll be able to achieve *higher throughput* if an early task is slow,
>> For example, with concurrency=2, and if the first task takes 10 minutes to
>> run, mapConcurrent() would only be able to process 2 tasks within the first
>> 10 minutes; whereas with encounter order, the first task being slow doesn't
>> block the 3rd - 100th elements from being processed and output.
>>
>> mapConcurrent() can be used to implement useful concurrent semantics, for
>> example to *support race* semantics. Imagine if I need to send request
>> to 10 candidate backends and take whichever that succeeds first, I'd be
>> able to do:
>>
>> backends.stream()
>>     .gather(mapConcurrent(
>>         backend -> {
>>           try {
>>             return backend.fetchOrder();
>>            } catch (RpcException e) {
>>              return null; // failed to fetch but not fatal
>>            }
>>         })
>>         .filter(Objects::notNull)
>>         .findFirst(); // first success then cancel the rest
>>
>>
>> Cheers,
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250602/3a2375e9/attachment.htm>

From nbenalla at openjdk.org  Mon Jun  2 14:46:15 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 2 Jun 2025 14:46:15 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v6]
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: <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>

> Get JDK 26 underway.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Revert "feedback: never bump ASM version"
   
   This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Update --release 25 symbol information for JDK 25 build 24
   The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
 - problem list some failing tests
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Update --release 25 symbol information for JDK 25 build 23
   The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/
 - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b

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

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=05
  Stats: 1824 lines in 59 files changed: 1734 ins; 16 del; 74 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 viktor.klang at oracle.com  Mon Jun  2 14:48:19 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 2 Jun 2025 14:48:19 +0000
Subject: [External] : Re: Should mapConcurrent() respect time order
 instead of input order?
In-Reply-To: <CAKD1RYuksGCWsqj6cnu3aoHqkzAepLeNHsGSX_nCi2QryJaGMQ@mail.gmail.com>
References: <CAKD1RYuoK07OvAn02v4qq74Q1QDfpQpf=t0J0VT-s1zi4iKRnA@mail.gmail.com>
 <MW4PR10MB5774AED3EC215ED5AB3AD52CFF62A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtLy_yC+L5+q1YOkbEvUis5LJ-tJNJDbyoptq8A=+W3eg@mail.gmail.com>
 <CAKD1RYuksGCWsqj6cnu3aoHqkzAepLeNHsGSX_nCi2QryJaGMQ@mail.gmail.com>
Message-ID: <SJ0PR10MB5766DAA744887EE8B0A2B991FF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>

>Even if it by default preserves input order, when I explicitly called stream.unordered(), could mapConcurrent() respect that and in return achieve higher throughput with support for race?

The Gatherer doesn't know whether the Stream is unordered or ordered. The operation should be semantically equivalent anyway.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com>
Sent: Monday, 2 June 2025 16:29
To: Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: [External] : Re: Should mapConcurrent() respect time order instead of input order?

Sorry. Forgot to copy to the mailing list.

On Mon, Jun 2, 2025 at 7:27?AM Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>> wrote:
Thanks Viktor!

I was thinking from my own experience that I wouldn't have automatically assumed that a concurrent fanout library would by default preserve input order.

And I think wanting high throughput with real-life utilities like race would be more commonly useful.

But I could be wrong.

Regardless, mapConcurrent() can do both, no?

Even if it by default preserves input order, when I explicitly called stream.unordered(), could mapConcurrent() respect that and in return achieve higher throughput with support for race?



On Mon, Jun 2, 2025 at 2:33?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi!

In a similar vein to the built-in Collectors,
the built-in Gatherers provide solutions to common stream-related problems, but also, they also serve as "inspiration" for developers for what is possible to implement using Gatherers.

If someone, for performance reasons, and with a use-case which does not require encounter-order, want to take advantage of that combination of circumstances, it is definitely possible to implement your own Gatherer which has that behavior.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Sunday, 1 June 2025 21:08
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Should mapConcurrent() respect time order instead of input order?

It seems like for most people, input order isn't that important for concurrent work, and concurrent results being in non-deterministic order is often expected.

If mapConcurrent() just respect output encounter order:

It'll be able to achieve higher throughput if an early task is slow, For example, with concurrency=2, and if the first task takes 10 minutes to run, mapConcurrent() would only be able to process 2 tasks within the first 10 minutes; whereas with encounter order, the first task being slow doesn't block the 3rd - 100th elements from being processed and output.

mapConcurrent() can be used to implement useful concurrent semantics, for example to support race semantics. Imagine if I need to send request to 10 candidate backends and take whichever that succeeds first, I'd be able to do:

backends.stream()
    .gather(mapConcurrent(
        backend -> {
          try {
            return backend.fetchOrder();
           } catch (RpcException e) {
             return null; // failed to fetch but not fatal
           }
        })
        .filter(Objects::notNull)
        .findFirst(); // first success then cancel the rest

Cheers,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250602/d3ebebef/attachment-0001.htm>

From nbenalla at openjdk.org  Mon Jun  2 14:52:55 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 2 Jun 2025 14:52:55 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v6]
In-Reply-To: <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
Message-ID: <ipx1oPnsQNo4Anlo64ABbMwZoAeHFQk0bOIp4kyo5ew=.4b73443a-0ba4-48e7-bf77-ffe1e502ac10@github.com>

On Mon, 2 Jun 2025 14:46:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 24
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - problem list some failing tests
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 23
>    The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b

I have bumped the ASM version in [0dbdde7](https://github.com/openjdk/jdk/pull/25008/commits/0dbdde7bf6a0343acca74b284a8114c60919dd25) because various HotSpot tests use ASM fail under JDK 26 without this change.

This can be rolled back later after [JDK-8356548](https://bugs.openjdk.org/browse/JDK-8356548)

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

PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2931105555

From nbenalla at openjdk.org  Mon Jun  2 15:05:54 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 2 Jun 2025 15:05:54 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v6]
In-Reply-To: <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
Message-ID: <-CUDiWjPLN2ywVxx5RQWUpmsjgkPLb0AmtnLi3MACP4=.d2aebd91-1220-4a2a-acf2-fb3dc953d908@github.com>

On Mon, 2 Jun 2025 14:46:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 24
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - problem list some failing tests
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 23
>    The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b

There were no API changes in JDK 25 build 25.

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

PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2931159736

From yujige at gmail.com  Mon Jun  2 15:05:54 2025
From: yujige at gmail.com (Jige Yu)
Date: Mon, 2 Jun 2025 08:05:54 -0700
Subject: [External] : Re: Should mapConcurrent() respect time order
 instead of input order?
In-Reply-To: <SJ0PR10MB5766DAA744887EE8B0A2B991FF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
References: <CAKD1RYuoK07OvAn02v4qq74Q1QDfpQpf=t0J0VT-s1zi4iKRnA@mail.gmail.com>
 <MW4PR10MB5774AED3EC215ED5AB3AD52CFF62A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtLy_yC+L5+q1YOkbEvUis5LJ-tJNJDbyoptq8A=+W3eg@mail.gmail.com>
 <CAKD1RYuksGCWsqj6cnu3aoHqkzAepLeNHsGSX_nCi2QryJaGMQ@mail.gmail.com>
 <SJ0PR10MB5766DAA744887EE8B0A2B991FF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
Message-ID: <CAKD1RYvhpcD=yAGAvTTi+c8sdjDAi776GCPCAdvsCCVF9JQpeQ@mail.gmail.com>

Thank you for your response and for considering my feedback on the
mapConcurrent() gatherer. I understand and respect that the final decision
rests with the JDK maintainers.

I would like to offer a couple of further points for consideration. My
perspective is that strict adherence to input order for mapConcurrent()
might not be the most common or beneficial default behavior for users. I'd
be very interested to see any research or data that suggests otherwise, as
that would certainly inform my understanding.

>From my experience, a more common need is for higher throughput in
I/O-intensive operations. The ability to support use cases like race()?where
the first successfully completed operation determines the outcome?also
seems like a valuable capability that is currently infeasible due to the
ordering constraint.

As I see it, if a developer specifically requires the input order to be
preserved, this can be achieved with relative ease by applying a subsequent
sorting operation. For instance:

.gather(mapConcurrent(...))
.sorted(Comparator.comparing(Result::getInputSequenceId))

The primary challenge in these scenarios is typically the efficient fan-out
and execution of concurrent tasks, not the subsequent sorting of results.

Conversely, as you've noted, there isn't a straightforward way to modify
the current default ordered behavior to achieve the higher throughput or
race() semantics that an unordered approach would naturally provide.

While re-implementing the gatherer is a possibility, the existing
implementation is non-trivial, and creating a custom, robust alternative
represents a significant undertaking. My hope was that an unordered option
could be a valuable addition to the standard library, benefiting a wider
range of developers.

Thank you again for your time and consideration.


On Mon, Jun 2, 2025 at 7:48?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> >Even if it by default preserves input order, when I explicitly called
> stream.unordered(), could mapConcurrent() respect that and in return
> achieve higher throughput with support for race?
>
> The Gatherer doesn't know whether the Stream is unordered or ordered. The
> operation should be semantically equivalent anyway.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 2 June 2025 16:29
> *To:* Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <
> core-libs-dev at openjdk.org>
> *Subject:* [External] : Re: Should mapConcurrent() respect time order
> instead of input order?
>
> Sorry. Forgot to copy to the mailing list.
>
> On Mon, Jun 2, 2025 at 7:27?AM Jige Yu <yujige at gmail.com> wrote:
>
> Thanks Viktor!
>
> I was thinking from my own experience that I wouldn't have automatically
> assumed that a concurrent fanout library would by default preserve input
> order.
>
> And I think wanting high throughput with real-life utilities like race
> would be more commonly useful.
>
> But I could be wrong.
>
> Regardless, mapConcurrent() can do both, no?
>
> Even if it by default preserves input order, when I explicitly called
> stream.unordered(), could mapConcurrent() respect that and in return
> achieve higher throughput with support for race?
>
>
>
> On Mon, Jun 2, 2025 at 2:33?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi!
>
> In a similar vein to the built-in Collectors,
> the built-in Gatherers provide solutions to common stream-related
> problems, but also, they also serve as "inspiration" for developers for
> what is possible to implement using Gatherers.
>
> If someone, for performance reasons, and with a use-case which does not
> require encounter-order, want to take advantage of that combination of
> circumstances, it is definitely possible to implement your own Gatherer
> which has that behavior.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Jige
> Yu <yujige at gmail.com>
> *Sent:* Sunday, 1 June 2025 21:08
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Should mapConcurrent() respect time order instead of input
> order?
>
> It seems like for most people, input order isn't that important for
> concurrent work, and concurrent results being in non-deterministic order is
> often expected.
>
> If mapConcurrent() just respect output encounter order:
>
> It'll be able to achieve *higher throughput* if an early task is slow,
> For example, with concurrency=2, and if the first task takes 10 minutes to
> run, mapConcurrent() would only be able to process 2 tasks within the first
> 10 minutes; whereas with encounter order, the first task being slow doesn't
> block the 3rd - 100th elements from being processed and output.
>
> mapConcurrent() can be used to implement useful concurrent semantics, for
> example to *support race* semantics. Imagine if I need to send request to
> 10 candidate backends and take whichever that succeeds first, I'd be able
> to do:
>
> backends.stream()
>     .gather(mapConcurrent(
>         backend -> {
>           try {
>             return backend.fetchOrder();
>            } catch (RpcException e) {
>              return null; // failed to fetch but not fatal
>            }
>         })
>         .filter(Objects::notNull)
>         .findFirst(); // first success then cancel the rest
>
>
> Cheers,
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250602/91b8ae3b/attachment-0001.htm>

From vromero at openjdk.org  Mon Jun  2 15:12:53 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Jun 2025 15:12:53 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment
In-Reply-To: <tO_z8q0cawzrkDP_z__sUZbM2sWejgIHdwksIbFboUI=.1b657729-6541-4310-9117-d4f7f0d75a7a@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
 <tO_z8q0cawzrkDP_z__sUZbM2sWejgIHdwksIbFboUI=.1b657729-6541-4310-9117-d4f7f0d75a7a@github.com>
Message-ID: <4Xzu7FifgELCGKkOTBMCpcgYwwKuqymJBpMSQHVFbcA=.95d8329e-453e-439f-a628-149ce8c22a51@github.com>

On Mon, 2 Jun 2025 13:48:23 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign.
>> 
>> The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files):
>> 
>> Use the number sign `#` in the argument file to identify comments.
>> All characters following the `#` are ignored until the end of line.
>> 
>> There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters.
>
> src/java.base/share/native/libjli/args.c line 276:
> 
>> 274:                     }
>> 275:                     pctx->cptr = nextc + 1;
>> 276:                     return token;
> 
> This code duplicates a large part of the block of the previous case. Perhaps an internal helper method could be extracted?

right I agree that if there is common code we should extract it in a helper method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2121454132

From vromero at openjdk.org  Mon Jun  2 15:37:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Jun 2025 15:37:52 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment
In-Reply-To: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
Message-ID: <rsAtUNjzub-hXleCBRNaWWE8dHweVkY-L38ZO8LCuZY=.0787403b-7484-4d44-9f0f-46a6c9f9e50c@github.com>

On Mon, 2 Jun 2025 13:46:23 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign.
> 
> The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files):
> 
> Use the number sign `#` in the argument file to identify comments.
> All characters following the `#` are ignored until the end of line.
> 
> There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters.

the fact that not including a space between the comment and the previous element created havoc seems to indicate that the scanner is pretty fragile and could break again in the future. We should probably file a follow up to make this code more reliable

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

PR Comment: https://git.openjdk.org/jdk/pull/25589#issuecomment-2931287541

From cstein at openjdk.org  Mon Jun  2 15:43:50 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 2 Jun 2025 15:43:50 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment
In-Reply-To: <rsAtUNjzub-hXleCBRNaWWE8dHweVkY-L38ZO8LCuZY=.0787403b-7484-4d44-9f0f-46a6c9f9e50c@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
 <rsAtUNjzub-hXleCBRNaWWE8dHweVkY-L38ZO8LCuZY=.0787403b-7484-4d44-9f0f-46a6c9f9e50c@github.com>
Message-ID: <oGGWZgLD87FOepbwE2uFL-zxzuxD8ShEejVf-BxHkYE=.78fcd216-efaf-4790-853c-fc9f7b8eb498@github.com>

On Mon, 2 Jun 2025 15:35:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> the fact that not including a space between the comment and the previous element created havoc seems to indicate that the scanner is pretty fragile and could break again in the future. We should probably file a follow up to make this code more reliable

Yes, seems reasonable.  My initial solution was to try to make use of the shared [CommandLine](https://github.com/openjdk/jdk/blob/master/src/jdk.internal.opt/share/classes/jdk/internal/opt/CommandLine.java) class, but the parsing of the launcher is too early in the game.

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

PR Comment: https://git.openjdk.org/jdk/pull/25589#issuecomment-2931306833

From viktor.klang at oracle.com  Mon Jun  2 15:51:12 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 2 Jun 2025 15:51:12 +0000
Subject: [External] : Re: Should mapConcurrent() respect time order
 instead of input order?
In-Reply-To: <CAKD1RYvhpcD=yAGAvTTi+c8sdjDAi776GCPCAdvsCCVF9JQpeQ@mail.gmail.com>
References: <CAKD1RYuoK07OvAn02v4qq74Q1QDfpQpf=t0J0VT-s1zi4iKRnA@mail.gmail.com>
 <MW4PR10MB5774AED3EC215ED5AB3AD52CFF62A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtLy_yC+L5+q1YOkbEvUis5LJ-tJNJDbyoptq8A=+W3eg@mail.gmail.com>
 <CAKD1RYuksGCWsqj6cnu3aoHqkzAepLeNHsGSX_nCi2QryJaGMQ@mail.gmail.com>
 <SJ0PR10MB5766DAA744887EE8B0A2B991FF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYvhpcD=yAGAvTTi+c8sdjDAi776GCPCAdvsCCVF9JQpeQ@mail.gmail.com>
Message-ID: <SJ0PR10MB5766DB20AB83B1199C7987EAFF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>

>My perspective is that strict adherence to input order for mapConcurrent() might not be the most common or beneficial default behavior for users.

If there is indeed a majority who would benefit from an unordered version of mapConcurrent (my experience is that the majority prefer ordered) then, since it is possible to implement such a Gatherer outside of the JDK, this is something which will be constructed, widely used, and someone will then propose to add something similar to the JDK.

>While re-implementing the gatherer is a possibility, the existing implementation is non-trivial, and creating a custom, robust alternative represents a significant undertaking.

The existing version needs to maintain order, which adds to the complexity of the implementation. Implementing an unordered version would likely look different.
I'd definitely encourage taking the opportunity to attempt to implement it.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Jige Yu <yujige at gmail.com>
Sent: Monday, 2 June 2025 17:05
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order?


Thank you for your response and for considering my feedback on the mapConcurrent() gatherer. I understand and respect that the final decision rests with the JDK maintainers.

I would like to offer a couple of further points for consideration. My perspective is that strict adherence to input order for mapConcurrent() might not be the most common or beneficial default behavior for users. I'd be very interested to see any research or data that suggests otherwise, as that would certainly inform my understanding.

From my experience, a more common need is for higher throughput in I/O-intensive operations. The ability to support use cases like race()?where the first successfully completed operation determines the outcome?also seems like a valuable capability that is currently infeasible due to the ordering constraint.

As I see it, if a developer specifically requires the input order to be preserved, this can be achieved with relative ease by applying a subsequent sorting operation. For instance:

.gather(mapConcurrent(...))
.sorted(Comparator.comparing(Result::getInputSequenceId))


The primary challenge in these scenarios is typically the efficient fan-out and execution of concurrent tasks, not the subsequent sorting of results.

Conversely, as you've noted, there isn't a straightforward way to modify the current default ordered behavior to achieve the higher throughput or race() semantics that an unordered approach would naturally provide.

While re-implementing the gatherer is a possibility, the existing implementation is non-trivial, and creating a custom, robust alternative represents a significant undertaking. My hope was that an unordered option could be a valuable addition to the standard library, benefiting a wider range of developers.

Thank you again for your time and consideration.


On Mon, Jun 2, 2025 at 7:48?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>Even if it by default preserves input order, when I explicitly called stream.unordered(), could mapConcurrent() respect that and in return achieve higher throughput with support for race?

The Gatherer doesn't know whether the Stream is unordered or ordered. The operation should be semantically equivalent anyway.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 2 June 2025 16:29
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>; core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: [External] : Re: Should mapConcurrent() respect time order instead of input order?

Sorry. Forgot to copy to the mailing list.

On Mon, Jun 2, 2025 at 7:27?AM Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>> wrote:
Thanks Viktor!

I was thinking from my own experience that I wouldn't have automatically assumed that a concurrent fanout library would by default preserve input order.

And I think wanting high throughput with real-life utilities like race would be more commonly useful.

But I could be wrong.

Regardless, mapConcurrent() can do both, no?

Even if it by default preserves input order, when I explicitly called stream.unordered(), could mapConcurrent() respect that and in return achieve higher throughput with support for race?



On Mon, Jun 2, 2025 at 2:33?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi!

In a similar vein to the built-in Collectors,
the built-in Gatherers provide solutions to common stream-related problems, but also, they also serve as "inspiration" for developers for what is possible to implement using Gatherers.

If someone, for performance reasons, and with a use-case which does not require encounter-order, want to take advantage of that combination of circumstances, it is definitely possible to implement your own Gatherer which has that behavior.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Sunday, 1 June 2025 21:08
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Should mapConcurrent() respect time order instead of input order?

It seems like for most people, input order isn't that important for concurrent work, and concurrent results being in non-deterministic order is often expected.

If mapConcurrent() just respect output encounter order:

It'll be able to achieve higher throughput if an early task is slow, For example, with concurrency=2, and if the first task takes 10 minutes to run, mapConcurrent() would only be able to process 2 tasks within the first 10 minutes; whereas with encounter order, the first task being slow doesn't block the 3rd - 100th elements from being processed and output.

mapConcurrent() can be used to implement useful concurrent semantics, for example to support race semantics. Imagine if I need to send request to 10 candidate backends and take whichever that succeeds first, I'd be able to do:

backends.stream()
    .gather(mapConcurrent(
        backend -> {
          try {
            return backend.fetchOrder();
           } catch (RpcException e) {
             return null; // failed to fetch but not fatal
           }
        })
        .filter(Objects::notNull)
        .findFirst(); // first success then cancel the rest

Cheers,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250602/6dfd302a/attachment-0001.htm>

From cstein at openjdk.org  Mon Jun  2 16:06:50 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 2 Jun 2025 16:06:50 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment
In-Reply-To: <4Xzu7FifgELCGKkOTBMCpcgYwwKuqymJBpMSQHVFbcA=.95d8329e-453e-439f-a628-149ce8c22a51@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
 <tO_z8q0cawzrkDP_z__sUZbM2sWejgIHdwksIbFboUI=.1b657729-6541-4310-9117-d4f7f0d75a7a@github.com>
 <4Xzu7FifgELCGKkOTBMCpcgYwwKuqymJBpMSQHVFbcA=.95d8329e-453e-439f-a628-149ce8c22a51@github.com>
Message-ID: <1aNuDmukQdUIs83wrKGgzmEHIOgMMUtTtePU9dHsUyE=.6b73641a-ab98-4b37-af3d-08b06d73533b@github.com>

On Mon, 2 Jun 2025 15:08:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/java.base/share/native/libjli/args.c line 276:
>> 
>>> 274:                     }
>>> 275:                     pctx->cptr = nextc + 1;
>>> 276:                     return token;
>> 
>> This code duplicates a large part of the block of the previous case. Perhaps an internal helper method could be extracted?
>
> right I agree that if there is common code we should extract it in a helper method

Or the handling of `#` can be merged with the previous case ... somehow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2121594206

From viktor.klang at oracle.com  Mon Jun  2 16:37:18 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 2 Jun 2025 16:37:18 +0000
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <CAKD1RYtcmwqDbF+i6DEXJKvAnZ-WcCc7xrEK_tRygKucpDMxtw@mail.gmail.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtAUfyUHOdmSeZ2Azny=RJU63FQozY2NxpYu-4xQYCRkA@mail.gmail.com>
 <MW4PR10MB5774B089653C902899FEBEAFFFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB5774BB2B60EE5A1F4B1A7306FFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvxZ0gpHJXW0ctuHwEGwfStfjmLvwV1CgSWrr8438rWPA@mail.gmail.com>
 <MW4PR10MB5774EF4D4316B5BE46B29A0EFFF12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYsJyHeEs1fc4DRTZKwDO_U4Pyjv45BQ5fvr6VbboaVCTQ@mail.gmail.com>
 <MW4PR10MB57743363CCA3306B316F3EEDFF65A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYuPzVW+VHt_MzOrXW93iNv0A03JFSCV+yawCFeaLm=HsA@mail.gmail.com>
 <CAKD1RYtpahV4766wNodvcrSGFqJ6ereG1fUJFi-yEviOpLcb=Q@mail.gmail.com>
 <MW4PR10MB577459221CD425EFD5686426FF67A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYscAh46O77zw=S68DefM9Aonnn7DjCB_8YJ-eWTKSpNDQ@mail.gmail.com>
 <3f9e1798-2edb-47b9-9d33-b455055dbcf5@oracle.com>
 <CAKD1RYtcmwqDbF+i6DEXJKvAnZ-WcCc7xrEK_tRygKucpDMxtw@mail.gmail.com>
Message-ID: <SJ0PR10MB57664D873E06C6AFA8E72B5EFF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>

I talked to Doug about this today, and it doesn't seem tractable to throw a non InterruptedException on interrupt (at least not without leaving the interruption flag set).

While it should be possible to broadcast stream-evaluation-thread's interruption to tasks (without cancelling them) so that tasks can check Thread.interrupted() and throw some application-specific exception, it is still unsatisfactory for most use-cases.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Jige Yu <yujige at gmail.com>
Sent: Friday, 30 May 2025 00:44
To: David Holmes <david.holmes at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Yeah. I can see these distinctions and guidelines being useful for callers of the low-level concurrency primitive methods (semaphore etc.)

But at a higher level, in the application code, does anyone know of a plausible scenario where being forced to catch IE is useful? It seems like you either always propagate it up, or you have to catch it and risk forgetting to re-interrupt the thread. And, there is not much useful thing you can do that's different from other types of exceptions.

That's why I think it may be reasonable for mapConcurrent() to:

- absorb cancellation into the API contract and catch the IE
and throw a more semantically specific exception (an unchecked exception indicating the mapConcurrent() has been interrupted).

Thinking from two typical ways of IE scenarios:

  *   mapConcurrent() is wrapped in a Future, and the future is canceled - if you've canceled it, the unchecked exception shouldn't bother you.
  *   mapConcurrent() is inside an outer mapConcurrent(), or inside an outer structured concurrency scope - in either case, interruption happens because a sibling task has failed to trigger the fail-fast cancellation. Checked exceptions work fine too.

I can't see harm being done for either case, compared to letting it keep running through all elements (what if the stream is infinite or very very long?)

On Wed, May 28, 2025 at 10:19?PM David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>> wrote:
On 29/05/2025 3:45 am, Jige Yu wrote:
> 17.2.4 is specifically about the Object wait()/notify() API, yeah?
>
> I've always had this confusion in my mind that I couldn't find an
> authoritative source for: what was the point of checked
> InterruptedException?

Interruption and IE provide a limited capability for task cancellation.
As such any method that calls a method that can throw IE has to be aware
that the method can do that, and by having IE be checked, they are
forced to confront the question: how do I respond to cancellation? As
Doug Lea describes in his book there are a few ways to respond to this
cancellation notice depending on the semantics of the method involved:

- make cancellation part of your own API, declare and rethrow any IE
should encounter (and your caller then has to make the choice)
- absorb cancellation into your general API contract and catch the IE
and throw a more semantically specific exception
- handle low-level cancellation by catching the IE and doing whatever
logic is appropriate

David
-----

> My naive observation has been two fold:
>
>  1. In most cases, when possible, applications declare "throws IE" and
>     let it propagate all the way up the call stack. This works exactly
>     the same as if IE were unchecked.
>  2. When the application is cornered into a Runnable, Function and
>     cannot "throws IE", it has to catch(IE),  remember to re-interrupt
>     the thread, and wrap in an unchecked. Except *it often forgets to
>     re-interrupt*.
>
> At the lowest level concurrent primitives (wait(), notify(), Semaphore),
> I presume IE being an integral part of the API contract.
>
> But at mid-level APIs (Future, mapConcurrent()), or high-level
> applications, I've always been at a loss on why we needed the checked IE
> in the first place.
>
> IE used to happen when someone calls Future.cancel(true). Now with
> structured concurrency, it can also be caused by a sibling task failing
> and fail-fast.
>
> But aside from the extra ceremony and the extra room for error
> (forgetting to reinterrupt), what do we get from it? I was asking
> ChatGPT about real-life scenarios where specifically catching and
> handling IE is necessary but all ChatGPT gave me was cases where the
> code has to re-interrupt, which would have been unnecessary if IE were
> unchecked and didn't clear the interruption bit.
>
> Would appreciate a pointer to code or authoritative discussion about
> this matter.
>
> Sorry for the tangent!
>
>
> On Wed, May 28, 2025 at 1:03?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
> <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>> wrote:
>
>     It would seem to require a change to the Java Language Specification
>     section 17.2.4
>
>     Cheers,
>     ?
>
>     *
>     *
>     *Viktor Klang*
>     Software Architect, Java Platform Group
>     Oracle
>     ------------------------------------------------------------------------
>     *From:* Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com> <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>     *Sent:* Wednesday, 28 May 2025 00:35
>     *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>     <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>     *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>     <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>>
>     *Subject:* Re: [External] : Re: mapConcurrent() with
>     InterruptedException
>     That said, I'm still curious. Have you considered propagating
>     cancellation, re-interrupting the current thread, and then throwing
>     an unchecked exception upon interruption? It's going to be the most
>     fail-fast-compatible.
>
>     catch (IE interrupted) {
>        cancel all pending futures
>        Thread.currentThread().interrupt();
>        throw new UncheckedInterruptedException();
>     }
>
>     What are the concerns against such practice?
>
>
>
>
>
>     On Mon, May 26, 2025 at 8:31?AM Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>
>     <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>> wrote:
>
>         Yeah, I think I missed the task cancellation and the joining part.
>
>         When the mapConcurrent() thread is interrupted, it propagates
>         the cancellation to the child threads.
>
>         And if any of the children threads (running the user-provided
>         Function) receives that cancellation, it will still need to
>         catch it and handle interruption.
>
>         That means the interruption isn't swallowed. If the user code
>         wants to abort, they can always just throw an unchecked
>         exception and catch it from the caller of mapConcurrent().
>
>         That should do for most of the IO type work.
>
>         This makes sense.
>
>
>
>         On Mon, May 26, 2025 at 12:30?AM Viktor Klang
>         <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com> <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>> wrote:
>
>             Yes, the updated Gatherers.mapConcurrent will continue under
>             interruption until done, and then restore the interrupt
>             status of the calling thread.
>
>             It cannot (reasonably) do anything else?if it were to throw
>             InterruptedException, it couldn't since that is a checked
>             exception and there's no tracking of checked exceptions
>             throughout a Stream, and that is the specified behavior to
>             handle thread interrupts (i.e. clear flag and throw
>             InterruptedException, which is not possible in this case;
>             or, make sure that interrupt status is maintained, which is
>             possible in this case.
>
>             I have given it some more thought in the meantime, but I
>             haven't arrived in something more satisfactory than that, yet.
>
>             Cheers,
>             ?
>
>             *
>             *
>             *Viktor Klang*
>             Software Architect, Java Platform Group
>             Oracle
>             ------------------------------------------------------------------------
>             *From:* Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com> <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>             *Sent:* Monday, 26 May 2025 03:07
>             *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>             <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>             *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-<mailto:core-libs->
>             dev at openjdk.org<mailto:dev at openjdk.org>> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-<mailto:core->
>             libs-dev at openjdk.org<mailto:libs-dev at openjdk.org>>>
>             *Subject:* Re: [External] : Re: mapConcurrent() with
>             InterruptedException
>             Thanks Viktor!
>
>             Sorry, I was giving myself more time to read the code, but
>             then I lost track.
>
>             If I'm reading the code right, the current behavior is that
>             if the current thread is interrupted, the mapConcurrent()
>             would suppress the interruption until all elements are
>             processed? (It will then restore the interruption bit)
>
>             Doesn't this break fail fast?
>
>             For example, I may have a mapConcurrent() called from within
>             structured concurrency, and that fans out to two operations:
>             ?
>             scope.fork(() -> doA());
>             scope.fork(() -> doB());  // calls mapConcurrent() internally
>             scope.join().throwIfFailed();
>
>             If doA() fails, doB() will be cancelled (thread interrupted).
>
>             If mapConcurrent() ignores the interruption, and if doB has
>             a long list to process, it'll continue to consume system
>             resources even when the caller no longer needs the results, no?
>
>
>             On Fri, Feb 7, 2025 at 2:16?AM Viktor Klang
>             <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com> <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>             wrote:
>
>                  >Sorry, did the PR stop using Semaphore?
>
>                 No, not that PR. See: https://github.com/openjdk/jdk/
>                 commit/450636ae28b84ded083b6861c6cba85fbf87e16e
>                 <https://urldefense.com/v3/__https://github.com/openjdk/
>                 jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e__;!!
>                 ACWV5N9M2RV99hQ!
>                 OKfWrvJEDCkiHcT5b4a6gfeomZzZeq3jv6ir2vf2I5WWIhujtb-
>                 by_VuQFaAPDIuAA0qAwpTUjllXMPF$>
>
>                 The problem with interruption under parallel evaluation
>                 is that there is no general support for propagation of
>                 interruption in CountedCompleters. Adding support for
>                 such in (at least) GathererOp needs further study before
>                 contemplating making any changes to mapConcurrent()'s
>                 interruption policy.
>
>                 Cheers,
>                 ?
>
>                 *
>                 *
>                 *Viktor Klang*
>                 Software Architect, Java Platform Group
>                 Oracle
>
>                 ------------------------------------------------------------------------
>                 *From:* Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com> <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>                 *Sent:* Thursday, 6 February 2025 17:04
>                 *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                 <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>                 *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-<mailto:core-libs->
>                 dev at openjdk.org<mailto:dev at openjdk.org>> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
>                 <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>>
>                 *Subject:* Re: [External] : Re: mapConcurrent() with
>                 InterruptedException
>                 Sorry, did the PR stop using Semaphore?
>
>                 I had naively thought that mapConcurrent() will keep a
>                 buffer of Future of all currently-running concurrent
>                 tasks (it can be a ConcurrentMap<TaskKey, Future> if we
>                 don't have to ensure FIFO).
>
>                 Upon interruption, the main thread can
>                 call .cancel(true) on all pending Futures; optionally
>                 join with the VTs (if we need to block until all VTs
>                 exit); then propagate exception.
>
>                 Upon completion, each task just removes itself from the
>                 ConcurrentMap.
>
>                 Just in case it adds anything.
>
>
>
>                 On Thu, Feb 6, 2025 at 6:47?AM Viktor Klang
>                 <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                 <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>> wrote:
>
>                     After some more investigation it seems tractable to
>                     propagate interruption of the caller in sequential
>                     mode, but parallel mode will require much bigger
>                     considerations.
>
>                     I made a comment to that effect on the JBS issue:
>                     https://bugs.openjdk.org/browse/JDK-8349462?
>                     focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017 <https://bugs.openjdk.org/browse/JDK-8349462?focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017>
>
>
>                     Cheers,
>                     ?
>
>                     *
>                     *
>                     *Viktor Klang*
>                     Software Architect, Java Platform Group
>                     Oracle
>                     ------------------------------------------------------------------------
>                     *From:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                     <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>                     *Sent:* Thursday, 6 February 2025 11:51
>                     *To:* Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>
>                     <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>                     *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-<mailto:core-libs->
>                     dev at openjdk.org<mailto:dev at openjdk.org>> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
>                     <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>>
>                     *Subject:* Re: [External] : Re: mapConcurrent() with
>                     InterruptedException
>                     I think alignment in behavior between parallel
>                     Stream and mapConcurrent in terms of how
>                     interruptions are handled is a possible path forward.
>
>                     I decided to close the PR for now as I realized my
>                     parallel Stream example had misled me regarding its
>                     exception throwing, so I'll need to go back and
>                     refine the solution.
>
>                     It still seems solvable though.
>
>                     Cheers,
>                     ?
>
>                     *
>                     *
>                     *Viktor Klang*
>                     Software Architect, Java Platform Group
>                     Oracle
>                     ------------------------------------------------------------------------
>                     *From:* Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>
>                     <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>                     *Sent:* Wednesday, 5 February 2025 19:20
>                     *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                     <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>                     *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-<mailto:core-libs->
>                     dev at openjdk.org<mailto:dev at openjdk.org>> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
>                     <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>>
>                     *Subject:* Re: [External] : Re: mapConcurrent() with
>                     InterruptedException
>                     Oh good call!
>
>                     I forgot to check what parallel streams do upon
>                     interruption (didn't think they do any blocking
>                     calls, but at least the main thread must block).
>
>                     On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang
>                     <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                     <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>> wrote:
>
>                         Hi Jige,
>
>                         I opened an issue to track the concern, and I
>                         have proposed a change which seems to align well
>                         with how parallel streams behave under caller
>                         thread interruption.
>
>                         I've opened the following PR for review:
>                         https://github.com/openjdk/jdk/pull/23467
>                         <https://urldefense.com/v3/__https://github.com/
>                         openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!
>                         M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
>
>                         If you are able to make a local OpenJDK build
>                         with that solution you could check if it
>                         addresses your use-cases (or not).
>                         <https://urldefense.com/v3/__https://github.com/
>                         openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!
>                         M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
>
>                         8349462: Gatherers.mapConcurrent could support
>                         async interrupts by viktorklang-ora ? Pull
>                         Request #23467 ? openjdk/jdk <https://
>                         urldefense.com/v3/__https://github.com/openjdk/<http://urldefense.com/v3/__https://github.com/openjdk/>
>                         jdk/pull/23467__;!!ACWV5N9M2RV99hQ!
>                         M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
>                         This change is likely going to need some extra
>                         verbiage in the spec for mapConcurrent, and thus
>                         a CSR. This behavior aligns mapConcurrent with
>                         how parallel streams work in conjunction with
>                         interrup...
>                         github.com<http://github.com> <https://urldefense.com/v3/__http://
>                         github.com__;!!ACWV5N9M2RV99hQ!
>                         M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89DBkMefT$>
>
>
>
>                         Cheers,
>                         ?
>
>                         *
>                         *
>                         *Viktor Klang*
>                         Software Architect, Java Platform Group
>                         Oracle
>                         ------------------------------------------------------------------------
>                         *From:* Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>
>                         <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>                         *Sent:* Wednesday, 5 February 2025 16:24
>                         *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                         <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>                         *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-<mailto:core->
>                         libs-dev at openjdk.org<mailto:libs-dev at openjdk.org>> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
>                         <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>>
>                         *Subject:* Re: [External] : Re: mapConcurrent()
>                         with InterruptedException
>                         Thanks Viktor!
>
>                         I understand the problem.
>
>                         The main reason I asked is because I want to
>                         understand how the core Java team thinks of
>                         throwing an unchecked exception.
>
>                         As explained above, I consider losing
>                         cancellability a big deal, a deal breaker even.
>                         And I thought throwing unchecked is more
>                         acceptable. Because the most common reason the
>                         mapConcurrent() VT can be interrupted is due to
>                         cancellation from a parent mapConcurrent(), or a
>                         parent Structured Concurrency scope. The
>                         cancellation could be either from an organic
>                         exception, or from the downstream not needing
>                         more elements, like maybe due to findFirst()
>                         already getting an element.
>
>                         In both cases, since the concurrent operation is
>                         already cancelled (result ignored), what
>                         exception pops up to the top level isn't that
>                         big of a deal (perhaps only a log record will be
>                         seen?)
>
>                         But if the core Java team considers it a bad
>                         idea, I would love to learn and adjust.
>
>                         On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang
>                         <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                         <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>> wrote:
>
>                             Hi,
>
>                             The problem is that mapConcurrent cannot
>                             throw InterruptedException because that is a
>                             checked exception, so we cannot clear the
>                             interrupted flag and throw that exception.
>
>                             So the updated semantics is to not cut the
>                             stream short but instead run to completion,
>                             restoring the interruption flag.
>
>                             There exists a couple of alternatives to
>                             this approach which I am contemplating, but
>                             they need to be further explored before I
>                             consider moving forward with any of them.
>
>                             Cheers,
>                             ?
>
>                             *
>                             *
>                             *Viktor Klang*
>                             Software Architect, Java Platform Group
>                             Oracle
>                             ------------------------------------------------------------------------
>                             *From:* Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>
>                             <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>                             *Sent:* Monday, 27 January 2025 17:00
>                             *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                             <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>                             *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
>                             <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>> <core-
>                             libs-dev at openjdk.org<mailto:libs-dev at openjdk.org> <mailto:core-libs-<mailto:core-libs->
>                             dev at openjdk.org<mailto:dev at openjdk.org>>>
>                             *Subject:* Re: [External] : Re:
>                             mapConcurrent() with InterruptedException
>                             Thanks Viktor!
>
>                             It looks like the current fix ignores
>                             interruption.
>
>                             I want to make sure my concern of it
>                             defeating cancellation is heard and understood.
>
>                             The scenarios I worry about is for a
>                             mapConcurrent() that fans out to another
>                             method call, which internally calls
>                             mapConcurrent() as implementation detail.
>
>                             An example:
>
>                             List<RefundResponse>
>                             refundHelper(transaction)
>                             {  transaction.creditCardAccounts.stream()
>                               .gather(mapConcurrent(acct ->
>                             service.refund(acct))    .toList(); }
>                             transactions.stream()
>                               .gather(mapConcurrent(transaction ->
>                             refundHelper(transaction));
>
>
>                             It seems undesirable that in such a case all
>                             the service.refund() calls become non
>                             cancellable, because the only way the outer
>                             mapConcurrent() cancels the refundHelper()
>                             calls is through Thread.interrupt() the
>                             virtual threads that call refundHelper(),
>                             which would then be disabled by the inner
>                             mapConcurrent().
>
>                             Does this example make sense to you? I can
>                             further explain if anything isn't clear.
>
>                             But I want to make sure the decision to
>                             disable interruption is deliberate judgement
>                             call that such nested mapConcurrent() is
>                             unlikely,or not important.
>
>                             Cheers,
>
>
>
>                             On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang
>                             <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                             <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>> wrote:
>
>                                 Hi!
>
>                                 Please see: https://github.com/openjdk/
>                                 jdk/pull/23100 <https://urldefense.com/
>                                 v3/__https://github.com/openjdk/jdk/
>                                 pull/23100__;!!ACWV5N9M2RV99hQ!
>                                 IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>
>
>                                 Cheers,
>                                 ?
>
>                                 *
>                                 *
>                                 *Viktor Klang*
>                                 Software Architect, Java Platform Group
>                                 Oracle
>                                 ------------------------------------------------------------------------
>                                 *From:* Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>
>                                 <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>                                 *Sent:* Sunday, 26 January 2025 23:03
>                                 *To:* Viktor Klang
>                                 <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                                 <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>                                 *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
>                                 <mailto:core-libs-<mailto:core-libs->
>                                 dev at openjdk.org<mailto:dev at openjdk.org>> <core-libs-
>                                 dev at openjdk.org<mailto:dev at openjdk.org> <mailto:core-libs-<mailto:core-libs->
>                                 dev at openjdk.org<mailto:dev at openjdk.org>>>
>                                 *Subject:* [External] : Re:
>                                 mapConcurrent() with InterruptedException
>                                 Checking in on what you've found out,
>                                 Viktor.
>
>                                  From where we left off, I understand
>                                 that you were looking at alternatives
>                                 instead of silent truncation?
>
>                                 Have you reached any conclusion?
>
>                                 We touched on disallowing interruption
>                                 during mapConcurrent(). I still have
>                                 concerns with disabling cancellation,
>                                 because it basically undoes this API
>                                 note from the javadoc <https://
>                                 cr.openjdk.org/~alanb/sc-20240503/<http://cr.openjdk.org/~alanb/sc-20240503/>
>                                 java.base/java/util/stream/
>                                 Gatherers.html#mapConcurrent(int,java.util.function.Function)>:
>
>                                 API Note:
>
>                                     In progress tasks will be attempted
>                                     to be cancelled, on a best-effort
>                                     basis, in situations where the
>                                     downstream no longer wants to
>                                     receive any more elements.
>
>                                 In reality, people will use
>                                 mapConcurrent() to fan out rpcs.
>                                 Sometimes these rpcs are just a single
>                                 blocking call; yet sometimes they may
>                                 themselves be a Structured Concurrency
>                                 scope, with 2 or 3 rpcs that constitute
>                                 a single logical operation. Under two
>                                 conditions, cancellation is imho
>                                 important semantic:
>
>                                  1. The downstream code uses
>                                     filter().findFirst(), and when it
>                                     sees an element, it will return and
>                                     no longer needs the other pending
>                                     rpcs to complete. If cancellation is
>                                     disabled, these unnecessary rpcs
>                                     will waste system resources.
>                                  2. One of the rpc throws and the Stream
>                                     pipeline needs to propagate the
>                                     exception. Again, if the other rpcs
>                                     cannot be cancelled, we'll have many
>                                     zombie rpcs.
>
>                                 Zombie rpcs may or may not be a deal
>                                 breaker, depending on the specific use
>                                 case. But for a JDK library, losing
>                                 cancellation would have a negative
>                                 impact on usability.
>
>                                 My 2c,
>
>
>                                 On Fri, Jan 3, 2025 at 9:18?AM Viktor
>                                 Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                                 <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>> wrote:
>
>                                     Hi Ben,
>
>                                     Thanks for raising these questions?
>                                     getting feedback is crucial in the
>                                     Preview stage of features.
>
>                                     I wrote a reply to the Reddit thread
>                                     so I'll just summarize here:
>
>                                     It is important to note that /
>                                     mapConcurrent()/ is not a part of
>                                     the Structured Concurrency JEPs, so
>                                     it is not designed to join SC scopes.
>
>                                     I'm currently experimenting with
>                                     ignoring-but-restoring interrupts on
>                                     the "calling thread" for /
>                                     mapConcurrent()/, as well as capping
>                                     work-in-progress to /
>                                     maxConcurrency/ (not only capping
>                                     the concurrency but also the amount
>                                     of completed-but-yet-to-be-pushed
>                                     work). Both of these adjustments
>                                     should increase predictability of
>                                     behavior in the face of blocking
>                                     operations with variable delays.
>
>                                     Another adjustment I'm looking at
>                                     right now is to harden/improve the
>                                     cleanup to wait for concurrent tasks
>                                     to acknowledge cancellation, so that
>                                     once the finisher is done executing
>                                     the VTs are known to have terminated.
>
>                                     As for not preserving the encounter
>                                     order, that would be a completely
>                                     different thing, and I'd encourage
>                                     you to experiment with that if that
>                                     functionality would be interesting
>                                     for your use-case(s).
>
>                                     Again, thanks for your feedback!
>
>                                     Cheers,
>                                     ?
>
>                                     *
>                                     *
>                                     *Viktor Klang*
>                                     Software Architect, Java Platform Group
>                                     Oracle
>                                     ------------------------------------------------------------------------
>                                     *From:* core-libs-dev <core-libs-
>                                     dev-retn at openjdk.org<mailto:dev-retn at openjdk.org> <mailto:core-<mailto:core->
>                                     libs-dev-retn at openjdk.org<mailto:libs-dev-retn at openjdk.org>>> on
>                                     behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>
>                                     <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>                                     *Sent:* Friday, 3 January 2025 17:53
>                                     *To:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
>                                     <mailto:core-libs-<mailto:core-libs->
>                                     dev at openjdk.org<mailto:dev at openjdk.org>> <core-libs-
>                                     dev at openjdk.org<mailto:dev at openjdk.org> <mailto:core-libs-<mailto:core-libs->
>                                     dev at openjdk.org<mailto:dev at openjdk.org>>>
>                                     *Subject:* mapConcurrent() with
>                                     InterruptedException
>                                     Hi Java Experts,
>
>                                     I sent this email incorrectly to
>                                     loom-dev@ and was told on Reddit
>                                     that core-libs-dev is the right list.
>
>                                     The question is about the behavior
>                                     of mapConcurrent() when the thread
>                                     is interrupted.
>
>                                     Currently mapConcurrent()'s finisher
>                                     phase will re-interrupt the thread,
>                                     then stop at whatever element that
>                                     has already been processed and return.
>
>                                     This strikes me as a surprising
>                                     behavior, because for example if I'm
>                                     running:
>
>                                         Stream.of(1, 2, 3)
>                                              .gather(mapConcurrent(i ->
>                                     i * 2))
>                                              .toList()
>
>                                     and the thread is being interrupted,
>                                     the result could be any of [2], [2,
>                                     4] or [2, 4, 6].
>
>                                     Since thread interruption is
>                                     cooperative, there is no guarantee
>                                     that the thread being interrupted
>                                     will just abort. It's quite possible
>                                     that it'll keep going and then will
>                                     use for example [2] as the result of
>                                     doubling the list of [1, 2, 3],
>                                     which is imho incorrect.
>
>                                     In the Reddit <https://
>                                     urldefense.com/v3/__https://<http://urldefense.com/v3/__https://>
>                                     www.reddit.com/r/java/<http://www.reddit.com/r/java/>
>                                     comments/1hr8xyu/
>                                     observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread, someone argued that interruption rarely happens so it's more of a theoretical issue. But interruption can easily happen in Structured Concurrency or in mapConcurrent() itself if any subtask has failed in order to cancel/interrupt the other ongoing tasks.
>
>                                     There had been discussion about
>                                     alternative strategies:
>
>                                      1. Don't respond to interruption
>                                         and just keep running to completion.
>                                      2. Re-interrupt thread and wrap the
>                                         InterruptedException in a
>                                         standard unchecked exception
>                                         (StructuredConcurrencyInterruptedException?).
>
>
>                                     I have concerns with option 1
>                                     because it disables cancellation
>                                     propagation when mapConcurrent()
>                                     itself is used in a subtask of a
>                                     parent mapConcurrent() or in a
>                                     StructuredConcurrencyScope.
>
>                                     Both equivalent Future-composition
>                                     async code, or C++'s fiber trees
>                                     support cancellation propagation and
>                                     imho it's a critical feature or else
>                                     it's possible that a zombie thread
>                                     is still sending RPCs long after the
>                                     main thread has exited (failed, or
>                                     falled back to some default action).
>
>                                     My arguments for option 2:
>
>                                      1. InterruptedException is more
>                                         error prone than traditional
>                                         checked exceptions for
>                                         *users* to catch and handle.
>                                         They can forget to re-interrupt
>                                         the thread. It's so confusing
>                                         that even seasoned programmers
>                                         may not know they are *supposed
>                                         to* re-interrupt the thread.
>                                      2. With Stream API using functional
>                                         interfaces like Supplier,
>                                         Function, the option of just
>                                         tacking on "throws IE" isn't
>                                         available to many users.
>                                      3. With Virtual Threads, it will be
>                                         more acceptable, or even become
>                                         common to do blocking calls from
>                                         a stream operation (including
>                                         but exclusive to
>                                         mapConcurrent()). So the chance
>                                         users are forced to deal with IE
>                                         will become substantially higher.
>                                      4. Other APIs such as the
>                                         Structured Concurrency API have
>                                         already started wrapping system
>                                         checked exceptions like
>                                         ExecutionException,
>                                         TimeoutException in unchecked
>                                         exceptions ( join() <https://
>                                         urldefense.com/v3/__https://<http://urldefense.com/v3/__https://>
>                                         download.java.net/java/<http://download.java.net/java/>
>                                         early_access/loom/docs/api/
>                                         java.base/java/util/concurrent/
>                                         StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for example).
>                                      5. Imho, exceptions that we'd
>                                         rather users not catch and
>                                         handle but instead should mostly
>                                         just propagate up as is, should
>                                         be unchecked.
>
>                                     There is also a side discussion
>                                     <https://urldefense.com/v3/
>                                     __https://www.reddit.com/r/java/
>                                     comments/1hr8xyu/comment/m4z4f8c/?
>                                     utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about whether mapConcurrent() is better off preserving input order or push to downstream as soon as an element is computed. I'd love to discuss that topic too but maybe it's better to start a separate thread?
>
>                                     Thank you and cheers!
>
>                                     Ben Yu
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250602/a17c81a3/attachment-0001.htm>

From yujige at gmail.com  Mon Jun  2 16:49:17 2025
From: yujige at gmail.com (Jige Yu)
Date: Mon, 2 Jun 2025 09:49:17 -0700
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <SJ0PR10MB57664D873E06C6AFA8E72B5EFF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtAUfyUHOdmSeZ2Azny=RJU63FQozY2NxpYu-4xQYCRkA@mail.gmail.com>
 <MW4PR10MB5774B089653C902899FEBEAFFFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB5774BB2B60EE5A1F4B1A7306FFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvxZ0gpHJXW0ctuHwEGwfStfjmLvwV1CgSWrr8438rWPA@mail.gmail.com>
 <MW4PR10MB5774EF4D4316B5BE46B29A0EFFF12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYsJyHeEs1fc4DRTZKwDO_U4Pyjv45BQ5fvr6VbboaVCTQ@mail.gmail.com>
 <MW4PR10MB57743363CCA3306B316F3EEDFF65A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYuPzVW+VHt_MzOrXW93iNv0A03JFSCV+yawCFeaLm=HsA@mail.gmail.com>
 <CAKD1RYtpahV4766wNodvcrSGFqJ6ereG1fUJFi-yEviOpLcb=Q@mail.gmail.com>
 <MW4PR10MB577459221CD425EFD5686426FF67A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYscAh46O77zw=S68DefM9Aonnn7DjCB_8YJ-eWTKSpNDQ@mail.gmail.com>
 <3f9e1798-2edb-47b9-9d33-b455055dbcf5@oracle.com>
 <CAKD1RYtcmwqDbF+i6DEXJKvAnZ-WcCc7xrEK_tRygKucpDMxtw@mail.gmail.com>
 <SJ0PR10MB57664D873E06C6AFA8E72B5EFF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
Message-ID: <CAKD1RYtOO-XkAfHjk8GQibmLoKv7sMYrQhSYEO98KESNgBnJ2A@mail.gmail.com>

Thanks Viktor! I didn't realize I wasn't explicit about the "leave the
interruption bit set" part.

So no, if mapConcurrent() throws unchecked upon interruption, the
interruption bit must be set. There is no question about that, from my
part. :)

With that, do you still think throwing unchecked (with interruption bit
set) is unsatisfactory?



On Mon, Jun 2, 2025 at 9:37?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> I talked to Doug about this today, and it doesn't seem tractable to throw
> a non InterruptedException on interrupt (at least not without leaving the
> interruption flag set).
>
> While it should be possible to broadcast stream-evaluation-thread's
> interruption to tasks (*without* cancelling them) so that tasks can check
> Thread.interrupted() and throw some application-specific exception, it is
> still unsatisfactory for most use-cases.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Jige
> Yu <yujige at gmail.com>
> *Sent:* Friday, 30 May 2025 00:44
> *To:* David Holmes <david.holmes at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Yeah. I can see these distinctions and guidelines being useful for callers
> of the low-level concurrency primitive methods (semaphore etc.)
>
> But at a higher level, in the application code, does anyone know of a
> plausible scenario where being forced to catch IE is useful? It seems like
> you either always propagate it up, or you have to catch it and risk
> forgetting to re-interrupt the thread. And, *there is not much useful
> thing you can do* that's different from other types of exceptions.
>
> That's why I think it may be reasonable for mapConcurrent() to:
>
> - absorb cancellation into the API contract and catch the IE
> and throw a more semantically specific exception (an unchecked exception
> indicating the mapConcurrent() has been interrupted).
>
> Thinking from two typical ways of IE scenarios:
>
>    - mapConcurrent() is wrapped in a Future, and the future is canceled -
>    if you've canceled it, the unchecked exception shouldn't bother you.
>    - mapConcurrent() is inside an outer mapConcurrent(), or inside an
>    outer structured concurrency scope - in either case, interruption happens
>    because a sibling task has failed to trigger the fail-fast cancellation.
>    Checked exceptions work fine too.
>
> I can't see harm being done for either case, compared to letting it keep
> running through all elements (what if the stream is infinite or very very
> long?)
>
> On Wed, May 28, 2025 at 10:19?PM David Holmes <david.holmes at oracle.com>
> wrote:
>
> On 29/05/2025 3:45 am, Jige Yu wrote:
> > 17.2.4 is specifically about the Object wait()/notify() API, yeah?
> >
> > I've always had this confusion in my mind that I couldn't find an
> > authoritative source for: what was the point of checked
> > InterruptedException?
>
> Interruption and IE provide a limited capability for task cancellation.
> As such any method that calls a method that can throw IE has to be aware
> that the method can do that, and by having IE be checked, they are
> forced to confront the question: how do I respond to cancellation? As
> Doug Lea describes in his book there are a few ways to respond to this
> cancellation notice depending on the semantics of the method involved:
>
> - make cancellation part of your own API, declare and rethrow any IE
> should encounter (and your caller then has to make the choice)
> - absorb cancellation into your general API contract and catch the IE
> and throw a more semantically specific exception
> - handle low-level cancellation by catching the IE and doing whatever
> logic is appropriate
>
> David
> -----
>
> > My naive observation has been two fold:
> >
> >  1. In most cases, when possible, applications declare "throws IE" and
> >     let it propagate all the way up the call stack. This works exactly
> >     the same as if IE were unchecked.
> >  2. When the application is cornered into a Runnable, Function and
> >     cannot "throws IE", it has to catch(IE),  remember to re-interrupt
> >     the thread, and wrap in an unchecked. Except *it often forgets to
> >     re-interrupt*.
> >
> > At the lowest level concurrent primitives (wait(), notify(), Semaphore),
> > I presume IE being an integral part of the API contract.
> >
> > But at mid-level APIs (Future, mapConcurrent()), or high-level
> > applications, I've always been at a loss on why we needed the checked IE
> > in the first place.
> >
> > IE used to happen when someone calls Future.cancel(true). Now with
> > structured concurrency, it can also be caused by a sibling task failing
> > and fail-fast.
> >
> > But aside from the extra ceremony and the extra room for error
> > (forgetting to reinterrupt), what do we get from it? I was asking
> > ChatGPT about real-life scenarios where specifically catching and
> > handling IE is necessary but all ChatGPT gave me was cases where the
> > code has to re-interrupt, which would have been unnecessary if IE were
> > unchecked and didn't clear the interruption bit.
> >
> > Would appreciate a pointer to code or authoritative discussion about
> > this matter.
> >
> > Sorry for the tangent!
> >
> >
> > On Wed, May 28, 2025 at 1:03?AM Viktor Klang <viktor.klang at oracle.com
> > <mailto:viktor.klang at oracle.com>> wrote:
> >
> >     It would seem to require a change to the Java Language Specification
> >     section 17.2.4
> >
> >     Cheers,
> >     ?
> >
> >     *
> >     *
> >     *Viktor Klang*
> >     Software Architect, Java Platform Group
> >     Oracle
> >
>  ------------------------------------------------------------------------
> >     *From:* Jige Yu <yujige at gmail.com <mailto:yujige at gmail.com>>
> >     *Sent:* Wednesday, 28 May 2025 00:35
> >     *To:* Viktor Klang <viktor.klang at oracle.com
> >     <mailto:viktor.klang at oracle.com>>
> >     *Cc:* core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org>
> >     <core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org>>
> >     *Subject:* Re: [External] : Re: mapConcurrent() with
> >     InterruptedException
> >     That said, I'm still curious. Have you considered propagating
> >     cancellation, re-interrupting the current thread, and then throwing
> >     an unchecked exception upon interruption? It's going to be the most
> >     fail-fast-compatible.
> >
> >     catch (IE interrupted) {
> >        cancel all pending futures
> >        Thread.currentThread().interrupt();
> >        throw new UncheckedInterruptedException();
> >     }
> >
> >     What are the concerns against such practice?
> >
> >
> >
> >
> >
> >     On Mon, May 26, 2025 at 8:31?AM Jige Yu <yujige at gmail.com
> >     <mailto:yujige at gmail.com>> wrote:
> >
> >         Yeah, I think I missed the task cancellation and the joining
> part.
> >
> >         When the mapConcurrent() thread is interrupted, it propagates
> >         the cancellation to the child threads.
> >
> >         And if any of the children threads (running the user-provided
> >         Function) receives that cancellation, it will still need to
> >         catch it and handle interruption.
> >
> >         That means the interruption isn't swallowed. If the user code
> >         wants to abort, they can always just throw an unchecked
> >         exception and catch it from the caller of mapConcurrent().
> >
> >         That should do for most of the IO type work.
> >
> >         This makes sense.
> >
> >
> >
> >         On Mon, May 26, 2025 at 12:30?AM Viktor Klang
> >         <viktor.klang at oracle.com <mailto:viktor.klang at oracle.com>>
> wrote:
> >
> >             Yes, the updated Gatherers.mapConcurrent will continue under
> >             interruption until done, and then restore the interrupt
> >             status of the calling thread.
> >
> >             It cannot (reasonably) do anything else?if it were to throw
> >             InterruptedException, it couldn't since that is a checked
> >             exception and there's no tracking of checked exceptions
> >             throughout a Stream, and that is the specified behavior to
> >             handle thread interrupts (i.e. clear flag and throw
> >             InterruptedException, which is not possible in this case;
> >             or, make sure that interrupt status is maintained, which is
> >             possible in this case.
> >
> >             I have given it some more thought in the meantime, but I
> >             haven't arrived in something more satisfactory than that,
> yet.
> >
> >             Cheers,
> >             ?
> >
> >             *
> >             *
> >             *Viktor Klang*
> >             Software Architect, Java Platform Group
> >             Oracle
> >
>  ------------------------------------------------------------------------
> >             *From:* Jige Yu <yujige at gmail.com <mailto:yujige at gmail.com>>
> >             *Sent:* Monday, 26 May 2025 03:07
> >             *To:* Viktor Klang <viktor.klang at oracle.com
> >             <mailto:viktor.klang at oracle.com>>
> >             *Cc:* core-libs-dev at openjdk.org <mailto:core-libs-
> >             dev at openjdk.org> <core-libs-dev at openjdk.org <mailto:core-
> >             libs-dev at openjdk.org>>
> >             *Subject:* Re: [External] : Re: mapConcurrent() with
> >             InterruptedException
> >             Thanks Viktor!
> >
> >             Sorry, I was giving myself more time to read the code, but
> >             then I lost track.
> >
> >             If I'm reading the code right, the current behavior is that
> >             if the current thread is interrupted, the mapConcurrent()
> >             would suppress the interruption until all elements are
> >             processed? (It will then restore the interruption bit)
> >
> >             Doesn't this break fail fast?
> >
> >             For example, I may have a mapConcurrent() called from within
> >             structured concurrency, and that fans out to two operations:
> >             ?
> >             scope.fork(() -> doA());
> >             scope.fork(() -> doB());  // calls mapConcurrent() internally
> >             scope.join().throwIfFailed();
> >
> >             If doA() fails, doB() will be cancelled (thread interrupted).
> >
> >             If mapConcurrent() ignores the interruption, and if doB has
> >             a long list to process, it'll continue to consume system
> >             resources even when the caller no longer needs the results,
> no?
> >
> >
> >             On Fri, Feb 7, 2025 at 2:16?AM Viktor Klang
> >             <viktor.klang at oracle.com <mailto:viktor.klang at oracle.com>>
> >             wrote:
> >
> >                  >Sorry, did the PR stop using Semaphore?
> >
> >                 No, not that PR. See: https://github.com/openjdk/jdk/
> >                 commit/450636ae28b84ded083b6861c6cba85fbf87e16e
> >                 <https://urldefense.com/v3/__https://github.com/openjdk/
> >                 jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e__;!!
> >                 ACWV5N9M2RV99hQ!
> >                 OKfWrvJEDCkiHcT5b4a6gfeomZzZeq3jv6ir2vf2I5WWIhujtb-
> >                 by_VuQFaAPDIuAA0qAwpTUjllXMPF$>
> >
> >                 The problem with interruption under parallel evaluation
> >                 is that there is no general support for propagation of
> >                 interruption in CountedCompleters. Adding support for
> >                 such in (at least) GathererOp needs further study before
> >                 contemplating making any changes to mapConcurrent()'s
> >                 interruption policy.
> >
> >                 Cheers,
> >                 ?
> >
> >                 *
> >                 *
> >                 *Viktor Klang*
> >                 Software Architect, Java Platform Group
> >                 Oracle
> >
> >
>  ------------------------------------------------------------------------
> >                 *From:* Jige Yu <yujige at gmail.com <mailto:
> yujige at gmail.com>>
> >                 *Sent:* Thursday, 6 February 2025 17:04
> >                 *To:* Viktor Klang <viktor.klang at oracle.com
> >                 <mailto:viktor.klang at oracle.com>>
> >                 *Cc:* core-libs-dev at openjdk.org <mailto:core-libs-
> >                 dev at openjdk.org> <core-libs-dev at openjdk.org
> >                 <mailto:core-libs-dev at openjdk.org>>
> >                 *Subject:* Re: [External] : Re: mapConcurrent() with
> >                 InterruptedException
> >                 Sorry, did the PR stop using Semaphore?
> >
> >                 I had naively thought that mapConcurrent() will keep a
> >                 buffer of Future of all currently-running concurrent
> >                 tasks (it can be a ConcurrentMap<TaskKey, Future> if we
> >                 don't have to ensure FIFO).
> >
> >                 Upon interruption, the main thread can
> >                 call .cancel(true) on all pending Futures; optionally
> >                 join with the VTs (if we need to block until all VTs
> >                 exit); then propagate exception.
> >
> >                 Upon completion, each task just removes itself from the
> >                 ConcurrentMap.
> >
> >                 Just in case it adds anything.
> >
> >
> >
> >                 On Thu, Feb 6, 2025 at 6:47?AM Viktor Klang
> >                 <viktor.klang at oracle.com
> >                 <mailto:viktor.klang at oracle.com>> wrote:
> >
> >                     After some more investigation it seems tractable to
> >                     propagate interruption of the caller in sequential
> >                     mode, but parallel mode will require much bigger
> >                     considerations.
> >
> >                     I made a comment to that effect on the JBS issue:
> >                     https://bugs.openjdk.org/browse/JDK-8349462?
> >
>  focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017
> <
> https://bugs.openjdk.org/browse/JDK-8349462?focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017
> >
> >
> >
> >                     Cheers,
> >                     ?
> >
> >                     *
> >                     *
> >                     *Viktor Klang*
> >                     Software Architect, Java Platform Group
> >                     Oracle
> >
>  ------------------------------------------------------------------------
> >                     *From:* Viktor Klang <viktor.klang at oracle.com
> >                     <mailto:viktor.klang at oracle.com>>
> >                     *Sent:* Thursday, 6 February 2025 11:51
> >                     *To:* Jige Yu <yujige at gmail.com
> >                     <mailto:yujige at gmail.com>>
> >                     *Cc:* core-libs-dev at openjdk.org <mailto:core-libs-
> >                     dev at openjdk.org> <core-libs-dev at openjdk.org
> >                     <mailto:core-libs-dev at openjdk.org>>
> >                     *Subject:* Re: [External] : Re: mapConcurrent() with
> >                     InterruptedException
> >                     I think alignment in behavior between parallel
> >                     Stream and mapConcurrent in terms of how
> >                     interruptions are handled is a possible path forward.
> >
> >                     I decided to close the PR for now as I realized my
> >                     parallel Stream example had misled me regarding its
> >                     exception throwing, so I'll need to go back and
> >                     refine the solution.
> >
> >                     It still seems solvable though.
> >
> >                     Cheers,
> >                     ?
> >
> >                     *
> >                     *
> >                     *Viktor Klang*
> >                     Software Architect, Java Platform Group
> >                     Oracle
> >
>  ------------------------------------------------------------------------
> >                     *From:* Jige Yu <yujige at gmail.com
> >                     <mailto:yujige at gmail.com>>
> >                     *Sent:* Wednesday, 5 February 2025 19:20
> >                     *To:* Viktor Klang <viktor.klang at oracle.com
> >                     <mailto:viktor.klang at oracle.com>>
> >                     *Cc:* core-libs-dev at openjdk.org <mailto:core-libs-
> >                     dev at openjdk.org> <core-libs-dev at openjdk.org
> >                     <mailto:core-libs-dev at openjdk.org>>
> >                     *Subject:* Re: [External] : Re: mapConcurrent() with
> >                     InterruptedException
> >                     Oh good call!
> >
> >                     I forgot to check what parallel streams do upon
> >                     interruption (didn't think they do any blocking
> >                     calls, but at least the main thread must block).
> >
> >                     On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang
> >                     <viktor.klang at oracle.com
> >                     <mailto:viktor.klang at oracle.com>> wrote:
> >
> >                         Hi Jige,
> >
> >                         I opened an issue to track the concern, and I
> >                         have proposed a change which seems to align well
> >                         with how parallel streams behave under caller
> >                         thread interruption.
> >
> >                         I've opened the following PR for review:
> >                         https://github.com/openjdk/jdk/pull/23467
> >                         <https://urldefense.com/v3/__https://github.com/
> >                         openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!
> >
>  M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
> >
> >                         If you are able to make a local OpenJDK build
> >                         with that solution you could check if it
> >                         addresses your use-cases (or not).
> >                         <https://urldefense.com/v3/__https://github.com/
> >                         openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!
> >
>  M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
> >
> >                         8349462: Gatherers.mapConcurrent could support
> >                         async interrupts by viktorklang-ora ? Pull
> >                         Request #23467 ? openjdk/jdk <https://
> >                         urldefense.com/v3/__https://github.com/openjdk/
> >                         jdk/pull/23467__;!!ACWV5N9M2RV99hQ!
> >
>  M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
> >                         This change is likely going to need some extra
> >                         verbiage in the spec for mapConcurrent, and thus
> >                         a CSR. This behavior aligns mapConcurrent with
> >                         how parallel streams work in conjunction with
> >                         interrup...
> >                         github.com <https://urldefense.com/v3/__http://
> >                         github.com__;!!ACWV5N9M2RV99hQ!
> >
>  M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89DBkMefT$>
> >
> >
> >
> >                         Cheers,
> >                         ?
> >
> >                         *
> >                         *
> >                         *Viktor Klang*
> >                         Software Architect, Java Platform Group
> >                         Oracle
> >
>  ------------------------------------------------------------------------
> >                         *From:* Jige Yu <yujige at gmail.com
> >                         <mailto:yujige at gmail.com>>
> >                         *Sent:* Wednesday, 5 February 2025 16:24
> >                         *To:* Viktor Klang <viktor.klang at oracle.com
> >                         <mailto:viktor.klang at oracle.com>>
> >                         *Cc:* core-libs-dev at openjdk.org <mailto:core-
> >                         libs-dev at openjdk.org> <core-libs-dev at openjdk.org
> >                         <mailto:core-libs-dev at openjdk.org>>
> >                         *Subject:* Re: [External] : Re: mapConcurrent()
> >                         with InterruptedException
> >                         Thanks Viktor!
> >
> >                         I understand the problem.
> >
> >                         The main reason I asked is because I want to
> >                         understand how the core Java team thinks of
> >                         throwing an unchecked exception.
> >
> >                         As explained above, I consider losing
> >                         cancellability a big deal, a deal breaker even.
> >                         And I thought throwing unchecked is more
> >                         acceptable. Because the most common reason the
> >                         mapConcurrent() VT can be interrupted is due to
> >                         cancellation from a parent mapConcurrent(), or a
> >                         parent Structured Concurrency scope. The
> >                         cancellation could be either from an organic
> >                         exception, or from the downstream not needing
> >                         more elements, like maybe due to findFirst()
> >                         already getting an element.
> >
> >                         In both cases, since the concurrent operation is
> >                         already cancelled (result ignored), what
> >                         exception pops up to the top level isn't that
> >                         big of a deal (perhaps only a log record will be
> >                         seen?)
> >
> >                         But if the core Java team considers it a bad
> >                         idea, I would love to learn and adjust.
> >
> >                         On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang
> >                         <viktor.klang at oracle.com
> >                         <mailto:viktor.klang at oracle.com>> wrote:
> >
> >                             Hi,
> >
> >                             The problem is that mapConcurrent cannot
> >                             throw InterruptedException because that is a
> >                             checked exception, so we cannot clear the
> >                             interrupted flag and throw that exception.
> >
> >                             So the updated semantics is to not cut the
> >                             stream short but instead run to completion,
> >                             restoring the interruption flag.
> >
> >                             There exists a couple of alternatives to
> >                             this approach which I am contemplating, but
> >                             they need to be further explored before I
> >                             consider moving forward with any of them.
> >
> >                             Cheers,
> >                             ?
> >
> >                             *
> >                             *
> >                             *Viktor Klang*
> >                             Software Architect, Java Platform Group
> >                             Oracle
> >
>  ------------------------------------------------------------------------
> >                             *From:* Jige Yu <yujige at gmail.com
> >                             <mailto:yujige at gmail.com>>
> >                             *Sent:* Monday, 27 January 2025 17:00
> >                             *To:* Viktor Klang <viktor.klang at oracle.com
> >                             <mailto:viktor.klang at oracle.com>>
> >                             *Cc:* core-libs-dev at openjdk.org
> >                             <mailto:core-libs-dev at openjdk.org> <core-
> >                             libs-dev at openjdk.org <mailto:core-libs-
> >                             dev at openjdk.org>>
> >                             *Subject:* Re: [External] : Re:
> >                             mapConcurrent() with InterruptedException
> >                             Thanks Viktor!
> >
> >                             It looks like the current fix ignores
> >                             interruption.
> >
> >                             I want to make sure my concern of it
> >                             defeating cancellation is heard and
> understood.
> >
> >                             The scenarios I worry about is for a
> >                             mapConcurrent() that fans out to another
> >                             method call, which internally calls
> >                             mapConcurrent() as implementation detail.
> >
> >                             An example:
> >
> >                             List<RefundResponse>
> >                             refundHelper(transaction)
> >                             {  transaction.creditCardAccounts.stream()
> >                               .gather(mapConcurrent(acct ->
> >                             service.refund(acct))    .toList(); }
> >                             transactions.stream()
> >                               .gather(mapConcurrent(transaction ->
> >                             refundHelper(transaction));
> >
> >
> >                             It seems undesirable that in such a case all
> >                             the service.refund() calls become non
> >                             cancellable, because the only way the outer
> >                             mapConcurrent() cancels the refundHelper()
> >                             calls is through Thread.interrupt() the
> >                             virtual threads that call refundHelper(),
> >                             which would then be disabled by the inner
> >                             mapConcurrent().
> >
> >                             Does this example make sense to you? I can
> >                             further explain if anything isn't clear.
> >
> >                             But I want to make sure the decision to
> >                             disable interruption is deliberate judgement
> >                             call that such nested mapConcurrent() is
> >                             unlikely,or not important.
> >
> >                             Cheers,
> >
> >
> >
> >                             On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang
> >                             <viktor.klang at oracle.com
> >                             <mailto:viktor.klang at oracle.com>> wrote:
> >
> >                                 Hi!
> >
> >                                 Please see: https://github.com/openjdk/
> >                                 jdk/pull/23100 <https://urldefense.com/
> >                                 v3/__https://github.com/openjdk/jdk/
> >                                 pull/23100__;!!ACWV5N9M2RV99hQ!
> >
>  IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>
> >
> >                                 Cheers,
> >                                 ?
> >
> >                                 *
> >                                 *
> >                                 *Viktor Klang*
> >                                 Software Architect, Java Platform Group
> >                                 Oracle
> >
>  ------------------------------------------------------------------------
> >                                 *From:* Jige Yu <yujige at gmail.com
> >                                 <mailto:yujige at gmail.com>>
> >                                 *Sent:* Sunday, 26 January 2025 23:03
> >                                 *To:* Viktor Klang
> >                                 <viktor.klang at oracle.com
> >                                 <mailto:viktor.klang at oracle.com>>
> >                                 *Cc:* core-libs-dev at openjdk.org
> >                                 <mailto:core-libs-
> >                                 dev at openjdk.org> <core-libs-
> >                                 dev at openjdk.org <mailto:core-libs-
> >                                 dev at openjdk.org>>
> >                                 *Subject:* [External] : Re:
> >                                 mapConcurrent() with InterruptedException
> >                                 Checking in on what you've found out,
> >                                 Viktor.
> >
> >                                  From where we left off, I understand
> >                                 that you were looking at alternatives
> >                                 instead of silent truncation?
> >
> >                                 Have you reached any conclusion?
> >
> >                                 We touched on disallowing interruption
> >                                 during mapConcurrent(). I still have
> >                                 concerns with disabling cancellation,
> >                                 because it basically undoes this API
> >                                 note from the javadoc <https://
> >                                 cr.openjdk.org/~alanb/sc-20240503/
> >                                 java.base/java/util/stream/
> >
>  Gatherers.html#mapConcurrent(int,java.util.function.Function)>:
> >
> >                                 API Note:
> >
> >                                     In progress tasks will be attempted
> >                                     to be cancelled, on a best-effort
> >                                     basis, in situations where the
> >                                     downstream no longer wants to
> >                                     receive any more elements.
> >
> >                                 In reality, people will use
> >                                 mapConcurrent() to fan out rpcs.
> >                                 Sometimes these rpcs are just a single
> >                                 blocking call; yet sometimes they may
> >                                 themselves be a Structured Concurrency
> >                                 scope, with 2 or 3 rpcs that constitute
> >                                 a single logical operation. Under two
> >                                 conditions, cancellation is imho
> >                                 important semantic:
> >
> >                                  1. The downstream code uses
> >                                     filter().findFirst(), and when it
> >                                     sees an element, it will return and
> >                                     no longer needs the other pending
> >                                     rpcs to complete. If cancellation is
> >                                     disabled, these unnecessary rpcs
> >                                     will waste system resources.
> >                                  2. One of the rpc throws and the Stream
> >                                     pipeline needs to propagate the
> >                                     exception. Again, if the other rpcs
> >                                     cannot be cancelled, we'll have many
> >                                     zombie rpcs.
> >
> >                                 Zombie rpcs may or may not be a deal
> >                                 breaker, depending on the specific use
> >                                 case. But for a JDK library, losing
> >                                 cancellation would have a negative
> >                                 impact on usability.
> >
> >                                 My 2c,
> >
> >
> >                                 On Fri, Jan 3, 2025 at 9:18?AM Viktor
> >                                 Klang <viktor.klang at oracle.com
> >                                 <mailto:viktor.klang at oracle.com>> wrote:
> >
> >                                     Hi Ben,
> >
> >                                     Thanks for raising these questions?
> >                                     getting feedback is crucial in the
> >                                     Preview stage of features.
> >
> >                                     I wrote a reply to the Reddit thread
> >                                     so I'll just summarize here:
> >
> >                                     It is important to note that /
> >                                     mapConcurrent()/ is not a part of
> >                                     the Structured Concurrency JEPs, so
> >                                     it is not designed to join SC scopes.
> >
> >                                     I'm currently experimenting with
> >                                     ignoring-but-restoring interrupts on
> >                                     the "calling thread" for /
> >                                     mapConcurrent()/, as well as capping
> >                                     work-in-progress to /
> >                                     maxConcurrency/ (not only capping
> >                                     the concurrency but also the amount
> >                                     of completed-but-yet-to-be-pushed
> >                                     work). Both of these adjustments
> >                                     should increase predictability of
> >                                     behavior in the face of blocking
> >                                     operations with variable delays.
> >
> >                                     Another adjustment I'm looking at
> >                                     right now is to harden/improve the
> >                                     cleanup to wait for concurrent tasks
> >                                     to acknowledge cancellation, so that
> >                                     once the finisher is done executing
> >                                     the VTs are known to have terminated.
> >
> >                                     As for not preserving the encounter
> >                                     order, that would be a completely
> >                                     different thing, and I'd encourage
> >                                     you to experiment with that if that
> >                                     functionality would be interesting
> >                                     for your use-case(s).
> >
> >                                     Again, thanks for your feedback!
> >
> >                                     Cheers,
> >                                     ?
> >
> >                                     *
> >                                     *
> >                                     *Viktor Klang*
> >                                     Software Architect, Java Platform
> Group
> >                                     Oracle
> >
>  ------------------------------------------------------------------------
> >                                     *From:* core-libs-dev <core-libs-
> >                                     dev-retn at openjdk.org <mailto:core-
> >                                     libs-dev-retn at openjdk.org>> on
> >                                     behalf of Jige Yu <yujige at gmail.com
> >                                     <mailto:yujige at gmail.com>>
> >                                     *Sent:* Friday, 3 January 2025 17:53
> >                                     *To:* core-libs-dev at openjdk.org
> >                                     <mailto:core-libs-
> >                                     dev at openjdk.org> <core-libs-
> >                                     dev at openjdk.org <mailto:core-libs-
> >                                     dev at openjdk.org>>
> >                                     *Subject:* mapConcurrent() with
> >                                     InterruptedException
> >                                     Hi Java Experts,
> >
> >                                     I sent this email incorrectly to
> >                                     loom-dev@ and was told on Reddit
> >                                     that core-libs-dev is the right list.
> >
> >                                     The question is about the behavior
> >                                     of mapConcurrent() when the thread
> >                                     is interrupted.
> >
> >                                     Currently mapConcurrent()'s finisher
> >                                     phase will re-interrupt the thread,
> >                                     then stop at whatever element that
> >                                     has already been processed and
> return.
> >
> >                                     This strikes me as a surprising
> >                                     behavior, because for example if I'm
> >                                     running:
> >
> >                                         Stream.of(1, 2, 3)
> >                                              .gather(mapConcurrent(i ->
> >                                     i * 2))
> >                                              .toList()
> >
> >                                     and the thread is being interrupted,
> >                                     the result could be any of [2], [2,
> >                                     4] or [2, 4, 6].
> >
> >                                     Since thread interruption is
> >                                     cooperative, there is no guarantee
> >                                     that the thread being interrupted
> >                                     will just abort. It's quite possible
> >                                     that it'll keep going and then will
> >                                     use for example [2] as the result of
> >                                     doubling the list of [1, 2, 3],
> >                                     which is imho incorrect.
> >
> >                                     In the Reddit <https://
> >                                     urldefense.com/v3/__https://
> >                                     www.reddit.com/r/java/
> >                                     comments/1hr8xyu/
> >
>  observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread,
> someone argued that interruption rarely happens so it's more of a
> theoretical issue. But interruption can easily happen in Structured
> Concurrency or in mapConcurrent() itself if any subtask has failed in order
> to cancel/interrupt the other ongoing tasks.
> >
> >                                     There had been discussion about
> >                                     alternative strategies:
> >
> >                                      1. Don't respond to interruption
> >                                         and just keep running to
> completion.
> >                                      2. Re-interrupt thread and wrap the
> >                                         InterruptedException in a
> >                                         standard unchecked exception
> >
>  (StructuredConcurrencyInterruptedException?).
> >
> >
> >                                     I have concerns with option 1
> >                                     because it disables cancellation
> >                                     propagation when mapConcurrent()
> >                                     itself is used in a subtask of a
> >                                     parent mapConcurrent() or in a
> >                                     StructuredConcurrencyScope.
> >
> >                                     Both equivalent Future-composition
> >                                     async code, or C++'s fiber trees
> >                                     support cancellation propagation and
> >                                     imho it's a critical feature or else
> >                                     it's possible that a zombie thread
> >                                     is still sending RPCs long after the
> >                                     main thread has exited (failed, or
> >                                     falled back to some default action).
> >
> >                                     My arguments for option 2:
> >
> >                                      1. InterruptedException is more
> >                                         error prone than traditional
> >                                         checked exceptions for
> >                                         *users* to catch and handle.
> >                                         They can forget to re-interrupt
> >                                         the thread. It's so confusing
> >                                         that even seasoned programmers
> >                                         may not know they are *supposed
> >                                         to* re-interrupt the thread.
> >                                      2. With Stream API using functional
> >                                         interfaces like Supplier,
> >                                         Function, the option of just
> >                                         tacking on "throws IE" isn't
> >                                         available to many users.
> >                                      3. With Virtual Threads, it will be
> >                                         more acceptable, or even become
> >                                         common to do blocking calls from
> >                                         a stream operation (including
> >                                         but exclusive to
> >                                         mapConcurrent()). So the chance
> >                                         users are forced to deal with IE
> >                                         will become substantially higher.
> >                                      4. Other APIs such as the
> >                                         Structured Concurrency API have
> >                                         already started wrapping system
> >                                         checked exceptions like
> >                                         ExecutionException,
> >                                         TimeoutException in unchecked
> >                                         exceptions ( join() <https://
> >                                         urldefense.com/v3/__https://
> >                                         download.java.net/java/
> >                                         early_access/loom/docs/api/
> >                                         java.base/java/util/concurrent/
> >
>  StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for
> example).
> >                                      5. Imho, exceptions that we'd
> >                                         rather users not catch and
> >                                         handle but instead should mostly
> >                                         just propagate up as is, should
> >                                         be unchecked.
> >
> >                                     There is also a side discussion
> >                                     <https://urldefense.com/v3/
> >                                     __https://www.reddit.com/r/java/
> >                                     comments/1hr8xyu/comment/m4z4f8c/?
> >
>  utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about
> whether mapConcurrent() is better off preserving input order or push to
> downstream as soon as an element is computed. I'd love to discuss that
> topic too but maybe it's better to start a separate thread?
> >
> >                                     Thank you and cheers!
> >
> >                                     Ben Yu
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250602/2254b2c5/attachment-0001.htm>

From yujige at gmail.com  Mon Jun  2 16:54:08 2025
From: yujige at gmail.com (Jige Yu)
Date: Mon, 2 Jun 2025 09:54:08 -0700
Subject: [External] : Re: Should mapConcurrent() respect time order
 instead of input order?
In-Reply-To: <SJ0PR10MB5766DB20AB83B1199C7987EAFF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
References: <CAKD1RYuoK07OvAn02v4qq74Q1QDfpQpf=t0J0VT-s1zi4iKRnA@mail.gmail.com>
 <MW4PR10MB5774AED3EC215ED5AB3AD52CFF62A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtLy_yC+L5+q1YOkbEvUis5LJ-tJNJDbyoptq8A=+W3eg@mail.gmail.com>
 <CAKD1RYuksGCWsqj6cnu3aoHqkzAepLeNHsGSX_nCi2QryJaGMQ@mail.gmail.com>
 <SJ0PR10MB5766DAA744887EE8B0A2B991FF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYvhpcD=yAGAvTTi+c8sdjDAi776GCPCAdvsCCVF9JQpeQ@mail.gmail.com>
 <SJ0PR10MB5766DB20AB83B1199C7987EAFF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
Message-ID: <CAKD1RYst6GOErvVozZ2SD6JGhTRUAugSHZFM7aY+5Je72iF3wA@mail.gmail.com>

Hi Viktor,

Thanks for your reply and for sharing your experience regarding user
preferences. I appreciate that perspective.

You're right, if an unordered version of mapConcurrent proves to be widely
beneficial and is implemented and adopted by the community, it could
certainly make a strong case for future inclusion in the JDK.

I wanted to clarify a nuance regarding user preference that I might not
have articulated clearly before. If the question is simply "ordered or
unordered?", in isolation, I can see why many, myself included, might lean
towards "ordered" as a general preference.

However, the decision becomes more complex when the associated trade-offs
are considered. If the question were phrased more like, "Do you prefer an
ordered mapConcurrent by default, even if it entails potential performance
overhead and limitations for certain use cases like race() operations,
versus an unordered version that offers higher throughput and broader
applicability in such scenarios?" my (and perhaps others') answer might
differ. The perceived cost versus benefit of ordering changes significantly
when these factors are explicit.

My initial suggestion stemmed from the belief that the performance and
flexibility gains of an unordered approach for I/O-bound tasks would, in
many practical situations, outweigh the convenience of default ordering,
especially since ordering can be reintroduced relatively easily, and
explicitly, when needed.

Thanks again for the discussion.

Best regards,

On Mon, Jun 2, 2025 at 8:51?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> >My perspective is that strict adherence to input order for
> mapConcurrent() might not be the most common or beneficial default
> behavior for users.
>
> If there is indeed a *majority* who would benefit from an unordered
> version of mapConcurrent (my experience is that the majority prefer
> ordered) then, since it is possible to implement such a Gatherer outside of
> the JDK, this is something which will be constructed, widely used, and
> someone will then propose to add something similar to the JDK.
>
> >While re-implementing the gatherer is a possibility, the existing
> implementation is non-trivial, and creating a custom, robust alternative
> represents a significant undertaking.
>
> The existing version needs to maintain order, which adds to the complexity
> of the implementation. Implementing an unordered version would likely look
> different.
> I'd definitely encourage taking the opportunity to attempt to implement it.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
>
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 2 June 2025 17:05
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Should mapConcurrent() respect time order
> instead of input order?
>
>
> Thank you for your response and for considering my feedback on the
> mapConcurrent() gatherer. I understand and respect that the final
> decision rests with the JDK maintainers.
>
> I would like to offer a couple of further points for consideration. My
> perspective is that strict adherence to input order for mapConcurrent() might
> not be the most common or beneficial default behavior for users. I'd be
> very interested to see any research or data that suggests otherwise, as
> that would certainly inform my understanding.
>
> From my experience, a more common need is for higher throughput in
> I/O-intensive operations. The ability to support use cases like race()?where
> the first successfully completed operation determines the outcome?also
> seems like a valuable capability that is currently infeasible due to the
> ordering constraint.
>
> As I see it, if a developer specifically requires the input order to be
> preserved, this can be achieved with relative ease by applying a subsequent
> sorting operation. For instance:
>
> .gather(mapConcurrent(...))
> .sorted(Comparator.comparing(Result::getInputSequenceId))
>
> The primary challenge in these scenarios is typically the efficient
> fan-out and execution of concurrent tasks, not the subsequent sorting of
> results.
>
> Conversely, as you've noted, there isn't a straightforward way to modify
> the current default ordered behavior to achieve the higher throughput or
> race() semantics that an unordered approach would naturally provide.
>
> While re-implementing the gatherer is a possibility, the existing
> implementation is non-trivial, and creating a custom, robust alternative
> represents a significant undertaking. My hope was that an unordered option
> could be a valuable addition to the standard library, benefiting a wider
> range of developers.
>
> Thank you again for your time and consideration.
>
>
> On Mon, Jun 2, 2025 at 7:48?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> >Even if it by default preserves input order, when I explicitly called
> stream.unordered(), could mapConcurrent() respect that and in return
> achieve higher throughput with support for race?
>
> The Gatherer doesn't know whether the Stream is unordered or ordered. The
> operation should be semantically equivalent anyway.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 2 June 2025 16:29
> *To:* Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <
> core-libs-dev at openjdk.org>
> *Subject:* [External] : Re: Should mapConcurrent() respect time order
> instead of input order?
>
> Sorry. Forgot to copy to the mailing list.
>
> On Mon, Jun 2, 2025 at 7:27?AM Jige Yu <yujige at gmail.com> wrote:
>
> Thanks Viktor!
>
> I was thinking from my own experience that I wouldn't have automatically
> assumed that a concurrent fanout library would by default preserve input
> order.
>
> And I think wanting high throughput with real-life utilities like race
> would be more commonly useful.
>
> But I could be wrong.
>
> Regardless, mapConcurrent() can do both, no?
>
> Even if it by default preserves input order, when I explicitly called
> stream.unordered(), could mapConcurrent() respect that and in return
> achieve higher throughput with support for race?
>
>
>
> On Mon, Jun 2, 2025 at 2:33?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi!
>
> In a similar vein to the built-in Collectors,
> the built-in Gatherers provide solutions to common stream-related
> problems, but also, they also serve as "inspiration" for developers for
> what is possible to implement using Gatherers.
>
> If someone, for performance reasons, and with a use-case which does not
> require encounter-order, want to take advantage of that combination of
> circumstances, it is definitely possible to implement your own Gatherer
> which has that behavior.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Jige
> Yu <yujige at gmail.com>
> *Sent:* Sunday, 1 June 2025 21:08
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Should mapConcurrent() respect time order instead of input
> order?
>
> It seems like for most people, input order isn't that important for
> concurrent work, and concurrent results being in non-deterministic order is
> often expected.
>
> If mapConcurrent() just respect output encounter order:
>
> It'll be able to achieve *higher throughput* if an early task is slow,
> For example, with concurrency=2, and if the first task takes 10 minutes to
> run, mapConcurrent() would only be able to process 2 tasks within the first
> 10 minutes; whereas with encounter order, the first task being slow doesn't
> block the 3rd - 100th elements from being processed and output.
>
> mapConcurrent() can be used to implement useful concurrent semantics, for
> example to *support race* semantics. Imagine if I need to send request to
> 10 candidate backends and take whichever that succeeds first, I'd be able
> to do:
>
> backends.stream()
>     .gather(mapConcurrent(
>         backend -> {
>           try {
>             return backend.fetchOrder();
>            } catch (RpcException e) {
>              return null; // failed to fetch but not fatal
>            }
>         })
>         .filter(Objects::notNull)
>         .findFirst(); // first success then cancel the rest
>
> Cheers,
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250602/b3e1519c/attachment-0001.htm>

From hgreule at openjdk.org  Mon Jun  2 16:59:34 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 2 Jun 2025 16:59:34 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v2]
In-Reply-To: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
Message-ID: <awuIAS0RLwt2RLf0b6mP8kWGqahDnR4rqYCUcJrqGrM=.ceb5469f-75f2-4a04-b731-7b9dbec1c73b@github.com>

> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.

Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:

  don't return null but latest as fallback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25569/files
  - new: https://git.openjdk.org/jdk/pull/25569/files/32da3621..487b85f1

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

  Stats: 15 lines in 3 files changed: 3 ins; 7 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25569/head:pull/25569

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

From duke at openjdk.org  Mon Jun  2 17:04:07 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Mon, 2 Jun 2025 17:04:07 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v6]
In-Reply-To: <Ncc03SW7hV4CiyaaSbqb1yn1YtvVP3cWkYr8b0n33v0=.2ebaa5ec-4af4-455a-8a57-8883bf4339e9@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <sZVVm3lr1byp_brwwk80CWNovJIKZ4Mc_RvcRNIBBEI=.4f9e6ca0-108f-4e11-9e0c-f4b5bcf32482@github.com>
 <Vua0yenFp1sDiTmOChgBc5fvYCdoByDo82MwLo1ikBI=.82d2bbe5-eb46-4cf8-acdc-6e7af56a325e@github.com>
 <CJ6XTFRmKm7TsbS74Vb1viZQDP9YqiZPUZOGFJYJ_cs=.37f559f3-d1c5-48d8-9b89-f103d1b1b053@github.com>
 <Ncc03SW7hV4CiyaaSbqb1yn1YtvVP3cWkYr8b0n33v0=.2ebaa5ec-4af4-455a-8a57-8883bf4339e9@github.com>
Message-ID: <B45nnM4tVAIuccbJPIC5l6xz9VeMgJf6srnwSDfE_SU=.7d105a23-3f7b-4b2c-854e-ca371f7d41c3@github.com>

On Mon, 2 Jun 2025 04:42:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > When you say "most of the non-x86 platforms", are you referring to the ones with processor types listed below?
> 
> Yes - 3 of the 5 non-x86 platforms.
> 
> > It looks like aarch64 and riscv don't take that route and would fall back to the default cbrt implementation.
> 
> I was wondering why Aarch64 didn't fail. I guess the other platforms may use this to detect new intrinsics being added.

The arm, ppc, and s390 breaks are resolved by #25568.

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

PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2931613343

From liach at openjdk.org  Mon Jun  2 17:32:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Jun 2025 17:32:54 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v2]
In-Reply-To: <awuIAS0RLwt2RLf0b6mP8kWGqahDnR4rqYCUcJrqGrM=.ceb5469f-75f2-4a04-b731-7b9dbec1c73b@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <awuIAS0RLwt2RLf0b6mP8kWGqahDnR4rqYCUcJrqGrM=.ceb5469f-75f2-4a04-b731-7b9dbec1c73b@github.com>
Message-ID: <3NtdD72C3NdAEhPOO6VL26fMjIUTRJLt5vMa9SG6QYI=.283834d3-c6d8-49a5-85de-8aa5b1f077f9@github.com>

On Mon, 2 Jun 2025 16:59:34 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   don't return null but latest as fallback

test/langtools/tools/javap/ClassFileVersionTest.java line 85:

> 83:     @ParameterizedTest
> 84:     @MethodSource("classFiles")
> 85:     void test(byte[] classFile, boolean shouldError) throws Throwable {

I recommend adding another String argument indicating the case name - otherwise, if junit fails, the error message reports the argument to string, which is not informative on which class file exactly is being tested.

An alternative approach can be inlining the arguments to `createClassFile` to the case arguments, like

void test(boolean shouldError, int major, int minor, AccessFlag... classFlags)

And junit provides a more useful error message for such arguments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25569#discussion_r2121764380

From liach at openjdk.org  Mon Jun  2 17:34:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Jun 2025 17:34:53 GMT
Subject: RFR: 8357798: ReverseOrderListView uses Boolean boxes after
 JDK-8356080 [v2]
In-Reply-To: <PhT14YEIl64GPW-wEdPuompsEyae4v7Dsy8VWQXVWrY=.3bd44848-f58a-41e4-9be6-fd115279e951@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
 <PhT14YEIl64GPW-wEdPuompsEyae4v7Dsy8VWQXVWrY=.3bd44848-f58a-41e4-9be6-fd115279e951@github.com>
Message-ID: <MfN1j01p4T5Ogru6noY6CbTOgt6vD9nWICInNbvDLuw=.e2064bd1-2e91-494e-b9d8-ae036e88a2fc@github.com>

On Mon, 2 Jun 2025 13:26:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the existence of the boxed object to allow optional constant folding.
>> 
>> We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `java/util`
>
> 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 five additional commits since the last revision:
> 
>  - Just drop back to boolean
>  - Merge branch 'master' into JDK-8357798-reverse-order-list-boxes
>  - A bit better comment
>  - Better fix
>  - Fix

We might look into strict final fields for trusted boolean fields later.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25456#pullrequestreview-2889358264

From pminborg at openjdk.org  Mon Jun  2 18:25:53 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 2 Jun 2025 18:25:53 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal [v3]
In-Reply-To: <98Ars6Qebvn48y6VXmJUmWnL2TlFUPlvhrjkKVB2MvM=.8b3d7ad7-7f9e-4e82-8189-3767ed5e1188@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
 <98Ars6Qebvn48y6VXmJUmWnL2TlFUPlvhrjkKVB2MvM=.8b3d7ad7-7f9e-4e82-8189-3767ed5e1188@github.com>
Message-ID: <tqWDLBpdKpgUKK43PKgndhzbeVpr6H5yXf6WtJHBdgk=.2ea13210-b200-4beb-b20e-259100a8c599@github.com>

On Fri, 30 May 2025 22:07:06 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Some static final arrays of BigInteger and BigDecimal are stable and immutable. We should add `@Stable` to give the optimizer more information
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BigInteger::mag remove Stable

A general comment with respect to `@Stable` is that it asserts the field/elements will only change at most once (e.g., an array cannot expand, an element can't be written to more than once (unless the contents is "equivalent")). It is dangerous not to uphold the invariants imposed by `@Stable`. So, triple-checking for potential updates (even via reflection) must be done.

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

PR Comment: https://git.openjdk.org/jdk/pull/25437#issuecomment-2931938182

From duke at openjdk.org  Mon Jun  2 19:16:55 2025
From: duke at openjdk.org (duke)
Date: Mon, 2 Jun 2025 19:16:55 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v15]
In-Reply-To: <bKpaZY60SBN77rtuHLpr9Lj9ZyeoyAJ3RoQjtnrWuIQ=.8c21d06d-0f6e-4c2c-91e1-3dbc6c688d6c@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <bKpaZY60SBN77rtuHLpr9Lj9ZyeoyAJ3RoQjtnrWuIQ=.8c21d06d-0f6e-4c2c-91e1-3dbc6c688d6c@github.com>
Message-ID: <UHXIwZdztZA6rHWJOVREql-3vA9aCw909aGnUjZmGks=.da28d00e-61a8-494b-af3d-ae1263481348@github.com>

On Tue, 27 May 2025 19:21:45 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplifying parsing of version parameter.

@david-beaumont 
Your change (at version fb8dd7509e74cf17d813cd48cb4952aefc01e506) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25178#issuecomment-2932104122

From vyazici at openjdk.org  Mon Jun  2 19:27:08 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 19:27:08 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v2]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <P7qUytAQKPn9aH3r34zhHjGHl0eXN7zWHHtnQs5fxMU=.405c8ac9-9fd0-402f-bcf4-0bcd3e021daa@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Provide fallback for `stdin.encoding`
 - Revert changes to `Application` and `JavaChild`
   
   There stdin is connected to the parent process rather than the console.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25544/files
  - new: https://git.openjdk.org/jdk/pull/25544/files/3da53cc9..ef30c050

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

  Stats: 28 lines in 8 files changed: 14 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/25544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25544/head:pull/25544

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

From vyazici at openjdk.org  Mon Jun  2 19:27:09 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 19:27:09 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v2]
In-Reply-To: <sa8L4ZBywxveDtzE7b5VbcdXy3cLvh3INzrIKv4ja7s=.01a87615-dc77-4022-a52a-2e6225b83f8f@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <sa8L4ZBywxveDtzE7b5VbcdXy3cLvh3INzrIKv4ja7s=.01a87615-dc77-4022-a52a-2e6225b83f8f@github.com>
Message-ID: <WSL4sRjVbOyRjK8xqSUVuclRvRXa5zwKdptdkG-BETY=.192e259a-1dec-4421-8bc4-e9bdc50493f1@github.com>

On Fri, 30 May 2025 14:23:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Provide fallback for `stdin.encoding`
>>  - Revert changes to `Application` and `JavaChild`
>>    
>>    There stdin is connected to the parent process rather than the console.
>
> test/jdk/com/sun/tools/attach/Application.java line 40:
> 
>> 38: 
>> 39:         try (BufferedReader br = new BufferedReader(new InputStreamReader(
>> 40:                 System.in, System.getProperty("stdin.encoding")))) {
> 
> This "application" is launched by the test so connected to the parent process rather than the console.

Reverted in 2d52ba408.

> test/jdk/java/lang/ProcessHandle/JavaChild.java line 315:
> 
>> 313:                         // children and wait for each to exit
>> 314:                         sendResult(action, "start");
>> 315:                         try (Reader reader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
> 
> I didn't study the test closely but I think this is another case where a child process is launched so System.in is connected to the parent rather than the console.

Reverted in 2d52ba408..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2121978546
PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2121978885

From cjplummer at openjdk.org  Mon Jun  2 19:29:50 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Jun 2025 19:29:50 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v2]
In-Reply-To: <P7qUytAQKPn9aH3r34zhHjGHl0eXN7zWHHtnQs5fxMU=.405c8ac9-9fd0-402f-bcf4-0bcd3e021daa@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <P7qUytAQKPn9aH3r34zhHjGHl0eXN7zWHHtnQs5fxMU=.405c8ac9-9fd0-402f-bcf4-0bcd3e021daa@github.com>
Message-ID: <8V_c_ulLVTPp6ivKsU3vsslAV3l4b41mRhDKbWGv5Qk=.ea887db3-4975-4c23-b907-d02ba90f2b44@github.com>

On Mon, 2 Jun 2025 19:27:08 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Provide fallback for `stdin.encoding`
>  - Revert changes to `Application` and `JavaChild`
>    
>    There stdin is connected to the parent process rather than the console.

test/jdk/com/sun/jdi/MultiBreakpointsTest.java line 141:

> 139:     Thread console(final int num, final int nhits) {
> 140:         final InputStreamReader isr = new InputStreamReader(
> 141:                 System.in, Charset.forName(System.getProperty("stdin.encoding")));

`isr` is not really needed. It is used to create `br`, which is never used. It is also synchronized on, but since there is a unique `isr` for each thread, the synchronization does nothing. I suggest just deleting `isr`, `br`, and the `synchronized` below.

Note there is a hint in a comment as to why it is like this:


                                // This is a tendril from the original jdb test.
                                // It could probably be deleted.


I think this test once used jdb (and had to deal with the jdb console), but no longer does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2121984300

From vyazici at openjdk.org  Mon Jun  2 19:50:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 19:50:10 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v3]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <A-d7eoGNEQ-n4RYuRRUfHuu4FT6clqA-Y_sYEScbdQs=.12fb732d-7078-43a2-855f-c8980a3f4de7@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Clean-up `MultiBreakpointsTarg`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25544/files
  - new: https://git.openjdk.org/jdk/pull/25544/files/ef30c050..8f8a6575

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

  Stats: 65 lines in 1 file changed: 5 ins; 21 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/25544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25544/head:pull/25544

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

From vyazici at openjdk.org  Mon Jun  2 19:50:11 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 19:50:11 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v3]
In-Reply-To: <8V_c_ulLVTPp6ivKsU3vsslAV3l4b41mRhDKbWGv5Qk=.ea887db3-4975-4c23-b907-d02ba90f2b44@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <P7qUytAQKPn9aH3r34zhHjGHl0eXN7zWHHtnQs5fxMU=.405c8ac9-9fd0-402f-bcf4-0bcd3e021daa@github.com>
 <8V_c_ulLVTPp6ivKsU3vsslAV3l4b41mRhDKbWGv5Qk=.ea887db3-4975-4c23-b907-d02ba90f2b44@github.com>
Message-ID: <oZJozOvTGdWRwxL9ISwdDP49MAHhj1-KM5CRF4w77LQ=.b13d7e0f-f02e-4b94-958b-09fc2f092eef@github.com>

On Mon, 2 Jun 2025 19:27:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean-up `MultiBreakpointsTarg`
>
> test/jdk/com/sun/jdi/MultiBreakpointsTest.java line 141:
> 
>> 139:     Thread console(final int num, final int nhits) {
>> 140:         final InputStreamReader isr = new InputStreamReader(
>> 141:                 System.in, Charset.forName(System.getProperty("stdin.encoding")));
> 
> `isr` is not really needed. It is used to create `br`, which is never used. It is also synchronized on, but since there is a unique `isr` for each thread, the synchronization does nothing. I suggest just deleting `isr`, `br`, and the `synchronized` below.
> 
> Note there is a hint in a comment as to why it is like this:
> 
> 
>                                 // This is a tendril from the original jdb test.
>                                 // It could probably be deleted.
> 
> 
> I think this test once used jdb (and had to deal with the jdb console), but no longer does.

Implemented your suggestion in 8f8a65754 ? took the liberty to remove the unused `done` too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2122019203

From hgreule at openjdk.org  Mon Jun  2 20:06:34 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 2 Jun 2025 20:06:34 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v3]
In-Reply-To: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
Message-ID: <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>

> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.

Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:

  make test failures easier to read

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25569/files
  - new: https://git.openjdk.org/jdk/pull/25569/files/487b85f1..379c892d

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

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

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

From hgreule at openjdk.org  Mon Jun  2 20:06:34 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 2 Jun 2025 20:06:34 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v2]
In-Reply-To: <3NtdD72C3NdAEhPOO6VL26fMjIUTRJLt5vMa9SG6QYI=.283834d3-c6d8-49a5-85de-8aa5b1f077f9@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <awuIAS0RLwt2RLf0b6mP8kWGqahDnR4rqYCUcJrqGrM=.ceb5469f-75f2-4a04-b731-7b9dbec1c73b@github.com>
 <3NtdD72C3NdAEhPOO6VL26fMjIUTRJLt5vMa9SG6QYI=.283834d3-c6d8-49a5-85de-8aa5b1f077f9@github.com>
Message-ID: <4JtP-QzIi6HHE6RAetfxa0fUynTQZjSQs-ly25vA8Z4=.5402ec04-30ab-4850-98b8-ae339eed2c50@github.com>

On Mon, 2 Jun 2025 17:30:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   don't return null but latest as fallback
>
> test/langtools/tools/javap/ClassFileVersionTest.java line 85:
> 
>> 83:     @ParameterizedTest
>> 84:     @MethodSource("classFiles")
>> 85:     void test(byte[] classFile, boolean shouldError) throws Throwable {
> 
> I recommend adding another String argument indicating the case name - otherwise, if junit fails, the error message reports the argument to string, which is not informative on which class file exactly is being tested.
> 
> An alternative approach can be inlining the arguments to `createClassFile` to the case arguments, like
> 
> void test(boolean shouldError, int major, int minor, AccessFlag... classFlags)
> 
> And junit provides a more useful error message for such arguments.

Good idea, I adjusted the test method signature. Seems like junit doesn't like the varargs, but that's okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25569#discussion_r2122046019

From darcy at openjdk.org  Mon Jun  2 20:43:52 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 2 Jun 2025 20:43:52 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications [v2]
In-Reply-To: <8gPP7kpzcCSz8A4o0eCUrDhJRqC_atLNvhu87K3wF_Y=.2a49957a-f2bb-40a5-a091-97d634e06457@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
 <8gPP7kpzcCSz8A4o0eCUrDhJRqC_atLNvhu87K3wF_Y=.2a49957a-f2bb-40a5-a091-97d634e06457@github.com>
Message-ID: <Dn80nyjlzAyyRdJh3xSv2xdqzZUFBl_jYnATxNirfkc=.e761b3d7-cfda-4459-8f05-1b36e127639f@github.com>

On Sat, 31 May 2025 00:47:16 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> For a full explanation, see the bug report [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015).
>> 
>> This PR includes three related changes:
>> * New overrides in SequencedMap view collection implementations, which improve their behavior.
>> * Update to `@implSpec` clauses to reflect this behavior (which was previously ill-specified).
>> * Update to a test which relied on unspecified behavior.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak nsee() declaration; adjust specs per suggestion; update copyrights.

src/java.base/share/classes/java/util/SequencedMap.java line 296:

> 294:                 return view().hashCode();
> 295:             }
> 296:             public void addFirst(K k) { throw new UnsupportedOperationException(); }

Any utility in adding `@Override` annotations to the methods to document intent?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25515#discussion_r2122114324

From duke at openjdk.org  Mon Jun  2 20:47:53 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 2 Jun 2025 20:47:53 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v3]
In-Reply-To: <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
Message-ID: <-cK9P7CnB_QbXtN2B28S0mFhSg4NG7EsmzAbbJq7j5c=.1e7be39c-dbcc-4b90-97c4-fbb6918c9aba@github.com>

On Mon, 2 Jun 2025 20:06:34 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make test failures easier to read

src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java line 122:

> 120:         if (major < JAVA_1_VERSION || major > ClassFile.latestMajorVersion())
> 121:             // something not representable by CFFV, let's fall back
> 122:             return ClassFileFormatVersion.latest();

For?`major <?JAVA_1_VERSION`, this?should?probably return?`ClassFileFormatVersion?.RELEASE_0`?instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25569#discussion_r2122121639

From cjplummer at openjdk.org  Mon Jun  2 22:03:51 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Jun 2025 22:03:51 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v3]
In-Reply-To: <A-d7eoGNEQ-n4RYuRRUfHuu4FT6clqA-Y_sYEScbdQs=.12fb732d-7078-43a2-855f-c8980a3f4de7@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <A-d7eoGNEQ-n4RYuRRUfHuu4FT6clqA-Y_sYEScbdQs=.12fb732d-7078-43a2-855f-c8980a3f4de7@github.com>
Message-ID: <ujbbla0V9GPjN2ivoOPSrIY_apfD9lXuiUCXFJkjWpc=.350f1114-42ed-4abf-85f5-7bfbf77d6655@github.com>

On Mon, 2 Jun 2025 19:50:10 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean-up `MultiBreakpointsTarg`

The src/jdk.jdi and test/jdk/com/sun/jdi changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25544#pullrequestreview-2890059517

From naoto at openjdk.org  Mon Jun  2 22:50:35 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 2 Jun 2025 22:50:35 GMT
Subject: RFR: 8358158: test/jdk/java/io/Console/CharsetTest.java failing with
 NoClassDefFoundError: jtreg/SkippedException
Message-ID: <BeaDtq7QEsiy4RqJeWM2SHkOfu8nAfntWQdo-dpgeCE=.77375173-c80a-4556-be99-6707df351681@github.com>

Fixing a regression caused by the fix to JDK-8356985. Although the fix in `CharsetTest` was a clean-up and not the gist of the original issue, the change seem to have caused not finding `SkippedException` at runtime in certain cases. Changing the test to JUnit based so that the offending `SkippedException` can be replaced with JUnit's `Assumptions`. Also renamed the test case itself to reflect what's actually tested in it.

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

Commit messages:
 - args -> classpath
 - Renamed the test
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/25601/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25601&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358158
  Stats: 217 lines in 4 files changed: 112 ins; 105 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25601.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25601/head:pull/25601

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

From bchristi at openjdk.org  Mon Jun  2 23:12:51 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 2 Jun 2025 23:12:51 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications [v2]
In-Reply-To: <8gPP7kpzcCSz8A4o0eCUrDhJRqC_atLNvhu87K3wF_Y=.2a49957a-f2bb-40a5-a091-97d634e06457@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
 <8gPP7kpzcCSz8A4o0eCUrDhJRqC_atLNvhu87K3wF_Y=.2a49957a-f2bb-40a5-a091-97d634e06457@github.com>
Message-ID: <AtgiTKmI2fWajbas8TFIr8TiSNmd2Lc0_zsP09OiVtw=.a997ed07-2aad-40cd-a956-908bc5bc702f@github.com>

On Sat, 31 May 2025 00:47:16 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> For a full explanation, see the bug report [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015).
>> 
>> This PR includes three related changes:
>> * New overrides in SequencedMap view collection implementations, which improve their behavior.
>> * Update to `@implSpec` clauses to reflect this behavior (which was previously ill-specified).
>> * Update to a test which relied on unspecified behavior.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak nsee() declaration; adjust specs per suggestion; update copyrights.

Marked as reviewed by bchristi (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25515#pullrequestreview-2890167983

From swen at openjdk.org  Mon Jun  2 23:34:55 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 2 Jun 2025 23:34:55 GMT
Subject: RFR: 8357823: Changes in StringBuilder (JDK-8351443) caused a 1-3%
 regression in biojava
In-Reply-To: <EqrJvAzbQYoe6SnQhsy9_KmtAhqJI4jGMaHOztKb0n8=.99ee9a06-04d4-499b-976c-74da3314f4b5@github.com>
References: <EqrJvAzbQYoe6SnQhsy9_KmtAhqJI4jGMaHOztKb0n8=.99ee9a06-04d4-499b-976c-74da3314f4b5@github.com>
Message-ID: <lhUQ3O7VzHadMIWXzDahHX_DMC8Knwocq7-22ZeYebE=.03300e8d-f9ec-4465-9de2-960c5a55da0a@github.com>

On Fri, 30 May 2025 14:01:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Comment out assertions added in JDK-8351443 from AbstractStringBuilder.ensureCapacityNewCoder that increase the codesize, preventing some inlining, and reducing performance
> 
>        assert coder == newCoder || newCoder == UTF16 : "bad new coder UTF16 -> LATIN1";
>        assert count <= newCapacity : "count exceeds new capacity";

The performance figures under x64 show that the performance of StringBuilders.appendWithIntLatin1 scenario drops by about 6%, but the performance of StringBuilders.appendWithLongLatin1 does not drop.

Someone from the optimizer team is needed to look at the assembly code generated under x64


# benfore
git checkout 68a118509a562334eb8c099129d79520041b10cf
make test TEST="micro:java.lang.StringBuilders.appendWithIntLatin1"

# after
git checkout 8fadf295b0ba720a5bc728c6b4d159e60447de97
make test TEST="micro:java.lang.StringBuilders.appendWithIntLatin1"


## Aliyun c8a (CPU AMD EPYC? Genoa)

-# before 68a118509a562334eb8c099129d79520041b10cf
-Benchmark                           Mode  Cnt    Score   Error  Units
-StringBuilders.appendWithIntLatin1  avgt   15  136.055 ? 0.146  ns/op


+# after 8fadf295b0ba720a5bc728c6b4d159e60447de97
+Benchmark                            Mode  Cnt    Score   Error  Units
+StringBuilders.appendWithIntLatin1   avgt   15  146.498 ? 0.983  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/25550#issuecomment-2932872603

From asemenyuk at openjdk.org  Mon Jun  2 23:36:55 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 2 Jun 2025 23:36:55 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v2]
In-Reply-To: <yojpBJpc6GeWiuvYK4iw3cgvPEUjy-RO_B5uobNKJ8M=.f5bc9868-8079-4296-98eb-4bc7d52b26e5@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <oLxZu8TJCbSx5W89GiyA0cxVP5_KWrSVEadfz876iYg=.eea6c6dd-43e1-4887-8d62-986a1a8a3576@github.com>
 <SPRobujHK5qp7oQL-yRLKKwAQRHogbLDsbJJuZ5j59c=.28818ebe-887e-4389-9cff-23bea37b88d2@github.com>
 <yojpBJpc6GeWiuvYK4iw3cgvPEUjy-RO_B5uobNKJ8M=.f5bc9868-8079-4296-98eb-4bc7d52b26e5@github.com>
Message-ID: <KEg0WvDnrb6rrpIeLnfqI8BspEMQGJNk1jey7Pc8A5g=.82076a3b-7564-4606-a53f-10946d2a5175@github.com>

On Wed, 21 May 2025 12:38:19 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

>> Thank you for making the change! Other property files and jpackage.md should also be updated to sync them with HelpResources.properties.
>
>> Thank you for making the change! Other property files and jpackage.md should also be updated to sync them with HelpResources.properties.
> 
> Done, sorry I missed them

@StefanLobbenmeier, if you would like to have this fix in JDK25, you need to issue the `/integrate` command in the PR. I'll sponsor it. The entire sequence should be completed by the end of June 4th; otherwise, this fix will be included in JDK26.

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

PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2932874874

From davidalayachew at gmail.com  Mon Jun  2 23:47:01 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 2 Jun 2025 19:47:01 -0400
Subject: Add varargs to Path::resolve?
Message-ID: <CAA9v-_MZ8aMWHFc1G4w3QVgh4B4yX18LSyDKTc-djK-YQR5ipw@mail.gmail.com>

Hello @core-libs-dev <core-libs-dev at openjdk.org>,

I have an instance of java.nio.file.Path to represent a root folder. I then
create many other instances of Path that refer to subfolders of that root
folder -- oftentimes, many levels deep. To do this, I use
Path.resolve(String).

However, I often find myself writing 4 or 5 layers deep of Path resolution.

rootPath
.resolve("src")
.resolve("main")
.resolve("java")
.resolve("someModule")
.resolve("somePackage")
;

I would much prefer to just use varargs, and list them all up front, as
opposed to having to call resolve over and over.

rootPath.resolve("src", "main", "java");

And I am ignorant about performance, but maybe there is a performance
benefit to be gained here? It appears that I don't need to create multiple
instances of Path anymore.

Thank you for your time and consideration.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250602/54b4fd7d/attachment.htm>

From joehw at openjdk.org  Tue Jun  3 00:23:50 2025
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 3 Jun 2025 00:23:50 GMT
Subject: RFR: 8358158: test/jdk/java/io/Console/CharsetTest.java failing
 with NoClassDefFoundError: jtreg/SkippedException
In-Reply-To: <BeaDtq7QEsiy4RqJeWM2SHkOfu8nAfntWQdo-dpgeCE=.77375173-c80a-4556-be99-6707df351681@github.com>
References: <BeaDtq7QEsiy4RqJeWM2SHkOfu8nAfntWQdo-dpgeCE=.77375173-c80a-4556-be99-6707df351681@github.com>
Message-ID: <Giz9aKV0lYRA-cuVzMHeHeLHZ3rc7qHR__HkYd5HInI=.9122aa19-ef17-4fe4-be35-129f0be28851@github.com>

On Mon, 2 Jun 2025 21:48:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a regression caused by the fix to JDK-8356985. Although the fix in `CharsetTest` was a clean-up and not the gist of the original issue, the change seem to have caused not finding `SkippedException` at runtime in certain cases. Changing the test to JUnit based so that the offending `SkippedException` can be replaced with JUnit's `Assumptions`. Also renamed the test case itself to reflect what's actually tested in it.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25601#pullrequestreview-2890244737

From xgong at openjdk.org  Tue Jun  3 01:49:07 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 3 Jun 2025 01:49:07 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API
In-Reply-To: <TPRwd9SD38ISkoXoJJRu0qMqx6_KU3USw1yPxpbUKVM=.f64594dd-b92b-4453-b7d2-f6b3ebb14a83@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <z9_9NOdQqxNvv_l0VxjGD4Xc-baboKUmbY5NGbXdAHw=.f8486a40-5d28-4f9c-913e-8155baadbec2@github.com>
 <t1DdwodJEC_7OWaci1nCnC6LZVV62x5flDo7rjzYcoM=.91f68c49-f044-43e3-8bba-67a2bd5a5800@github.com>
 <yYd0dXTCX-TXZpluDy9iktVQWeLifmY5GG_GNHkH9lU=.c414c05b-af7e-4b67-8f0f-9ba39696c82a@github.com>
 <TPRwd9SD38ISkoXoJJRu0qMqx6_KU3USw1yPxpbUKVM=.f64594dd-b92b-4453-b7d2-f6b3ebb14a83@github.com>
Message-ID: <uZ0D7FnGH_rusd5CQ_L3mEpcNQRh_2zOZzuYlTKSb5E=.1b1e9e30-3376-4579-b6ec-8bc803d87326@github.com>

On Fri, 30 May 2025 08:15:22 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> @XiaohongGong Thanks for splitting this one out, and for investigating the regressions here.
>>> 
>>> Putting the permalink here, fixed to the current change (the link you pasted will always refer to the newest, which may later on point to the wrong line when lines above are inserted / deleted):
>>> 
>>> https://github.com/openjdk/jdk/blob/7077535c0b0a6ea0a2a167f9135b1504a3d71fb3/src/hotspot/share/opto/loopnode.cpp#L1659-L1661
>>> 
>>> I wonder if we should just use `Node::uncast` there? But I'm quite unsure about that.
>> 
>> Sounds good to me. I will have a deep investigation for it. Thanks!
>> 
>> 
>> 
>>> > Yes, I also observed such regression.
>>> > It would be nice if you proactively mentioned regressions, so it does not have to be pointed out by reviewers.
>>> 
>>> For me, it could be ok to fix it in a follow-up patch. I think we are too close to RDP1 for JDK25 now anyway, and so we could push this patch here into JDK26, and then we have enough time in JDK26 to investigate the regression. Even better would be if we could do the other patch first, so we never even encounter a regression.
>> 
>> Sounds good to me. Thanks!
>
>> > @XiaohongGong Thanks for splitting this one out, and for investigating the regressions here.
>> > Putting the permalink here, fixed to the current change (the link you pasted will always refer to the newest, which may later on point to the wrong line when lines above are inserted / deleted):
>> > https://github.com/openjdk/jdk/blob/7077535c0b0a6ea0a2a167f9135b1504a3d71fb3/src/hotspot/share/opto/loopnode.cpp#L1659-L1661
>> > 
>> > I wonder if we should just use `Node::uncast` there? But I'm quite unsure about that.
>> 
>> Sounds good to me. I will have a deep investigation for it. Thanks!
> 
> Hi @eme64  @jatin-bhateja,  I'v created a PR https://github.com/openjdk/jdk/pull/25539 to fix this issue. With this change, the performance regression can be fixed as well.  Could you please take a look at that change and help to run the test on different X86 machines?   Thanks a lot!

> @XiaohongGong I reviewed #25539. Since it is a relatively simple patch, I suggest that we integrate that one first, and come back to this here later. Is that ok for you?

That's fine to me. Thanks for your review!

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

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2933082670

From xgong at openjdk.org  Tue Jun  3 01:49:07 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 3 Jun 2025 01:49:07 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API
In-Reply-To: <uZ0D7FnGH_rusd5CQ_L3mEpcNQRh_2zOZzuYlTKSb5E=.1b1e9e30-3376-4579-b6ec-8bc803d87326@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <z9_9NOdQqxNvv_l0VxjGD4Xc-baboKUmbY5NGbXdAHw=.f8486a40-5d28-4f9c-913e-8155baadbec2@github.com>
 <t1DdwodJEC_7OWaci1nCnC6LZVV62x5flDo7rjzYcoM=.91f68c49-f044-43e3-8bba-67a2bd5a5800@github.com>
 <yYd0dXTCX-TXZpluDy9iktVQWeLifmY5GG_GNHkH9lU=.c414c05b-af7e-4b67-8f0f-9ba39696c82a@github.com>
 <TPRwd9SD38ISkoXoJJRu0qMqx6_KU3USw1yPxpbUKVM=.f64594dd-b92b-4453-b7d2-f6b3ebb14a83@github.com>
 <uZ0D7FnGH_rusd5CQ_L3mEpcNQRh_2zOZzuYlTKSb5E=.1b1e9e30-3376-4579-b6ec-8bc803d87326@github.com>
Message-ID: <W-JaC11Jl_VqmYHcLDSvUl_-i2i0ooNH1eAw_b4jDn4=.fc13517c-4aca-465d-b8f2-aa94e4797df7@github.com>

On Tue, 3 Jun 2025 01:45:57 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> > @XiaohongGong Thanks for splitting this one out, and for investigating the regressions here.
>>> > Putting the permalink here, fixed to the current change (the link you pasted will always refer to the newest, which may later on point to the wrong line when lines above are inserted / deleted):
>>> > https://github.com/openjdk/jdk/blob/7077535c0b0a6ea0a2a167f9135b1504a3d71fb3/src/hotspot/share/opto/loopnode.cpp#L1659-L1661
>>> > 
>>> > I wonder if we should just use `Node::uncast` there? But I'm quite unsure about that.
>>> 
>>> Sounds good to me. I will have a deep investigation for it. Thanks!
>> 
>> Hi @eme64  @jatin-bhateja,  I'v created a PR https://github.com/openjdk/jdk/pull/25539 to fix this issue. With this change, the performance regression can be fixed as well.  Could you please take a look at that change and help to run the test on different X86 machines?   Thanks a lot!
>
>> @XiaohongGong I reviewed #25539. Since it is a relatively simple patch, I suggest that we integrate that one first, and come back to this here later. Is that ok for you?
> 
> That's fine to me. Thanks for your review!

> Hi @XiaohongGong , Looks good to me, thanks again for this re-factor !!
> 
> Best Regards, Jatin

Thanks so much for your review @jatin-bhateja !

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

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-2933083694

From tkiriyama at openjdk.org  Tue Jun  3 02:08:57 2025
From: tkiriyama at openjdk.org (Takuya Kiriyama)
Date: Tue, 3 Jun 2025 02:08:57 GMT
Subject: RFR: 8352016: Improve
 java/lang/RuntimeTests/RuntimeExitLogTest.java
In-Reply-To: <nHPkgGguDOyGtYHRyaAdCJbxYt_5ufhp99mcHkUGQx4=.da1cdd58-80eb-45c2-adde-ebff8932031a@github.com>
References: <NUixQl_OY2xQ7VehoMd2fRm9S6T-z5qZNi2Uevslyp0=.0ef35d36-1b32-4bda-93bd-4a4f9f810614@github.com>
 <nHPkgGguDOyGtYHRyaAdCJbxYt_5ufhp99mcHkUGQx4=.da1cdd58-80eb-45c2-adde-ebff8932031a@github.com>
Message-ID: <pgXpGXXah9S7jUUKIBKhMek6z03uyf8GbW75zPuClsQ=.71796130-12f8-40cb-9b67-0e35da669895@github.com>

On Wed, 19 Mar 2025 20:07:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

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

Hi, @RogerRiggs 
Just a reminder to please re-review this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/24050#issuecomment-2933115471

From jai.forums2013 at gmail.com  Tue Jun  3 03:58:09 2025
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 3 Jun 2025 09:28:09 +0530
Subject: Add varargs to Path::resolve?
In-Reply-To: <CAA9v-_MZ8aMWHFc1G4w3QVgh4B4yX18LSyDKTc-djK-YQR5ipw@mail.gmail.com>
References: <CAA9v-_MZ8aMWHFc1G4w3QVgh4B4yX18LSyDKTc-djK-YQR5ipw@mail.gmail.com>
Message-ID: <c31128c5-6418-4f12-bf51-4a0bbac7795d@gmail.com>

Hello David,

On 03/06/25 5:17 am, David Alayachew wrote:
> ...
>
> I would much prefer to just use varargs, and list them all up front, 
> as opposed to having to call resolve over and over.
>
> rootPath.resolve("src", "main", "java");
>
This is already possible since Java 22 
https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#resolve(java.lang.String,java.lang.String...)

-Jaikiran


From jpai at openjdk.org  Tue Jun  3 04:04:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Jun 2025 04:04:00 GMT
Subject: RFR: 8350880: (zipfs) Add support for read-only zip file systems
 [v15]
In-Reply-To: <bKpaZY60SBN77rtuHLpr9Lj9ZyeoyAJ3RoQjtnrWuIQ=.8c21d06d-0f6e-4c2c-91e1-3dbc6c688d6c@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
 <bKpaZY60SBN77rtuHLpr9Lj9ZyeoyAJ3RoQjtnrWuIQ=.8c21d06d-0f6e-4c2c-91e1-3dbc6c688d6c@github.com>
Message-ID: <3_nGD6XvWuX2VOV5vjWcvldIcGWzdEZTmaqy1IZfZnI=.64d2685a-5440-4aad-afeb-773ed7c1460a@github.com>

On Tue, 27 May 2025 19:21:45 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adding read-only support to ZipFileSystem.
>> 
>> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
>> 
>> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
>> 
>> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplifying parsing of version parameter.

tier1, tier2 and tier3 testing of this change went fine. I'll go ahead and sponsor this now.

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

PR Comment: https://git.openjdk.org/jdk/pull/25178#issuecomment-2933324356

From duke at openjdk.org  Tue Jun  3 04:04:00 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 3 Jun 2025 04:04:00 GMT
Subject: Integrated: 8350880: (zipfs) Add support for read-only zip file
 systems
In-Reply-To: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
References: <WgcchLghjuld27Ys15gHI6JCQvLeJf63Agi3dJ2piMU=.e0e097ab-40fb-470a-a492-cf35f1ee3635@github.com>
Message-ID: <6b7HS_a0sOL7vkfcxStYwrHj92KHWKkMLe2s5aHOOeY=.c3a6271e-88e0-429e-a1d7-4158236b31b7@github.com>

On Mon, 12 May 2025 09:40:56 GMT, David Beaumont <duke at openjdk.org> wrote:

> Adding read-only support to ZipFileSystem.
> 
> The new `accessMode` environment property allows for readOnly and readWrite values, and ensures that the requested mode is consistent with what's returned.
> 
> This involved a little refactoring to ensure that "read only" state was set initially and only unset at the end of initialization if appropriate.
> 
> By making 2 methods return values (rather than silently set non-final fields as a side effect) it's now clear in what order fields are initialized and which are final (sadly there are still non-final fields, but only a split of this class into two types can fix that, since determining multi-jar support requires reading the file system).

This pull request has now been integrated.

Changeset: 832c5b06
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/832c5b06e8f278d70398e07d32d63d094a06967c
Stats:     396 lines in 5 files changed: 328 ins; 33 del; 35 mod

8350880: (zipfs) Add support for read-only zip file systems

Reviewed-by: lancea, alanb, jpai

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

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

From syan at openjdk.org  Tue Jun  3 05:52:53 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Jun 2025 05:52:53 GMT
Subject: RFR: 8358158: test/jdk/java/io/Console/CharsetTest.java failing
 with NoClassDefFoundError: jtreg/SkippedException
In-Reply-To: <BeaDtq7QEsiy4RqJeWM2SHkOfu8nAfntWQdo-dpgeCE=.77375173-c80a-4556-be99-6707df351681@github.com>
References: <BeaDtq7QEsiy4RqJeWM2SHkOfu8nAfntWQdo-dpgeCE=.77375173-c80a-4556-be99-6707df351681@github.com>
Message-ID: <PSGB8adDEE6uuJ4tKN6PT5vgGe_j0vSn9IWr03BLPXU=.87595721-786b-4873-85c1-837c1ab351c0@github.com>

On Mon, 2 Jun 2025 21:48:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a regression caused by the fix to JDK-8356985. Although the fix in `CharsetTest` was a clean-up and not the gist of the original issue, the change seem to have caused not finding `SkippedException` at runtime in certain cases. Changing the test to JUnit based so that the offending `SkippedException` can be replaced with JUnit's `Assumptions`. Also renamed the test case itself to reflect what's actually tested in it.

test/jdk/java/io/Console/StdoutEncodingTest.java line 41:

> 39:  *          Console.charset() method. "expect" command in Windows/Cygwin
> 40:  *          does not work as expected. Ignoring tests on Windows.
> 41:  * @requires (os.family == "linux") | (os.family == "mac")

The previous line say `Ignoring tests on Windows.`, so this line maybe set as


@requires os.family != "windows"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25601#discussion_r2122774215

From hgreule at openjdk.org  Tue Jun  3 05:56:55 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Tue, 3 Jun 2025 05:56:55 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v3]
In-Reply-To: <-cK9P7CnB_QbXtN2B28S0mFhSg4NG7EsmzAbbJq7j5c=.1e7be39c-dbcc-4b90-97c4-fbb6918c9aba@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
 <-cK9P7CnB_QbXtN2B28S0mFhSg4NG7EsmzAbbJq7j5c=.1e7be39c-dbcc-4b90-97c4-fbb6918c9aba@github.com>
Message-ID: <c6SFaL1fIIUu0dAFvGPvjt5cz67Fk4SdaYU5njR8r9M=.c7952553-a147-4ed8-9e15-53b6737197a4@github.com>

On Mon, 2 Jun 2025 20:44:44 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make test failures easier to read
>
> src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java line 122:
> 
>> 120:         if (major < JAVA_1_VERSION || major > ClassFile.latestMajorVersion())
>> 121:             // something not representable by CFFV, let's fall back
>> 122:             return ClassFileFormatVersion.latest();
> 
> For?`major <?JAVA_1_VERSION`, this?should?probably return?`ClassFileFormatVersion?.RELEASE_0`?instead.

I'm not sure if there is any better or worse default here, but for now, this just restores the semantics to what it was before javap was made CFFV-aware (instead of crashing). I think future improvements should be made separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25569#discussion_r2122784822

From duke at openjdk.org  Tue Jun  3 06:15:55 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Tue, 3 Jun 2025 06:15:55 GMT
Subject: RFR: 8358158: test/jdk/java/io/Console/CharsetTest.java failing
 with NoClassDefFoundError: jtreg/SkippedException
In-Reply-To: <BeaDtq7QEsiy4RqJeWM2SHkOfu8nAfntWQdo-dpgeCE=.77375173-c80a-4556-be99-6707df351681@github.com>
References: <BeaDtq7QEsiy4RqJeWM2SHkOfu8nAfntWQdo-dpgeCE=.77375173-c80a-4556-be99-6707df351681@github.com>
Message-ID: <mrpFkFHZOSxrrLRlsxpuNCUh8yb0BJA0vebQ0LwRU1E=.bcc84ea4-447f-4185-a2c7-5617629c6fdf@github.com>

On Mon, 2 Jun 2025 21:48:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a regression caused by the fix to JDK-8356985. Although the fix in `CharsetTest` was a clean-up and not the gist of the original issue, the change seem to have caused not finding `SkippedException` at runtime in certain cases. Changing the test to JUnit based so that the offending `SkippedException` can be replaced with JUnit's `Assumptions`. Also renamed the test case itself to reflect what's actually tested in it.

test/jdk/java/io/Console/StdoutEncodingTest.java line 72:

> 70:         if (eval != 0) {
> 71:             throw new RuntimeException("Test failed. Exit value from 'expect' command: " + eval);
> 72:         }

suggestion: `assertEquals(0, eval, "exit value");`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25601#discussion_r2122817415

From jpai at openjdk.org  Tue Jun  3 06:40:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Jun 2025 06:40:31 GMT
Subject: RFR: 8358456: ZipFile.getInputStream(ZipEntry) throws unspecified
 IllegalArgumentException
Message-ID: <pGyKc4WnqscGK1Ttq-jFE9dTGkwvfTnUmW_vN_iXpdg=.4fa18e88-400f-4fe0-b8de-44a67e9bf84a@github.com>

Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8358456?

In Java 24, through https://bugs.openjdk.org/browse/JDK-8341597 we did a change which started using the "compressed size" field value for computing a input buffer size for the `InflaterInputStream`. The change was reasonable. One part of the change removed a check for  ` <= 0` which would have taken into account invalid/unexpected "compressed size" values:
>From https://github.com/openjdk/jdk/pull/21379
> There is a check for size <= 0. This condition is unreachable in the current code and in the PR as well, since the compressed size will always be >= 2. I propose we remove this check.

Without that check, the computed input buffer size can end up being `<= 0` which is an invalid value for a buffer size and thus results in an `IllegalArgumentException` from the `InflaterInputStream` constructor.

My initial thought was to catch the the `IllegalArgumentException` and rethrow a `ZipException`, but thinking about it, this clearly is more an issue with the value that we computed as an input buffer size. So I believe the right thing here is to reintroduce the check that was previously in place and in such cases just default to reasonable sized buffer. That's what the commit in this PR does. Additionally, I renamed that variable to `inputBufSize` to be clear what this `size` represents.

A new jtreg test has been introduced which reproduces the issue and verifies the fix. tier testing is currently in progress.

P.S: As a separate task we might want to do a similar change as what was done in JDK-8341597, to the `ZipFileSystem` code. It currently uses the uncompressed size of the entry to decide the input buffer size.

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

Commit messages:
 - 8358456: ZipFile.getInputStream(ZipEntry) throws unspecified IllegalArgumentException

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

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

From duke at openjdk.org  Tue Jun  3 07:06:05 2025
From: duke at openjdk.org (Stefan Lobbenmeier)
Date: Tue, 3 Jun 2025 07:06:05 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v4]
In-Reply-To: <wWi_NL_McwvSGuBvHJVI5ie3U9lAV4rmoruJf91JDsg=.143f84ac-f8b8-44e9-8377-d94a69a993c7@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <wWi_NL_McwvSGuBvHJVI5ie3U9lAV4rmoruJf91JDsg=.143f84ac-f8b8-44e9-8377-d94a69a993c7@github.com>
Message-ID: <IryyLSeYnl0oDyHbl8Q7yK2OvV9eOrgvV8eMQtS6Wc0=.0bfd335d-a89b-4590-962a-4f7882870b43@github.com>

On Tue, 27 May 2025 19:48:11 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

>> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space
>> 
>> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372
>
> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct backtick position

There is an integration blocker because of the issue title, should I change the PR or can you change the issue title?

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

PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2933800256

From davidalayachew at gmail.com  Tue Jun  3 07:38:58 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 3 Jun 2025 03:38:58 -0400
Subject: Add varargs to Path::resolve?
In-Reply-To: <c31128c5-6418-4f12-bf51-4a0bbac7795d@gmail.com>
References: <CAA9v-_MZ8aMWHFc1G4w3QVgh4B4yX18LSyDKTc-djK-YQR5ipw@mail.gmail.com>
 <c31128c5-6418-4f12-bf51-4a0bbac7795d@gmail.com>
Message-ID: <CAA9v-_Oz1AVvPccm_fzVnyKw031xT2-8wwAO7rOa7Y5DDgJ_qg@mail.gmail.com>

Heh, I forgot that my Javadoc was set to 21. Thank you for the correction.

On Mon, Jun 2, 2025, 11:58?PM Jaikiran Pai <jai.forums2013 at gmail.com> wrote:

> Hello David,
>
> On 03/06/25 5:17 am, David Alayachew wrote:
> > ...
> >
> > I would much prefer to just use varargs, and list them all up front,
> > as opposed to having to call resolve over and over.
> >
> > rootPath.resolve("src", "main", "java");
> >
> This is already possible since Java 22
>
> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#resolve(java.lang.String,java.lang.String..
> .)
>
> -Jaikiran
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250603/af5c5479/attachment.htm>

From vyazici at openjdk.org  Tue Jun  3 07:55:06 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 3 Jun 2025 07:55:06 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v4]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Fix missing `java.io.Reader` import in `Ktab`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25544/files
  - new: https://git.openjdk.org/jdk/pull/25544/files/8f8a6575..78e8de51

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

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

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

From michaelm at openjdk.org  Tue Jun  3 08:14:48 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 3 Jun 2025 08:14:48 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v19]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <vicgJ1AulH1JCrSUbP0nPu3FOPi1PLLKxJanl3FWjVM=.b0e75401-049c-45ee-855a-48d3f7678728@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

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

 - Merge branch 'master' into 8348986-exceptions
 - doc update to java.security
 - removed jmod/Handler change
 - doc update to java.security
 - Fixed problem with j.n.HostPortRange
 - typo in suggestions and other issues
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - Additional callsites identified by Mark S.
 - Merge branch 'master' into 8348986-exceptions
 - ... and 29 more: https://git.openjdk.org/jdk/compare/dbf562c7...ab6387d8

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

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=18
  Stats: 984 lines in 47 files changed: 709 ins; 101 del; 174 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

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

From shade at openjdk.org  Tue Jun  3 08:16:03 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jun 2025 08:16:03 GMT
Subject: RFR: 8357798: ReverseOrderListView uses Boolean boxes after
 JDK-8356080 [v2]
In-Reply-To: <PhT14YEIl64GPW-wEdPuompsEyae4v7Dsy8VWQXVWrY=.3bd44848-f58a-41e4-9be6-fd115279e951@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
 <PhT14YEIl64GPW-wEdPuompsEyae4v7Dsy8VWQXVWrY=.3bd44848-f58a-41e4-9be6-fd115279e951@github.com>
Message-ID: <F8ou37OtZcMY-RM6N74dTolzDjo_dWuGu2hY1IDQkXg=.746f6640-8fd0-4f9f-9a8d-610927c6f598@github.com>

On Mon, 2 Jun 2025 13:26:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the existence of the boxed object to allow optional constant folding.
>> 
>> We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `java/util`
>
> 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 five additional commits since the last revision:
> 
>  - Just drop back to boolean
>  - Merge branch 'master' into JDK-8357798-reverse-order-list-boxes
>  - A bit better comment
>  - Better fix
>  - Fix

Right. Any more reviews?

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

PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2934060776

From vklang at openjdk.org  Tue Jun  3 09:02:00 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 3 Jun 2025 09:02:00 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message
In-Reply-To: <7IXvN9Kkr1UqkczbU3DqFZK4aAnFPpysfEPoouqWdds=.fa401d16-3d5e-4d48-aec5-8a336afac317@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <AnrjLD7rJwg1dT8fNc5XMs8rqhSlLxIPNPk27zZtN7k=.34540e60-36c4-4c98-9a11-668fff434160@github.com>
 <3C_11D3AR_qG3ifDbWztlzhD8rZyultJEKh_89wWN1M=.5af79488-6978-4f80-a07e-b4c38139b390@github.com>
 <7IXvN9Kkr1UqkczbU3DqFZK4aAnFPpysfEPoouqWdds=.fa401d16-3d5e-4d48-aec5-8a336afac317@github.com>
Message-ID: <tMECink5yhJaBmp3cFA33RunWcoeNlQ4VOGhhGposBY=.b3381f15-7c6a-4188-9939-195cf556db57@github.com>

On Thu, 22 May 2025 02:09:08 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

>> @He-Pin Just pinging you here, in case the notification from my most recent comments got lost in transit.
>
> @viktorklang-ora @liach, I think we need a contribution guide that explains how to set up the work in the IDE, how to perform tests, etc.

@He-Pin Reminder: Integration needs to be done immediately if this is to make the release train.

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

PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2934230413

From vyazici at openjdk.org  Tue Jun  3 09:12:52 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 3 Jun 2025 09:12:52 GMT
Subject: RFR: 8357821: Revert incorrectly named JavaLangAccess::unchecked*
 methods
In-Reply-To: <tDzMTU2VeD_fIb5s8gweKAF1fnz5p6y7kWgGkWcpMAY=.749b0bce-e6e0-490f-a6eb-f584c3f7166f@github.com>
References: <tDzMTU2VeD_fIb5s8gweKAF1fnz5p6y7kWgGkWcpMAY=.749b0bce-e6e0-490f-a6eb-f584c3f7166f@github.com>
Message-ID: <wqqD43dK-OFxmDgiJe4CphOLXmzODWdGTjWAhO8KO2o=.682028b3-5ec8-450c-ad21-783328af758b@github.com>

On Fri, 30 May 2025 11:57:39 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Reverts certain [JDK-8353197](https://bugs.openjdk.org/browse/JDK-8353197) (which implements JavaDoc improvement and precautionary naming for certain unsafe methods in `jdk.internal.access.JavaLangAccess`) changes that are found to be incorrect. See the JBS issue for details on the followed evaluation process.

> I wonder if we should add that implementations of the affected method _shall_ do bounds checking to reduce the likelihood of a new/updated native implementation miss that?

@minborg, would you mind elaborating on this a bit, please? Do you imply adding an `@implSpec` to the touched `JavaLangAccess` methods?

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

PR Comment: https://git.openjdk.org/jdk/pull/25545#issuecomment-2934272812

From viktor.klang at oracle.com  Tue Jun  3 09:13:26 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 3 Jun 2025 09:13:26 +0000
Subject: [External] : Re: Should mapConcurrent() respect time order
 instead of input order?
In-Reply-To: <CAKD1RYst6GOErvVozZ2SD6JGhTRUAugSHZFM7aY+5Je72iF3wA@mail.gmail.com>
References: <CAKD1RYuoK07OvAn02v4qq74Q1QDfpQpf=t0J0VT-s1zi4iKRnA@mail.gmail.com>
 <MW4PR10MB5774AED3EC215ED5AB3AD52CFF62A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtLy_yC+L5+q1YOkbEvUis5LJ-tJNJDbyoptq8A=+W3eg@mail.gmail.com>
 <CAKD1RYuksGCWsqj6cnu3aoHqkzAepLeNHsGSX_nCi2QryJaGMQ@mail.gmail.com>
 <SJ0PR10MB5766DAA744887EE8B0A2B991FF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYvhpcD=yAGAvTTi+c8sdjDAi776GCPCAdvsCCVF9JQpeQ@mail.gmail.com>
 <SJ0PR10MB5766DB20AB83B1199C7987EAFF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYst6GOErvVozZ2SD6JGhTRUAugSHZFM7aY+5Je72iF3wA@mail.gmail.com>
Message-ID: <MW4PR10MB57749F82094174F71CF0BB56FF6DA@MW4PR10MB5774.namprd10.prod.outlook.com>

The general feedback received thus far has been primarily positive. There have been a few behavior-related enhancements over the previews to better handle interruption (there's still room to improve there, as per our concurrent conversation) as well as some improvements to work-in-progress tracking.

It will be interesting to see which Gatherer-based operations will be devised by Java developers in the future.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com>
Sent: Monday, 2 June 2025 18:54
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order?


Hi Viktor,

Thanks for your reply and for sharing your experience regarding user preferences. I appreciate that perspective.

You're right, if an unordered version of mapConcurrent proves to be widely beneficial and is implemented and adopted by the community, it could certainly make a strong case for future inclusion in the JDK.

I wanted to clarify a nuance regarding user preference that I might not have articulated clearly before. If the question is simply "ordered or unordered?", in isolation, I can see why many, myself included, might lean towards "ordered" as a general preference.

However, the decision becomes more complex when the associated trade-offs are considered. If the question were phrased more like, "Do you prefer an ordered mapConcurrent by default, even if it entails potential performance overhead and limitations for certain use cases like race() operations, versus an unordered version that offers higher throughput and broader applicability in such scenarios?" my (and perhaps others') answer might differ. The perceived cost versus benefit of ordering changes significantly when these factors are explicit.

My initial suggestion stemmed from the belief that the performance and flexibility gains of an unordered approach for I/O-bound tasks would, in many practical situations, outweigh the convenience of default ordering, especially since ordering can be reintroduced relatively easily, and explicitly, when needed.

Thanks again for the discussion.

Best regards,

On Mon, Jun 2, 2025 at 8:51?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>My perspective is that strict adherence to input order for mapConcurrent() might not be the most common or beneficial default behavior for users.

If there is indeed a majority who would benefit from an unordered version of mapConcurrent (my experience is that the majority prefer ordered) then, since it is possible to implement such a Gatherer outside of the JDK, this is something which will be constructed, widely used, and someone will then propose to add something similar to the JDK.

>While re-implementing the gatherer is a possibility, the existing implementation is non-trivial, and creating a custom, robust alternative represents a significant undertaking.

The existing version needs to maintain order, which adds to the complexity of the implementation. Implementing an unordered version would likely look different.
I'd definitely encourage taking the opportunity to attempt to implement it.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 2 June 2025 17:05
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order?


Thank you for your response and for considering my feedback on the mapConcurrent() gatherer. I understand and respect that the final decision rests with the JDK maintainers.

I would like to offer a couple of further points for consideration. My perspective is that strict adherence to input order for mapConcurrent() might not be the most common or beneficial default behavior for users. I'd be very interested to see any research or data that suggests otherwise, as that would certainly inform my understanding.

From my experience, a more common need is for higher throughput in I/O-intensive operations. The ability to support use cases like race()?where the first successfully completed operation determines the outcome?also seems like a valuable capability that is currently infeasible due to the ordering constraint.

As I see it, if a developer specifically requires the input order to be preserved, this can be achieved with relative ease by applying a subsequent sorting operation. For instance:

.gather(mapConcurrent(...))
.sorted(Comparator.comparing(Result::getInputSequenceId))


The primary challenge in these scenarios is typically the efficient fan-out and execution of concurrent tasks, not the subsequent sorting of results.

Conversely, as you've noted, there isn't a straightforward way to modify the current default ordered behavior to achieve the higher throughput or race() semantics that an unordered approach would naturally provide.

While re-implementing the gatherer is a possibility, the existing implementation is non-trivial, and creating a custom, robust alternative represents a significant undertaking. My hope was that an unordered option could be a valuable addition to the standard library, benefiting a wider range of developers.

Thank you again for your time and consideration.


On Mon, Jun 2, 2025 at 7:48?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>Even if it by default preserves input order, when I explicitly called stream.unordered(), could mapConcurrent() respect that and in return achieve higher throughput with support for race?

The Gatherer doesn't know whether the Stream is unordered or ordered. The operation should be semantically equivalent anyway.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 2 June 2025 16:29
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>; core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: [External] : Re: Should mapConcurrent() respect time order instead of input order?

Sorry. Forgot to copy to the mailing list.

On Mon, Jun 2, 2025 at 7:27?AM Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>> wrote:
Thanks Viktor!

I was thinking from my own experience that I wouldn't have automatically assumed that a concurrent fanout library would by default preserve input order.

And I think wanting high throughput with real-life utilities like race would be more commonly useful.

But I could be wrong.

Regardless, mapConcurrent() can do both, no?

Even if it by default preserves input order, when I explicitly called stream.unordered(), could mapConcurrent() respect that and in return achieve higher throughput with support for race?



On Mon, Jun 2, 2025 at 2:33?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi!

In a similar vein to the built-in Collectors,
the built-in Gatherers provide solutions to common stream-related problems, but also, they also serve as "inspiration" for developers for what is possible to implement using Gatherers.

If someone, for performance reasons, and with a use-case which does not require encounter-order, want to take advantage of that combination of circumstances, it is definitely possible to implement your own Gatherer which has that behavior.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Sunday, 1 June 2025 21:08
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Should mapConcurrent() respect time order instead of input order?

It seems like for most people, input order isn't that important for concurrent work, and concurrent results being in non-deterministic order is often expected.

If mapConcurrent() just respect output encounter order:

It'll be able to achieve higher throughput if an early task is slow, For example, with concurrency=2, and if the first task takes 10 minutes to run, mapConcurrent() would only be able to process 2 tasks within the first 10 minutes; whereas with encounter order, the first task being slow doesn't block the 3rd - 100th elements from being processed and output.

mapConcurrent() can be used to implement useful concurrent semantics, for example to support race semantics. Imagine if I need to send request to 10 candidate backends and take whichever that succeeds first, I'd be able to do:

backends.stream()
    .gather(mapConcurrent(
        backend -> {
          try {
            return backend.fetchOrder();
           } catch (RpcException e) {
             return null; // failed to fetch but not fatal
           }
        })
        .filter(Objects::notNull)
        .findFirst(); // first success then cancel the rest

Cheers,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250603/7a6548c0/attachment-0001.htm>

From viktor.klang at oracle.com  Tue Jun  3 09:15:47 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 3 Jun 2025 09:15:47 +0000
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <CAKD1RYtOO-XkAfHjk8GQibmLoKv7sMYrQhSYEO98KESNgBnJ2A@mail.gmail.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtAUfyUHOdmSeZ2Azny=RJU63FQozY2NxpYu-4xQYCRkA@mail.gmail.com>
 <MW4PR10MB5774B089653C902899FEBEAFFFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB5774BB2B60EE5A1F4B1A7306FFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvxZ0gpHJXW0ctuHwEGwfStfjmLvwV1CgSWrr8438rWPA@mail.gmail.com>
 <MW4PR10MB5774EF4D4316B5BE46B29A0EFFF12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYsJyHeEs1fc4DRTZKwDO_U4Pyjv45BQ5fvr6VbboaVCTQ@mail.gmail.com>
 <MW4PR10MB57743363CCA3306B316F3EEDFF65A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYuPzVW+VHt_MzOrXW93iNv0A03JFSCV+yawCFeaLm=HsA@mail.gmail.com>
 <CAKD1RYtpahV4766wNodvcrSGFqJ6ereG1fUJFi-yEviOpLcb=Q@mail.gmail.com>
 <MW4PR10MB577459221CD425EFD5686426FF67A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYscAh46O77zw=S68DefM9Aonnn7DjCB_8YJ-eWTKSpNDQ@mail.gmail.com>
 <3f9e1798-2edb-47b9-9d33-b455055dbcf5@oracle.com>
 <CAKD1RYtcmwqDbF+i6DEXJKvAnZ-WcCc7xrEK_tRygKucpDMxtw@mail.gmail.com>
 <SJ0PR10MB57664D873E06C6AFA8E72B5EFF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYtOO-XkAfHjk8GQibmLoKv7sMYrQhSYEO98KESNgBnJ2A@mail.gmail.com>
Message-ID: <MW4PR10MB57742196707F12609C3EEF08FF6DA@MW4PR10MB5774.namprd10.prod.outlook.com>

Yes, it is unsatisfactory. A Stream using `map(f)` wouldn't respond to interruptions at all (unless `f` intentionally does so), so it would be inconsistent if `mapConcurrent(x, f)` automatically did so.

I'm currently leaning more towards augmenting the implementation to broadcast caller-interruption to the task threads, and leave the decision up to `f` (user code).

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com>
Sent: Monday, 2 June 2025 18:49
To: Viktor Klang <viktor.klang at oracle.com>
Cc: David Holmes <david.holmes at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Thanks Viktor! I didn't realize I wasn't explicit about the "leave the interruption bit set" part.

So no, if mapConcurrent() throws unchecked upon interruption, the interruption bit must be set. There is no question about that, from my part. :)

With that, do you still think throwing unchecked (with interruption bit set) is unsatisfactory?



On Mon, Jun 2, 2025 at 9:37?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
I talked to Doug about this today, and it doesn't seem tractable to throw a non InterruptedException on interrupt (at least not without leaving the interruption flag set).

While it should be possible to broadcast stream-evaluation-thread's interruption to tasks (without cancelling them) so that tasks can check Thread.interrupted() and throw some application-specific exception, it is still unsatisfactory for most use-cases.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Friday, 30 May 2025 00:44
To: David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Yeah. I can see these distinctions and guidelines being useful for callers of the low-level concurrency primitive methods (semaphore etc.)

But at a higher level, in the application code, does anyone know of a plausible scenario where being forced to catch IE is useful? It seems like you either always propagate it up, or you have to catch it and risk forgetting to re-interrupt the thread. And, there is not much useful thing you can do that's different from other types of exceptions.

That's why I think it may be reasonable for mapConcurrent() to:

- absorb cancellation into the API contract and catch the IE
and throw a more semantically specific exception (an unchecked exception indicating the mapConcurrent() has been interrupted).

Thinking from two typical ways of IE scenarios:

  *   mapConcurrent() is wrapped in a Future, and the future is canceled - if you've canceled it, the unchecked exception shouldn't bother you.
  *   mapConcurrent() is inside an outer mapConcurrent(), or inside an outer structured concurrency scope - in either case, interruption happens because a sibling task has failed to trigger the fail-fast cancellation. Checked exceptions work fine too.

I can't see harm being done for either case, compared to letting it keep running through all elements (what if the stream is infinite or very very long?)

On Wed, May 28, 2025 at 10:19?PM David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>> wrote:
On 29/05/2025 3:45 am, Jige Yu wrote:
> 17.2.4 is specifically about the Object wait()/notify() API, yeah?
>
> I've always had this confusion in my mind that I couldn't find an
> authoritative source for: what was the point of checked
> InterruptedException?

Interruption and IE provide a limited capability for task cancellation.
As such any method that calls a method that can throw IE has to be aware
that the method can do that, and by having IE be checked, they are
forced to confront the question: how do I respond to cancellation? As
Doug Lea describes in his book there are a few ways to respond to this
cancellation notice depending on the semantics of the method involved:

- make cancellation part of your own API, declare and rethrow any IE
should encounter (and your caller then has to make the choice)
- absorb cancellation into your general API contract and catch the IE
and throw a more semantically specific exception
- handle low-level cancellation by catching the IE and doing whatever
logic is appropriate

David
-----

> My naive observation has been two fold:
>
>  1. In most cases, when possible, applications declare "throws IE" and
>     let it propagate all the way up the call stack. This works exactly
>     the same as if IE were unchecked.
>  2. When the application is cornered into a Runnable, Function and
>     cannot "throws IE", it has to catch(IE),  remember to re-interrupt
>     the thread, and wrap in an unchecked. Except *it often forgets to
>     re-interrupt*.
>
> At the lowest level concurrent primitives (wait(), notify(), Semaphore),
> I presume IE being an integral part of the API contract.
>
> But at mid-level APIs (Future, mapConcurrent()), or high-level
> applications, I've always been at a loss on why we needed the checked IE
> in the first place.
>
> IE used to happen when someone calls Future.cancel(true). Now with
> structured concurrency, it can also be caused by a sibling task failing
> and fail-fast.
>
> But aside from the extra ceremony and the extra room for error
> (forgetting to reinterrupt), what do we get from it? I was asking
> ChatGPT about real-life scenarios where specifically catching and
> handling IE is necessary but all ChatGPT gave me was cases where the
> code has to re-interrupt, which would have been unnecessary if IE were
> unchecked and didn't clear the interruption bit.
>
> Would appreciate a pointer to code or authoritative discussion about
> this matter.
>
> Sorry for the tangent!
>
>
> On Wed, May 28, 2025 at 1:03?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
> <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>> wrote:
>
>     It would seem to require a change to the Java Language Specification
>     section 17.2.4
>
>     Cheers,
>     ?
>
>     *
>     *
>     *Viktor Klang*
>     Software Architect, Java Platform Group
>     Oracle
>     ------------------------------------------------------------------------
>     *From:* Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com> <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>     *Sent:* Wednesday, 28 May 2025 00:35
>     *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>     <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>     *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>     <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>>
>     *Subject:* Re: [External] : Re: mapConcurrent() with
>     InterruptedException
>     That said, I'm still curious. Have you considered propagating
>     cancellation, re-interrupting the current thread, and then throwing
>     an unchecked exception upon interruption? It's going to be the most
>     fail-fast-compatible.
>
>     catch (IE interrupted) {
>        cancel all pending futures
>        Thread.currentThread().interrupt();
>        throw new UncheckedInterruptedException();
>     }
>
>     What are the concerns against such practice?
>
>
>
>
>
>     On Mon, May 26, 2025 at 8:31?AM Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>
>     <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>> wrote:
>
>         Yeah, I think I missed the task cancellation and the joining part.
>
>         When the mapConcurrent() thread is interrupted, it propagates
>         the cancellation to the child threads.
>
>         And if any of the children threads (running the user-provided
>         Function) receives that cancellation, it will still need to
>         catch it and handle interruption.
>
>         That means the interruption isn't swallowed. If the user code
>         wants to abort, they can always just throw an unchecked
>         exception and catch it from the caller of mapConcurrent().
>
>         That should do for most of the IO type work.
>
>         This makes sense.
>
>
>
>         On Mon, May 26, 2025 at 12:30?AM Viktor Klang
>         <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com> <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>> wrote:
>
>             Yes, the updated Gatherers.mapConcurrent will continue under
>             interruption until done, and then restore the interrupt
>             status of the calling thread.
>
>             It cannot (reasonably) do anything else?if it were to throw
>             InterruptedException, it couldn't since that is a checked
>             exception and there's no tracking of checked exceptions
>             throughout a Stream, and that is the specified behavior to
>             handle thread interrupts (i.e. clear flag and throw
>             InterruptedException, which is not possible in this case;
>             or, make sure that interrupt status is maintained, which is
>             possible in this case.
>
>             I have given it some more thought in the meantime, but I
>             haven't arrived in something more satisfactory than that, yet.
>
>             Cheers,
>             ?
>
>             *
>             *
>             *Viktor Klang*
>             Software Architect, Java Platform Group
>             Oracle
>             ------------------------------------------------------------------------
>             *From:* Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com> <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>             *Sent:* Monday, 26 May 2025 03:07
>             *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>             <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>             *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-<mailto:core-libs->
>             dev at openjdk.org<mailto:dev at openjdk.org>> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-<mailto:core->
>             libs-dev at openjdk.org<mailto:libs-dev at openjdk.org>>>
>             *Subject:* Re: [External] : Re: mapConcurrent() with
>             InterruptedException
>             Thanks Viktor!
>
>             Sorry, I was giving myself more time to read the code, but
>             then I lost track.
>
>             If I'm reading the code right, the current behavior is that
>             if the current thread is interrupted, the mapConcurrent()
>             would suppress the interruption until all elements are
>             processed? (It will then restore the interruption bit)
>
>             Doesn't this break fail fast?
>
>             For example, I may have a mapConcurrent() called from within
>             structured concurrency, and that fans out to two operations:
>             ?
>             scope.fork(() -> doA());
>             scope.fork(() -> doB());  // calls mapConcurrent() internally
>             scope.join().throwIfFailed();
>
>             If doA() fails, doB() will be cancelled (thread interrupted).
>
>             If mapConcurrent() ignores the interruption, and if doB has
>             a long list to process, it'll continue to consume system
>             resources even when the caller no longer needs the results, no?
>
>
>             On Fri, Feb 7, 2025 at 2:16?AM Viktor Klang
>             <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com> <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>             wrote:
>
>                  >Sorry, did the PR stop using Semaphore?
>
>                 No, not that PR. See: https://github.com/openjdk/jdk/<https://urldefense.com/v3/__https://github.com/openjdk/jdk/__;!!ACWV5N9M2RV99hQ!PMr-UM3yFuDgyliwYrx2zxVolGwtII5c6ZgHEwNbV9qHqYijWdXqel6Bs_H6GPcKYaibqz9KtmJ7K2TD$>
>                 commit/450636ae28b84ded083b6861c6cba85fbf87e16e
>                 <https://urldefense.com/v3/__https://github.com/openjdk/
>                 jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e__;!!
>                 ACWV5N9M2RV99hQ!
>                 OKfWrvJEDCkiHcT5b4a6gfeomZzZeq3jv6ir2vf2I5WWIhujtb-
>                 by_VuQFaAPDIuAA0qAwpTUjllXMPF$>
>
>                 The problem with interruption under parallel evaluation
>                 is that there is no general support for propagation of
>                 interruption in CountedCompleters. Adding support for
>                 such in (at least) GathererOp needs further study before
>                 contemplating making any changes to mapConcurrent()'s
>                 interruption policy.
>
>                 Cheers,
>                 ?
>
>                 *
>                 *
>                 *Viktor Klang*
>                 Software Architect, Java Platform Group
>                 Oracle
>
>                 ------------------------------------------------------------------------
>                 *From:* Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com> <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>                 *Sent:* Thursday, 6 February 2025 17:04
>                 *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                 <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>                 *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-<mailto:core-libs->
>                 dev at openjdk.org<mailto:dev at openjdk.org>> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
>                 <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>>
>                 *Subject:* Re: [External] : Re: mapConcurrent() with
>                 InterruptedException
>                 Sorry, did the PR stop using Semaphore?
>
>                 I had naively thought that mapConcurrent() will keep a
>                 buffer of Future of all currently-running concurrent
>                 tasks (it can be a ConcurrentMap<TaskKey, Future> if we
>                 don't have to ensure FIFO).
>
>                 Upon interruption, the main thread can
>                 call .cancel(true) on all pending Futures; optionally
>                 join with the VTs (if we need to block until all VTs
>                 exit); then propagate exception.
>
>                 Upon completion, each task just removes itself from the
>                 ConcurrentMap.
>
>                 Just in case it adds anything.
>
>
>
>                 On Thu, Feb 6, 2025 at 6:47?AM Viktor Klang
>                 <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                 <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>> wrote:
>
>                     After some more investigation it seems tractable to
>                     propagate interruption of the caller in sequential
>                     mode, but parallel mode will require much bigger
>                     considerations.
>
>                     I made a comment to that effect on the JBS issue:
>                     https://bugs.openjdk.org/browse/JDK-8349462?
>                     focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017 <https://bugs.openjdk.org/browse/JDK-8349462?focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017>
>
>
>                     Cheers,
>                     ?
>
>                     *
>                     *
>                     *Viktor Klang*
>                     Software Architect, Java Platform Group
>                     Oracle
>                     ------------------------------------------------------------------------
>                     *From:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                     <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>                     *Sent:* Thursday, 6 February 2025 11:51
>                     *To:* Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>
>                     <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>                     *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-<mailto:core-libs->
>                     dev at openjdk.org<mailto:dev at openjdk.org>> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
>                     <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>>
>                     *Subject:* Re: [External] : Re: mapConcurrent() with
>                     InterruptedException
>                     I think alignment in behavior between parallel
>                     Stream and mapConcurrent in terms of how
>                     interruptions are handled is a possible path forward.
>
>                     I decided to close the PR for now as I realized my
>                     parallel Stream example had misled me regarding its
>                     exception throwing, so I'll need to go back and
>                     refine the solution.
>
>                     It still seems solvable though.
>
>                     Cheers,
>                     ?
>
>                     *
>                     *
>                     *Viktor Klang*
>                     Software Architect, Java Platform Group
>                     Oracle
>                     ------------------------------------------------------------------------
>                     *From:* Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>
>                     <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>                     *Sent:* Wednesday, 5 February 2025 19:20
>                     *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                     <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>                     *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-<mailto:core-libs->
>                     dev at openjdk.org<mailto:dev at openjdk.org>> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
>                     <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>>
>                     *Subject:* Re: [External] : Re: mapConcurrent() with
>                     InterruptedException
>                     Oh good call!
>
>                     I forgot to check what parallel streams do upon
>                     interruption (didn't think they do any blocking
>                     calls, but at least the main thread must block).
>
>                     On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang
>                     <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                     <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>> wrote:
>
>                         Hi Jige,
>
>                         I opened an issue to track the concern, and I
>                         have proposed a change which seems to align well
>                         with how parallel streams behave under caller
>                         thread interruption.
>
>                         I've opened the following PR for review:
>                         https://github.com/openjdk/jdk/pull/23467<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!PMr-UM3yFuDgyliwYrx2zxVolGwtII5c6ZgHEwNbV9qHqYijWdXqel6Bs_H6GPcKYaibqz9KtufyGAaA$>
>                         <https://urldefense.com/v3/__https://github.com/
>                         openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!
>                         M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
>
>                         If you are able to make a local OpenJDK build
>                         with that solution you could check if it
>                         addresses your use-cases (or not).
>                         <https://urldefense.com/v3/__https://github.com/
>                         openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!
>                         M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
>
>                         8349462: Gatherers.mapConcurrent could support
>                         async interrupts by viktorklang-ora ? Pull
>                         Request #23467 ? openjdk/jdk <https://
>                         urldefense.com/v3/__https://github.com/openjdk/<http://urldefense.com/v3/__https://github.com/openjdk/>
>                         jdk/pull/23467__;!!ACWV5N9M2RV99hQ!
>                         M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
>                         This change is likely going to need some extra
>                         verbiage in the spec for mapConcurrent, and thus
>                         a CSR. This behavior aligns mapConcurrent with
>                         how parallel streams work in conjunction with
>                         interrup...
>                         github.com<https://urldefense.com/v3/__http://github.com__;!!ACWV5N9M2RV99hQ!PMr-UM3yFuDgyliwYrx2zxVolGwtII5c6ZgHEwNbV9qHqYijWdXqel6Bs_H6GPcKYaibqz9Ktl6pXJ7z$> <https://urldefense.com/v3/__http://
>                         github.com__;!!ACWV5N9M2RV99hQ!
>                         M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89DBkMefT$>
>
>
>
>                         Cheers,
>                         ?
>
>                         *
>                         *
>                         *Viktor Klang*
>                         Software Architect, Java Platform Group
>                         Oracle
>                         ------------------------------------------------------------------------
>                         *From:* Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>
>                         <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>                         *Sent:* Wednesday, 5 February 2025 16:24
>                         *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                         <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>                         *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-<mailto:core->
>                         libs-dev at openjdk.org<mailto:libs-dev at openjdk.org>> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
>                         <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>>
>                         *Subject:* Re: [External] : Re: mapConcurrent()
>                         with InterruptedException
>                         Thanks Viktor!
>
>                         I understand the problem.
>
>                         The main reason I asked is because I want to
>                         understand how the core Java team thinks of
>                         throwing an unchecked exception.
>
>                         As explained above, I consider losing
>                         cancellability a big deal, a deal breaker even.
>                         And I thought throwing unchecked is more
>                         acceptable. Because the most common reason the
>                         mapConcurrent() VT can be interrupted is due to
>                         cancellation from a parent mapConcurrent(), or a
>                         parent Structured Concurrency scope. The
>                         cancellation could be either from an organic
>                         exception, or from the downstream not needing
>                         more elements, like maybe due to findFirst()
>                         already getting an element.
>
>                         In both cases, since the concurrent operation is
>                         already cancelled (result ignored), what
>                         exception pops up to the top level isn't that
>                         big of a deal (perhaps only a log record will be
>                         seen?)
>
>                         But if the core Java team considers it a bad
>                         idea, I would love to learn and adjust.
>
>                         On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang
>                         <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                         <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>> wrote:
>
>                             Hi,
>
>                             The problem is that mapConcurrent cannot
>                             throw InterruptedException because that is a
>                             checked exception, so we cannot clear the
>                             interrupted flag and throw that exception.
>
>                             So the updated semantics is to not cut the
>                             stream short but instead run to completion,
>                             restoring the interruption flag.
>
>                             There exists a couple of alternatives to
>                             this approach which I am contemplating, but
>                             they need to be further explored before I
>                             consider moving forward with any of them.
>
>                             Cheers,
>                             ?
>
>                             *
>                             *
>                             *Viktor Klang*
>                             Software Architect, Java Platform Group
>                             Oracle
>                             ------------------------------------------------------------------------
>                             *From:* Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>
>                             <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>                             *Sent:* Monday, 27 January 2025 17:00
>                             *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                             <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>                             *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
>                             <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>> <core-
>                             libs-dev at openjdk.org<mailto:libs-dev at openjdk.org> <mailto:core-libs-<mailto:core-libs->
>                             dev at openjdk.org<mailto:dev at openjdk.org>>>
>                             *Subject:* Re: [External] : Re:
>                             mapConcurrent() with InterruptedException
>                             Thanks Viktor!
>
>                             It looks like the current fix ignores
>                             interruption.
>
>                             I want to make sure my concern of it
>                             defeating cancellation is heard and understood.
>
>                             The scenarios I worry about is for a
>                             mapConcurrent() that fans out to another
>                             method call, which internally calls
>                             mapConcurrent() as implementation detail.
>
>                             An example:
>
>                             List<RefundResponse>
>                             refundHelper(transaction)
>                             {  transaction.creditCardAccounts.stream()
>                               .gather(mapConcurrent(acct ->
>                             service.refund(acct))    .toList(); }
>                             transactions.stream()
>                               .gather(mapConcurrent(transaction ->
>                             refundHelper(transaction));
>
>
>                             It seems undesirable that in such a case all
>                             the service.refund() calls become non
>                             cancellable, because the only way the outer
>                             mapConcurrent() cancels the refundHelper()
>                             calls is through Thread.interrupt() the
>                             virtual threads that call refundHelper(),
>                             which would then be disabled by the inner
>                             mapConcurrent().
>
>                             Does this example make sense to you? I can
>                             further explain if anything isn't clear.
>
>                             But I want to make sure the decision to
>                             disable interruption is deliberate judgement
>                             call that such nested mapConcurrent() is
>                             unlikely,or not important.
>
>                             Cheers,
>
>
>
>                             On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang
>                             <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                             <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>> wrote:
>
>                                 Hi!
>
>                                 Please see: https://github.com/openjdk/<https://urldefense.com/v3/__https://github.com/openjdk/__;!!ACWV5N9M2RV99hQ!PMr-UM3yFuDgyliwYrx2zxVolGwtII5c6ZgHEwNbV9qHqYijWdXqel6Bs_H6GPcKYaibqz9KtqljGxI8$>
>                                 jdk/pull/23100 <https://urldefense.com/
>                                 v3/__https://github.com/openjdk/jdk/<https://urldefense.com/v3/__https://github.com/openjdk/jdk/__;!!ACWV5N9M2RV99hQ!PMr-UM3yFuDgyliwYrx2zxVolGwtII5c6ZgHEwNbV9qHqYijWdXqel6Bs_H6GPcKYaibqz9KtmJ7K2TD$>
>                                 pull/23100__;!!ACWV5N9M2RV99hQ!
>                                 IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>
>
>                                 Cheers,
>                                 ?
>
>                                 *
>                                 *
>                                 *Viktor Klang*
>                                 Software Architect, Java Platform Group
>                                 Oracle
>                                 ------------------------------------------------------------------------
>                                 *From:* Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>
>                                 <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>                                 *Sent:* Sunday, 26 January 2025 23:03
>                                 *To:* Viktor Klang
>                                 <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                                 <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>>
>                                 *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
>                                 <mailto:core-libs-<mailto:core-libs->
>                                 dev at openjdk.org<mailto:dev at openjdk.org>> <core-libs-
>                                 dev at openjdk.org<mailto:dev at openjdk.org> <mailto:core-libs-<mailto:core-libs->
>                                 dev at openjdk.org<mailto:dev at openjdk.org>>>
>                                 *Subject:* [External] : Re:
>                                 mapConcurrent() with InterruptedException
>                                 Checking in on what you've found out,
>                                 Viktor.
>
>                                  From where we left off, I understand
>                                 that you were looking at alternatives
>                                 instead of silent truncation?
>
>                                 Have you reached any conclusion?
>
>                                 We touched on disallowing interruption
>                                 during mapConcurrent(). I still have
>                                 concerns with disabling cancellation,
>                                 because it basically undoes this API
>                                 note from the javadoc <https://
>                                 cr.openjdk.org/~alanb/sc-20240503/<http://cr.openjdk.org/~alanb/sc-20240503/>
>                                 java.base/java/util/stream/
>                                 Gatherers.html#mapConcurrent(int,java.util.function.Function)>:
>
>                                 API Note:
>
>                                     In progress tasks will be attempted
>                                     to be cancelled, on a best-effort
>                                     basis, in situations where the
>                                     downstream no longer wants to
>                                     receive any more elements.
>
>                                 In reality, people will use
>                                 mapConcurrent() to fan out rpcs.
>                                 Sometimes these rpcs are just a single
>                                 blocking call; yet sometimes they may
>                                 themselves be a Structured Concurrency
>                                 scope, with 2 or 3 rpcs that constitute
>                                 a single logical operation. Under two
>                                 conditions, cancellation is imho
>                                 important semantic:
>
>                                  1. The downstream code uses
>                                     filter().findFirst(), and when it
>                                     sees an element, it will return and
>                                     no longer needs the other pending
>                                     rpcs to complete. If cancellation is
>                                     disabled, these unnecessary rpcs
>                                     will waste system resources.
>                                  2. One of the rpc throws and the Stream
>                                     pipeline needs to propagate the
>                                     exception. Again, if the other rpcs
>                                     cannot be cancelled, we'll have many
>                                     zombie rpcs.
>
>                                 Zombie rpcs may or may not be a deal
>                                 breaker, depending on the specific use
>                                 case. But for a JDK library, losing
>                                 cancellation would have a negative
>                                 impact on usability.
>
>                                 My 2c,
>
>
>                                 On Fri, Jan 3, 2025 at 9:18?AM Viktor
>                                 Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>
>                                 <mailto:viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>> wrote:
>
>                                     Hi Ben,
>
>                                     Thanks for raising these questions?
>                                     getting feedback is crucial in the
>                                     Preview stage of features.
>
>                                     I wrote a reply to the Reddit thread
>                                     so I'll just summarize here:
>
>                                     It is important to note that /
>                                     mapConcurrent()/ is not a part of
>                                     the Structured Concurrency JEPs, so
>                                     it is not designed to join SC scopes.
>
>                                     I'm currently experimenting with
>                                     ignoring-but-restoring interrupts on
>                                     the "calling thread" for /
>                                     mapConcurrent()/, as well as capping
>                                     work-in-progress to /
>                                     maxConcurrency/ (not only capping
>                                     the concurrency but also the amount
>                                     of completed-but-yet-to-be-pushed
>                                     work). Both of these adjustments
>                                     should increase predictability of
>                                     behavior in the face of blocking
>                                     operations with variable delays.
>
>                                     Another adjustment I'm looking at
>                                     right now is to harden/improve the
>                                     cleanup to wait for concurrent tasks
>                                     to acknowledge cancellation, so that
>                                     once the finisher is done executing
>                                     the VTs are known to have terminated.
>
>                                     As for not preserving the encounter
>                                     order, that would be a completely
>                                     different thing, and I'd encourage
>                                     you to experiment with that if that
>                                     functionality would be interesting
>                                     for your use-case(s).
>
>                                     Again, thanks for your feedback!
>
>                                     Cheers,
>                                     ?
>
>                                     *
>                                     *
>                                     *Viktor Klang*
>                                     Software Architect, Java Platform Group
>                                     Oracle
>                                     ------------------------------------------------------------------------
>                                     *From:* core-libs-dev <core-libs-
>                                     dev-retn at openjdk.org<mailto:dev-retn at openjdk.org> <mailto:core-<mailto:core->
>                                     libs-dev-retn at openjdk.org<mailto:libs-dev-retn at openjdk.org>>> on
>                                     behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>
>                                     <mailto:yujige at gmail.com<mailto:yujige at gmail.com>>>
>                                     *Sent:* Friday, 3 January 2025 17:53
>                                     *To:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
>                                     <mailto:core-libs-<mailto:core-libs->
>                                     dev at openjdk.org<mailto:dev at openjdk.org>> <core-libs-
>                                     dev at openjdk.org<mailto:dev at openjdk.org> <mailto:core-libs-<mailto:core-libs->
>                                     dev at openjdk.org<mailto:dev at openjdk.org>>>
>                                     *Subject:* mapConcurrent() with
>                                     InterruptedException
>                                     Hi Java Experts,
>
>                                     I sent this email incorrectly to
>                                     loom-dev@ and was told on Reddit
>                                     that core-libs-dev is the right list.
>
>                                     The question is about the behavior
>                                     of mapConcurrent() when the thread
>                                     is interrupted.
>
>                                     Currently mapConcurrent()'s finisher
>                                     phase will re-interrupt the thread,
>                                     then stop at whatever element that
>                                     has already been processed and return.
>
>                                     This strikes me as a surprising
>                                     behavior, because for example if I'm
>                                     running:
>
>                                         Stream.of(1, 2, 3)
>                                              .gather(mapConcurrent(i ->
>                                     i * 2))
>                                              .toList()
>
>                                     and the thread is being interrupted,
>                                     the result could be any of [2], [2,
>                                     4] or [2, 4, 6].
>
>                                     Since thread interruption is
>                                     cooperative, there is no guarantee
>                                     that the thread being interrupted
>                                     will just abort. It's quite possible
>                                     that it'll keep going and then will
>                                     use for example [2] as the result of
>                                     doubling the list of [1, 2, 3],
>                                     which is imho incorrect.
>
>                                     In the Reddit <https://
>                                     urldefense.com/v3/__https://<http://urldefense.com/v3/__https://>
>                                     www.reddit.com/r/java/<https://urldefense.com/v3/__http://www.reddit.com/r/java/__;!!ACWV5N9M2RV99hQ!PMr-UM3yFuDgyliwYrx2zxVolGwtII5c6ZgHEwNbV9qHqYijWdXqel6Bs_H6GPcKYaibqz9KtiI8zC4I$>
>                                     comments/1hr8xyu/
>                                     observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread, someone argued that interruption rarely happens so it's more of a theoretical issue. But interruption can easily happen in Structured Concurrency or in mapConcurrent() itself if any subtask has failed in order to cancel/interrupt the other ongoing tasks.
>
>                                     There had been discussion about
>                                     alternative strategies:
>
>                                      1. Don't respond to interruption
>                                         and just keep running to completion.
>                                      2. Re-interrupt thread and wrap the
>                                         InterruptedException in a
>                                         standard unchecked exception
>                                         (StructuredConcurrencyInterruptedException?).
>
>
>                                     I have concerns with option 1
>                                     because it disables cancellation
>                                     propagation when mapConcurrent()
>                                     itself is used in a subtask of a
>                                     parent mapConcurrent() or in a
>                                     StructuredConcurrencyScope.
>
>                                     Both equivalent Future-composition
>                                     async code, or C++'s fiber trees
>                                     support cancellation propagation and
>                                     imho it's a critical feature or else
>                                     it's possible that a zombie thread
>                                     is still sending RPCs long after the
>                                     main thread has exited (failed, or
>                                     falled back to some default action).
>
>                                     My arguments for option 2:
>
>                                      1. InterruptedException is more
>                                         error prone than traditional
>                                         checked exceptions for
>                                         *users* to catch and handle.
>                                         They can forget to re-interrupt
>                                         the thread. It's so confusing
>                                         that even seasoned programmers
>                                         may not know they are *supposed
>                                         to* re-interrupt the thread.
>                                      2. With Stream API using functional
>                                         interfaces like Supplier,
>                                         Function, the option of just
>                                         tacking on "throws IE" isn't
>                                         available to many users.
>                                      3. With Virtual Threads, it will be
>                                         more acceptable, or even become
>                                         common to do blocking calls from
>                                         a stream operation (including
>                                         but exclusive to
>                                         mapConcurrent()). So the chance
>                                         users are forced to deal with IE
>                                         will become substantially higher.
>                                      4. Other APIs such as the
>                                         Structured Concurrency API have
>                                         already started wrapping system
>                                         checked exceptions like
>                                         ExecutionException,
>                                         TimeoutException in unchecked
>                                         exceptions ( join() <https://
>                                         urldefense.com/v3/__https://<http://urldefense.com/v3/__https://>
>                                         download.java.net/java/<https://urldefense.com/v3/__http://download.java.net/java/__;!!ACWV5N9M2RV99hQ!PMr-UM3yFuDgyliwYrx2zxVolGwtII5c6ZgHEwNbV9qHqYijWdXqel6Bs_H6GPcKYaibqz9Kto23a6du$>
>                                         early_access/loom/docs/api/
>                                         java.base/java/util/concurrent/
>                                         StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for example).
>                                      5. Imho, exceptions that we'd
>                                         rather users not catch and
>                                         handle but instead should mostly
>                                         just propagate up as is, should
>                                         be unchecked.
>
>                                     There is also a side discussion
>                                     <https://urldefense.com/v3/
>                                     __https://www.reddit.com/r/java/<https://urldefense.com/v3/__https://www.reddit.com/r/java/__;!!ACWV5N9M2RV99hQ!PMr-UM3yFuDgyliwYrx2zxVolGwtII5c6ZgHEwNbV9qHqYijWdXqel6Bs_H6GPcKYaibqz9KtkCrsIFe$>
>                                     comments/1hr8xyu/comment/m4z4f8c/?
>                                     utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about whether mapConcurrent() is better off preserving input order or push to downstream as soon as an element is computed. I'd love to discuss that topic too but maybe it's better to start a separate thread?
>
>                                     Thank you and cheers!
>
>                                     Ben Yu
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250603/05eb98b7/attachment-0001.htm>

From eirbjo at openjdk.org  Tue Jun  3 09:20:50 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 3 Jun 2025 09:20:50 GMT
Subject: RFR: 8358456: ZipFile.getInputStream(ZipEntry) throws unspecified
 IllegalArgumentException
In-Reply-To: <pGyKc4WnqscGK1Ttq-jFE9dTGkwvfTnUmW_vN_iXpdg=.4fa18e88-400f-4fe0-b8de-44a67e9bf84a@github.com>
References: <pGyKc4WnqscGK1Ttq-jFE9dTGkwvfTnUmW_vN_iXpdg=.4fa18e88-400f-4fe0-b8de-44a67e9bf84a@github.com>
Message-ID: <L7tnQvOcmEjer5uyASRgiwf6lssJBGhanmksJZuhuuY=.c359b441-d4e9-467b-b6e4-02e9af4ace86@github.com>

On Tue, 3 Jun 2025 06:35:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8358456?
> 
> In Java 24, through https://bugs.openjdk.org/browse/JDK-8341597 we did a change which started using the "compressed size" field value for computing a input buffer size for the `InflaterInputStream`. The change was reasonable. One part of the change removed a check for  ` <= 0` which would have taken into account invalid/unexpected "compressed size" values:
> From https://github.com/openjdk/jdk/pull/21379
>> There is a check for size <= 0. This condition is unreachable in the current code and in the PR as well, since the compressed size will always be >= 2. I propose we remove this check.
> 
> Without that check, the computed input buffer size can end up being `<= 0` which is an invalid value for a buffer size and thus results in an `IllegalArgumentException` from the `InflaterInputStream` constructor.
> 
> My initial thought was to catch the the `IllegalArgumentException` and rethrow a `ZipException`, but thinking about it, this clearly is more an issue with the value that we computed as an input buffer size. So I believe the right thing here is to reintroduce the check that was previously in place and in such cases just default to reasonable sized buffer. That's what the commit in this PR does. Additionally, I renamed that variable to `inputBufSize` to be clear what this `size` represents.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix. tier testing is currently in progress.
> 
> P.S: As a separate task we might want to do a similar change as what was done in JDK-8341597, to the `ZipFileSystem` code. It currently uses the uncompressed size of the entry to decide the input buffer size.

Looks reasonable to me. I clearly did not consider invalid input for this case, assuming compressed content would at least have the two-byte deflate header.

A good reminder to always consider invalid input.

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

PR Comment: https://git.openjdk.org/jdk/pull/25606#issuecomment-2934304456

From eirbjo at openjdk.org  Tue Jun  3 09:30:05 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 3 Jun 2025 09:30:05 GMT
Subject: RFR: 8358456: ZipFile.getInputStream(ZipEntry) throws unspecified
 IllegalArgumentException
In-Reply-To: <pGyKc4WnqscGK1Ttq-jFE9dTGkwvfTnUmW_vN_iXpdg=.4fa18e88-400f-4fe0-b8de-44a67e9bf84a@github.com>
References: <pGyKc4WnqscGK1Ttq-jFE9dTGkwvfTnUmW_vN_iXpdg=.4fa18e88-400f-4fe0-b8de-44a67e9bf84a@github.com>
Message-ID: <RshfwWcy2vf_sLnetRzaOhAcKUF60oR3KKuxp8o4i8M=.b8549a64-e76d-4a57-98f0-d067e1e4b31f@github.com>

On Tue, 3 Jun 2025 06:35:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8358456?
> 
> In Java 24, through https://bugs.openjdk.org/browse/JDK-8341597 we did a change which started using the "compressed size" field value for computing a input buffer size for the `InflaterInputStream`. The change was reasonable. One part of the change removed a check for  ` <= 0` which would have taken into account invalid/unexpected "compressed size" values:
> From https://github.com/openjdk/jdk/pull/21379
>> There is a check for size <= 0. This condition is unreachable in the current code and in the PR as well, since the compressed size will always be >= 2. I propose we remove this check.
> 
> Without that check, the computed input buffer size can end up being `<= 0` which is an invalid value for a buffer size and thus results in an `IllegalArgumentException` from the `InflaterInputStream` constructor.
> 
> My initial thought was to catch the the `IllegalArgumentException` and rethrow a `ZipException`, but thinking about it, this clearly is more an issue with the value that we computed as an input buffer size. So I believe the right thing here is to reintroduce the check that was previously in place and in such cases just default to reasonable sized buffer. That's what the commit in this PR does. Additionally, I renamed that variable to `inputBufSize` to be clear what this `size` represents.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix. tier testing is currently in progress.
> 
> P.S: As a separate task we might want to do a similar change as what was done in JDK-8341597, to the `ZipFileSystem` code. It currently uses the uncompressed size of the entry to decide the input buffer size.

Would be interesting to know what kind of tooling produced this invalid/surprising compressed size. The JBS issues do indicate this from what I can tell.

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

PR Comment: https://git.openjdk.org/jdk/pull/25606#issuecomment-2934344795

From nbenalla at openjdk.org  Tue Jun  3 11:14:36 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 3 Jun 2025 11:14:36 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
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: <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>

> Get JDK 26 underway.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'master' into jdk.8355746
 - Problemlist JavaBaseCheckSince
 - Revert "feedback: never bump ASM version"
   
   This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Update --release 25 symbol information for JDK 25 build 24
   The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
 - problem list some failing tests
 - Merge branch 'master' into jdk.8355746
 - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496

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

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=06
  Stats: 1830 lines in 60 files changed: 1740 ins; 16 del; 74 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  Tue Jun  3 11:14:37 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 3 Jun 2025 11:14:37 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v6]
In-Reply-To: <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
Message-ID: <_yRRFog3hl3dV5bNvkT2t8vPwaPqOPtzz-JY9_fozKs=.fa645a72-84f9-4736-8ae8-a719302a2f24@github.com>

On Mon, 2 Jun 2025 14:46:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 24
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - problem list some failing tests
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 23
>    The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b

I have problemlisted `tools/sincechecker/modules/java.base/JavaBaseCheckSince.java` as it is failing due to the symbol information lagging behind.

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

PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2934728105

From nbenalla at openjdk.org  Tue Jun  3 11:19:34 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 3 Jun 2025 11:19:34 GMT
Subject: RFR: 8346884: Add since checker test to jdk.editpad
Message-ID: <eqA9zD_EnXUJr7Q_xq7OZbBzAxViuUHyzy0Tw6LtZ8U=.6868ebd9-4afa-4a03-8c2d-7addef9a2ddf@github.com>

Please review this patch to add a new test to check `@since` tags in the `jdk.editpad` module.

TIA

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

Commit messages:
 - add new `@since` test

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

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

From nbenalla at openjdk.org  Tue Jun  3 11:19:34 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 3 Jun 2025 11:19:34 GMT
Subject: RFR: 8346884: Add since checker test to jdk.editpad
In-Reply-To: <eqA9zD_EnXUJr7Q_xq7OZbBzAxViuUHyzy0Tw6LtZ8U=.6868ebd9-4afa-4a03-8c2d-7addef9a2ddf@github.com>
References: <eqA9zD_EnXUJr7Q_xq7OZbBzAxViuUHyzy0Tw6LtZ8U=.6868ebd9-4afa-4a03-8c2d-7addef9a2ddf@github.com>
Message-ID: <CKteKl44uoBG40c95jLiAemwvEUmI-3X9nrJOfz8Q4s=.a0e6aefa-ef23-4746-9174-5eeb0ab25b99@github.com>

On Tue, 3 Jun 2025 10:09:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to add a new test to check `@since` tags in the `jdk.editpad` module.
> 
> TIA

I realize there are no classfiles in `jdk.editpad` but the test can also check the `@since` information in the `module-info.java` file.

The goal is to have an `@since` test per module.

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

PR Comment: https://git.openjdk.org/jdk/pull/25613#issuecomment-2934750409

From egahlin at openjdk.org  Tue Jun  3 12:50:49 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 3 Jun 2025 12:50:49 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Fix adjust boundary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/d0097506..7fa2db19

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

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

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

From dfuchs at openjdk.org  Tue Jun  3 13:22:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Jun 2025 13:22:58 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v19]
In-Reply-To: <vicgJ1AulH1JCrSUbP0nPu3FOPi1PLLKxJanl3FWjVM=.b0e75401-049c-45ee-855a-48d3f7678728@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <vicgJ1AulH1JCrSUbP0nPu3FOPi1PLLKxJanl3FWjVM=.b0e75401-049c-45ee-855a-48d3f7678728@github.com>
Message-ID: <Z9wuYyFiAHmGeI1K2E_tBDqs3kurtsXNmE327z_Io6Q=.248a8519-e3c3-436c-b597-b46195984eb2@github.com>

On Tue, 3 Jun 2025 08:14:48 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - doc update to java.security
>  - removed jmod/Handler change
>  - doc update to java.security
>  - Fixed problem with j.n.HostPortRange
>  - typo in suggestions and other issues
>  - Merge branch 'master' into 8348986-exceptions
>  - Apply suggestions from code review
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - Additional callsites identified by Mark S.
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/dbf562c7...ab6387d8

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23929#pullrequestreview-2892334027

From mgronlun at openjdk.org  Tue Jun  3 14:10:59 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 14:10:59 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
Message-ID: <8jbZNr-7dzvGRglSLxMcgr5WjmSrGRChJ8MQarUTkdo=.dc1c9dff-65da-4e75-a49c-9af112b26cc7@github.com>

On Tue, 3 Jun 2025 12:50:49 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix adjust boundary

Great stuff.

We have now what amounts to a carbon-copy of the existing throttling implementation used in the JVM, mainly used by the jdk.ObjectAllocationSample event. (see hotspot/src/share/jfr/support/jfrAdaptiveSampler.cpp and hotspot/src/share/jfr/recorder/service/jfrEventThrottler.cpp).

Smart work to write the Java implementation as a method-to-method comparison, which made it easier to review.

Thanks
Markus

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25559#pullrequestreview-2892579207

From michaelm at openjdk.org  Tue Jun  3 14:27:57 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 3 Jun 2025 14:27:57 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v20]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <hsUAHdr4P3y03WbiHc5STSivjrWY6Co24wF5Yx1v1PA=.03fc5d87-504d-4e55-92a8-e21d5bd49d2c@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  uodate to JNDI

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/ab6387d8..1a6f5af2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=18-19

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

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

From dfuchs at openjdk.org  Tue Jun  3 14:27:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Jun 2025 14:27:57 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v20]
In-Reply-To: <hsUAHdr4P3y03WbiHc5STSivjrWY6Co24wF5Yx1v1PA=.03fc5d87-504d-4e55-92a8-e21d5bd49d2c@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <hsUAHdr4P3y03WbiHc5STSivjrWY6Co24wF5Yx1v1PA=.03fc5d87-504d-4e55-92a8-e21d5bd49d2c@github.com>
Message-ID: <ipCTRLZJFZ552tbf9IHpkAhXwOtPdgOXDPmliSJieUc=.f0ed0520-c99d-4d6f-ad46-03891f10ca76@github.com>

On Tue, 3 Jun 2025 14:23:54 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   uodate to JNDI

Thanks for the last updates Michael. I believe we're good now!

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23929#pullrequestreview-2892676320

From michaelm at openjdk.org  Tue Jun  3 15:39:06 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 3 Jun 2025 15:39:06 GMT
Subject: Integrated: 8348986: Improve coverage of enhanced exception messages
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <ANCJMV9FtfHoAU_5eMxPFITXqxhqUwFM7UMQW1kicBQ=.57bfe450-373c-45b6-94a8-4a8b33c873f4@github.com>

On Thu, 6 Mar 2025 10:24:13 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

This pull request has now been integrated.

Changeset: b6f827ef
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6f827ef054959662190e21ce63fc3d3c45b92f3
Stats:     984 lines in 47 files changed: 709 ins; 101 del; 174 mod

8348986: Improve coverage of enhanced exception messages

Reviewed-by: dfuchs

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

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

From jpai at openjdk.org  Tue Jun  3 15:39:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Jun 2025 15:39:52 GMT
Subject: RFR: 8358456: ZipFile.getInputStream(ZipEntry) throws unspecified
 IllegalArgumentException
In-Reply-To: <pGyKc4WnqscGK1Ttq-jFE9dTGkwvfTnUmW_vN_iXpdg=.4fa18e88-400f-4fe0-b8de-44a67e9bf84a@github.com>
References: <pGyKc4WnqscGK1Ttq-jFE9dTGkwvfTnUmW_vN_iXpdg=.4fa18e88-400f-4fe0-b8de-44a67e9bf84a@github.com>
Message-ID: <9bIsR70aUELgjF6g5STM58fBjd_uVEHuDxZiWAh0eSg=.8af027cf-a44b-4cb1-8d55-e8593cf05323@github.com>

On Tue, 3 Jun 2025 06:35:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8358456?
> 
> In Java 24, through https://bugs.openjdk.org/browse/JDK-8341597 we did a change which started using the "compressed size" field value for computing a input buffer size for the `InflaterInputStream`. The change was reasonable. One part of the change removed a check for  ` <= 0` which would have taken into account invalid/unexpected "compressed size" values:
> From https://github.com/openjdk/jdk/pull/21379
>> There is a check for size <= 0. This condition is unreachable in the current code and in the PR as well, since the compressed size will always be >= 2. I propose we remove this check.
> 
> Without that check, the computed input buffer size can end up being `<= 0` which is an invalid value for a buffer size and thus results in an `IllegalArgumentException` from the `InflaterInputStream` constructor.
> 
> My initial thought was to catch the the `IllegalArgumentException` and rethrow a `ZipException`, but thinking about it, this clearly is more an issue with the value that we computed as an input buffer size. So I believe the right thing here is to reintroduce the check that was previously in place and in such cases just default to reasonable sized buffer. That's what the commit in this PR does. Additionally, I renamed that variable to `inputBufSize` to be clear what this `size` represents.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix. tier testing is currently in progress.
> 
> P.S: As a separate task we might want to do a similar change as what was done in JDK-8341597, to the `ZipFileSystem` code. It currently uses the uncompressed size of the entry to decide the input buffer size.

Hello Eirik,

> Would be interesting to know what kind of tooling produced this invalid/surprising compressed size. The JBS issues does not indicate this from what I can tell.

This was uncovered in tests using ZIP/JAR files created through an internal infrastructure. The tests were validating the exception type being thrown from these APIs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25606#issuecomment-2936020959

From lancea at openjdk.org  Tue Jun  3 16:05:57 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 3 Jun 2025 16:05:57 GMT
Subject: RFR: 8358456: ZipFile.getInputStream(ZipEntry) throws unspecified
 IllegalArgumentException
In-Reply-To: <pGyKc4WnqscGK1Ttq-jFE9dTGkwvfTnUmW_vN_iXpdg=.4fa18e88-400f-4fe0-b8de-44a67e9bf84a@github.com>
References: <pGyKc4WnqscGK1Ttq-jFE9dTGkwvfTnUmW_vN_iXpdg=.4fa18e88-400f-4fe0-b8de-44a67e9bf84a@github.com>
Message-ID: <XE7ymzUR2patBnLObCkQNsjDggZggsP8NR2gZxQktKY=.7493797b-4127-4704-a893-df08b512fda1@github.com>

On Tue, 3 Jun 2025 06:35:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8358456?
> 
> In Java 24, through https://bugs.openjdk.org/browse/JDK-8341597 we did a change which started using the "compressed size" field value for computing a input buffer size for the `InflaterInputStream`. The change was reasonable. One part of the change removed a check for  ` <= 0` which would have taken into account invalid/unexpected "compressed size" values:
> From https://github.com/openjdk/jdk/pull/21379
>> There is a check for size <= 0. This condition is unreachable in the current code and in the PR as well, since the compressed size will always be >= 2. I propose we remove this check.
> 
> Without that check, the computed input buffer size can end up being `<= 0` which is an invalid value for a buffer size and thus results in an `IllegalArgumentException` from the `InflaterInputStream` constructor.
> 
> My initial thought was to catch the the `IllegalArgumentException` and rethrow a `ZipException`, but thinking about it, this clearly is more an issue with the value that we computed as an input buffer size. So I believe the right thing here is to reintroduce the check that was previously in place and in such cases just default to reasonable sized buffer. That's what the commit in this PR does. Additionally, I renamed that variable to `inputBufSize` to be clear what this `size` represents.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix. tier testing is currently in progress.
> 
> P.S: As a separate task we might want to do a similar change as what was done in JDK-8341597, to the `ZipFileSystem` code. It currently uses the uncompressed size of the entry to decide the input buffer size.

Thank you Jai for the changes. 

They look good

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25606#pullrequestreview-2893200034

From jlu at openjdk.org  Tue Jun  3 16:16:08 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Jun 2025 16:16:08 GMT
Subject: Integrated: 8358095: Cleanup tests with explicit locale provider set
 to only CLDR
In-Reply-To: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
Message-ID: <kqCsa1NzrqdMmP8-vK1PxG7qjFoG5BUL9F4Tr63W1L0=.e6514553-b10b-4330-86a6-4fee1e01fe39@github.com>

On Thu, 29 May 2025 21:59:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which cleans up some i18n tests.
> 
> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
> 
> As this change is trivial cleanup, bug IDs are not updated in this change.

This pull request has now been integrated.

Changeset: 04c15466
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/04c15466f68f1208084ee6e5f2322ace707d0446
Stats:     63 lines in 21 files changed: 0 ins; 5 del; 58 mod

8358095: Cleanup tests with explicit locale provider set to only CLDR

Reviewed-by: bpb, naoto

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

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

From jlu at openjdk.org  Tue Jun  3 16:16:07 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Jun 2025 16:16:07 GMT
Subject: RFR: 8358095: Cleanup tests with explicit locale provider set to
 only CLDR [v3]
In-Reply-To: <5cqPWaioFUDsw2wn7U5eCC-YlWAoVx0R7zhSJHzNETY=.8b6e93da-1b95-402c-84dc-c5ba15269160@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
 <5cqPWaioFUDsw2wn7U5eCC-YlWAoVx0R7zhSJHzNETY=.8b6e93da-1b95-402c-84dc-c5ba15269160@github.com>
Message-ID: <qd-gz4QPAoYviH03C5JXOPq1euH8XlEwfh49I4SzVbI=.683fee1a-8dc9-487b-86b0-e11b51f7942c@github.com>

On Fri, 30 May 2025 17:02:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which cleans up some i18n tests.
>> 
>> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
>> 
>> As this change is trivial cleanup, bug IDs are not updated in this change.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-add testCompat to Bug8167143.java

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25532#issuecomment-2936166046

From bpb at openjdk.org  Tue Jun  3 16:35:00 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 3 Jun 2025 16:35:00 GMT
Subject: Integrated: 8354450: A File should be invalid if an element of its
 name sequence ends with a space
In-Reply-To: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
Message-ID: <MdLgF-fF80vclCS7RBwmj5lX1au2dEBlztYyxr1HuRk=.ae0eb1f6-f3c3-45c5-a02a-204d5a79d5e8@github.com>

On Mon, 14 Apr 2025 20:57:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `java.io.WinNTFileSystem::isInvalid`, replace an insufficient test for file path validity with a sufficient test for file path invalidity. Also, add a new test.

This pull request has now been integrated.

Changeset: 57862005
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/57862005f9914ce60aa389a6e35d2e0cd38f8c35
Stats:     104 lines in 2 files changed: 92 ins; 8 del; 4 mod

8354450: A File should be invalid if an element of its name sequence ends with a space

Reviewed-by: alanb

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

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

From weijun at openjdk.org  Tue Jun  3 16:37:53 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 3 Jun 2025 16:37:53 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: <E9b9UD8T3CZoDC8h06KoWMmmFikmVjRpmltbpnCcbpM=.7dd730d3-e0b6-4318-87d3-29ba4152bd04@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <bDqDySX1BG1Y7OOoTeFjpGVoUhOOB5tb8PiaYOaYqas=.6fe24483-812e-4761-8fd7-2dadfe97d69d@github.com>
 <E9b9UD8T3CZoDC8h06KoWMmmFikmVjRpmltbpnCcbpM=.7dd730d3-e0b6-4318-87d3-29ba4152bd04@github.com>
Message-ID: <Vl-kbwNIBs0PMNSVHDHbicUBj6_gqwSHN-8rqUI1BvA=.35f594fc-e149-4ccb-b0c5-7f02ad047b1f@github.com>

On Fri, 30 May 2025 13:59:06 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> > Have you thought about creating a helper method for this purpose even if it's internal? At least, for the tests you can create one in `/test/lib`.
> 
> Required changes are pretty minimal ? passing `System.getProperty("stdin.encoding")` as an argument to the ctor. I doubt adding an extra layer of indirection (plus the need for changes in `@build` and `@library` tags) will worth it.

I?m just not sure if we?ll end up changing the rule again in the future. Hardcoding the system property name makes me a bit uneasy, and the default fallback being hardcoded as well adds to that concern.

That said, the changes to the security tools look good and should work as expected.

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

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2936243501

From jlu at openjdk.org  Tue Jun  3 16:53:27 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Jun 2025 16:53:27 GMT
Subject: RFR: 8358170: Repurpose testCompat in
 test/jdk/java/util/TimeZone/Bug8167143.java
Message-ID: <HrmmeikYwNOcksOC0w_FA77nNhHkdcXWjOIx6cKQWC4=.1d5a6edb-9b7c-4b03-97ce-3c90bc962964@github.com>

Please review this PR which modifies the test/jdk/java/util/TimeZone/Bug8167143.java "testCompat" case to be repurposed to check the implicit locales for the FALLBACK BreakIterator and Collator providers. (FALLBACK is the primary provider in those cases.) Since the method is corrected, it can be re-added as a test case. This change stems from discussion in https://git.openjdk.org/jdk/pull/25532.

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

Commit messages:
 - init

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

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

From naoto at openjdk.org  Tue Jun  3 16:59:18 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 16:59:18 GMT
Subject: RFR: 8358158: test/jdk/java/io/Console/CharsetTest.java failing
 with NoClassDefFoundError: jtreg/SkippedException [v2]
In-Reply-To: <BeaDtq7QEsiy4RqJeWM2SHkOfu8nAfntWQdo-dpgeCE=.77375173-c80a-4556-be99-6707df351681@github.com>
References: <BeaDtq7QEsiy4RqJeWM2SHkOfu8nAfntWQdo-dpgeCE=.77375173-c80a-4556-be99-6707df351681@github.com>
Message-ID: <zAXcq6Dqj6L1aTzmI5BRnHa1cOLh7BrSxA2zSLkOqBI=.6a2610c6-2722-4c6e-abf1-aec27889ded4@github.com>

> Fixing a regression caused by the fix to JDK-8356985. Although the fix in `CharsetTest` was a clean-up and not the gist of the original issue, the change seem to have caused not finding `SkippedException` at runtime in certain cases. Changing the test to JUnit based so that the offending `SkippedException` can be replaced with JUnit's `Assumptions`. Also renamed the test case itself to reflect what's actually tested in it.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Use of OutputAnalyzer.shouldHaveExitValue() where appropriate

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25601/files
  - new: https://git.openjdk.org/jdk/pull/25601/files/2ce00332..24ccb0fc

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

  Stats: 14 lines in 4 files changed: 0 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25601.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25601/head:pull/25601

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

From naoto at openjdk.org  Tue Jun  3 17:08:57 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 17:08:57 GMT
Subject: RFR: 8358158: test/jdk/java/io/Console/CharsetTest.java failing
 with NoClassDefFoundError: jtreg/SkippedException [v2]
In-Reply-To: <PSGB8adDEE6uuJ4tKN6PT5vgGe_j0vSn9IWr03BLPXU=.87595721-786b-4873-85c1-837c1ab351c0@github.com>
References: <BeaDtq7QEsiy4RqJeWM2SHkOfu8nAfntWQdo-dpgeCE=.77375173-c80a-4556-be99-6707df351681@github.com>
 <PSGB8adDEE6uuJ4tKN6PT5vgGe_j0vSn9IWr03BLPXU=.87595721-786b-4873-85c1-837c1ab351c0@github.com>
Message-ID: <X0xEHC88pnyB8K-NiIegiLx7f68gOjBlg9bzHh4cRpE=.cb900b80-d855-4c6f-b55f-2da322e2afce@github.com>

On Tue, 3 Jun 2025 05:48:30 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use of OutputAnalyzer.shouldHaveExitValue() where appropriate
>
> test/jdk/java/io/Console/StdoutEncodingTest.java line 41:
> 
>> 39:  *          Console.charset() method. "expect" command in Windows/Cygwin
>> 40:  *          does not work as expected. Ignoring tests on Windows.
>> 41:  * @requires (os.family == "linux") | (os.family == "mac")
> 
> The previous line say `Ignoring tests on Windows.`, so this line maybe set as
> 
> 
> @requires os.family != "windows"

It is true that the intention is to exclude testing on Windows. However, I would like to keep the testing on the platforms which are guaranteed to work, as the test relies on the behavior of the platforms' executable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25601#discussion_r2124449337

From asemenyuk at openjdk.org  Tue Jun  3 17:09:01 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 3 Jun 2025 17:09:01 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v4]
In-Reply-To: <wWi_NL_McwvSGuBvHJVI5ie3U9lAV4rmoruJf91JDsg=.143f84ac-f8b8-44e9-8377-d94a69a993c7@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <wWi_NL_McwvSGuBvHJVI5ie3U9lAV4rmoruJf91JDsg=.143f84ac-f8b8-44e9-8377-d94a69a993c7@github.com>
Message-ID: <2quvOERuBYY8FJ80GZ1bc4jikaQOKCwLA6YlH4zFJLA=.2fc0ecc3-b985-4e5a-9c10-72df2f4632e8@github.com>

On Tue, 27 May 2025 19:48:11 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

>> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space
>> 
>> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372
>
> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct backtick position

I've updated the title in the JBS record. Please try to integrate.

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

PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2936346338

From naoto at openjdk.org  Tue Jun  3 17:08:59 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 17:08:59 GMT
Subject: RFR: 8358158: test/jdk/java/io/Console/CharsetTest.java failing
 with NoClassDefFoundError: jtreg/SkippedException [v2]
In-Reply-To: <mrpFkFHZOSxrrLRlsxpuNCUh8yb0BJA0vebQ0LwRU1E=.bcc84ea4-447f-4185-a2c7-5617629c6fdf@github.com>
References: <BeaDtq7QEsiy4RqJeWM2SHkOfu8nAfntWQdo-dpgeCE=.77375173-c80a-4556-be99-6707df351681@github.com>
 <mrpFkFHZOSxrrLRlsxpuNCUh8yb0BJA0vebQ0LwRU1E=.bcc84ea4-447f-4185-a2c7-5617629c6fdf@github.com>
Message-ID: <reSPZAiz1GrOLLyWNV6mNnGNsLdRB6Qqz6hmomib3jM=.28b5bc9e-8489-40c8-944a-75fe7509c1c9@github.com>

On Tue, 3 Jun 2025 06:13:35 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use of OutputAnalyzer.shouldHaveExitValue() where appropriate
>
> test/jdk/java/io/Console/StdoutEncodingTest.java line 72:
> 
>> 70:         if (eval != 0) {
>> 71:             throw new RuntimeException("Test failed. Exit value from 'expect' command: " + eval);
>> 72:         }
> 
> suggestion: `assertEquals(0, eval, "exit value");`

Thanks. I replaced it (and other locations applicable) with `OutputAnalyzer.shouldHaveExitValue()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25601#discussion_r2124450355

From jlu at openjdk.org  Tue Jun  3 17:19:27 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Jun 2025 17:19:27 GMT
Subject: RFR: 8358449: Locale.getISOCountries does not specify the returned set
 is unmodifiable
Message-ID: <9Si_Ruzf7n7eVEpEyk1nDssH9q9661mOzNES7OCyELI=.515bdbe0-17fd-4c54-b0e8-4564119274e4@github.com>

Please review this trivial doc correction to `Locale.getISOCountries(Locale.IsoCountryCode type)` which makes it apparent that the returned Set is unmodifiable. Associated CSR filed.

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

Commit messages:
 - init

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

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

From jlu at openjdk.org  Tue Jun  3 17:23:54 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Jun 2025 17:23:54 GMT
Subject: RFR: 8358158: test/jdk/java/io/Console/CharsetTest.java failing
 with NoClassDefFoundError: jtreg/SkippedException [v2]
In-Reply-To: <zAXcq6Dqj6L1aTzmI5BRnHa1cOLh7BrSxA2zSLkOqBI=.6a2610c6-2722-4c6e-abf1-aec27889ded4@github.com>
References: <BeaDtq7QEsiy4RqJeWM2SHkOfu8nAfntWQdo-dpgeCE=.77375173-c80a-4556-be99-6707df351681@github.com>
 <zAXcq6Dqj6L1aTzmI5BRnHa1cOLh7BrSxA2zSLkOqBI=.6a2610c6-2722-4c6e-abf1-aec27889ded4@github.com>
Message-ID: <4C1fhEOXxSgjqKgj56ox0TaPEtgaoReZ8rqsNbgBdR0=.23bf65ad-ca34-4666-9022-6c5c859f6e3f@github.com>

On Tue, 3 Jun 2025 16:59:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing a regression caused by the fix to JDK-8356985. Although the fix in `CharsetTest` was a clean-up and not the gist of the original issue, the change seem to have caused not finding `SkippedException` at runtime in certain cases. Changing the test to JUnit based so that the offending `SkippedException` can be replaced with JUnit's `Assumptions`. Also renamed the test case itself to reflect what's actually tested in it.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use of OutputAnalyzer.shouldHaveExitValue() where appropriate

Swapping the `jtreg.SkippedException` with `Assumptions` looks good, and we would expect no problems since _StdinEncodingTest.java_ has been passing with a similar `Assumptions` set up. LGTM.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25601#pullrequestreview-2893422288

From joehw at openjdk.org  Tue Jun  3 17:28:54 2025
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 3 Jun 2025 17:28:54 GMT
Subject: RFR: 8358158: test/jdk/java/io/Console/CharsetTest.java failing
 with NoClassDefFoundError: jtreg/SkippedException [v2]
In-Reply-To: <zAXcq6Dqj6L1aTzmI5BRnHa1cOLh7BrSxA2zSLkOqBI=.6a2610c6-2722-4c6e-abf1-aec27889ded4@github.com>
References: <BeaDtq7QEsiy4RqJeWM2SHkOfu8nAfntWQdo-dpgeCE=.77375173-c80a-4556-be99-6707df351681@github.com>
 <zAXcq6Dqj6L1aTzmI5BRnHa1cOLh7BrSxA2zSLkOqBI=.6a2610c6-2722-4c6e-abf1-aec27889ded4@github.com>
Message-ID: <1xANki3ljjG7Utr56e6DWmrsqAQriMDXOVp4TzDveCI=.f23e9ed9-97fb-4495-aeeb-458b14354b45@github.com>

On Tue, 3 Jun 2025 16:59:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing a regression caused by the fix to JDK-8356985. Although the fix in `CharsetTest` was a clean-up and not the gist of the original issue, the change seem to have caused not finding `SkippedException` at runtime in certain cases. Changing the test to JUnit based so that the offending `SkippedException` can be replaced with JUnit's `Assumptions`. Also renamed the test case itself to reflect what's actually tested in it.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use of OutputAnalyzer.shouldHaveExitValue() where appropriate

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25601#pullrequestreview-2893434471

From iris at openjdk.org  Tue Jun  3 17:49:51 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 3 Jun 2025 17:49:51 GMT
Subject: RFR: 8358158: test/jdk/java/io/Console/CharsetTest.java failing
 with NoClassDefFoundError: jtreg/SkippedException [v2]
In-Reply-To: <zAXcq6Dqj6L1aTzmI5BRnHa1cOLh7BrSxA2zSLkOqBI=.6a2610c6-2722-4c6e-abf1-aec27889ded4@github.com>
References: <BeaDtq7QEsiy4RqJeWM2SHkOfu8nAfntWQdo-dpgeCE=.77375173-c80a-4556-be99-6707df351681@github.com>
 <zAXcq6Dqj6L1aTzmI5BRnHa1cOLh7BrSxA2zSLkOqBI=.6a2610c6-2722-4c6e-abf1-aec27889ded4@github.com>
Message-ID: <2wmFgHxXiPuCKdSwZvx9b303B1eJZOBb5yCnIZkRAyw=.c13fb8cf-cd8d-4fb8-8874-5436b2541683@github.com>

On Tue, 3 Jun 2025 16:59:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing a regression caused by the fix to JDK-8356985. Although the fix in `CharsetTest` was a clean-up and not the gist of the original issue, the change seem to have caused not finding `SkippedException` at runtime in certain cases. Changing the test to JUnit based so that the offending `SkippedException` can be replaced with JUnit's `Assumptions`. Also renamed the test case itself to reflect what's actually tested in it.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use of OutputAnalyzer.shouldHaveExitValue() where appropriate

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25601#pullrequestreview-2893447856

From jlu at openjdk.org  Tue Jun  3 17:52:13 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Jun 2025 17:52:13 GMT
Subject: RFR: 8358170: Repurpose testCompat in
 test/jdk/java/util/TimeZone/Bug8167143.java [v2]
In-Reply-To: <HrmmeikYwNOcksOC0w_FA77nNhHkdcXWjOIx6cKQWC4=.1d5a6edb-9b7c-4b03-97ce-3c90bc962964@github.com>
References: <HrmmeikYwNOcksOC0w_FA77nNhHkdcXWjOIx6cKQWC4=.1d5a6edb-9b7c-4b03-97ce-3c90bc962964@github.com>
Message-ID: <oQZZaMDXs3KiFup1B7eUfcDTfj7q8fDnMHDmeEPiwqk=.66d196db-31f7-45f6-88c8-c81847b5f1aa@github.com>

> Please review this PR which modifies the test/jdk/java/util/TimeZone/Bug8167143.java "testCompat" case to be repurposed to check the implicit locales for the FALLBACK BreakIterator and Collator providers. (FALLBACK is the primary provider in those cases.) Since the method is corrected, it can be re-added as a test case. This change stems from discussion in https://git.openjdk.org/jdk/pull/25532.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  review - var rename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25621/files
  - new: https://git.openjdk.org/jdk/pull/25621/files/4d587501..a7ce5621

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

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

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

From naoto at openjdk.org  Tue Jun  3 17:52:14 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 17:52:14 GMT
Subject: RFR: 8358170: Repurpose testCompat in
 test/jdk/java/util/TimeZone/Bug8167143.java [v2]
In-Reply-To: <oQZZaMDXs3KiFup1B7eUfcDTfj7q8fDnMHDmeEPiwqk=.66d196db-31f7-45f6-88c8-c81847b5f1aa@github.com>
References: <HrmmeikYwNOcksOC0w_FA77nNhHkdcXWjOIx6cKQWC4=.1d5a6edb-9b7c-4b03-97ce-3c90bc962964@github.com>
 <oQZZaMDXs3KiFup1B7eUfcDTfj7q8fDnMHDmeEPiwqk=.66d196db-31f7-45f6-88c8-c81847b5f1aa@github.com>
Message-ID: <7WYQ5-OG0eL4GnmKGQCUnYTXwUmTuCq-VungHRLISak=.c0125bf7-8844-4018-86b3-05c67099ff12@github.com>

On Tue, 3 Jun 2025 17:46:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which modifies the test/jdk/java/util/TimeZone/Bug8167143.java "testCompat" case to be repurposed to check the implicit locales for the FALLBACK BreakIterator and Collator providers. (FALLBACK is the primary provider in those cases.) Since the method is corrected, it can be re-added as a test case. This change stems from discussion in https://git.openjdk.org/jdk/pull/25532.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review - var rename

Looks good. Thanks for the repurposing the provider

test/jdk/java/util/TimeZone/Bug8167143.java line 239:

> 237:      */
> 238:     private static void testImplicitFallbackLocales() {
> 239:         LocaleProviderAdapter jre = LocaleProviderAdapter.forType(Type.FALLBACK);

Nit: maybe `jre` can be renamed too

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

PR Review: https://git.openjdk.org/jdk/pull/25621#pullrequestreview-2893474483
PR Review Comment: https://git.openjdk.org/jdk/pull/25621#discussion_r2124509694

From jlu at openjdk.org  Tue Jun  3 17:52:15 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Jun 2025 17:52:15 GMT
Subject: RFR: 8358170: Repurpose testCompat in
 test/jdk/java/util/TimeZone/Bug8167143.java [v2]
In-Reply-To: <7WYQ5-OG0eL4GnmKGQCUnYTXwUmTuCq-VungHRLISak=.c0125bf7-8844-4018-86b3-05c67099ff12@github.com>
References: <HrmmeikYwNOcksOC0w_FA77nNhHkdcXWjOIx6cKQWC4=.1d5a6edb-9b7c-4b03-97ce-3c90bc962964@github.com>
 <oQZZaMDXs3KiFup1B7eUfcDTfj7q8fDnMHDmeEPiwqk=.66d196db-31f7-45f6-88c8-c81847b5f1aa@github.com>
 <7WYQ5-OG0eL4GnmKGQCUnYTXwUmTuCq-VungHRLISak=.c0125bf7-8844-4018-86b3-05c67099ff12@github.com>
Message-ID: <knMZNXYwAt3J4bsuMQx3bgzA-WQ40dAy-XYcFJMGXeE=.bf72bb81-de05-40b8-9b91-586937cbedc7@github.com>

On Tue, 3 Jun 2025 17:40:19 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review - var rename
>
> test/jdk/java/util/TimeZone/Bug8167143.java line 239:
> 
>> 237:      */
>> 238:     private static void testImplicitFallbackLocales() {
>> 239:         LocaleProviderAdapter jre = LocaleProviderAdapter.forType(Type.FALLBACK);
> 
> Nit: maybe `jre` can be renamed too

Definitely; updated in https://github.com/openjdk/jdk/pull/25621/commits/a7ce562157a12dd971e492eab29a669b2a960cf2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25621#discussion_r2124520913

From ihse at openjdk.org  Tue Jun  3 17:52:55 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 3 Jun 2025 17:52:55 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v3]
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <9mEkfsOwQAc6LbxKWQHEMF4GbH_icsLrA_JPWDcIAck=.ec8f6cb8-efa5-4d6f-aadc-c1264ee1dd1a@github.com>

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

Magnus Ihse Bursie has updated the pull request with a new target base 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 utf8-minor-cleanup
 - Revert changes in RotFontBoundsTest.java
 - Restore MenuShortcut.java
 - Restore LocaleDataTest.java
 - Replace uncessary unicode characters with ASCII in instructions, and fix typo
 - Seems like typos in the comments
 - Fix unicode sequences in comments (previously missed)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25228/files
  - new: https://git.openjdk.org/jdk/pull/25228/files/7184e685..c3027c1a

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

  Stats: 125596 lines in 1865 files changed: 71361 ins; 38692 del; 15543 mod
  Patch: https://git.openjdk.org/jdk/pull/25228.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25228/head:pull/25228

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

From naoto at openjdk.org  Tue Jun  3 17:52:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 17:52:55 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v3]
In-Reply-To: <9mEkfsOwQAc6LbxKWQHEMF4GbH_icsLrA_JPWDcIAck=.ec8f6cb8-efa5-4d6f-aadc-c1264ee1dd1a@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <9mEkfsOwQAc6LbxKWQHEMF4GbH_icsLrA_JPWDcIAck=.ec8f6cb8-efa5-4d6f-aadc-c1264ee1dd1a@github.com>
Message-ID: <gah_JMPE3xHcudSsDq_iqqxmTfi3edTCv8NCbKznr1M=.67bfc258-b96f-4d60-b2f7-cda514b11b68@github.com>

On Tue, 3 Jun 2025 17:42:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request with a new target base 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 utf8-minor-cleanup
>  - Revert changes in RotFontBoundsTest.java
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java
>  - Replace uncessary unicode characters with ASCII in instructions, and fix typo
>  - Seems like typos in the comments
>  - Fix unicode sequences in comments (previously missed)

> @naotoj Are you happy with the other changes?

Yes. Thank you for the cleanup!

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25228#pullrequestreview-2893481166

From ihse at openjdk.org  Tue Jun  3 17:52:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 3 Jun 2025 17:52:57 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
Message-ID: <DsuF98gTV85TRV5ofvmvH_-7fKmRNk28rI3RJV4e6Gk=.bc6bd102-147c-497e-9734-1bf6863060df@github.com>

On Mon, 26 May 2025 08:20:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java

@naotoj Are you happy with the other changes?

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

PR Comment: https://git.openjdk.org/jdk/pull/25228#issuecomment-2936435086

From naoto at openjdk.org  Tue Jun  3 18:00:39 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 18:00:39 GMT
Subject: RFR: 8358170: Repurpose testCompat in
 test/jdk/java/util/TimeZone/Bug8167143.java [v2]
In-Reply-To: <oQZZaMDXs3KiFup1B7eUfcDTfj7q8fDnMHDmeEPiwqk=.66d196db-31f7-45f6-88c8-c81847b5f1aa@github.com>
References: <HrmmeikYwNOcksOC0w_FA77nNhHkdcXWjOIx6cKQWC4=.1d5a6edb-9b7c-4b03-97ce-3c90bc962964@github.com>
 <oQZZaMDXs3KiFup1B7eUfcDTfj7q8fDnMHDmeEPiwqk=.66d196db-31f7-45f6-88c8-c81847b5f1aa@github.com>
Message-ID: <0EuzPGH-Cxvz8udOUyH6EN6d3lfcpYN6I0YIN60K1ag=.0675c197-3ce1-427d-bebc-351748b9d059@github.com>

On Tue, 3 Jun 2025 17:52:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which modifies the test/jdk/java/util/TimeZone/Bug8167143.java "testCompat" case to be repurposed to check the implicit locales for the FALLBACK BreakIterator and Collator providers. (FALLBACK is the primary provider in those cases.) Since the method is corrected, it can be re-added as a test case. This change stems from discussion in https://git.openjdk.org/jdk/pull/25532.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review - var rename

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25621#pullrequestreview-2893527656

From duke at openjdk.org  Tue Jun  3 18:05:22 2025
From: duke at openjdk.org (duke)
Date: Tue, 3 Jun 2025 18:05:22 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v4]
In-Reply-To: <wWi_NL_McwvSGuBvHJVI5ie3U9lAV4rmoruJf91JDsg=.143f84ac-f8b8-44e9-8377-d94a69a993c7@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <wWi_NL_McwvSGuBvHJVI5ie3U9lAV4rmoruJf91JDsg=.143f84ac-f8b8-44e9-8377-d94a69a993c7@github.com>
Message-ID: <DvERQe9XiB8OmEYOHChfEwahJhiEp9qFHh_ReTVk3c8=.0399621a-fd83-47bb-9c4c-e35a33cb99b2@github.com>

On Tue, 27 May 2025 19:48:11 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

>> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space
>> 
>> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372
>
> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct backtick position

@StefanLobbenmeier 
Your change (at version 51ed08e2bd1b2b865518451d331fc53aee0cb625) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2936543641

From naoto at openjdk.org  Tue Jun  3 18:20:17 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 18:20:17 GMT
Subject: RFR: 8358449: Locale.getISOCountries does not specify the returned
 set is unmodifiable
In-Reply-To: <9Si_Ruzf7n7eVEpEyk1nDssH9q9661mOzNES7OCyELI=.515bdbe0-17fd-4c54-b0e8-4564119274e4@github.com>
References: <9Si_Ruzf7n7eVEpEyk1nDssH9q9661mOzNES7OCyELI=.515bdbe0-17fd-4c54-b0e8-4564119274e4@github.com>
Message-ID: <cVkPkkjWhwsaRbmeF41pfsdUjwcqTPjo2OoFKYQYyxw=.7172c8ee-9c14-41dd-ac78-5984ee4da621@github.com>

On Tue, 3 Jun 2025 17:13:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this trivial doc correction to `Locale.getISOCountries(Locale.IsoCountryCode type)` which makes it apparent that the returned Set is unmodifiable. Associated CSR filed.

Looks good. Reviewed the CSR too, but not sure it would make it for 25 though, as the RDP1 starts the day after tomorrow

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25622#pullrequestreview-2893593915

From jlu at openjdk.org  Tue Jun  3 18:31:16 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Jun 2025 18:31:16 GMT
Subject: RFR: 8358449: Locale.getISOCountries does not specify the returned
 set is unmodifiable
In-Reply-To: <cVkPkkjWhwsaRbmeF41pfsdUjwcqTPjo2OoFKYQYyxw=.7172c8ee-9c14-41dd-ac78-5984ee4da621@github.com>
References: <9Si_Ruzf7n7eVEpEyk1nDssH9q9661mOzNES7OCyELI=.515bdbe0-17fd-4c54-b0e8-4564119274e4@github.com>
 <cVkPkkjWhwsaRbmeF41pfsdUjwcqTPjo2OoFKYQYyxw=.7172c8ee-9c14-41dd-ac78-5984ee4da621@github.com>
Message-ID: <wqhPlOkR9PzDO2HBWSH91W0tB2B4w-cUp4iv6323pJQ=.fe75a69b-3ab7-4377-925e-8cbf59fc3663@github.com>

On Tue, 3 Jun 2025 18:17:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this trivial doc correction to `Locale.getISOCountries(Locale.IsoCountryCode type)` which makes it apparent that the returned Set is unmodifiable. Associated CSR filed.
>
> Looks good. Reviewed the CSR too, but not sure it would make it for 25 though, as the RDP1 starts the day after tomorrow

@naotoj Thanks! I have no issues with deferring if needed, but IIUC I think this change would be fine to make into JDK25 RDP1 since it is a doc-only change.

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

PR Comment: https://git.openjdk.org/jdk/pull/25622#issuecomment-2936646996

From vyazici at openjdk.org  Tue Jun  3 19:08:17 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 3 Jun 2025 19:08:17 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: <Vl-kbwNIBs0PMNSVHDHbicUBj6_gqwSHN-8rqUI1BvA=.35f594fc-e149-4ccb-b0c5-7f02ad047b1f@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <bDqDySX1BG1Y7OOoTeFjpGVoUhOOB5tb8PiaYOaYqas=.6fe24483-812e-4761-8fd7-2dadfe97d69d@github.com>
 <E9b9UD8T3CZoDC8h06KoWMmmFikmVjRpmltbpnCcbpM=.7dd730d3-e0b6-4318-87d3-29ba4152bd04@github.com>
 <Vl-kbwNIBs0PMNSVHDHbicUBj6_gqwSHN-8rqUI1BvA=.35f594fc-e149-4ccb-b0c5-7f02ad047b1f@github.com>
Message-ID: <wYx8GmUa9k8P3LWrlcgLIGdsNsb-iAFq68A8mCYNFi0=.0e5b689f-6d56-4278-bafa-87ea1db6ac2c@github.com>

On Tue, 3 Jun 2025 16:35:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I?m just not sure if we?ll end up changing the rule again in the future. Hardcoding the system property name makes me a bit uneasy, and the default fallback being hardcoded as well adds to that concern.

Thanks so much for the review @wangweij. What would be your preference?

1. Leave things as is
2. Add an internal method to create stdin-aware `Scanner`/`InputStreamReader` (If this is your preference, any hints on which class I shall use? Shall I create a new `src/java.base/share/classes/jdk/internal/io/StdinAware.java`? Something else?)
3. Add a test utility method to create stdin-aware `Scanner`/`InputStreamReader`
4. Something else

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

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2936772995

From duke at openjdk.org  Tue Jun  3 19:25:28 2025
From: duke at openjdk.org (Stefan Lobbenmeier)
Date: Tue, 3 Jun 2025 19:25:28 GMT
Subject: Integrated: 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: <WbUS7_xoBAPigA4OESQfbVqnulPaYXHPC8TmBCYYddE=.96e330ff-3db9-4858-8afc-81b6acc74e7d@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

This pull request has now been integrated.

Changeset: cc11b7d1
Author:    Stefan Lobbenmeier <stefan.lobbenmeier at gmail.com>
Committer: Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc11b7d1f560d42d1de123e650470362f1f2aabb
Stats:     5 lines in 5 files changed: 0 ins; 0 del; 5 mod

8356128: Correct documentation for --linux-package-deps

Reviewed-by: asemenyuk, almatvee

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

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

From weijun at openjdk.org  Tue Jun  3 20:02:27 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 3 Jun 2025 20:02:27 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v4]
In-Reply-To: <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
Message-ID: <vHzpavpczSKL0Mt6tcnqTJ86WVo8GXMBnJRyCKbUh40=.20742ec0-3fe4-4480-86f9-32807e5128d5@github.com>

On Tue, 3 Jun 2025 07:55:06 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing `java.io.Reader` import in `Ktab`

Personally I think both 2 and 3 are good. However, I'm totally OK with keeping your current code if no one else think it's worth a rewrite.

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

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2936969327

From smarks at openjdk.org  Tue Jun  3 20:02:30 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 3 Jun 2025 20:02:30 GMT
Subject: RFR: 8357798: ReverseOrderListView uses Boolean boxes after
 JDK-8356080 [v2]
In-Reply-To: <PhT14YEIl64GPW-wEdPuompsEyae4v7Dsy8VWQXVWrY=.3bd44848-f58a-41e4-9be6-fd115279e951@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
 <PhT14YEIl64GPW-wEdPuompsEyae4v7Dsy8VWQXVWrY=.3bd44848-f58a-41e4-9be6-fd115279e951@github.com>
Message-ID: <IoEJgCTeF7ycglU6SezMoCBxd34mRNFffnL14wZIeac=.abab2139-912b-4802-8787-eed54e6e94ec@github.com>

On Mon, 2 Jun 2025 13:26:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the existence of the boxed object to allow optional constant folding.
>> 
>> We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `java/util`
>
> 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 five additional commits since the last revision:
> 
>  - Just drop back to boolean
>  - Merge branch 'master' into JDK-8357798-reverse-order-list-boxes
>  - A bit better comment
>  - Better fix
>  - Fix

Looks great!

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

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25456#pullrequestreview-2893929543

From naoto at openjdk.org  Tue Jun  3 20:12:17 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 20:12:17 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v4]
In-Reply-To: <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
Message-ID: <0r4lN4voPGXnF1IPlmMGgdyZd54Y4a5GdOsngNbSGlY=.03c9a53f-b044-44d3-affa-4542a7711d8c@github.com>

On Tue, 3 Jun 2025 07:55:06 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing `java.io.Reader` import in `Ktab`

I was thinking if someone made a typo for "stdin.encoding" and then it unknowingly defaults to the fallback. Turned out it immediately fails with "java.lang.IllegalArgumentException: Null charset name" so I think it should be OK.

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

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2937031130

From smarks at openjdk.org  Tue Jun  3 20:17:20 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 3 Jun 2025 20:17:20 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications [v2]
In-Reply-To: <Dn80nyjlzAyyRdJh3xSv2xdqzZUFBl_jYnATxNirfkc=.e761b3d7-cfda-4459-8f05-1b36e127639f@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
 <8gPP7kpzcCSz8A4o0eCUrDhJRqC_atLNvhu87K3wF_Y=.2a49957a-f2bb-40a5-a091-97d634e06457@github.com>
 <Dn80nyjlzAyyRdJh3xSv2xdqzZUFBl_jYnATxNirfkc=.e761b3d7-cfda-4459-8f05-1b36e127639f@github.com>
Message-ID: <9vq8tA47eS-P2oW0rUMhk1YkcTWYq3_7kEibzlRgIXM=.fbb4480b-b2ad-47c5-8b60-6c3728ae4fad@github.com>

On Mon, 2 Jun 2025 20:41:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak nsee() declaration; adjust specs per suggestion; update copyrights.
>
> src/java.base/share/classes/java/util/SequencedMap.java line 296:
> 
>> 294:                 return view().hashCode();
>> 295:             }
>> 296:             public void addFirst(K k) { throw new UnsupportedOperationException(); }
> 
> Any utility in adding `@Override` annotations to the methods to document intent?

The `@Override` annotation has been inconsistently applied in the collections implementations. In practice since so many methods are overridden, and some test would likely fail if a method weren't overridden properly, the annotation would mostly add clutter. Indeed I'm considering pulling out all uses of `@Override` in certain areas because they're just clutter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25515#discussion_r2124847105

From naoto at openjdk.org  Tue Jun  3 23:31:23 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 23:31:23 GMT
Subject: RFR: 8358158: test/jdk/java/io/Console/CharsetTest.java failing
 with NoClassDefFoundError: jtreg/SkippedException [v2]
In-Reply-To: <zAXcq6Dqj6L1aTzmI5BRnHa1cOLh7BrSxA2zSLkOqBI=.6a2610c6-2722-4c6e-abf1-aec27889ded4@github.com>
References: <BeaDtq7QEsiy4RqJeWM2SHkOfu8nAfntWQdo-dpgeCE=.77375173-c80a-4556-be99-6707df351681@github.com>
 <zAXcq6Dqj6L1aTzmI5BRnHa1cOLh7BrSxA2zSLkOqBI=.6a2610c6-2722-4c6e-abf1-aec27889ded4@github.com>
Message-ID: <FbnGozUeJyCP8ZlGYJgvzwZjZqiThITprbV-NI0sJlU=.fe0aa3c7-7697-4766-a151-628906eeadd3@github.com>

On Tue, 3 Jun 2025 16:59:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing a regression caused by the fix to JDK-8356985. Although the fix in `CharsetTest` was a clean-up and not the gist of the original issue, the change seem to have caused not finding `SkippedException` at runtime in certain cases. Changing the test to JUnit based so that the offending `SkippedException` can be replaced with JUnit's `Assumptions`. Also renamed the test case itself to reflect what's actually tested in it.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use of OutputAnalyzer.shouldHaveExitValue() where appropriate

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25601#issuecomment-2937710180

From naoto at openjdk.org  Tue Jun  3 23:31:24 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 23:31:24 GMT
Subject: Integrated: 8358158: test/jdk/java/io/Console/CharsetTest.java failing
 with NoClassDefFoundError: jtreg/SkippedException
In-Reply-To: <BeaDtq7QEsiy4RqJeWM2SHkOfu8nAfntWQdo-dpgeCE=.77375173-c80a-4556-be99-6707df351681@github.com>
References: <BeaDtq7QEsiy4RqJeWM2SHkOfu8nAfntWQdo-dpgeCE=.77375173-c80a-4556-be99-6707df351681@github.com>
Message-ID: <qgsht4rKjA-m-FVda4Reh5JYccgcz8YZ8aaxBBcPzXY=.a59634dd-bfe4-4dbc-ae8f-a47cf34b7a86@github.com>

On Mon, 2 Jun 2025 21:48:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a regression caused by the fix to JDK-8356985. Although the fix in `CharsetTest` was a clean-up and not the gist of the original issue, the change seem to have caused not finding `SkippedException` at runtime in certain cases. Changing the test to JUnit based so that the offending `SkippedException` can be replaced with JUnit's `Assumptions`. Also renamed the test case itself to reflect what's actually tested in it.

This pull request has now been integrated.

Changeset: 9c74d545
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9c74d545147c2eeec187df552037a12b6b476a61
Stats:     224 lines in 7 files changed: 109 ins; 111 del; 4 mod

8358158: test/jdk/java/io/Console/CharsetTest.java failing with NoClassDefFoundError: jtreg/SkippedException

Reviewed-by: joehw, jlu, iris

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

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

From liach at openjdk.org  Tue Jun  3 23:55:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Jun 2025 23:55:22 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message [v5]
In-Reply-To: <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com>
Message-ID: <gOr8ADun9I3BVmVVVuVqzOyyRYUbsoW0IezG5LkCKU4=.094dd65e-1732-4171-9a44-c1f375547cc4@github.com>

On Tue, 20 May 2025 10:54:44 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

>> Motivation:
>> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful.
>> 
>> Modification:
>> Add detail error messages.
>> 
>> Result:
>> Helpful messages.
>
> He-Pin(kerr) has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
>  - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

Or, you can seek to backport this into jdk25u(-dev) repo once RDP1 begin, as if backporting to an LTS release.

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

PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2937766309

From swen at openjdk.org  Wed Jun  4 01:07:29 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 4 Jun 2025 01:07:29 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal [v3]
In-Reply-To: <tqWDLBpdKpgUKK43PKgndhzbeVpr6H5yXf6WtJHBdgk=.2ea13210-b200-4beb-b20e-259100a8c599@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
 <98Ars6Qebvn48y6VXmJUmWnL2TlFUPlvhrjkKVB2MvM=.8b3d7ad7-7f9e-4e82-8189-3767ed5e1188@github.com>
 <tqWDLBpdKpgUKK43PKgndhzbeVpr6H5yXf6WtJHBdgk=.2ea13210-b200-4beb-b20e-259100a8c599@github.com>
Message-ID: <LdDETRsNWj3VZjMRUIMiC18bQMvuaotsfl1ZAzF4PnY=.a9031c48-2660-4c00-bd42-0df7f14d1de7@github.com>

On Mon, 2 Jun 2025 18:23:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   BigInteger::mag remove Stable
>
> A general comment with respect to `@Stable` is that it asserts the field/elements will only change at most once (e.g., an array cannot expand, an element can't be written to more than once (unless the contents is "equivalent")). It is dangerous not to uphold the invariants imposed by `@Stable`. So, triple-checking for potential updates (even via reflection) must be done.

Thank you @minborg  and @ExE-Boss  for your review. I checked again that the static fields marked with @Stable have not been changed after initialization.

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

PR Comment: https://git.openjdk.org/jdk/pull/25437#issuecomment-2937928480

From duke at openjdk.org  Wed Jun  4 02:28:26 2025
From: duke at openjdk.org (duke)
Date: Wed, 4 Jun 2025 02:28:26 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message [v5]
In-Reply-To: <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <4WKAr-Mo_imEyvRkBhuKG8qENEFWokufiR5aX9nhkPw=.1c0941b6-c639-41a8-ae59-c1ea871c401a@github.com>
Message-ID: <otB80eHaRvwOn4bsgazQtiI8BSgZoTtw1IEB690uzXQ=.d8a38625-9428-45f2-991b-57720c333dc3@github.com>

On Tue, 20 May 2025 10:54:44 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

>> Motivation:
>> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful.
>> 
>> Modification:
>> Add detail error messages.
>> 
>> Result:
>> Helpful messages.
>
> He-Pin(kerr) has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
>  - Update src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

@He-Pin 
Your change (at version ad67bd17bcc966a4949607575fa3b84974fb1ee0) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2938108199

From darcy at openjdk.org  Wed Jun  4 04:11:17 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 4 Jun 2025 04:11:17 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications [v2]
In-Reply-To: <9vq8tA47eS-P2oW0rUMhk1YkcTWYq3_7kEibzlRgIXM=.fbb4480b-b2ad-47c5-8b60-6c3728ae4fad@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
 <8gPP7kpzcCSz8A4o0eCUrDhJRqC_atLNvhu87K3wF_Y=.2a49957a-f2bb-40a5-a091-97d634e06457@github.com>
 <Dn80nyjlzAyyRdJh3xSv2xdqzZUFBl_jYnATxNirfkc=.e761b3d7-cfda-4459-8f05-1b36e127639f@github.com>
 <9vq8tA47eS-P2oW0rUMhk1YkcTWYq3_7kEibzlRgIXM=.fbb4480b-b2ad-47c5-8b60-6c3728ae4fad@github.com>
Message-ID: <zdF61ZWS4smTOymsOYnXr4_-nsg8JufkcP7Pn6Hl3Rg=.5dde6f8c-4700-430f-840b-23b3319c1e86@github.com>

On Tue, 3 Jun 2025 20:14:13 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/SequencedMap.java line 296:
>> 
>>> 294:                 return view().hashCode();
>>> 295:             }
>>> 296:             public void addFirst(K k) { throw new UnsupportedOperationException(); }
>> 
>> Any utility in adding `@Override` annotations to the methods to document intent?
>
> The `@Override` annotation has been inconsistently applied in the collections implementations. In practice since so many methods are overridden, and some test would likely fail if a method weren't overridden properly, the annotation would mostly add clutter. Indeed I'm considering pulling out all uses of `@Override` in certain areas because they're just clutter.

It would be helpful in situations like this to have the inverse annotation -- "All methods should be overridden, except the ones marked `@NoOverride`".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25515#discussion_r2125580996

From shade at openjdk.org  Wed Jun  4 06:06:23 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Jun 2025 06:06:23 GMT
Subject: RFR: 8357798: ReverseOrderListView uses Boolean boxes after
 JDK-8356080 [v2]
In-Reply-To: <PhT14YEIl64GPW-wEdPuompsEyae4v7Dsy8VWQXVWrY=.3bd44848-f58a-41e4-9be6-fd115279e951@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
 <PhT14YEIl64GPW-wEdPuompsEyae4v7Dsy8VWQXVWrY=.3bd44848-f58a-41e4-9be6-fd115279e951@github.com>
Message-ID: <NRnXijADnunJDiqhadOuSzp-DaFkK_oROOS7Q8V0FyQ=.c4781c81-7a82-4875-bdca-9a0eb156a06a@github.com>

On Mon, 2 Jun 2025 13:26:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the existence of the boxed object to allow optional constant folding.
>> 
>> We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `java/util`
>
> 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 five additional commits since the last revision:
> 
>  - Just drop back to boolean
>  - Merge branch 'master' into JDK-8357798-reverse-order-list-boxes
>  - A bit better comment
>  - Better fix
>  - Fix

All right, here goes. Thanks all!

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

PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2938685594

From shade at openjdk.org  Wed Jun  4 06:06:24 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Jun 2025 06:06:24 GMT
Subject: Integrated: 8357798: ReverseOrderListView uses Boolean boxes after
 JDK-8356080
In-Reply-To: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
Message-ID: <0lPP8Ww7I9esVQfJPdghEehB14ctgSIVPpefBY1MrTk=.5b73fcbf-e395-4fd6-8cea-3aaa788eaf92@github.com>

On Mon, 26 May 2025 17:08:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the existence of the boxed object to allow optional constant folding.
> 
> We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/util`

This pull request has now been integrated.

Changeset: 683319f2
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/683319f25cbea83e28b9a0ad22e1c3e781e78165
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8357798: ReverseOrderListView uses Boolean boxes after JDK-8356080

Reviewed-by: liach, smarks

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

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

From duke at openjdk.org  Wed Jun  4 06:09:27 2025
From: duke at openjdk.org (Stefan Lobbenmeier)
Date: Wed, 4 Jun 2025 06:09:27 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v4]
In-Reply-To: <wWi_NL_McwvSGuBvHJVI5ie3U9lAV4rmoruJf91JDsg=.143f84ac-f8b8-44e9-8377-d94a69a993c7@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <wWi_NL_McwvSGuBvHJVI5ie3U9lAV4rmoruJf91JDsg=.143f84ac-f8b8-44e9-8377-d94a69a993c7@github.com>
Message-ID: <uNT2ARCANUbI7zbiszSkUX6GJNMoYqKTYgOmHjSJJJk=.e3b6610c-5df9-458c-b269-ac6a1b3a121b@github.com>

On Tue, 27 May 2025 19:48:11 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

>> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space
>> 
>> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372
>
> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct backtick position

Thank you very much for sponsoring ??

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

PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2938694773

From smarks at openjdk.org  Wed Jun  4 06:28:04 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 4 Jun 2025 06:28:04 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications [v3]
In-Reply-To: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
Message-ID: <C-pfucz3j6cweSlvtVyipigFmIN2HerLTL_-XexniBQ=.79b42b9a-6b07-40d3-b9da-40082e719822@github.com>

> For a full explanation, see the bug report [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015).
> 
> This PR includes three related changes:
> * New overrides in SequencedMap view collection implementations, which improve their behavior.
> * Update to `@implSpec` clauses to reflect this behavior (which was previously ill-specified).
> * Update to a test which relied on unspecified behavior.

Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into JDK-8358015-SequencedMap-view-implSpecs
 - Tweak nsee() declaration; adjust specs per suggestion; update copyrights.
 - Update @implSpecs of SequencedMap view methods.
 - Update SequencedMap views to use SequencedMap methods instead of inheriting
   default methods from SequencedCollection.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25515/files
  - new: https://git.openjdk.org/jdk/pull/25515/files/ff9fe9ab..830215f3

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

  Stats: 54047 lines in 888 files changed: 29240 ins; 15574 del; 9233 mod
  Patch: https://git.openjdk.org/jdk/pull/25515.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25515/head:pull/25515

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

From jpai at openjdk.org  Wed Jun  4 06:28:04 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jun 2025 06:28:04 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications [v3]
In-Reply-To: <C-pfucz3j6cweSlvtVyipigFmIN2HerLTL_-XexniBQ=.79b42b9a-6b07-40d3-b9da-40082e719822@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
 <C-pfucz3j6cweSlvtVyipigFmIN2HerLTL_-XexniBQ=.79b42b9a-6b07-40d3-b9da-40082e719822@github.com>
Message-ID: <r__2FK1X5F7HgNEQoN4s1Kk_BcbDQHIdbbqeJpy11vk=.0d477568-d4b6-4eea-972e-8b6e42b1ebd3@github.com>

On Wed, 4 Jun 2025 06:24:57 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> For a full explanation, see the bug report [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015).
>> 
>> This PR includes three related changes:
>> * New overrides in SequencedMap view collection implementations, which improve their behavior.
>> * Update to `@implSpec` clauses to reflect this behavior (which was previously ill-specified).
>> * Update to a test which relied on unspecified behavior.
>
> Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8358015-SequencedMap-view-implSpecs
>  - Tweak nsee() declaration; adjust specs per suggestion; update copyrights.
>  - Update @implSpecs of SequencedMap view methods.
>  - Update SequencedMap views to use SequencedMap methods instead of inheriting
>    default methods from SequencedCollection.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25515#pullrequestreview-2895381564

From jpai at openjdk.org  Wed Jun  4 06:33:19 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jun 2025 06:33:19 GMT
Subject: RFR: 8358456: ZipFile.getInputStream(ZipEntry) throws unspecified
 IllegalArgumentException
In-Reply-To: <pGyKc4WnqscGK1Ttq-jFE9dTGkwvfTnUmW_vN_iXpdg=.4fa18e88-400f-4fe0-b8de-44a67e9bf84a@github.com>
References: <pGyKc4WnqscGK1Ttq-jFE9dTGkwvfTnUmW_vN_iXpdg=.4fa18e88-400f-4fe0-b8de-44a67e9bf84a@github.com>
Message-ID: <OqjWDMykQtFoOyhNTXwqouP5zbQVq5LPuLfwvl14reY=.e51b2ff1-576a-4acd-b198-5e9c6947cabf@github.com>

On Tue, 3 Jun 2025 06:35:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8358456?
> 
> In Java 24, through https://bugs.openjdk.org/browse/JDK-8341597 we did a change which started using the "compressed size" field value for computing a input buffer size for the `InflaterInputStream`. The change was reasonable. One part of the change removed a check for  ` <= 0` which would have taken into account invalid/unexpected "compressed size" values:
> From https://github.com/openjdk/jdk/pull/21379
>> There is a check for size <= 0. This condition is unreachable in the current code and in the PR as well, since the compressed size will always be >= 2. I propose we remove this check.
> 
> Without that check, the computed input buffer size can end up being `<= 0` which is an invalid value for a buffer size and thus results in an `IllegalArgumentException` from the `InflaterInputStream` constructor.
> 
> My initial thought was to catch the the `IllegalArgumentException` and rethrow a `ZipException`, but thinking about it, this clearly is more an issue with the value that we computed as an input buffer size. So I believe the right thing here is to reintroduce the check that was previously in place and in such cases just default to reasonable sized buffer. That's what the commit in this PR does. Additionally, I renamed that variable to `inputBufSize` to be clear what this `size` represents.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix. tier testing is currently in progress.
> 
> P.S: As a separate task we might want to do a similar change as what was done in JDK-8341597, to the `ZipFileSystem` code. It currently uses the uncompressed size of the entry to decide the input buffer size.

Thank you Eirik and Lance for the reviews. tier1, tier2 and tier3 testing completed successfully with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/25606#issuecomment-2938760684

From jpai at openjdk.org  Wed Jun  4 06:41:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jun 2025 06:41:31 GMT
Subject: Integrated: 8358456: ZipFile.getInputStream(ZipEntry) throws
 unspecified IllegalArgumentException
In-Reply-To: <pGyKc4WnqscGK1Ttq-jFE9dTGkwvfTnUmW_vN_iXpdg=.4fa18e88-400f-4fe0-b8de-44a67e9bf84a@github.com>
References: <pGyKc4WnqscGK1Ttq-jFE9dTGkwvfTnUmW_vN_iXpdg=.4fa18e88-400f-4fe0-b8de-44a67e9bf84a@github.com>
Message-ID: <fkzNz6HncTCnpZNAuvj9nTfKsxfwsWjrQLu5vaac3ts=.48af25ed-08f6-4906-ab0b-b1284263402e@github.com>

On Tue, 3 Jun 2025 06:35:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8358456?
> 
> In Java 24, through https://bugs.openjdk.org/browse/JDK-8341597 we did a change which started using the "compressed size" field value for computing a input buffer size for the `InflaterInputStream`. The change was reasonable. One part of the change removed a check for  ` <= 0` which would have taken into account invalid/unexpected "compressed size" values:
> From https://github.com/openjdk/jdk/pull/21379
>> There is a check for size <= 0. This condition is unreachable in the current code and in the PR as well, since the compressed size will always be >= 2. I propose we remove this check.
> 
> Without that check, the computed input buffer size can end up being `<= 0` which is an invalid value for a buffer size and thus results in an `IllegalArgumentException` from the `InflaterInputStream` constructor.
> 
> My initial thought was to catch the the `IllegalArgumentException` and rethrow a `ZipException`, but thinking about it, this clearly is more an issue with the value that we computed as an input buffer size. So I believe the right thing here is to reintroduce the check that was previously in place and in such cases just default to reasonable sized buffer. That's what the commit in this PR does. Additionally, I renamed that variable to `inputBufSize` to be clear what this `size` represents.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix. tier testing is currently in progress.
> 
> P.S: As a separate task we might want to do a similar change as what was done in JDK-8341597, to the `ZipFileSystem` code. It currently uses the uncompressed size of the entry to decide the input buffer size.

This pull request has now been integrated.

Changeset: b5cfd76c
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5cfd76c047392788b6a5c25ebadc463b2c8ce90
Stats:     132 lines in 2 files changed: 124 ins; 0 del; 8 mod

8358456: ZipFile.getInputStream(ZipEntry) throws unspecified IllegalArgumentException

Reviewed-by: lancea

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

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

From kbarrett at openjdk.org  Wed Jun  4 07:00:28 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 4 Jun 2025 07:00:28 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v3]
In-Reply-To: <exAsyfZMy1uYG8NvVHhll1AmgHr67ETeNedXNSTSRcA=.f38cf914-08cc-4eca-9226-c0af3f54de24@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <CxhBye_jinJNbfyBQYStOoZ1Ah1saCPxl1fwMODoeXo=.d54042aa-1113-488d-a2ab-f29f17efcc64@github.com>
 <exAsyfZMy1uYG8NvVHhll1AmgHr67ETeNedXNSTSRcA=.f38cf914-08cc-4eca-9226-c0af3f54de24@github.com>
Message-ID: <JFPMxfN9Ks4nIoqfoBLO4k0YZU37G4c9PjxnmlFhA6s=.49b30db5-ac2c-4162-a9c0-0cb2d001b8a2@github.com>

On Wed, 21 May 2025 05:42:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - add description of BufferCleaner class
>>  - exception handling in cleaner for backward consistency
>>  - detabify
>
> src/java.base/share/classes/java/nio/BufferCleaner.java line 82:
> 
>> 80:                         new Error("nio Cleaner terminated abnormally", x).printStackTrace();
>> 81:                     }
>> 82:                     System.exit(1);
> 
> This is the same behavior as jdk.internal.ref.Cleaner, for which this class is
> substituting in the new regime for DBB management. PR 22165 (and earlier
> versions of this PR) put this in the DBB's Deallocator::run method, but I
> think it's both clearer here, and better to leave the Deallocator as it was in
> mainline and be more consistent with the mainline code.

Also, I think the prior placement from PR22165 doesn't cover the unmapper
case, but only the DBB.Deallocator case, so (I think) was a hidden change from
the baseline use of jdk.internal.ref.Cleaner.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2125821039

From kbarrett at openjdk.org  Wed Jun  4 07:12:42 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 4 Jun 2025 07:12:42 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v8]
In-Reply-To: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
Message-ID: <f38TCAjHwOS64Y5LhxNVogPv8KaK2hxmMgrS_reN8DQ=.0b93f71f-7fa2-4c1f-b2b5-1cb82d130952@github.com>

> Please review this change which adds a native method providing the
> implementation of Reference::get.  Referece::get is an intrinsic candidate, so
> this native method implementation is only used when the intrinsic is not.
> 
> Currently there is intrinsic support by the interpreter, C1, C2, and graal,
> which are always used.  With this change we can later remove all the
> per-platform interpreter intrinsic implementations, and might also remove the
> C1 intrinsic implementation.
> 
> Testing:
> (1) mach5 tier1-6 normal (so using all the existing intrinsics).
> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Merge branch 'master' into native-reference-get
 - make private native Reference.get0 the intrinsic
 - Merge branch 'master' into native-reference-get
 - Merge branch 'master' into native-reference-get
 - use new waitForRefProc, some tidying
 - Merge branch 'master' into native-reference-get
 - remove timeout by using waitForReferenceProcessing
 - make ill-timed gc in non-concurrent case less likely
 - fix test package use
 - add package decl to test
 - ... and 3 more: https://git.openjdk.org/jdk/compare/9578d341...98056a8b

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24315/files
  - new: https://git.openjdk.org/jdk/pull/24315/files/4387e2fe..98056a8b

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

  Stats: 49978 lines in 811 files changed: 26005 ins; 15101 del; 8872 mod
  Patch: https://git.openjdk.org/jdk/pull/24315.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24315/head:pull/24315

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

From kbarrett at openjdk.org  Wed Jun  4 07:12:42 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 4 Jun 2025 07:12:42 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v6]
In-Reply-To: <OO52OkYR36yZwZgtvR6vpVsIz6FzeZeLmmaxnle4fTo=.9a912443-0cd1-4cba-9233-fad8a2e59e21@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <5D6vakt8Q41_YF90LaGoxI0tECxo3hm_fiMCuXrpf-w=.363ecf9a-9421-482d-a101-a7ec1efd8b8e@github.com>
 <ymq-cS14PaC1PpdKAzAZJwxdwtVTbSZtT-LNC21lW6Q=.f956592a-fd59-4bb5-a485-f4138942d290@github.com>
 <lnDH0vCQvoIGjjsjeO7ukv8gpTfp1vWR8hOX-CXlFjA=.a859787f-bc16-40c2-9f9d-ae879e68dc25@github.com>
 <rHMm6DwsyFJIOTQRKO17T0VyOvaxUwxVpwWKw4mpIj8=.d2633532-bc82-4505-a14b-45b46798d4ff@github.com>
 <cskdHy0_3zFOp7bAI-zz6V-avY2vPIcnwIseaE0NrS8=.3c147c4d-78e9-4499-88d3-73fbb40560ab@github.com>
 <wQkKLSTJsvldZxWleQpPTv_9N1ugC067-gv5LUVTdPI=.8917db0c-0653-48f5-acc2-e040a61f650a@github.com>
 <DOmW1DiflE8ovJmLEHeU8S8laqzbcy1gjqfRsJaMyUU=.8bca0d18-8ffa-402d-af96-66236f6b84c2@github.com>
 <_99Geoayi09Ey7YT7qWw4pjMqbVUNxfKpFBwwI_EbHg=.e81158ae-813c-4015-94d6-4404eb756394@github.com>
 <ZS11BbUZhXvjekz9J6Nx0YdmsRy4vi8Xc4LUc-60I_w=.d0f276f4-f023-4414-9fc2-8000ffa4e0c1@github.com>
 <wIIM4tKR9hV6IpgsQN6YWxG8DTw8Ua-vl5f
 AYDpKsw8=.38c3e194-dc26-44bc-bf56-29957fe2361f@github.com>
 <OO52OkYR36yZwZgtvR6vpVsIz6FzeZeLmmaxnle4fTo=.9a912443-0cd1-4cba-9233-fad8a2e59e21@github.com>
Message-ID: <oToOeIUTei6UI5ut4WznU6kGm680BHrKj1JoJLvBOH0=.92099d6c-6b4b-41d6-a859-808b83421341@github.com>

On Fri, 30 May 2025 19:30:50 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Much of the point of this change is to let us later remove the interpreter/c1
>> intrinsics for this function. I think what you are saying is that might be
>> tricky if `get()` is the intrinsic. So maybe I should just go ahead now with
>> making the native `get0()` be the intrinsic. I'll take a look at it and see
>> how widespread the renaming changes are.
>> 
>> If `get0()` is the intrinsic, then I think that referenced snippet from the
>> Compile ctor can go away? Rather than being changed to refer to the get0
>> intrinsic.
>
>> If get0() is the intrinsic, then I think that referenced snippet from the
> Compile ctor can go away? 
> 
> Yes.

OK, I've moved the intrinsification to get0.  It adds a fair number of files, but the changes are mostly trivial
renaming of "get" to "get0".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2125849565

From ihse at openjdk.org  Wed Jun  4 08:14:23 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 4 Jun 2025 08:14:23 GMT
Subject: Integrated: 8356977: UTF-8 cleanups
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <At8VnpzuhZYQNUNMKjqDDQJWpn-95O-PP01qGcpOB20=.8371e2ec-5f36-4a13-b566-6482ac2b6667@github.com>

On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

This pull request has now been integrated.

Changeset: edf92721
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/edf92721c2db4cfba091cf4901af603db8486951
Stats:     15 lines in 13 files changed: 0 ins; 0 del; 15 mod

8356977: UTF-8 cleanups

Reviewed-by: naoto, prr

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

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

From duke at openjdk.org  Wed Jun  4 08:31:30 2025
From: duke at openjdk.org (He-Pin (kerr))
Date: Wed, 4 Jun 2025 08:31:30 GMT
Subject: Integrated: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message
In-Reply-To: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
Message-ID: <6RVn5K1qkoAy5DNiKQgw9A-MXIV4NnDZY9dZp6r-dy0=.fbffa1da-4584-4db1-a7a9-ffdc69a3e504@github.com>

On Sat, 11 Jan 2025 07:10:53 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.

This pull request has now been integrated.

Changeset: f141674d
Author:    He-Pin(kerr) <hepin1989 at gmail.com>
Committer: Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f141674d1619d95053d38a9cd8f93a8959b4a211
Stats:     269 lines in 4 files changed: 170 ins; 21 del; 78 mod

8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message

Reviewed-by: vklang, liach, pminborg

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

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

From pminborg at openjdk.org  Wed Jun  4 10:39:24 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 4 Jun 2025 10:39:24 GMT
Subject: RFR: 8357798: ReverseOrderListView uses Boolean boxes after
 JDK-8356080 [v2]
In-Reply-To: <PhT14YEIl64GPW-wEdPuompsEyae4v7Dsy8VWQXVWrY=.3bd44848-f58a-41e4-9be6-fd115279e951@github.com>
References: <LfVV8uHpWMqkJSRGudVFGbmNts0kNH-ofv2Jrtbaxe8=.ede88208-375c-4bad-bc95-2e759915ede3@github.com>
 <PhT14YEIl64GPW-wEdPuompsEyae4v7Dsy8VWQXVWrY=.3bd44848-f58a-41e4-9be6-fd115279e951@github.com>
Message-ID: <dgvYP0b7c-mpBCT37Zd-agQnczwR2gnNhpQqwlb4kwc=.6276748b-ef46-4c34-95aa-067e6afd1bd2@github.com>

On Mon, 2 Jun 2025 13:26:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> SonarCloud complains that since [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` was made in [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable` folding of boolean field. But it is very awkward to trade in the existence of the boxed object to allow optional constant folding.
>> 
>> We can flatten this field to `byte` and check the specific non-zero values. The field is final, so it is never actually in `0` state.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `java/util`
>
> 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 five additional commits since the last revision:
> 
>  - Just drop back to boolean
>  - Merge branch 'master' into JDK-8357798-reverse-order-list-boxes
>  - A bit better comment
>  - Better fix
>  - Fix

Late to the party, but I agree this is a reasonable change.

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

PR Comment: https://git.openjdk.org/jdk/pull/25456#issuecomment-2939505116

From egahlin at openjdk.org  Wed Jun  4 11:34:24 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Jun 2025 11:34:24 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
Message-ID: <bLfJIXOSXfrN-_id6hgutPMxJyeDvfya-o5X8x5AsEc=.8582bbda-fb3e-4d18-992c-c9699b8f68f3@github.com>

On Tue, 3 Jun 2025 12:50:49 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix adjust boundary

@AlanBateman Do you have time for a review?

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

PR Comment: https://git.openjdk.org/jdk/pull/25559#issuecomment-2939669198

From pminborg at openjdk.org  Wed Jun  4 11:42:17 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 4 Jun 2025 11:42:17 GMT
Subject: RFR: 8357821: Revert incorrectly named JavaLangAccess::unchecked*
 methods
In-Reply-To: <wqqD43dK-OFxmDgiJe4CphOLXmzODWdGTjWAhO8KO2o=.682028b3-5ec8-450c-ad21-783328af758b@github.com>
References: <tDzMTU2VeD_fIb5s8gweKAF1fnz5p6y7kWgGkWcpMAY=.749b0bce-e6e0-490f-a6eb-f584c3f7166f@github.com>
 <wqqD43dK-OFxmDgiJe4CphOLXmzODWdGTjWAhO8KO2o=.682028b3-5ec8-450c-ad21-783328af758b@github.com>
Message-ID: <IZG_8Y678RGrqZCI3vzu0i8zMO3HOWPR1z1Yhbu-NAU=.68d39f3a-1906-4414-aabf-3103b3f00c1e@github.com>

On Tue, 3 Jun 2025 09:10:04 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> > I wonder if we should add that implementations of the affected method _shall_ do bounds checking to reduce the likelihood of a new/updated native implementation miss that?
> 
> @minborg, would you mind elaborating on this a bit, please? Do you imply adding an `@implSpec` to the touched `JavaLangAccess` methods?

Yes, I think that would be a good thing to do.

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

PR Comment: https://git.openjdk.org/jdk/pull/25545#issuecomment-2939694237

From alanb at openjdk.org  Wed Jun  4 12:10:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 12:10:20 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <bLfJIXOSXfrN-_id6hgutPMxJyeDvfya-o5X8x5AsEc=.8582bbda-fb3e-4d18-992c-c9699b8f68f3@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <bLfJIXOSXfrN-_id6hgutPMxJyeDvfya-o5X8x5AsEc=.8582bbda-fb3e-4d18-992c-c9699b8f68f3@github.com>
Message-ID: <us23R2nkGfg4Fisd7aTuf2-qDgnmaTn7sbqe0wuvphc=.ee7dcfdb-ae16-4f97-bae6-0328079a09ed@github.com>

On Wed, 4 Jun 2025 11:31:21 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> @AlanBateman Do you have time for a review?

Yes, looking at the changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25559#issuecomment-2939787559

From pminborg at openjdk.org  Wed Jun  4 12:11:27 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 4 Jun 2025 12:11:27 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal [v3]
In-Reply-To: <98Ars6Qebvn48y6VXmJUmWnL2TlFUPlvhrjkKVB2MvM=.8b3d7ad7-7f9e-4e82-8189-3767ed5e1188@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
 <98Ars6Qebvn48y6VXmJUmWnL2TlFUPlvhrjkKVB2MvM=.8b3d7ad7-7f9e-4e82-8189-3767ed5e1188@github.com>
Message-ID: <q1GKDvad3GF4chYQRDF28JvCV9nJ6QmllaoaP3WJBGs=.960db4f5-8c1b-44e1-aa19-b5424120f493@github.com>

On Fri, 30 May 2025 22:07:06 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Some static final arrays of BigInteger and BigDecimal are stable and immutable. We should add `@Stable` to give the optimizer more information
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BigInteger::mag remove Stable

The newly marked arrays are indeed only updated once. Can we see any benchmark showing a performance gain?

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

PR Comment: https://git.openjdk.org/jdk/pull/25437#issuecomment-2939788232

From swen at openjdk.org  Wed Jun  4 13:12:33 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 4 Jun 2025 13:12:33 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal [v4]
In-Reply-To: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
Message-ID: <nOyjL13Gw7c91vi9NtdXLyLpyI9VpoFTRaWzHcM9Quk=.c9ed3ca3-fe1a-4e69-a058-dcc13e5a0f4f@github.com>

> Some static final arrays of BigInteger and BigDecimal are stable and immutable. We should add `@Stable` to give the optimizer more information

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into math_stable_202505
 - BigInteger::mag remove Stable
 - bug fix, from @minborg
 - BigInteger::mag add `@Stable`
 - add stable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25437/files
  - new: https://git.openjdk.org/jdk/pull/25437/files/4e9be2c6..0edf6830

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

  Stats: 67304 lines in 1146 files changed: 37501 ins; 18443 del; 11360 mod
  Patch: https://git.openjdk.org/jdk/pull/25437.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25437/head:pull/25437

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

From asemenyuk at openjdk.org  Wed Jun  4 13:18:13 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 4 Jun 2025 13:18:13 GMT
Subject: RFR: 8356128: Correct documentation for --linux-package-deps [v4]
In-Reply-To: <wWi_NL_McwvSGuBvHJVI5ie3U9lAV4rmoruJf91JDsg=.143f84ac-f8b8-44e9-8377-d94a69a993c7@github.com>
References: <EREeytO0tfJKeSsi2IE3M16-UlMZDBJk9KmVf2GbWCo=.ce096360-6f19-4418-ac76-def4e78cdc88@github.com>
 <wWi_NL_McwvSGuBvHJVI5ie3U9lAV4rmoruJf91JDsg=.143f84ac-f8b8-44e9-8377-d94a69a993c7@github.com>
Message-ID: <DKdGNOnYMQqY85N4MQKRiIglBCU_HU5N04oJ0416Tvw=.d9dc403b-ec49-437c-84c1-cd7841be1c66@github.com>

On Tue, 27 May 2025 19:48:11 GMT, Stefan Lobbenmeier <duke at openjdk.org> wrote:

>> The documentation suggests that --linux-package-deps is a boolean option, while in fact it is a string option with dependencies separated by comma and space
>> 
>> You can tell that this option is supposed to have an argument here: https://github.com/openjdk/jdk/blob/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java#L366-L372
>
> Stefan Lobbenmeier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct backtick position

No problem. Thank you for your contribution!

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

PR Comment: https://git.openjdk.org/jdk/pull/23638#issuecomment-2940003401

From shade at openjdk.org  Wed Jun  4 13:19:26 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Jun 2025 13:19:26 GMT
Subject: RFR: 8358588: ThreadSnapshot.ThreadLock should be static nested class
Message-ID: <yl_murI005bnuwvL1KcpN7jmXlbkivSD69yvW9jldGU=.a1d787d3-16e9-4e18-a3f5-5e0cfcde0a0c@github.com>

SonarCloud points out that ThreadLock class introduced by [JDK-8357650](https://bugs.openjdk.org/browse/JDK-8357650) can be turned into static nested class. I don't think this shows any real bug yet, as unreferenced enclosing class reference gets nowhere. But it would be nice to be extra crisp here.

Additional testing:
 - [ ] Linux x86_64 server fastdebug, `serviceability/`

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

Commit messages:
 - Fix

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

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

From jpai at openjdk.org  Wed Jun  4 13:19:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jun 2025 13:19:31 GMT
Subject: RFR: 8358558: (zipfs) Reorder the listing of accessMode property in
 the ZIP file system's documentation
Message-ID: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>

Can I please get a review of this trivial doc-only change to the `jdk.zipfs`'s documentation? This moves the `accessMode` property listing to the top of the table instead of being at the bottom. With this change, the text about throwing `IllegalArgumentException` when `create=true` and `accessMode=readOnly` has been moved to the `create` property's description.

No functional or specification changes are involved. I verified that the generated documentation looks fine too.

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

Commit messages:
 - 8358558: (zipfs) Reorder the listing of accessMode property in the ZIP file system's documentation

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

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

From jpai at openjdk.org  Wed Jun  4 13:19:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jun 2025 13:19:31 GMT
Subject: RFR: 8358558: (zipfs) Reorder the listing of accessMode property
 in the ZIP file system's documentation
In-Reply-To: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
References: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
Message-ID: <ZbQ9B1_udGdO2m-hBJSnGBAA75KaYazBP_Zsaww2CeE=.51a4ba42-38a4-46d6-b292-f4c3a46491bf@github.com>

On Wed, 4 Jun 2025 06:47:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial doc-only change to the `jdk.zipfs`'s documentation? This moves the `accessMode` property listing to the top of the table instead of being at the bottom. With this change, the text about throwing `IllegalArgumentException` when `create=true` and `accessMode=readOnly` has been moved to the `create` property's description.
> 
> No functional or specification changes are involved. I verified that the generated documentation looks fine too.

Hello Volkan, the alphabetical ordering wasn't an intention of this change. But after what you noted, I was almost considering making it alphabetically ordered, but then I noticed that I will also have to move down the properties `encoding` and `enablePosixFileAttributes`. So I think it's not worth it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25634#issuecomment-2939124076

From dfuchs at openjdk.org  Wed Jun  4 13:19:31 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 13:19:31 GMT
Subject: RFR: 8358558: (zipfs) Reorder the listing of accessMode property
 in the ZIP file system's documentation
In-Reply-To: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
References: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
Message-ID: <H0faOWkhqoh6QyZRjVQAAHbXjhIX1au_N-EJhyFR_Ak=.fb18a202-ec04-460a-ba13-aa611571bc9a@github.com>

On Wed, 4 Jun 2025 06:47:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial doc-only change to the `jdk.zipfs`'s documentation? This moves the `accessMode` property listing to the top of the table instead of being at the bottom. With this change, the text about throwing `IllegalArgumentException` when `create=true` and `accessMode=readOnly` has been moved to the `create` property's description.
> 
> No functional or specification changes are involved. I verified that the generated documentation looks fine too.

src/jdk.zipfs/share/classes/module-info.java line 195:

> 193:  *       If the value is {@code true}, the ZIP file system provider creates a
> 194:  *       new ZIP or JAR file if it does not exist. Specifying the {@code create}
> 195:  *       property as {@code true} with the {@code accessMode} as {@code readOnly}

should we change that to `with <em>read-only</em> {@code accessMode}` or to `with the {@code accessMode} as {@code "readOnly"}`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25634#discussion_r2126150769

From vyazici at openjdk.org  Wed Jun  4 13:19:31 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 4 Jun 2025 13:19:31 GMT
Subject: RFR: 8358558: (zipfs) Reorder the listing of accessMode property
 in the ZIP file system's documentation
In-Reply-To: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
References: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
Message-ID: <FSstef0Db1nyXEzKcz172RzXW-mEbJ43_7V9VJ8plPA=.822533e0-7b15-4d29-8821-77e345d3454a@github.com>

On Wed, 4 Jun 2025 06:47:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial doc-only change to the `jdk.zipfs`'s documentation? This moves the `accessMode` property listing to the top of the table instead of being at the bottom. With this change, the text about throwing `IllegalArgumentException` when `create=true` and `accessMode=readOnly` has been moved to the `create` property's description.
> 
> No functional or specification changes are involved. I verified that the generated documentation looks fine too.

I don't know if it is a goal, but this change also helps with establishing the alphabetical order in the table, with one exception: `compressionMethod`. Would it make sense to move `compressionMethod` up accordingly too?

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

Marked as reviewed by vyazici (Author).

PR Review: https://git.openjdk.org/jdk/pull/25634#pullrequestreview-2895787229

From jpai at openjdk.org  Wed Jun  4 13:20:39 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jun 2025 13:20:39 GMT
Subject: RFR: 8349914: ZipFile::entries and ZipFile::getInputStream not
 consistent with each other when there are duplicate entries
Message-ID: <iwdjrcKGI2cp3q-DG7LcJKvUkVmPRVSCTeEpjtmW8TU=.d14e454a-2c9a-4b6f-8ebd-32f885e61398@github.com>

Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8349914?

The ZIP specification allows for more than one entry to have the same file name (and may have different file data). In such situation, as noted in the linked issue, the `ZipFile.getInputStream(ZipEntry)` may end up picking up an "incorrect" entry content (and metadata) for the passed entry.

The commit in this PR addresses that issue by holding on to the LOC offset of the entry in the `ZipEntry` class. This way, whenever that `ZipEntry` instance is used, it knows which exact entry it represents.

A new jtreg test has been introduced to reproduce the issue and verify the fix. The new test and existing tests in tier1, tier2 and tier3 pass with this change.

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

Commit messages:
 - 8349914: ZipFile::entries and ZipFile::getInputStream not consistent with each other when there are duplicate entries

Changes: https://git.openjdk.org/jdk/pull/25635/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25635&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349914
  Stats: 237 lines in 3 files changed: 233 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25635.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25635/head:pull/25635

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

From alanb at openjdk.org  Wed Jun  4 13:35:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 13:35:52 GMT
Subject: RFR: 8358558: (zipfs) Reorder the listing of accessMode property
 in the ZIP file system's documentation
In-Reply-To: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
References: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
Message-ID: <VMUz2hU_D0h0LZtwFzuPkaYLBUTG7Mr66RR49OCxbWA=.80532cd4-1d6c-432c-8bcc-127f46bfdd0c@github.com>

On Wed, 4 Jun 2025 06:47:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial doc-only change to the `jdk.zipfs`'s documentation? This moves the `accessMode` property listing to the top of the table instead of being at the bottom. With this change, the text about throwing `IllegalArgumentException` when `create=true` and `accessMode=readOnly` has been moved to the `create` property's description.
> 
> No functional or specification changes are involved. I verified that the generated documentation looks fine too.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25634#pullrequestreview-2896763397

From alanb at openjdk.org  Wed Jun  4 13:35:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 13:35:54 GMT
Subject: RFR: 8358558: (zipfs) Reorder the listing of accessMode property
 in the ZIP file system's documentation
In-Reply-To: <ZbQ9B1_udGdO2m-hBJSnGBAA75KaYazBP_Zsaww2CeE=.51a4ba42-38a4-46d6-b292-f4c3a46491bf@github.com>
References: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
 <ZbQ9B1_udGdO2m-hBJSnGBAA75KaYazBP_Zsaww2CeE=.51a4ba42-38a4-46d6-b292-f4c3a46491bf@github.com>
Message-ID: <E5ordGlZaunkkjQ2XKsxG6gcUkiDEmqVKGr2NuVrnSA=.7f507139-e4bd-44ac-9d37-c53b50d270c3@github.com>

On Wed, 4 Jun 2025 08:35:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Volkan, the alphabetical ordering wasn't an intention of this change. But after what you noted, I was almost considering making it alphabetically ordered, but then I noticed that I will also have to move down the properties `encoding` and `enablePosixFileAttributes`. So I think it's not worth it.

The motivation for suggesting the re-order was to have "accessMode" before "create" so that the description of the latter would be the replace to document that create + readOnly is a combination that is not allowed.  I'd prefer if they weren't changed to be  alphabetical as that would cause the permissions + owner/group to get separated in the table and I think better to have them follow each other.

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

PR Comment: https://git.openjdk.org/jdk/pull/25634#issuecomment-2940065433

From lancea at openjdk.org  Wed Jun  4 13:51:53 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 4 Jun 2025 13:51:53 GMT
Subject: RFR: 8358558: (zipfs) Reorder the listing of accessMode property
 in the ZIP file system's documentation
In-Reply-To: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
References: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
Message-ID: <RGcTEZFD9M06WvYmEQxgkSUB38PriLztLUiIMCYPBC4=.79e643b6-8e6c-4dd7-b106-1aac2b312ec0@github.com>

On Wed, 4 Jun 2025 06:47:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial doc-only change to the `jdk.zipfs`'s documentation? This moves the `accessMode` property listing to the top of the table instead of being at the bottom. With this change, the text about throwing `IllegalArgumentException` when `create=true` and `accessMode=readOnly` has been moved to the `create` property's description.
> 
> No functional or specification changes are involved. I verified that the generated documentation looks fine too.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25634#pullrequestreview-2896819802

From rgiulietti at openjdk.org  Wed Jun  4 13:55:53 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 4 Jun 2025 13:55:53 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal [v2]
In-Reply-To: <_TTbaqxnk9iDRAkGkRp3YFGsuTX87abbtfEP2X3iqlE=.af987502-4705-4273-bbb5-8505d3534fda@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
 <lp1xFhlZNmOPvbkAsqk1nWHA_edVtGbkbryGXZGwjTg=.e824710a-4cac-48ea-a65c-3ddabfa27a22@github.com>
 <VxyY6tC-siH_6C0HrNpIIvBJ-tPlmJKEqSW7ioK51m8=.b85fd988-3ac6-416a-a7fd-8cdca298b8af@github.com>
 <_TTbaqxnk9iDRAkGkRp3YFGsuTX87abbtfEP2X3iqlE=.af987502-4705-4273-bbb5-8505d3534fda@github.com>
Message-ID: <IT1oGbYtZGIme2JaERmFSKcMzjvEItU_lTSCgDutxnc=.fec0e3ae-f74d-41ee-be4f-31c2acb0322b@github.com>

On Fri, 30 May 2025 22:21:34 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 192:
>> 
>>> 190:      * zero-length mag array.
>>> 191:      */
>>> 192:     @Stable
>> 
>> `BigInteger.mag` gets?written?to a?few?times during?computation in?`BigInteger?.largePrime(?)`: <https://github.com/openjdk/jdk/blob/db340e54f83cf7bf72abb94c9cf9cdac007ed38a/src/java.base/share/classes/java/math/BigInteger.java#L886-L887><https://github.com/openjdk/jdk/blob/db340e54f83cf7bf72abb94c9cf9cdac007ed38a/src/java.base/share/classes/java/math/BigInteger.java#L895-L898>
>
> BigInteger is an object that is considered immutable, but its field mag is actually changed. This is incredible and should be fixed here. It is easy to make mistakes.

Please do _not_ fix the `mag` issue in this PR.
I'll take care of it in a future PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25437#discussion_r2126665207

From rgiulietti at openjdk.org  Wed Jun  4 14:06:52 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 4 Jun 2025 14:06:52 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal [v2]
In-Reply-To: <IT1oGbYtZGIme2JaERmFSKcMzjvEItU_lTSCgDutxnc=.fec0e3ae-f74d-41ee-be4f-31c2acb0322b@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
 <lp1xFhlZNmOPvbkAsqk1nWHA_edVtGbkbryGXZGwjTg=.e824710a-4cac-48ea-a65c-3ddabfa27a22@github.com>
 <VxyY6tC-siH_6C0HrNpIIvBJ-tPlmJKEqSW7ioK51m8=.b85fd988-3ac6-416a-a7fd-8cdca298b8af@github.com>
 <_TTbaqxnk9iDRAkGkRp3YFGsuTX87abbtfEP2X3iqlE=.af987502-4705-4273-bbb5-8505d3534fda@github.com>
 <IT1oGbYtZGIme2JaERmFSKcMzjvEItU_lTSCgDutxnc=.fec0e3ae-f74d-41ee-be4f-31c2acb0322b@github.com>
Message-ID: <rSnQYMg2s_mZ7f9XV9zHdxPGFm-vzI6zUAgyt_hnXGM=.14ccf0d8-5231-47ff-b568-e14fbb9ea485@github.com>

On Wed, 4 Jun 2025 13:53:09 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> BigInteger is an object that is considered immutable, but its field mag is actually changed. This is incredible and should be fixed here. It is easy to make mistakes.
>
> Please do _not_ fix the `mag` issue in this PR.
> I'll take care of it in a future PR.

I just filed [JDK-8358599](https://bugs.openjdk.org/browse/JDK-8358599).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25437#discussion_r2126690570

From yujige at gmail.com  Wed Jun  4 14:20:41 2025
From: yujige at gmail.com (Jige Yu)
Date: Wed, 4 Jun 2025 07:20:41 -0700
Subject: [External] : Re: Should mapConcurrent() respect time order
 instead of input order?
In-Reply-To: <MW4PR10MB57749F82094174F71CF0BB56FF6DA@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAKD1RYuoK07OvAn02v4qq74Q1QDfpQpf=t0J0VT-s1zi4iKRnA@mail.gmail.com>
 <MW4PR10MB5774AED3EC215ED5AB3AD52CFF62A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtLy_yC+L5+q1YOkbEvUis5LJ-tJNJDbyoptq8A=+W3eg@mail.gmail.com>
 <CAKD1RYuksGCWsqj6cnu3aoHqkzAepLeNHsGSX_nCi2QryJaGMQ@mail.gmail.com>
 <SJ0PR10MB5766DAA744887EE8B0A2B991FF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYvhpcD=yAGAvTTi+c8sdjDAi776GCPCAdvsCCVF9JQpeQ@mail.gmail.com>
 <SJ0PR10MB5766DB20AB83B1199C7987EAFF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYst6GOErvVozZ2SD6JGhTRUAugSHZFM7aY+5Je72iF3wA@mail.gmail.com>
 <MW4PR10MB57749F82094174F71CF0BB56FF6DA@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAKD1RYu3CUT5nOj9i-cv_n7T=FXvwBpx3BQp6px6Mk2zg6GZNA@mail.gmail.com>

Hi Viktor,

Thank you for sharing that the general feedback on mapConcurrent() has been
positive and for the insights into the ongoing enhancements, especially
around interruption handling and work-in-progress tracking.

To clarify my own position, I am also extremely enthusiastic about the
mapConcurrent() API overall. It offers an elegant and straightforward way
to manage homogenous, I/O-intensive concurrent tasks within a structured
concurrency model, which is a significant improvement and a much-needed
addition. My feedback on ordering is aimed at maximizing its potential.

I'd like to elaborate on a few specific scenarios and expectations that
inform my perspective on the ordering:

   1.

   *Temptation for Race Semantics:* The beauty of mapConcurrent()
   integrating with the Stream API means developers will naturally be drawn to
   use it for race-like scenarios. Operations like findFirst() or limit(N)
   to get the first few completed results are very intuitive combinations. For
   example:
   Java

   // Hypothetical use case: find the fastest responding service
   Optional<Result> fastestResult = serviceUrls.stream()
       .gather(Gatherers.mapConcurrent(MAX_CONCURRENCY, url -> fetch(url)))
       .findFirst();

   2.

   *Surprise for Race Semantics Users:* Following from the above, it could
   be surprising for developers when they realize that the inherent input
   ordering of mapConcurrent() means it's not optimized for these race
   scenarios. The expectation would be that findFirst() returns as soon as
   *any* task completes, but ordering can delay this if an earlier task (in
   input order) is slower.
   3.

   *Ordering Assumption in Concurrency:* My experience is that ordering is
   not typically a default assumption when dealing with operations explicitly
   marked as "parallel" or "concurrent." For instance, Stream.forEach() on
   a parallel stream does not guarantee encounter order, presumably for
   performance reasons ? a similar trade-off to what's being discussed for
   mapConcurrent(). Developers often consult documentation for ordering
   guarantees in concurrent contexts rather than assuming them.
   4.

   *Expectation of "True" Concurrency:* When I see an API like
mapConcurrent(maxConcurrency,
   mapper), my mental model is that if maxConcurrency permits, new tasks
   should be initiated as soon as a slot is free. For example, with
   maxConcurrency=2:
   - Task 1 starts.
      - Task 2 starts.
      - If Task 2 finishes while Task 1 is still running, I would expect
      Task 3 to run concurrently alongside task 1, because the max
concurrency is
      2, not 1. The current ordered behavior, where Task 3 might have
to wait for
      Task 1 to complete before its result can be processed (even if Task 3
      itself could have started and finished), can feel a bit
counterintuitive to
      the notion of maximizing concurrency up to the specified limit. It almost
      feels like not a "max concurrency", but "max buffer size".

These points are offered to highlight potential areas where the current
default could lead to subtle surprises or suboptimal performance for useful
concurrent patterns.

Thanks again for the open discussion and for your work on these valuable
additions to the JDK.

Best regards,

On Tue, Jun 3, 2025 at 2:13?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> The general feedback received thus far has been primarily positive. There
> have been a few behavior-related enhancements over the previews to better
> handle interruption (there's still room to improve there, as per our
> concurrent conversation) as well as some improvements to work-in-progress
> tracking.
>
> It will be interesting to see which Gatherer-based operations will be
> devised by Java developers in the future.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 2 June 2025 18:54
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Should mapConcurrent() respect time order
> instead of input order?
>
>
> Hi Viktor,
>
> Thanks for your reply and for sharing your experience regarding user
> preferences. I appreciate that perspective.
>
> You're right, if an unordered version of mapConcurrent proves to be
> widely beneficial and is implemented and adopted by the community, it could
> certainly make a strong case for future inclusion in the JDK.
>
> I wanted to clarify a nuance regarding user preference that I might not
> have articulated clearly before. If the question is simply "ordered or
> unordered?", in isolation, I can see why many, myself included, might lean
> towards "ordered" as a general preference.
>
> However, the decision becomes more complex when the associated trade-offs
> are considered. If the question were phrased more like, "Do you prefer an
> ordered mapConcurrent by default, even if it entails potential
> performance overhead and limitations for certain use cases like race()
> operations, versus an unordered version that offers higher throughput and
> broader applicability in such scenarios?" my (and perhaps others') answer
> might differ. The perceived cost versus benefit of ordering changes
> significantly when these factors are explicit.
>
> My initial suggestion stemmed from the belief that the performance and
> flexibility gains of an unordered approach for I/O-bound tasks would, in
> many practical situations, outweigh the convenience of default ordering,
> especially since ordering can be reintroduced relatively easily, and
> explicitly, when needed.
>
> Thanks again for the discussion.
>
> Best regards,
>
> On Mon, Jun 2, 2025 at 8:51?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> >My perspective is that strict adherence to input order for
> mapConcurrent() might not be the most common or beneficial default
> behavior for users.
>
> If there is indeed a *majority* who would benefit from an unordered
> version of mapConcurrent (my experience is that the majority prefer
> ordered) then, since it is possible to implement such a Gatherer outside of
> the JDK, this is something which will be constructed, widely used, and
> someone will then propose to add something similar to the JDK.
>
> >While re-implementing the gatherer is a possibility, the existing
> implementation is non-trivial, and creating a custom, robust alternative
> represents a significant undertaking.
>
> The existing version needs to maintain order, which adds to the complexity
> of the implementation. Implementing an unordered version would likely look
> different.
> I'd definitely encourage taking the opportunity to attempt to implement it.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
>
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 2 June 2025 17:05
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Should mapConcurrent() respect time order
> instead of input order?
>
>
> Thank you for your response and for considering my feedback on the
> mapConcurrent() gatherer. I understand and respect that the final
> decision rests with the JDK maintainers.
>
> I would like to offer a couple of further points for consideration. My
> perspective is that strict adherence to input order for mapConcurrent() might
> not be the most common or beneficial default behavior for users. I'd be
> very interested to see any research or data that suggests otherwise, as
> that would certainly inform my understanding.
>
> From my experience, a more common need is for higher throughput in
> I/O-intensive operations. The ability to support use cases like race()?where
> the first successfully completed operation determines the outcome?also
> seems like a valuable capability that is currently infeasible due to the
> ordering constraint.
>
> As I see it, if a developer specifically requires the input order to be
> preserved, this can be achieved with relative ease by applying a subsequent
> sorting operation. For instance:
>
> .gather(mapConcurrent(...))
> .sorted(Comparator.comparing(Result::getInputSequenceId))
>
> The primary challenge in these scenarios is typically the efficient
> fan-out and execution of concurrent tasks, not the subsequent sorting of
> results.
>
> Conversely, as you've noted, there isn't a straightforward way to modify
> the current default ordered behavior to achieve the higher throughput or
> race() semantics that an unordered approach would naturally provide.
>
> While re-implementing the gatherer is a possibility, the existing
> implementation is non-trivial, and creating a custom, robust alternative
> represents a significant undertaking. My hope was that an unordered option
> could be a valuable addition to the standard library, benefiting a wider
> range of developers.
>
> Thank you again for your time and consideration.
>
>
> On Mon, Jun 2, 2025 at 7:48?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> >Even if it by default preserves input order, when I explicitly called
> stream.unordered(), could mapConcurrent() respect that and in return
> achieve higher throughput with support for race?
>
> The Gatherer doesn't know whether the Stream is unordered or ordered. The
> operation should be semantically equivalent anyway.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 2 June 2025 16:29
> *To:* Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <
> core-libs-dev at openjdk.org>
> *Subject:* [External] : Re: Should mapConcurrent() respect time order
> instead of input order?
>
> Sorry. Forgot to copy to the mailing list.
>
> On Mon, Jun 2, 2025 at 7:27?AM Jige Yu <yujige at gmail.com> wrote:
>
> Thanks Viktor!
>
> I was thinking from my own experience that I wouldn't have automatically
> assumed that a concurrent fanout library would by default preserve input
> order.
>
> And I think wanting high throughput with real-life utilities like race
> would be more commonly useful.
>
> But I could be wrong.
>
> Regardless, mapConcurrent() can do both, no?
>
> Even if it by default preserves input order, when I explicitly called
> stream.unordered(), could mapConcurrent() respect that and in return
> achieve higher throughput with support for race?
>
>
>
> On Mon, Jun 2, 2025 at 2:33?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi!
>
> In a similar vein to the built-in Collectors,
> the built-in Gatherers provide solutions to common stream-related
> problems, but also, they also serve as "inspiration" for developers for
> what is possible to implement using Gatherers.
>
> If someone, for performance reasons, and with a use-case which does not
> require encounter-order, want to take advantage of that combination of
> circumstances, it is definitely possible to implement your own Gatherer
> which has that behavior.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Jige
> Yu <yujige at gmail.com>
> *Sent:* Sunday, 1 June 2025 21:08
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Should mapConcurrent() respect time order instead of input
> order?
>
> It seems like for most people, input order isn't that important for
> concurrent work, and concurrent results being in non-deterministic order is
> often expected.
>
> If mapConcurrent() just respect output encounter order:
>
> It'll be able to achieve *higher throughput* if an early task is slow,
> For example, with concurrency=2, and if the first task takes 10 minutes to
> run, mapConcurrent() would only be able to process 2 tasks within the first
> 10 minutes; whereas with encounter order, the first task being slow doesn't
> block the 3rd - 100th elements from being processed and output.
>
> mapConcurrent() can be used to implement useful concurrent semantics, for
> example to *support race* semantics. Imagine if I need to send request to
> 10 candidate backends and take whichever that succeeds first, I'd be able
> to do:
>
> backends.stream()
>     .gather(mapConcurrent(
>         backend -> {
>           try {
>             return backend.fetchOrder();
>            } catch (RpcException e) {
>              return null; // failed to fetch but not fatal
>            }
>         })
>         .filter(Objects::notNull)
>         .findFirst(); // first success then cancel the rest
>
> Cheers,
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250604/6f5dcc38/attachment-0001.htm>

From swen at openjdk.org  Wed Jun  4 14:21:53 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 4 Jun 2025 14:21:53 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal [v2]
In-Reply-To: <rSnQYMg2s_mZ7f9XV9zHdxPGFm-vzI6zUAgyt_hnXGM=.14ccf0d8-5231-47ff-b568-e14fbb9ea485@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
 <lp1xFhlZNmOPvbkAsqk1nWHA_edVtGbkbryGXZGwjTg=.e824710a-4cac-48ea-a65c-3ddabfa27a22@github.com>
 <VxyY6tC-siH_6C0HrNpIIvBJ-tPlmJKEqSW7ioK51m8=.b85fd988-3ac6-416a-a7fd-8cdca298b8af@github.com>
 <_TTbaqxnk9iDRAkGkRp3YFGsuTX87abbtfEP2X3iqlE=.af987502-4705-4273-bbb5-8505d3534fda@github.com>
 <IT1oGbYtZGIme2JaERmFSKcMzjvEItU_lTSCgDutxnc=.fec0e3ae-f74d-41ee-be4f-31c2acb0322b@github.com>
 <rSnQYMg2s_mZ7f9XV9zHdxPGFm-vzI6zUAgyt_hnXGM=.14ccf0d8-5231-47ff-b568-e14fbb9ea485@github.com>
Message-ID: <knsSLPjuGbAcyN9967m8_GTXPoQoseCrfv0V_68RL0U=.8d8fdeec-7158-407a-aa66-9c42fbf1fcd7@github.com>

On Wed, 4 Jun 2025 14:03:49 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Please do _not_ fix the `mag` issue in this PR.
>> I'll take care of it in a future PR.
>
> I just filed [JDK-8358599](https://bugs.openjdk.org/browse/JDK-8358599).

> Please do _not_ fix the `mag` issue in this PR. I'll take care of it in a future PR.

Note that there is a troublesome thing here. There are many places in BigInteger that pass mag to MutableBigInteger

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25437#discussion_r2126729841

From rgiulietti at openjdk.org  Wed Jun  4 14:31:16 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 4 Jun 2025 14:31:16 GMT
Subject: RFR: 8358540: Enhance MathUtils in view of FloatingDecimal
 enhancements
Message-ID: <QCVtBd071dMKhosNAlY09O1LpR6G9W4pnXpxPhwvTPA=.34e14f02-699d-49d7-8fc5-8090080aa106@github.com>

Another step in enhancing floating-point <-> decimal conversions.

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

Commit messages:
 - 8358540: Enhance MathUtils in view of FloatingDecimal enhancements

Changes: https://git.openjdk.org/jdk/pull/25641/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25641&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358540
  Stats: 1781 lines in 8 files changed: 343 ins; 481 del; 957 mod
  Patch: https://git.openjdk.org/jdk/pull/25641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25641/head:pull/25641

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

From rgiulietti at openjdk.org  Wed Jun  4 14:32:53 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 4 Jun 2025 14:32:53 GMT
Subject: RFR: 8358540: Enhance MathUtils in view of FloatingDecimal
 enhancements
In-Reply-To: <QCVtBd071dMKhosNAlY09O1LpR6G9W4pnXpxPhwvTPA=.34e14f02-699d-49d7-8fc5-8090080aa106@github.com>
References: <QCVtBd071dMKhosNAlY09O1LpR6G9W4pnXpxPhwvTPA=.34e14f02-699d-49d7-8fc5-8090080aa106@github.com>
Message-ID: <zyVIa1Uci5cmOlxKP07g4Oky3-eUzuB3stzRJwv1eA4=.92f53e55-08ea-41b3-936d-53c52ef8e8f2@github.com>

On Wed, 4 Jun 2025 14:22:43 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Another step in enhancing floating-point <-> decimal conversions.

Changes include, but are not limited to:
- Accessing `g0()` and `g1()` with the exponent rather than the negated exponent.
- Inverting the order of the `MathUtils.g` table.
- Expanding the `MathUtils.g` table with more entries.
- Expanding the `MathUtils.pow10` table with more entries.
- Enhanced and simplified tests.
- Overall better documentation.

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

PR Comment: https://git.openjdk.org/jdk/pull/25641#issuecomment-2940269391

From alanb at openjdk.org  Wed Jun  4 14:35:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 14:35:00 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
Message-ID: <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>

On Tue, 3 Jun 2025 12:50:49 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix adjust boundary

src/java.base/share/classes/java/net/Socket.java line 970:

> 968:             long end = SocketReadEvent.timestamp();
> 969:             long duration = end - start;
> 970:             if (SocketReadEvent.shouldThrottleCommit(duration, end)) {

The use sites want to ask if an event should be committed. Does the word "Throttle" need to be in name as I don't think the use cases need to care about this.

Also,  just to point out that the shouldXXX method is called with the the end timestamp and duration whereas the offset/emit/commit methods are called with the start timestamp and duration. So two long timestamps and a long measure of time, easy to get it wrong somewhere. Maybe not this PR but I think would be clearer at the use sites to use start or end consistently and reduce potential for mistakes.

src/jdk.jfr/share/classes/jdk/jfr/Throttle.java line 77:

> 75:      * Specifying {@code "off"} (case-sensitive) results in all events being emitted.
> 76:      *
> 77:      * @return the throttle value, default {@code "off"} not {@code null}

I think it would be clear to drop "not null" from the return description.

src/jdk.jfr/share/conf/jfr/default.jfc line 762:

> 760:       <setting name="enabled">true</setting>
> 761:       <setting name="stackTrace">true</setting>
> 762:       <setting name="threshold">20 ms</setting>

I agree FileForce isn't a good candidate to throttle.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126765474
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126722810
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126719134

From viktor.klang at oracle.com  Wed Jun  4 14:38:16 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 4 Jun 2025 14:38:16 +0000
Subject: [External] : Re: Should mapConcurrent() respect time order
 instead of input order?
In-Reply-To: <CAKD1RYu3CUT5nOj9i-cv_n7T=FXvwBpx3BQp6px6Mk2zg6GZNA@mail.gmail.com>
References: <CAKD1RYuoK07OvAn02v4qq74Q1QDfpQpf=t0J0VT-s1zi4iKRnA@mail.gmail.com>
 <MW4PR10MB5774AED3EC215ED5AB3AD52CFF62A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtLy_yC+L5+q1YOkbEvUis5LJ-tJNJDbyoptq8A=+W3eg@mail.gmail.com>
 <CAKD1RYuksGCWsqj6cnu3aoHqkzAepLeNHsGSX_nCi2QryJaGMQ@mail.gmail.com>
 <SJ0PR10MB5766DAA744887EE8B0A2B991FF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYvhpcD=yAGAvTTi+c8sdjDAi776GCPCAdvsCCVF9JQpeQ@mail.gmail.com>
 <SJ0PR10MB5766DB20AB83B1199C7987EAFF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYst6GOErvVozZ2SD6JGhTRUAugSHZFM7aY+5Je72iF3wA@mail.gmail.com>
 <MW4PR10MB57749F82094174F71CF0BB56FF6DA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYu3CUT5nOj9i-cv_n7T=FXvwBpx3BQp6px6Mk2zg6GZNA@mail.gmail.com>
Message-ID: <MW4PR10MB577448E6F3C06E7A0387AFAAFF6CA@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Jige,

First of all?you're most welcome. Thanks for your insightful questions.

>Temptation for Race Semantics: The beauty of mapConcurrent() integrating with the Stream API means developers will naturally be drawn to use it for race-like scenarios. Operations like findFirst() or limit(N) to get the first few completed results are very intuitive combinations.

It's important to distinguish between spatial (encounter) order and temporal (availability) order.

If we look at `Stream::findFirst()` we see:

?Returns an Optional<https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/util/Optional.html> describing the first element of this stream, or an empty Optional if the stream is empty. If the stream has no encounter order, then any element may be returned.? - https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html#findFirst()

And if we look at `Stream::limit(long)` we see:

?While limit() is generally a cheap operation on sequential stream pipelines, it can be quite expensive on ordered parallel pipelines, especially for large values of maxSize, since limit(n) is constrained to return not just any n elements, but the first n elements in the encounter order. ? (emphasis mine) - https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html#limit(long)

So, we can conclude that "first" and "limit" are about encounter order, and we can conclude that the presence of parallel does not change that?only "unorderedness" may change that.

>Surprise for Race Semantics Users: Following from the above, it could be surprising for developers when they realize that the inherent input ordering of mapConcurrent() means it's not optimized for these race scenarios. The expectation would be that findFirst() returns as soon as any task completes, but ordering can delay this if an earlier task (in input order) is slower.

This should be addressed above.

>Ordering Assumption in Concurrency: My experience is that ordering is not typically a default assumption when dealing with operations explicitly marked as "parallel" or "concurrent." For instance, Stream.forEach() on a parallel stream does not guarantee encounter order, presumably for performance reasons ? a similar trade-off to what's being discussed for mapConcurrent(). Developers often consult documentation for ordering guarantees in concurrent contexts rather than assuming them.

This should also be addressed above.

>Expectation of "True" Concurrency: When I see an API like mapConcurrent(maxConcurrency, mapper), my mental model is that if maxConcurrency permits, new tasks should be initiated as soon as a slot is free.

This is interesting, because this is how mapConcurrent used to work. It only placed the limit of concurrent work in progress and not work not yet possible to propagate downstream. This was changed, because a delayed initial (in encounter order) item may let subsequent (completed) work queue up indefinitely.

So in conclusion, there's still room for a different take on "mapConcurrentReorder" (name of course left up to the reader), and the good news is that such a Gatherer can be implemented, evaluated, hardened, etc outside of the JDK?and potentially some day something like it ends up in the JDK.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Jige Yu <yujige at gmail.com>
Sent: Wednesday, 4 June 2025 16:20
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order?


Hi Viktor,

Thank you for sharing that the general feedback on mapConcurrent() has been positive and for the insights into the ongoing enhancements, especially around interruption handling and work-in-progress tracking.

To clarify my own position, I am also extremely enthusiastic about the mapConcurrent() API overall. It offers an elegant and straightforward way to manage homogenous, I/O-intensive concurrent tasks within a structured concurrency model, which is a significant improvement and a much-needed addition. My feedback on ordering is aimed at maximizing its potential.

I'd like to elaborate on a few specific scenarios and expectations that inform my perspective on the ordering:

  1.  Temptation for Race Semantics: The beauty of mapConcurrent() integrating with the Stream API means developers will naturally be drawn to use it for race-like scenarios. Operations like findFirst() or limit(N) to get the first few completed results are very intuitive combinations. For example:

Java

// Hypothetical use case: find the fastest responding service
Optional<Result> fastestResult = serviceUrls.stream()
    .gather(Gatherers.mapConcurrent(MAX_CONCURRENCY, url -> fetch(url)))
    .findFirst();


  2.  Surprise for Race Semantics Users: Following from the above, it could be surprising for developers when they realize that the inherent input ordering of mapConcurrent() means it's not optimized for these race scenarios. The expectation would be that findFirst() returns as soon as any task completes, but ordering can delay this if an earlier task (in input order) is slower.

  3.  Ordering Assumption in Concurrency: My experience is that ordering is not typically a default assumption when dealing with operations explicitly marked as "parallel" or "concurrent." For instance, Stream.forEach() on a parallel stream does not guarantee encounter order, presumably for performance reasons ? a similar trade-off to what's being discussed for mapConcurrent(). Developers often consult documentation for ordering guarantees in concurrent contexts rather than assuming them.

  4.  Expectation of "True" Concurrency: When I see an API like mapConcurrent(maxConcurrency, mapper), my mental model is that if maxConcurrency permits, new tasks should be initiated as soon as a slot is free. For example, with maxConcurrency=2:

     *   Task 1 starts.
     *   Task 2 starts.
     *   If Task 2 finishes while Task 1 is still running, I would expect Task 3 to run concurrently alongside task 1, because the max concurrency is 2, not 1. The current ordered behavior, where Task 3 might have to wait for Task 1 to complete before its result can be processed (even if Task 3 itself could have started and finished), can feel a bit counterintuitive to the notion of maximizing concurrency up to the specified limit. It almost feels like not a "max concurrency", but "max buffer size".

These points are offered to highlight potential areas where the current default could lead to subtle surprises or suboptimal performance for useful concurrent patterns.

Thanks again for the open discussion and for your work on these valuable additions to the JDK.

Best regards,

On Tue, Jun 3, 2025 at 2:13?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
The general feedback received thus far has been primarily positive. There have been a few behavior-related enhancements over the previews to better handle interruption (there's still room to improve there, as per our concurrent conversation) as well as some improvements to work-in-progress tracking.

It will be interesting to see which Gatherer-based operations will be devised by Java developers in the future.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 2 June 2025 18:54
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order?


Hi Viktor,

Thanks for your reply and for sharing your experience regarding user preferences. I appreciate that perspective.

You're right, if an unordered version of mapConcurrent proves to be widely beneficial and is implemented and adopted by the community, it could certainly make a strong case for future inclusion in the JDK.

I wanted to clarify a nuance regarding user preference that I might not have articulated clearly before. If the question is simply "ordered or unordered?", in isolation, I can see why many, myself included, might lean towards "ordered" as a general preference.

However, the decision becomes more complex when the associated trade-offs are considered. If the question were phrased more like, "Do you prefer an ordered mapConcurrent by default, even if it entails potential performance overhead and limitations for certain use cases like race() operations, versus an unordered version that offers higher throughput and broader applicability in such scenarios?" my (and perhaps others') answer might differ. The perceived cost versus benefit of ordering changes significantly when these factors are explicit.

My initial suggestion stemmed from the belief that the performance and flexibility gains of an unordered approach for I/O-bound tasks would, in many practical situations, outweigh the convenience of default ordering, especially since ordering can be reintroduced relatively easily, and explicitly, when needed.

Thanks again for the discussion.

Best regards,

On Mon, Jun 2, 2025 at 8:51?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>My perspective is that strict adherence to input order for mapConcurrent() might not be the most common or beneficial default behavior for users.

If there is indeed a majority who would benefit from an unordered version of mapConcurrent (my experience is that the majority prefer ordered) then, since it is possible to implement such a Gatherer outside of the JDK, this is something which will be constructed, widely used, and someone will then propose to add something similar to the JDK.

>While re-implementing the gatherer is a possibility, the existing implementation is non-trivial, and creating a custom, robust alternative represents a significant undertaking.

The existing version needs to maintain order, which adds to the complexity of the implementation. Implementing an unordered version would likely look different.
I'd definitely encourage taking the opportunity to attempt to implement it.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 2 June 2025 17:05
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order?


Thank you for your response and for considering my feedback on the mapConcurrent() gatherer. I understand and respect that the final decision rests with the JDK maintainers.

I would like to offer a couple of further points for consideration. My perspective is that strict adherence to input order for mapConcurrent() might not be the most common or beneficial default behavior for users. I'd be very interested to see any research or data that suggests otherwise, as that would certainly inform my understanding.

From my experience, a more common need is for higher throughput in I/O-intensive operations. The ability to support use cases like race()?where the first successfully completed operation determines the outcome?also seems like a valuable capability that is currently infeasible due to the ordering constraint.

As I see it, if a developer specifically requires the input order to be preserved, this can be achieved with relative ease by applying a subsequent sorting operation. For instance:

.gather(mapConcurrent(...))
.sorted(Comparator.comparing(Result::getInputSequenceId))


The primary challenge in these scenarios is typically the efficient fan-out and execution of concurrent tasks, not the subsequent sorting of results.

Conversely, as you've noted, there isn't a straightforward way to modify the current default ordered behavior to achieve the higher throughput or race() semantics that an unordered approach would naturally provide.

While re-implementing the gatherer is a possibility, the existing implementation is non-trivial, and creating a custom, robust alternative represents a significant undertaking. My hope was that an unordered option could be a valuable addition to the standard library, benefiting a wider range of developers.

Thank you again for your time and consideration.


On Mon, Jun 2, 2025 at 7:48?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>Even if it by default preserves input order, when I explicitly called stream.unordered(), could mapConcurrent() respect that and in return achieve higher throughput with support for race?

The Gatherer doesn't know whether the Stream is unordered or ordered. The operation should be semantically equivalent anyway.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 2 June 2025 16:29
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>; core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: [External] : Re: Should mapConcurrent() respect time order instead of input order?

Sorry. Forgot to copy to the mailing list.

On Mon, Jun 2, 2025 at 7:27?AM Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>> wrote:
Thanks Viktor!

I was thinking from my own experience that I wouldn't have automatically assumed that a concurrent fanout library would by default preserve input order.

And I think wanting high throughput with real-life utilities like race would be more commonly useful.

But I could be wrong.

Regardless, mapConcurrent() can do both, no?

Even if it by default preserves input order, when I explicitly called stream.unordered(), could mapConcurrent() respect that and in return achieve higher throughput with support for race?



On Mon, Jun 2, 2025 at 2:33?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi!

In a similar vein to the built-in Collectors,
the built-in Gatherers provide solutions to common stream-related problems, but also, they also serve as "inspiration" for developers for what is possible to implement using Gatherers.

If someone, for performance reasons, and with a use-case which does not require encounter-order, want to take advantage of that combination of circumstances, it is definitely possible to implement your own Gatherer which has that behavior.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Sunday, 1 June 2025 21:08
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Should mapConcurrent() respect time order instead of input order?

It seems like for most people, input order isn't that important for concurrent work, and concurrent results being in non-deterministic order is often expected.

If mapConcurrent() just respect output encounter order:

It'll be able to achieve higher throughput if an early task is slow, For example, with concurrency=2, and if the first task takes 10 minutes to run, mapConcurrent() would only be able to process 2 tasks within the first 10 minutes; whereas with encounter order, the first task being slow doesn't block the 3rd - 100th elements from being processed and output.

mapConcurrent() can be used to implement useful concurrent semantics, for example to support race semantics. Imagine if I need to send request to 10 candidate backends and take whichever that succeeds first, I'd be able to do:

backends.stream()
    .gather(mapConcurrent(
        backend -> {
          try {
            return backend.fetchOrder();
           } catch (RpcException e) {
             return null; // failed to fetch but not fatal
           }
        })
        .filter(Objects::notNull)
        .findFirst(); // first success then cancel the rest

Cheers,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250604/72c6dd7b/attachment-0001.htm>

From dfuchs at openjdk.org  Wed Jun  4 15:06:06 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 15:06:06 GMT
Subject: RFR: 8358558: (zipfs) Reorder the listing of "accessMode" property
 in the ZIP file system's documentation [v2]
In-Reply-To: <J1XovT8EqMrzy5UJcJ2t8TbgLkHgk2PqWL-A9iKmL-M=.16a64c83-077b-4aba-9ad6-04b1f673da76@github.com>
References: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
 <J1XovT8EqMrzy5UJcJ2t8TbgLkHgk2PqWL-A9iKmL-M=.16a64c83-077b-4aba-9ad6-04b1f673da76@github.com>
Message-ID: <bkzpZMIIOXY5JDJJPOxh5MfdKfssrnVw4MyRKdMSgG8=.3ae9965d-8017-4f89-8b00-931312928f1a@github.com>

On Wed, 4 Jun 2025 15:03:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this trivial doc-only change to the `jdk.zipfs`'s documentation? This moves the `accessMode` property listing to the top of the table instead of being at the bottom. With this change, the text about throwing `IllegalArgumentException` when `create=true` and `accessMode=readOnly` has been moved to the `create` property's description.
>> 
>> No functional or specification changes are involved. I verified that the generated documentation looks fine too.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's suggestion - consistent use of {@code "readOnly"}

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25634#pullrequestreview-2897112388

From jpai at openjdk.org  Wed Jun  4 15:06:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jun 2025 15:06:07 GMT
Subject: RFR: 8358558: (zipfs) Reorder the listing of "accessMode" property
 in the ZIP file system's documentation
In-Reply-To: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
References: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
Message-ID: <hJFYnD9084regmLO8-TaDCxc_rjzweuOQLukbqDsspk=.5122b95c-fed3-453d-a3a0-b5da68ef83b0@github.com>

On Wed, 4 Jun 2025 06:47:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial doc-only change to the `jdk.zipfs`'s documentation? This moves the `accessMode` property listing to the top of the table instead of being at the bottom. With this change, the text about throwing `IllegalArgumentException` when `create=true` and `accessMode=readOnly` has been moved to the `create` property's description.
> 
> No functional or specification changes are involved. I verified that the generated documentation looks fine too.

Thank you all for the reviews. I'll integrate this in the morning tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/25634#issuecomment-2940386748

From jpai at openjdk.org  Wed Jun  4 15:06:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jun 2025 15:06:08 GMT
Subject: RFR: 8358558: (zipfs) Reorder the listing of "accessMode" property
 in the ZIP file system's documentation [v2]
In-Reply-To: <H0faOWkhqoh6QyZRjVQAAHbXjhIX1au_N-EJhyFR_Ak=.fb18a202-ec04-460a-ba13-aa611571bc9a@github.com>
References: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
 <H0faOWkhqoh6QyZRjVQAAHbXjhIX1au_N-EJhyFR_Ak=.fb18a202-ec04-460a-ba13-aa611571bc9a@github.com>
Message-ID: <rkYbZHUzCo6LkeLO64YqpsO5_YtbjHCcSNbFjZeQNo4=.8750e7ff-ab28-4d3d-a805-107c54a6507a@github.com>

On Wed, 4 Jun 2025 09:35:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Daniel's suggestion - consistent use of {@code "readOnly"}
>
> src/jdk.zipfs/share/classes/module-info.java line 195:
> 
>> 193:  *       If the value is {@code true}, the ZIP file system provider creates a
>> 194:  *       new ZIP or JAR file if it does not exist. Specifying the {@code create}
>> 195:  *       property as {@code true} with the {@code accessMode} as {@code readOnly}
> 
> should we change that to `with <em>read-only</em> {@code accessMode}` or to `with the {@code accessMode} as {@code "readOnly"}`?

I see your reasoning. In the `accessMode` property description, we have used `{@code "readOnly"}`. I will go ahead and change it to `with the {@code accessMode} as {@code "readOnly"}`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25634#discussion_r2126822336

From jpai at openjdk.org  Wed Jun  4 15:06:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jun 2025 15:06:08 GMT
Subject: RFR: 8358558: (zipfs) Reorder the listing of "accessMode" property
 in the ZIP file system's documentation [v2]
In-Reply-To: <rkYbZHUzCo6LkeLO64YqpsO5_YtbjHCcSNbFjZeQNo4=.8750e7ff-ab28-4d3d-a805-107c54a6507a@github.com>
References: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
 <H0faOWkhqoh6QyZRjVQAAHbXjhIX1au_N-EJhyFR_Ak=.fb18a202-ec04-460a-ba13-aa611571bc9a@github.com>
 <rkYbZHUzCo6LkeLO64YqpsO5_YtbjHCcSNbFjZeQNo4=.8750e7ff-ab28-4d3d-a805-107c54a6507a@github.com>
Message-ID: <mEog-Xtj5WOqQRSd2HHmEhYwcI9Vo7G35tlqmFMGUzo=.3dcc1971-1905-46ea-82c7-b095979a6ba9@github.com>

On Wed, 4 Jun 2025 14:56:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/jdk.zipfs/share/classes/module-info.java line 195:
>> 
>>> 193:  *       If the value is {@code true}, the ZIP file system provider creates a
>>> 194:  *       new ZIP or JAR file if it does not exist. Specifying the {@code create}
>>> 195:  *       property as {@code true} with the {@code accessMode} as {@code readOnly}
>> 
>> should we change that to `with <em>read-only</em> {@code accessMode}` or to `with the {@code accessMode} as {@code "readOnly"}`?
>
> I see your reasoning. In the `accessMode` property description, we have used `{@code "readOnly"}`. I will go ahead and change it to `with the {@code accessMode} as {@code "readOnly"}`.

Done, updated the PR with this text.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25634#discussion_r2126827055

From jpai at openjdk.org  Wed Jun  4 15:06:06 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jun 2025 15:06:06 GMT
Subject: RFR: 8358558: (zipfs) Reorder the listing of "accessMode" property
 in the ZIP file system's documentation [v2]
In-Reply-To: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
References: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
Message-ID: <J1XovT8EqMrzy5UJcJ2t8TbgLkHgk2PqWL-A9iKmL-M=.16a64c83-077b-4aba-9ad6-04b1f673da76@github.com>

> Can I please get a review of this trivial doc-only change to the `jdk.zipfs`'s documentation? This moves the `accessMode` property listing to the top of the table instead of being at the bottom. With this change, the text about throwing `IllegalArgumentException` when `create=true` and `accessMode=readOnly` has been moved to the `create` property's description.
> 
> No functional or specification changes are involved. I verified that the generated documentation looks fine too.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Daniel's suggestion - consistent use of {@code "readOnly"}

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25634/files
  - new: https://git.openjdk.org/jdk/pull/25634/files/546afbb7..09d68dd8

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

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

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

From dfuchs at openjdk.org  Wed Jun  4 15:46:36 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 15:46:36 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v6]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <VLxUS3uO-15BM72IayGCOFsuDVbfjLhF00V_1M0ObmI=.b93005af-4d6b-4aa4-a30c-9eb41efdc048@github.com>

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

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

 - merge latest changes from master branch
 - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
 - http3: refactor HTTP/3 connection pool management in a separate class
 - Ignore DestroyFailedExceptions
 - Remove outdated TODO
 - Remove outdated TODO
 - Remove cryptic TODO
 - Remove outdated TODO
 - Fix race in test server's Http3StreamDispatcher
 - Test H3 server: close connection if control stream closed
 - ... and 485 more: https://git.openjdk.org/jdk/compare/7838321b...a41217f0

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=05
  Stats: 103642 lines in 473 files changed: 100781 ins; 1345 del; 1516 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 egahlin at openjdk.org  Wed Jun  4 15:59:03 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Jun 2025 15:59:03 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
Message-ID: <wJSneY7Iw7SjTULCVaLikMyjKH7L9q5sn4ZuAQcx8lA=.15ec6ced-d662-474b-99a1-b7937c7ceb68@github.com>

On Wed, 4 Jun 2025 14:16:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix adjust boundary
>
> src/jdk.jfr/share/classes/jdk/jfr/Throttle.java line 77:
> 
>> 75:      * Specifying {@code "off"} (case-sensitive) results in all events being emitted.
>> 76:      *
>> 77:      * @return the throttle value, default {@code "off"} not {@code null}
> 
> I think it would be clearer to drop "not null" from the return description.

We have "not null" with Threshold, but not with "Period". I filed a bug to make it consistent for all JFR annotations and I can bring Throttle into the same CSR. 

https://bugs.openjdk.org/browse/JDK-8358602

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126946237

From egahlin at openjdk.org  Wed Jun  4 16:06:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Jun 2025 16:06:55 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
Message-ID: <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>

On Wed, 4 Jun 2025 14:32:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix adjust boundary
>
> src/java.base/share/classes/java/net/Socket.java line 970:
> 
>> 968:             long end = SocketReadEvent.timestamp();
>> 969:             long duration = end - start;
>> 970:             if (SocketReadEvent.shouldThrottleCommit(duration, end)) {
> 
> The use sites want to ask if an event should be committed. Does the word "Throttle" need to be in name as I don't think the use cases need to care about this.
> 
> Also,  just to point out that the shouldXXX method is called with the the end timestamp and duration whereas the offset/emit/commit methods are called with the start timestamp and duration. So two long timestamps and a long measure of time, easy to get it wrong somewhere. Maybe not this PR but I think would be clearer at the use sites to use start or end consistently and reduce potential for mistakes.

We need some indication of which events are throttleable and looking at the mirror event may not work in some scenarios.

We need to sample the endTime, because the startTime may be several minutes in the past. We could use commit(startTime, endTime, ...) and calculate the duration inside the method, but it may be confusing because the fields in the event are startTime and duration. We would also need to calculate the duration twice, both for shouldCommit and commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126960704

From dfuchs at openjdk.org  Wed Jun  4 16:08:04 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 16:08:04 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v5]
In-Reply-To: <t01ZejGn4WMUYiK_2xMiWTgI-gtY6BOEsix4cOxKESA=.4ae87c30-da46-4e5c-9094-b676d4c38f4b@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <l0kZnNDdN-TbltTkaEW4yohiocDPHWvIJu34Nl8em8g=.02e58472-5252-414f-bfa6-9c06af35d5b6@github.com>
 <t01ZejGn4WMUYiK_2xMiWTgI-gtY6BOEsix4cOxKESA=.4ae87c30-da46-4e5c-9094-b676d4c38f4b@github.com>
Message-ID: <UngOa-uQ8FF4qZk_AdQcyxqGWy_EsLCwDJDFv7MQqMQ=.a822c514-86df-452a-b63a-2716cc50b238@github.com>

On Fri, 16 May 2025 10:26:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 422 commits:
>> 
>>  - merge latest changes from master branch
>>  - Undo whitespace change
>>  - Remove unnecessary import
>>  - Merge remote-tracking branch 'origin/master' into http3
>>  - Fix test license
>>  - Remove leftover file (test was moved to parent directory)
>>  - Remove unnecessary import
>>  - Update throws clauses
>>  - Merge remote-tracking branch 'origin/master' into http3
>>  - 8354275: Add HTTP/3 tests to `EmptyAuthenticate`
>>  - ... and 412 more: https://git.openjdk.org/jdk/compare/568dcc15...8c27f53c
>
> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 737:
> 
>> 735:         // channel, and a single selector thread, so we can do
>> 736:         // the reading directly in the selector thread and offload
>> 737:         // the parsing (the readLoop) to the executor.
> 
> This comment is outdated. We actually stop reading from the channel when the amount of data buffered exceeds a high watermark threshold.

Updated in latest commits (https://github.com/openjdk/jdk/pull/24751/commits/6ce42f44c52c5b6db54ccceb4f62259cb02992fb)

> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 822:
> 
>> 820:                     if (this.buffered.get() >= MAX_BUFFERED_HIGH) {
>> 821:                         pauseReading();
>> 822:                         readLoopScheduler.runOrSchedule(executor);
> 
> This line should not be needed: we should already have kicked the read loop at line 797.

Updated in latest commits (https://github.com/openjdk/jdk/pull/24751/commits/6ce42f44c52c5b6db54ccceb4f62259cb02992fb)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2126958527
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2126959414

From smarks at openjdk.org  Wed Jun  4 16:16:57 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 4 Jun 2025 16:16:57 GMT
Subject: Integrated: 8358015: Fix SequencedMap sequenced view method
 specifications
In-Reply-To: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
Message-ID: <AQBpwq03Qd8pwU0Ecri-SHIwm_NQ2eBpv4PFg-79wpk=.7af4a43f-b02c-4eaa-bc7b-8aea0e0db191@github.com>

On Thu, 29 May 2025 00:21:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> For a full explanation, see the bug report [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015).
> 
> This PR includes three related changes:
> * New overrides in SequencedMap view collection implementations, which improve their behavior.
> * Update to `@implSpec` clauses to reflect this behavior (which was previously ill-specified).
> * Update to a test which relied on unspecified behavior.

This pull request has now been integrated.

Changeset: ef47635d
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef47635d5a27b003937d865ad9067dbd151db888
Stats:     71 lines in 3 files changed: 59 ins; 0 del; 12 mod

8358015: Fix SequencedMap sequenced view method specifications

Reviewed-by: jpai, bchristi

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

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

From yujige at gmail.com  Wed Jun  4 16:18:02 2025
From: yujige at gmail.com (Jige Yu)
Date: Wed, 4 Jun 2025 09:18:02 -0700
Subject: [External] : Re: Should mapConcurrent() respect time order
 instead of input order?
In-Reply-To: <MW4PR10MB577448E6F3C06E7A0387AFAAFF6CA@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAKD1RYuoK07OvAn02v4qq74Q1QDfpQpf=t0J0VT-s1zi4iKRnA@mail.gmail.com>
 <MW4PR10MB5774AED3EC215ED5AB3AD52CFF62A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtLy_yC+L5+q1YOkbEvUis5LJ-tJNJDbyoptq8A=+W3eg@mail.gmail.com>
 <CAKD1RYuksGCWsqj6cnu3aoHqkzAepLeNHsGSX_nCi2QryJaGMQ@mail.gmail.com>
 <SJ0PR10MB5766DAA744887EE8B0A2B991FF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYvhpcD=yAGAvTTi+c8sdjDAi776GCPCAdvsCCVF9JQpeQ@mail.gmail.com>
 <SJ0PR10MB5766DB20AB83B1199C7987EAFF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYst6GOErvVozZ2SD6JGhTRUAugSHZFM7aY+5Je72iF3wA@mail.gmail.com>
 <MW4PR10MB57749F82094174F71CF0BB56FF6DA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYu3CUT5nOj9i-cv_n7T=FXvwBpx3BQp6px6Mk2zg6GZNA@mail.gmail.com>
 <MW4PR10MB577448E6F3C06E7A0387AFAAFF6CA@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAKD1RYtf4K-r6X0dQZsXUcyZcNa5WLxKZy8p11R163GeLkYn5g@mail.gmail.com>

Hi Viktor,

Thank you for the detailed explanation and the links to the Javadoc for
findFirst() and limit(). You're absolutely correct in your characterization
of these operations ? they are indeed concerned with encounter order, and
parallel execution doesn't inherently change that unless the stream is
explicitly unordered. I want to clarify a few of my points that I didn't
explain clearly (see below).


On Wed, Jun 4, 2025 at 7:38?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> Hi Jige,
>
> First of all?you're most welcome. Thanks for your insightful questions.
>
> >*Temptation for Race Semantics:* The beauty of mapConcurrent() integrating
> with the Stream API means developers will naturally be drawn to use it for
> race-like scenarios. Operations like findFirst() or limit(N) to get the
> first few completed results are very intuitive combinations.
>
> It's important to distinguish between spatial (encounter) order and
> temporal (availability) order.
>
> If we look at `Stream::findFirst()` we see:
>
> ?Returns an Optional
> <https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/util/Optional.html> describing
> the first element of this stream, or an empty Optional if the stream is
> empty. If the stream has no encounter order, then any element may be
> returned.? -
> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html#findFirst()
>
> And if we look at `Stream::limit(long)` we see:
>
> *?While limit() is generally a cheap operation on sequential stream
> pipelines, it can be quite expensive on ordered parallel pipelines,
> especially for large values of maxSize, since limit(n) is constrained to
> return not just any n elements, but **the first n elements in the
> encounter order**. ? (emphasis mine) -
> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html#limit(long)
> <https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html#limit(long)>*
>
> So, we can conclude that "first" and "limit" are about *encounter order*,
> and we can conclude that the presence of parallel does not change that?only
> "unorderedness" *may* change that.
>


My apologies if my previous example using findFirst() wasn't as clear as it
could have been. I'd like to clarify how I see the interaction with
mapConcurrent() playing out:

   1.

   *mapConcurrent()'s Influence on Encounter Order:* When I mentioned using
   findFirst() (or limit()) for race semantics, the implicit assumption was
   how mapConcurrent() would feed elements into these terminal operations.
   The "encounter order" that findFirst() sees is precisely what
   mapConcurrent() emits. If mapConcurrent() emits results strictly
   according to input order, then findFirst() will respect that. However,
   if an unordered mapConcurrent() were to emit results in their temporal
   order of completion, then findFirst() would naturally pick the first one
   that *actually finished*, effectively achieving a race. My point is that
   mapConcurrent() is in a position to define the encounter order that
   downstream operations like findFirst() will act upon. The surprise isn't
   with findFirst()'s definition, but with how a strictly ordered
   mapConcurrent() might prevent it from being used effectively for
   "first-to-finish" logic.
   2.

   *The Role of findAny():* You're right that my example using findFirst()
   was more nuanced than I intuitively assumed. A developer well-versed in the
   Stream API nuances might indeed opt for findAny() to implement race
   semantics, especially given its Javadoc explicitly mentioning suitability
   for "maximal performance in parallel operations." findAny() is designed
   to return *any* element, which aligns well with picking the temporally
   first available result from an unordered concurrent process.
   3.

   *Aligning Spec with Intuition:* My broader concern is about the
   intuitive use of these powerful new tools. If mapConcurrent() maintains
   strict input ordering, it's a perfectly valid and understandable
   specification by itself. However, the potential for surprise arises when
   developers, especially those less acquainted with every fine print of
   stream ordering, attempt to combine mapConcurrent() with findFirst() or
   findAny() to build common concurrent utilities like a race. They might
   intuitively expect that "concurrent mapping" followed by "find first/any"
   would yield the result that completes earliest. While developers *should*
   read all related documentation, there's also a design ideal where the API's
   behavior aligns closely with reasonable developer intuition, especially for
   common patterns. An unordered mapConcurrent() (or an option for it)
   would, in my view, better support this intuitive use for race-like
   patterns. Whereas, I have my doubts that developers commonly would
   intuitively assume a concurrent operation to stick to strict ordering (it's
   not what we are used to in most concurrent or multil-threading scenarios)

Ultimately, the question is whether mapConcurrent() should be optimized
primarily for preserving input sequence, or for enabling maximum throughput
and flexibility in concurrent scenarios, including efficient
"first-to-finish" patterns.


>
> >*Surprise for Race Semantics Users:* Following from the above, it could
> be surprising for developers when they realize that the inherent input
> ordering of mapConcurrent() means it's not optimized for these race
> scenarios. The expectation would be that findFirst() returns as soon as
> *any* task completes, but ordering can delay this if an earlier task (in
> input order) is slower.
>
> This should be addressed above.
>
> >*Ordering Assumption in Concurrency:* My experience is that ordering is
> not typically a default assumption when dealing with operations explicitly
> marked as "parallel" or "concurrent." For instance, Stream.forEach() on a
> parallel stream does not guarantee encounter order, presumably for
> performance reasons ? a similar trade-off to what's being discussed for
> mapConcurrent(). Developers often consult documentation for ordering
> guarantees in concurrent contexts rather than assuming them.
>
> This should also be addressed above.
>
> >*Expectation of "True" Concurrency:* When I see an API like mapConcurrent(maxConcurrency,
> mapper), my mental model is that if maxConcurrency permits, new tasks
> should be initiated as soon as a slot is free.
>
> This is interesting, because this is how mapConcurrent used to work. It
> only placed the limit of *concurrent work in progress* and not *work not
> yet possible to propagate downstream*. This was changed, because a
> delayed initial (in encounter order) item may let subsequent (completed)
> work queue up indefinitely.
>
> So in conclusion, there's still room for a different take on
> "mapConcurrentReorder" (name of course left up to the reader), and the good
> news is that such a Gatherer can be implemented, evaluated, hardened, etc
> outside of the JDK?and potentially some day something like it ends up in
> the JDK.
>

Your mention of a potential mapConcurrentReorder() also brings to mind a
thought about API consistency with existing Stream conventions. We see
patterns like Stream.forEach() (which for parallel streams doesn't
guarantee encounter order, prioritizing performance) versus
Stream.forEachOrdered() (which explicitly enforces it). If mapConcurrent()
were to follow a similar naming convention, it might suggest that the base
mapConcurrent() itself would be the version optimized for throughput (and
thus potentially unordered by default), while a hypothetical
mapConcurrentOrdered() would be the variant explicitly providing the strict
ordering guarantee. This is an observation on how naming might align with
established JDK patterns to intuitively guide user expectations about the
default behavior.

This naturally leads to the inherent challenge in designing such an API. It
seems we're trying to balance three desirable, but sometimes conflicting,
goals:

   1. *Strict Encounter Ordering:* Results are emitted in the same order as
   the input elements.
   2. *Bounded Memory Buffering:* Avoid out-of-memory errors by not letting
   completed but un-emitted results queue up indefinitely.
   3. *Optimized (True) Concurrency:* If maxConcurrency is set (e.g., to N),
   the system strives to have N tasks actively running whenever there are
   pending input elements and available concurrency slots, rather than being
   stalled by a slow-to-complete but earlier-in-sequence task.

It appears that achieving all three simultaneously is not possible, and a
compromise must be made.

>From my perspective:

   - Goal #2 (Bounded Memory) is non-negotiable; OOM situations are
   generally unacceptable.
   - Goal #3 (Optimized Concurrency) feels fundamental to an API named
   mapConcurrent(). Users will likely expect it to maximize the concurrent
   execution of tasks up to the specified limit. Deviations from this, often
   necessitated by strict adherence to Goal #1, can lead to surprises.
   - Goal #1 (Strict Ordering), while a "nice-to-have" and sometimes
   beneficial, might not always align with common developer intuition for
   operations explicitly labeled "concurrent," especially if it compromises
   true concurrency. As discussed, ordering can often be reintroduced by the
   caller if specifically needed.

The current implementation understandably prioritizes #1 (Ordering) and #2
(Bounded Memory). However, this prioritization can lead to situations where
#3 (Optimized Concurrency) is not fully realized, which can be
counter-intuitive.

I've already mentioned the race scenario. Consider another example where
this becomes particularly evident. Imagine a scenario with a long-running
task (e.g., for periodic monitoring) combined with a stream of other "real"
tasks:
Java

// Main tasks
List<Callable<Result>> realTasks = ... ;
// A long-running monitoring task
Callable<Void> longRunningMonitoringTask = () -> {
    while (!allRealTasksSeemDone()) { // Simplified condition
        System.out.println("Monitoring...");
        Thread.sleep(5000);
    }
    return null;
};

Stream<Callable<?>> allTasks = Stream.concat(
    Stream.of(longRunningMonitoringTask),
    realTasks.stream().map(task -> (Callable<?>) task)
);

allTasks
    .gather(Gatherers.mapConcurrent(MAX_CONCURRENCY, callable ->
callable.call()))
    .forEach(result -> { /* output results */ });

The longRunningMonitoringTask would usually be the first element, with the
current strictly ordered behavior, it would occupy one of the
MAX_CONCURRENCY slots. and as soon as MAX_CONCURRENCY tasks are
executed, completed or not, all subsequent realTasks (beyond the first one)
would be starved, unable to even start until the longRunningMonitoringTask
completes?which is *never*. This creates a deadlock or significant
processing delay that would likely surprise a developer expecting tasks to
proceed concurrently up to the maxConcurrency limit. An implementation more
aligned with the "base name implies throughput" idea (as per the forEach
analogy) would likely handle this more gracefully by letting tasks run
truly concurrently without an implicit ordering dependency.

This reinforces my belief that an alternative gatherer, or a default
behavior for mapConcurrent() that prioritizes concurrency (as the name
mapConcurrent might suggest to many, akin to forEach), could be very
valuable. I understand this might be something that evolves outside the JDK
initially, and I appreciate you highlighting that path.

Thanks again for the continued discussion and the transparency about the
design choices.

Best regards,


>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
>
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Wednesday, 4 June 2025 16:20
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Should mapConcurrent() respect time order
> instead of input order?
>
>
> Hi Viktor,
>
> Thank you for sharing that the general feedback on mapConcurrent() has
> been positive and for the insights into the ongoing enhancements,
> especially around interruption handling and work-in-progress tracking.
>
> To clarify my own position, I am also extremely enthusiastic about the
> mapConcurrent() API overall. It offers an elegant and straightforward way
> to manage homogenous, I/O-intensive concurrent tasks within a structured
> concurrency model, which is a significant improvement and a much-needed
> addition. My feedback on ordering is aimed at maximizing its potential.
>
> I'd like to elaborate on a few specific scenarios and expectations that
> inform my perspective on the ordering:
>
>    1.
>
>    *Temptation for Race Semantics:* The beauty of mapConcurrent() integrating
>    with the Stream API means developers will naturally be drawn to use it for
>    race-like scenarios. Operations like findFirst() or limit(N) to get
>    the first few completed results are very intuitive combinations. For
>    example:
>    Java
>
>    // Hypothetical use case: find the fastest responding service
>    Optional<Result> fastestResult = serviceUrls.stream()
>        .gather(Gatherers.mapConcurrent(MAX_CONCURRENCY, url -> fetch(url)))
>        .findFirst();
>
>    2.
>
>    *Surprise for Race Semantics Users:* Following from the above, it
>    could be surprising for developers when they realize that the inherent
>    input ordering of mapConcurrent() means it's not optimized for these
>    race scenarios. The expectation would be that findFirst() returns as
>    soon as *any* task completes, but ordering can delay this if an
>    earlier task (in input order) is slower.
>    3.
>
>    *Ordering Assumption in Concurrency:* My experience is that ordering
>    is not typically a default assumption when dealing with operations
>    explicitly marked as "parallel" or "concurrent." For instance,
>    Stream.forEach() on a parallel stream does not guarantee encounter
>    order, presumably for performance reasons ? a similar trade-off to what's
>    being discussed for mapConcurrent(). Developers often consult
>    documentation for ordering guarantees in concurrent contexts rather than
>    assuming them.
>    4.
>
>    *Expectation of "True" Concurrency:* When I see an API like mapConcurrent(maxConcurrency,
>    mapper), my mental model is that if maxConcurrency permits, new tasks
>    should be initiated as soon as a slot is free. For example, with
>    maxConcurrency=2:
>    - Task 1 starts.
>       - Task 2 starts.
>       - If Task 2 finishes while Task 1 is still running, I would expect
>       Task 3 to run concurrently alongside task 1, because the max concurrency is
>       2, not 1. The current ordered behavior, where Task 3 might have to wait for
>       Task 1 to complete before its result can be processed (even if Task 3
>       itself could have started and finished), can feel a bit counterintuitive to
>       the notion of maximizing concurrency up to the specified limit. It almost
>       feels like not a "max concurrency", but "max buffer size".
>
> These points are offered to highlight potential areas where the current
> default could lead to subtle surprises or suboptimal performance for useful
> concurrent patterns.
>
> Thanks again for the open discussion and for your work on these valuable
> additions to the JDK.
>
> Best regards,
>
> On Tue, Jun 3, 2025 at 2:13?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> The general feedback received thus far has been primarily positive. There
> have been a few behavior-related enhancements over the previews to better
> handle interruption (there's still room to improve there, as per our
> concurrent conversation) as well as some improvements to work-in-progress
> tracking.
>
> It will be interesting to see which Gatherer-based operations will be
> devised by Java developers in the future.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 2 June 2025 18:54
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Should mapConcurrent() respect time order
> instead of input order?
>
>
> Hi Viktor,
>
> Thanks for your reply and for sharing your experience regarding user
> preferences. I appreciate that perspective.
>
> You're right, if an unordered version of mapConcurrent proves to be
> widely beneficial and is implemented and adopted by the community, it could
> certainly make a strong case for future inclusion in the JDK.
>
> I wanted to clarify a nuance regarding user preference that I might not
> have articulated clearly before. If the question is simply "ordered or
> unordered?", in isolation, I can see why many, myself included, might lean
> towards "ordered" as a general preference.
>
> However, the decision becomes more complex when the associated trade-offs
> are considered. If the question were phrased more like, "Do you prefer an
> ordered mapConcurrent by default, even if it entails potential
> performance overhead and limitations for certain use cases like race() operations,
> versus an unordered version that offers higher throughput and broader
> applicability in such scenarios?" my (and perhaps others') answer might
> differ. The perceived cost versus benefit of ordering changes significantly
> when these factors are explicit.
>
> My initial suggestion stemmed from the belief that the performance and
> flexibility gains of an unordered approach for I/O-bound tasks would, in
> many practical situations, outweigh the convenience of default ordering,
> especially since ordering can be reintroduced relatively easily, and
> explicitly, when needed.
>
> Thanks again for the discussion.
>
> Best regards,
>
> On Mon, Jun 2, 2025 at 8:51?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> >My perspective is that strict adherence to input order for
> mapConcurrent() might not be the most common or beneficial default
> behavior for users.
>
> If there is indeed a *majority* who would benefit from an unordered
> version of mapConcurrent (my experience is that the majority prefer
> ordered) then, since it is possible to implement such a Gatherer outside of
> the JDK, this is something which will be constructed, widely used, and
> someone will then propose to add something similar to the JDK.
>
> >While re-implementing the gatherer is a possibility, the existing
> implementation is non-trivial, and creating a custom, robust alternative
> represents a significant undertaking.
>
> The existing version needs to maintain order, which adds to the complexity
> of the implementation. Implementing an unordered version would likely look
> different.
> I'd definitely encourage taking the opportunity to attempt to implement it.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
>
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 2 June 2025 17:05
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Should mapConcurrent() respect time order
> instead of input order?
>
>
> Thank you for your response and for considering my feedback on the
> mapConcurrent() gatherer. I understand and respect that the final
> decision rests with the JDK maintainers.
>
> I would like to offer a couple of further points for consideration. My
> perspective is that strict adherence to input order for mapConcurrent() might
> not be the most common or beneficial default behavior for users. I'd be
> very interested to see any research or data that suggests otherwise, as
> that would certainly inform my understanding.
>
> From my experience, a more common need is for higher throughput in
> I/O-intensive operations. The ability to support use cases like race()?where
> the first successfully completed operation determines the outcome?also
> seems like a valuable capability that is currently infeasible due to the
> ordering constraint.
>
> As I see it, if a developer specifically requires the input order to be
> preserved, this can be achieved with relative ease by applying a subsequent
> sorting operation. For instance:
>
> .gather(mapConcurrent(...))
> .sorted(Comparator.comparing(Result::getInputSequenceId))
>
> The primary challenge in these scenarios is typically the efficient
> fan-out and execution of concurrent tasks, not the subsequent sorting of
> results.
>
> Conversely, as you've noted, there isn't a straightforward way to modify
> the current default ordered behavior to achieve the higher throughput or
> race() semantics that an unordered approach would naturally provide.
>
> While re-implementing the gatherer is a possibility, the existing
> implementation is non-trivial, and creating a custom, robust alternative
> represents a significant undertaking. My hope was that an unordered option
> could be a valuable addition to the standard library, benefiting a wider
> range of developers.
>
> Thank you again for your time and consideration.
>
>
> On Mon, Jun 2, 2025 at 7:48?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> >Even if it by default preserves input order, when I explicitly called
> stream.unordered(), could mapConcurrent() respect that and in return
> achieve higher throughput with support for race?
>
> The Gatherer doesn't know whether the Stream is unordered or ordered. The
> operation should be semantically equivalent anyway.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 2 June 2025 16:29
> *To:* Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <
> core-libs-dev at openjdk.org>
> *Subject:* [External] : Re: Should mapConcurrent() respect time order
> instead of input order?
>
> Sorry. Forgot to copy to the mailing list.
>
> On Mon, Jun 2, 2025 at 7:27?AM Jige Yu <yujige at gmail.com> wrote:
>
> Thanks Viktor!
>
> I was thinking from my own experience that I wouldn't have automatically
> assumed that a concurrent fanout library would by default preserve input
> order.
>
> And I think wanting high throughput with real-life utilities like race
> would be more commonly useful.
>
> But I could be wrong.
>
> Regardless, mapConcurrent() can do both, no?
>
> Even if it by default preserves input order, when I explicitly called
> stream.unordered(), could mapConcurrent() respect that and in return
> achieve higher throughput with support for race?
>
>
>
> On Mon, Jun 2, 2025 at 2:33?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi!
>
> In a similar vein to the built-in Collectors,
> the built-in Gatherers provide solutions to common stream-related
> problems, but also, they also serve as "inspiration" for developers for
> what is possible to implement using Gatherers.
>
> If someone, for performance reasons, and with a use-case which does not
> require encounter-order, want to take advantage of that combination of
> circumstances, it is definitely possible to implement your own Gatherer
> which has that behavior.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Jige
> Yu <yujige at gmail.com>
> *Sent:* Sunday, 1 June 2025 21:08
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Should mapConcurrent() respect time order instead of input
> order?
>
> It seems like for most people, input order isn't that important for
> concurrent work, and concurrent results being in non-deterministic order is
> often expected.
>
> If mapConcurrent() just respect output encounter order:
>
> It'll be able to achieve *higher throughput* if an early task is slow,
> For example, with concurrency=2, and if the first task takes 10 minutes to
> run, mapConcurrent() would only be able to process 2 tasks within the first
> 10 minutes; whereas with encounter order, the first task being slow doesn't
> block the 3rd - 100th elements from being processed and output.
>
> mapConcurrent() can be used to implement useful concurrent semantics, for
> example to *support race* semantics. Imagine if I need to send request to
> 10 candidate backends and take whichever that succeeds first, I'd be able
> to do:
>
> backends.stream()
>     .gather(mapConcurrent(
>         backend -> {
>           try {
>             return backend.fetchOrder();
>            } catch (RpcException e) {
>              return null; // failed to fetch but not fatal
>            }
>         })
>         .filter(Objects::notNull)
>         .findFirst(); // first success then cancel the rest
>
> Cheers,
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250604/688eff56/attachment-0001.htm>

From smarks at openjdk.org  Wed Jun  4 16:21:58 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 4 Jun 2025 16:21:58 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications [v2]
In-Reply-To: <zdF61ZWS4smTOymsOYnXr4_-nsg8JufkcP7Pn6Hl3Rg=.5dde6f8c-4700-430f-840b-23b3319c1e86@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
 <8gPP7kpzcCSz8A4o0eCUrDhJRqC_atLNvhu87K3wF_Y=.2a49957a-f2bb-40a5-a091-97d634e06457@github.com>
 <Dn80nyjlzAyyRdJh3xSv2xdqzZUFBl_jYnATxNirfkc=.e761b3d7-cfda-4459-8f05-1b36e127639f@github.com>
 <9vq8tA47eS-P2oW0rUMhk1YkcTWYq3_7kEibzlRgIXM=.fbb4480b-b2ad-47c5-8b60-6c3728ae4fad@github.com>
 <zdF61ZWS4smTOymsOYnXr4_-nsg8JufkcP7Pn6Hl3Rg=.5dde6f8c-4700-430f-840b-23b3319c1e86@github.com>
Message-ID: <lxqTwJxWxJuzvoPoHCyxv-DfMR1VHFVzSJ7h5iVrjsw=.c6260f02-d8ee-4ed5-b715-e36b3146fcbc@github.com>

On Wed, 4 Jun 2025 04:08:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The `@Override` annotation has been inconsistently applied in the collections implementations. In practice since so many methods are overridden, and some test would likely fail if a method weren't overridden properly, the annotation would mostly add clutter. Indeed I'm considering pulling out all uses of `@Override` in certain areas because they're just clutter.
>
> It would be helpful in situations like this to have the inverse annotation -- "All methods should be overridden, except the ones marked `@NoOverride`".

Interesting. This `@NoOverride` idea could be useful on a subclass that wants to make sure it overrides everything. (Maybe `@NoInherit` would be a better name.) Meanwhile for JDK-8357272 (PR https://github.com/openjdk/jdk/pull/25478) we're implementing similar policy checking in a test, though the exact policy is "no inheritance of default methods."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25515#discussion_r2126988299

From mdoerr at openjdk.org  Wed Jun  4 16:25:00 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 4 Jun 2025 16:25:00 GMT
Subject: RFR: 8357823: Changes in StringBuilder (JDK-8351443) caused a 1-3%
 regression in biojava
In-Reply-To: <EqrJvAzbQYoe6SnQhsy9_KmtAhqJI4jGMaHOztKb0n8=.99ee9a06-04d4-499b-976c-74da3314f4b5@github.com>
References: <EqrJvAzbQYoe6SnQhsy9_KmtAhqJI4jGMaHOztKb0n8=.99ee9a06-04d4-499b-976c-74da3314f4b5@github.com>
Message-ID: <t2P66XlPmW7IJUAELU2cwJKp4ZdZubNuB7m79NmgmAA=.98d4e566-5508-451c-87fa-9eca0f920b0f@github.com>

On Fri, 30 May 2025 14:01:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Comment out assertions added in JDK-8351443 from AbstractStringBuilder.ensureCapacityNewCoder that increase the codesize, preventing some inlining, and reducing performance
> 
>        assert coder == newCoder || newCoder == UTF16 : "bad new coder UTF16 -> LATIN1";
>        assert count <= newCapacity : "count exceeds new capacity";

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25550#pullrequestreview-2897377032

From lancea at openjdk.org  Wed Jun  4 16:30:52 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 4 Jun 2025 16:30:52 GMT
Subject: RFR: 8349914: ZipFile::entries and ZipFile::getInputStream not
 consistent with each other when there are duplicate entries
In-Reply-To: <iwdjrcKGI2cp3q-DG7LcJKvUkVmPRVSCTeEpjtmW8TU=.d14e454a-2c9a-4b6f-8ebd-32f885e61398@github.com>
References: <iwdjrcKGI2cp3q-DG7LcJKvUkVmPRVSCTeEpjtmW8TU=.d14e454a-2c9a-4b6f-8ebd-32f885e61398@github.com>
Message-ID: <2Ycb4IckyeDZ5jVI47uvA97UIE7t04RtL89SVDSAR7w=.c8753b30-eea6-43dd-a0d4-00fdf0201b77@github.com>

On Wed, 4 Jun 2025 09:53:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8349914?
> 
> The ZIP specification allows for more than one entry to have the same file name (and may have different file data). In such situation, as noted in the linked issue, the `ZipFile.getInputStream(ZipEntry)` may end up picking up an "incorrect" entry content (and metadata) for the passed entry.
> 
> The commit in this PR addresses that issue by holding on to the LOC offset of the entry in the `ZipEntry` class. This way, whenever that `ZipEntry` instance is used, it knows which exact entry it represents.
> 
> A new jtreg test has been introduced to reproduce the issue and verify the fix. The new test and existing tests in tier1, tier2 and tier3 pass with this change.

Hi Jai,

Thank you for addressing this issue.  The changes look good

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25635#pullrequestreview-2897391926

From jlu at openjdk.org  Wed Jun  4 16:42:55 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 4 Jun 2025 16:42:55 GMT
Subject: Integrated: 8358449: Locale.getISOCountries does not specify the
 returned set is unmodifiable
In-Reply-To: <9Si_Ruzf7n7eVEpEyk1nDssH9q9661mOzNES7OCyELI=.515bdbe0-17fd-4c54-b0e8-4564119274e4@github.com>
References: <9Si_Ruzf7n7eVEpEyk1nDssH9q9661mOzNES7OCyELI=.515bdbe0-17fd-4c54-b0e8-4564119274e4@github.com>
Message-ID: <hp1OPc7rGcjB5eaHX30xlkxZEP7wT01FRZTZBsq_VAw=.a8ddab4f-db13-4125-867a-7d33549271b5@github.com>

On Tue, 3 Jun 2025 17:13:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this trivial doc correction to `Locale.getISOCountries(Locale.IsoCountryCode type)` which makes it apparent that the returned Set is unmodifiable. Associated CSR filed.

This pull request has now been integrated.

Changeset: 8a79ac88
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a79ac88639c35a6938f82a391c4b5d77e6eda32
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8358449: Locale.getISOCountries does not specify the returned set is unmodifiable

Reviewed-by: naoto

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

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

From duke at openjdk.org  Wed Jun  4 16:52:57 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Wed, 4 Jun 2025 16:52:57 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications [v2]
In-Reply-To: <lxqTwJxWxJuzvoPoHCyxv-DfMR1VHFVzSJ7h5iVrjsw=.c6260f02-d8ee-4ed5-b715-e36b3146fcbc@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
 <8gPP7kpzcCSz8A4o0eCUrDhJRqC_atLNvhu87K3wF_Y=.2a49957a-f2bb-40a5-a091-97d634e06457@github.com>
 <Dn80nyjlzAyyRdJh3xSv2xdqzZUFBl_jYnATxNirfkc=.e761b3d7-cfda-4459-8f05-1b36e127639f@github.com>
 <9vq8tA47eS-P2oW0rUMhk1YkcTWYq3_7kEibzlRgIXM=.fbb4480b-b2ad-47c5-8b60-6c3728ae4fad@github.com>
 <zdF61ZWS4smTOymsOYnXr4_-nsg8JufkcP7Pn6Hl3Rg=.5dde6f8c-4700-430f-840b-23b3319c1e86@github.com>
 <lxqTwJxWxJuzvoPoHCyxv-DfMR1VHFVzSJ7h5iVrjsw=.c6260f02-d8ee-4ed5-b715-e36b3146fcbc@github.com>
Message-ID: <TfgVx46NtJvr8PKc0-EfhpWtX8VjkYjM9544vuJduEU=.4258687a-8b6c-446f-ae71-2df9f990f7b7@github.com>

On Wed, 4 Jun 2025 16:19:23 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> It would be helpful in situations like this to have the inverse annotation -- "All methods should be overridden, except the ones marked `@NoOverride`".
>
> Interesting. This `@NoOverride` idea could be useful on a subclass that wants to make sure it overrides everything. (Maybe `@NoInherit` would be a better name.) Meanwhile for JDK-8357272 (PR https://github.com/openjdk/jdk/pull/25478) we're implementing similar policy checking in a test, though the exact policy is "no inheritance of default methods."

> The `@Override` annotation has been inconsistently applied in the collections implementations. In practice since so many methods are overridden, and some test would likely fail if a method weren't overridden properly, the annotation would mostly add clutter. Indeed I'm considering pulling out all uses of `@Override` in certain areas because they're just clutter.

The @Override annotation was one of Java's best innovations to detect consequences of changes in a base class for derived classes at compile time and it also carries information to any developer looking at a method, so calling it clutter (in Collection implementations) seems like a bit of exaggeration to me. Some IDEs have a feature to automatically add @Override annotations on save, and I think the JDK would improve if missing @Override annotations would be added to the whole code base.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25515#discussion_r2127039998

From pminborg at openjdk.org  Wed Jun  4 17:39:44 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 4 Jun 2025 17:39:44 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v7]
In-Reply-To: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
Message-ID: <f12M_ydACA34yptZNolA24Rj0xXIlngWVFTSKyYxv_0=.560226d3-9e03-435e-bcf8-169aa8f41571@github.com>

> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
> 
> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
> 
> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
> 
> This PR passes tier1, tier2, and tier3 on multiple platforms.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - Fix benchmark
 - Merge branch 'master' into fill-overlap
 - Merge branch 'master' into fill-overlap
 - Update test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update benchmark to reflect new fill method
 - Simplify
 - Add case for long operations and break out methods
 - Correct typo in comment
 - Simplify the fill method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25383/files
  - new: https://git.openjdk.org/jdk/pull/25383/files/d0cd7bbb..e9e8d15e

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

  Stats: 63091 lines in 997 files changed: 37316 ins; 15895 del; 9880 mod
  Patch: https://git.openjdk.org/jdk/pull/25383.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25383/head:pull/25383

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

From liach at openjdk.org  Wed Jun  4 17:43:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Jun 2025 17:43:03 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v8]
In-Reply-To: <f38TCAjHwOS64Y5LhxNVogPv8KaK2hxmMgrS_reN8DQ=.0b93f71f-7fa2-4c1f-b2b5-1cb82d130952@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <f38TCAjHwOS64Y5LhxNVogPv8KaK2hxmMgrS_reN8DQ=.0b93f71f-7fa2-4c1f-b2b5-1cb82d130952@github.com>
Message-ID: <kMVnziEf9Mt5-zD1FLOauM3VcloHUVj5mkueqtCgHEQ=.01578f3b-1bde-41a4-81e5-bd7e20ebd154@github.com>

On Wed, 4 Jun 2025 07:12:42 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change which adds a native method providing the
>> implementation of Reference::get.  Referece::get is an intrinsic candidate, so
>> this native method implementation is only used when the intrinsic is not.
>> 
>> Currently there is intrinsic support by the interpreter, C1, C2, and graal,
>> which are always used.  With this change we can later remove all the
>> per-platform interpreter intrinsic implementations, and might also remove the
>> C1 intrinsic implementation.
>> 
>> Testing:
>> (1) mach5 tier1-6 normal (so using all the existing intrinsics).
>> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into native-reference-get
>  - make private native Reference.get0 the intrinsic
>  - Merge branch 'master' into native-reference-get
>  - Merge branch 'master' into native-reference-get
>  - use new waitForRefProc, some tidying
>  - Merge branch 'master' into native-reference-get
>  - remove timeout by using waitForReferenceProcessing
>  - make ill-timed gc in non-concurrent case less likely
>  - fix test package use
>  - add package decl to test
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/8d780d2e...98056a8b

src/hotspot/share/classfile/vmSymbols.hpp line 425:

> 423:   template(pc_name,                                   "pc")                                       \
> 424:   template(cs_name,                                   "cs")                                       \
> 425:   template(get_name,                                  "get")                                      \

A bit surprised that this is not used elsewhere - but as long as this passes compilation I guess this is fine.

src/hotspot/share/interpreter/abstractInterpreter.hpp line 86:

> 84:     java_lang_math_fmaF,                                        // implementation of java.lang.Math.fma   (x, y, z)
> 85:     java_lang_math_fmaD,                                        // implementation of java.lang.Math.fma   (x, y, z)
> 86:     java_lang_ref_reference_get0,                                // implementation of java.lang.ref.Reference.get()

Suggestion:

    java_lang_ref_reference_get0,                               // implementation of java.lang.ref.Reference.get()

src/hotspot/share/opto/compile.cpp line 786:

> 784:       initial_gvn()->set_type_bottom(s);
> 785:       verify_start(s);
> 786:       if (method()->intrinsic_id() == vmIntrinsics::_Reference_get) {

Should we remove this now or as part of the redundant intrinsic cleanup for interpreter and c1? I see the interpreter is now kept intact.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2127108041
PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2127114784
PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2127117794

From dfuchs at openjdk.org  Wed Jun  4 17:54:25 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 17:54:25 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v6]
In-Reply-To: <VLxUS3uO-15BM72IayGCOFsuDVbfjLhF00V_1M0ObmI=.b93005af-4d6b-4aa4-a30c-9eb41efdc048@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <VLxUS3uO-15BM72IayGCOFsuDVbfjLhF00V_1M0ObmI=.b93005af-4d6b-4aa4-a30c-9eb41efdc048@github.com>
Message-ID: <ilp-dq4Sz3lLQs-v9R-04shh7tKsaQLPBts7z5VO0zQ=.9c6aa5c9-357f-43c2-9481-e54e01f48ce4@github.com>

On Wed, 4 Jun 2025 15:46:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 495 commits:
> 
>  - merge latest changes from master branch
>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>  - http3: refactor HTTP/3 connection pool management in a separate class
>  - Ignore DestroyFailedExceptions
>  - Remove outdated TODO
>  - Remove outdated TODO
>  - Remove cryptic TODO
>  - Remove outdated TODO
>  - Fix race in test server's Http3StreamDispatcher
>  - Test H3 server: close connection if control stream closed
>  - ... and 485 more: https://git.openjdk.org/jdk/compare/7838321b...a41217f0

src/java.net.http/share/classes/jdk/internal/net/http/hpack/HPACK.java line 176:

> 174: 
> 175:     @FunctionalInterface
> 176:     interface BufferUpdateConsumer {

@AlekseiEfimov It looks like this change is no longer required and could be reverted

src/java.net.http/share/classes/jdk/internal/net/http/hpack/ISO_8859_1.java line 43:

> 41: // The encoding is simple and well known: 1 byte <-> 1 char
> 42: //
> 43: final class ISO_8859_1 {

OK - this class is actually used in QPack as well as HPack. Same for the `QuickHuffman` class below (notice that this is Quick - not Quic ;-) )

It might be interesting to investigate if we could pull out these classes to a common location to break the tie between QPack and HPack. Something to think about after integration maybe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2126966393
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2127123043

From vlivanov at openjdk.org  Wed Jun  4 18:08:57 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 4 Jun 2025 18:08:57 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v8]
In-Reply-To: <f38TCAjHwOS64Y5LhxNVogPv8KaK2hxmMgrS_reN8DQ=.0b93f71f-7fa2-4c1f-b2b5-1cb82d130952@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <f38TCAjHwOS64Y5LhxNVogPv8KaK2hxmMgrS_reN8DQ=.0b93f71f-7fa2-4c1f-b2b5-1cb82d130952@github.com>
Message-ID: <3W47upHu1No4yeE-HHeJobnmONh-za_namTyrrIWWao=.32752508-95c8-4c1e-b261-3e435cdad79f@github.com>

On Wed, 4 Jun 2025 07:12:42 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change which adds a native method providing the
>> implementation of Reference::get.  Referece::get is an intrinsic candidate, so
>> this native method implementation is only used when the intrinsic is not.
>> 
>> Currently there is intrinsic support by the interpreter, C1, C2, and graal,
>> which are always used.  With this change we can later remove all the
>> per-platform interpreter intrinsic implementations, and might also remove the
>> C1 intrinsic implementation.
>> 
>> Testing:
>> (1) mach5 tier1-6 normal (so using all the existing intrinsics).
>> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into native-reference-get
>  - make private native Reference.get0 the intrinsic
>  - Merge branch 'master' into native-reference-get
>  - Merge branch 'master' into native-reference-get
>  - use new waitForRefProc, some tidying
>  - Merge branch 'master' into native-reference-get
>  - remove timeout by using waitForReferenceProcessing
>  - make ill-timed gc in non-concurrent case less likely
>  - fix test package use
>  - add package decl to test
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/3c35a7ee...98056a8b

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

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

From viktor.klang at oracle.com  Wed Jun  4 18:22:31 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 4 Jun 2025 18:22:31 +0000
Subject: [External] : Re: Should mapConcurrent() respect time order
 instead of input order?
In-Reply-To: <CAKD1RYtf4K-r6X0dQZsXUcyZcNa5WLxKZy8p11R163GeLkYn5g@mail.gmail.com>
References: <CAKD1RYuoK07OvAn02v4qq74Q1QDfpQpf=t0J0VT-s1zi4iKRnA@mail.gmail.com>
 <MW4PR10MB5774AED3EC215ED5AB3AD52CFF62A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtLy_yC+L5+q1YOkbEvUis5LJ-tJNJDbyoptq8A=+W3eg@mail.gmail.com>
 <CAKD1RYuksGCWsqj6cnu3aoHqkzAepLeNHsGSX_nCi2QryJaGMQ@mail.gmail.com>
 <SJ0PR10MB5766DAA744887EE8B0A2B991FF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYvhpcD=yAGAvTTi+c8sdjDAi776GCPCAdvsCCVF9JQpeQ@mail.gmail.com>
 <SJ0PR10MB5766DB20AB83B1199C7987EAFF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYst6GOErvVozZ2SD6JGhTRUAugSHZFM7aY+5Je72iF3wA@mail.gmail.com>
 <MW4PR10MB57749F82094174F71CF0BB56FF6DA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYu3CUT5nOj9i-cv_n7T=FXvwBpx3BQp6px6Mk2zg6GZNA@mail.gmail.com>
 <MW4PR10MB577448E6F3C06E7A0387AFAAFF6CA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtf4K-r6X0dQZsXUcyZcNa5WLxKZy8p11R163GeLkYn5g@mail.gmail.com>
Message-ID: <MW4PR10MB57749105268519A8984C7C3EFF6CA@MW4PR10MB5774.namprd10.prod.outlook.com>

>Ultimately, the question is whether mapConcurrent() should be optimized primarily for preserving input sequence, or for enabling maximum throughput and flexibility in concurrent scenarios, including efficient "first-to-finish" patterns.

The answer to that is clear in the specification for the operation:

?This operation preserves the ordering of the stream.? - http://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com>
Sent: Wednesday, 4 June 2025 18:18
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order?

Hi Viktor,

Thank you for the detailed explanation and the links to the Javadoc for findFirst() and limit(). You're absolutely correct in your characterization of these operations ? they are indeed concerned with encounter order, and parallel execution doesn't inherently change that unless the stream is explicitly unordered. I want to clarify a few of my points that I didn't explain clearly (see below).


On Wed, Jun 4, 2025 at 7:38?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi Jige,

First of all?you're most welcome. Thanks for your insightful questions.

>Temptation for Race Semantics: The beauty of mapConcurrent() integrating with the Stream API means developers will naturally be drawn to use it for race-like scenarios. Operations like findFirst() or limit(N) to get the first few completed results are very intuitive combinations.

It's important to distinguish between spatial (encounter) order and temporal (availability) order.

If we look at `Stream::findFirst()` we see:

?Returns an Optional<https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/util/Optional.html> describing the first element of this stream, or an empty Optional if the stream is empty. If the stream has no encounter order, then any element may be returned.? - https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html#findFirst()

And if we look at `Stream::limit(long)` we see:

?While limit() is generally a cheap operation on sequential stream pipelines, it can be quite expensive on ordered parallel pipelines, especially for large values of maxSize, since limit(n) is constrained to return not just any n elements, but the first n elements in the encounter order. ? (emphasis mine) - https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html#limit(long)

So, we can conclude that "first" and "limit" are about encounter order, and we can conclude that the presence of parallel does not change that?only "unorderedness" may change that.



My apologies if my previous example using findFirst() wasn't as clear as it could have been. I'd like to clarify how I see the interaction with mapConcurrent() playing out:

  1.  mapConcurrent()'s Influence on Encounter Order: When I mentioned using findFirst() (or limit()) for race semantics, the implicit assumption was how mapConcurrent() would feed elements into these terminal operations. The "encounter order" that findFirst() sees is precisely what mapConcurrent() emits. If mapConcurrent() emits results strictly according to input order, then findFirst() will respect that. However, if an unordered mapConcurrent() were to emit results in their temporal order of completion, then findFirst() would naturally pick the first one that actually finished, effectively achieving a race. My point is that mapConcurrent() is in a position to define the encounter order that downstream operations like findFirst() will act upon. The surprise isn't with findFirst()'s definition, but with how a strictly ordered mapConcurrent() might prevent it from being used effectively for "first-to-finish" logic.

  2.  The Role of findAny(): You're right that my example using findFirst() was more nuanced than I intuitively assumed. A developer well-versed in the Stream API nuances might indeed opt for findAny() to implement race semantics, especially given its Javadoc explicitly mentioning suitability for "maximal performance in parallel operations." findAny() is designed to return any element, which aligns well with picking the temporally first available result from an unordered concurrent process.

  3.  Aligning Spec with Intuition: My broader concern is about the intuitive use of these powerful new tools. If mapConcurrent() maintains strict input ordering, it's a perfectly valid and understandable specification by itself. However, the potential for surprise arises when developers, especially those less acquainted with every fine print of stream ordering, attempt to combine mapConcurrent() with findFirst() or findAny() to build common concurrent utilities like a race. They might intuitively expect that "concurrent mapping" followed by "find first/any" would yield the result that completes earliest. While developers should read all related documentation, there's also a design ideal where the API's behavior aligns closely with reasonable developer intuition, especially for common patterns. An unordered mapConcurrent() (or an option for it) would, in my view, better support this intuitive use for race-like patterns. Whereas, I have my doubts that developers commonly would intuitively assume a concurrent operation to stick to strict ordering (it's not what we are used to in most concurrent or multil-threading scenarios)

Ultimately, the question is whether mapConcurrent() should be optimized primarily for preserving input sequence, or for enabling maximum throughput and flexibility in concurrent scenarios, including efficient "first-to-finish" patterns.



>Surprise for Race Semantics Users: Following from the above, it could be surprising for developers when they realize that the inherent input ordering of mapConcurrent() means it's not optimized for these race scenarios. The expectation would be that findFirst() returns as soon as any task completes, but ordering can delay this if an earlier task (in input order) is slower.

This should be addressed above.

>Ordering Assumption in Concurrency: My experience is that ordering is not typically a default assumption when dealing with operations explicitly marked as "parallel" or "concurrent." For instance, Stream.forEach() on a parallel stream does not guarantee encounter order, presumably for performance reasons ? a similar trade-off to what's being discussed for mapConcurrent(). Developers often consult documentation for ordering guarantees in concurrent contexts rather than assuming them.

This should also be addressed above.

>Expectation of "True" Concurrency: When I see an API like mapConcurrent(maxConcurrency, mapper), my mental model is that if maxConcurrency permits, new tasks should be initiated as soon as a slot is free.

This is interesting, because this is how mapConcurrent used to work. It only placed the limit of concurrent work in progress and not work not yet possible to propagate downstream. This was changed, because a delayed initial (in encounter order) item may let subsequent (completed) work queue up indefinitely.

So in conclusion, there's still room for a different take on "mapConcurrentReorder" (name of course left up to the reader), and the good news is that such a Gatherer can be implemented, evaluated, hardened, etc outside of the JDK?and potentially some day something like it ends up in the JDK.


Your mention of a potential mapConcurrentReorder() also brings to mind a thought about API consistency with existing Stream conventions. We see patterns like Stream.forEach() (which for parallel streams doesn't guarantee encounter order, prioritizing performance) versus Stream.forEachOrdered() (which explicitly enforces it). If mapConcurrent() were to follow a similar naming convention, it might suggest that the base mapConcurrent() itself would be the version optimized for throughput (and thus potentially unordered by default), while a hypothetical mapConcurrentOrdered() would be the variant explicitly providing the strict ordering guarantee. This is an observation on how naming might align with established JDK patterns to intuitively guide user expectations about the default behavior.

This naturally leads to the inherent challenge in designing such an API. It seems we're trying to balance three desirable, but sometimes conflicting, goals:

  1.  Strict Encounter Ordering: Results are emitted in the same order as the input elements.
  2.  Bounded Memory Buffering: Avoid out-of-memory errors by not letting completed but un-emitted results queue up indefinitely.
  3.  Optimized (True) Concurrency: If maxConcurrency is set (e.g., to N), the system strives to have N tasks actively running whenever there are pending input elements and available concurrency slots, rather than being stalled by a slow-to-complete but earlier-in-sequence task.

It appears that achieving all three simultaneously is not possible, and a compromise must be made.

From my perspective:

  *   Goal #2 (Bounded Memory) is non-negotiable; OOM situations are generally unacceptable.
  *   Goal #3 (Optimized Concurrency) feels fundamental to an API named mapConcurrent(). Users will likely expect it to maximize the concurrent execution of tasks up to the specified limit. Deviations from this, often necessitated by strict adherence to Goal #1, can lead to surprises.
  *   Goal #1 (Strict Ordering), while a "nice-to-have" and sometimes beneficial, might not always align with common developer intuition for operations explicitly labeled "concurrent," especially if it compromises true concurrency. As discussed, ordering can often be reintroduced by the caller if specifically needed.

The current implementation understandably prioritizes #1 (Ordering) and #2 (Bounded Memory). However, this prioritization can lead to situations where #3 (Optimized Concurrency) is not fully realized, which can be counter-intuitive.

I've already mentioned the race scenario. Consider another example where this becomes particularly evident. Imagine a scenario with a long-running task (e.g., for periodic monitoring) combined with a stream of other "real" tasks:

Java

// Main tasks
List<Callable<Result>> realTasks = ... ;

// A long-running monitoring task
Callable<Void> longRunningMonitoringTask = () -> {
    while (!allRealTasksSeemDone()) { // Simplified condition
        System.out.println("Monitoring...");
        Thread.sleep(5000);
    }
    return null;
};

Stream<Callable<?>> allTasks = Stream.concat(
    Stream.of(longRunningMonitoringTask),
    realTasks.stream().map(task -> (Callable<?>) task)
);

allTasks
    .gather(Gatherers.mapConcurrent(MAX_CONCURRENCY, callable -> callable.call()))
    .forEach(result -> { /* output results */ });


The longRunningMonitoringTask would usually be the first element, with the current strictly ordered behavior, it would occupy one of the MAX_CONCURRENCY slots. and as soon as MAX_CONCURRENCY tasks are executed, completed or not, all subsequent realTasks (beyond the first one) would be starved, unable to even start until the longRunningMonitoringTask completes?which is never. This creates a deadlock or significant processing delay that would likely surprise a developer expecting tasks to proceed concurrently up to the maxConcurrency limit. An implementation more aligned with the "base name implies throughput" idea (as per the forEach analogy) would likely handle this more gracefully by letting tasks run truly concurrently without an implicit ordering dependency.

This reinforces my belief that an alternative gatherer, or a default behavior for mapConcurrent() that prioritizes concurrency (as the name mapConcurrent might suggest to many, akin to forEach), could be very valuable. I understand this might be something that evolves outside the JDK initially, and I appreciate you highlighting that path.

Thanks again for the continued discussion and the transparency about the design choices.

Best regards,



Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Wednesday, 4 June 2025 16:20
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order?


Hi Viktor,

Thank you for sharing that the general feedback on mapConcurrent() has been positive and for the insights into the ongoing enhancements, especially around interruption handling and work-in-progress tracking.

To clarify my own position, I am also extremely enthusiastic about the mapConcurrent() API overall. It offers an elegant and straightforward way to manage homogenous, I/O-intensive concurrent tasks within a structured concurrency model, which is a significant improvement and a much-needed addition. My feedback on ordering is aimed at maximizing its potential.

I'd like to elaborate on a few specific scenarios and expectations that inform my perspective on the ordering:

  1.  Temptation for Race Semantics: The beauty of mapConcurrent() integrating with the Stream API means developers will naturally be drawn to use it for race-like scenarios. Operations like findFirst() or limit(N) to get the first few completed results are very intuitive combinations. For example:

Java

// Hypothetical use case: find the fastest responding service
Optional<Result> fastestResult = serviceUrls.stream()
    .gather(Gatherers.mapConcurrent(MAX_CONCURRENCY, url -> fetch(url)))
    .findFirst();


  2.  Surprise for Race Semantics Users: Following from the above, it could be surprising for developers when they realize that the inherent input ordering of mapConcurrent() means it's not optimized for these race scenarios. The expectation would be that findFirst() returns as soon as any task completes, but ordering can delay this if an earlier task (in input order) is slower.

  3.  Ordering Assumption in Concurrency: My experience is that ordering is not typically a default assumption when dealing with operations explicitly marked as "parallel" or "concurrent." For instance, Stream.forEach() on a parallel stream does not guarantee encounter order, presumably for performance reasons ? a similar trade-off to what's being discussed for mapConcurrent(). Developers often consult documentation for ordering guarantees in concurrent contexts rather than assuming them.

  4.  Expectation of "True" Concurrency: When I see an API like mapConcurrent(maxConcurrency, mapper), my mental model is that if maxConcurrency permits, new tasks should be initiated as soon as a slot is free. For example, with maxConcurrency=2:

     *   Task 1 starts.
     *   Task 2 starts.
     *   If Task 2 finishes while Task 1 is still running, I would expect Task 3 to run concurrently alongside task 1, because the max concurrency is 2, not 1. The current ordered behavior, where Task 3 might have to wait for Task 1 to complete before its result can be processed (even if Task 3 itself could have started and finished), can feel a bit counterintuitive to the notion of maximizing concurrency up to the specified limit. It almost feels like not a "max concurrency", but "max buffer size".

These points are offered to highlight potential areas where the current default could lead to subtle surprises or suboptimal performance for useful concurrent patterns.

Thanks again for the open discussion and for your work on these valuable additions to the JDK.

Best regards,

On Tue, Jun 3, 2025 at 2:13?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
The general feedback received thus far has been primarily positive. There have been a few behavior-related enhancements over the previews to better handle interruption (there's still room to improve there, as per our concurrent conversation) as well as some improvements to work-in-progress tracking.

It will be interesting to see which Gatherer-based operations will be devised by Java developers in the future.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 2 June 2025 18:54
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order?


Hi Viktor,

Thanks for your reply and for sharing your experience regarding user preferences. I appreciate that perspective.

You're right, if an unordered version of mapConcurrent proves to be widely beneficial and is implemented and adopted by the community, it could certainly make a strong case for future inclusion in the JDK.

I wanted to clarify a nuance regarding user preference that I might not have articulated clearly before. If the question is simply "ordered or unordered?", in isolation, I can see why many, myself included, might lean towards "ordered" as a general preference.

However, the decision becomes more complex when the associated trade-offs are considered. If the question were phrased more like, "Do you prefer an ordered mapConcurrent by default, even if it entails potential performance overhead and limitations for certain use cases like race() operations, versus an unordered version that offers higher throughput and broader applicability in such scenarios?" my (and perhaps others') answer might differ. The perceived cost versus benefit of ordering changes significantly when these factors are explicit.

My initial suggestion stemmed from the belief that the performance and flexibility gains of an unordered approach for I/O-bound tasks would, in many practical situations, outweigh the convenience of default ordering, especially since ordering can be reintroduced relatively easily, and explicitly, when needed.

Thanks again for the discussion.

Best regards,

On Mon, Jun 2, 2025 at 8:51?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>My perspective is that strict adherence to input order for mapConcurrent() might not be the most common or beneficial default behavior for users.

If there is indeed a majority who would benefit from an unordered version of mapConcurrent (my experience is that the majority prefer ordered) then, since it is possible to implement such a Gatherer outside of the JDK, this is something which will be constructed, widely used, and someone will then propose to add something similar to the JDK.

>While re-implementing the gatherer is a possibility, the existing implementation is non-trivial, and creating a custom, robust alternative represents a significant undertaking.

The existing version needs to maintain order, which adds to the complexity of the implementation. Implementing an unordered version would likely look different.
I'd definitely encourage taking the opportunity to attempt to implement it.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 2 June 2025 17:05
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order?


Thank you for your response and for considering my feedback on the mapConcurrent() gatherer. I understand and respect that the final decision rests with the JDK maintainers.

I would like to offer a couple of further points for consideration. My perspective is that strict adherence to input order for mapConcurrent() might not be the most common or beneficial default behavior for users. I'd be very interested to see any research or data that suggests otherwise, as that would certainly inform my understanding.

From my experience, a more common need is for higher throughput in I/O-intensive operations. The ability to support use cases like race()?where the first successfully completed operation determines the outcome?also seems like a valuable capability that is currently infeasible due to the ordering constraint.

As I see it, if a developer specifically requires the input order to be preserved, this can be achieved with relative ease by applying a subsequent sorting operation. For instance:

.gather(mapConcurrent(...))
.sorted(Comparator.comparing(Result::getInputSequenceId))


The primary challenge in these scenarios is typically the efficient fan-out and execution of concurrent tasks, not the subsequent sorting of results.

Conversely, as you've noted, there isn't a straightforward way to modify the current default ordered behavior to achieve the higher throughput or race() semantics that an unordered approach would naturally provide.

While re-implementing the gatherer is a possibility, the existing implementation is non-trivial, and creating a custom, robust alternative represents a significant undertaking. My hope was that an unordered option could be a valuable addition to the standard library, benefiting a wider range of developers.

Thank you again for your time and consideration.


On Mon, Jun 2, 2025 at 7:48?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>Even if it by default preserves input order, when I explicitly called stream.unordered(), could mapConcurrent() respect that and in return achieve higher throughput with support for race?

The Gatherer doesn't know whether the Stream is unordered or ordered. The operation should be semantically equivalent anyway.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 2 June 2025 16:29
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>; core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: [External] : Re: Should mapConcurrent() respect time order instead of input order?

Sorry. Forgot to copy to the mailing list.

On Mon, Jun 2, 2025 at 7:27?AM Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>> wrote:
Thanks Viktor!

I was thinking from my own experience that I wouldn't have automatically assumed that a concurrent fanout library would by default preserve input order.

And I think wanting high throughput with real-life utilities like race would be more commonly useful.

But I could be wrong.

Regardless, mapConcurrent() can do both, no?

Even if it by default preserves input order, when I explicitly called stream.unordered(), could mapConcurrent() respect that and in return achieve higher throughput with support for race?



On Mon, Jun 2, 2025 at 2:33?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi!

In a similar vein to the built-in Collectors,
the built-in Gatherers provide solutions to common stream-related problems, but also, they also serve as "inspiration" for developers for what is possible to implement using Gatherers.

If someone, for performance reasons, and with a use-case which does not require encounter-order, want to take advantage of that combination of circumstances, it is definitely possible to implement your own Gatherer which has that behavior.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Sunday, 1 June 2025 21:08
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Should mapConcurrent() respect time order instead of input order?

It seems like for most people, input order isn't that important for concurrent work, and concurrent results being in non-deterministic order is often expected.

If mapConcurrent() just respect output encounter order:

It'll be able to achieve higher throughput if an early task is slow, For example, with concurrency=2, and if the first task takes 10 minutes to run, mapConcurrent() would only be able to process 2 tasks within the first 10 minutes; whereas with encounter order, the first task being slow doesn't block the 3rd - 100th elements from being processed and output.

mapConcurrent() can be used to implement useful concurrent semantics, for example to support race semantics. Imagine if I need to send request to 10 candidate backends and take whichever that succeeds first, I'd be able to do:

backends.stream()
    .gather(mapConcurrent(
        backend -> {
          try {
            return backend.fetchOrder();
           } catch (RpcException e) {
             return null; // failed to fetch but not fatal
           }
        })
        .filter(Objects::notNull)
        .findFirst(); // first success then cancel the rest

Cheers,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250604/05f99d32/attachment-0001.htm>

From jlu at openjdk.org  Wed Jun  4 18:48:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 4 Jun 2025 18:48:53 GMT
Subject: Integrated: 8358170: Repurpose testCompat in
 test/jdk/java/util/TimeZone/Bug8167143.java
In-Reply-To: <HrmmeikYwNOcksOC0w_FA77nNhHkdcXWjOIx6cKQWC4=.1d5a6edb-9b7c-4b03-97ce-3c90bc962964@github.com>
References: <HrmmeikYwNOcksOC0w_FA77nNhHkdcXWjOIx6cKQWC4=.1d5a6edb-9b7c-4b03-97ce-3c90bc962964@github.com>
Message-ID: <BM4BXCjN9lpVOZ-MJX3XOgQ424cv_wnEKlIIfqEh3YQ=.a63effa7-be28-46f0-8d62-ce7c92f146fc@github.com>

On Tue, 3 Jun 2025 16:47:20 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which modifies the test/jdk/java/util/TimeZone/Bug8167143.java "testCompat" case to be repurposed to check the implicit locales for the FALLBACK BreakIterator and Collator providers. (FALLBACK is the primary provider in those cases.) Since the method is corrected, it can be re-added as a test case. This change stems from discussion in https://git.openjdk.org/jdk/pull/25532.

This pull request has now been integrated.

Changeset: 8f821175
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f821175cc4484d651151818cc518ef608ebcc83
Stats:     39 lines in 1 file changed: 2 ins; 20 del; 17 mod

8358170: Repurpose testCompat in test/jdk/java/util/TimeZone/Bug8167143.java

Reviewed-by: naoto

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

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

From hgreule at openjdk.org  Wed Jun  4 19:22:51 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Wed, 4 Jun 2025 19:22:51 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file
In-Reply-To: <_pcPENDOo2UK1hUIaUEe39a4uP94xmkHCJRXT3VNCRE=.46e88a2e-7c78-44d0-8d5d-3fe297b36238@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <_pcPENDOo2UK1hUIaUEe39a4uP94xmkHCJRXT3VNCRE=.46e88a2e-7c78-44d0-8d5d-3fe297b36238@github.com>
Message-ID: <a4r34MXHmlbCk-RjuVF0c6iJPwj9k5U9LVyHFX5-6fI=.a5702df0-636a-45d3-9de0-57e2d0d884a2@github.com>

On Mon, 2 Jun 2025 12:58:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.
>
> That sounds right.

@liach is there anything else to do? Please let me know.

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

PR Comment: https://git.openjdk.org/jdk/pull/25569#issuecomment-2941172515

From psandoz at openjdk.org  Wed Jun  4 19:42:51 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 4 Jun 2025 19:42:51 GMT
Subject: RFR: 8358217: jdk/incubator/vector/PreferredSpeciesTest.java#id0
 failures - expected [128] but found [256] [v2]
In-Reply-To: <4IACB2JbB8Dik4VZTQA-68HoODNpfA25v1bBiMD4feM=.2ddc0a45-d1fe-424a-9d2d-99d628cc4c3c@github.com>
References: <3e872OAhOzIPD2H_NVh3BdB_ea2LIFemxzAoJ7bZ190=.6e962666-502b-428e-a3a4-452cfbddb8ad@github.com>
 <4IACB2JbB8Dik4VZTQA-68HoODNpfA25v1bBiMD4feM=.2ddc0a45-d1fe-424a-9d2d-99d628cc4c3c@github.com>
Message-ID: <5MVf3WvLD1zIMfpQb-cJBgEJkTzdmnw0N5d_7Ou2wiU=.bb3ac863-0a43-49ef-9cd5-b6e38566f5e4@github.com>

On Sat, 31 May 2025 17:27:30 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> Removing incorrect assumptions and assertions from a breaking test related to https://bugs.openjdk.org/browse/JDK-8358218
>
> Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8358217
>  - Removing incorrect assumptions from test

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25565#pullrequestreview-2897898218

From igraves at openjdk.org  Wed Jun  4 19:48:53 2025
From: igraves at openjdk.org (Ian Graves)
Date: Wed, 4 Jun 2025 19:48:53 GMT
Subject: Integrated: 8358217:
 jdk/incubator/vector/PreferredSpeciesTest.java#id0 failures - expected [128]
 but found [256]
In-Reply-To: <3e872OAhOzIPD2H_NVh3BdB_ea2LIFemxzAoJ7bZ190=.6e962666-502b-428e-a3a4-452cfbddb8ad@github.com>
References: <3e872OAhOzIPD2H_NVh3BdB_ea2LIFemxzAoJ7bZ190=.6e962666-502b-428e-a3a4-452cfbddb8ad@github.com>
Message-ID: <76hmFbqKLhRQWcD-Qj1WKbV7I_A4dNNCzycFqbmKTI0=.1e70281d-1446-4a6f-8f74-8387ee2b99e1@github.com>

On Sat, 31 May 2025 16:18:59 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Removing incorrect assumptions and assertions from a breaking test related to https://bugs.openjdk.org/browse/JDK-8358218

This pull request has now been integrated.

Changeset: 901144ee
Author:    Ian Graves <igraves at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/901144ee0d3e984aa8b8f047498440450942f3e5
Stats:     13 lines in 2 files changed: 0 ins; 13 del; 0 mod

8358217: jdk/incubator/vector/PreferredSpeciesTest.java#id0 failures - expected [128] but found [256]

Co-authored-by: Paul Sandoz <psandoz at openjdk.org>
Co-authored-by: Jaikiran Pai <jpai at openjdk.org>
Reviewed-by: syan, psandoz

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

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

From darcy at openjdk.org  Wed Jun  4 20:13:56 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 4 Jun 2025 20:13:56 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
In-Reply-To: <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
Message-ID: <TtJhT2d8gCxXyqE4Do-VMnz1G-4c4yZEw_Bmsw7UWog=.48da9ef3-ebd5-4f08-8ee6-d372d213fd32@github.com>

On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' into jdk.8355746
>  - Problemlist JavaBaseCheckSince
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 24
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - problem list some failing tests
>  - Merge branch 'master' into jdk.8355746
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2897980100

From iris at openjdk.org  Wed Jun  4 20:37:51 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 4 Jun 2025 20:37:51 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
In-Reply-To: <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
Message-ID: <35K5iPJmI7-SaswDGvLtPKD87st1QJcFgfka38TsImQ=.b8f56c80-d2c6-4282-8b85-eca97880dfe0@github.com>

On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' into jdk.8355746
>  - Problemlist JavaBaseCheckSince
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 24
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - problem list some failing tests
>  - Merge branch 'master' into jdk.8355746
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2898034878

From kcr at openjdk.org  Wed Jun  4 20:37:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 4 Jun 2025 20:37:52 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v6]
In-Reply-To: <_yRRFog3hl3dV5bNvkT2t8vPwaPqOPtzz-JY9_fozKs=.fa645a72-84f9-4736-8ae8-a719302a2f24@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
 <_yRRFog3hl3dV5bNvkT2t8vPwaPqOPtzz-JY9_fozKs=.fa645a72-84f9-4736-8ae8-a719302a2f24@github.com>
Message-ID: <_Vfw9XCw0xZe8UevwOD5UOW4dZHoT2VzKC4_PT5nIGI=.9f6c8119-c437-49b1-90f5-740793992c20@github.com>

On Tue, 3 Jun 2025 11:10:30 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> I have problemlisted `tools/sincechecker/modules/java.base/JavaBaseCheckSince.java` as it is failing due to the symbol information lagging behind.

What is your plan for addressing this? In its current state, that problem list entry will prevent integration. If you intend to integrate this PR with that test problem listed, you will need to file a new bug and use that bug ID in the problem list.

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

PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2941383168

From kcr at openjdk.org  Wed Jun  4 20:46:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 4 Jun 2025 20:46:52 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
In-Reply-To: <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
Message-ID: <mjQQ6ZCQWERIdNo17Fcy-PDJJF06I2sPaWMNb6l5E_M=.40e02f60-30eb-46c2-932e-3943f1e456d5@github.com>

On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' into jdk.8355746
>  - Problemlist JavaBaseCheckSince
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 24
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - problem list some failing tests
>  - Merge branch 'master' into jdk.8355746
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496

test/jdk/ProblemList.txt line 843:

> 841: # jdk_since_checks
> 842: 
> 843: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8355746 generic-all

You will need a different bug ID in order to problem list this test. It is an integration blocker to use the bug ID of a bug being fixed in the problem list.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2127408934

From jlu at openjdk.org  Wed Jun  4 21:26:04 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 4 Jun 2025 21:26:04 GMT
Subject: RFR: 8358426: Improve lazy computation in Locale
Message-ID: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>

Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.

Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.

Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).

Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.

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

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/25646/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25646&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358426
  Stats: 151 lines in 2 files changed: 51 ins; 59 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/25646.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25646/head:pull/25646

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

From nbenalla at openjdk.org  Wed Jun  4 21:36:52 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Jun 2025 21:36:52 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
In-Reply-To: <mjQQ6ZCQWERIdNo17Fcy-PDJJF06I2sPaWMNb6l5E_M=.40e02f60-30eb-46c2-932e-3943f1e456d5@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
 <mjQQ6ZCQWERIdNo17Fcy-PDJJF06I2sPaWMNb6l5E_M=.40e02f60-30eb-46c2-932e-3943f1e456d5@github.com>
Message-ID: <LPUpmFAwsEr9okQ2_9nJfDQNXtD6VX6CI5qi8TEf_-k=.0d220f12-4685-4681-9ea6-ac6f5e8a1d0f@github.com>

On Wed, 4 Jun 2025 20:44:12 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Merge branch 'master' into jdk.8355746
>>  - Problemlist JavaBaseCheckSince
>>  - Revert "feedback: never bump ASM version"
>>    
>>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>>  - Merge branch 'master' into jdk.8355746
>>  - Merge branch 'master' into jdk.8355746
>>  - Merge branch 'master' into jdk.8355746
>>  - Update --release 25 symbol information for JDK 25 build 24
>>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>>  - Merge branch 'master' into jdk.8355746
>>  - problem list some failing tests
>>  - Merge branch 'master' into jdk.8355746
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496
>
> test/jdk/ProblemList.txt line 843:
> 
>> 841: # jdk_since_checks
>> 842: 
>> 843: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8355746 generic-all
> 
> You will need a different bug ID in order to problem list this test. It is an integration blocker to use the bug ID of a bug being fixed in the problem list.

Will update this in a couple of hours. Thanks Kevin.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2127478174

From swen at openjdk.org  Wed Jun  4 21:50:50 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 4 Jun 2025 21:50:50 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal [v3]
In-Reply-To: <q1GKDvad3GF4chYQRDF28JvCV9nJ6QmllaoaP3WJBGs=.960db4f5-8c1b-44e1-aa19-b5424120f493@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
 <98Ars6Qebvn48y6VXmJUmWnL2TlFUPlvhrjkKVB2MvM=.8b3d7ad7-7f9e-4e82-8189-3767ed5e1188@github.com>
 <q1GKDvad3GF4chYQRDF28JvCV9nJ6QmllaoaP3WJBGs=.960db4f5-8c1b-44e1-aa19-b5424120f493@github.com>
Message-ID: <ytJK-XAFCb07KJgz0KX27l1cbPKtO58mzKal3MLApac=.3cadff91-0aeb-40cc-bcfb-116978a0d66f@github.com>

On Wed, 4 Jun 2025 12:08:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> The newly marked arrays are indeed only updated once. Can we see any benchmark showing a performance gain?

I ran `make test TEST="micro:java.math.BigDecimals` on a MacBook M1 Pro, and there was no performance improvement with the Stable added by this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25437#issuecomment-2941634408

From kcr at openjdk.org  Wed Jun  4 21:51:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 4 Jun 2025 21:51:52 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
In-Reply-To: <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
Message-ID: <CT4PKK-7N0z92vGQulU36AwsHzHnASR0frsvU4kJUkM=.eb614b2e-51b2-437d-bbc0-a8d7ebdd7c84@github.com>

On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' into jdk.8355746
>  - Problemlist JavaBaseCheckSince
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 24
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - problem list some failing tests
>  - Merge branch 'master' into jdk.8355746
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496

test/jdk/ProblemList.txt line 843:

> 841: # jdk_since_checks
> 842: 
> 843: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8355746 generic-all

Suggestion:

tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8358627 generic-all


@nizarbenalla Per our offline discussion, I created [JDK-8358627](https://bugs.openjdk.org/browse/JDK-8358627) to track this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2127497730

From smarks at openjdk.org  Wed Jun  4 22:33:54 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 4 Jun 2025 22:33:54 GMT
Subject: RFR: 8358015: Fix SequencedMap sequenced view method
 specifications [v2]
In-Reply-To: <TfgVx46NtJvr8PKc0-EfhpWtX8VjkYjM9544vuJduEU=.4258687a-8b6c-446f-ae71-2df9f990f7b7@github.com>
References: <SnpLEV0JAj3XXhlcuHptG00kSERD8Loy_fklx6xhRLc=.6c588402-9d95-48fd-aa44-9c5b463b6fab@github.com>
 <8gPP7kpzcCSz8A4o0eCUrDhJRqC_atLNvhu87K3wF_Y=.2a49957a-f2bb-40a5-a091-97d634e06457@github.com>
 <Dn80nyjlzAyyRdJh3xSv2xdqzZUFBl_jYnATxNirfkc=.e761b3d7-cfda-4459-8f05-1b36e127639f@github.com>
 <9vq8tA47eS-P2oW0rUMhk1YkcTWYq3_7kEibzlRgIXM=.fbb4480b-b2ad-47c5-8b60-6c3728ae4fad@github.com>
 <zdF61ZWS4smTOymsOYnXr4_-nsg8JufkcP7Pn6Hl3Rg=.5dde6f8c-4700-430f-840b-23b3319c1e86@github.com>
 <lxqTwJxWxJuzvoPoHCyxv-DfMR1VHFVzSJ7h5iVrjsw=.c6260f02-d8ee-4ed5-b715-e36b3146fcbc@github.com>
 <TfgVx46NtJvr8PKc0-EfhpWtX8VjkYjM9544vuJduEU=.4258687a-8b6c-446f-ae71-2df9f990f7b7@github.com>
Message-ID: <Py3hbu2qfBw5Kts1MBILKq9RQ3C4A7ohucy9OscURYg=.6caf819d-61e5-454f-aee7-eb07f9e2edce@github.com>

On Wed, 4 Jun 2025 16:50:15 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> Interesting. This `@NoOverride` idea could be useful on a subclass that wants to make sure it overrides everything. (Maybe `@NoInherit` would be a better name.) Meanwhile for JDK-8357272 (PR https://github.com/openjdk/jdk/pull/25478) we're implementing similar policy checking in a test, though the exact policy is "no inheritance of default methods."
>
>> The `@Override` annotation has been inconsistently applied in the collections implementations. In practice since so many methods are overridden, and some test would likely fail if a method weren't overridden properly, the annotation would mostly add clutter. Indeed I'm considering pulling out all uses of `@Override` in certain areas because they're just clutter.
> 
> The @Override annotation was one of Java's best innovations to detect consequences of changes in a base class for derived classes at compile time and it also carries information to any developer looking at a method, so calling it clutter (in Collection implementations) seems like a bit of exaggeration to me. Some IDEs have a feature to automatically add @Override annotations on save, and I think the JDK would improve if missing @Override annotations would be added to the whole code base.

The `@Override` annotation doesn't help with the main maintenance issue facing the collections framework, which occurs when an overriding method is missing. Virtually all of the public methods in the collection implementation classes are overrides. Adding an `@Override` annotation to every one of these would add a considerable amount of clutter for little benefit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25515#discussion_r2127545058

From nbenalla at openjdk.org  Wed Jun  4 23:01:14 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Jun 2025 23:01:14 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v8]
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: <0wD_TZCgYfWRZurWBE_yoLoNtP7xlUUUPxJ3Stqi5Cs=.42b298e3-bbd7-4d9e-bdfd-ae9176ffc9b5@github.com>

> Get JDK 26 underway.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - use a different bug ID to problemlist `kevinrushforth `
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Problemlist JavaBaseCheckSince
 - Revert "feedback: never bump ASM version"
   
   This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Update --release 25 symbol information for JDK 25 build 24
   The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
 - ... and 12 more: https://git.openjdk.org/jdk/compare/5b27e9c2...09df3b66

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

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=07
  Stats: 1830 lines in 60 files changed: 1740 ins; 16 del; 74 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 liach at openjdk.org  Wed Jun  4 23:03:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Jun 2025 23:03:50 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v3]
In-Reply-To: <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
Message-ID: <43VTjEzkK3bCvuzs_O39TqLIPEYTy1kGDrpenF2iOrE=.cef539f8-8a57-4938-9fb9-4a314a241bf9@github.com>

On Mon, 2 Jun 2025 20:06:34 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make test failures easier to read

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25569#pullrequestreview-2898306324

From nbenalla at openjdk.org  Wed Jun  4 23:09:08 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Jun 2025 23:09:08 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v9]
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: <gFIWry-KmlCjSbUQfbXZDS1Vu9XdAgesfId6WktB3EM=.749bcbf5-a04e-4694-a67c-3913ecd68a42@github.com>

> Get JDK 26 underway.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25008/files
  - new: https://git.openjdk.org/jdk/pull/25008/files/09df3b66..9929da7b

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 iris at openjdk.org  Wed Jun  4 23:56:52 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 4 Jun 2025 23:56:52 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v9]
In-Reply-To: <gFIWry-KmlCjSbUQfbXZDS1Vu9XdAgesfId6WktB3EM=.749bcbf5-a04e-4694-a67c-3913ecd68a42@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <gFIWry-KmlCjSbUQfbXZDS1Vu9XdAgesfId6WktB3EM=.749bcbf5-a04e-4694-a67c-3913ecd68a42@github.com>
Message-ID: <SKr7_DxXZshmrjnCr9TN17KU-5ziqCGNDQCpFY4LmvM=.755c3425-adbb-48a0-8cb0-453601ae7c0e@github.com>

On Wed, 4 Jun 2025 23:09:08 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2898378068

From liach at openjdk.org  Thu Jun  5 00:20:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Jun 2025 00:20:49 GMT
Subject: RFR: 8358426: Improve lazy computation in Locale
In-Reply-To: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
Message-ID: <ozQnpoa8ilbhpOap8qfjG0IhCu2GOX5DYE342PTSMe8=.56bb67d2-f21d-4617-9204-60f0914ad499@github.com>

On Wed, 4 Jun 2025 21:20:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
> 
> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
> 
> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
> 
> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.

Looks correct. Note we have a separate effort #25040 to avoid anonymous supplier classes, don't know if @minborg wishes locale to migrate to that one directly or remain on the more high-level SV.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25646#pullrequestreview-2898526691

From smarks at openjdk.org  Thu Jun  5 00:24:55 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 5 Jun 2025 00:24:55 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
 <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>
Message-ID: <UTGl8Bkt5sB4NW77bhZVWQGE4xN7a0MCXjhVn5k_wnk=.b1ff279d-f5b4-45f3-94a7-4aad266878d1@github.com>

On Wed, 4 Jun 2025 16:04:08 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/Socket.java line 970:
>> 
>>> 968:             long end = SocketReadEvent.timestamp();
>>> 969:             long duration = end - start;
>>> 970:             if (SocketReadEvent.shouldThrottleCommit(duration, end)) {
>> 
>> The use sites want to ask if an event should be committed. Does the word "Throttle" need to be in name as I don't think the use cases need to care about this.
>> 
>> Also,  just to point out that the shouldXXX method is called with the the end timestamp and duration whereas the offset/emit/commit methods are called with the start timestamp and duration. So two long timestamps and a long measure of time, easy to get it wrong somewhere. Maybe not this PR but I think would be clearer at the use sites to use start or end consistently and reduce potential for mistakes.
>
> We need some indication of which events are throttleable and looking at the mirror event may not work in some scenarios.
> 
> We need to sample the endTime, because the startTime may be several minutes in the past. We could use commit(startTime, endTime, ...) and calculate the duration inside the method, but it may be confusing because the fields in the event are startTime and duration. We would also need to calculate the duration twice, both for shouldCommit and commit.
> 
> When we get value types and perhaps value events, much of the ugliness of static methods could be avoided.

I think we (from both the java.base and jdk.jfr perspectives) need to keep an eye on the complexity of the use sites. The new throttling stuff requires a new local variable. By itself this isn't a big deal, but there are 12 events being updated here. In addition, each requires a start, end, and duration, and clearly duration = end - start. These are all long values, and the different calls require different long values, so sooner or later somebody is going to get this wrong.

To a certain extent we can do more cleanup on the java.base side, by using things like SocketReadEvent's offer() method instead of its emit() method. Unfortunately only one site uses offer() -- NIO SocketChannelImpl -- and note that it didn't need to be updated! The other events should have something like the offer() method, which groups together the testing of shouldCommit/shouldThrottleCommit with the committing of the event. (This also should avoid recalculating the duration, but really, this is only a subtraction of two longs, so it should take only one cycle.)

But note what we're doing here is constructing an internal API within java.base, between the use sites (like java.net.Socket) and the java.base-side JFR stuff (jdk.internal.event.SocketReadEvent). Maybe after things are cleaned up and consolidated here we can see if the API between jdk.internal.event and jdk.jfr can be improved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2127716516

From hgreule at openjdk.org  Thu Jun  5 01:35:51 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Thu, 5 Jun 2025 01:35:51 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v3]
In-Reply-To: <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
Message-ID: <3gheiEAamKkwB_QE3Xx49ue7OBnt0R70kTyXnVLUrW8=.40b9509d-37f4-40be-8ccd-7ad2e8345ba8@github.com>

On Mon, 2 Jun 2025 20:06:34 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make test failures easier to read

Thanks for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/25569#issuecomment-2942410190

From duke at openjdk.org  Thu Jun  5 01:35:51 2025
From: duke at openjdk.org (duke)
Date: Thu, 5 Jun 2025 01:35:51 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v3]
In-Reply-To: <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
Message-ID: <phXoBLBbdZro4KmjlRcEPDYl_tiD28HyahpJQLBikvI=.8d3b9468-354b-4994-9026-cad7daf6907e@github.com>

On Mon, 2 Jun 2025 20:06:34 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make test failures easier to read

@SirYwell 
Your change (at version 379c892da367f2a7db6ada1fd027df82e758bb9f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25569#issuecomment-2942411420

From liach at openjdk.org  Thu Jun  5 01:43:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Jun 2025 01:43:57 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v3]
In-Reply-To: <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
Message-ID: <hSgyQSOmHi-k4_JvVQzVu46ePcULtLlDhJZzMOu6gbY=.27dcce37-c106-4afd-a578-8287a9c6d71f@github.com>

On Mon, 2 Jun 2025 20:06:34 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make test failures easier to read

Thanks. Since this test is in tier1 langtools which is green, I think we can go ahead.

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

PR Comment: https://git.openjdk.org/jdk/pull/25569#issuecomment-2942421568

From hgreule at openjdk.org  Thu Jun  5 01:43:58 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Thu, 5 Jun 2025 01:43:58 GMT
Subject: Integrated: 8358078: javap crashes with NPE on preview class file
In-Reply-To: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
Message-ID: <5tWT2kiEgtGMukHjrp22pcWLRZRjLMljuQxQKismJgM=.1cedb4d7-56c5-4b87-a391-805481476e90@github.com>

On Sun, 1 Jun 2025 04:53:46 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.

This pull request has now been integrated.

Changeset: 575806c0
Author:    Hannes Greule <hgreule at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/575806c0e5584ea24cda80158070579b88c477f7
Stats:     102 lines in 2 files changed: 100 ins; 0 del; 2 mod

8358078: javap crashes with NPE on preview class file

Reviewed-by: liach

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

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

From naoto at openjdk.org  Thu Jun  5 01:44:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Jun 2025 01:44:56 GMT
Subject: RFR: 8358626: Emit UTF-8 CLDR resources
In-Reply-To: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
Message-ID: <HI4ELhcHNrZgg7rBbIQXzzvU3UjbiVp5xoYBYcJpofw=.9acdbaf6-52a2-4939-8aff-15b1b1aed792@github.com>

On Wed, 4 Jun 2025 21:54:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)

Looks like this PR did not send out the email in the first place, I am leaving a comment to kick the bot

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

PR Comment: https://git.openjdk.org/jdk/pull/25648#issuecomment-2942422941

From jpai at openjdk.org  Thu Jun  5 04:28:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 5 Jun 2025 04:28:54 GMT
Subject: Integrated: 8358558: (zipfs) Reorder the listing of "accessMode"
 property in the ZIP file system's documentation
In-Reply-To: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
References: <k8E289sZiKYn2o1C8waE41W_UbIaxaZ_4MNyEazvfKY=.cffba5eb-e6e2-402f-b98b-13ba0cc9cdb5@github.com>
Message-ID: <8Pr9hdIS-A-o8Kod2NtWunI68S_CuQQXv3bp0eQ91IY=.746c0c6f-4ce4-44e0-9185-3726328a6128@github.com>

On Wed, 4 Jun 2025 06:47:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial doc-only change to the `jdk.zipfs`'s documentation? This moves the `accessMode` property listing to the top of the table instead of being at the bottom. With this change, the text about throwing `IllegalArgumentException` when `create=true` and `accessMode=readOnly` has been moved to the `create` property's description.
> 
> No functional or specification changes are involved. I verified that the generated documentation looks fine too.

This pull request has now been integrated.

Changeset: 08023481
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08023481edec4c0cacc79a608c573856f0718e58
Stats:     82 lines in 1 file changed: 40 ins; 41 del; 1 mod

8358558: (zipfs) Reorder the listing of "accessMode" property in the ZIP file system's documentation

Reviewed-by: dfuchs, vyazici, alanb, lancea

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

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

From vyazici at openjdk.org  Thu Jun  5 06:04:49 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 5 Jun 2025 06:04:49 GMT
Subject: RFR: 8357821: Revert incorrectly named JavaLangAccess::unchecked*
 methods [v2]
In-Reply-To: <tDzMTU2VeD_fIb5s8gweKAF1fnz5p6y7kWgGkWcpMAY=.749b0bce-e6e0-490f-a6eb-f584c3f7166f@github.com>
References: <tDzMTU2VeD_fIb5s8gweKAF1fnz5p6y7kWgGkWcpMAY=.749b0bce-e6e0-490f-a6eb-f584c3f7166f@github.com>
Message-ID: <5s84AfVzajq6I_OyXi6Jt5zDt_r64OSOIvQlTouKX2k=.3650b2dd-c985-460d-b0da-7e78af6799aa@github.com>

> Reverts certain [JDK-8353197](https://bugs.openjdk.org/browse/JDK-8353197) (which implements JavaDoc improvement and precautionary naming for certain unsafe methods in `jdk.internal.access.JavaLangAccess`) changes that are found to be incorrect. See the JBS issue for details on the followed evaluation process.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Add `@implSpec`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25545/files
  - new: https://git.openjdk.org/jdk/pull/25545/files/bbf42347..1e135598

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

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

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

From vyazici at openjdk.org  Thu Jun  5 06:04:50 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 5 Jun 2025 06:04:50 GMT
Subject: RFR: 8357821: Revert incorrectly named JavaLangAccess::unchecked*
 methods
In-Reply-To: <IZG_8Y678RGrqZCI3vzu0i8zMO3HOWPR1z1Yhbu-NAU=.68d39f3a-1906-4414-aabf-3103b3f00c1e@github.com>
References: <tDzMTU2VeD_fIb5s8gweKAF1fnz5p6y7kWgGkWcpMAY=.749b0bce-e6e0-490f-a6eb-f584c3f7166f@github.com>
 <wqqD43dK-OFxmDgiJe4CphOLXmzODWdGTjWAhO8KO2o=.682028b3-5ec8-450c-ad21-783328af758b@github.com>
 <IZG_8Y678RGrqZCI3vzu0i8zMO3HOWPR1z1Yhbu-NAU=.68d39f3a-1906-4414-aabf-3103b3f00c1e@github.com>
Message-ID: <nceBUkqXTnr_MiSCcxHl2sr37n8P4J1irX26c7ZevPQ=.41757cac-5380-4833-8b75-780fdb7621e1@github.com>

On Wed, 4 Jun 2025 11:39:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>>> I wonder if we should add that implementations of the affected method _shall_ do bounds checking to reduce the likelihood of a new/updated native implementation miss that?
>> 
>> @minborg, would you mind elaborating on this a bit, please? Do you imply adding an `@implSpec` to the touched `JavaLangAccess` methods?
>
>> > I wonder if we should add that implementations of the affected method _shall_ do bounds checking to reduce the likelihood of a new/updated native implementation miss that?
>> 
>> @minborg, would you mind elaborating on this a bit, please? Do you imply adding an `@implSpec` to the touched `JavaLangAccess` methods?
> 
> Yes, I think that would be a good thing to do.

@minborg, added `@implSpec` in 1e135598e6c.

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

PR Comment: https://git.openjdk.org/jdk/pull/25545#issuecomment-2942878470

From vyazici at openjdk.org  Thu Jun  5 06:17:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 5 Jun 2025 06:17:53 GMT
Subject: RFR: 8358626: Emit UTF-8 CLDR resources
In-Reply-To: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
Message-ID: <RQJAF7lmALTUQcXhOfsiwP-IgTSGcvPSIKWQd3nI49w=.b4b7eb8d-6f4d-445b-bf3e-de66ee808c53@github.com>

On Wed, 4 Jun 2025 21:54:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)

@naotoj, shall we add this note as a comment to places where `-utf8` is added?

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

PR Comment: https://git.openjdk.org/jdk/pull/25648#issuecomment-2942906463

From vklang at openjdk.org  Thu Jun  5 07:52:30 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 5 Jun 2025 07:52:30 GMT
Subject: RFR: 8358633 : Test
 ThreadPoolExecutorTest::testTimedInvokeAnyNullTimeUnit is broken by
 JDK-8347491
Message-ID: <ZDn_Lzo1bgeuvKaTALiP3aD8Cq3ro2Wg9S0YqyD4Owc=.b09b622d-ac64-4baa-b1bb-29dfde351f0c@github.com>

It's too fragile to depend on generated NPE messages

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

Commit messages:
 - Removing exception message check to avoid failures if helpful NPEs are turned off

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

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

From egahlin at openjdk.org  Thu Jun  5 08:10:42 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 08:10:42 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v4]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <72MCuwD8Jd9igYMm5C4yZyxh-8xLnnKePImAaep3p2U=.49745a1b-7f46-4a07-a150-4c243683068f@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request with a new target base 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 remote-tracking branch 'upstream/master' into throttle-mania-3
 - Fix adjust boundary
 - Some reviewer feedback
 - Consistent annotation
 - Fix typos
 - Fix whitespace
 - Initial

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/7fa2db19..59278ca8

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

  Stats: 26802 lines in 553 files changed: 20626 ins; 2170 del; 4006 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

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

From egahlin at openjdk.org  Thu Jun  5 08:13:21 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 08:13:21 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v5]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <8opPh4lTfGQBzlleDOuxmi3QyhF3M9M7U7MpIoFWUCE=.a14d1385-e759-4fa5-8733-5ebb162d20a7@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request with a new target base 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 remote-tracking branch 'upstream/master' into throttle-mania-3
 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Fix adjust boundary
 - Some reviewer feedback
 - Consistent annotation
 - Fix typos
 - Fix whitespace
 - Initial

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/59278ca8..535d458a

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

  Stats: 2776 lines in 58 files changed: 477 ins; 2217 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

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

From dholmes at openjdk.org  Thu Jun  5 08:14:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 5 Jun 2025 08:14:53 GMT
Subject: RFR: 8358633 : Test
 ThreadPoolExecutorTest::testTimedInvokeAnyNullTimeUnit is broken by
 JDK-8347491
In-Reply-To: <ZDn_Lzo1bgeuvKaTALiP3aD8Cq3ro2Wg9S0YqyD4Owc=.b09b622d-ac64-4baa-b1bb-29dfde351f0c@github.com>
References: <ZDn_Lzo1bgeuvKaTALiP3aD8Cq3ro2Wg9S0YqyD4Owc=.b09b622d-ac64-4baa-b1bb-29dfde351f0c@github.com>
Message-ID: <XTA7f4ihfqcOl1i-knmoMw2zbO0JXHT54o6KKnQOztU=.60273562-833d-48a1-b8ce-9f0ef0744024@github.com>

On Thu, 5 Jun 2025 07:47:17 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> It's too fragile to depend on generated NPE messages

Sorry Viktor but I strongly disagree. It is far too easy to have a test "pass" because it catches the wrong instance of a thrown exception and hide an underlying problem.

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

PR Comment: https://git.openjdk.org/jdk/pull/25655#issuecomment-2943190741

From aturbanov at openjdk.org  Thu Jun  5 08:39:52 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 5 Jun 2025 08:39:52 GMT
Subject: RFR: 8358426: Improve lazy computation in Locale
In-Reply-To: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
Message-ID: <l9FKU1UhkZJT5ar0UT2s4SbS4rbwmnJ-40vG8NMqsVc=.414b38ee-14c4-4f24-81e7-4a7e029d3021@github.com>

On Wed, 4 Jun 2025 21:20:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
> 
> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
> 
> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
> 
> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.

src/java.base/share/classes/java/util/Locale.java line 2348:

> 2346:     private static volatile Locale defaultFormatLocale;
> 2347: 
> 2348:     private transient final Supplier<String> languageTag =

let's use blessed modifiers order
Suggestion:

    private final transient Supplier<String> languageTag =

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25646#discussion_r2128278908

From egahlin at openjdk.org  Thu Jun  5 08:40:44 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 08:40:44 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v6]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <0zy-Tz-VxzBeZiq5EE1iHvG-Z5pmhyByw6H3aCD2Mm4=.217bcfc4-f471-48cc-a003-22bcda24669d@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Fix adjust boundary
 - Some reviewer feedback
 - Consistent annotation
 - Fix typos
 - Fix whitespace
 - Initial

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/535d458a..8259ff41

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

  Stats: 2319 lines in 41 files changed: 2179 ins; 128 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

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

From kbarrett at openjdk.org  Thu Jun  5 08:42:38 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 5 Jun 2025 08:42:38 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v9]
In-Reply-To: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
Message-ID: <fxvzcTxFkifYc-6plgOoHsjPY2uLdL3S9I5Y5e9OAbw=.17f863fb-7573-4ca3-a48a-2f067a6f11d6@github.com>

> Please review this change which adds a native method providing the
> implementation of Reference::get.  Referece::get is an intrinsic candidate, so
> this native method implementation is only used when the intrinsic is not.
> 
> Currently there is intrinsic support by the interpreter, C1, C2, and graal,
> which are always used.  With this change we can later remove all the
> per-platform interpreter intrinsic implementations, and might also remove the
> C1 intrinsic implementation.
> 
> Testing:
> (1) mach5 tier1-6 normal (so using all the existing intrinsics).
> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  fix comment alignment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24315/files
  - new: https://git.openjdk.org/jdk/pull/24315/files/98056a8b..edd4dec2

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

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

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

From aturbanov at openjdk.org  Thu Jun  5 09:02:57 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 5 Jun 2025 09:02:57 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v6]
In-Reply-To: <0zy-Tz-VxzBeZiq5EE1iHvG-Z5pmhyByw6H3aCD2Mm4=.217bcfc4-f471-48cc-a003-22bcda24669d@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <0zy-Tz-VxzBeZiq5EE1iHvG-Z5pmhyByw6H3aCD2Mm4=.217bcfc4-f471-48cc-a003-22bcda24669d@github.com>
Message-ID: <bPhyUNuWlTSgWzVu0XGymtuPwYZa2VqhcLPb7siVcmU=.60458892-b041-4fa8-8237-094f995e50c6@github.com>

On Thu, 5 Jun 2025 08:40:44 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
>  - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
>  - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
>  - Fix adjust boundary
>  - Some reviewer feedback
>  - Consistent annotation
>  - Fix typos
>  - Fix whitespace
>  - Initial

src/java.base/share/classes/java/io/RandomAccessFile.java line 594:

> 592:         } finally {
> 593:             long end = FileWriteEvent.timestamp();
> 594:             long duration =  end - start;

Suggestion:

            long duration = end - start;

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 65:

> 63: public final class EventInstrumentation {
> 64:     public static final long MASK_THROTTLE              = 1 << 62;
> 65:     public static final long MASK_THROTTLE_CHECK        = 1 << 63;

Let's align
Suggestion:

    public static final long MASK_THROTTLE               = 1 << 62;
    public static final long MASK_THROTTLE_CHECK         = 1 << 63;

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 593:

> 591:         if (throttled) {
> 592:             codeBuilder.aload(0);
> 593:             getfield(codeBuilder, eventClassDesc,  ImplicitFields.FIELD_DURATION);

Suggestion:

            getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_DURATION);

test/jdk/jdk/jfr/api/recording/settings/TestSettingsAvailability.java line 93:

> 91:         testSetting(EventNames.JVMInformation, "enabled", "period");
> 92:         testSetting(EventNames.FileRead, "enabled", "threshold", "stackTrace", "throttle");
> 93:         testSetting(EventNames.FileWrite, "enabled", "threshold","stackTrace", "throttle");

Suggestion:

        testSetting(EventNames.FileWrite, "enabled", "threshold", "stackTrace", "throttle");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128322876
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128321445
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128322474
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128323708

From aturbanov at openjdk.org  Thu Jun  5 09:03:53 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 5 Jun 2025 09:03:53 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v4]
In-Reply-To: <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
Message-ID: <Dgsv_uSz55K8txQhEFMYlV1LO2pK9uce85qifdv21hA=.7a279770-1103-4140-a3b2-15503dbb80e8@github.com>

On Tue, 3 Jun 2025 07:55:06 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing `java.io.Reader` import in `Ktab`

test/jdk/com/sun/jdi/MultiBreakpointsTest.java line 181:

> 179: 
> 180:                 }
> 181:             } catch(Exception e) {

Suggestion:

            } catch (Exception e) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2128325755

From vklang at openjdk.org  Thu Jun  5 09:09:50 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 5 Jun 2025 09:09:50 GMT
Subject: RFR: 8358633 : Test
 ThreadPoolExecutorTest::testTimedInvokeAnyNullTimeUnit is broken by
 JDK-8347491
In-Reply-To: <XTA7f4ihfqcOl1i-knmoMw2zbO0JXHT54o6KKnQOztU=.60273562-833d-48a1-b8ce-9f0ef0744024@github.com>
References: <ZDn_Lzo1bgeuvKaTALiP3aD8Cq3ro2Wg9S0YqyD4Owc=.b09b622d-ac64-4baa-b1bb-29dfde351f0c@github.com>
 <XTA7f4ihfqcOl1i-knmoMw2zbO0JXHT54o6KKnQOztU=.60273562-833d-48a1-b8ce-9f0ef0744024@github.com>
Message-ID: <hlI_tUUGxRE9rY-5WkEQRLTFrg0e3jEFt-rbnvF7p2w=.be30a386-4a6c-4a1e-9657-4240023cddc3@github.com>

On Thu, 5 Jun 2025 08:12:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> It's too fragile to depend on generated NPE messages
>
> Sorry Viktor but I strongly disagree. It is far too easy to have a test "pass" because it catches the wrong instance of a thrown exception and hide an underlying problem.

@dholmes-ora In general I agree with you 100%, in this case it was actually the addition of the exception message which broke test runs when -XX:-OmitStackTraceInFastThrow disables JEP 358: https://github.com/openjdk/jdk/commit/f141674d1619d95053d38a9cd8f93a8959b4a211#diff-17cb67c2df590a137a7c215e9367919cd7224b4eedd9c1b0a7e35ccd0a1ac450R1730

So yeah, we could change the test to accept either a null message, or the JEP 358 message, but a null message would still be not verifying that it is thrown for the intended reason (thus hiding underlying issues, as you noted).

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

PR Comment: https://git.openjdk.org/jdk/pull/25655#issuecomment-2943361363

From duke at openjdk.org  Thu Jun  5 09:12:30 2025
From: duke at openjdk.org (erifan)
Date: Thu, 5 Jun 2025 09:12:30 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v7]
In-Reply-To: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
Message-ID: <dCstHcUFS9A79fKEf3RWnPrxvnzKjyVfbBzyT_iyzYo=.19255391-54fb-445e-b7e8-faf016e8a79f@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 12 additional commits since the last revision:

 - Addressed some review comments
 - Merge branch 'master' into JDK-8354242
 - Refactor the JTReg tests for compare.xor(maskAll)
   
   Also made a bit change to support pattern `VectorMask.fromLong()`.
 - Merge branch 'master' into JDK-8354242
 - Refactor code
   
   Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
   optimization, making the code more modular.
 - Merge branch 'master' into JDK-8354242
 - Update the jtreg test
 - Merge branch 'master' into JDK-8354242
 - Addressed some review comments
   
   1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
   2. Improve code comments.
 - Merge branch 'master' into JDK-8354242
 - ... and 2 more: https://git.openjdk.org/jdk/compare/71938fba...ebbcc405

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24674/files
  - new: https://git.openjdk.org/jdk/pull/24674/files/f2f71e34..ebbcc405

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

  Stats: 146911 lines in 2345 files changed: 87334 ins; 41007 del; 18570 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 Jun  5 09:12:33 2025
From: duke at openjdk.org (erifan)
Date: Thu, 5 Jun 2025 09:12:33 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v6]
In-Reply-To: <Di5SQQr4tO4H1VnO-GY1n8JLFtOcH3FID9sGvlRnF1Y=.04e918b6-2efb-426e-9d38-281c08ddc7d7@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <oDd6wkHsAQU3IUV3qCvjtqZ8BSHt7Qq2sx0Yy0Q8onc=.8e7db79c-15a5-4151-ac60-73f114433383@github.com>
 <Di5SQQr4tO4H1VnO-GY1n8JLFtOcH3FID9sGvlRnF1Y=.04e918b6-2efb-426e-9d38-281c08ddc7d7@github.com>
Message-ID: <i7ZGOLC7XeSsY_HtAszZar_KciZlOo-m969xvnww0hs=.7bc25e2f-ded4-4d9d-aaba-892e44a74a19@github.com>

On Wed, 28 May 2025 12:03:48 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Refactor the JTReg tests for compare.xor(maskAll)
>>    
>>    Also made a bit change to support pattern `VectorMask.fromLong()`.
>>  - Merge branch 'master' into JDK-8354242
>>  - Refactor code
>>    
>>    Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
>>    optimization, making the code more modular.
>>  - Merge branch 'master' into JDK-8354242
>>  - Update the jtreg test
>>  - Merge branch 'master' into JDK-8354242
>>  - Addressed some review comments
>>    
>>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>>    2. Improve code comments.
>>  - Merge branch 'master' into JDK-8354242
>>  - Merge branch 'master' into JDK-8354242
>>  - 8354242: VectorAPI: combine vector not operation with compare
>>    
>>    This patch optimizes the following patterns:
>>    For integer types:
>>    ```
>>    (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    ```
>>    cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>>    negative comparison of cond.
>>    
>>    For float and double types:
>>    ```
>>    (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    ```
>>    cond can be eq or ne.
>>    
>>    Benchmarks on Nvidia Grace machine with 128-bit SVE2:
>>    With option `-XX:UseSVE=2`:
>>    ```
>>    Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>>    testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>>    testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>>    testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>>    testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>>    testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>>    testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>>    testCompareGEMaskNotByte	ops/s	7907615.16	4...
>
> src/hotspot/share/opto/vectornode.cpp line 2213:
> 
>> 2211:   Node* in1 = in(1);
>> 2212:   Node* in2 = in(2);
>> 2213:   // Transformations for predicated IRs are not supported for now.
> 
> Suggestion:
> 
>   // Transformations for predicated vectors are not supported for now.

Done.

> src/hotspot/share/opto/vectornode.cpp line 2215:
> 
>> 2213:   // Transformations for predicated IRs are not supported for now.
>> 2214:   if (is_predicated_vector() || in1->is_predicated_vector() ||
>> 2215:       in2->is_predicated_vector()) {
> 
> I would either put all on the same line, or all on separate lines.

Done.

> src/hotspot/share/opto/vectornode.cpp line 2219:
> 
>> 2217:   }
>> 2218: 
>> 2219:   // XorV/XorVMask is commutative, swap VectorMaskCmp/Op_VectorMaskCast to in1.
> 
> Suggestion:
> 
>   // XorV/XorVMask is commutative, swap VectorMaskCmp/VectorMaskCast to in1.
> 
> Would look a little cleaner, and you did also not write `Op_VectorMaskCmp` either ;)

Done, thanks!

> src/hotspot/share/opto/vectornode.cpp line 2225:
> 
>> 2223:   }
>> 2224: 
>> 2225:   const TypeVect* vmcast_vt = nullptr;
> 
> Suggestion:
> 
>   const TypeVect* vector_mask_cast_vt = nullptr;
> 
> I think it would not hurt to write it out. Otherwise, the reader always has to reconstruct that in their head.

Done.

> src/hotspot/share/opto/vectornode.cpp line 2230:
> 
>> 2228:     vmcast_vt = in1->as_Vector()->vect_type();
>> 2229:     in1 = in1->in(1);
>> 2230:   }
> 
> Add a comment why you check `in1->outcnt() == 1`.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2128341063
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2128340484
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2128341959
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2128342468
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2128342908

From duke at openjdk.org  Thu Jun  5 09:12:33 2025
From: duke at openjdk.org (erifan)
Date: Thu, 5 Jun 2025 09:12:33 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v6]
In-Reply-To: <ANJVx2XVfd0JhiyYI1Ny1S9G6kvlYgVlA2hw30_BdzE=.88d7eba0-dc16-4d63-9b09-cd01abad03c4@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <oDd6wkHsAQU3IUV3qCvjtqZ8BSHt7Qq2sx0Yy0Q8onc=.8e7db79c-15a5-4151-ac60-73f114433383@github.com>
 <Di5SQQr4tO4H1VnO-GY1n8JLFtOcH3FID9sGvlRnF1Y=.04e918b6-2efb-426e-9d38-281c08ddc7d7@github.com>
 <ANJVx2XVfd0JhiyYI1Ny1S9G6kvlYgVlA2hw30_BdzE=.88d7eba0-dc16-4d63-9b09-cd01abad03c4@github.com>
Message-ID: <c4UFOSWCKSitUS4U6H0D5dLLYYYyxGcQMm6Ut_M6JYA=.8a232158-a4a8-437e-9081-72e60b750eeb@github.com>

On Thu, 29 May 2025 08:00:05 GMT, erifan <duke at openjdk.org> wrote:

>> src/hotspot/share/opto/vectornode.cpp line 2233:
>> 
>>> 2231:   if (in2->Opcode() == Op_VectorMaskCast) {
>>> 2232:     in2 = in2->in(1);
>>> 2233:   }
>> 
>> Wow, this seems to be an addition that is not covered in the patterns you mention above, right?
>> But is that even necessary?
>> I suppose here `in2 = VectorMaskCast(all_ones_vector)`.
>> Would we not already want to transform this pattern in `VectorMaskCast::Ideal`, is that not possible and more powerful?
>
> Oh yeah, I forgot to mention it in the above comment and commit message. 
> 
> Yes, this is for `in2 = VectorMaskCast(all_ones_vector)`.  I agree it's better to do this transformation in `VectorMaskCast::Ideal`. I'll remove this code change and do the `VectorMaskCast` optimization later. Thanks!

Done.

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

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

From alanb at openjdk.org  Thu Jun  5 09:16:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:16:55 GMT
Subject: RFR: 8358633 : Test
 ThreadPoolExecutorTest::testTimedInvokeAnyNullTimeUnit is broken by
 JDK-8347491
In-Reply-To: <XTA7f4ihfqcOl1i-knmoMw2zbO0JXHT54o6KKnQOztU=.60273562-833d-48a1-b8ce-9f0ef0744024@github.com>
References: <ZDn_Lzo1bgeuvKaTALiP3aD8Cq3ro2Wg9S0YqyD4Owc=.b09b622d-ac64-4baa-b1bb-29dfde351f0c@github.com>
 <XTA7f4ihfqcOl1i-knmoMw2zbO0JXHT54o6KKnQOztU=.60273562-833d-48a1-b8ce-9f0ef0744024@github.com>
Message-ID: <w18KpQKhL2BUboHvj0k5EIh-Igkzab7RpYNZCyQqIlk=.874d9031-05b2-46d1-8e07-2bcaed6f38d0@github.com>

On Thu, 5 Jun 2025 08:12:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> It is far too easy to have a test "pass" because it catches the wrong instance of a thrown exception and hide an underlying problem.

OmitStackTraceInFastThrow is enabled by default so possible for C2 to compile this to throw a pre-allocated exception with no message detail or stack trace. This is what is happening with these -Xcomp runs so the detail message is null rather than the expected message. An explicit test with Objects.requireNonNull would likely dodge this but does seem fragile.

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

PR Comment: https://git.openjdk.org/jdk/pull/25655#issuecomment-2943390680

From duke at openjdk.org  Thu Jun  5 09:17:54 2025
From: duke at openjdk.org (erifan)
Date: Thu, 5 Jun 2025 09:17:54 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v6]
In-Reply-To: <WWv5dtJhaETpblalKdNVW3en9M6rpmDM7aCP_XloaYU=.893365f9-ebfd-4d86-bf27-62be0bdd590e@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <oDd6wkHsAQU3IUV3qCvjtqZ8BSHt7Qq2sx0Yy0Q8onc=.8e7db79c-15a5-4151-ac60-73f114433383@github.com>
 <Di5SQQr4tO4H1VnO-GY1n8JLFtOcH3FID9sGvlRnF1Y=.04e918b6-2efb-426e-9d38-281c08ddc7d7@github.com>
 <9u6hJ-WgnHLMaYBa8ViRdpUZY-bI2wOk-TCRKWJJdqk=.b3303f1f-da3b-4c2e-8f0c-a2e16ba9688e@github.com>
 <WWv5dtJhaETpblalKdNVW3en9M6rpmDM7aCP_XloaYU=.893365f9-ebfd-4d86-bf27-62be0bdd590e@github.com>
Message-ID: <wiw-AkO6_oqCMy_Riy4vB31xNlvW05XFEphD4SZRpGE=.e88bdc7b-4728-41ee-a290-e70c5877d14e@github.com>

On Thu, 29 May 2025 07:55:06 GMT, erifan <duke at openjdk.org> wrote:

>> Also: You now cast `(VectorMaskCmpNode*) in1` twice. Can we not do `as_VectorMaskCmp()`? Or could we at least cast it only once, and then use it as `in1_mask_cmp` instead?
>
>> What is the hard-coded ^ 4 here?
> 
> This is to negate the comparison condition. We can't use `BoolTest::negate()` here because the comparison condition may be **unsigned** comparison. Since there's already a `negate()` function in `BoolTest`, so I tend to add a new function `get_negative_predicate` for this into class `VectorMaskCmpNode`.
> 
>> Also: You now cast (VectorMaskCmpNode*) in1 twice. Can we not do as_VectorMaskCmp()? Or could we at least cast it only once, and then use it as in1_mask_cmp instead?
> 
> For the first cast, I think you mean
> 
>   if (in1->Opcode() != Op_VectorMaskCmp ||
>       in1->outcnt() > 1 ||
>       !((VectorMaskCmpNode*) in1)->predicate_can_be_negated() ||
>       !VectorNode::is_all_ones_vector(in2)) {
>     return nullptr;
>   }
> 
> To remove one cast, then we have to split the above `if` because `in1` may not be a `VectorMaskCmpNode`.
> 
>   if (in1->Opcode() != Op_VectorMaskCmp) {
>     return nullptr;
>   }
>   VectorMaskCmpNode* in1_as_mask_cmp = (VectorMaskCmpNode*) in1;
>   if (in1->outcnt() > 1 ||
>       !in1_as_mask_cmp->predicate_can_be_negated() ||
>       !VectorNode::is_all_ones_vector(in2)) {
>     return nullptr;
>   }
>  BoolTest::mask neg_cond = (BoolTest::mask) (in1_as_mask_cmp->get_predicate() ^ 4);
> 
> Does this look better to you ?

For now I kept the current approach, as I feel it's a little more compact. Thanks!

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

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

From duke at openjdk.org  Thu Jun  5 09:25:35 2025
From: duke at openjdk.org (Alice Pellegrini)
Date: Thu, 5 Jun 2025 09:25:35 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process output
 as it happens
Message-ID: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>

The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.

I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.

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

Commit messages:
 - Update test/lib/jdk/test/lib/process/OutputBuffer.java
 - Initial working solution

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

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

From liach at openjdk.org  Thu Jun  5 09:25:35 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Jun 2025 09:25:35 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens
In-Reply-To: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
Message-ID: <I76DIn_uy0FZM6kmFZ_3bCR9CSAAycWYH7AbF3qliQ0=.3a5c4a5f-0dd2-4d2e-af92-23049ddf703e@github.com>

On Mon, 2 Jun 2025 11:54:10 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
> 
> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.

test/lib/jdk/test/lib/process/OutputBuffer.java line 150:

> 148:       this.p = p;
> 149:       logProgress("Gathering output");
> 150:       boolean verbose = Boolean.valueOf(System.getProperty("outputanalyzer.verbose", "false"));

Suggestion:

      boolean verbose = Boolean.getBoolean("outputanalyzer.verbose");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2121483594

From egahlin at openjdk.org  Thu Jun  5 09:26:13 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 09:26:13 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v7]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <nf8lATfmGhbu9fh-ojvo7nnxJnONoa42lBlCJxTwLLc=.5fed0134-cff8-46d4-9ebd-0c14425801ba@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Use offer method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/8259ff41..7f26f172

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

  Stats: 570 lines in 10 files changed: 455 ins; 88 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

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

From epeter at openjdk.org  Thu Jun  5 09:26:59 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 5 Jun 2025 09:26:59 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v7]
In-Reply-To: <dCstHcUFS9A79fKEf3RWnPrxvnzKjyVfbBzyT_iyzYo=.19255391-54fb-445e-b7e8-faf016e8a79f@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <dCstHcUFS9A79fKEf3RWnPrxvnzKjyVfbBzyT_iyzYo=.19255391-54fb-445e-b7e8-faf016e8a79f@github.com>
Message-ID: <jc11aMooMRS54e6I3rd0HyobUW38VG_SbP60BoHUu48=.6ad63307-03bb-4171-bfa6-4f40741a1fc6@github.com>

On Thu, 5 Jun 2025 09:12:30 GMT, erifan <duke at openjdk.org> wrote:

>> This patch optimizes the following patterns:
>> For integer types:
>> 
>> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> 
>> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond.
>> 
>> For float and double types:
>> 
>> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> 
>> cond can be eq or ne.
>> 
>> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`:
>> 
>> Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>> testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>> testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>> testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>> testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>> testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>> testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>> testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>> testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>> testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
>> testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
>> testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
>> testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
>> testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
>> testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
>> testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
>> testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
>> testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
>> testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
>> testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
>> testCompareLTMaskNotInt		ops/s	16721...
>
> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Addressed some review comments
>  - Merge branch 'master' into JDK-8354242
>  - Refactor the JTReg tests for compare.xor(maskAll)
>    
>    Also made a bit change to support pattern `VectorMask.fromLong()`.
>  - Merge branch 'master' into JDK-8354242
>  - Refactor code
>    
>    Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
>    optimization, making the code more modular.
>  - Merge branch 'master' into JDK-8354242
>  - Update the jtreg test
>  - Merge branch 'master' into JDK-8354242
>  - Addressed some review comments
>    
>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>    2. Improve code comments.
>  - Merge branch 'master' into JDK-8354242
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/93b141e6...ebbcc405

FYI: `BoolTest::negate` already does what you want: `mask negate( ) const { return mask(_test^4); }`
I think you should use that instead :)

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

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

From duke at openjdk.org  Thu Jun  5 09:27:03 2025
From: duke at openjdk.org (erifan)
Date: Thu, 5 Jun 2025 09:27:03 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v6]
In-Reply-To: <Di5SQQr4tO4H1VnO-GY1n8JLFtOcH3FID9sGvlRnF1Y=.04e918b6-2efb-426e-9d38-281c08ddc7d7@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <oDd6wkHsAQU3IUV3qCvjtqZ8BSHt7Qq2sx0Yy0Q8onc=.8e7db79c-15a5-4151-ac60-73f114433383@github.com>
 <Di5SQQr4tO4H1VnO-GY1n8JLFtOcH3FID9sGvlRnF1Y=.04e918b6-2efb-426e-9d38-281c08ddc7d7@github.com>
Message-ID: <ZmAUXg0b54Ua_suaNFovehG4NdgHINNjovFHAEzq2NY=.fed61067-fe6b-4875-b24a-ce5702db0c49@github.com>

On Wed, 28 May 2025 12:18:15 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Refactor the JTReg tests for compare.xor(maskAll)
>>    
>>    Also made a bit change to support pattern `VectorMask.fromLong()`.
>>  - Merge branch 'master' into JDK-8354242
>>  - Refactor code
>>    
>>    Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this
>>    optimization, making the code more modular.
>>  - Merge branch 'master' into JDK-8354242
>>  - Update the jtreg test
>>  - Merge branch 'master' into JDK-8354242
>>  - Addressed some review comments
>>    
>>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>>    2. Improve code comments.
>>  - Merge branch 'master' into JDK-8354242
>>  - Merge branch 'master' into JDK-8354242
>>  - 8354242: VectorAPI: combine vector not operation with compare
>>    
>>    This patch optimizes the following patterns:
>>    For integer types:
>>    ```
>>    (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>        => (VectorMaskCmp src1 src2 ncond)
>>    ```
>>    cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
>>    negative comparison of cond.
>>    
>>    For float and double types:
>>    ```
>>    (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>        => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>>    ```
>>    cond can be eq or ne.
>>    
>>    Benchmarks on Nvidia Grace machine with 128-bit SVE2:
>>    With option `-XX:UseSVE=2`:
>>    ```
>>    Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>>    testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>>    testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>>    testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>>    testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>>    testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>>    testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>>    testCompareGEMaskNotByte	ops/s	7907615.16	4...
>
> src/hotspot/share/opto/vectornode.cpp line 2251:
> 
>> 2249:                                       predicate_node, vt);
>> 2250:   if (vmcast_vt != nullptr) {
>> 2251:     // We optimized out an VectorMaskCast, and in order to ensure type
> 
> Suggestion:
> 
>     // We optimized out a VectorMaskCast, and in order to ensure type

Done.

> src/hotspot/share/opto/vectornode.cpp line 2253:
> 
>> 2251:     // We optimized out an VectorMaskCast, and in order to ensure type
>> 2252:     // correctness, we need to regenerate one. VectorMaskCast will be encoded as
>> 2253:     // empty for types with the same size.
> 
> Suggestion:
> 
>     // a no-op (identity function) for types with the same size.
> 
> Or what do you mean by "empty"? `TOP`? All zeros?

I mean `no-op`. Done, thanks.

> test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 96:
> 
>> 94:         Generator<Long> lGen = RD.uniformLongs(Long.MIN_VALUE, Long.MAX_VALUE);
>> 95:         Generator<Float> fGen = RD.uniformFloats(Float.MIN_VALUE, Float.MAX_VALUE);
>> 96:         Generator<Double> dGen = RD.uniformDoubles(Double.MIN_VALUE, Double.MAX_VALUE);
> 
> Are you sure you only want to draw from the uniform distribution?
> If you don't super care about the distribution, please just take `RD.ints/longs/floats/doubles()`.
> That way, you get all sorts of distributions, and also some that include NaN values etc. I think that would be important for your float cmp cases, no?

For float and double, we have to use the uniform distribution, because we have to make sure `NAN` is not generated. I added some comments about the reasons.

For other types, changed to use `RD.ints/longs`.

We have covered the special cases like +/- Inf, NaN.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2128376851
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2128378888
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2128375032

From duke at openjdk.org  Thu Jun  5 09:27:04 2025
From: duke at openjdk.org (erifan)
Date: Thu, 5 Jun 2025 09:27:04 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v6]
In-Reply-To: <9u6hJ-WgnHLMaYBa8ViRdpUZY-bI2wOk-TCRKWJJdqk=.b3303f1f-da3b-4c2e-8f0c-a2e16ba9688e@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <oDd6wkHsAQU3IUV3qCvjtqZ8BSHt7Qq2sx0Yy0Q8onc=.8e7db79c-15a5-4151-ac60-73f114433383@github.com>
 <Di5SQQr4tO4H1VnO-GY1n8JLFtOcH3FID9sGvlRnF1Y=.04e918b6-2efb-426e-9d38-281c08ddc7d7@github.com>
 <9u6hJ-WgnHLMaYBa8ViRdpUZY-bI2wOk-TCRKWJJdqk=.b3303f1f-da3b-4c2e-8f0c-a2e16ba9688e@github.com>
Message-ID: <xUtX13MnmDpI2_OOKm5UgZTgBZ1SjLE06VCMwdu21zY=.18d29d37-b3c4-49df-a457-74991f66de31@github.com>

On Wed, 28 May 2025 12:28:20 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 237:
>> 
>>> 235:     // Byte tests
>>> 236:     @Test
>>> 237:     @IR(counts = { IRNode.XOR_V_MASK, "= 0", IRNode.XOR_VB, "= 0" },
>> 
>> Could you still assert the presence of some other vectors, just to make sure we are indeed getting vectors here?
>
> Not testing for any present vectors makes me a little nervous: what if we just don't get any vectors because inlining fails or something else silly happens?

Done.

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

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

From duke at openjdk.org  Thu Jun  5 09:27:05 2025
From: duke at openjdk.org (erifan)
Date: Thu, 5 Jun 2025 09:27:05 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v6]
In-Reply-To: <PSAOxtbUtgWE5qIjFqSrfKkr40Ig4grY7-GUVB3NRDE=.3047e122-7362-48bf-b428-4c9577bc9f6f@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <oDd6wkHsAQU3IUV3qCvjtqZ8BSHt7Qq2sx0Yy0Q8onc=.8e7db79c-15a5-4151-ac60-73f114433383@github.com>
 <Di5SQQr4tO4H1VnO-GY1n8JLFtOcH3FID9sGvlRnF1Y=.04e918b6-2efb-426e-9d38-281c08ddc7d7@github.com>
 <PSAOxtbUtgWE5qIjFqSrfKkr40Ig4grY7-GUVB3NRDE=.3047e122-7362-48bf-b428-4c9577bc9f6f@github.com>
Message-ID: <dE1sMV9Eg6kI-jfzpQ5A_NlGgNe2AIdSQH3gfjiVR3E=.2418d1a0-5503-4e08-baec-124d30e3aef2@github.com>

On Thu, 29 May 2025 01:44:49 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/jdk/incubator/vector/MaskCompareNotBenchmark.java line 49:
>> 
>>> 47:     private static final VectorSpecies<Long> L_SPECIES = LongVector.SPECIES_MAX;
>>> 48:     private static final VectorSpecies<Float> F_SPECIES = FloatVector.SPECIES_MAX;
>>> 49:     private static final VectorSpecies<Double> D_SPECIES = DoubleVector.SPECIES_MAX;
>> 
>> Are you taking `SPECIES_MAX` on purpose here, or could we take `SPECIES_PREFERRED` instead?
>> @jatin-bhateja What is the best to do in these tests? I suppose best would be to test with all vector lengths...
>
> Thanks for pointing out this @eme64 ! Per my understanding, `SPECIES_MAX` is almost the same with `SPECIES_PREFERRED` in this case which are all specified to the max vector size of a hardware. Since the max vector size is different on different architectures, not all vector lengths are supported to be intrinsified on a specified architecture like AArch64, especially the SVE arch with different vector register size. Hence, just testing the max species makes sense to me as this is a mid-end common transformation.

Changed to use `ofLargestShape()` because on x64 the max vector length is related to data types.

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

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

From alanb at openjdk.org  Thu Jun  5 09:28:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:28:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v7]
In-Reply-To: <nf8lATfmGhbu9fh-ojvo7nnxJnONoa42lBlCJxTwLLc=.5fed0134-cff8-46d4-9ebd-0c14425801ba@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <nf8lATfmGhbu9fh-ojvo7nnxJnONoa42lBlCJxTwLLc=.5fed0134-cff8-46d4-9ebd-0c14425801ba@github.com>
Message-ID: <g4wakHQv7Fsl1YNLYTUXAPUC7WwQb7CM3wV9FrJMNYs=.b91f4a96-a4ec-4bd2-9ddc-67409d4097b4@github.com>

On Thu, 5 Jun 2025 09:26:13 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use offer method

t.txt line 1:

> 1: diff --git a/src/java.base/share/classes/java/io/FileInputStream.java b/src/java.base/share/classes/java/io/FileInputStream.java

t.txt added by mistake.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128388583

From duke at openjdk.org  Thu Jun  5 09:34:59 2025
From: duke at openjdk.org (erifan)
Date: Thu, 5 Jun 2025 09:34:59 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v7]
In-Reply-To: <jc11aMooMRS54e6I3rd0HyobUW38VG_SbP60BoHUu48=.6ad63307-03bb-4171-bfa6-4f40741a1fc6@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <dCstHcUFS9A79fKEf3RWnPrxvnzKjyVfbBzyT_iyzYo=.19255391-54fb-445e-b7e8-faf016e8a79f@github.com>
 <jc11aMooMRS54e6I3rd0HyobUW38VG_SbP60BoHUu48=.6ad63307-03bb-4171-bfa6-4f40741a1fc6@github.com>
Message-ID: <NOSjg9nd8YCpTLPchcVXO2KxOzfTmYuxaQHqZhmHGUo=.e98cf933-0c08-4761-8210-75d56ece7542@github.com>

On Thu, 5 Jun 2025 09:24:10 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> FYI: `BoolTest::negate` already does what you want: `mask negate( ) const { return mask(_test^4); }` I think you should use that instead :)

Indeed, I hadn't noticed that, thank you.

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

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

From duke at openjdk.org  Thu Jun  5 09:36:37 2025
From: duke at openjdk.org (Alice Pellegrini)
Date: Thu, 5 Jun 2025 09:36:37 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
Message-ID: <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>

> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
> 
> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.

Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print
 - Update test/lib/jdk/test/lib/process/OutputBuffer.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - Initial working solution

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25587/files
  - new: https://git.openjdk.org/jdk/pull/25587/files/db559d20..7cfbec22

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

  Stats: 20245 lines in 457 files changed: 17183 ins; 1318 del; 1744 mod
  Patch: https://git.openjdk.org/jdk/pull/25587.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25587/head:pull/25587

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

From egahlin at openjdk.org  Thu Jun  5 09:41:10 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 09:41:10 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:

 - Remove the mistakenly added file.
 - Fix whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/7f26f172..8beb194a

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

  Stats: 414 lines in 3 files changed: 0 ins; 410 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

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

From alanb at openjdk.org  Thu Jun  5 09:41:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:41:10 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
Message-ID: <APXhHhCmSmtSgE7-D_oiy7_DFNdzKqfEdkOmQUkXVMc=.e66a486a-0074-4756-a5d5-903fc4a4cbd0@github.com>

On Thu, 5 Jun 2025 09:37:45 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove the mistakenly added file.
>  - Fix whitespace

src/java.base/share/classes/java/io/FileInputStream.java line 219:

> 217:             }
> 218:         } finally {
> 219:             FileReadEvent.offer(start, path, bytesRead);

Thanks for this update, this looks much better. It think would be better again if `start = FileReadEvent.timestamp()` is moved to before the try.

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 328:

> 326:         } finally {
> 327:             long end = FileReadEvent.timestamp();
> 328:             FileReadEvent.offer(start, path, bytesRead);

I don't think "end" is needed now.

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 382:

> 380:             FileWriteEvent.offer(start, path, bytes);
> 381:         }
> 382:         return bytes;

The method returns the number of bytes written and traceImplRead uses bytesRead for the number of bytes read. So I think better to leave it as bytesWritten.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128400058
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128401565
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128406420

From egahlin at openjdk.org  Thu Jun  5 09:41:10 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 09:41:10 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <UTGl8Bkt5sB4NW77bhZVWQGE4xN7a0MCXjhVn5k_wnk=.b1ff279d-f5b4-45f3-94a7-4aad266878d1@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
 <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>
 <UTGl8Bkt5sB4NW77bhZVWQGE4xN7a0MCXjhVn5k_wnk=.b1ff279d-f5b4-45f3-94a7-4aad266878d1@github.com>
Message-ID: <h88YQpMEwvvo4z9dv7JVCWzKp6PsjSFNIXJ2ECAYQA4=.9adce128-6e5c-49f2-b9d2-21b0f2786008@github.com>

On Thu, 5 Jun 2025 00:21:45 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> We need some indication of which events are throttleable and looking at the mirror event may not work in some scenarios.
>> 
>> We need to sample the endTime, because the startTime may be several minutes in the past. We could use commit(startTime, endTime, ...) and calculate the duration inside the method, but it may be confusing because the fields in the event are startTime and duration. We would also need to calculate the duration twice, both for shouldCommit and commit.
>> 
>> When we get value types and perhaps value events, much of the ugliness of static methods could be avoided.
>
> I think we (from both the java.base and jdk.jfr perspectives) need to keep an eye on the complexity of the use sites. The new throttling stuff requires a new local variable. By itself this isn't a big deal, but there are 12 events being updated here. In addition, each requires a start, end, and duration, and clearly duration = end - start. These are all long values, and the different calls require different long values, so sooner or later somebody is going to get this wrong.
> 
> To a certain extent we can do more cleanup on the java.base side, by using things like SocketReadEvent's offer() method instead of its emit() method. Unfortunately only one site uses offer() -- NIO SocketChannelImpl -- and note that it didn't need to be updated! The other events should have something like the offer() method, which groups together the testing of shouldCommit/shouldThrottleCommit with the committing of the event. (This also should avoid recalculating the duration, but really, this is only a subtraction of two longs, so it should take only one cycle.)
> 
> But note what we're doing here is constructing an internal API within java.base, between the use sites (like java.net.Socket) and the java.base-side JFR stuff (jdk.internal.event.SocketReadEvent). Maybe after things are cleaned up and consolidated here we can see if the API between jdk.internal.event and jdk.jfr can be improved.

I updated FileRead and FileWrite to use an offer method like SocketRead and SocketWrite, reducing boilerplate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128398824

From alanb at openjdk.org  Thu Jun  5 09:41:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:41:10 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <h88YQpMEwvvo4z9dv7JVCWzKp6PsjSFNIXJ2ECAYQA4=.9adce128-6e5c-49f2-b9d2-21b0f2786008@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
 <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>
 <UTGl8Bkt5sB4NW77bhZVWQGE4xN7a0MCXjhVn5k_wnk=.b1ff279d-f5b4-45f3-94a7-4aad266878d1@github.com>
 <h88YQpMEwvvo4z9dv7JVCWzKp6PsjSFNIXJ2ECAYQA4=.9adce128-6e5c-49f2-b9d2-21b0f2786008@github.com>
Message-ID: <Zwcb_hQVZmXxEiB91eADdb60FeRk8-8g5VfbolZa1FA=.3d4e5d5b-6653-4adc-9c9d-06e06b7d2977@github.com>

On Thu, 5 Jun 2025 09:31:39 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I think we (from both the java.base and jdk.jfr perspectives) need to keep an eye on the complexity of the use sites. The new throttling stuff requires a new local variable. By itself this isn't a big deal, but there are 12 events being updated here. In addition, each requires a start, end, and duration, and clearly duration = end - start. These are all long values, and the different calls require different long values, so sooner or later somebody is going to get this wrong.
>> 
>> To a certain extent we can do more cleanup on the java.base side, by using things like SocketReadEvent's offer() method instead of its emit() method. Unfortunately only one site uses offer() -- NIO SocketChannelImpl -- and note that it didn't need to be updated! The other events should have something like the offer() method, which groups together the testing of shouldCommit/shouldThrottleCommit with the committing of the event. (This also should avoid recalculating the duration, but really, this is only a subtraction of two longs, so it should take only one cycle.)
>> 
>> But note what we're doing here is constructing an internal API within java.base, between the use sites (like java.net.Socket) and the java.base-side JFR stuff (jdk.internal.event.SocketReadEvent). Maybe after things are cleaned up and consolidated here we can see if the API between jdk.internal.event and jdk.jfr can be improved.
>
> I updated FileRead and FileWrite to use an offer method like SocketRead and SocketWrite, reducing boilerplate.

Thank you for this update, it looks much better now. I chatted briefly with Stuart yesterday and mostly agreed there would need to be some follow-up cleanup of the use-sites. Doing in now is good as it addresses our grumblings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128410969

From alanb at openjdk.org  Thu Jun  5 09:48:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:48:57 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
Message-ID: <QzDSW4zb1mvKE02K7Lqu-i0ORDvEpXM5AXglPU0MkrM=.8cb32924-10cf-4734-8bef-ca5820d47ac2@github.com>

On Thu, 5 Jun 2025 09:41:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove the mistakenly added file.
>  - Fix whitespace

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1252:

> 1250:         } finally {
> 1251:             long bytes = bytesWritten > 0 ? bytesWritten : 0;
> 1252:             FileWriteEvent.offer(start, path, bytes);

The number of bytes written is >=0, it can't be < 0, so I'm not sure why the existing code checks bytesWritten > 0.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128429546

From duke at openjdk.org  Thu Jun  5 09:51:59 2025
From: duke at openjdk.org (erifan)
Date: Thu, 5 Jun 2025 09:51:59 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v7]
In-Reply-To: <NOSjg9nd8YCpTLPchcVXO2KxOzfTmYuxaQHqZhmHGUo=.e98cf933-0c08-4761-8210-75d56ece7542@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <dCstHcUFS9A79fKEf3RWnPrxvnzKjyVfbBzyT_iyzYo=.19255391-54fb-445e-b7e8-faf016e8a79f@github.com>
 <jc11aMooMRS54e6I3rd0HyobUW38VG_SbP60BoHUu48=.6ad63307-03bb-4171-bfa6-4f40741a1fc6@github.com>
 <NOSjg9nd8YCpTLPchcVXO2KxOzfTmYuxaQHqZhmHGUo=.e98cf933-0c08-4761-8210-75d56ece7542@github.com>
Message-ID: <tLkj61MwZSaQEeLO3reAqAWfAMbs_hcR4wVXuUNpu5E=.197c558b-665f-4d7d-8f0c-97031a0ccf16@github.com>

On Thu, 5 Jun 2025 09:32:15 GMT, erifan <duke at openjdk.org> wrote:

> > FYI: `BoolTest::negate` already does what you want: `mask negate( ) const { return mask(_test^4); }` I think you should use that instead :)
> 
> Indeed, I hadn't noticed that, thank you.

Oh I think we still cannot use `BoolTest::negate`, because we cannot instantiate a `BoolTest` object with **unsigned** comparison. `BoolTest::negate` is a non-static function.

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

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

From alanb at openjdk.org  Thu Jun  5 09:54:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:54:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
Message-ID: <AbC0yTXSfxSe_gfV46sAk4L4sfP-eXuvN2j-tXYrQ18=.86ff17dc-b339-4c4f-98b5-b7c555096ce5@github.com>

On Thu, 5 Jun 2025 09:41:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove the mistakenly added file.
>  - Fix whitespace

src/jdk.jfr/share/conf/jfr/default.jfc line 845:

> 843:       <setting name="enabled" control="enable-exceptions">true</setting>
> 844:       <setting name="stackTrace">true</setting>
> 845:       <setting name="throttle" control="exceptions-throttle-rate">100/s</setting>

What was used to proposed 100/s as the default and 300/s in profile.jfc?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128442250

From egahlin at openjdk.org  Thu Jun  5 10:10:41 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 10:10:41 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/8beb194a..45adc081

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

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

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

From vyazici at openjdk.org  Thu Jun  5 10:13:24 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 5 Jun 2025 10:13:24 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v5]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Improve code style
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25544/files
  - new: https://git.openjdk.org/jdk/pull/25544/files/78e8de51..92248bb3

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

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

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

From alanb at openjdk.org  Thu Jun  5 10:37:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 10:37:53 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
Message-ID: <mIz-ZlnUCQ9vsXsA3MfLr8-GNJYsFi8Ii94b8KbiJbI=.c584134b-ade6-4e55-8649-1471b0d2e161@github.com>

On Thu, 5 Jun 2025 10:10:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

src/java.base/share/classes/java/lang/Throwable.java line 124:

> 122:      * exceptions should be traced by JFR.
> 123:      */
> 124:     static boolean jfrTracing;

Are you sure this is okay?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128525269

From egahlin at openjdk.org  Thu Jun  5 10:51:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 10:51:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <AbC0yTXSfxSe_gfV46sAk4L4sfP-eXuvN2j-tXYrQ18=.86ff17dc-b339-4c4f-98b5-b7c555096ce5@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
 <AbC0yTXSfxSe_gfV46sAk4L4sfP-eXuvN2j-tXYrQ18=.86ff17dc-b339-4c4f-98b5-b7c555096ce5@github.com>
Message-ID: <-LaEF0pmA3xzw9HcVJlYD91h2ek-nUAfB3BQ1NG--Is=.381146ec-7a22-4fc1-aa2c-032726bc134b@github.com>

On Thu, 5 Jun 2025 09:51:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove the mistakenly added file.
>>  - Fix whitespace
>
> src/jdk.jfr/share/conf/jfr/default.jfc line 845:
> 
>> 843:       <setting name="enabled" control="enable-exceptions">true</setting>
>> 844:       <setting name="stackTrace">true</setting>
>> 845:       <setting name="throttle" control="exceptions-throttle-rate">100/s</setting>
> 
> What was used to propose 100/s as the default and 300/s in profile.jfc?  Just curious if there was a benchmark or test to see the overhead.

It's hard to benchmark since it depends on the application, but we have used 150 events / second for the Object Allocation Sample event without complaints. If you divide one second by 20 ms, the previous threshold, you end up with at most 50 events / second per thread. That said, I think few applications actually have socket read/write around 20-25 ms, so I don't think we should draw too many conclusions from that.

Another way of thinking about it is that the cost of walking maximum 64 stack frames is roughly 5000 ns, so we end up with 100 * 5000 = 500 000 ns or 0.05% of CPU usage. There is also the cost of sampling, and that's why I put in the 1 ms threshold, which puts an upper bound of 1000 sampling attempts per thread.

For profile, I used the same value as Object Allocation Sample.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128549389

From pminborg at openjdk.org  Thu Jun  5 10:57:50 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Jun 2025 10:57:50 GMT
Subject: RFR: 8358426: Improve lazy computation in Locale
In-Reply-To: <ozQnpoa8ilbhpOap8qfjG0IhCu2GOX5DYE342PTSMe8=.56bb67d2-f21d-4617-9204-60f0914ad499@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
 <ozQnpoa8ilbhpOap8qfjG0IhCu2GOX5DYE342PTSMe8=.56bb67d2-f21d-4617-9204-60f0914ad499@github.com>
Message-ID: <vaojNywC8FuhQeD-YIIuzIMbflVwbf81SsTn0SdZyNk=.3aa9424d-146e-4378-a699-7a5415fb7096@github.com>

On Thu, 5 Jun 2025 00:18:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
>> 
>> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
>> 
>> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
>> 
>> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.
>
> Looks correct. Note we have a separate effort #25040 to avoid anonymous supplier classes, don't know if @minborg wishes locale to migrate to that one directly or remain on the more high-level SV.

Looks good! As @liach mentioned, there is an even better way coming, but I think it's good to do this update anyway. Here is a similar one that I am working on: https://github.com/openjdk/jdk/pull/25630

So, once we have stable field updaters, it will be almost trivial to update the code in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25646#issuecomment-2943716752

From pminborg at openjdk.org  Thu Jun  5 11:00:53 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Jun 2025 11:00:53 GMT
Subject: RFR: 8357821: Revert incorrectly named JavaLangAccess::unchecked*
 methods [v2]
In-Reply-To: <5s84AfVzajq6I_OyXi6Jt5zDt_r64OSOIvQlTouKX2k=.3650b2dd-c985-460d-b0da-7e78af6799aa@github.com>
References: <tDzMTU2VeD_fIb5s8gweKAF1fnz5p6y7kWgGkWcpMAY=.749b0bce-e6e0-490f-a6eb-f584c3f7166f@github.com>
 <5s84AfVzajq6I_OyXi6Jt5zDt_r64OSOIvQlTouKX2k=.3650b2dd-c985-460d-b0da-7e78af6799aa@github.com>
Message-ID: <gyvTy_5r71aJDntN6lZj4YeQB71-gcmlA9MaPlYyEvU=.90bf183f-ef11-446a-a394-fe4c58d6852f@github.com>

On Thu, 5 Jun 2025 06:04:49 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Reverts certain [JDK-8353197](https://bugs.openjdk.org/browse/JDK-8353197) (which implements JavaDoc improvement and precautionary naming for certain unsafe methods in `jdk.internal.access.JavaLangAccess`) changes that are found to be incorrect. See the JBS issue for details on the followed evaluation process.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add `@implSpec`

LGTM. Thank you for these updates!

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

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25545#pullrequestreview-2899838166

From alanb at openjdk.org  Thu Jun  5 11:07:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 11:07:56 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
Message-ID: <iDfQv5IiGJsRClkYco3XrTBrU1XbMUPxSXQ9YlwfA88=.5656cc2f-d519-4eab-951a-5c36babd57c0@github.com>

On Thu, 5 Jun 2025 10:10:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

The usages are much cleaner in the update so I think this all good.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25559#pullrequestreview-2899855765

From epeter at openjdk.org  Thu Jun  5 11:08:56 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 5 Jun 2025 11:08:56 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v7]
In-Reply-To: <tLkj61MwZSaQEeLO3reAqAWfAMbs_hcR4wVXuUNpu5E=.197c558b-665f-4d7d-8f0c-97031a0ccf16@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <dCstHcUFS9A79fKEf3RWnPrxvnzKjyVfbBzyT_iyzYo=.19255391-54fb-445e-b7e8-faf016e8a79f@github.com>
 <jc11aMooMRS54e6I3rd0HyobUW38VG_SbP60BoHUu48=.6ad63307-03bb-4171-bfa6-4f40741a1fc6@github.com>
 <NOSjg9nd8YCpTLPchcVXO2KxOzfTmYuxaQHqZhmHGUo=.e98cf933-0c08-4761-8210-75d56ece7542@github.com>
 <tLkj61MwZSaQEeLO3reAqAWfAMbs_hcR4wVXuUNpu5E=.197c558b-665f-4d7d-8f0c-97031a0ccf16@github.com>
Message-ID: <15TW6hiffz65NhHevPefL_6swSC07UD-GwiJ4tPDtFs=.b83081df-8abd-4756-b4e0-1d969678a0d2@github.com>

On Thu, 5 Jun 2025 09:48:46 GMT, erifan <duke at openjdk.org> wrote:

> Oh I think we still cannot use `BoolTest::negate`, because we cannot instantiate a `BoolTest` object with **unsigned** comparison. `BoolTest::negate` is a non-static function.

I see. Ok. Hmm. I still think that the logic should be in `BoolTest`, because that is where the exact implementation of the enum values is. In that context it is easier to see why `^4` does the negation. And imagine we were ever to change the enum values, then it would be harder to find your code and fix it.

Maybe it could be called `BoolTest::negate_mask(mast btm)` and explain in a comment that both signed and unsigned is supported.

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

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

From egahlin at openjdk.org  Thu Jun  5 11:10:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 11:10:54 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <mIz-ZlnUCQ9vsXsA3MfLr8-GNJYsFi8Ii94b8KbiJbI=.c584134b-ade6-4e55-8649-1471b0d2e161@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
 <mIz-ZlnUCQ9vsXsA3MfLr8-GNJYsFi8Ii94b8KbiJbI=.c584134b-ade6-4e55-8649-1471b0d2e161@github.com>
Message-ID: <dk_r3oQg_7Ir8nrdVEVm3K3iJ8JX5GM6Bx9iC8k7jXc=.35d39c84-62a2-474a-9c3d-8496474dddee@github.com>

On Thu, 5 Jun 2025 10:35:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code
>
> src/java.base/share/classes/java/lang/Throwable.java line 124:
> 
>> 122:      * exceptions should be traced by JFR.
>> 123:      */
>> 124:     static boolean jfrTracing;
> 
> Are you sure this is okay?

When JFR starts the JVM is brought to safepoint so the whole heap becomes visible. We have used it for socket events without any issues.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128580995

From egahlin at openjdk.org  Thu Jun  5 11:20:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 11:20:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
Message-ID: <FjjoB-kxB5mI8i2jb_jxw9kkTbwzudcRZnmXQmdWdms=.4446bbc6-7c65-4200-8fd8-9660b7dc30cb@github.com>

On Thu, 5 Jun 2025 10:10:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

Thanks for the reviews, the offer methods turned out nicely.

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

PR Comment: https://git.openjdk.org/jdk/pull/25559#issuecomment-2943787262

From mgronlun at openjdk.org  Thu Jun  5 11:35:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 5 Jun 2025 11:35:53 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
Message-ID: <gn5HwfhUBgCGFVHOTLTYdpOyCN1GJ2_cJtAmKGIsiBI=.7a0fd2dd-0584-4b56-a15b-29dcf16c7b7d@github.com>

On Thu, 5 Jun 2025 10:10:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25559#pullrequestreview-2899934064

From egahlin at openjdk.org  Thu Jun  5 11:39:01 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 11:39:01 GMT
Subject: Integrated: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <AhEyXqirLtAgGs8Pkoa2uv6V1EyWqdENXIwyjcE_lxY=.957d323b-e3cd-413f-934d-e183bf6b43e5@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: eb770a06
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb770a060ad86d69b38df7d11622e9e25a528e1d
Stats:     1346 lines in 37 files changed: 1056 ins; 174 del; 116 mod

8351594: JFR: Rate-limited sampling of Java events

Reviewed-by: mgronlun, alanb

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

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

From alanb at openjdk.org  Thu Jun  5 11:51:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 11:51:52 GMT
Subject: RFR: 8358633 : Test
 ThreadPoolExecutorTest::testTimedInvokeAnyNullTimeUnit is broken by
 JDK-8347491
In-Reply-To: <ZDn_Lzo1bgeuvKaTALiP3aD8Cq3ro2Wg9S0YqyD4Owc=.b09b622d-ac64-4baa-b1bb-29dfde351f0c@github.com>
References: <ZDn_Lzo1bgeuvKaTALiP3aD8Cq3ro2Wg9S0YqyD4Owc=.b09b622d-ac64-4baa-b1bb-29dfde351f0c@github.com>
Message-ID: <wbqiHOCvTkxAmy4izL627lXrvf8pa0jXEEnQDQVUKrU=.eb92b9bf-d6f6-41d4-a0cc-f40e70271c99@github.com>

On Thu, 5 Jun 2025 07:47:17 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> It's too fragile to depend on generated NPE messages

Dropping checking the message detail okay for now to remove the noise.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25655#pullrequestreview-2899992391

From duke at openjdk.org  Thu Jun  5 11:52:51 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 5 Jun 2025 11:52:51 GMT
Subject: RFR: 8358426: Improve lazy computation in Locale
In-Reply-To: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
Message-ID: <iAFbT1HUh2ZRo1jPev8CYqOqlPqjuQYBV_ygHiwLbnw=.319bfb7b-5238-4f55-a356-100ac3d7a5e1@github.com>

On Wed, 4 Jun 2025 21:20:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
> 
> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
> 
> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
> 
> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.

src/java.base/share/classes/java/util/Locale.java line 1269:

> 1267:     public static String[] getISOCountries() {
> 1268:         String[] countries = ISO_3166_1_ALPHA2.get();
> 1269:         return Arrays.copyOf(countries, countries.length);

what about `return ISO_3166_1_ALPHA2.get().clone();`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25646#discussion_r2128662123

From duke at openjdk.org  Thu Jun  5 11:57:52 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 5 Jun 2025 11:57:52 GMT
Subject: RFR: 8358426: Improve lazy computation in Locale
In-Reply-To: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
Message-ID: <DpPjrOn2LEjt7l1xS0feNt3HiRtfMxtIm3AkdnuA55I=.015fc545-2703-4c44-bd01-d3689d6c94b6@github.com>

On Wed, 4 Jun 2025 21:20:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
> 
> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
> 
> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
> 
> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.

src/java.base/share/classes/java/util/Locale.java line 2578:

> 2576:                     return Set.of(LocaleISOData.ISO3166_3);
> 2577:                 }
> 2578:             });

What about moving these four stable suppliers and `getISO2Table` to LocaleISOData to shrink size of Locale.java?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25646#discussion_r2128672698

From vklang at openjdk.org  Thu Jun  5 12:07:56 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 5 Jun 2025 12:07:56 GMT
Subject: Integrated: 8358633 : Test
 ThreadPoolExecutorTest::testTimedInvokeAnyNullTimeUnit is broken by
 JDK-8347491
In-Reply-To: <ZDn_Lzo1bgeuvKaTALiP3aD8Cq3ro2Wg9S0YqyD4Owc=.b09b622d-ac64-4baa-b1bb-29dfde351f0c@github.com>
References: <ZDn_Lzo1bgeuvKaTALiP3aD8Cq3ro2Wg9S0YqyD4Owc=.b09b622d-ac64-4baa-b1bb-29dfde351f0c@github.com>
Message-ID: <oIKl1HGprCbIFO6ZCaY4StLQbd37XGfnczhThCWe-cw=.71a4d6c8-0fb3-4664-8f20-0ac7bf11b379@github.com>

On Thu, 5 Jun 2025 07:47:17 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> It's too fragile to depend on generated NPE messages

This pull request has now been integrated.

Changeset: 782bbca4
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/782bbca439cd0d6db9366b4bd8d4861b8f780203
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8358633: Test ThreadPoolExecutorTest::testTimedInvokeAnyNullTimeUnit is broken by JDK-8347491

Reviewed-by: alanb

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

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

From erikj at openjdk.org  Thu Jun  5 12:55:53 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 5 Jun 2025 12:55:53 GMT
Subject: RFR: 8358626: Emit UTF-8 CLDR resources
In-Reply-To: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
Message-ID: <yL5CuAs0Jf9FdyVFsfyUlZ1jXs7c-SG0N27bLHsZ-Yg=.19385987-17f0-4557-817e-8ba70f4ad1ca@github.com>

On Wed, 4 Jun 2025 21:54:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25648#pullrequestreview-2900205154

From pminborg at openjdk.org  Thu Jun  5 13:11:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Jun 2025 13:11:03 GMT
Subject: RFR: 8358520: Improve lazy computation in BreakIteratorResourceBundle
 and related classes
Message-ID: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>

This PR proposes to simplify lazy computation related to resource bundles. Previously, some objects were computed lazily using a double-checked locking algorithm. StableValues offers a more robust and succinct solution. 
 
 
This PR passes tier1, tier2, and tier3 on multiple platforms.

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

Commit messages:
 - Break out logic in separate methods
 - Revoke the use of immutable collections
 - Fix concurrency issues

Changes: https://git.openjdk.org/jdk/pull/25630/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25630&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358520
  Stats: 138 lines in 3 files changed: 51 ins; 73 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25630.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25630/head:pull/25630

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

From dholmes at openjdk.org  Thu Jun  5 13:13:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 5 Jun 2025 13:13:52 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
Message-ID: <9tUh13m9k4GC-CYZiu5hF1kgO_TdnN6y0TmNsc5Al-Q=.c063df53-0f61-45fd-9a42-cbea51c80e47@github.com>

On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

>> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
>> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
>> 
>> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.
>
> Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print
>  - Update test/lib/jdk/test/lib/process/OutputBuffer.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Initial working solution

I'm not sure I really understand the proposal here. To where is the output going "as it happens"? If you use OutputAnalyzer  correctly then on failure all output to stdout and stderr is printed via reportDiagnosticSummary. Could you give a concrete example of a test with a problem and how this change fixes it? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25587#issuecomment-2944254033

From duke at openjdk.org  Thu Jun  5 13:51:50 2025
From: duke at openjdk.org (Alice Pellegrini)
Date: Thu, 5 Jun 2025 13:51:50 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <9tUh13m9k4GC-CYZiu5hF1kgO_TdnN6y0TmNsc5Al-Q=.c063df53-0f61-45fd-9a42-cbea51c80e47@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
 <9tUh13m9k4GC-CYZiu5hF1kgO_TdnN6y0TmNsc5Al-Q=.c063df53-0f61-45fd-9a42-cbea51c80e47@github.com>
Message-ID: <EPKVCgkLdEirDRfFjjwYZKZ_CFXVvrc_PLRIdDMrI60=.5f09faf1-9904-42cd-8f13-0f1bcc3f7df5@github.com>

On Thu, 5 Jun 2025 13:11:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> To where is the output going "as it happens"?

If the `outputanalyzer.verbose` flag is set, the output is going to be printed to the console, in addition to being stored in the buffer

> If you use OutputAnalyzer correctly then on failure all output to stdout and stderr is printed via reportDiagnosticSummary. Could you give a concrete example of a test with a problem and how this change fixes it?

As far as I understand, the creator of the issue would like debugging to be easier; they'd like, while debugging (so having paused) the execution of a test, to be able to see the output of whatever tool is wrapper by `OutputBuffer` in the console, **before** hitting the failure, looking at the output so far in the console, while being able to examine the state of the program being debugged.

As far as an example, I defer to the poster @mpdonova in case they have a more concrete example.

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

PR Comment: https://git.openjdk.org/jdk/pull/25587#issuecomment-2944467386

From mdonovan at openjdk.org  Thu Jun  5 15:00:56 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 5 Jun 2025 15:00:56 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
Message-ID: <NBeas7VSHxEynwU9LXuGy-p9Lg9Tm5I9auSaHBExzRA=.effd0ad3-a5f2-4049-b4df-49030a0502ef@github.com>

On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

>> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
>> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
>> 
>> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.
>
> Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print
>  - Update test/lib/jdk/test/lib/process/OutputBuffer.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Initial working solution

test/lib/jdk/test/lib/process/OutputBuffer.java line 150:

> 148:       this.p = p;
> 149:       logProgress("Gathering output");
> 150:       boolean verbose = Boolean.getBoolean("outputanalyzer.verbose");

Putting a system property at this level of the code kind of hides the functionality.

An alternative solution would be to have `OutputAnalyzer` constructor(s) that takes a boolean argument. That boolean could be set as needed by individual tests using the `test.debug` property already used by a lot of tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2129066907

From nbenalla at openjdk.org  Thu Jun  5 16:03:58 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 5 Jun 2025 16:03:58 GMT
Subject: Integrated: 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: <-TeQIT9Gmt8CLUcMmPfOQzcPTIGyMpqqVsuEloBx6x8=.55986278-6168-4eff-9784-d91ed7768650@github.com>

On Fri, 2 May 2025 14:48:01 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Get JDK 26 underway.

This pull request has now been integrated.

Changeset: af87035b
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af87035b713f8bfe05a007a4d4670cefc6a6aaf2
Stats:     1830 lines in 60 files changed: 1740 ins; 16 del; 74 mod

8355746: Start of release updates for JDK 26
8355748: Add SourceVersion.RELEASE_26
8355751: Add source 26 and target 26 to javac

Co-authored-by: Joe Darcy <darcy at openjdk.org>
Reviewed-by: iris, coleenp, darcy

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

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

From mullan at openjdk.org  Thu Jun  5 17:47:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 5 Jun 2025 17:47:54 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
Message-ID: <s3KKr3corBQNC4HO3LqGCPCvoEMf45X3Q3ch3aUCAE0=.86e1d246-19c1-4222-971f-50f2a96cda1f@github.com>

On Wed, 14 May 2025 18:16:13 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
>> 
>> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the test run on TLSv1.3

Some initial comments.

src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 264:

> 262:      * the peer (if any).
> 263:      *
> 264:      * @since 1.5

I would remove the `@since 1.5` from these methods. It isn't relevant anymore since this is an internal class and that version is no longer supported. That version info is in the `X509ExtendedKeyManager` API which is sufficient.

src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 395:

> 393:                 if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
> 394:                     SSLLogger.fine("Ignore alias " + alias +
> 395:                             ": certificate list does not conform to " +

suggest saying "certificate chain" not "certificate list".

test/lib/jdk/test/lib/security/CertificateBuilder.java line 244:

> 242:      * @throws IOException if an encoding error occurs.
> 243:      */
> 244:     public CertificateBuilder addSubjectAltNameIPExt(List<String> IPAddresses)

variables usually start with lower case letter, so suggest `ipAddresses`

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

PR Review: https://git.openjdk.org/jdk/pull/25016#pullrequestreview-2900744862
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2129536065
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2129556680
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2129090967

From naoto at openjdk.org  Thu Jun  5 18:30:40 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Jun 2025 18:30:40 GMT
Subject: RFR: 8358626: Emit UTF-8 CLDR resources [v2]
In-Reply-To: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
Message-ID: <P7k7-80mHzOV334m1nbODa3b7hIAKEPd1ftRJNytXFQ=.b6f36e21-6ee4-44ac-95ad-2e5275d610dc@github.com>

> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  java.base/Gensrc.gmk comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25648/files
  - new: https://git.openjdk.org/jdk/pull/25648/files/a5b1c576..5f87c71e

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

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

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

From naoto at openjdk.org  Thu Jun  5 18:30:40 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Jun 2025 18:30:40 GMT
Subject: RFR: 8358626: Emit UTF-8 CLDR resources
In-Reply-To: <HI4ELhcHNrZgg7rBbIQXzzvU3UjbiVp5xoYBYcJpofw=.9acdbaf6-52a2-4939-8aff-15b1b1aed792@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
 <HI4ELhcHNrZgg7rBbIQXzzvU3UjbiVp5xoYBYcJpofw=.9acdbaf6-52a2-4939-8aff-15b1b1aed792@github.com>
Message-ID: <Y8UxzwkN512bgnQVMyaOMYgjfCQ6mSHESmnVmIBVj7M=.0a746085-fe51-430a-a14c-7bac09303869@github.com>

On Thu, 5 Jun 2025 01:42:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)
>
> Looks like this PR did not send out the email in the first place, I am leaving a comment to kick the bot

> @naotoj, shall we add this note as a comment to places where `-utf8` is added?

Good point. Added.

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

PR Comment: https://git.openjdk.org/jdk/pull/25648#issuecomment-2945607754

From vlivanov at openjdk.org  Thu Jun  5 18:35:57 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 5 Jun 2025 18:35:57 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v9]
In-Reply-To: <fxvzcTxFkifYc-6plgOoHsjPY2uLdL3S9I5Y5e9OAbw=.17f863fb-7573-4ca3-a48a-2f067a6f11d6@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <fxvzcTxFkifYc-6plgOoHsjPY2uLdL3S9I5Y5e9OAbw=.17f863fb-7573-4ca3-a48a-2f067a6f11d6@github.com>
Message-ID: <cDDFM4-XMPhwK8RvEGd-TJR6pNGJG9axYjGhwBVu4lA=.5dc0ed91-bbac-4d7e-af03-b5fc324aa66d@github.com>

On Thu, 5 Jun 2025 08:42:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change which adds a native method providing the
>> implementation of Reference::get.  Referece::get is an intrinsic candidate, so
>> this native method implementation is only used when the intrinsic is not.
>> 
>> Currently there is intrinsic support by the interpreter, C1, C2, and graal,
>> which are always used.  With this change we can later remove all the
>> per-platform interpreter intrinsic implementations, and might also remove the
>> C1 intrinsic implementation.
>> 
>> Testing:
>> (1) mach5 tier1-6 normal (so using all the existing intrinsics).
>> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comment alignment

Marked as reviewed by vlivanov (Reviewer).

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

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

From jlu at openjdk.org  Thu Jun  5 18:37:51 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 5 Jun 2025 18:37:51 GMT
Subject: RFR: 8358426: Improve lazy computation in Locale
In-Reply-To: <iAFbT1HUh2ZRo1jPev8CYqOqlPqjuQYBV_ygHiwLbnw=.319bfb7b-5238-4f55-a356-100ac3d7a5e1@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
 <iAFbT1HUh2ZRo1jPev8CYqOqlPqjuQYBV_ygHiwLbnw=.319bfb7b-5238-4f55-a356-100ac3d7a5e1@github.com>
Message-ID: <EnQWlIt1AVWKfSx9hm64Mdl4x8n3NwpAypP1-AjhR3s=.bf69ae0e-fcc8-435b-9830-4e75155ad9ef@github.com>

On Thu, 5 Jun 2025 11:50:01 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
>> 
>> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
>> 
>> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
>> 
>> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.
>
> src/java.base/share/classes/java/util/Locale.java line 1269:
> 
>> 1267:     public static String[] getISOCountries() {
>> 1268:         String[] countries = ISO_3166_1_ALPHA2.get();
>> 1269:         return Arrays.copyOf(countries, countries.length);
> 
> what about `return ISO_3166_1_ALPHA2.get().clone();`

`clone` is more concise, but I think I prefer the explicitness of `copyOf` here.

> src/java.base/share/classes/java/util/Locale.java line 2578:
> 
>> 2576:                     return Set.of(LocaleISOData.ISO3166_3);
>> 2577:                 }
>> 2578:             });
> 
> What about moving these four stable suppliers and `getISO2Table` to LocaleISOData to shrink size of Locale.java?

I like this suggestion, we can also move `getISO3Code` in addition to those you mentioned, and have all ISO resources and methods come from LocaleISOData. @naotoj, would you be in favor of this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25646#discussion_r2129762095
PR Review Comment: https://git.openjdk.org/jdk/pull/25646#discussion_r2129762038

From naoto at openjdk.org  Thu Jun  5 18:37:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Jun 2025 18:37:52 GMT
Subject: RFR: 8358426: Improve lazy computation in Locale
In-Reply-To: <EnQWlIt1AVWKfSx9hm64Mdl4x8n3NwpAypP1-AjhR3s=.bf69ae0e-fcc8-435b-9830-4e75155ad9ef@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
 <iAFbT1HUh2ZRo1jPev8CYqOqlPqjuQYBV_ygHiwLbnw=.319bfb7b-5238-4f55-a356-100ac3d7a5e1@github.com>
 <EnQWlIt1AVWKfSx9hm64Mdl4x8n3NwpAypP1-AjhR3s=.bf69ae0e-fcc8-435b-9830-4e75155ad9ef@github.com>
Message-ID: <jZ6bNIBSNkE7s1GHmJ8wat7XdZzP7g5Enx5fLUiayhs=.0eed7199-7282-4806-8741-29a39756df09@github.com>

On Thu, 5 Jun 2025 18:32:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Locale.java line 2578:
>> 
>>> 2576:                     return Set.of(LocaleISOData.ISO3166_3);
>>> 2577:                 }
>>> 2578:             });
>> 
>> What about moving these four stable suppliers and `getISO2Table` to LocaleISOData to shrink size of Locale.java?
>
> I like this suggestion, we can also move `getISO3Code` in addition to those you mentioned, and have all ISO resources and methods come from LocaleISOData. @naotoj, would you be in favor of this?

I agree, that would be more straightforward. Thanks for the suggestion!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25646#discussion_r2129770483

From naoto at openjdk.org  Thu Jun  5 18:57:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Jun 2025 18:57:50 GMT
Subject: RFR: 8358520: Improve lazy computation in
 BreakIteratorResourceBundle and related classes
In-Reply-To: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
References: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
Message-ID: <FLTgBhIXBlLYu3dsr6jL9AILgfvcgXEPzvFAQC4x3t0=.df00f72f-19c4-4979-9b44-df7f2cd57f23@github.com>

On Tue, 3 Jun 2025 20:14:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to simplify lazy computation related to resource bundles. Previously, some objects were computed lazily using a double-checked locking algorithm. StableValues offers a more robust and succinct solution. 
>  
>  
> This PR passes tier1, tier2, and tier3 on multiple platforms.

Looks good and clean. Thanks for the refactoring, Per!

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25630#pullrequestreview-2901743240

From pminborg at openjdk.org  Thu Jun  5 19:05:34 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Jun 2025 19:05:34 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v8]
In-Reply-To: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
Message-ID: <Q-OG1bF1rYlzzItZwo-j89AhpuT0S8FU6S4px8FDQoU=.1a93d2b6-4638-4374-b0e8-dd32afd38dc9@github.com>

> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
> 
> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
> 
> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
> 
> This PR passes tier1, tier2, and tier3 on multiple platforms.

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

  Use a fixed threashold for fill

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25383/files
  - new: https://git.openjdk.org/jdk/pull/25383/files/e9e8d15e..0da4c0be

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

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

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

From duke at openjdk.org  Thu Jun  5 19:49:09 2025
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Thu, 5 Jun 2025 19:49:09 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11]
In-Reply-To: <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
Message-ID: <olgGqmHRPSIQCHTonjvX1dY4tgtzVuBBAqNvZjFhTLI=.8bdc466b-de3d-4c1e-bebb-1b9e47216192@github.com>

On Sun, 22 Oct 2023 17:26:52 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> * improved  mixed insertion sort (makes whole sorting faster)
>> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n)
>> * improved merging sort for almost sorted data
>> * optimized parallel sorting
>> * improved step for pivot candidates and pivot partitioning
>> * extended existing tests
>> * added benchmarking JMH tests
>> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap
>> 
>> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938
>
> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @SuppressWarnings (serial)

keep alive, need time to complete

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2945907790

From jlu at openjdk.org  Thu Jun  5 20:29:48 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 5 Jun 2025 20:29:48 GMT
Subject: RFR: 8358426: Improve lazy computation in Locale [v2]
In-Reply-To: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
Message-ID: <rTqhiIsNXTejPYZE2wRgQdryau_JUVOcXbkcRipfwh8=.f5f6f1a5-e528-4d27-bc3e-4cf0afc4619c@github.com>

> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
> 
> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
> 
> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
> 
> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  review - Moving all ISO resources to LocaleISOData & blessed modifier order for languageTag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25646/files
  - new: https://git.openjdk.org/jdk/pull/25646/files/b679594c..e6f3d0de

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

  Stats: 155 lines in 2 files changed: 78 ins; 63 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25646.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25646/head:pull/25646

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

From jlu at openjdk.org  Thu Jun  5 20:33:50 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 5 Jun 2025 20:33:50 GMT
Subject: RFR: 8358520: Improve lazy computation in
 BreakIteratorResourceBundle and related classes
In-Reply-To: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
References: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
Message-ID: <4NHONywQ86qHsZZDzrOLISzRXv3y4zlfaD2Ug3-GgRM=.99200218-f65a-4a51-8714-a22201cd1937@github.com>

On Tue, 3 Jun 2025 20:14:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to simplify lazy computation related to resource bundles. Previously, some objects were computed lazily using a double-checked locking algorithm. StableValues offers a more robust and succinct solution. 
>  
>  
> This PR passes tier1, tier2, and tier3 on multiple platforms.

Should we consider converting `lookup` in ParallelListResourceBundle.java to be a stable supplier of the CHM as well? Then separating the creation of the map from the insertion of parallel data.

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

PR Comment: https://git.openjdk.org/jdk/pull/25630#issuecomment-2946104521

From rgiulietti at openjdk.org  Thu Jun  5 22:11:52 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 5 Jun 2025 22:11:52 GMT
Subject: RFR: 8077587: BigInteger Roots [v15]
In-Reply-To: <8id1JAg7v3hZfZgSn2aRRA_V-mnpgMWrHD8xhwb7qMM=.f31152a1-23ac-43a5-b26c-21a5f53a1272@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <NepVSdYvhMG501_Fjefgk_ezwqK3FT2rOfIfcKiQ8O4=.1b994e30-acd2-488c-b876-ed7b95d3c4bb@github.com>
 <V4he0DJLrCSGDVnq5JmOWXh4OcEIwlUUH7R-vLno3VA=.3ba1b7e6-237d-48bf-9d2d-88b0bf830083@github.com>
 <8id1JAg7v3hZfZgSn2aRRA_V-mnpgMWrHD8xhwb7qMM=.f31152a1-23ac-43a5-b26c-21a5f53a1272@github.com>
Message-ID: <z7r4MHzpLkNN4v0-sv_vLIpPyWHNuEdaLqq272yytKg=.61fee605-01ff-4629-810c-e83959a83164@github.com>

On Sat, 17 May 2025 11:25:58 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The [Rampdown Phase One](https://openjdk.org/projects/jdk/25/) for JDK 25 is about 3 weeks from now.
>> 
>> I think it's a bit too late for API additions to be approved in due time. And even if we could rush this work for 25, it makes little sense to have this in 25 and the future one in 26. IMO, they should be released together. So this and the followup PR for `BigDecimal` will probably be integrated only in 26.
>> 
>> In other words, take your time ;-)
>
> @rgiulietti Regarding the tests for _n_-th root, the tests for `sqrt()` could be extended in order to test also `nthRoot()`.

@fabioromano1 Now that the jdk25 stabilization branch has been created, work on mainline (branch master) will no longer affect JDK25 (except for backports of bug fixes).
I'll soon start reviewing this PR based on the work of Brent and Zimmermann.

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

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-2946510626

From naoto at openjdk.org  Thu Jun  5 23:36:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Jun 2025 23:36:55 GMT
Subject: RFR: 8358520: Improve lazy computation in
 BreakIteratorResourceBundle and related classes
In-Reply-To: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
References: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
Message-ID: <QG1Di4modF9QI3eRHf9srYM0Q--2EbsVmgkOnRvVm78=.596e153b-74d9-4de8-9417-0dd966c8b945@github.com>

On Tue, 3 Jun 2025 20:14:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to simplify lazy computation related to resource bundles. Previously, some objects were computed lazily using a double-checked locking algorithm. StableValues offers a more robust and succinct solution. 
>  
>  
> This PR passes tier1, tier2, and tier3 on multiple platforms.

I am thinking about removing javatime supplementary logic altogether, including ParallelListResourceBundle. Might be good to wait for it

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

PR Comment: https://git.openjdk.org/jdk/pull/25630#issuecomment-2946933327

From jlu at openjdk.org  Thu Jun  5 23:42:50 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 5 Jun 2025 23:42:50 GMT
Subject: RFR: 8358520: Improve lazy computation in
 BreakIteratorResourceBundle and related classes
In-Reply-To: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
References: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
Message-ID: <rPykN0FzHb7YxYEupCB-3kHg6dsognSwGNe_pKr3hOg=.b5436b23-c613-42ce-bec6-3bf02c80aaa9@github.com>

On Tue, 3 Jun 2025 20:14:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to simplify lazy computation related to resource bundles. Previously, some objects were computed lazily using a double-checked locking algorithm. StableValues offers a more robust and succinct solution. 
>  
>  
> This PR passes tier1, tier2, and tier3 on multiple platforms.

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25630#pullrequestreview-2903045850

From jpai at openjdk.org  Fri Jun  6 02:10:12 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 6 Jun 2025 02:10:12 GMT
Subject: RFR: 8349914: ZipFile::entries and ZipFile::getInputStream not
 consistent with each other when there are duplicate entries
In-Reply-To: <iwdjrcKGI2cp3q-DG7LcJKvUkVmPRVSCTeEpjtmW8TU=.d14e454a-2c9a-4b6f-8ebd-32f885e61398@github.com>
References: <iwdjrcKGI2cp3q-DG7LcJKvUkVmPRVSCTeEpjtmW8TU=.d14e454a-2c9a-4b6f-8ebd-32f885e61398@github.com>
Message-ID: <qn-qUYLGi5E89E0_tRm5UQPrfqqgC4X7jw1oj-aE6z0=.38deddbf-28e1-4c4b-b5d7-9328fe198f5c@github.com>

On Wed, 4 Jun 2025 09:53:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8349914?
> 
> The ZIP specification allows for more than one entry to have the same file name (and may have different file data). In such situation, as noted in the linked issue, the `ZipFile.getInputStream(ZipEntry)` may end up picking up an "incorrect" entry content (and metadata) for the passed entry.
> 
> The commit in this PR addresses that issue by holding on to the LOC offset of the entry in the `ZipEntry` class. This way, whenever that `ZipEntry` instance is used, it knows which exact entry it represents.
> 
> A new jtreg test has been introduced to reproduce the issue and verify the fix. The new test and existing tests in tier1, tier2 and tier3 pass with this change.

Thank you Lance for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25635#issuecomment-2947807108

From jpai at openjdk.org  Fri Jun  6 02:10:12 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 6 Jun 2025 02:10:12 GMT
Subject: Integrated: 8349914: ZipFile::entries and ZipFile::getInputStream not
 consistent with each other when there are duplicate entries
In-Reply-To: <iwdjrcKGI2cp3q-DG7LcJKvUkVmPRVSCTeEpjtmW8TU=.d14e454a-2c9a-4b6f-8ebd-32f885e61398@github.com>
References: <iwdjrcKGI2cp3q-DG7LcJKvUkVmPRVSCTeEpjtmW8TU=.d14e454a-2c9a-4b6f-8ebd-32f885e61398@github.com>
Message-ID: <qhOgxC66-EDp5PPbwOuAN2mvsff6E5N7mJHsQ8_D2Nc=.92f1c402-c31a-4aea-a179-04fdf1761b72@github.com>

On Wed, 4 Jun 2025 09:53:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8349914?
> 
> The ZIP specification allows for more than one entry to have the same file name (and may have different file data). In such situation, as noted in the linked issue, the `ZipFile.getInputStream(ZipEntry)` may end up picking up an "incorrect" entry content (and metadata) for the passed entry.
> 
> The commit in this PR addresses that issue by holding on to the LOC offset of the entry in the `ZipEntry` class. This way, whenever that `ZipEntry` instance is used, it knows which exact entry it represents.
> 
> A new jtreg test has been introduced to reproduce the issue and verify the fix. The new test and existing tests in tier1, tier2 and tier3 pass with this change.

This pull request has now been integrated.

Changeset: 029e3bf8
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/029e3bf8f582f7399b80c592421b2fd72737e264
Stats:     237 lines in 3 files changed: 233 ins; 0 del; 4 mod

8349914: ZipFile::entries and ZipFile::getInputStream not consistent with each other when there are duplicate entries

Co-authored-by: Lance Andersen <lancea at openjdk.org>
Reviewed-by: lancea

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

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

From kbarrett at openjdk.org  Fri Jun  6 06:00:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 6 Jun 2025 06:00:48 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v10]
In-Reply-To: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
Message-ID: <QbYMOIfisI2YkBi0BMV0HcIbtOp-1ZsKJl-xHu3OSIk=.8d72edb7-1a0a-47c9-8716-9d6bf76adcef@github.com>

> Please review this change which adds a native method providing the
> implementation of Reference::get.  Referece::get is an intrinsic candidate, so
> this native method implementation is only used when the intrinsic is not.
> 
> Currently there is intrinsic support by the interpreter, C1, C2, and graal,
> which are always used.  With this change we can later remove all the
> per-platform interpreter intrinsic implementations, and might also remove the
> C1 intrinsic implementation.
> 
> Testing:
> (1) mach5 tier1-6 normal (so using all the existing intrinsics).
> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.

Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:

 - add pseudo-native entry for Reference.get0
 - tidy CallGenerator lookup in Compile ctor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24315/files
  - new: https://git.openjdk.org/jdk/pull/24315/files/edd4dec2..46ba079f

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

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

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

From kbarrett at openjdk.org  Fri Jun  6 06:00:49 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 6 Jun 2025 06:00:49 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v10]
In-Reply-To: <QbYMOIfisI2YkBi0BMV0HcIbtOp-1ZsKJl-xHu3OSIk=.8d72edb7-1a0a-47c9-8716-9d6bf76adcef@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <QbYMOIfisI2YkBi0BMV0HcIbtOp-1ZsKJl-xHu3OSIk=.8d72edb7-1a0a-47c9-8716-9d6bf76adcef@github.com>
Message-ID: <6VlOZeW27xLro_Q5JSZ-JdbqqAKovTTkWKlW6Vij-qk=.4aa5ec6c-5ec9-4bb5-9023-417df122e411@github.com>

On Fri, 6 Jun 2025 05:57:16 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change which adds a native method providing the
>> implementation of Reference::get.  Referece::get is an intrinsic candidate, so
>> this native method implementation is only used when the intrinsic is not.
>> 
>> Currently there is intrinsic support by the interpreter, C1, C2, and graal,
>> which are always used.  With this change we can later remove all the
>> per-platform interpreter intrinsic implementations, and might also remove the
>> C1 intrinsic implementation.
>> 
>> Testing:
>> (1) mach5 tier1-6 normal (so using all the existing intrinsics).
>> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add pseudo-native entry for Reference.get0
>  - tidy CallGenerator lookup in Compile ctor

src/hotspot/share/interpreter/templateInterpreterGenerator.cpp line 231:

> 229:   // intrinsic is disabled.
> 230:   native_method_entry(java_lang_Thread_currentThread)
> 231:   native_method_entry(java_lang_ref_reference_get0)

It turned out there was a bug lurking in the change to move the intrinsic to
Reference::get0. I had tested it with the interpreter intrinsic made
inoperative, but nearly forgot to test the normal case. It turned out that if
the interpreter intrinsic was operational but disabled then the interpreter
would hit an assert "tried to execute native method as non-native". This line
is the fix for that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2131558170

From kbarrett at openjdk.org  Fri Jun  6 06:02:59 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 6 Jun 2025 06:02:59 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v10]
In-Reply-To: <kMVnziEf9Mt5-zD1FLOauM3VcloHUVj5mkueqtCgHEQ=.01578f3b-1bde-41a4-81e5-bd7e20ebd154@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <f38TCAjHwOS64Y5LhxNVogPv8KaK2hxmMgrS_reN8DQ=.0b93f71f-7fa2-4c1f-b2b5-1cb82d130952@github.com>
 <kMVnziEf9Mt5-zD1FLOauM3VcloHUVj5mkueqtCgHEQ=.01578f3b-1bde-41a4-81e5-bd7e20ebd154@github.com>
Message-ID: <VhuiCxsgpzD3bl730QdDf93kvpCXUcq_B0fK8KFBMB0=.851fbf2f-d15c-4309-84b7-1e0e36cff0b8@github.com>

On Wed, 4 Jun 2025 17:39:55 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add pseudo-native entry for Reference.get0
>>  - tidy CallGenerator lookup in Compile ctor
>
> src/hotspot/share/opto/compile.cpp line 786:
> 
>> 784:       initial_gvn()->set_type_bottom(s);
>> 785:       verify_start(s);
>> 786:       if (method()->intrinsic_id() == vmIntrinsics::_Reference_get) {
> 
> Should we remove this now or as part of the redundant intrinsic cleanup for interpreter and c1? I see the interpreter is now kept intact.

I'm planning to remove the interpreter intrinsic as a followup. I couldn't
figure out how to hit this after making Reference::get0 the intrinsic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2131561433

From vyazici at openjdk.org  Fri Jun  6 06:28:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 06:28:55 GMT
Subject: Integrated: 8357821: Revert incorrectly named
 JavaLangAccess::unchecked* methods
In-Reply-To: <tDzMTU2VeD_fIb5s8gweKAF1fnz5p6y7kWgGkWcpMAY=.749b0bce-e6e0-490f-a6eb-f584c3f7166f@github.com>
References: <tDzMTU2VeD_fIb5s8gweKAF1fnz5p6y7kWgGkWcpMAY=.749b0bce-e6e0-490f-a6eb-f584c3f7166f@github.com>
Message-ID: <RMZFOmlhwKW6pRa9Vkc56Sg078-6bHiZz13D79uxCDk=.5bd9dd11-d643-4410-b455-4b169640dc52@github.com>

On Fri, 30 May 2025 11:57:39 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Reverts certain [JDK-8353197](https://bugs.openjdk.org/browse/JDK-8353197) (which implements JavaDoc improvement and precautionary naming for certain unsafe methods in `jdk.internal.access.JavaLangAccess`) changes that are found to be incorrect. See the JBS issue for details on the followed evaluation process.

This pull request has now been integrated.

Changeset: e918a59b
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e918a59b1dacf273620aee334517bebfb1fb1a0f
Stats:     25 lines in 12 files changed: 0 ins; 0 del; 25 mod

8357821: Revert incorrectly named JavaLangAccess::unchecked* methods

Reviewed-by: pminborg

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

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

From vyazici at openjdk.org  Fri Jun  6 07:04:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 07:04:00 GMT
Subject: RFR: 8358626: Emit UTF-8 CLDR resources [v2]
In-Reply-To: <P7k7-80mHzOV334m1nbODa3b7hIAKEPd1ftRJNytXFQ=.b6f36e21-6ee4-44ac-95ad-2e5275d610dc@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
 <P7k7-80mHzOV334m1nbODa3b7hIAKEPd1ftRJNytXFQ=.b6f36e21-6ee4-44ac-95ad-2e5275d610dc@github.com>
Message-ID: <rPnVSddeu404FxfDv58ka1gnXqAtklhkF94HHHjcZwg=.7b4bae4d-25a8-411f-8b5d-34e307dbd99d@github.com>

On Thu, 5 Jun 2025 18:30:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   java.base/Gensrc.gmk comment

Verified that
1. `TOOL_CLDRCONVERTER` points to `CLDRConverter`
2. `CLDRConverter` indeed accepts `-utf8`
3. `make/modules/java.base/Gensrc.gmk` and `make/modules/jdk.localedata/Gensrc.gmk` are the only two places where `CLDRConverter` is invoked

make/modules/jdk.localedata/Gensrc.gmk line 49:

> 47: 	    -o $(GENSRC_DIR) \
> 48: 	    -tzdatadir $(TZ_DATA_DIR) \
> 49: 	    -utf8)

@naotoj, I assume you did not add the comment to this change intentionally.

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

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25648#pullrequestreview-2903974963
PR Review Comment: https://git.openjdk.org/jdk/pull/25648#discussion_r2131625005

From duke at openjdk.org  Fri Jun  6 07:05:03 2025
From: duke at openjdk.org (erifan)
Date: Fri, 6 Jun 2025 07:05:03 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v7]
In-Reply-To: <15TW6hiffz65NhHevPefL_6swSC07UD-GwiJ4tPDtFs=.b83081df-8abd-4756-b4e0-1d969678a0d2@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <dCstHcUFS9A79fKEf3RWnPrxvnzKjyVfbBzyT_iyzYo=.19255391-54fb-445e-b7e8-faf016e8a79f@github.com>
 <jc11aMooMRS54e6I3rd0HyobUW38VG_SbP60BoHUu48=.6ad63307-03bb-4171-bfa6-4f40741a1fc6@github.com>
 <NOSjg9nd8YCpTLPchcVXO2KxOzfTmYuxaQHqZhmHGUo=.e98cf933-0c08-4761-8210-75d56ece7542@github.com>
 <tLkj61MwZSaQEeLO3reAqAWfAMbs_hcR4wVXuUNpu5E=.197c558b-665f-4d7d-8f0c-97031a0ccf16@github.com>
 <15TW6hiffz65NhHevPefL_6swSC07UD-GwiJ4tPDtFs=.b83081df-8abd-4756-b4e0-1d969678a0d2@github.com>
Message-ID: <7jhSkkRnLI9jPxnO55qlmkoJa-0By2VbkUnAFsJsFD8=.1eda80fa-424f-4766-9fb6-2cf6eb061c68@github.com>

On Thu, 5 Jun 2025 11:05:48 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> > Oh I think we still cannot use `BoolTest::negate`, because we cannot instantiate a `BoolTest` object with **unsigned** comparison. `BoolTest::negate` is a non-static function.
> 
> I see. Ok. Hmm. I still think that the logic should be in `BoolTest`, because that is where the exact implementation of the enum values is. In that context it is easier to see why `^4` does the negation. And imagine we were ever to change the enum values, then it would be harder to find your code and fix it.
> 
> Maybe it could be called `BoolTest::negate_mask(mast btm)` and explain in a comment that both signed and unsigned is supported.

Make sense, I'll update later, thanks.

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

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

From jpai at openjdk.org  Fri Jun  6 07:38:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 6 Jun 2025 07:38:59 GMT
Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP
 replies if Connection is subsequently closed
In-Reply-To: <CZdLQBjUl3_Zc7iYQy8wQu_S-oas7bAq_VJI61PV-XU=.c2be4d19-ec1a-4256-9878-19804be74566@github.com>
References: <VTKn99Us3UFmdorIHejMcIiqSL_Q_ma5Ju25cRbiOeQ=.e7655703-6c7c-487a-a98e-64339edd0197@github.com>
 <Sd-PJhZYbfwz5SXfYnDKgw8Ie_HaHQWjwBKV93teijA=.f48ec2b6-91ad-476a-88ef-81c9188d1c07@github.com>
 <WUgd6zzvGoagacI1-dQaBcJj9ebL0vpqC28b7LElMx0=.7dfee186-fcee-49cf-ad42-afca69ffd154@github.com>
 <CZdLQBjUl3_Zc7iYQy8wQu_S-oas7bAq_VJI61PV-XU=.c2be4d19-ec1a-4256-9878-19804be74566@github.com>
Message-ID: <GmzoACnFjHssYk9PzN1au9sBlSEUWrxjtCZT21Ux_Ko=.9797e06e-40b4-4d40-9836-8366e162ec39@github.com>

On Mon, 26 May 2025 16:52:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hello Daniel,
>> 
>>> I'd be tempted to say no - except that getReplyBer() will take the markers out of the queue.
>> 
>> That's correct - the change intentionally removes the lock and also lets the close/cancel markers land into the queue so that if the `getReplyBer()` is already blocked in a `take()` or `poll()` call, then it will be unblocked and if it isn't yet blocked on those calls then a subsequent call will find these markers (which are distinct for close and cancel).
>> 
>> Adding these (distinct) markers will also allow for an ordered identifiable content in the queue - some replies followed by close/cancel marker or a close/cancel marker followed by replies.
>> 
>> Additionally, the `addRequest()`, `close()` and `cancel()` methods of this `LdapRequet` get called by a single thread managed by the `Connection` class, so there isn't expected to be concurrent calls across these methods. So, I think, removing the lock and letting the (distinct) markers end up in the queue makes this code in the `LdapRequest` simpler.
>> 
>> The `getReplyBer()` the implementation polls the ordered queue, so it find all replies that have arrived before the cancel/close marker is encountered. Once it encounters those markers it can then throw the relevant exception as per its current specified behaviour.
>
>> Additionally, the addRequest(), close() and cancel() methods of this LdapRequet get called by a single thread managed by the Connection class, so there isn't expected to be concurrent calls across these methods. 
> 
> I am not seeing that - close() is called by Connection.cleanup() which seems to be callable asynchronously.

I forgot to reply here, but yes Daniel is right that the `close()` method can be called concurrently. With the current proposed change, it should be OK to have close() be invoked concurrently. The `close()/cancel()` invocation will place the respective marker in the queue and will also mark the close/cancel flag. We intentionally place the close/cancel markers in the queue so that  the `getReplyBer()` will find that marker in the right order, when it is next invoked or if it is currently blocked waiting for the next message.

Given the current expected semantics of `getReplyBer()`, we skip adding any new replies after the close/cancel markers have been placed in the queue. But that's on a best effort basis. Due to a race, if we do add replies to the queue after the close/cancel has been invoked, then it's OK because the `getReplyBer()` upon noticing the close/cancel markers first, will not process the subsequent replies in the queue. Thus it retains the current behaviour of not processing any replies after close/cancel has been noticed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25449#discussion_r2131678285

From duke at openjdk.org  Fri Jun  6 08:08:09 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 6 Jun 2025 08:08:09 GMT
Subject: RFR: 8077587: BigInteger Roots [v18]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <EPMNChZccG151dVhM5NjfVkNaHxmkBQ7uClT2JzrjBY=.57de2188-2baa-4877-b20d-2a86a3d17053@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  Update "since" version

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/fe82fa72..788a82b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=16-17

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

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

From erikj at openjdk.org  Fri Jun  6 08:51:51 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 6 Jun 2025 08:51:51 GMT
Subject: RFR: 8358626: Emit UTF-8 CLDR resources [v2]
In-Reply-To: <P7k7-80mHzOV334m1nbODa3b7hIAKEPd1ftRJNytXFQ=.b6f36e21-6ee4-44ac-95ad-2e5275d610dc@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
 <P7k7-80mHzOV334m1nbODa3b7hIAKEPd1ftRJNytXFQ=.b6f36e21-6ee4-44ac-95ad-2e5275d610dc@github.com>
Message-ID: <rY_BPR5kNLmgWgffDnAE3aLdgvcHwq4f4QqB7bfh5xI=.e84adb3e-a9ad-4698-bbd2-e92a50889b76@github.com>

On Thu, 5 Jun 2025 18:30:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   java.base/Gensrc.gmk comment

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25648#pullrequestreview-2904257875

From duke at openjdk.org  Fri Jun  6 10:38:11 2025
From: duke at openjdk.org (erifan)
Date: Fri, 6 Jun 2025 10:38:11 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v8]
In-Reply-To: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
Message-ID: <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@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 incrementally with one additional commit since the last revision:

  Support negating unsigned comparison for BoolTest::mask
  
  Added a static method `negate_mask(mask btm)` into BoolTest class to
  negate both signed and unsigned comparison.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24674/files
  - new: https://git.openjdk.org/jdk/pull/24674/files/ebbcc405..f51bf722

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

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

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

From duke at openjdk.org  Fri Jun  6 10:38:11 2025
From: duke at openjdk.org (erifan)
Date: Fri, 6 Jun 2025 10:38:11 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v7]
In-Reply-To: <7jhSkkRnLI9jPxnO55qlmkoJa-0By2VbkUnAFsJsFD8=.1eda80fa-424f-4766-9fb6-2cf6eb061c68@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <dCstHcUFS9A79fKEf3RWnPrxvnzKjyVfbBzyT_iyzYo=.19255391-54fb-445e-b7e8-faf016e8a79f@github.com>
 <jc11aMooMRS54e6I3rd0HyobUW38VG_SbP60BoHUu48=.6ad63307-03bb-4171-bfa6-4f40741a1fc6@github.com>
 <NOSjg9nd8YCpTLPchcVXO2KxOzfTmYuxaQHqZhmHGUo=.e98cf933-0c08-4761-8210-75d56ece7542@github.com>
 <tLkj61MwZSaQEeLO3reAqAWfAMbs_hcR4wVXuUNpu5E=.197c558b-665f-4d7d-8f0c-97031a0ccf16@github.com>
 <15TW6hiffz65NhHevPefL_6swSC07UD-GwiJ4tPDtFs=.b83081df-8abd-4756-b4e0-1d969678a0d2@github.com>
 <7jhSkkRnLI9jPxnO55qlmkoJa-0By2VbkUnAFsJsFD8=.1eda80fa-424f-4766-9fb6-2cf6eb061c68@github.com>
Message-ID: <_YWpW68O6gzU99lre_qtNA5zkH_fCU50rcs8Va4E5eQ=.aaa944f8-5150-405a-8534-50de7c74d762@github.com>

On Fri, 6 Jun 2025 07:01:58 GMT, erifan <duke at openjdk.org> wrote:

> > > Oh I think we still cannot use `BoolTest::negate`, because we cannot instantiate a `BoolTest` object with **unsigned** comparison. `BoolTest::negate` is a non-static function.
> > 
> > 
> > I see. Ok. Hmm. I still think that the logic should be in `BoolTest`, because that is where the exact implementation of the enum values is. In that context it is easier to see why `^4` does the negation. And imagine we were ever to change the enum values, then it would be harder to find your code and fix it.
> > Maybe it could be called `BoolTest::negate_mask(mast btm)` and explain in a comment that both signed and unsigned is supported.
> 
> Make sense, I'll update later, thanks.

@eme64 your comment is addressed, thanks for your suggestion!

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

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

From dfuchs at openjdk.org  Fri Jun  6 12:00:37 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 12:00:37 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>

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

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

 - merge latest changes from master branch
 - http3: improve H3ConnectionPoolTest.java
 - Fix snippet
 - Improve key destruction
 - merge latest changes from master branch
 - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
 - http3: refactor HTTP/3 connection pool management in a separate class
 - Ignore DestroyFailedExceptions
 - Remove outdated TODO
 - Remove outdated TODO
 - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=06
  Stats: 103750 lines in 473 files changed: 100888 ins; 1345 del; 1517 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 rgiulietti at openjdk.org  Fri Jun  6 12:32:33 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 6 Jun 2025 12:32:33 GMT
Subject: RFR: 8358540: Enhance MathUtils in view of FloatingDecimal
 enhancements [v2]
In-Reply-To: <QCVtBd071dMKhosNAlY09O1LpR6G9W4pnXpxPhwvTPA=.34e14f02-699d-49d7-8fc5-8090080aa106@github.com>
References: <QCVtBd071dMKhosNAlY09O1LpR6G9W4pnXpxPhwvTPA=.34e14f02-699d-49d7-8fc5-8090080aa106@github.com>
Message-ID: <MonA4vsHBSRJmyB9ieo6ajV77ZdMGhkX0IH8xK6KohE=.d1b8d412-1b5e-4db1-ab93-feff591121aa@github.com>

> Another step in enhancing floating-point <-> decimal conversions.

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

 - Merge branch 'master' into 8358540
 - 8358540: Enhance MathUtils in view of FloatingDecimal enhancements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25641/files
  - new: https://git.openjdk.org/jdk/pull/25641/files/555f6869..a741b105

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

  Stats: 16477 lines in 314 files changed: 14667 ins; 1100 del; 710 mod
  Patch: https://git.openjdk.org/jdk/pull/25641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25641/head:pull/25641

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

From naoto at openjdk.org  Fri Jun  6 15:18:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Jun 2025 15:18:51 GMT
Subject: RFR: 8358626: Emit UTF-8 CLDR resources [v2]
In-Reply-To: <rPnVSddeu404FxfDv58ka1gnXqAtklhkF94HHHjcZwg=.7b4bae4d-25a8-411f-8b5d-34e307dbd99d@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
 <P7k7-80mHzOV334m1nbODa3b7hIAKEPd1ftRJNytXFQ=.b6f36e21-6ee4-44ac-95ad-2e5275d610dc@github.com>
 <rPnVSddeu404FxfDv58ka1gnXqAtklhkF94HHHjcZwg=.7b4bae4d-25a8-411f-8b5d-34e307dbd99d@github.com>
Message-ID: <VWLCHwmBs2pARXfoUO1Fdeg7rkjC1H2aWFBm-uxEtD4=.38c4e650-ab9c-4421-8c4f-851c9ca6f621@github.com>

On Fri, 6 Jun 2025 06:57:20 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   java.base/Gensrc.gmk comment
>
> make/modules/jdk.localedata/Gensrc.gmk line 49:
> 
>> 47: 	    -o $(GENSRC_DIR) \
>> 48: 	    -tzdatadir $(TZ_DATA_DIR) \
>> 49: 	    -utf8)
> 
> @naotoj, I assume you did not add the comment to this change intentionally.

Yes, that was intentional. It seems apparent that `jdk.localedata` contains resources in non-Latin1 characters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25648#discussion_r2132387343

From naoto at openjdk.org  Fri Jun  6 15:29:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Jun 2025 15:29:53 GMT
Subject: RFR: 8358426: Improve lazy computation in Locale [v2]
In-Reply-To: <rTqhiIsNXTejPYZE2wRgQdryau_JUVOcXbkcRipfwh8=.f5f6f1a5-e528-4d27-bc3e-4cf0afc4619c@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
 <rTqhiIsNXTejPYZE2wRgQdryau_JUVOcXbkcRipfwh8=.f5f6f1a5-e528-4d27-bc3e-4cf0afc4619c@github.com>
Message-ID: <ZenrQ9LYHfavgv7CKqDJB4TbHlEOJP1u0VXpLD1SZyo=.6f748062-2257-4839-9f48-d6ee1dfb9519@github.com>

On Thu, 5 Jun 2025 20:29:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
>> 
>> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
>> 
>> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
>> 
>> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review - Moving all ISO resources to LocaleISOData & blessed modifier order for languageTag

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25646#pullrequestreview-2905273821

From smarks at openjdk.org  Fri Jun  6 18:38:29 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 6 Jun 2025 18:38:29 GMT
Subject: RFR: 8358809: better link to stdin.encoding from java.lang.IO
Message-ID: <P_11GsQlp9XleS2Vfz71RjEnd-F74pyMedsh6tcViKA=.9fab378a-c18d-4801-9d04-e0ca57fbb791@github.com>

Use a link of the form `System##stdin.encoding` to link directly to the system property's description.

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

Commit messages:
 - 8358809: better link to stdin.encoding from java.lang.IO

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

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

From prr at openjdk.org  Fri Jun  6 18:41:38 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 6 Jun 2025 18:41:38 GMT
Subject: RFR: 8358731: Remove jdk.internal.access.JavaAWTAccess.java
Message-ID: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>

The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after JEP 486 and JEP 491 integration
removed use of AppContext from java/util/logging/LogManager.java.
That was the only place in the JDK that used jdk.internal.access.JavaAWTAccess.java so it can be removed.

There are 3 tests that use it (digging into internals) but those tests are pointless now that LogManager doesn't use AppContext, so they should be deleted.

Automated client tests and logging tests (JDK tier1 for the latter it seems) all pass.

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

Commit messages:
 - 8358731

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

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

From prr at openjdk.org  Fri Jun  6 18:41:38 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 6 Jun 2025 18:41:38 GMT
Subject: RFR: 8358731: Remove jdk.internal.access.JavaAWTAccess.java
In-Reply-To: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>
References: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>
Message-ID: <cL7qvjaj0zGitG3Q0-HaVVz15pPzW_COHxNX1iL3JHs=.5cb2672c-b57a-45ad-848a-4a69df509995@github.com>

On Fri, 6 Jun 2025 18:35:53 GMT, Phil Race <prr at openjdk.org> wrote:

> The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after JEP 486 and JEP 491 integration
> removed use of AppContext from java/util/logging/LogManager.java.
> That was the only place in the JDK that used jdk.internal.access.JavaAWTAccess.java so it can be removed.
> 
> There are 3 tests that use it (digging into internals) but those tests are pointless now that LogManager doesn't use AppContext, so they should be deleted.
> 
> Automated client tests and logging tests (JDK tier1 for the latter it seems) all pass.

@dfuch please review this.

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

PR Comment: https://git.openjdk.org/jdk/pull/25677#issuecomment-2950146654

From vlivanov at openjdk.org  Fri Jun  6 18:55:57 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 6 Jun 2025 18:55:57 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v10]
In-Reply-To: <QbYMOIfisI2YkBi0BMV0HcIbtOp-1ZsKJl-xHu3OSIk=.8d72edb7-1a0a-47c9-8716-9d6bf76adcef@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <QbYMOIfisI2YkBi0BMV0HcIbtOp-1ZsKJl-xHu3OSIk=.8d72edb7-1a0a-47c9-8716-9d6bf76adcef@github.com>
Message-ID: <MyjEhMe2Vo4loYOm2vryckikR05Fb7se-txLbqr7-7w=.cee39377-ae0e-4cf4-9346-d2cc07493e90@github.com>

On Fri, 6 Jun 2025 06:00:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change which adds a native method providing the
>> implementation of Reference::get.  Referece::get is an intrinsic candidate, so
>> this native method implementation is only used when the intrinsic is not.
>> 
>> Currently there is intrinsic support by the interpreter, C1, C2, and graal,
>> which are always used.  With this change we can later remove all the
>> per-platform interpreter intrinsic implementations, and might also remove the
>> C1 intrinsic implementation.
>> 
>> Testing:
>> (1) mach5 tier1-6 normal (so using all the existing intrinsics).
>> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add pseudo-native entry for Reference.get0
>  - tidy CallGenerator lookup in Compile ctor

Marked as reviewed by vlivanov (Reviewer).

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

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

From naoto at openjdk.org  Fri Jun  6 19:52:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Jun 2025 19:52:52 GMT
Subject: RFR: 8358809: better link to stdin.encoding from java.lang.IO
In-Reply-To: <P_11GsQlp9XleS2Vfz71RjEnd-F74pyMedsh6tcViKA=.9fab378a-c18d-4801-9d04-e0ca57fbb791@github.com>
References: <P_11GsQlp9XleS2Vfz71RjEnd-F74pyMedsh6tcViKA=.9fab378a-c18d-4801-9d04-e0ca57fbb791@github.com>
Message-ID: <r3BIml4Mv7rnzOJUzr7Tisi4NQMkfoXLMLU3KKOUyPg=.1b66edaf-b211-4180-80c1-c0b4eb3a9229@github.com>

On Fri, 6 Jun 2025 18:34:10 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Use a link of the form `System##stdin.encoding` to link directly to the system property's description.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25676#pullrequestreview-2906011665

From smarks at openjdk.org  Fri Jun  6 20:10:53 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 6 Jun 2025 20:10:53 GMT
Subject: Integrated: 8358809: Improve link to stdin.encoding from java.lang.IO
In-Reply-To: <P_11GsQlp9XleS2Vfz71RjEnd-F74pyMedsh6tcViKA=.9fab378a-c18d-4801-9d04-e0ca57fbb791@github.com>
References: <P_11GsQlp9XleS2Vfz71RjEnd-F74pyMedsh6tcViKA=.9fab378a-c18d-4801-9d04-e0ca57fbb791@github.com>
Message-ID: <KEQqfCBFD6n3z1tc4NDF-WHhRG4ukS13TIVJ1M98p7g=.20e07e19-914f-490e-bf8f-d6d8838121c2@github.com>

On Fri, 6 Jun 2025 18:34:10 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Use a link of the form `System##stdin.encoding` to link directly to the system property's description.

This pull request has now been integrated.

Changeset: d024f58e
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d024f58e61ec27f6c13fde5dadb95c31875815d6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8358809: Improve link to stdin.encoding from java.lang.IO

Reviewed-by: naoto

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

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

From dfuchs at openjdk.org  Fri Jun  6 21:28:49 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 21:28:49 GMT
Subject: RFR: 8358731: Remove jdk.internal.access.JavaAWTAccess.java
In-Reply-To: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>
References: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>
Message-ID: <GmfnwkItU5m1dwNNCnnNnOhExO36SJM9QNTTpoy8-xc=.f5699710-8786-44c4-a04e-9200c79fc921@github.com>

On Fri, 6 Jun 2025 18:35:53 GMT, Phil Race <prr at openjdk.org> wrote:

> The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after JEP 486 and JEP 491 integration
> removed use of AppContext from java/util/logging/LogManager.java.
> That was the only place in the JDK that used jdk.internal.access.JavaAWTAccess.java so it can be removed.
> 
> There are 3 tests that use it (digging into internals) but those tests are pointless now that LogManager doesn't use AppContext, so they should be deleted.
> 
> Automated client tests and logging tests (JDK tier1 for the latter it seems) all pass.

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25677#pullrequestreview-2906178505

From smarks at openjdk.org  Fri Jun  6 22:12:40 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 6 Jun 2025 22:12:40 GMT
Subject: [jdk25] RFR: 8358809: Improve link to stdin.encoding from java.lang.IO
Message-ID: <mvDyVbh9BdEwNyZtxgkhKSjRzKYwo-QM5Dwki9s3vdw=.340a6bf5-4bd2-4b7b-bf7c-8941cc029e20@github.com>

Hi all,

This pull request contains a backport of commit [d024f58e](https://github.com/openjdk/jdk/commit/d024f58e61ec27f6c13fde5dadb95c31875815d6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Stuart Marks on 6 Jun 2025 and was reviewed by Naoto Sato.

Thanks!

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

Commit messages:
 - Backport d024f58e61ec27f6c13fde5dadb95c31875815d6

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

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

From naoto at openjdk.org  Fri Jun  6 22:31:49 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Jun 2025 22:31:49 GMT
Subject: [jdk25] RFR: 8358809: Improve link to stdin.encoding from
 java.lang.IO
In-Reply-To: <mvDyVbh9BdEwNyZtxgkhKSjRzKYwo-QM5Dwki9s3vdw=.340a6bf5-4bd2-4b7b-bf7c-8941cc029e20@github.com>
References: <mvDyVbh9BdEwNyZtxgkhKSjRzKYwo-QM5Dwki9s3vdw=.340a6bf5-4bd2-4b7b-bf7c-8941cc029e20@github.com>
Message-ID: <6taCHZ4e7NRkQOmypwi46xbvp_6H2lcNJaW65BK4mZA=.bcc5e2e7-1393-4b77-a159-0d406ccb677a@github.com>

On Fri, 6 Jun 2025 22:07:38 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [d024f58e](https://github.com/openjdk/jdk/commit/d024f58e61ec27f6c13fde5dadb95c31875815d6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Stuart Marks on 6 Jun 2025 and was reviewed by Naoto Sato.
> 
> Thanks!

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25681#pullrequestreview-2906279687

From smarks at openjdk.org  Sat Jun  7 00:59:03 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 7 Jun 2025 00:59:03 GMT
Subject: [jdk25] RFR: 8358809: Improve link to stdin.encoding from
 java.lang.IO
In-Reply-To: <mvDyVbh9BdEwNyZtxgkhKSjRzKYwo-QM5Dwki9s3vdw=.340a6bf5-4bd2-4b7b-bf7c-8941cc029e20@github.com>
References: <mvDyVbh9BdEwNyZtxgkhKSjRzKYwo-QM5Dwki9s3vdw=.340a6bf5-4bd2-4b7b-bf7c-8941cc029e20@github.com>
Message-ID: <D145lO1F_1YtWLRNBgbfPXqmXOO9BpwRLDKhsq3g-f8=.9e785df9-a8b1-4c6d-895d-a23fae0707e7@github.com>

On Fri, 6 Jun 2025 22:07:38 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [d024f58e](https://github.com/openjdk/jdk/commit/d024f58e61ec27f6c13fde5dadb95c31875815d6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Stuart Marks on 6 Jun 2025 and was reviewed by Naoto Sato.
> 
> Thanks!

@naotoj Thanks for the reviews of the mainline bug and the backport!

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

PR Comment: https://git.openjdk.org/jdk/pull/25681#issuecomment-2951342820

From smarks at openjdk.org  Sat Jun  7 00:59:03 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 7 Jun 2025 00:59:03 GMT
Subject: [jdk25] Integrated: 8358809: Improve link to stdin.encoding from
 java.lang.IO
In-Reply-To: <mvDyVbh9BdEwNyZtxgkhKSjRzKYwo-QM5Dwki9s3vdw=.340a6bf5-4bd2-4b7b-bf7c-8941cc029e20@github.com>
References: <mvDyVbh9BdEwNyZtxgkhKSjRzKYwo-QM5Dwki9s3vdw=.340a6bf5-4bd2-4b7b-bf7c-8941cc029e20@github.com>
Message-ID: <9A3vA3KAT_4vA9J2_UogDqv1dzQ3VG56q0wgwTNkxwg=.7fecd567-7ec9-4a33-845c-89bdfaca027f@github.com>

On Fri, 6 Jun 2025 22:07:38 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [d024f58e](https://github.com/openjdk/jdk/commit/d024f58e61ec27f6c13fde5dadb95c31875815d6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Stuart Marks on 6 Jun 2025 and was reviewed by Naoto Sato.
> 
> Thanks!

This pull request has now been integrated.

Changeset: c7df72ff
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c7df72ff0f8b4e4d4560661b5fe036dc206159ba
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8358809: Improve link to stdin.encoding from java.lang.IO

Reviewed-by: naoto
Backport-of: d024f58e61ec27f6c13fde5dadb95c31875815d6

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

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

From serb at openjdk.org  Sat Jun  7 12:52:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 7 Jun 2025 12:52:51 GMT
Subject: RFR: 8358731: Remove jdk.internal.access.JavaAWTAccess.java
In-Reply-To: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>
References: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>
Message-ID: <ltbzzzMlyFCZnSbqfGDL0IOGfNIfcJY3oM9OiUyiWGY=.a2140d15-07f6-415d-8a4c-49f3398c5503@github.com>

On Fri, 6 Jun 2025 18:35:53 GMT, Phil Race <prr at openjdk.org> wrote:

> The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after JEP 486 and JEP 491 integration
> removed use of AppContext from java/util/logging/LogManager.java.
> That was the only place in the JDK that used jdk.internal.access.JavaAWTAccess.java so it can be removed.
> 
> There are 3 tests that use it (digging into internals) but those tests are pointless now that LogManager doesn't use AppContext, so they should be deleted.
> 
> Automated client tests and logging tests (JDK tier1 for the latter it seems) all pass.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25677#pullrequestreview-2907352143

From duke at openjdk.org  Sat Jun  7 17:38:52 2025
From: duke at openjdk.org (Johannes Graham)
Date: Sat, 7 Jun 2025 17:38:52 GMT
Subject: RFR: 8358426: Improve lazy computation in Locale [v2]
In-Reply-To: <rTqhiIsNXTejPYZE2wRgQdryau_JUVOcXbkcRipfwh8=.f5f6f1a5-e528-4d27-bc3e-4cf0afc4619c@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
 <rTqhiIsNXTejPYZE2wRgQdryau_JUVOcXbkcRipfwh8=.f5f6f1a5-e528-4d27-bc3e-4cf0afc4619c@github.com>
Message-ID: <nXLruLQd1Zzx4tlLaTbi6VhM9epxWMyRzGo0dTv17Rc=.d239e5e9-80db-4d3a-9cb4-0adbceb97a58@github.com>

On Thu, 5 Jun 2025 20:29:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
>> 
>> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
>> 
>> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
>> 
>> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review - Moving all ISO resources to LocaleISOData & blessed modifier order for languageTag

src/java.base/share/classes/java/util/Locale.java line 1282:

> 1280:     public static Set<String> getISOCountries(IsoCountryCode type) {
> 1281:         Objects.requireNonNull(type);
> 1282:         return switch (type) {

The body of this method could also be moved to a method in `LocaleISOData`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25646#discussion_r2134036165

From yujige at gmail.com  Sun Jun  8 05:39:39 2025
From: yujige at gmail.com (Jige Yu)
Date: Sat, 7 Jun 2025 22:39:39 -0700
Subject: [External] : Re: Should mapConcurrent() respect time order
 instead of input order?
In-Reply-To: <MW4PR10MB57749105268519A8984C7C3EFF6CA@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAKD1RYuoK07OvAn02v4qq74Q1QDfpQpf=t0J0VT-s1zi4iKRnA@mail.gmail.com>
 <MW4PR10MB5774AED3EC215ED5AB3AD52CFF62A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtLy_yC+L5+q1YOkbEvUis5LJ-tJNJDbyoptq8A=+W3eg@mail.gmail.com>
 <CAKD1RYuksGCWsqj6cnu3aoHqkzAepLeNHsGSX_nCi2QryJaGMQ@mail.gmail.com>
 <SJ0PR10MB5766DAA744887EE8B0A2B991FF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYvhpcD=yAGAvTTi+c8sdjDAi776GCPCAdvsCCVF9JQpeQ@mail.gmail.com>
 <SJ0PR10MB5766DB20AB83B1199C7987EAFF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYst6GOErvVozZ2SD6JGhTRUAugSHZFM7aY+5Je72iF3wA@mail.gmail.com>
 <MW4PR10MB57749F82094174F71CF0BB56FF6DA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYu3CUT5nOj9i-cv_n7T=FXvwBpx3BQp6px6Mk2zg6GZNA@mail.gmail.com>
 <MW4PR10MB577448E6F3C06E7A0387AFAAFF6CA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtf4K-r6X0dQZsXUcyZcNa5WLxKZy8p11R163GeLkYn5g@mail.gmail.com>
 <MW4PR10MB57749105268519A8984C7C3EFF6CA@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAKD1RYvM=BtM1mOo2+KqFZV6GTtPb6c+n7JOVSHN34SsV6=_Jw@mail.gmail.com>

Hi Viktor,

Thank you for pointing to the spec. You are absolutely right, that is the
documented behavior.

My feedback is aimed directly at questioning that specific design choice
within the specification. My perspective is that the benefit of preserving
stream ordering may be outweighed by the significant trade-offs it
introduces?namely, the potential for surprising performance behavior (like
reduced throughput or task starvation) and the loss of flexibility for
implementing common concurrent patterns like race semantics.

I understand if the design for the current release is finalized, but I
believe this feedback is relevant for the ongoing evolution of the API.

Best regards,

On Wed, Jun 4, 2025 at 11:22?AM Viktor Klang <viktor.klang at oracle.com>
wrote:

> >Ultimately, the question is whether mapConcurrent() should be optimized
> primarily for preserving input sequence, or for enabling maximum throughput
> and flexibility in concurrent scenarios, including efficient
> "first-to-finish" patterns.
>
> The answer to that is clear in the specification for the operation:
>
> ?This operation preserves the ordering of the stream.? -
> http://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Wednesday, 4 June 2025 18:18
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Should mapConcurrent() respect time order
> instead of input order?
>
> Hi Viktor,
>
> Thank you for the detailed explanation and the links to the Javadoc for
> findFirst() and limit(). You're absolutely correct in your
> characterization of these operations ? they are indeed concerned with
> encounter order, and parallel execution doesn't inherently change that
> unless the stream is explicitly unordered. I want to clarify a few of my
> points that I didn't explain clearly (see below).
>
>
> On Wed, Jun 4, 2025 at 7:38?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi Jige,
>
> First of all?you're most welcome. Thanks for your insightful questions.
>
> >*Temptation for Race Semantics:* The beauty of mapConcurrent() integrating
> with the Stream API means developers will naturally be drawn to use it for
> race-like scenarios. Operations like findFirst() or limit(N) to get the
> first few completed results are very intuitive combinations.
>
> It's important to distinguish between spatial (encounter) order and
> temporal (availability) order.
>
> If we look at `Stream::findFirst()` we see:
>
> ?Returns an Optional
> <https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/util/Optional.html> describing
> the first element of this stream, or an empty Optional if the stream is
> empty. If the stream has no encounter order, then any element may be
> returned.? -
> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html#findFirst()
>
> And if we look at `Stream::limit(long)` we see:
>
> *?While limit() is generally a cheap operation on sequential stream
> pipelines, it can be quite expensive on ordered parallel pipelines,
> especially for large values of maxSize, since limit(n) is constrained to
> return not just any n elements, but **the first n elements in the
> encounter order**. ? (emphasis mine) -
> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html#limit(long)
> <https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html#limit(long)>*
>
> So, we can conclude that "first" and "limit" are about *encounter order*,
> and we can conclude that the presence of parallel does not change that?only
> "unorderedness" *may* change that.
>
>
>
> My apologies if my previous example using findFirst() wasn't as clear as
> it could have been. I'd like to clarify how I see the interaction with
> mapConcurrent() playing out:
>
>    1.
>
>    *mapConcurrent()'s Influence on Encounter Order:* When I mentioned
>    using findFirst() (or limit()) for race semantics, the implicit
>    assumption was how mapConcurrent() would feed elements into these
>    terminal operations. The "encounter order" that findFirst() sees is
>    precisely what mapConcurrent() emits. If mapConcurrent() emits results
>    strictly according to input order, then findFirst() will respect that.
>    However, if an unordered mapConcurrent() were to emit results in their
>    temporal order of completion, then findFirst() would naturally pick
>    the first one that *actually finished*, effectively achieving a race.
>    My point is that mapConcurrent() is in a position to define the
>    encounter order that downstream operations like findFirst() will act
>    upon. The surprise isn't with findFirst()'s definition, but with how a
>    strictly ordered mapConcurrent() might prevent it from being used
>    effectively for "first-to-finish" logic.
>    2.
>
>    *The Role of findAny():* You're right that my example using
>    findFirst() was more nuanced than I intuitively assumed. A developer
>    well-versed in the Stream API nuances might indeed opt for findAny()
>    to implement race semantics, especially given its Javadoc explicitly
>    mentioning suitability for "maximal performance in parallel operations."
>    findAny() is designed to return *any* element, which aligns well with
>    picking the temporally first available result from an unordered concurrent
>    process.
>    3.
>
>    *Aligning Spec with Intuition:* My broader concern is about the
>    intuitive use of these powerful new tools. If mapConcurrent()
>    maintains strict input ordering, it's a perfectly valid and understandable
>    specification by itself. However, the potential for surprise arises when
>    developers, especially those less acquainted with every fine print of
>    stream ordering, attempt to combine mapConcurrent() with findFirst()
>    or findAny() to build common concurrent utilities like a race. They
>    might intuitively expect that "concurrent mapping" followed by "find
>    first/any" would yield the result that completes earliest. While developers
>    *should* read all related documentation, there's also a design ideal
>    where the API's behavior aligns closely with reasonable developer
>    intuition, especially for common patterns. An unordered mapConcurrent()
>    (or an option for it) would, in my view, better support this intuitive use
>    for race-like patterns. Whereas, I have my doubts that developers commonly
>    would intuitively assume a concurrent operation to stick to strict ordering
>    (it's not what we are used to in most concurrent or
>    multil-threading scenarios)
>
> Ultimately, the question is whether mapConcurrent() should be optimized
> primarily for preserving input sequence, or for enabling maximum throughput
> and flexibility in concurrent scenarios, including efficient
> "first-to-finish" patterns.
>
>
>
> >*Surprise for Race Semantics Users:* Following from the above, it could
> be surprising for developers when they realize that the inherent input
> ordering of mapConcurrent() means it's not optimized for these race
> scenarios. The expectation would be that findFirst() returns as soon as
> *any* task completes, but ordering can delay this if an earlier task (in
> input order) is slower.
>
> This should be addressed above.
>
> >*Ordering Assumption in Concurrency:* My experience is that ordering is
> not typically a default assumption when dealing with operations explicitly
> marked as "parallel" or "concurrent." For instance, Stream.forEach() on a
> parallel stream does not guarantee encounter order, presumably for
> performance reasons ? a similar trade-off to what's being discussed for
> mapConcurrent(). Developers often consult documentation for ordering
> guarantees in concurrent contexts rather than assuming them.
>
> This should also be addressed above.
>
> >*Expectation of "True" Concurrency:* When I see an API like mapConcurrent(maxConcurrency,
> mapper), my mental model is that if maxConcurrency permits, new tasks
> should be initiated as soon as a slot is free.
>
> This is interesting, because this is how mapConcurrent used to work. It
> only placed the limit of *concurrent work in progress* and not *work not
> yet possible to propagate downstream*. This was changed, because a
> delayed initial (in encounter order) item may let subsequent (completed)
> work queue up indefinitely.
>
> So in conclusion, there's still room for a different take on
> "mapConcurrentReorder" (name of course left up to the reader), and the good
> news is that such a Gatherer can be implemented, evaluated, hardened, etc
> outside of the JDK?and potentially some day something like it ends up in
> the JDK.
>
>
> Your mention of a potential mapConcurrentReorder() also brings to mind a
> thought about API consistency with existing Stream conventions. We see
> patterns like Stream.forEach() (which for parallel streams doesn't
> guarantee encounter order, prioritizing performance) versus
> Stream.forEachOrdered() (which explicitly enforces it). If mapConcurrent()
> were to follow a similar naming convention, it might suggest that the base
> mapConcurrent() itself would be the version optimized for throughput (and
> thus potentially unordered by default), while a hypothetical
> mapConcurrentOrdered() would be the variant explicitly providing the
> strict ordering guarantee. This is an observation on how naming might align
> with established JDK patterns to intuitively guide user expectations about
> the default behavior.
>
> This naturally leads to the inherent challenge in designing such an API.
> It seems we're trying to balance three desirable, but sometimes
> conflicting, goals:
>
>    1. *Strict Encounter Ordering:* Results are emitted in the same order
>    as the input elements.
>    2. *Bounded Memory Buffering:* Avoid out-of-memory errors by not
>    letting completed but un-emitted results queue up indefinitely.
>    3. *Optimized (True) Concurrency:* If maxConcurrency is set (e.g., to N),
>    the system strives to have N tasks actively running whenever there are
>    pending input elements and available concurrency slots, rather than being
>    stalled by a slow-to-complete but earlier-in-sequence task.
>
> It appears that achieving all three simultaneously is not possible, and a
> compromise must be made.
>
> From my perspective:
>
>    - Goal #2 (Bounded Memory) is non-negotiable; OOM situations are
>    generally unacceptable.
>    - Goal #3 (Optimized Concurrency) feels fundamental to an API named
>    mapConcurrent(). Users will likely expect it to maximize the
>    concurrent execution of tasks up to the specified limit. Deviations from
>    this, often necessitated by strict adherence to Goal #1, can lead to
>    surprises.
>    - Goal #1 (Strict Ordering), while a "nice-to-have" and sometimes
>    beneficial, might not always align with common developer intuition for
>    operations explicitly labeled "concurrent," especially if it compromises
>    true concurrency. As discussed, ordering can often be reintroduced by the
>    caller if specifically needed.
>
> The current implementation understandably prioritizes #1 (Ordering) and #2
> (Bounded Memory). However, this prioritization can lead to situations where
> #3 (Optimized Concurrency) is not fully realized, which can be
> counter-intuitive.
>
> I've already mentioned the race scenario. Consider another example where
> this becomes particularly evident. Imagine a scenario with a long-running
> task (e.g., for periodic monitoring) combined with a stream of other "real"
> tasks:
> Java
>
> // Main tasks
> List<Callable<Result>> realTasks = ... ;
> // A long-running monitoring task
> Callable<Void> longRunningMonitoringTask = () -> {
>     while (!allRealTasksSeemDone()) { // Simplified condition
>         System.out.println("Monitoring...");
>         Thread.sleep(5000);
>     }
>     return null;
> };
>
> Stream<Callable<?>> allTasks = Stream.concat(
>     Stream.of(longRunningMonitoringTask),
>     realTasks.stream().map(task -> (Callable<?>) task)
> );
>
> allTasks
>     .gather(Gatherers.mapConcurrent(MAX_CONCURRENCY, callable -> callable.call()))
>     .forEach(result -> { /* output results */ });
>
> The longRunningMonitoringTask would usually be the first element, with
> the current strictly ordered behavior, it would occupy one of the
> MAX_CONCURRENCY slots. and as soon as MAX_CONCURRENCY tasks are
> executed, completed or not, all subsequent realTasks (beyond the first
> one) would be starved, unable to even start until the
> longRunningMonitoringTask completes?which is *never*. This creates a
> deadlock or significant processing delay that would likely surprise a
> developer expecting tasks to proceed concurrently up to the maxConcurrency
> limit. An implementation more aligned with the "base name implies
> throughput" idea (as per the forEach analogy) would likely handle this
> more gracefully by letting tasks run truly concurrently without an implicit
> ordering dependency.
>
> This reinforces my belief that an alternative gatherer, or a default
> behavior for mapConcurrent() that prioritizes concurrency (as the name
> mapConcurrent might suggest to many, akin to forEach), could be very
> valuable. I understand this might be something that evolves outside the JDK
> initially, and I appreciate you highlighting that path.
>
> Thanks again for the continued discussion and the transparency about the
> design choices.
>
> Best regards,
>
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
>
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Wednesday, 4 June 2025 16:20
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Should mapConcurrent() respect time order
> instead of input order?
>
>
> Hi Viktor,
>
> Thank you for sharing that the general feedback on mapConcurrent() has
> been positive and for the insights into the ongoing enhancements,
> especially around interruption handling and work-in-progress tracking.
>
> To clarify my own position, I am also extremely enthusiastic about the
> mapConcurrent() API overall. It offers an elegant and straightforward way
> to manage homogenous, I/O-intensive concurrent tasks within a structured
> concurrency model, which is a significant improvement and a much-needed
> addition. My feedback on ordering is aimed at maximizing its potential.
>
> I'd like to elaborate on a few specific scenarios and expectations that
> inform my perspective on the ordering:
>
>    1.
>
>    *Temptation for Race Semantics:* The beauty of mapConcurrent() integrating
>    with the Stream API means developers will naturally be drawn to use it for
>    race-like scenarios. Operations like findFirst() or limit(N) to get
>    the first few completed results are very intuitive combinations. For
>    example:
>    Java
>
>    // Hypothetical use case: find the fastest responding service
>    Optional<Result> fastestResult = serviceUrls.stream()
>        .gather(Gatherers.mapConcurrent(MAX_CONCURRENCY, url -> fetch(url)))
>        .findFirst();
>
>    2.
>
>    *Surprise for Race Semantics Users:* Following from the above, it
>    could be surprising for developers when they realize that the inherent
>    input ordering of mapConcurrent() means it's not optimized for these
>    race scenarios. The expectation would be that findFirst() returns as
>    soon as *any* task completes, but ordering can delay this if an
>    earlier task (in input order) is slower.
>    3.
>
>    *Ordering Assumption in Concurrency:* My experience is that ordering
>    is not typically a default assumption when dealing with operations
>    explicitly marked as "parallel" or "concurrent." For instance,
>    Stream.forEach() on a parallel stream does not guarantee encounter
>    order, presumably for performance reasons ? a similar trade-off to what's
>    being discussed for mapConcurrent(). Developers often consult
>    documentation for ordering guarantees in concurrent contexts rather than
>    assuming them.
>    4.
>
>    *Expectation of "True" Concurrency:* When I see an API like mapConcurrent(maxConcurrency,
>    mapper), my mental model is that if maxConcurrency permits, new tasks
>    should be initiated as soon as a slot is free. For example, with
>    maxConcurrency=2:
>    - Task 1 starts.
>       - Task 2 starts.
>       - If Task 2 finishes while Task 1 is still running, I would expect
>       Task 3 to run concurrently alongside task 1, because the max concurrency is
>       2, not 1. The current ordered behavior, where Task 3 might have to wait for
>       Task 1 to complete before its result can be processed (even if Task 3
>       itself could have started and finished), can feel a bit counterintuitive to
>       the notion of maximizing concurrency up to the specified limit. It almost
>       feels like not a "max concurrency", but "max buffer size".
>
> These points are offered to highlight potential areas where the current
> default could lead to subtle surprises or suboptimal performance for useful
> concurrent patterns.
>
> Thanks again for the open discussion and for your work on these valuable
> additions to the JDK.
>
> Best regards,
>
> On Tue, Jun 3, 2025 at 2:13?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> The general feedback received thus far has been primarily positive. There
> have been a few behavior-related enhancements over the previews to better
> handle interruption (there's still room to improve there, as per our
> concurrent conversation) as well as some improvements to work-in-progress
> tracking.
>
> It will be interesting to see which Gatherer-based operations will be
> devised by Java developers in the future.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 2 June 2025 18:54
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Should mapConcurrent() respect time order
> instead of input order?
>
>
> Hi Viktor,
>
> Thanks for your reply and for sharing your experience regarding user
> preferences. I appreciate that perspective.
>
> You're right, if an unordered version of mapConcurrent proves to be
> widely beneficial and is implemented and adopted by the community, it could
> certainly make a strong case for future inclusion in the JDK.
>
> I wanted to clarify a nuance regarding user preference that I might not
> have articulated clearly before. If the question is simply "ordered or
> unordered?", in isolation, I can see why many, myself included, might lean
> towards "ordered" as a general preference.
>
> However, the decision becomes more complex when the associated trade-offs
> are considered. If the question were phrased more like, "Do you prefer an
> ordered mapConcurrent by default, even if it entails potential
> performance overhead and limitations for certain use cases like race() operations,
> versus an unordered version that offers higher throughput and broader
> applicability in such scenarios?" my (and perhaps others') answer might
> differ. The perceived cost versus benefit of ordering changes significantly
> when these factors are explicit.
>
> My initial suggestion stemmed from the belief that the performance and
> flexibility gains of an unordered approach for I/O-bound tasks would, in
> many practical situations, outweigh the convenience of default ordering,
> especially since ordering can be reintroduced relatively easily, and
> explicitly, when needed.
>
> Thanks again for the discussion.
>
> Best regards,
>
> On Mon, Jun 2, 2025 at 8:51?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> >My perspective is that strict adherence to input order for
> mapConcurrent() might not be the most common or beneficial default
> behavior for users.
>
> If there is indeed a *majority* who would benefit from an unordered
> version of mapConcurrent (my experience is that the majority prefer
> ordered) then, since it is possible to implement such a Gatherer outside of
> the JDK, this is something which will be constructed, widely used, and
> someone will then propose to add something similar to the JDK.
>
> >While re-implementing the gatherer is a possibility, the existing
> implementation is non-trivial, and creating a custom, robust alternative
> represents a significant undertaking.
>
> The existing version needs to maintain order, which adds to the complexity
> of the implementation. Implementing an unordered version would likely look
> different.
> I'd definitely encourage taking the opportunity to attempt to implement it.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
>
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 2 June 2025 17:05
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Should mapConcurrent() respect time order
> instead of input order?
>
>
> Thank you for your response and for considering my feedback on the
> mapConcurrent() gatherer. I understand and respect that the final
> decision rests with the JDK maintainers.
>
> I would like to offer a couple of further points for consideration. My
> perspective is that strict adherence to input order for mapConcurrent() might
> not be the most common or beneficial default behavior for users. I'd be
> very interested to see any research or data that suggests otherwise, as
> that would certainly inform my understanding.
>
> From my experience, a more common need is for higher throughput in
> I/O-intensive operations. The ability to support use cases like race()?where
> the first successfully completed operation determines the outcome?also
> seems like a valuable capability that is currently infeasible due to the
> ordering constraint.
>
> As I see it, if a developer specifically requires the input order to be
> preserved, this can be achieved with relative ease by applying a subsequent
> sorting operation. For instance:
>
> .gather(mapConcurrent(...))
> .sorted(Comparator.comparing(Result::getInputSequenceId))
>
> The primary challenge in these scenarios is typically the efficient
> fan-out and execution of concurrent tasks, not the subsequent sorting of
> results.
>
> Conversely, as you've noted, there isn't a straightforward way to modify
> the current default ordered behavior to achieve the higher throughput or
> race() semantics that an unordered approach would naturally provide.
>
> While re-implementing the gatherer is a possibility, the existing
> implementation is non-trivial, and creating a custom, robust alternative
> represents a significant undertaking. My hope was that an unordered option
> could be a valuable addition to the standard library, benefiting a wider
> range of developers.
>
> Thank you again for your time and consideration.
>
>
> On Mon, Jun 2, 2025 at 7:48?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> >Even if it by default preserves input order, when I explicitly called
> stream.unordered(), could mapConcurrent() respect that and in return
> achieve higher throughput with support for race?
>
> The Gatherer doesn't know whether the Stream is unordered or ordered. The
> operation should be semantically equivalent anyway.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 2 June 2025 16:29
> *To:* Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <
> core-libs-dev at openjdk.org>
> *Subject:* [External] : Re: Should mapConcurrent() respect time order
> instead of input order?
>
> Sorry. Forgot to copy to the mailing list.
>
> On Mon, Jun 2, 2025 at 7:27?AM Jige Yu <yujige at gmail.com> wrote:
>
> Thanks Viktor!
>
> I was thinking from my own experience that I wouldn't have automatically
> assumed that a concurrent fanout library would by default preserve input
> order.
>
> And I think wanting high throughput with real-life utilities like race
> would be more commonly useful.
>
> But I could be wrong.
>
> Regardless, mapConcurrent() can do both, no?
>
> Even if it by default preserves input order, when I explicitly called
> stream.unordered(), could mapConcurrent() respect that and in return
> achieve higher throughput with support for race?
>
>
>
> On Mon, Jun 2, 2025 at 2:33?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi!
>
> In a similar vein to the built-in Collectors,
> the built-in Gatherers provide solutions to common stream-related
> problems, but also, they also serve as "inspiration" for developers for
> what is possible to implement using Gatherers.
>
> If someone, for performance reasons, and with a use-case which does not
> require encounter-order, want to take advantage of that combination of
> circumstances, it is definitely possible to implement your own Gatherer
> which has that behavior.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Jige
> Yu <yujige at gmail.com>
> *Sent:* Sunday, 1 June 2025 21:08
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Should mapConcurrent() respect time order instead of input
> order?
>
> It seems like for most people, input order isn't that important for
> concurrent work, and concurrent results being in non-deterministic order is
> often expected.
>
> If mapConcurrent() just respect output encounter order:
>
> It'll be able to achieve *higher throughput* if an early task is slow,
> For example, with concurrency=2, and if the first task takes 10 minutes to
> run, mapConcurrent() would only be able to process 2 tasks within the first
> 10 minutes; whereas with encounter order, the first task being slow doesn't
> block the 3rd - 100th elements from being processed and output.
>
> mapConcurrent() can be used to implement useful concurrent semantics, for
> example to *support race* semantics. Imagine if I need to send request to
> 10 candidate backends and take whichever that succeeds first, I'd be able
> to do:
>
> backends.stream()
>     .gather(mapConcurrent(
>         backend -> {
>           try {
>             return backend.fetchOrder();
>            } catch (RpcException e) {
>              return null; // failed to fetch but not fatal
>            }
>         })
>         .filter(Objects::notNull)
>         .findFirst(); // first success then cancel the rest
>
> Cheers,
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250607/b84f6e79/attachment-0001.htm>

From duke at openjdk.org  Sun Jun  8 16:15:40 2025
From: duke at openjdk.org (kieran-farrell)
Date: Sun, 8 Jun 2025 16:15:40 GMT
Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in
 RFC 9562 [v5]
In-Reply-To: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
Message-ID: <f9nUaJKfvz-_Ei2ziDo24J92zBzMEWpy_lE90qOxF04=.dc44325a-0420-4b88-b4bd-7ab61637af9f@github.com>

> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. 
> 
> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
> 
> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation:
> 
> 
> - random-byte-only - 99.8%
> - higher-precision - 3.5%
> - counter-based - 0%
> 
> 
> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization:
> 
> - random-byte-only   143.487 ? 10.932  ns/op
> - higher-precision      149.651 ?  8.438 ns/op
> - counter-based         245.036 ?  2.943  ns/op
> 
> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost.

kieran-farrell has updated the pull request incrementally with one additional commit since the last revision:

  updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25303/files
  - new: https://git.openjdk.org/jdk/pull/25303/files/33d8ccbf..804187fd

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

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

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

From dholmes at openjdk.org  Mon Jun  9 04:06:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 04:06:55 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
Message-ID: <HKWEHqFFRe96b0Hd_cnbIcArNoJx6Uw6ou9eJudG81w=.954f2e0a-95ef-47fe-9a11-d61064f9ae0a@github.com>

On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

>> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
>> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
>> 
>> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.
>
> Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print
>  - Update test/lib/jdk/test/lib/process/OutputBuffer.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Initial working solution

Given jtreg buffers everything anyway, does this even help the outlined usecase?

To be blunt if I were debugging the process launched via ProcessTools, I'd be doing that directly without jtreg and the test libraries getting in the way. That said the proposed change doesn't seem to cause any harm so I'm not totally against it. Just not sure how effective it actually is, nor the best way for the person running the test to turn it on.

test/lib/jdk/test/lib/process/OutputBuffer.java line 150:

> 148:       this.p = p;
> 149:       logProgress("Gathering output");
> 150:       boolean verbose = Boolean.getBoolean("outputanalyzer.verbose");

"verbose" is not really the right word here either. This does not change the amount of output only where it also gets sent to, and that is hard-wired to stdout/err so the name should reflect that e.g. `printToStdStreams` ?

I'm not at all sure how to expose this to the top-level API's though.

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

PR Review: https://git.openjdk.org/jdk/pull/25587#pullrequestreview-2908864741
PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2134992541

From dholmes at openjdk.org  Mon Jun  9 04:06:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 04:06:56 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <NBeas7VSHxEynwU9LXuGy-p9Lg9Tm5I9auSaHBExzRA=.effd0ad3-a5f2-4049-b4df-49030a0502ef@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
 <NBeas7VSHxEynwU9LXuGy-p9Lg9Tm5I9auSaHBExzRA=.effd0ad3-a5f2-4049-b4df-49030a0502ef@github.com>
Message-ID: <v45mu9Zly3T9l94b-WP1p_4oB_Y2Pe0gdU6C3w_vRqM=.ebaa8261-3d70-43a1-82b2-bba9def061a2@github.com>

On Thu, 5 Jun 2025 14:58:40 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print
>>  - Update test/lib/jdk/test/lib/process/OutputBuffer.java
>>    
>>    Co-authored-by: Chen Liang <liach at openjdk.org>
>>  - Initial working solution
>
> test/lib/jdk/test/lib/process/OutputBuffer.java line 150:
> 
>> 148:       this.p = p;
>> 149:       logProgress("Gathering output");
>> 150:       boolean verbose = Boolean.getBoolean("outputanalyzer.verbose");
> 
> Putting a system property at this level of the code kind of hides the functionality.
> 
> An alternative solution would be to have `OutputAnalyzer` constructor(s) that takes a boolean argument. That boolean could be set as needed by individual tests using the `test.debug` property already used by a lot of tests.

But isn't it the person running the tests that wants to set this, not an inherent property of a test itself? Or are you envisaging enabling it at the test-level so the person running the tests doesn't have to do so? But then how does that affect the overall jtreg log content. ??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2134994847

From pminborg at openjdk.org  Mon Jun  9 07:03:55 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 9 Jun 2025 07:03:55 GMT
Subject: Integrated: 8358520: Improve lazy computation in
 BreakIteratorResourceBundle and related classes
In-Reply-To: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
References: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
Message-ID: <glahQKpb6QQYyrFfPUKSO35XeJG87ACpx7stwazvdU8=.3f49a8d5-85f3-454a-a49c-590aa1749a88@github.com>

On Tue, 3 Jun 2025 20:14:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to simplify lazy computation related to resource bundles. Previously, some objects were computed lazily using a double-checked locking algorithm. StableValues offers a more robust and succinct solution. 
>  
>  
> This PR passes tier1, tier2, and tier3 on multiple platforms.

This pull request has now been integrated.

Changeset: 52338c94
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/52338c94f610611a9e89a6ccbe6f2c6cd768b50a
Stats:     138 lines in 3 files changed: 51 ins; 73 del; 14 mod

8358520: Improve lazy computation in BreakIteratorResourceBundle and related classes

Reviewed-by: naoto, jlu

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

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

From viktor.klang at oracle.com  Mon Jun  9 08:49:14 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 9 Jun 2025 08:49:14 +0000
Subject: [External] : Re: Should mapConcurrent() respect time order
 instead of input order?
In-Reply-To: <CAKD1RYvM=BtM1mOo2+KqFZV6GTtPb6c+n7JOVSHN34SsV6=_Jw@mail.gmail.com>
References: <CAKD1RYuoK07OvAn02v4qq74Q1QDfpQpf=t0J0VT-s1zi4iKRnA@mail.gmail.com>
 <MW4PR10MB5774AED3EC215ED5AB3AD52CFF62A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtLy_yC+L5+q1YOkbEvUis5LJ-tJNJDbyoptq8A=+W3eg@mail.gmail.com>
 <CAKD1RYuksGCWsqj6cnu3aoHqkzAepLeNHsGSX_nCi2QryJaGMQ@mail.gmail.com>
 <SJ0PR10MB5766DAA744887EE8B0A2B991FF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYvhpcD=yAGAvTTi+c8sdjDAi776GCPCAdvsCCVF9JQpeQ@mail.gmail.com>
 <SJ0PR10MB5766DB20AB83B1199C7987EAFF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYst6GOErvVozZ2SD6JGhTRUAugSHZFM7aY+5Je72iF3wA@mail.gmail.com>
 <MW4PR10MB57749F82094174F71CF0BB56FF6DA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYu3CUT5nOj9i-cv_n7T=FXvwBpx3BQp6px6Mk2zg6GZNA@mail.gmail.com>
 <MW4PR10MB577448E6F3C06E7A0387AFAAFF6CA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtf4K-r6X0dQZsXUcyZcNa5WLxKZy8p11R163GeLkYn5g@mail.gmail.com>
 <MW4PR10MB57749105268519A8984C7C3EFF6CA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvM=BtM1mOo2+KqFZV6GTtPb6c+n7JOVSHN34SsV6=_Jw@mail.gmail.com>
Message-ID: <MW4PR10MB5774AA40877246F6C78068D8FF6BA@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Jige,

Yes, let's see what developers need. ?

In the meantime, I want to reiterate that it is possible to build what you're asking for, outside of the JDK. To gather experience, feedback, and ultimately decide if the feature is worthwhile.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com>
Sent: Sunday, 8 June 2025 07:39
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order?


Hi Viktor,

Thank you for pointing to the spec. You are absolutely right, that is the documented behavior.

My feedback is aimed directly at questioning that specific design choice within the specification. My perspective is that the benefit of preserving stream ordering may be outweighed by the significant trade-offs it introduces?namely, the potential for surprising performance behavior (like reduced throughput or task starvation) and the loss of flexibility for implementing common concurrent patterns like race semantics.

I understand if the design for the current release is finalized, but I believe this feedback is relevant for the ongoing evolution of the API.

Best regards,

On Wed, Jun 4, 2025 at 11:22?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>Ultimately, the question is whether mapConcurrent() should be optimized primarily for preserving input sequence, or for enabling maximum throughput and flexibility in concurrent scenarios, including efficient "first-to-finish" patterns.

The answer to that is clear in the specification for the operation:

?This operation preserves the ordering of the stream.? - http://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Wednesday, 4 June 2025 18:18
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order?

Hi Viktor,

Thank you for the detailed explanation and the links to the Javadoc for findFirst() and limit(). You're absolutely correct in your characterization of these operations ? they are indeed concerned with encounter order, and parallel execution doesn't inherently change that unless the stream is explicitly unordered. I want to clarify a few of my points that I didn't explain clearly (see below).


On Wed, Jun 4, 2025 at 7:38?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi Jige,

First of all?you're most welcome. Thanks for your insightful questions.

>Temptation for Race Semantics: The beauty of mapConcurrent() integrating with the Stream API means developers will naturally be drawn to use it for race-like scenarios. Operations like findFirst() or limit(N) to get the first few completed results are very intuitive combinations.

It's important to distinguish between spatial (encounter) order and temporal (availability) order.

If we look at `Stream::findFirst()` we see:

?Returns an Optional<https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/util/Optional.html> describing the first element of this stream, or an empty Optional if the stream is empty. If the stream has no encounter order, then any element may be returned.? - https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html#findFirst()

And if we look at `Stream::limit(long)` we see:

?While limit() is generally a cheap operation on sequential stream pipelines, it can be quite expensive on ordered parallel pipelines, especially for large values of maxSize, since limit(n) is constrained to return not just any n elements, but the first n elements in the encounter order. ? (emphasis mine) - https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html#limit(long)

So, we can conclude that "first" and "limit" are about encounter order, and we can conclude that the presence of parallel does not change that?only "unorderedness" may change that.



My apologies if my previous example using findFirst() wasn't as clear as it could have been. I'd like to clarify how I see the interaction with mapConcurrent() playing out:

  1.  mapConcurrent()'s Influence on Encounter Order: When I mentioned using findFirst() (or limit()) for race semantics, the implicit assumption was how mapConcurrent() would feed elements into these terminal operations. The "encounter order" that findFirst() sees is precisely what mapConcurrent() emits. If mapConcurrent() emits results strictly according to input order, then findFirst() will respect that. However, if an unordered mapConcurrent() were to emit results in their temporal order of completion, then findFirst() would naturally pick the first one that actually finished, effectively achieving a race. My point is that mapConcurrent() is in a position to define the encounter order that downstream operations like findFirst() will act upon. The surprise isn't with findFirst()'s definition, but with how a strictly ordered mapConcurrent() might prevent it from being used effectively for "first-to-finish" logic.

  2.  The Role of findAny(): You're right that my example using findFirst() was more nuanced than I intuitively assumed. A developer well-versed in the Stream API nuances might indeed opt for findAny() to implement race semantics, especially given its Javadoc explicitly mentioning suitability for "maximal performance in parallel operations." findAny() is designed to return any element, which aligns well with picking the temporally first available result from an unordered concurrent process.

  3.  Aligning Spec with Intuition: My broader concern is about the intuitive use of these powerful new tools. If mapConcurrent() maintains strict input ordering, it's a perfectly valid and understandable specification by itself. However, the potential for surprise arises when developers, especially those less acquainted with every fine print of stream ordering, attempt to combine mapConcurrent() with findFirst() or findAny() to build common concurrent utilities like a race. They might intuitively expect that "concurrent mapping" followed by "find first/any" would yield the result that completes earliest. While developers should read all related documentation, there's also a design ideal where the API's behavior aligns closely with reasonable developer intuition, especially for common patterns. An unordered mapConcurrent() (or an option for it) would, in my view, better support this intuitive use for race-like patterns. Whereas, I have my doubts that developers commonly would intuitively assume a concurrent operation to stick to strict ordering (it's not what we are used to in most concurrent or multil-threading scenarios)

Ultimately, the question is whether mapConcurrent() should be optimized primarily for preserving input sequence, or for enabling maximum throughput and flexibility in concurrent scenarios, including efficient "first-to-finish" patterns.



>Surprise for Race Semantics Users: Following from the above, it could be surprising for developers when they realize that the inherent input ordering of mapConcurrent() means it's not optimized for these race scenarios. The expectation would be that findFirst() returns as soon as any task completes, but ordering can delay this if an earlier task (in input order) is slower.

This should be addressed above.

>Ordering Assumption in Concurrency: My experience is that ordering is not typically a default assumption when dealing with operations explicitly marked as "parallel" or "concurrent." For instance, Stream.forEach() on a parallel stream does not guarantee encounter order, presumably for performance reasons ? a similar trade-off to what's being discussed for mapConcurrent(). Developers often consult documentation for ordering guarantees in concurrent contexts rather than assuming them.

This should also be addressed above.

>Expectation of "True" Concurrency: When I see an API like mapConcurrent(maxConcurrency, mapper), my mental model is that if maxConcurrency permits, new tasks should be initiated as soon as a slot is free.

This is interesting, because this is how mapConcurrent used to work. It only placed the limit of concurrent work in progress and not work not yet possible to propagate downstream. This was changed, because a delayed initial (in encounter order) item may let subsequent (completed) work queue up indefinitely.

So in conclusion, there's still room for a different take on "mapConcurrentReorder" (name of course left up to the reader), and the good news is that such a Gatherer can be implemented, evaluated, hardened, etc outside of the JDK?and potentially some day something like it ends up in the JDK.


Your mention of a potential mapConcurrentReorder() also brings to mind a thought about API consistency with existing Stream conventions. We see patterns like Stream.forEach() (which for parallel streams doesn't guarantee encounter order, prioritizing performance) versus Stream.forEachOrdered() (which explicitly enforces it). If mapConcurrent() were to follow a similar naming convention, it might suggest that the base mapConcurrent() itself would be the version optimized for throughput (and thus potentially unordered by default), while a hypothetical mapConcurrentOrdered() would be the variant explicitly providing the strict ordering guarantee. This is an observation on how naming might align with established JDK patterns to intuitively guide user expectations about the default behavior.

This naturally leads to the inherent challenge in designing such an API. It seems we're trying to balance three desirable, but sometimes conflicting, goals:

  1.  Strict Encounter Ordering: Results are emitted in the same order as the input elements.
  2.  Bounded Memory Buffering: Avoid out-of-memory errors by not letting completed but un-emitted results queue up indefinitely.
  3.  Optimized (True) Concurrency: If maxConcurrency is set (e.g., to N), the system strives to have N tasks actively running whenever there are pending input elements and available concurrency slots, rather than being stalled by a slow-to-complete but earlier-in-sequence task.

It appears that achieving all three simultaneously is not possible, and a compromise must be made.

From my perspective:

  *   Goal #2 (Bounded Memory) is non-negotiable; OOM situations are generally unacceptable.
  *   Goal #3 (Optimized Concurrency) feels fundamental to an API named mapConcurrent(). Users will likely expect it to maximize the concurrent execution of tasks up to the specified limit. Deviations from this, often necessitated by strict adherence to Goal #1, can lead to surprises.
  *   Goal #1 (Strict Ordering), while a "nice-to-have" and sometimes beneficial, might not always align with common developer intuition for operations explicitly labeled "concurrent," especially if it compromises true concurrency. As discussed, ordering can often be reintroduced by the caller if specifically needed.

The current implementation understandably prioritizes #1 (Ordering) and #2 (Bounded Memory). However, this prioritization can lead to situations where #3 (Optimized Concurrency) is not fully realized, which can be counter-intuitive.

I've already mentioned the race scenario. Consider another example where this becomes particularly evident. Imagine a scenario with a long-running task (e.g., for periodic monitoring) combined with a stream of other "real" tasks:

Java

// Main tasks
List<Callable<Result>> realTasks = ... ;

// A long-running monitoring task
Callable<Void> longRunningMonitoringTask = () -> {
    while (!allRealTasksSeemDone()) { // Simplified condition
        System.out.println("Monitoring...");
        Thread.sleep(5000);
    }
    return null;
};

Stream<Callable<?>> allTasks = Stream.concat(
    Stream.of(longRunningMonitoringTask),
    realTasks.stream().map(task -> (Callable<?>) task)
);

allTasks
    .gather(Gatherers.mapConcurrent(MAX_CONCURRENCY, callable -> callable.call()))
    .forEach(result -> { /* output results */ });


The longRunningMonitoringTask would usually be the first element, with the current strictly ordered behavior, it would occupy one of the MAX_CONCURRENCY slots. and as soon as MAX_CONCURRENCY tasks are executed, completed or not, all subsequent realTasks (beyond the first one) would be starved, unable to even start until the longRunningMonitoringTask completes?which is never. This creates a deadlock or significant processing delay that would likely surprise a developer expecting tasks to proceed concurrently up to the maxConcurrency limit. An implementation more aligned with the "base name implies throughput" idea (as per the forEach analogy) would likely handle this more gracefully by letting tasks run truly concurrently without an implicit ordering dependency.

This reinforces my belief that an alternative gatherer, or a default behavior for mapConcurrent() that prioritizes concurrency (as the name mapConcurrent might suggest to many, akin to forEach), could be very valuable. I understand this might be something that evolves outside the JDK initially, and I appreciate you highlighting that path.

Thanks again for the continued discussion and the transparency about the design choices.

Best regards,



Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Wednesday, 4 June 2025 16:20
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order?


Hi Viktor,

Thank you for sharing that the general feedback on mapConcurrent() has been positive and for the insights into the ongoing enhancements, especially around interruption handling and work-in-progress tracking.

To clarify my own position, I am also extremely enthusiastic about the mapConcurrent() API overall. It offers an elegant and straightforward way to manage homogenous, I/O-intensive concurrent tasks within a structured concurrency model, which is a significant improvement and a much-needed addition. My feedback on ordering is aimed at maximizing its potential.

I'd like to elaborate on a few specific scenarios and expectations that inform my perspective on the ordering:

  1.  Temptation for Race Semantics: The beauty of mapConcurrent() integrating with the Stream API means developers will naturally be drawn to use it for race-like scenarios. Operations like findFirst() or limit(N) to get the first few completed results are very intuitive combinations. For example:

Java

// Hypothetical use case: find the fastest responding service
Optional<Result> fastestResult = serviceUrls.stream()
    .gather(Gatherers.mapConcurrent(MAX_CONCURRENCY, url -> fetch(url)))
    .findFirst();


  2.  Surprise for Race Semantics Users: Following from the above, it could be surprising for developers when they realize that the inherent input ordering of mapConcurrent() means it's not optimized for these race scenarios. The expectation would be that findFirst() returns as soon as any task completes, but ordering can delay this if an earlier task (in input order) is slower.

  3.  Ordering Assumption in Concurrency: My experience is that ordering is not typically a default assumption when dealing with operations explicitly marked as "parallel" or "concurrent." For instance, Stream.forEach() on a parallel stream does not guarantee encounter order, presumably for performance reasons ? a similar trade-off to what's being discussed for mapConcurrent(). Developers often consult documentation for ordering guarantees in concurrent contexts rather than assuming them.

  4.  Expectation of "True" Concurrency: When I see an API like mapConcurrent(maxConcurrency, mapper), my mental model is that if maxConcurrency permits, new tasks should be initiated as soon as a slot is free. For example, with maxConcurrency=2:

     *   Task 1 starts.
     *   Task 2 starts.
     *   If Task 2 finishes while Task 1 is still running, I would expect Task 3 to run concurrently alongside task 1, because the max concurrency is 2, not 1. The current ordered behavior, where Task 3 might have to wait for Task 1 to complete before its result can be processed (even if Task 3 itself could have started and finished), can feel a bit counterintuitive to the notion of maximizing concurrency up to the specified limit. It almost feels like not a "max concurrency", but "max buffer size".

These points are offered to highlight potential areas where the current default could lead to subtle surprises or suboptimal performance for useful concurrent patterns.

Thanks again for the open discussion and for your work on these valuable additions to the JDK.

Best regards,

On Tue, Jun 3, 2025 at 2:13?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
The general feedback received thus far has been primarily positive. There have been a few behavior-related enhancements over the previews to better handle interruption (there's still room to improve there, as per our concurrent conversation) as well as some improvements to work-in-progress tracking.

It will be interesting to see which Gatherer-based operations will be devised by Java developers in the future.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 2 June 2025 18:54
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order?


Hi Viktor,

Thanks for your reply and for sharing your experience regarding user preferences. I appreciate that perspective.

You're right, if an unordered version of mapConcurrent proves to be widely beneficial and is implemented and adopted by the community, it could certainly make a strong case for future inclusion in the JDK.

I wanted to clarify a nuance regarding user preference that I might not have articulated clearly before. If the question is simply "ordered or unordered?", in isolation, I can see why many, myself included, might lean towards "ordered" as a general preference.

However, the decision becomes more complex when the associated trade-offs are considered. If the question were phrased more like, "Do you prefer an ordered mapConcurrent by default, even if it entails potential performance overhead and limitations for certain use cases like race() operations, versus an unordered version that offers higher throughput and broader applicability in such scenarios?" my (and perhaps others') answer might differ. The perceived cost versus benefit of ordering changes significantly when these factors are explicit.

My initial suggestion stemmed from the belief that the performance and flexibility gains of an unordered approach for I/O-bound tasks would, in many practical situations, outweigh the convenience of default ordering, especially since ordering can be reintroduced relatively easily, and explicitly, when needed.

Thanks again for the discussion.

Best regards,

On Mon, Jun 2, 2025 at 8:51?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>My perspective is that strict adherence to input order for mapConcurrent() might not be the most common or beneficial default behavior for users.

If there is indeed a majority who would benefit from an unordered version of mapConcurrent (my experience is that the majority prefer ordered) then, since it is possible to implement such a Gatherer outside of the JDK, this is something which will be constructed, widely used, and someone will then propose to add something similar to the JDK.

>While re-implementing the gatherer is a possibility, the existing implementation is non-trivial, and creating a custom, robust alternative represents a significant undertaking.

The existing version needs to maintain order, which adds to the complexity of the implementation. Implementing an unordered version would likely look different.
I'd definitely encourage taking the opportunity to attempt to implement it.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 2 June 2025 17:05
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order?


Thank you for your response and for considering my feedback on the mapConcurrent() gatherer. I understand and respect that the final decision rests with the JDK maintainers.

I would like to offer a couple of further points for consideration. My perspective is that strict adherence to input order for mapConcurrent() might not be the most common or beneficial default behavior for users. I'd be very interested to see any research or data that suggests otherwise, as that would certainly inform my understanding.

From my experience, a more common need is for higher throughput in I/O-intensive operations. The ability to support use cases like race()?where the first successfully completed operation determines the outcome?also seems like a valuable capability that is currently infeasible due to the ordering constraint.

As I see it, if a developer specifically requires the input order to be preserved, this can be achieved with relative ease by applying a subsequent sorting operation. For instance:

.gather(mapConcurrent(...))
.sorted(Comparator.comparing(Result::getInputSequenceId))


The primary challenge in these scenarios is typically the efficient fan-out and execution of concurrent tasks, not the subsequent sorting of results.

Conversely, as you've noted, there isn't a straightforward way to modify the current default ordered behavior to achieve the higher throughput or race() semantics that an unordered approach would naturally provide.

While re-implementing the gatherer is a possibility, the existing implementation is non-trivial, and creating a custom, robust alternative represents a significant undertaking. My hope was that an unordered option could be a valuable addition to the standard library, benefiting a wider range of developers.

Thank you again for your time and consideration.


On Mon, Jun 2, 2025 at 7:48?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>Even if it by default preserves input order, when I explicitly called stream.unordered(), could mapConcurrent() respect that and in return achieve higher throughput with support for race?

The Gatherer doesn't know whether the Stream is unordered or ordered. The operation should be semantically equivalent anyway.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 2 June 2025 16:29
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>; core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: [External] : Re: Should mapConcurrent() respect time order instead of input order?

Sorry. Forgot to copy to the mailing list.

On Mon, Jun 2, 2025 at 7:27?AM Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>> wrote:
Thanks Viktor!

I was thinking from my own experience that I wouldn't have automatically assumed that a concurrent fanout library would by default preserve input order.

And I think wanting high throughput with real-life utilities like race would be more commonly useful.

But I could be wrong.

Regardless, mapConcurrent() can do both, no?

Even if it by default preserves input order, when I explicitly called stream.unordered(), could mapConcurrent() respect that and in return achieve higher throughput with support for race?



On Mon, Jun 2, 2025 at 2:33?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi!

In a similar vein to the built-in Collectors,
the built-in Gatherers provide solutions to common stream-related problems, but also, they also serve as "inspiration" for developers for what is possible to implement using Gatherers.

If someone, for performance reasons, and with a use-case which does not require encounter-order, want to take advantage of that combination of circumstances, it is definitely possible to implement your own Gatherer which has that behavior.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Sunday, 1 June 2025 21:08
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Should mapConcurrent() respect time order instead of input order?

It seems like for most people, input order isn't that important for concurrent work, and concurrent results being in non-deterministic order is often expected.

If mapConcurrent() just respect output encounter order:

It'll be able to achieve higher throughput if an early task is slow, For example, with concurrency=2, and if the first task takes 10 minutes to run, mapConcurrent() would only be able to process 2 tasks within the first 10 minutes; whereas with encounter order, the first task being slow doesn't block the 3rd - 100th elements from being processed and output.

mapConcurrent() can be used to implement useful concurrent semantics, for example to support race semantics. Imagine if I need to send request to 10 candidate backends and take whichever that succeeds first, I'd be able to do:

backends.stream()
    .gather(mapConcurrent(
        backend -> {
          try {
            return backend.fetchOrder();
           } catch (RpcException e) {
             return null; // failed to fetch but not fatal
           }
        })
        .filter(Objects::notNull)
        .findFirst(); // first success then cancel the rest

Cheers,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250609/daebbef6/attachment-0001.htm>

From vklang at openjdk.org  Mon Jun  9 09:01:02 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 9 Jun 2025 09:01:02 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <Zyz8nyCssvU32SJGYXRHwq6vbTUR1x5gBZmBnDYPC7Y=.97852347-7820-489c-a9b7-1d2448c5f4cc@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com>
 <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com>
 <YhkDQaU0FTyyP_42JTmUxM5x97rwSAHQbVYPJxRv3cI=.d70127c6-4f45-48b4-8b6c-eebad4084a34@github.com>
 <fT_4bHAK3fI6N5eRE7LgQ7FMt6o9C3WgTpfEh0ZbDkE=.579c1c92-0173-4f85-b7ff-83cbdf05b630@github.com>
 <LyZhpoeP4NnTHa0mSzdcRfEdvrtb3nvJST8yCz62XDo=.327dd96c-ab3a-4251-a7bd-8a23b92b2731@github.com>
 <Zyz8nyCssvU32SJGYXRHwq6vbTUR1x5gBZmBnDYPC7Y=.97852347-7820-489c-a9b7-1d2448c5f4cc@github.com>
Message-ID: <iAbm65twNYrkCzHZWZBvS8s3c7hVbo7q6fClwbhbO_s=.eb91c1df-be84-449c-8f60-9b1debf25474@github.com>

On Tue, 13 May 2025 13:16:45 GMT, kabutz <duke at openjdk.org> wrote:

>>> > @kabutz I think @AlanBateman might be able to have a look as well.
>>> > As for timing, it seems to me most reasonable if this PR (if it is to be integrated) to go in _after_ JDK25 has been forked, to give enough time for JDK26 early access feedback and giving the changes time to harden. I hope that makes sense.
>>> 
>>> That sound reasonable. When would this be?
>> 
>> About a month or so.
>
>> About a month or so.
> 
> Perfect, thanks @viktorklang-ora. I've marked the other issues as closed - duplicates, and referenced this single umbrella PR.

@kabutz Java 25 has been branched off so it's time to get back to this one. I'll spend some time today to have another look at this, and then discuss it with Doug this afternoon.

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

PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2955137099

From vklang at openjdk.org  Mon Jun  9 09:22:58 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 9 Jun 2025 09:22:58 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <EA5TgRWJRik6NTmG9n7L12cq-viCZ9wcOMu2spIgEPk=.06fc3b76-8949-45c5-a280-08424a898e45@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <-elHwuRlU4xfy382a9QVdVT6WQMPoZyyEHANGR2TgmQ=.b4329ab0-7f2e-4c7b-9053-9917f2ea3a5f@github.com>
 <EA5TgRWJRik6NTmG9n7L12cq-viCZ9wcOMu2spIgEPk=.06fc3b76-8949-45c5-a280-08424a898e45@github.com>
Message-ID: <ql0KpBn5MHeVurYlr_WJ5Na6W6zAMm8U_qRsSSRF2Ys=.d27ce0fd-f8b7-4c58-8e8e-b455e6c79015@github.com>

On Thu, 8 May 2025 13:47:41 GMT, kabutz <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 341:
>> 
>>> 339:             if (count >= capacity)
>>> 340:                 return false;
>>> 341:             linkFirst(node);
>> 
>> I'm a bit uneasy about incrementing the `count` in `linkFirst` but not enforcing the invariant. What's the benefit to changing linkFirst and linkLast to return void instead of keeping the original returning a boolean?
>
>> I'm a bit uneasy about incrementing the `count` in `linkFirst` but not enforcing the invariant. What's the benefit to changing linkFirst and linkLast to return void instead of keeping the original returning a boolean?
> 
> I based the approach on the LBQ enqueue() and dequeue() methods, which also return void and have a comment with the assertion.

@kabutz I'd think maintaining the invariants within linkFirst and linkLast would be preferable (`count` must be re-read under the lock anyway)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2135364751

From vklang at openjdk.org  Mon Jun  9 09:27:58 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 9 Jun 2025 09:27:58 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <znTHuGY13_blYpGZOhjbjcSZAbsdGmPqI1SZb4-Y7ek=.37c22106-d082-4f6a-a03e-7eaa6e897c87@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <VjVR6fAsjI47ypazhGOkMo5b6Q451Y7yjyKPeNm-_e0=.371a3007-d96b-40e4-bfa3-4e14ab2d2ebe@github.com>
 <znTHuGY13_blYpGZOhjbjcSZAbsdGmPqI1SZb4-Y7ek=.37c22106-d082-4f6a-a03e-7eaa6e897c87@github.com>
Message-ID: <gms3u90qq6y0VmwWa1oUjLbMHg7tRqVJUm1IXGJWjnQ=.95aec097-beea-444b-bc87-eb4fb7d350e4@github.com>

On Thu, 8 May 2025 13:53:31 GMT, kabutz <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 860:
>> 
>>> 858:             // As historically specified in AbstractQueue#addAll
>>> 859:             throw new IllegalArgumentException();
>>> 860: 
>> 
>> We could likely check if there's any remaining capacity up front, and immediately return false?
>
>> We could likely check if there's any remaining capacity up front, and immediately return false?
> 
> We could if you like. I wanted to make as few changes as possible, to not introduce unexpected changes. This particular bug was to stop a size overflow.

@DougLea What do you think about checking if the target collection is likely going to fit into the queue early?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2135371406

From duke at openjdk.org  Mon Jun  9 09:58:53 2025
From: duke at openjdk.org (erifan)
Date: Mon, 9 Jun 2025 09:58:53 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v8]
In-Reply-To: <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
Message-ID: <6FGYIrxqZhFZn9Ycw_VOw7gltjocfG451Ex_Qq9yjhM=.c8183515-a047-4160-be9b-98200040c19f@github.com>

On Fri, 6 Jun 2025 10:38:11 GMT, erifan <duke at openjdk.org> wrote:

>> This patch optimizes the following patterns:
>> For integer types:
>> 
>> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> 
>> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond.
>> 
>> For float and double types:
>> 
>> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> 
>> cond can be eq or ne.
>> 
>> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`:
>> 
>> Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>> testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>> testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>> testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>> testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>> testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>> testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>> testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>> testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>> testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
>> testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
>> testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
>> testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
>> testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
>> testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
>> testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
>> testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
>> testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
>> testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
>> testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
>> testCompareLTMaskNotInt		ops/s	16721...
>
> erifan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Support negating unsigned comparison for BoolTest::mask
>   
>   Added a static method `negate_mask(mask btm)` into BoolTest class to
>   negate both signed and unsigned comparison.

Hi @RealFYang , would you mind helping test this patch on a risc-v machine with rvv? This optimization also applies to rvv, but I don't have a risc-v test environment.

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

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

From dl at openjdk.org  Mon Jun  9 10:59:53 2025
From: dl at openjdk.org (Doug Lea)
Date: Mon, 9 Jun 2025 10:59:53 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <gms3u90qq6y0VmwWa1oUjLbMHg7tRqVJUm1IXGJWjnQ=.95aec097-beea-444b-bc87-eb4fb7d350e4@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <VjVR6fAsjI47ypazhGOkMo5b6Q451Y7yjyKPeNm-_e0=.371a3007-d96b-40e4-bfa3-4e14ab2d2ebe@github.com>
 <znTHuGY13_blYpGZOhjbjcSZAbsdGmPqI1SZb4-Y7ek=.37c22106-d082-4f6a-a03e-7eaa6e897c87@github.com>
 <gms3u90qq6y0VmwWa1oUjLbMHg7tRqVJUm1IXGJWjnQ=.95aec097-beea-444b-bc87-eb4fb7d350e4@github.com>
Message-ID: <d53R8cBBYiAnM2v__HgOJOwM7rcnBFkz5_JAYAkrAVU=.185ebf7f-c21c-46bd-932c-64309587cd67@github.com>

On Mon, 9 Jun 2025 09:24:57 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>>> We could likely check if there's any remaining capacity up front, and immediately return false?
>> 
>> We could if you like. I wanted to make as few changes as possible, to not introduce unexpected changes. This particular bug was to stop a size overflow.
>
> @DougLea What do you think about checking if the target collection is likely going to fit into the queue early?

Because of races, prechecks can't  be exactly accurate, but I think Heinz's current approach is a good choice, and is similar to how it's done elsewhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2135512775

From duke at openjdk.org  Mon Jun  9 12:01:06 2025
From: duke at openjdk.org (kabutz)
Date: Mon, 9 Jun 2025 12:01:06 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <ql0KpBn5MHeVurYlr_WJ5Na6W6zAMm8U_qRsSSRF2Ys=.d27ce0fd-f8b7-4c58-8e8e-b455e6c79015@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <-elHwuRlU4xfy382a9QVdVT6WQMPoZyyEHANGR2TgmQ=.b4329ab0-7f2e-4c7b-9053-9917f2ea3a5f@github.com>
 <EA5TgRWJRik6NTmG9n7L12cq-viCZ9wcOMu2spIgEPk=.06fc3b76-8949-45c5-a280-08424a898e45@github.com>
 <ql0KpBn5MHeVurYlr_WJ5Na6W6zAMm8U_qRsSSRF2Ys=.d27ce0fd-f8b7-4c58-8e8e-b455e6c79015@github.com>
Message-ID: <1SKPNkGME2qEQSi1M-WCFSl6FOROtP90y3KqnLXmquk=.f833977e-b9ed-4309-b567-66ae63219eee@github.com>

On Mon, 9 Jun 2025 09:20:31 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>>> I'm a bit uneasy about incrementing the `count` in `linkFirst` but not enforcing the invariant. What's the benefit to changing linkFirst and linkLast to return void instead of keeping the original returning a boolean?
>> 
>> I based the approach on the LBQ enqueue() and dequeue() methods, which also return void and have a comment with the assertion.
>
> @kabutz I'd think maintaining the invariants within linkFirst and linkLast would be preferable (`count` must be re-read under the lock anyway)

What would you like to do if the invariant fails inside linkFirst() and linkLast()? Should we throw an AssertionError each time?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2135589310

From vklang at openjdk.org  Mon Jun  9 13:13:53 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 9 Jun 2025 13:13:53 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <1SKPNkGME2qEQSi1M-WCFSl6FOROtP90y3KqnLXmquk=.f833977e-b9ed-4309-b567-66ae63219eee@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <-elHwuRlU4xfy382a9QVdVT6WQMPoZyyEHANGR2TgmQ=.b4329ab0-7f2e-4c7b-9053-9917f2ea3a5f@github.com>
 <EA5TgRWJRik6NTmG9n7L12cq-viCZ9wcOMu2spIgEPk=.06fc3b76-8949-45c5-a280-08424a898e45@github.com>
 <ql0KpBn5MHeVurYlr_WJ5Na6W6zAMm8U_qRsSSRF2Ys=.d27ce0fd-f8b7-4c58-8e8e-b455e6c79015@github.com>
 <1SKPNkGME2qEQSi1M-WCFSl6FOROtP90y3KqnLXmquk=.f833977e-b9ed-4309-b567-66ae63219eee@github.com>
Message-ID: <1Q6S4w1FCTNqbKvWsxjYMWBVJq39EJ0B-oY6omiVZ68=.7d1021af-7a1c-4cba-9d9a-8a05affbc854@github.com>

On Mon, 9 Jun 2025 11:58:03 GMT, kabutz <duke at openjdk.org> wrote:

>> @kabutz I'd think maintaining the invariants within linkFirst and linkLast would be preferable (`count` must be re-read under the lock anyway)
>
> What would you like to do if the invariant fails inside linkFirst() and linkLast()? Should we throw an AssertionError each time?

No, I was more thinking keeping it as it was: (return true/false from linkFirst / linkLast depending on whether it passes the capacity check or not)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2135696882

From ihse at openjdk.org  Mon Jun  9 13:33:39 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 13:33:39 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8 [v2]
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <zxrLICCCcLyUhUi55p4ZTPn1ioJOVims3WQ6cImbTzA=.3ebe3fc0-c8c7-4156-b563-e14f04bac137@github.com>

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into utf8-sequences-in-src
 - 8356978: Convert unicode sequences in Java source code to UTF-8

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

Changes: https://git.openjdk.org/jdk/pull/25229/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25229&range=01
  Stats: 6776 lines in 79 files changed: 0 ins; 0 del; 6776 mod
  Patch: https://git.openjdk.org/jdk/pull/25229.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25229/head:pull/25229

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

From ihse at openjdk.org  Mon Jun  9 13:41:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 13:41:10 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8 [v3]
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <Zdq3BujNi2Cl5avP8MFyhJkTZl5bXJ--K_Du7lw-AUM=.914662bc-d218-4d48-8a05-63efc91e90d6@github.com>

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Reverting fixes in java.xml and jdk.jdi

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25229/files
  - new: https://git.openjdk.org/jdk/pull/25229/files/37bf474c..5a5d7b7b

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

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

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

From ihse at openjdk.org  Mon Jun  9 13:41:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 13:41:10 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <oD07jz4sbaXmrAQXxWt9B31R7oYM1rYfg30hH9d0-Kc=.f3b6cd24-8e2e-4e77-b9dd-4ea4511b64c5@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <rtLeXcGYPjdVH16A5db5VvNl3AFbcqwVQYzbrrYZrZo=.5bdee26b-cc5f-4834-9cf3-f710cb34c0a0@github.com>
 <oD07jz4sbaXmrAQXxWt9B31R7oYM1rYfg30hH9d0-Kc=.f3b6cd24-8e2e-4e77-b9dd-4ea4511b64c5@github.com>
Message-ID: <MlaNiiD6KyfBbrM7Rfs6jeWHg9ZGE-MKa4i2p2Ya4sU=.63399b3c-2270-4916-8055-47e0dac8a29c@github.com>

On Tue, 27 May 2025 16:31:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> @justin-curtis-lu Are these files handled by the translation team?
>
> @magicus The ones under java.xml and jdk.jdi are updated by the translation team, I think it'd be best to remove those files from this change.

I have now reverted the changes in java.xml and jdk.jdi. I still think these changes should be made, but it should apparently go through the translation team. @justin-curtis-lu Can you help me file a bug report so this gets done? I'm not sure how to do that. Basically, they will need to revert 5a5d7b7b13158c3b35ed9c433e6fdc34aa20b73d.

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

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2955820392

From ihse at openjdk.org  Mon Jun  9 13:41:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 13:41:10 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <b0f0ldjIu6qI6gHCIZj-QuqZdUZ87_2s2znpk2gkmwY=.8d297170-8ec9-4710-9cea-be3b3fe9db03@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <b0f0ldjIu6qI6gHCIZj-QuqZdUZ87_2s2znpk2gkmwY=.8d297170-8ec9-4710-9cea-be3b3fe9db03@github.com>
Message-ID: <Cpl6dRjtnj-m3gtvHqeiIIVcCdpGWvNoqOUJtoVm7eM=.4a0bfc91-6c1a-4bd0-b8f5-bb89e2a7d732@github.com>

On Tue, 27 May 2025 17:01:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.
>
> Those TimeZoneNames* resource bundles are in fact leftovers from COMPAT locale provider removal. I am going to remove those files later so you can exclude them.

@naotoj You okay with this?

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

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2955822435

From aivanov at openjdk.org  Mon Jun  9 14:25:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 9 Jun 2025 14:25:55 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8 [v3]
In-Reply-To: <Zdq3BujNi2Cl5avP8MFyhJkTZl5bXJ--K_Du7lw-AUM=.914662bc-d218-4d48-8a05-63efc91e90d6@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <Zdq3BujNi2Cl5avP8MFyhJkTZl5bXJ--K_Du7lw-AUM=.914662bc-d218-4d48-8a05-63efc91e90d6@github.com>
Message-ID: <cClJUYWcy9oZ_a3qLky54b_n8y4KXr1z9435NpmUoEg=.d03699aa-68c9-49e5-841c-729e8dc4a533@github.com>

On Mon, 9 Jun 2025 13:41:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverting fixes in java.xml and jdk.jdi

src/demo/share/jfc/Stylepad/HelloWorld.java line 196:

> 194:             + "???????"
> 195:             + "??? ???"
> 196:             + "?!")

Maybe we can merge the string now:
Suggestion:

            new Run("none", "?????? ?????????? ????!") // Greek

At least two words seem to be split between the wrapped lines.

src/demo/share/jfc/Stylepad/HelloWorld.java line 203:

> 201:         new Paragraph("title", new Run[] {
> 202:             new Run("none", "???? ????"
> 203:             + "????")

Suggestion:

            new Run("none", "???? ????????")

src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ja.java line 90:

> 88:             { "japanese.FirstYear",
> 89:                 new String[] {  // first year name
> 90:                     "?",   // "Gan"-nen

Suggestion:

                    "?",       // "Gan"-nen

Preserve comment alignment?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25229#discussion_r2135817539
PR Review Comment: https://git.openjdk.org/jdk/pull/25229#discussion_r2135819248
PR Review Comment: https://git.openjdk.org/jdk/pull/25229#discussion_r2135821435

From duke at openjdk.org  Mon Jun  9 15:50:03 2025
From: duke at openjdk.org (kabutz)
Date: Mon, 9 Jun 2025 15:50:03 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v2]
In-Reply-To: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
Message-ID: <4dFrhxasUHj7mZzDv7ns8ICmusUkms6Hzf0X0UAtlLA=.19b2da87-022f-4a1d-a374-83f2fa861eed@github.com>

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

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

  Moved invariant checking into linkFirst() and linkLast() methods and added unit test for weakly consistent iteration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24925/files
  - new: https://git.openjdk.org/jdk/pull/24925/files/76282a43..e2a0967a

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

  Stats: 50 lines in 2 files changed: 30 ins; 10 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24925.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24925/head:pull/24925

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

From ihse at openjdk.org  Mon Jun  9 15:52:24 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 15:52:24 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8 [v4]
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <3yL38BGxpG7641rwLTFNIBmL4PbnxVM4-0cdTondkx0=.f9e7da4e-f155-4ff1-ad9b-750311409de7@github.com>

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:

 - Fix comment indentation
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Concatenate string literals
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Concatenate string literals
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25229/files
  - new: https://git.openjdk.org/jdk/pull/25229/files/5a5d7b7b..a9f7acc6

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

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

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

From ihse at openjdk.org  Mon Jun  9 15:52:24 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 15:52:24 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8 [v3]
In-Reply-To: <Zdq3BujNi2Cl5avP8MFyhJkTZl5bXJ--K_Du7lw-AUM=.914662bc-d218-4d48-8a05-63efc91e90d6@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <Zdq3BujNi2Cl5avP8MFyhJkTZl5bXJ--K_Du7lw-AUM=.914662bc-d218-4d48-8a05-63efc91e90d6@github.com>
Message-ID: <800l9jY8WcERDH6cBd9Jiw-TXxDWjjsn2kJhxK32HYA=.9eae1609-b9f8-4485-af6c-1808a5735cd0@github.com>

On Mon, 9 Jun 2025 13:41:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverting fixes in java.xml and jdk.jdi

Thanks @aivanov-jdk!

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

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2956185963

From prr at openjdk.org  Mon Jun  9 16:04:00 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 9 Jun 2025 16:04:00 GMT
Subject: Integrated: 8358731: Remove jdk.internal.access.JavaAWTAccess.java
In-Reply-To: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>
References: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>
Message-ID: <MWLlvat_GaMGyCxofHjNm79qkTL08IUcVP8LCWlbIC4=.6f2ff711-2e92-4102-b229-56b9fe7b481a@github.com>

On Fri, 6 Jun 2025 18:35:53 GMT, Phil Race <prr at openjdk.org> wrote:

> The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after JEP 486 and JEP 491 integration
> removed use of AppContext from java/util/logging/LogManager.java.
> That was the only place in the JDK that used jdk.internal.access.JavaAWTAccess.java so it can be removed.
> 
> There are 3 tests that use it (digging into internals) but those tests are pointless now that LogManager doesn't use AppContext, so they should be deleted.
> 
> Automated client tests and logging tests (JDK tier1 for the latter it seems) all pass.

This pull request has now been integrated.

Changeset: eb8ee8bd
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb8ee8bdc7c170910abc9aa18de1e22677160358
Stats:     1110 lines in 6 files changed: 0 ins; 1110 del; 0 mod

8358731: Remove jdk.internal.access.JavaAWTAccess.java

Reviewed-by: dfuchs, serb

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

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

From naoto at openjdk.org  Mon Jun  9 16:09:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jun 2025 16:09:53 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8 [v4]
In-Reply-To: <3yL38BGxpG7641rwLTFNIBmL4PbnxVM4-0cdTondkx0=.f9e7da4e-f155-4ff1-ad9b-750311409de7@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <3yL38BGxpG7641rwLTFNIBmL4PbnxVM4-0cdTondkx0=.f9e7da4e-f155-4ff1-ad9b-750311409de7@github.com>
Message-ID: <f86k18YSqMNnLFfAES-56FVmEwDL3qBo2JfZnATOR88=.631be620-509d-459a-8d85-f18e0e8e6af5@github.com>

On Mon, 9 Jun 2025 15:52:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix comment indentation
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Concatenate string literals
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Concatenate string literals
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25229#pullrequestreview-2910543905

From duke at openjdk.org  Mon Jun  9 16:25:09 2025
From: duke at openjdk.org (kabutz)
Date: Mon, 9 Jun 2025 16:25:09 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v3]
In-Reply-To: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
Message-ID: <kfkc6Uyy5rWwz12wVri8GzKJcE-7K50r3sXBS7bZIak=.ad3996d4-3449-4998-b7af-e299eb5cb866@github.com>

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

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

  Fixed bug in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24925/files
  - new: https://git.openjdk.org/jdk/pull/24925/files/e2a0967a..1da40f92

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

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

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

From duke at openjdk.org  Mon Jun  9 16:33:20 2025
From: duke at openjdk.org (kabutz)
Date: Mon, 9 Jun 2025 16:33:20 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v4]
In-Reply-To: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
Message-ID: <_V-u5DQXsbqDp3DQ-uTWhwxVe5EZjDNjFUbyioxWe6w=.a26b20e7-74ba-4d6c-8d10-0e2dd838a482@github.com>

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

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

  Fixed another bug in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24925/files
  - new: https://git.openjdk.org/jdk/pull/24925/files/1da40f92..23adc1d1

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

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

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

From duke at openjdk.org  Mon Jun  9 16:38:08 2025
From: duke at openjdk.org (kabutz)
Date: Mon, 9 Jun 2025 16:38:08 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v5]
In-Reply-To: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
Message-ID: <Zr0HKddrDANDqKeiMB2Qxn_1mez1SeKkDPguIRcogfk=.0d17519b-79e2-47fe-81e4-a43b003b8f37@github.com>

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

kabutz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Moved invariant checking into linkFirst() and linkLast() methods and added unit test for iterator.remove() in weakly consistent iteration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24925/files
  - new: https://git.openjdk.org/jdk/pull/24925/files/23adc1d1..e0db5ce8

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

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

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

From duke at openjdk.org  Mon Jun  9 16:53:07 2025
From: duke at openjdk.org (kabutz)
Date: Mon, 9 Jun 2025 16:53:07 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v6]
In-Reply-To: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
Message-ID: <ooPu9wL4j0HOvuZd0etBF767JWdlSRruQIc3PFGemp0=.33a2288f-2c31-45bd-a00f-9f6f9f254752@github.com>

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

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

  Whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24925/files
  - new: https://git.openjdk.org/jdk/pull/24925/files/e0db5ce8..27b05362

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

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

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

From duke at openjdk.org  Mon Jun  9 16:57:00 2025
From: duke at openjdk.org (kabutz)
Date: Mon, 9 Jun 2025 16:57:00 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v6]
In-Reply-To: <1Q6S4w1FCTNqbKvWsxjYMWBVJq39EJ0B-oY6omiVZ68=.7d1021af-7a1c-4cba-9d9a-8a05affbc854@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <-elHwuRlU4xfy382a9QVdVT6WQMPoZyyEHANGR2TgmQ=.b4329ab0-7f2e-4c7b-9053-9917f2ea3a5f@github.com>
 <EA5TgRWJRik6NTmG9n7L12cq-viCZ9wcOMu2spIgEPk=.06fc3b76-8949-45c5-a280-08424a898e45@github.com>
 <ql0KpBn5MHeVurYlr_WJ5Na6W6zAMm8U_qRsSSRF2Ys=.d27ce0fd-f8b7-4c58-8e8e-b455e6c79015@github.com>
 <1SKPNkGME2qEQSi1M-WCFSl6FOROtP90y3KqnLXmquk=.f833977e-b9ed-4309-b567-66ae63219eee@github.com>
 <1Q6S4w1FCTNqbKvWsxjYMWBVJq39EJ0B-oY6omiVZ68=.7d1021af-7a1c-4cba-9d9a-8a05affbc854@github.com>
Message-ID: <dF573nJrhsYripGLnDSQ0HgSS4gRYDG9VpJZUt0EgIk=.0d2318a1-76e8-43e1-b955-e048d7f6f04f@github.com>

On Mon, 9 Jun 2025 13:11:34 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> What would you like to do if the invariant fails inside linkFirst() and linkLast()? Should we throw an AssertionError each time?
>
> No, I was more thinking keeping it as it was: (return true/false from linkFirst / linkLast depending on whether it passes the capacity check or not)

I've made the changes you suggested and it is indeed better. Thanks @viktorklang-ora

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2136077386

From duke at openjdk.org  Mon Jun  9 17:01:55 2025
From: duke at openjdk.org (kabutz)
Date: Mon, 9 Jun 2025 17:01:55 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v6]
In-Reply-To: <evfaz5EKS-CJbYM0Ai3PqcC-0Soa6CC4TfJ_ZHAK1vs=.0515c9b9-7bec-4782-8482-86956e1cb173@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <rO9njoSonLf7DLUrHaB9jMMXDTodgbWlZ-391cqxW50=.0f02cb42-105b-4aaf-88cf-9d6574e0d555@github.com>
 <evfaz5EKS-CJbYM0Ai3PqcC-0Soa6CC4TfJ_ZHAK1vs=.0515c9b9-7bec-4782-8482-86956e1cb173@github.com>
Message-ID: <wUQIO1ZsNXT6ILoVj9mBW4_NPQZm1YcQiYZ9wR7BcKw=.0e1435e1-2aad-43e8-89b5-7171ea99a973@github.com>

On Thu, 8 May 2025 14:27:07 GMT, kabutz <duke at openjdk.org> wrote:

>> test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java line 1958:
>> 
>>> 1956:         q.add(four);
>>> 1957:         q.add(five);
>>> 1958:         q.add(six);
>> 
>> Out of curiosity, how does `it.remove()` work under these conditions?
>
>> Out of curiosity, how does `it.remove()` work under these conditions?
> 
> If we call it.remove() on the first element, it delegates to unlinkFirst() (if we are using an ascending iterator), and unlinkLast (if we are using a descending iterator). Similarly, if we call it.remove() on the last element it will call unlinkLast() or unlinkFirst(). With unlinkFirst(), it will make f.next = f (thus linking back to itself) and with unlinkLast(), it will make l.prev = l.
> 
> If we call it.remove() on a middle element, then we simply link the p.next = n; n.prev = p; and does not do self-linking. Thus if we have an LBD with 1,2,3,4,5 with two iterators pointing onto 3, if one of them removes it, then the other will continue with 3 (cached), 4, 5, and it won't go back to the beginning and see duplicate elements.

I've added a unit test for this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2136084498

From duke at openjdk.org  Mon Jun  9 17:16:01 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 9 Jun 2025 17:16:01 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved
Message-ID: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>

This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`

As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.

Testing:
- GHA
- Local run of tier 2 and jtreg:jdk/java/text
- New benchmark: DecimalFormatParseBench

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

Commit messages:
 - Merge branch 'openjdk:master' into digitlist-getdouble-get-long
 - simplify getBigDecimal
 - simplify comparison
 - update comment
 - copyright dates
 - improve getDouble, getLong

Changes: https://git.openjdk.org/jdk/pull/25644/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25644&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358880
  Stats: 177 lines in 4 files changed: 119 ins; 46 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/25644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25644/head:pull/25644

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

From duke at openjdk.org  Mon Jun  9 17:16:02 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 9 Jun 2025 17:16:02 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved
In-Reply-To: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
Message-ID: <-e5rXCnNcp7f2EdOodLJlsFcytVjKA7Qrwt3HkzGtYU=.c78eb6e8-3f44-4668-bc3a-5c3393a5fe18@github.com>

On Wed, 4 Jun 2025 18:18:39 GMT, Johannes Graham <duke at openjdk.org> wrote:

> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
> 
> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
> 
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench

Rough performance results on AArch64 M4:



Original
Benchmark                                   Mode  Cnt      Score     Error   Units
-DecimalFormatParseBench.testParseDoubles  thrpt   15  15200.984 ? 409.547  ops/ms
-DecimalFormatParseBench.testParseLongs    thrpt   15  25777.899 ? 559.096  ops/ms

This PR
Benchmark                                   Mode  Cnt      Score     Error   Units
+DecimalFormatParseBench.testParseDoubles  thrpt   15  28041.325 ? 472.657  ops/ms
+DecimalFormatParseBench.testParseLongs    thrpt   15  34181.146 ? 655.719  ops/ms

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

PR Comment: https://git.openjdk.org/jdk/pull/25644#issuecomment-2940975486

From liach at openjdk.org  Mon Jun  9 17:16:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Jun 2025 17:16:03 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved
In-Reply-To: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
Message-ID: <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>

On Wed, 4 Jun 2025 18:18:39 GMT, Johannes Graham <duke at openjdk.org> wrote:

> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
> 
> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
> 
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench

src/java.base/share/classes/java/text/DigitList.java line 192:

> 190:         long v = Long.parseUnsignedLong(new String(digits, 0, count));
> 191:         if (v < 0) {
> 192:             if (Long.compareUnsigned(v, Long.MIN_VALUE) == 0) {

Unsigned == should be equivalent to signed ==, so `v == Long.MIN_VALUE` should be sufficient.

src/java.base/share/classes/java/text/DigitList.java line 198:

> 196:         }
> 197:         long pow10 = Math.powExact(10L, Math.max(0, decimalAt - count));
> 198:         return Math.multiplyExact(v, pow10);

These two methods throw ArithmeticException. This needs to be rethrown as NumberFormatException.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2127580172
PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2127581325

From duke at openjdk.org  Mon Jun  9 17:16:03 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 9 Jun 2025 17:16:03 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved
In-Reply-To: <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>
Message-ID: <6fAXoHW5qw6s-IzMjisZcYYQ9nxee7mZeVDJl76BW_8=.68ff17f1-01ce-4b50-b257-a6e54db79f14@github.com>

On Wed, 4 Jun 2025 23:15:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>> 
>> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
>> 
>> Testing:
>> - GHA
>> - Local run of tier 2 and jtreg:jdk/java/text
>> - New benchmark: DecimalFormatParseBench
>
> src/java.base/share/classes/java/text/DigitList.java line 198:
> 
>> 196:         }
>> 197:         long pow10 = Math.powExact(10L, Math.max(0, decimalAt - count));
>> 198:         return Math.multiplyExact(v, pow10);
> 
> These two methods throw ArithmeticException. This needs to be rethrown as NumberFormatException.

This one is a little odd. The parse methods that call `getLong` are not supposed to throw `NumberFormatException` either. So wherever `getLong` is called, it must be preceded by a check to `fitsIntoLong`, which should avoid any exceptions here. That said, rethrowing as NFE would avoid new surprises. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2127637333

From liach at openjdk.org  Mon Jun  9 17:16:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Jun 2025 17:16:04 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved
In-Reply-To: <6fAXoHW5qw6s-IzMjisZcYYQ9nxee7mZeVDJl76BW_8=.68ff17f1-01ce-4b50-b257-a6e54db79f14@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>
 <6fAXoHW5qw6s-IzMjisZcYYQ9nxee7mZeVDJl76BW_8=.68ff17f1-01ce-4b50-b257-a6e54db79f14@github.com>
Message-ID: <brpBKJEdZwELSiDmMHYv8R-grQz-Ospsu6g_bpYFLMk=.ee5f347f-5a85-4363-9614-56d8dbd22c11@github.com>

On Wed, 4 Jun 2025 23:59:38 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DigitList.java line 198:
>> 
>>> 196:         }
>>> 197:         long pow10 = Math.powExact(10L, Math.max(0, decimalAt - count));
>>> 198:         return Math.multiplyExact(v, pow10);
>> 
>> These two methods throw ArithmeticException. This needs to be rethrown as NumberFormatException.
>
> This one is a little odd. The parse methods that call `getLong` are not supposed to throw `NumberFormatException` either. So wherever `getLong` is called, it must be preceded by a check to `fitsIntoLong`, which should avoid any exceptions here. That said, rethrowing as NFE would avoid new surprises. What do you think?

I will leave this question to I18N reviewers, who are ultimately in charge of DigitList.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2127673711

From ihse at openjdk.org  Mon Jun  9 18:01:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 18:01:56 GMT
Subject: Integrated: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <IBsqcOHT6G9vQO7_iXKeYsFa4SuRwl-93HvWt9xyFZA=.6550ebd6-354f-42ae-9733-ece720f75da2@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

This pull request has now been integrated.

Changeset: 156187ac
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/156187accc1c3e2a897ced011727a5c8d8e1b0cf
Stats:     17 lines in 3 files changed: 0 ins; 4 del; 13 mod

8356978: Convert unicode sequences in Java source code to UTF-8

Co-authored-by: Alexey Ivanov <aivanov at openjdk.org>
Reviewed-by: naoto, prr, joehw

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

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

From naoto at openjdk.org  Mon Jun  9 18:56:45 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jun 2025 18:56:45 GMT
Subject: RFR: 8358626: Emit UTF-8 CLDR resources [v2]
In-Reply-To: <P7k7-80mHzOV334m1nbODa3b7hIAKEPd1ftRJNytXFQ=.b6f36e21-6ee4-44ac-95ad-2e5275d610dc@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
 <P7k7-80mHzOV334m1nbODa3b7hIAKEPd1ftRJNytXFQ=.b6f36e21-6ee4-44ac-95ad-2e5275d610dc@github.com>
Message-ID: <UbopHsJ78HDKh5nvcOwaY0B__wb6YIqGe7G1TSzhiLQ=.730a13c6-b24b-4065-86b3-f7efb38f7b6a@github.com>

On Thu, 5 Jun 2025 18:30:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   java.base/Gensrc.gmk comment

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25648#issuecomment-2956654203

From naoto at openjdk.org  Mon Jun  9 19:07:36 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jun 2025 19:07:36 GMT
Subject: Integrated: 8358626: Emit UTF-8 CLDR resources
In-Reply-To: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
Message-ID: <JfiJmieYzP39BNGLkb5tepWJBZGGDajE-fB1aNWqPfQ=.8b6c6243-b960-4c48-b65b-da1e2979564a@github.com>

On Wed, 4 Jun 2025 21:54:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)

This pull request has now been integrated.

Changeset: fcb68ea2
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fcb68ea22d020d567c560c7bd5976d3c070d9806
Stats:     6 lines in 2 files changed: 4 ins; 0 del; 2 mod

8358626: Emit UTF-8 CLDR resources

Reviewed-by: erikj, vyazici

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

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

From naoto at openjdk.org  Mon Jun  9 19:18:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jun 2025 19:18:51 GMT
Subject: RFR: 8358734: Remove JavaTimeSupplementary resource bundles
Message-ID: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>

The parallel loading of JavaTimeSupplementary was a historical artifact from the introduction of JSR 310, which additionally loads resouces that had not existed before. Since the COMPAT locale provider which relied on this mechanism has been removed, and the CLDR resource bundles now include those resources by default, removing the parallel loading mechanism simplifies the implementation

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

Commit messages:
 - Merge branch 'master' into JDK-8358734-removing-JavaTime-supplemental
 - init

Changes: https://git.openjdk.org/jdk/pull/25699/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25699&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358734
  Stats: 740 lines in 10 files changed: 263 ins; 439 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/25699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25699/head:pull/25699

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

From naoto at openjdk.org  Mon Jun  9 20:07:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jun 2025 20:07:53 GMT
Subject: RFR: 8358734: Remove JavaTimeSupplementary resource bundles [v2]
In-Reply-To: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
References: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
Message-ID: <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>

> The parallel loading of JavaTimeSupplementary was a historical artifact from the introduction of JSR 310, which additionally loads resouces that had not existed before. Since the COMPAT locale provider which relied on this mechanism has been removed, and the CLDR resource bundles now include those resources by default, removing the parallel loading mechanism simplifies the implementation

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Removed the bundle

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25699/files
  - new: https://git.openjdk.org/jdk/pull/25699/files/ad5df6ca..020535c3

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

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

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

From jlu at openjdk.org  Mon Jun  9 20:51:42 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Jun 2025 20:51:42 GMT
Subject: RFR: 8358729: jdk/internal/loader/URLClassPath/ClassnameCharTest.java
 depends on Applet
Message-ID: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>

Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.

`testclasses.jar` is updated such that the two classes no longer extend Applet.


$ javap fo\ o.class 
public class fo o {
}
$ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
public class ?? {
}


The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.

Additionally, the security APIs that were marked for removal are also removed from this test as well.

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

Commit messages:
 - init

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

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

From jlu at openjdk.org  Mon Jun  9 20:52:39 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Jun 2025 20:52:39 GMT
Subject: RFR: 8358426: Improve lazy computation in Locale [v2]
In-Reply-To: <rTqhiIsNXTejPYZE2wRgQdryau_JUVOcXbkcRipfwh8=.f5f6f1a5-e528-4d27-bc3e-4cf0afc4619c@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
 <rTqhiIsNXTejPYZE2wRgQdryau_JUVOcXbkcRipfwh8=.f5f6f1a5-e528-4d27-bc3e-4cf0afc4619c@github.com>
Message-ID: <FK3TVafBhdADbrTLUmZzOsY_VZpwdqHs_3jKRufINlo=.ae274122-2d0c-41d2-8d66-32cb63330c8b@github.com>

On Thu, 5 Jun 2025 20:29:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
>> 
>> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
>> 
>> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
>> 
>> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review - Moving all ISO resources to LocaleISOData & blessed modifier order for languageTag

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25646#issuecomment-2956999624

From jlu at openjdk.org  Mon Jun  9 20:52:40 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Jun 2025 20:52:40 GMT
Subject: RFR: 8358426: Improve lazy computation in Locale [v2]
In-Reply-To: <nXLruLQd1Zzx4tlLaTbi6VhM9epxWMyRzGo0dTv17Rc=.d239e5e9-80db-4d3a-9cb4-0adbceb97a58@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
 <rTqhiIsNXTejPYZE2wRgQdryau_JUVOcXbkcRipfwh8=.f5f6f1a5-e528-4d27-bc3e-4cf0afc4619c@github.com>
 <nXLruLQd1Zzx4tlLaTbi6VhM9epxWMyRzGo0dTv17Rc=.d239e5e9-80db-4d3a-9cb4-0adbceb97a58@github.com>
Message-ID: <J5-Bj0yCXfogXFNooEGU7JbXbFkK0pXXLeWgWJ9HH5w=.6cb25f91-b7bc-4fdc-9663-f079adac6a54@github.com>

On Sat, 7 Jun 2025 17:36:40 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review - Moving all ISO resources to LocaleISOData & blessed modifier order for languageTag
>
> src/java.base/share/classes/java/util/Locale.java line 1282:
> 
>> 1280:     public static Set<String> getISOCountries(IsoCountryCode type) {
>> 1281:         Objects.requireNonNull(type);
>> 1282:         return switch (type) {
> 
> The body of this method could also be moved to a method in `LocaleISOData`

I think it's OK as is, don't want to force re-approvals. Currently it is consistent with the other ISO related methods in `Locale`, which grab the ISO resources from `LocaleISOData` but handle some logic on their own as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25646#discussion_r2136488492

From jlu at openjdk.org  Mon Jun  9 20:52:41 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Jun 2025 20:52:41 GMT
Subject: Integrated: 8358426: Improve lazy computation in Locale
In-Reply-To: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
Message-ID: <SSKmh5EWAzYwNCj7pA_1TSf68hubP-F-xekVXq8k3WM=.a7bde6ed-7c1e-47d1-b9d0-7f65dd99c8b8@github.com>

On Wed, 4 Jun 2025 21:20:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
> 
> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
> 
> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
> 
> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.

This pull request has now been integrated.

Changeset: cd9b1bc8
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd9b1bc820540184c79dd1957edc7ad4e8e469dc
Stats:     242 lines in 3 files changed: 101 ins; 94 del; 47 mod

8358426: Improve lazy computation in Locale

Reviewed-by: naoto, liach

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

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

From bpb at openjdk.org  Mon Jun  9 21:08:49 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Jun 2025 21:08:49 GMT
Subject: RFR: 8351010: Test java/io/File/GetXSpace.java failed: / usable
 space 56380809216 > free space 14912244940
In-Reply-To: <oBcTx6T3zrjS82QX8y7EuOkhJq2nMhdu2ueXx82OpUE=.89f22d39-c873-4f7f-a633-d04751508d5a@github.com>
References: <oBcTx6T3zrjS82QX8y7EuOkhJq2nMhdu2ueXx82OpUE=.89f22d39-c873-4f7f-a633-d04751508d5a@github.com>
Message-ID: <OhF4gHin6fGtEEsL5pXL5O_UQykhoAt7Nm1Fzyi8vHc=.efac2470-9f81-4109-b647-8eade94f9f7f@github.com>

On Mon, 9 Jun 2025 21:03:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Relax testing the inequality `usable_space <= free_space` to testing the inequality `usable_space <= total_space`.

Although the native system call `statfs` (Unix) and native function `GetDiskFreeSpaceExW` (Windows) might collect the space values atomically at a given instant, the space values returned by `getFreeSpace` and `getUsableSpace` are obtained at two distinct times, hence the state of the file system might have changed in the intervening interval, and the inequality `usable_space <= free_space` cannot be reliably tested in a deterministic manner. This has caused many failures in the `GetXSpace` test, so it seems reasonable to relax the constrain to `usable_space <= free_space`. Other statistical methods could be used to test the original inequality `usable_space <= free_space`, but they all admit to some degree of randomness as to how much the file system might change in a small interval of time and are therefore open to (likely spurious) failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/25704#issuecomment-2957031060

From bpb at openjdk.org  Mon Jun  9 21:08:49 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Jun 2025 21:08:49 GMT
Subject: RFR: 8351010: Test java/io/File/GetXSpace.java failed: / usable space
 56380809216 > free space 14912244940
Message-ID: <oBcTx6T3zrjS82QX8y7EuOkhJq2nMhdu2ueXx82OpUE=.89f22d39-c873-4f7f-a633-d04751508d5a@github.com>

Relax testing the inequality `usable_space <= free_space` to testing the inequality `usable_space <= total_space`.

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

Commit messages:
 - 8351010: Test java/io/File/GetXSpace.java failed: / usable space 56380809216 > free space 14912244940

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

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

From naoto at openjdk.org  Mon Jun  9 21:47:37 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jun 2025 21:47:37 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved
In-Reply-To: <brpBKJEdZwELSiDmMHYv8R-grQz-Ospsu6g_bpYFLMk=.ee5f347f-5a85-4363-9614-56d8dbd22c11@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>
 <6fAXoHW5qw6s-IzMjisZcYYQ9nxee7mZeVDJl76BW_8=.68ff17f1-01ce-4b50-b257-a6e54db79f14@github.com>
 <brpBKJEdZwELSiDmMHYv8R-grQz-Ospsu6g_bpYFLMk=.ee5f347f-5a85-4363-9614-56d8dbd22c11@github.com>
Message-ID: <MvD5955Lp-Pe192CGu2AzaQ7V7wD52m2E_JLuMRidjg=.7c54a0c7-fb65-4c89-ac60-d90ff9ca300a@github.com>

On Thu, 5 Jun 2025 00:10:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This one is a little odd. The parse methods that call `getLong` are not supposed to throw `NumberFormatException` either. So wherever `getLong` is called, it must be preceded by a check to `fitsIntoLong`, which should avoid any exceptions here. That said, rethrowing as NFE would avoid new surprises. What do you think?
>
> I will leave this question to I18N reviewers, who are ultimately in charge of DigitList.

The existing implementation does not throw `NumberFormatException`/`ArithmeticException`, but `ParseException` if parsing is failing. I would expect the same here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2136557633

From duke at openjdk.org  Mon Jun  9 22:07:27 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 9 Jun 2025 22:07:27 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved
In-Reply-To: <MvD5955Lp-Pe192CGu2AzaQ7V7wD52m2E_JLuMRidjg=.7c54a0c7-fb65-4c89-ac60-d90ff9ca300a@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>
 <6fAXoHW5qw6s-IzMjisZcYYQ9nxee7mZeVDJl76BW_8=.68ff17f1-01ce-4b50-b257-a6e54db79f14@github.com>
 <brpBKJEdZwELSiDmMHYv8R-grQz-Ospsu6g_bpYFLMk=.ee5f347f-5a85-4363-9614-56d8dbd22c11@github.com>
 <MvD5955Lp-Pe192CGu2AzaQ7V7wD52m2E_JLuMRidjg=.7c54a0c7-fb65-4c89-ac60-d90ff9ca300a@github.com>
Message-ID: <EJN0jGyONSmv2OqjFQU5hXPq1i3bS-_Vi0FJh7HYEoc=.c9b613a3-8833-4b52-a0d3-c3168cad1701@github.com>

On Mon, 9 Jun 2025 21:45:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I will leave this question to I18N reviewers, who are ultimately in charge of DigitList.
>
> The existing implementation does not throw `NumberFormatException`/`ArithmeticException`, but `ParseException` if parsing is failing. I would expect the same here.

Sorry, I'm not seeing where the original could throw ParseException.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2136574842

From naoto at openjdk.org  Mon Jun  9 22:11:26 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jun 2025 22:11:26 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved
In-Reply-To: <EJN0jGyONSmv2OqjFQU5hXPq1i3bS-_Vi0FJh7HYEoc=.c9b613a3-8833-4b52-a0d3-c3168cad1701@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>
 <6fAXoHW5qw6s-IzMjisZcYYQ9nxee7mZeVDJl76BW_8=.68ff17f1-01ce-4b50-b257-a6e54db79f14@github.com>
 <brpBKJEdZwELSiDmMHYv8R-grQz-Ospsu6g_bpYFLMk=.ee5f347f-5a85-4363-9614-56d8dbd22c11@github.com>
 <MvD5955Lp-Pe192CGu2AzaQ7V7wD52m2E_JLuMRidjg=.7c54a0c7-fb65-4c89-ac60-d90ff9ca300a@github.com>
 <EJN0jGyONSmv2OqjFQU5hXPq1i3bS-_Vi0FJh7HYEoc=.c9b613a3-8833-4b52-a0d3-c3168cad1701@github.com>
Message-ID: <TcP37iElvBcnrVAw_9Rz9EpbWSn3MeXBWiU7aqp2Q8U=.3783fc7e-542c-4477-9aba-0af091044912@github.com>

On Mon, 9 Jun 2025 22:03:37 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> The existing implementation does not throw `NumberFormatException`/`ArithmeticException`, but `ParseException` if parsing is failing. I would expect the same here.
>
> Sorry, I'm not seeing where the original could throw ParseException.

Sorry if I was unclear. I mean the `parse()` in the NumberFormat do not throw NumberFormatException/ArithmeticException, but ParseException, so if this piece of code need to throw something, it should be `ParseException`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2136578931

From duke at openjdk.org  Mon Jun  9 22:46:50 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 9 Jun 2025 22:46:50 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v2]
In-Reply-To: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
Message-ID: <jNo1y3QVwzaJ-e2yXXZH-hFmbtRerqT4vSytEHBN2x0=.9725dfee-cd87-4739-b313-c23af309d4ea@github.com>

> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
> 
> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
> 
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  catch ArithmeticException

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25644/files
  - new: https://git.openjdk.org/jdk/pull/25644/files/a85ddd82..da9e4aea

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

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

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

From duke at openjdk.org  Mon Jun  9 22:46:50 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 9 Jun 2025 22:46:50 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v2]
In-Reply-To: <TcP37iElvBcnrVAw_9Rz9EpbWSn3MeXBWiU7aqp2Q8U=.3783fc7e-542c-4477-9aba-0af091044912@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>
 <6fAXoHW5qw6s-IzMjisZcYYQ9nxee7mZeVDJl76BW_8=.68ff17f1-01ce-4b50-b257-a6e54db79f14@github.com>
 <brpBKJEdZwELSiDmMHYv8R-grQz-Ospsu6g_bpYFLMk=.ee5f347f-5a85-4363-9614-56d8dbd22c11@github.com>
 <MvD5955Lp-Pe192CGu2AzaQ7V7wD52m2E_JLuMRidjg=.7c54a0c7-fb65-4c89-ac60-d90ff9ca300a@github.com>
 <EJN0jGyONSmv2OqjFQU5hXPq1i3bS-_Vi0FJh7HYEoc=.c9b613a3-8833-4b52-a0d3-c3168cad1701@github.com>
 <TcP37iElvBcnrVAw_9Rz9EpbWSn3MeXBWiU7aqp2Q8U=.3783fc7e-542c-4477-9aba-0af091044912@github.com>
Message-ID: <MgGR7p_lhYuMEEq4zFp_zGYx8t6yj74D-8QGbJT4Q-g=.e66bac23-0454-4a9c-9b10-b1954b8e218b@github.com>

On Mon, 9 Jun 2025 22:08:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Sorry, I'm not seeing where the original could throw ParseException.
>
> Sorry if I was unclear. I mean the `parse()` in the NumberFormat do not throw NumberFormatException/ArithmeticException, but ParseException, so if this piece of code need to throw something, it should be `ParseException`

The `parse()` methods where this code gets used in `DecimalFormat` don't throw `ParseException`. The current calls to `getLong` always are guarded with a call to `fitsIntoLong`, which should avoid any exceptions actually being thrown here. So there is no parse failure as such - instead it tries to parse it as a `double` or a `BigDecimal`. If getLong were to be called without the guard, the exception would have come from `Long.parseLong`, which throws a `NumberFormatException`.

I've added a commit to follow @liach's suggestion to at least rethrow the ArithmeticException so as to not introduce new exceptions into the mix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2136611661

From jlu at openjdk.org  Mon Jun  9 23:11:28 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Jun 2025 23:11:28 GMT
Subject: RFR: 8358734: Remove JavaTimeSupplementary resource bundles [v2]
In-Reply-To: <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
References: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
 <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
Message-ID: <tUxMODtJoAQUMb8LNstGAy_KJafVDPq6lxcj5oE4Btg=.7b999ead-f27a-42a8-bec9-dc906407ce95@github.com>

On Mon, 9 Jun 2025 20:07:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The parallel loading of JavaTimeSupplementary was a historical artifact from the introduction of JSR 310, which additionally loads resouces that had not existed before. Since the COMPAT locale provider which relied on this mechanism has been removed, and the CLDR resource bundles now include those resources by default, removing the parallel loading mechanism simplifies the implementation
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the bundle

Cleanup looks good to me.

src/java.base/share/classes/sun/util/resources/LocaleData.java line 214:

> 212:                 int lastDot = baseName.lastIndexOf('.');
> 213:                 String category = (lastDot >= 0) ? baseName.substring(lastDot + 1) : baseName;
> 214:                 if (adapter instanceof JRELocaleProviderAdapter jlpa) {

For safety, should we have some type of failure if this is not true, similar to the previous `CCE`.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25699#pullrequestreview-2911552652
PR Review Comment: https://git.openjdk.org/jdk/pull/25699#discussion_r2136628185

From naoto at openjdk.org  Mon Jun  9 23:44:35 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jun 2025 23:44:35 GMT
Subject: RFR: 8358734: Remove JavaTimeSupplementary resource bundles [v2]
In-Reply-To: <tUxMODtJoAQUMb8LNstGAy_KJafVDPq6lxcj5oE4Btg=.7b999ead-f27a-42a8-bec9-dc906407ce95@github.com>
References: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
 <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
 <tUxMODtJoAQUMb8LNstGAy_KJafVDPq6lxcj5oE4Btg=.7b999ead-f27a-42a8-bec9-dc906407ce95@github.com>
Message-ID: <Vk7hNIfDsLnyIrQ-inuFWIwSUJcJuIPYKAHiPPrv58M=.8ebdad86-29bf-4564-84b6-3054a099d549@github.com>

On Mon, 9 Jun 2025 22:57:24 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed the bundle
>
> src/java.base/share/classes/sun/util/resources/LocaleData.java line 214:
> 
>> 212:                 int lastDot = baseName.lastIndexOf('.');
>> 213:                 String category = (lastDot >= 0) ? baseName.substring(lastDot + 1) : baseName;
>> 214:                 if (adapter instanceof JRELocaleProviderAdapter jlpa) {
> 
> For safety, should we have some type of failure if this is not true, similar to the previous `CCE`.

I think this is acceptable.  If, for some reason, `adapter` is not an instance, it will simply be ignored. That cast was a mere artifact from a time before we had this `instanceof` construct and we knew it wouldn't throw a CCE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25699#discussion_r2136674459

From jlu at openjdk.org  Mon Jun  9 23:48:29 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Jun 2025 23:48:29 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v2]
In-Reply-To: <jNo1y3QVwzaJ-e2yXXZH-hFmbtRerqT4vSytEHBN2x0=.9725dfee-cd87-4739-b313-c23af309d4ea@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <jNo1y3QVwzaJ-e2yXXZH-hFmbtRerqT4vSytEHBN2x0=.9725dfee-cd87-4739-b313-c23af309d4ea@github.com>
Message-ID: <Du9MYXbdEwDCcfImykmsIkXrXYB59O2VZwd3bH3YbNk=.c77cc3ab-5a5f-457e-9239-a23127587cf4@github.com>

On Mon, 9 Jun 2025 22:46:50 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>> 
>> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
>> 
>> Testing:
>> - GHA
>> - Local run of tier 2 and jtreg:jdk/java/text
>> - New benchmark: DecimalFormatParseBench
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   catch ArithmeticException

Thanks for the improvements. I think we need to prioritize behavioral compatibility with this change, so we will want to run the JCK tests as well for the extra safety.

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 134:

> 132:      * @return The double-precision value of the conversion
> 133:      */
> 134:     public static double parseDoubleDigits(int decExp, char[] digits, int length) throws NumberFormatException {

I don't think this method needs to declare `NFE` in the signature since it is not reading in any strings so it should not throw.

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1848:

> 1846:             buf[i] = (byte) digits[i];
> 1847:         }
> 1848:         return new ASCIIToBinaryBuffer(false, decExp, buf, length);

Since `negSign` is always false, adding a _positive_ somewhere to the method name might be helpful/explicit. Although you could argue that the array parameter itself is telling enough, but one could misinterpret the char array as including a sign character.

test/jdk/java/text/Format/DecimalFormat/CloneTest.java line 98:

> 96:                 }
> 97: 
> 98:                 Object tempBuilder = valFromDigitList(original, "tempBuilder");

Since this is required as a direct result of this change, I think that warrants adding the JBS bug ID to the Jtreg header.

test/micro/org/openjdk/bench/java/text/DecimalFormatParseBench.java line 28:

> 26: import java.text.DecimalFormat;
> 27: import java.text.ParseException;
> 28: import java.util.Locale;

Looks unused.

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

PR Review: https://git.openjdk.org/jdk/pull/25644#pullrequestreview-2911579886
PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2136657118
PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2136676237
PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2136643849
PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2136644390

From joehw at openjdk.org  Tue Jun 10 01:13:27 2025
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 10 Jun 2025 01:13:27 GMT
Subject: RFR: 8358734: Remove JavaTimeSupplementary resource bundles [v2]
In-Reply-To: <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
References: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
 <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
Message-ID: <qKaksraWAM6-ppA3k3DS4qGMZ4fFxLLB4nWjUJxssws=.a29f1fe1-b447-41da-981f-1296171a250d@github.com>

On Mon, 9 Jun 2025 20:07:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The parallel loading of JavaTimeSupplementary was a historical artifact from the introduction of JSR 310, which additionally loads resouces that had not existed before. Since the COMPAT locale provider which relied on this mechanism has been removed, and the CLDR resource bundles now include those resources by default, removing the parallel loading mechanism simplifies the implementation
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the bundle

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25699#pullrequestreview-2911715083

From iris at openjdk.org  Tue Jun 10 01:40:27 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 10 Jun 2025 01:40:27 GMT
Subject: RFR: 8358734: Remove JavaTimeSupplementary resource bundles [v2]
In-Reply-To: <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
References: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
 <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
Message-ID: <1qohGcWf_E6w7vdFzI5wYF_lx9mGr5q9QOffb3l-olI=.517a6473-afb8-427f-b3dd-0065ecc6443d@github.com>

On Mon, 9 Jun 2025 20:07:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The parallel loading of JavaTimeSupplementary was a historical artifact from the introduction of JSR 310, which additionally loads resouces that had not existed before. Since the COMPAT locale provider which relied on this mechanism has been removed, and the CLDR resource bundles now include those resources by default, removing the parallel loading mechanism simplifies the implementation
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the bundle

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25699#pullrequestreview-2911742189

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

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

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

keep alive

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

PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2957461147

From duke at openjdk.org  Tue Jun 10 02:31:06 2025
From: duke at openjdk.org (He-Pin (kerr))
Date: Tue, 10 Jun 2025 02:31:06 GMT
Subject: RFR: 8359067: Fix typo in DelayScheduler.java
Message-ID: <CvaLMuKZ72CTQVOaAxeJyS8pGWcbev9SwyTkwpiSiBs=.61a0a2ce-6816-45a0-bd84-85c6ed7ecf23@github.com>

Rename auxilliary to  auxiliary

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

Commit messages:
 - chore: Fix typo in DelayScheduler

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

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

From syan at openjdk.org  Tue Jun 10 02:31:06 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 10 Jun 2025 02:31:06 GMT
Subject: RFR: 8359067: Fix typo in DelayScheduler.java
In-Reply-To: <CvaLMuKZ72CTQVOaAxeJyS8pGWcbev9SwyTkwpiSiBs=.61a0a2ce-6816-45a0-bd84-85c6ed7ecf23@github.com>
References: <CvaLMuKZ72CTQVOaAxeJyS8pGWcbev9SwyTkwpiSiBs=.61a0a2ce-6816-45a0-bd84-85c6ed7ecf23@github.com>
Message-ID: <scUQrx1cFua00C_k31V6ohaH3egBFB5HZmMa4DLDrcE=.7ec7352e-968f-4e2b-9a0b-f1789cda4361@github.com>

On Sun, 8 Jun 2025 09:07:11 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

> Rename auxilliary to  auxiliary

Marked as reviewed by syan (Committer).

What does `chore` mean

I create a JBS issue for this PR

https://bugs.openjdk.org/browse/JDK-8359067, you should change the PR title to "8359067: Fix typo in DelayScheduler.java"

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

PR Review: https://git.openjdk.org/jdk/pull/25685#pullrequestreview-2911690691
PR Comment: https://git.openjdk.org/jdk/pull/25685#issuecomment-2957387930
PR Comment: https://git.openjdk.org/jdk/pull/25685#issuecomment-2957394184

From fyang at openjdk.org  Tue Jun 10 02:43:34 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 10 Jun 2025 02:43:34 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v8]
In-Reply-To: <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
Message-ID: <PCXl2eBZh-Wpx0JeLOXUn_0h7EYTMb54smymVVaokBQ=.49090c1a-a82d-4e1d-9722-7a2748400642@github.com>

On Fri, 6 Jun 2025 10:38:11 GMT, erifan <duke at openjdk.org> wrote:

>> This patch optimizes the following patterns:
>> For integer types:
>> 
>> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> 
>> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond.
>> 
>> For float and double types:
>> 
>> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> 
>> cond can be eq or ne.
>> 
>> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`:
>> 
>> Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>> testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>> testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>> testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>> testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>> testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>> testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>> testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>> testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>> testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
>> testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
>> testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
>> testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
>> testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
>> testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
>> testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
>> testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
>> testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
>> testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
>> testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
>> testCompareLTMaskNotInt		ops/s	16721...
>
> erifan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Support negating unsigned comparison for BoolTest::mask
>   
>   Added a static method `negate_mask(mask btm)` into BoolTest class to
>   negate both signed and unsigned comparison.

FYI: I submitted to testing in QEMU-system / Ubuntu 25.04 (fastdebug jdk build and 256-bit RVV) and I see `compiler/vectorization`, `compiler/vectorapi` and `jdk_vector` tests are passing.

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

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

From duke at openjdk.org  Tue Jun 10 03:18:29 2025
From: duke at openjdk.org (erifan)
Date: Tue, 10 Jun 2025 03:18:29 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v8]
In-Reply-To: <PCXl2eBZh-Wpx0JeLOXUn_0h7EYTMb54smymVVaokBQ=.49090c1a-a82d-4e1d-9722-7a2748400642@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
 <PCXl2eBZh-Wpx0JeLOXUn_0h7EYTMb54smymVVaokBQ=.49090c1a-a82d-4e1d-9722-7a2748400642@github.com>
Message-ID: <45vF6n57b-4myKJ0sMUgkcMqeXfveOsRfx3oDhmAMvM=.4be42b00-297a-4b89-af87-49bf86369828@github.com>

On Tue, 10 Jun 2025 02:38:29 GMT, Fei Yang <fyang at openjdk.org> wrote:

> FYI: I submitted to testing in QEMU-system / Ubuntu 25.04 (fastdebug jdk build and 256-bit RVV) and I see `compiler/vectorization`, `compiler/vectorapi` and `jdk_vector` tests are passing.

Thank you very much!

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

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

From duke at openjdk.org  Tue Jun 10 07:52:29 2025
From: duke at openjdk.org (Alice Pellegrini)
Date: Tue, 10 Jun 2025 07:52:29 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <v45mu9Zly3T9l94b-WP1p_4oB_Y2Pe0gdU6C3w_vRqM=.ebaa8261-3d70-43a1-82b2-bba9def061a2@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
 <NBeas7VSHxEynwU9LXuGy-p9Lg9Tm5I9auSaHBExzRA=.effd0ad3-a5f2-4049-b4df-49030a0502ef@github.com>
 <v45mu9Zly3T9l94b-WP1p_4oB_Y2Pe0gdU6C3w_vRqM=.ebaa8261-3d70-43a1-82b2-bba9def061a2@github.com>
Message-ID: <8pLm1mah1JKonu3z5tWwIpU_J5jEggSiBst-PNEdG4s=.931782e4-3e34-4535-bc71-622d76b871a7@github.com>

On Mon, 9 Jun 2025 04:03:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/lib/jdk/test/lib/process/OutputBuffer.java line 150:
>> 
>>> 148:       this.p = p;
>>> 149:       logProgress("Gathering output");
>>> 150:       boolean verbose = Boolean.getBoolean("outputanalyzer.verbose");
>> 
>> Putting a system property at this level of the code kind of hides the functionality.
>> 
>> An alternative solution would be to have `OutputAnalyzer` constructor(s) that takes a boolean argument. That boolean could be set as needed by individual tests using the `test.debug` property already used by a lot of tests.
>
> But isn't it the person running the tests that wants to set this, not an inherent property of a test itself? Or are you envisaging enabling it at the test-level so the person running the tests doesn't have to do so? But then how does that affect the overall jtreg log content. ??

To add on this, I should mention that I noticed a lot of tests are using OutputAnalyzer indirectly, returned as a result of a utility function, for example `ProcessTools.execute{Process,Command)`


git grep -E "ProcessTools.execute((Process)|(Command))" | wc -l
     351


Instead of calling one of OutputAnalyzer's constructors (700 invocations, but many of them are with the Eager, string based and not process based, constructor, which we don't care about)


I'm not sure adding additional parameters also to that code is an ideal solution, I'd much prefer adding the command line parameter to the docs of the OutputAnalyzer class, so that one knows to enable it when running the single test through jtreg

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2137161838

From cstein at openjdk.org  Tue Jun 10 08:18:34 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 10 Jun 2025 08:18:34 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment
In-Reply-To: <1aNuDmukQdUIs83wrKGgzmEHIOgMMUtTtePU9dHsUyE=.6b73641a-ab98-4b37-af3d-08b06d73533b@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
 <tO_z8q0cawzrkDP_z__sUZbM2sWejgIHdwksIbFboUI=.1b657729-6541-4310-9117-d4f7f0d75a7a@github.com>
 <4Xzu7FifgELCGKkOTBMCpcgYwwKuqymJBpMSQHVFbcA=.95d8329e-453e-439f-a628-149ce8c22a51@github.com>
 <1aNuDmukQdUIs83wrKGgzmEHIOgMMUtTtePU9dHsUyE=.6b73641a-ab98-4b37-af3d-08b06d73533b@github.com>
Message-ID: <IqvVkOj7xntKKswD9SJsGwSyI7gDgHYHWfCrkgh1zjY=.0dbce17a-81e5-41e5-8bfd-a95d01230b3e@github.com>

On Mon, 2 Jun 2025 16:03:49 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> right I agree that if there is common code we should extract it in a helper method
>
> Or the handling of `#` can be merged with the previous case ... somehow.

Extracting a method wouldn't really simplify the code, as many local variables are in play.

Merging the cases also ends up in more if-else constructs in the case block that counter-act readability.

So, perhaps, the duplication is goog-enough here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2137227216

From pminborg at openjdk.org  Tue Jun 10 09:06:07 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Jun 2025 09:06:07 GMT
Subject: RFR: 8345292: Improve javadocs for MemorySegment::getStrings defining
 word boundary cases
Message-ID: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>

This PR proposes to improve the 'MemorySegment.getString(long offset, Charset charset)` method documentation with respect to multi-octet concerns.

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

Commit messages:
 - Add info for multi-octet Charsets

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

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

From vklang at openjdk.org  Tue Jun 10 09:14:34 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 10 Jun 2025 09:14:34 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v2]
In-Reply-To: <8r28eulzOwmt6cxFjNPLg5zujXD1o1CEiPUqP4dHxvM=.3b8e608a-b97c-4ebd-8094-6e2e6d8f33e1@github.com>
References: <iGlPHf8dSXOGgy-Qby4L6bwR_ZfAMVEETLqpnPVN3NQ=.64a2d77a-fb3b-4ee9-89f3-298610dba273@github.com>
 <8r28eulzOwmt6cxFjNPLg5zujXD1o1CEiPUqP4dHxvM=.3b8e608a-b97c-4ebd-8094-6e2e6d8f33e1@github.com>
Message-ID: <rz99etMtDH0Yvh1SFu3T2eigx5Q0I1kH1gp-IPDTfMA=.6079c227-bc08-44e1-a374-32da6644ff27@github.com>

On Thu, 15 May 2025 23:59:41 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with Cleaner.
>> 
>> (The [first PR](https://github.com/openjdk/jdk/pull/8311) for this fix started some substantial discussions, leading to, among other things, the [8314480](https://bugs.openjdk.org/browse/JDK-8314480) `java.lang.ref` memory ordering spec update.)
>> 
>> In standard fashion, pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved into a _Context_ object. From there, the change is fairly mechanical.
>> 
>> Details of note:
>> 
>> 1. Some operations need to change the state values (the `update()` method is probably the most interesting). Use of `reachabilityFence()` ensures memory visibility on the Cleaner thread (per the aforementioned spec update).
>> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's state.
>> 
>> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. It confirms that the use of Cleaner does not keep an `LdapSearchEnumeration` object reachable. The other `AbstractLdapNamingEnumeration` subclasses (`LdapNamingEnumeration` and `LdapBindingEnumeration`) can be expected to behave the same.
>> 
>> Thanks.
>> 
>> **Edit: (Re)viewers: due to there being a lot of indentation changes, you might consider enabling the "Hide whitespace" option on the "Files changed" tab. To my eye, it gives a better view of the changes.**
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright

src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 142:

> 140:             this.enumCtx = new EnumCtx(homeCtx, answer, homeCtx.clnt);
> 141:             // Ensures that context won't get closed from underneath us
> 142:             this.enumCtx.homeCtx.incEnumCount();

@bchristi-git Would it make sense to increment this in the EnumCtx ctor instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25242#discussion_r2137343209

From vklang at openjdk.org  Tue Jun 10 09:25:31 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 10 Jun 2025 09:25:31 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v2]
In-Reply-To: <8r28eulzOwmt6cxFjNPLg5zujXD1o1CEiPUqP4dHxvM=.3b8e608a-b97c-4ebd-8094-6e2e6d8f33e1@github.com>
References: <iGlPHf8dSXOGgy-Qby4L6bwR_ZfAMVEETLqpnPVN3NQ=.64a2d77a-fb3b-4ee9-89f3-298610dba273@github.com>
 <8r28eulzOwmt6cxFjNPLg5zujXD1o1CEiPUqP4dHxvM=.3b8e608a-b97c-4ebd-8094-6e2e6d8f33e1@github.com>
Message-ID: <vnkWGkqN_FD8SRmAoo4QHA5kDfW5iOcJRzLmMHDCEKA=.4fccee1e-a974-4a00-98fa-a94c2ae38771@github.com>

On Thu, 15 May 2025 23:59:41 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with Cleaner.
>> 
>> (The [first PR](https://github.com/openjdk/jdk/pull/8311) for this fix started some substantial discussions, leading to, among other things, the [8314480](https://bugs.openjdk.org/browse/JDK-8314480) `java.lang.ref` memory ordering spec update.)
>> 
>> In standard fashion, pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved into a _Context_ object. From there, the change is fairly mechanical.
>> 
>> Details of note:
>> 
>> 1. Some operations need to change the state values (the `update()` method is probably the most interesting). Use of `reachabilityFence()` ensures memory visibility on the Cleaner thread (per the aforementioned spec update).
>> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's state.
>> 
>> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. It confirms that the use of Cleaner does not keep an `LdapSearchEnumeration` object reachable. The other `AbstractLdapNamingEnumeration` subclasses (`LdapNamingEnumeration` and `LdapBindingEnumeration`) can be expected to behave the same.
>> 
>> Thanks.
>> 
>> **Edit: (Re)viewers: due to there being a lot of indentation changes, you might consider enabling the "Hide whitespace" option on the "Files changed" tab. To my eye, it gives a better view of the changes.**
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright

src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 394:

> 392:     @SuppressWarnings("removal")
> 393:     protected final void finalize() {
> 394:         cleanup();

?

src/java.naming/share/classes/com/sun/jndi/ldap/LdapSearchEnumeration.java line 59:

> 57:         // super() call (aka AbstrctLdapNamingEnumeration ctor) keeps 'this'
> 58:         // reachable until end of Cleaner registration. Code after that
> 59:         // clearly does not touch cleanable state.

@bchristi-git I fear this could be a brittle assumption. Would an extra reachabilityFence here hurt?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25242#discussion_r2137360174
PR Review Comment: https://git.openjdk.org/jdk/pull/25242#discussion_r2137365068

From vklang at openjdk.org  Tue Jun 10 10:20:31 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 10 Jun 2025 10:20:31 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v6]
In-Reply-To: <ooPu9wL4j0HOvuZd0etBF767JWdlSRruQIc3PFGemp0=.33a2288f-2c31-45bd-a00f-9f6f9f254752@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <ooPu9wL4j0HOvuZd0etBF767JWdlSRruQIc3PFGemp0=.33a2288f-2c31-45bd-a00f-9f6f9f254752@github.com>
Message-ID: <zAt8cFmoPvvu-LFuqrVGy_hwWith9mXifxV0IHhas1s=.04114209-3213-4526-b0f5-f3fd5b87c1e7@github.com>

On Mon, 9 Jun 2025 16:53:07 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 hol...
>
> kabutz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace

@kabutz Thanks for the updates, this is really looking good now. I added some suggestions for edits to avoid a couple of volatile reads, which I think makes sense for Aarch64-based systems (as we're already updating the code).

src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 215:

> 213:         // assert lock.isHeldByCurrentThread();
> 214:         if (count >= capacity)
> 215:             return false;

Suggestion:

        int c;
        if ((c = count) >= capacity)
            return false;

src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 225:

> 223:         ++count;
> 224:         notEmpty.signal();
> 225:         return true;

Suggestion:

        count = c + 1;
        notEmpty.signal();
        return true;

src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 236:

> 234:         // assert lock.isHeldByCurrentThread();
> 235:         if (count >= capacity)
> 236:             return false;

Suggestion:

        int c;
        if ((c = count) >= capacity)
            return false;

src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 246:

> 244:         ++count;
> 245:         notEmpty.signal();
> 246:         return true;

Suggestion:

        count = c + 1;
        notEmpty.signal();
        return true;

test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java line 1967:

> 1965: 
> 1966:     public void testWeaklyConsistentIterationWithIteratorRemove() {
> 1967:         final LinkedBlockingDeque<Item> q = new LinkedBlockingDeque<>(15);

@kabutz Would 5 suffice?

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

PR Review: https://git.openjdk.org/jdk/pull/24925#pullrequestreview-2912857958
PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2137473157
PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2137473540
PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2137471349
PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2137472031
PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2137478626

From jpai at openjdk.org  Tue Jun 10 10:31:45 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Jun 2025 10:31:45 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v2]
In-Reply-To: <VK3OPea665iZC9L0afD3lLokdgrTbNj_kbiYZFe2Xf8=.885395b6-9daa-421b-8c5a-09722b236052@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
 <VK3OPea665iZC9L0afD3lLokdgrTbNj_kbiYZFe2Xf8=.885395b6-9daa-421b-8c5a-09722b236052@github.com>
Message-ID: <USriuw2Xh65pMGKkP2rtqvWiOfWEs_8hj_V18XdgH9A=.f0225d4f-95e2-4a10-9514-a4c595dc6035@github.com>

On Fri, 25 Apr 2025 19:07:37 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: add missing <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
>>  - http3: Artur's review - make methods package private
>>  - http3: qpack - allow 0 capacity when max capacity is 0
>>  - Remove flow control from stream limit comments
>>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe
>
> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 192:
> 
>> 190:      */
>> 191:     static AlgorithmConstraints forQUIC(QuicTLSEngine engine,
>> 192:                                         String[] allowedAlgorithms,
> 
> This should probably be renamed to `supportedAlgorithms` for consistency, to match SSLEngine and SSLSocket methods.

Done, the PR has been updated to rename this to supportedAlgorithms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2137500358

From dl at openjdk.org  Tue Jun 10 10:35:30 2025
From: dl at openjdk.org (Doug Lea)
Date: Tue, 10 Jun 2025 10:35:30 GMT
Subject: RFR: 8359067: Fix typo in DelayScheduler.java
In-Reply-To: <CvaLMuKZ72CTQVOaAxeJyS8pGWcbev9SwyTkwpiSiBs=.61a0a2ce-6816-45a0-bd84-85c6ed7ecf23@github.com>
References: <CvaLMuKZ72CTQVOaAxeJyS8pGWcbev9SwyTkwpiSiBs=.61a0a2ce-6816-45a0-bd84-85c6ed7ecf23@github.com>
Message-ID: <FqUvPVccGUFEb7zrMfTn7_qDobXncxi-MbNuUXUMQLE=.35cd1ecc-3ef5-4290-af97-1745bf960f23@github.com>

On Sun, 8 Jun 2025 09:07:11 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

> Rename auxilliary to  auxiliary

Thanks for finding and fixing this.

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

Marked as reviewed by dl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25685#pullrequestreview-2912920005

From duke at openjdk.org  Tue Jun 10 12:08:41 2025
From: duke at openjdk.org (Abhishek N)
Date: Tue, 10 Jun 2025 12:08:41 GMT
Subject: Withdrawn: 8355393: Create a Test case to have special cases coverage
 for currency.getInstance()
In-Reply-To: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
Message-ID: <4YE0Py2WUEbdDOUOxLosrGdYiDUUL7Mk40yRv5l04j0=.ba7cfefa-531c-4ea2-b610-dfa0a09dc24a@github.com>

On Tue, 6 May 2025 07:25:36 GMT, Abhishek N <duke at openjdk.org> wrote:

> Create a Test case to have special cases coverage for currency.getInstance().
> 
> The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API.
> 
> test results:
> 
> jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java
> Directory "JTwork" not found: creating
> Directory "JTreport" not found: creating
> Test results: passed: 1
> Report written to JTreport\html\report.html
> Results written to JTwork

This pull request has been closed without being integrated.

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

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

From rriggs at openjdk.org  Tue Jun 10 13:28:32 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 10 Jun 2025 13:28:32 GMT
Subject: RFR: 8359067: Fix typo in DelayScheduler.java
In-Reply-To: <CvaLMuKZ72CTQVOaAxeJyS8pGWcbev9SwyTkwpiSiBs=.61a0a2ce-6816-45a0-bd84-85c6ed7ecf23@github.com>
References: <CvaLMuKZ72CTQVOaAxeJyS8pGWcbev9SwyTkwpiSiBs=.61a0a2ce-6816-45a0-bd84-85c6ed7ecf23@github.com>
Message-ID: <q7RF1IKVJtgfxIoLo02tAuY8mrevy-JDDMgpwZCkcBw=.2077d756-d362-4206-bd04-fb16b8c5752e@github.com>

On Sun, 8 Jun 2025 09:07:11 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

> Rename auxilliary to  auxiliary

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25685#pullrequestreview-2913582933

From tschatzl at openjdk.org  Tue Jun 10 13:33:27 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 10 Jun 2025 13:33:27 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v39]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <dbgVIxaLhZIz3-6qkuM7QOnBwh7k88E00pCXejUGzrE=.68761112-3f5e-4ca0-9d89-d2aa912c021f@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits:

 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review: remove sweep_epoch
 - Merge branch 'master' into card-table-as-dcq-merge
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review (part 2 - yield duration changes)
 - * ayang review (part 1)
 - * indentation fix
 - * remove support for 32 bit x86 in the barrier generation code, following latest changes from @shade
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - ... and 45 more: https://git.openjdk.org/jdk/compare/0582bd29...c07a73db

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=38
  Stats: 7085 lines in 111 files changed: 2568 ins; 3599 del; 918 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

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

From vklang at openjdk.org  Tue Jun 10 13:34:33 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 10 Jun 2025 13:34:33 GMT
Subject: RFR: 8359067: Fix typo in DelayScheduler.java
In-Reply-To: <CvaLMuKZ72CTQVOaAxeJyS8pGWcbev9SwyTkwpiSiBs=.61a0a2ce-6816-45a0-bd84-85c6ed7ecf23@github.com>
References: <CvaLMuKZ72CTQVOaAxeJyS8pGWcbev9SwyTkwpiSiBs=.61a0a2ce-6816-45a0-bd84-85c6ed7ecf23@github.com>
Message-ID: <BDbPlzEIzYhA78Nfa8xjiXiI3rWyIkAcOXlGHQ2ifs0=.590f91bf-8417-4130-843d-aff46ec00ebf@github.com>

On Sun, 8 Jun 2025 09:07:11 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

> Rename auxilliary to  auxiliary

Marked as reviewed by vklang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25685#pullrequestreview-2913606115

From duke at openjdk.org  Tue Jun 10 15:41:47 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 10 Jun 2025 15:41:47 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v3]
In-Reply-To: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
Message-ID: <-6TYWikmLNBtyQt6_xeJ8KoziHxA8Ijr067NIc740X0=.2f9e4cae-7f39-46b8-b3a9-f381fb2e0518@github.com>

> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
> 
> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
> 
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25644/files
  - new: https://git.openjdk.org/jdk/pull/25644/files/da9e4aea..6953dcfc

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

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

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

From naoto at openjdk.org  Tue Jun 10 15:49:38 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 10 Jun 2025 15:49:38 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v3]
In-Reply-To: <MgGR7p_lhYuMEEq4zFp_zGYx8t6yj74D-8QGbJT4Q-g=.e66bac23-0454-4a9c-9b10-b1954b8e218b@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>
 <6fAXoHW5qw6s-IzMjisZcYYQ9nxee7mZeVDJl76BW_8=.68ff17f1-01ce-4b50-b257-a6e54db79f14@github.com>
 <brpBKJEdZwELSiDmMHYv8R-grQz-Ospsu6g_bpYFLMk=.ee5f347f-5a85-4363-9614-56d8dbd22c11@github.com>
 <MvD5955Lp-Pe192CGu2AzaQ7V7wD52m2E_JLuMRidjg=.7c54a0c7-fb65-4c89-ac60-d90ff9ca300a@github.com>
 <EJN0jGyONSmv2OqjFQU5hXPq1i3bS-_Vi0FJh7HYEoc=.c9b613a3-8833-4b52-a0d3-c3168cad1701@github.com>
 <TcP37iElvBcnrVAw_9Rz9EpbWSn3MeXBWiU7aqp2Q8U=.3783fc7e-542c-4477-9aba-0af091044912@github.com>
 <MgGR7p_lhYuMEEq4zFp_zGYx8t6yj74D-8QGbJT4Q-g=.e66bac23-0454-4a9c-9b10-b1954b8e218b@github.com>
Message-ID: <50Iv4eohLdoAeHlQ5bwh4CCPKuuLJJu46P_jcE4JJ84=.9271d6a9-a420-4382-b5bc-4e88620e3f00@github.com>

On Mon, 9 Jun 2025 22:41:21 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Sorry if I was unclear. I mean the `parse()` in the NumberFormat do not throw NumberFormatException/ArithmeticException, but ParseException, so if this piece of code need to throw something, it should be `ParseException`
>
> The `parse()` methods where this code gets used in `DecimalFormat` unfortunately don't throw `ParseException`. The current calls to `getLong` always are guarded with a call to `fitsIntoLong`, which should avoid any exceptions actually being thrown here. So there is no parse failure as such - instead it tries to parse it as a `double` or a `BigDecimal`. If getLong were to be called without the guard, the exception would have come from `Long.parseLong`, which throws a `NumberFormatException`.
> 
> I've added a commit to follow @liach's suggestion to at least handle the ArithmeticException so as to not introduce new exceptions into the mix.

OK, sounds reasonable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2138252488

From jean-noel.rouvignac at pingidentity.com  Tue Jun 10 15:50:16 2025
From: jean-noel.rouvignac at pingidentity.com (=?UTF-8?Q?Jean=2DNo=C3=ABl_Rouvignac?=)
Date: Tue, 10 Jun 2025 17:50:16 +0200
Subject: javac confused by generics on class?
Message-ID: <CABw-sUJXEOm2AMkKT2Dp3sPDS=up3jgzRG4Rcd6rZ+wZB69JiQ@mail.gmail.com>

Hello,

When doing refactorings to take advantage of newer Java features, I hit a
new and weird edge case. I trimmed down the code several times, and ended
up with the following tiny reproducer, and I don't understand what javac is
complaining about even with javac 24:

(Note: unlike the original code, this reproducer is very contrived, so
there's no need to make comments on how bad it is: I fully agree)

```java
1 import java.util.ArrayList;
import java.util.List;
import java.util.stream.Collectors;

public class Main {
    private static final class Child<T> {
        public List<String> getValues() {
            return new ArrayList<>();
        }
    }

    @SuppressWarnings("unchecked")
    private static String getString1(Child c) {
        // Compilation error:
        // Main.java:16: error: incompatible types: Object cannot be
converted to String
        return c.getValues().stream().collect(Collectors.joining());
    }

    private static String getString2(Child c) {
        // Compilation error:
        // Main.java:27: warning: [unchecked] unchecked conversion
        //        List<String> values = c.getValues();
        //                                         ^
        //  required: List<String>
        //  found:    List
        //1 warning
        List<String> values = c.getValues();
        return values.stream().collect(Collectors.joining());
    }
}
```

It turns out IntelliJ is a bit more eloquent than javac, and when hovering
over the warning on `c.getValues()` at the line with `List<String> values =
c.getValues();`, it reports the following:

>    Unchecked assignment: 'java.util.List' to
'java.util.List<java.lang.String>'. Reason: 'c' has raw type, so result of
getValues is erased

Is it possible that javac is doing early type erasure when analysing this
code, erasing a bit too much? Even if the code uses `Child` without type
argument, I would expect the return type of `getValues()` to be well
defined as `List<String>`?

What do you think?
I am sure there is some rational explanation that I missed for this
behaviour. I could not find a JBS issue showing the same case as here.

Thank you,
Jean-No?l Rouvignac

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.? If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250610/6785c172/attachment-0001.htm>

From mcimadamore at openjdk.org  Tue Jun 10 15:53:34 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 10 Jun 2025 15:53:34 GMT
Subject: RFR: 8345292: Improve javadocs for MemorySegment::getStrings
 defining word boundary cases
In-Reply-To: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
References: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
Message-ID: <JI1egGZkcWn1hBX2tqX3YofFfcrYZLDvd1aafvOUKC8=.b1a9b9e1-b474-46c4-a47b-5fce46e0e72d@github.com>

On Tue, 10 Jun 2025 09:01:17 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset charset)` method documentation with respect to multi-octet concerns.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1301:

> 1299:      * <p>
> 1300:      * If the {@linkplain #byteSize()} of this segment is not evenly dividable by the
> 1301:      * number of octets used by provided {@code charset}, the reminding bytes of this

`the remaining bytes of this segment are not accessed`

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1302:

> 1300:      * If the {@linkplain #byteSize()} of this segment is not evenly dividable by the
> 1301:      * number of octets used by provided {@code charset}, the reminding bytes of this
> 1302:      * segment is not accessed. For multi-octet charset, nulls are only detected on

Elsewhere in the javadoc we say string terminator/terminator char. The mention of `null` is surprising here.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1303:

> 1301:      * number of octets used by provided {@code charset}, the reminding bytes of this
> 1302:      * segment is not accessed. For multi-octet charset, nulls are only detected on
> 1303:      * multi-octet-aligned boundaries.

This feels like an implementation note rather that something that belongs to the javadoc?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25715#discussion_r2138255612
PR Review Comment: https://git.openjdk.org/jdk/pull/25715#discussion_r2138258190
PR Review Comment: https://git.openjdk.org/jdk/pull/25715#discussion_r2138259170

From duke at openjdk.org  Tue Jun 10 15:54:18 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 10 Jun 2025 15:54:18 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v7]
In-Reply-To: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
Message-ID: <P-Dmw_vChbKRQzN95NjoswHh7Y4eO1fR8MhNwxj1rKo=.a6939762-2c0a-457d-94d9-ce34ce053ef1@github.com>

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

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

  Reduced volatile reads
  
  Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24925/files
  - new: https://git.openjdk.org/jdk/pull/24925/files/27b05362..5faf1f11

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

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

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

From duke at openjdk.org  Tue Jun 10 16:03:48 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 10 Jun 2025 16:03:48 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v6]
In-Reply-To: <zAt8cFmoPvvu-LFuqrVGy_hwWith9mXifxV0IHhas1s=.04114209-3213-4526-b0f5-f3fd5b87c1e7@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <ooPu9wL4j0HOvuZd0etBF767JWdlSRruQIc3PFGemp0=.33a2288f-2c31-45bd-a00f-9f6f9f254752@github.com>
 <zAt8cFmoPvvu-LFuqrVGy_hwWith9mXifxV0IHhas1s=.04114209-3213-4526-b0f5-f3fd5b87c1e7@github.com>
Message-ID: <RdQsQi_DmAN9npLH0V1b8S5uhjVaxqaoS9u5xXWnCrc=.7eebae81-636d-4730-b74a-ce057f257543@github.com>

On Tue, 10 Jun 2025 10:13:20 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> kabutz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Whitespace
>
> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 225:
> 
>> 223:         ++count;
>> 224:         notEmpty.signal();
>> 225:         return true;
> 
> Suggestion:
> 
>         count = c + 1;
>         notEmpty.signal();
>         return true;

Good idea

> test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java line 1967:
> 
>> 1965: 
>> 1966:     public void testWeaklyConsistentIterationWithIteratorRemove() {
>> 1967:         final LinkedBlockingDeque<Item> q = new LinkedBlockingDeque<>(15);
> 
> @kabutz Would 5 suffice?

I've removed the sizes - they served no purpose.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2138276297
PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2138279198

From duke at openjdk.org  Tue Jun 10 16:03:47 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 10 Jun 2025 16:03:47 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v8]
In-Reply-To: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
Message-ID: <rDk8LnLdEkVX8CZVJq8TefwV8ZIPFeRCDztsO1d9Gn0=.d0270e62-dc29-44cd-934b-5848c9f02efb@github.com>

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

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

 - Removed sizes from LBD constructors - not necessary
 - More optimizing volatile reads

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24925/files
  - new: https://git.openjdk.org/jdk/pull/24925/files/5faf1f11..91e48a5a

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

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

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

From emcmanus at google.com  Tue Jun 10 16:20:02 2025
From: emcmanus at google.com (=?UTF-8?Q?=C3=89amonn_McManus?=)
Date: Tue, 10 Jun 2025 09:20:02 -0700
Subject: javac confused by generics on class?
In-Reply-To: <CABw-sUJXEOm2AMkKT2Dp3sPDS=up3jgzRG4Rcd6rZ+wZB69JiQ@mail.gmail.com>
References: <CABw-sUJXEOm2AMkKT2Dp3sPDS=up3jgzRG4Rcd6rZ+wZB69JiQ@mail.gmail.com>
Message-ID: <CAChqX88R4kDimdLk-dKy3fR5s8kzgT4M6Vf=Y0sNxAVPuHNDgw@mail.gmail.com>

This question would probably be better asked on Stack Overflow or the like.
The short answer is that the compiler is following the language spec. ?4.8
<https://docs.oracle.com/javase/specs/jls/se24/html/jls-4.html#jls-4.8>
 says:

> The type of a constructor (?8.8
<https://docs.oracle.com/javase/specs/jls/se24/html/jls-8.html#jls-8.8>),
instance method (?8.4
<https://docs.oracle.com/javase/specs/jls/se24/html/jls-8.html#jls-8.4>,
?9.4 <https://docs.oracle.com/javase/specs/jls/se24/html/jls-9.html#jls-9.4>),
or non-static field (?8.3
<https://docs.oracle.com/javase/specs/jls/se24/html/jls-8.html#jls-8.3>) of
a raw type C that is not inherited from its superclasses or superinterfaces
is the erasure of its type in the generic class or interface C.
It *doesn't* say that this only applies when the original type references
the type parameters that have been omitted from the raw type. So the return
type of getValues() in the raw Child is raw List, even though the original
type List<String> doesn't mention T.

On Tue, 10 Jun 2025 at 08:50, Jean-No?l Rouvignac <
jean-noel.rouvignac at pingidentity.com> wrote:

> Hello,
>
> When doing refactorings to take advantage of newer Java features, I hit a
> new and weird edge case. I trimmed down the code several times, and ended
> up with the following tiny reproducer, and I don't understand what javac is
> complaining about even with javac 24:
>
> (Note: unlike the original code, this reproducer is very contrived, so
> there's no need to make comments on how bad it is: I fully agree)
>
> ```java
> 1 import java.util.ArrayList;
> import java.util.List;
> import java.util.stream.Collectors;
>
> public class Main {
>     private static final class Child<T> {
>         public List<String> getValues() {
>             return new ArrayList<>();
>         }
>     }
>
>     @SuppressWarnings("unchecked")
>     private static String getString1(Child c) {
>         // Compilation error:
>         // Main.java:16: error: incompatible types: Object cannot be
> converted to String
>         return c.getValues().stream().collect(Collectors.joining());
>     }
>
>     private static String getString2(Child c) {
>         // Compilation error:
>         // Main.java:27: warning: [unchecked] unchecked conversion
>         //        List<String> values = c.getValues();
>         //                                         ^
>         //  required: List<String>
>         //  found:    List
>         //1 warning
>         List<String> values = c.getValues();
>         return values.stream().collect(Collectors.joining());
>     }
> }
> ```
>
> It turns out IntelliJ is a bit more eloquent than javac, and when hovering
> over the warning on `c.getValues()` at the line with `List<String> values =
> c.getValues();`, it reports the following:
>
> >    Unchecked assignment: 'java.util.List' to
> 'java.util.List<java.lang.String>'. Reason: 'c' has raw type, so result of
> getValues is erased
>
> Is it possible that javac is doing early type erasure when analysing this
> code, erasing a bit too much? Even if the code uses `Child` without type
> argument, I would expect the return type of `getValues()` to be well
> defined as `List<String>`?
>
> What do you think?
> I am sure there is some rational explanation that I missed for this
> behaviour. I could not find a JBS issue showing the same case as here.
>
> Thank you,
> Jean-No?l Rouvignac
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250610/7170ee0b/attachment.htm>

From maurizio.cimadamore at oracle.com  Tue Jun 10 16:29:33 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 10 Jun 2025 17:29:33 +0100
Subject: javac confused by generics on class?
In-Reply-To: <CAChqX88R4kDimdLk-dKy3fR5s8kzgT4M6Vf=Y0sNxAVPuHNDgw@mail.gmail.com>
References: <CABw-sUJXEOm2AMkKT2Dp3sPDS=up3jgzRG4Rcd6rZ+wZB69JiQ@mail.gmail.com>
 <CAChqX88R4kDimdLk-dKy3fR5s8kzgT4M6Vf=Y0sNxAVPuHNDgw@mail.gmail.com>
Message-ID: <d775eff9-b4ad-4b7f-87b4-4fa440e26f48@oracle.com>

I've replied here (and moved the thread in compiler-dev) -- please 
follow up there if anything feels missing:

https://mail.openjdk.org/pipermail/compiler-dev/2025-June/030756.html

Maurizio

On 10/06/2025 17:20, ?amonn McManus wrote:
> This question would probably be better asked on Stack Overflow or the 
> like. The short answer is that the compiler is following the language 
> spec. ?4.8 
> <https://docs.oracle.com/javase/specs/jls/se24/html/jls-4.html#jls-4.8>?says:
>
> > The type of a constructor (?8.8 
> <https://docs.oracle.com/javase/specs/jls/se24/html/jls-8.html#jls-8.8>), 
> instance method (?8.4 
> <https://docs.oracle.com/javase/specs/jls/se24/html/jls-8.html#jls-8.4>, 
> ?9.4 
> <https://docs.oracle.com/javase/specs/jls/se24/html/jls-9.html#jls-9.4>), 
> or non-|static|?field (?8.3 
> <https://docs.oracle.com/javase/specs/jls/se24/html/jls-8.html#jls-8.3>) 
> of a raw type C?that is not inherited from its superclasses or 
> superinterfaces is the erasure of its type in the generic class or 
> interface C.
>
> It /doesn't/?say that this only applies when the original type 
> references the type parameters that have been omitted from the raw 
> type. So the return type of getValues() in the raw Child is raw List, 
> even though the original type List<String> doesn't mention T.
>
> On Tue, 10 Jun 2025 at 08:50, Jean-No?l Rouvignac 
> <jean-noel.rouvignac at pingidentity.com> wrote:
>
>     Hello,
>
>     When doing refactorings to take advantage of newer Java features,
>     I hit a new?and weird edge case. I trimmed down the code several
>     times, and ended up with the following tiny reproducer,?and I
>     don't understand what javac is complaining about even with javac 24:
>
>     (Note: unlike the original code,?this reproducer is very
>     contrived, so there's no need to make comments on how bad it is: I
>     fully agree)
>
>     ```java
>     1 import java.util.ArrayList;
>     import java.util.List;
>     import java.util.stream.Collectors;
>
>     public class Main {
>     ? ? private static final class Child<T> {
>     ? ? ? ? public List<String> getValues() {
>     ? ? ? ? ? ? return new ArrayList<>();
>     ? ? ? ? }
>     ? ? }
>
>     ? ? @SuppressWarnings("unchecked")
>     ? ? private static String getString1(Child c) {
>     ? ? ? ? // Compilation error:
>     ? ? ? ? // Main.java:16: error: incompatible types: Object cannot
>     be converted to String
>     ? ? ? ? return c.getValues().stream().collect(Collectors.joining());
>     ? ? }
>
>     ? ? private static String getString2(Child c) {
>     ? ? ? ? // Compilation error:
>     ? ? ? ? // Main.java:27: warning: [unchecked] unchecked conversion
>     ? ? ? ? // ? ? ? ?List<String> values = c.getValues();
>     ? ? ? ? // ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^
>     ? ? ? ? // ?required: List<String>
>     ? ? ? ? // ?found: ? ?List
>     ? ? ? ? //1 warning
>     ? ? ? ? List<String> values = c.getValues();
>     ? ? ? ? return values.stream().collect(Collectors.joining());
>     ? ? }
>     }
>     ```
>
>     It turns out IntelliJ is a bit more eloquent than javac, and when
>     hovering over the warning on `c.getValues()` at the line with
>     `List<String> values = c.getValues();`, it reports the following:
>
>     >? ? Unchecked assignment: 'java.util.List' to
>     'java.util.List<java.lang.String>'. Reason: 'c' has raw type, so
>     result of getValues is erased
>
>     Is it possible that javac is doing early type erasure when
>     analysing this code, erasing a bit too much? Even if the code uses
>     `Child` without type argument, I would expect the return type of
>     `getValues()` to be well defined as `List<String>`?
>
>     What do you think?
>     I am sure?there?is some rational explanation that I missed for
>     this behaviour. I could not find a JBS issue showing the same case
>     as here.
>
>     Thank you,
>     Jean-No?l?Rouvignac
>
>     /CONFIDENTIALITY NOTICE: This email may contain confidential and
>     privileged material for the sole use of the intended recipient(s).
>     Any review, use, distribution or disclosure by others is strictly
>     prohibited.? If you have received this communication in error,
>     please notify the sender immediately by e-mail and delete the
>     message and any file attachments from your computer. Thank you./
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250610/1cf67bf6/attachment-0001.htm>

From mcimadamore at openjdk.org  Tue Jun 10 16:40:33 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 10 Jun 2025 16:40:33 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v8]
In-Reply-To: <Q-OG1bF1rYlzzItZwo-j89AhpuT0S8FU6S4px8FDQoU=.1a93d2b6-4638-4374-b0e8-dd32afd38dc9@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <Q-OG1bF1rYlzzItZwo-j89AhpuT0S8FU6S4px8FDQoU=.1a93d2b6-4638-4374-b0e8-dd32afd38dc9@github.com>
Message-ID: <UlRQQ-nptdOM3jd8gNNcsiUC1YLSHaWwwZVacLzMS3o=.3c92196d-29e2-4885-9d93-60a9397f41b1@github.com>

On Thu, 5 Jun 2025 19:05:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
>> 
>> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
>> 
>> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
>> 
>> This PR passes tier1, tier2, and tier3 on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use a fixed threashold for fill

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 55:

> 53: 
> 54:     // All the threshold values below MUST be a power of two and greater or equal to 2^3.
> 55:     private static final int NATIVE_THRESHOLD_FILL = 32;

Is there any reason you removed this property? While I understand that performance can regress for bigger sizes, taking away the property seems harsh/asymmetric?

test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java line 104:

> 102:     @Benchmark
> 103:     public void heapSegmentFillUnsafe() {
> 104:         SCOPED_MEMORY_ACCESS.setMemory(heapSegment.sessionImpl(), heapSegment.unsafeGetBase(), heapSegment.unsafeGetOffset(), heapSegment.byteSize(), (byte) 0);

I think I would prefer just using Unsafe here. You can do that by saving the segment address in a `long` non-final field, and then use that field as the unsafe offset for the unsafe access operation. No need to use internal routines and/or ScopedMemoryAccess. I understand that, perhaps, using ScopedMemoryAccess allows you to include the cost of the liveness check, but I think using plain Unsafe as a reference is what this (and other similar benchmarks) should be doing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25383#discussion_r2138344248
PR Review Comment: https://git.openjdk.org/jdk/pull/25383#discussion_r2138343109

From pminborg at openjdk.org  Tue Jun 10 17:01:24 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Jun 2025 17:01:24 GMT
Subject: RFR: 8345292: Improve javadocs for MemorySegment::getStrings
 defining word boundary cases [v2]
In-Reply-To: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
References: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
Message-ID: <FVDMRZXsGbZRCYYdv_lk2vuR18T3_a0jHSsLG-JUxbU=.022a0fd7-0a53-4375-9db1-672d17e94996@github.com>

> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset charset)` method documentation with respect to multi-octet concerns.

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

  Update after comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25715/files
  - new: https://git.openjdk.org/jdk/pull/25715/files/7e4d4bf3..86b891a2

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

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

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

From pminborg at openjdk.org  Tue Jun 10 17:01:25 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Jun 2025 17:01:25 GMT
Subject: RFR: 8345292: Improve javadocs for MemorySegment::getStrings
 defining word boundary cases [v2]
In-Reply-To: <JI1egGZkcWn1hBX2tqX3YofFfcrYZLDvd1aafvOUKC8=.b1a9b9e1-b474-46c4-a47b-5fce46e0e72d@github.com>
References: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
 <JI1egGZkcWn1hBX2tqX3YofFfcrYZLDvd1aafvOUKC8=.b1a9b9e1-b474-46c4-a47b-5fce46e0e72d@github.com>
Message-ID: <F_wpolWXsndKTSb032AMTCSvgJBsbNa5-MZ5JJPBvGY=.ebfb75dc-a0e9-4742-b820-18a19c7c3882@github.com>

On Tue, 10 Jun 2025 15:50:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after comments
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1302:
> 
>> 1300:      * If the {@linkplain #byteSize()} of this segment is not evenly dividable by the
>> 1301:      * number of octets used by provided {@code charset}, the reminding bytes of this
>> 1302:      * segment is not accessed. For multi-octet charset, nulls are only detected on
> 
> Elsewhere in the javadoc we say string terminator/terminator char. The mention of `null` is surprising here.

The docs start with saying "Reads a null-terminated string..." so I thought this was not that surprising. But I will update the wording.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25715#discussion_r2138372991

From pminborg at openjdk.org  Tue Jun 10 17:03:34 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Jun 2025 17:03:34 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v8]
In-Reply-To: <UlRQQ-nptdOM3jd8gNNcsiUC1YLSHaWwwZVacLzMS3o=.3c92196d-29e2-4885-9d93-60a9397f41b1@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <Q-OG1bF1rYlzzItZwo-j89AhpuT0S8FU6S4px8FDQoU=.1a93d2b6-4638-4374-b0e8-dd32afd38dc9@github.com>
 <UlRQQ-nptdOM3jd8gNNcsiUC1YLSHaWwwZVacLzMS3o=.3c92196d-29e2-4885-9d93-60a9397f41b1@github.com>
Message-ID: <b0kB429gITgutasSiqrabEiwCmSv2GDYEBCHbFJC2qg=.c8b333a6-e868-4ae9-a3d6-ac84f483c869@github.com>

On Tue, 10 Jun 2025 16:37:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use a fixed threashold for fill
>
> src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 55:
> 
>> 53: 
>> 54:     // All the threshold values below MUST be a power of two and greater or equal to 2^3.
>> 55:     private static final int NATIVE_THRESHOLD_FILL = 32;
> 
> Is there any reason you removed this property? While I understand that performance can regress for bigger sizes, taking away the property seems harsh/asymmetric?

So, eventually, I'd like to move away from using these properties once the consuming method is fairly stable across both platforms and workloads. I am hoping to do the same for the remaining operations once they are revisited.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25383#discussion_r2138381943

From pminborg at openjdk.org  Tue Jun 10 17:31:20 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Jun 2025 17:31:20 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v9]
In-Reply-To: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
Message-ID: <eSigRXfWIK7P5KZaDDT9-6euHDK3gUwf7draTv_PnAA=.9f1f2518-6ac4-4991-9b39-6bb03806c0dd@github.com>

> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
> 
> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
> 
> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
> 
> This PR passes tier1, tier2, and tier3 on multiple platforms.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Use Unsafe directly in benchmarks
 - Merge branch 'master' into fill-overlap
 - Use a fixed threashold for fill
 - Fix benchmark
 - Merge branch 'master' into fill-overlap
 - Merge branch 'master' into fill-overlap
 - Update test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update benchmark to reflect new fill method
 - Simplify
 - Add case for long operations and break out methods
 - ... and 2 more: https://git.openjdk.org/jdk/compare/f8256c19...c2583a50

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25383/files
  - new: https://git.openjdk.org/jdk/pull/25383/files/0da4c0be..c2583a50

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

  Stats: 12500 lines in 430 files changed: 8818 ins; 2677 del; 1005 mod
  Patch: https://git.openjdk.org/jdk/pull/25383.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25383/head:pull/25383

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

From dfuchs at openjdk.org  Tue Jun 10 18:20:37 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 10 Jun 2025 18:20:37 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v2]
In-Reply-To: <8r28eulzOwmt6cxFjNPLg5zujXD1o1CEiPUqP4dHxvM=.3b8e608a-b97c-4ebd-8094-6e2e6d8f33e1@github.com>
References: <iGlPHf8dSXOGgy-Qby4L6bwR_ZfAMVEETLqpnPVN3NQ=.64a2d77a-fb3b-4ee9-89f3-298610dba273@github.com>
 <8r28eulzOwmt6cxFjNPLg5zujXD1o1CEiPUqP4dHxvM=.3b8e608a-b97c-4ebd-8094-6e2e6d8f33e1@github.com>
Message-ID: <d1LwzUErg-Kyx2L2w0proovDu0llyiMR-wR4Z1IQFjM=.70c4b34f-57f4-450b-a6fc-7b27004e8e48@github.com>

On Thu, 15 May 2025 23:59:41 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with Cleaner.
>> 
>> (The [first PR](https://github.com/openjdk/jdk/pull/8311) for this fix started some substantial discussions, leading to, among other things, the [8314480](https://bugs.openjdk.org/browse/JDK-8314480) `java.lang.ref` memory ordering spec update.)
>> 
>> In standard fashion, pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved into a _Context_ object. From there, the change is fairly mechanical.
>> 
>> Details of note:
>> 
>> 1. Some operations need to change the state values (the `update()` method is probably the most interesting). Use of `reachabilityFence()` ensures memory visibility on the Cleaner thread (per the aforementioned spec update).
>> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's state.
>> 
>> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. It confirms that the use of Cleaner does not keep an `LdapSearchEnumeration` object reachable. The other `AbstractLdapNamingEnumeration` subclasses (`LdapNamingEnumeration` and `LdapBindingEnumeration`) can be expected to behave the same.
>> 
>> Thanks.
>> 
>> **Edit: (Re)viewers: due to there being a lot of indentation changes, you might consider enabling the "Hide whitespace" option on the "Files changed" tab. To my eye, it gives a better view of the changes.**
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright

Generally looks good. I haven't verified whether all methods that need a reachabilityFence have it. This will require further analysis (from me).
As Alan noted it would be really good if we could use try-with-resource, but I am not expert enough in LDAP search implementation to figure out whether that's feasible.

Your proposed fix preseves the status quo - where a finalizer has been replaced by a cleaner - and asserting that the two are equivalent seems more trackable for now.

src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 453:

> 451:         try {
> 452:             // Cleanup previous context first
> 453:             getHomeCtx().decEnumCount();

What is the reason for calling `getHomeCtx()` here when we use `enumCtxt.homeCtx` a few lines below?

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

PR Review: https://git.openjdk.org/jdk/pull/25242#pullrequestreview-2914626239
PR Review Comment: https://git.openjdk.org/jdk/pull/25242#discussion_r2138506580

From naoto at openjdk.org  Tue Jun 10 18:42:43 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 10 Jun 2025 18:42:43 GMT
Subject: RFR: 8358819: The first year is not displayed correctly in Japanese
 Calendar
Message-ID: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>

This regression was introduced by the removal of the COMPAT locale provider, which partially broke support for the first year in the Japanese calendar. In the Japanese calendar system, the first year of an era should be formatted using the character "?" rather than the numeral "1". The issue arises from a difference in how pattern character lengths are interpreted between CLDR and SimpleDateFormat. The existing `JapaneseEraNameTest` has been updated to cover this fix.

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

Commit messages:
 - initial commit

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

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

From abarashev at openjdk.org  Tue Jun 10 22:04:46 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 10 Jun 2025 22:04:46 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
Message-ID: <w_IZtUmgo7JbvZayavQbvsBLhMesF1P60iZ-tMJU5-w=.3bd35485-107b-4e10-9a65-b9acb64811f8@github.com>

On Fri, 6 Jun 2025 12:00:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
> 
>  - merge latest changes from master branch
>  - http3: improve H3ConnectionPoolTest.java
>  - Fix snippet
>  - Improve key destruction
>  - merge latest changes from master branch
>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>  - http3: refactor HTTP/3 connection pool management in a separate class
>  - Ignore DestroyFailedExceptions
>  - Remove outdated TODO
>  - Remove outdated TODO
>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 243:

> 241:         }
> 242:         // QUIC TLS version is mandated to be always TLSv1.3
> 243:         if (!ProtocolVersion.useTLS12PlusSpec(session.getProtocol())) {

Should be `useTLS13PlusSpec`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138839652

From abarashev at openjdk.org  Tue Jun 10 22:12:46 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 10 Jun 2025 22:12:46 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
Message-ID: <6AU7lGXUVGbSk3B65aPdjokTF3j91LjG445kzW5Hq1Y=.c1580e0d-3ebe-4b0b-8e58-b0233639b295@github.com>

On Fri, 6 Jun 2025 12:00:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
> 
>  - merge latest changes from master branch
>  - http3: improve H3ConnectionPoolTest.java
>  - Fix snippet
>  - Improve key destruction
>  - merge latest changes from master branch
>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>  - http3: refactor HTTP/3 connection pool management in a separate class
>  - Ignore DestroyFailedExceptions
>  - Remove outdated TODO
>  - Remove outdated TODO
>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 229:

> 227:             // any algorithm constraints when choosing the client alias and
> 228:             // just call the functionally limited
> 229:             // javax.net.ssl.X509KeyManager.chooseClientAlias(...)

This comment should be updated as we do take into account algorithm constraints. I would remove `TODO` word as well, maybe replace it with `NOTE`

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 328:

> 326:                 // any algorithm constraints when choosing the server alias
> 327:                 // and just call the functionally limited
> 328:                 // javax.net.ssl.X509KeyManager.chooseServerAlias(...)

Same as above, update the comment

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138847212
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138847768

From abarashev at openjdk.org  Tue Jun 10 22:19:41 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 10 Jun 2025 22:19:41 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
Message-ID: <vLvyqUUFPFSJUrFUl8EOEBJHGsoIxWOVGMeB0uhV6Tw=.249ece3e-3a6e-4671-ae9a-5fa23bee0b14@github.com>

On Fri, 6 Jun 2025 12:00:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
> 
>  - merge latest changes from master branch
>  - http3: improve H3ConnectionPoolTest.java
>  - Fix snippet
>  - Improve key destruction
>  - merge latest changes from master branch
>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>  - http3: refactor HTTP/3 connection pool management in a separate class
>  - Ignore DestroyFailedExceptions
>  - Remove outdated TODO
>  - Remove outdated TODO
>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8

src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 164:

> 162:      */
> 163:     static AlgorithmConstraints forQUIC(QuicTLSEngine engine,
> 164:                                         boolean applyCertPathAlgConstraints) {

This parameter should be called `withDefaultCertPathConstraints` for consistency with other methods.

src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 188:

> 186:     static AlgorithmConstraints forQUIC(QuicTLSEngine engine,
> 187:                                         String[] supportedAlgorithms,
> 188:                                         boolean applyCertPathAlgConstraints) {

Same as above:  should be called `withDefaultCertPathConstraints`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138853006
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138853942

From abarashev at openjdk.org  Tue Jun 10 22:24:42 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 10 Jun 2025 22:24:42 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
Message-ID: <bzvffTIetPOaCPk8bKt4q77OBVIyKKdWmJGHZy8sYNE=.d284be58-fc5b-4119-a77f-b599644aab03@github.com>

On Fri, 6 Jun 2025 12:00:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
> 
>  - merge latest changes from master branch
>  - http3: improve H3ConnectionPoolTest.java
>  - Fix snippet
>  - Improve key destruction
>  - merge latest changes from master branch
>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>  - http3: refactor HTTP/3 connection pool management in a separate class
>  - Ignore DestroyFailedExceptions
>  - Remove outdated TODO
>  - Remove outdated TODO
>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8

src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 247:

> 245:         if (quicEngine != null) {
> 246:             if (quicEngine instanceof QuicTLSEngineImpl engineImpl) {
> 247:                 return engineImpl.getAlgorithmConstraints();

Any particular reason constraints selection code was moved to `engineImpl.getAlgorithmConstraints()` and not kept in this file for consistency with `SSLEngine` and `SSLSocket`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138858886

From abarashev at openjdk.org  Tue Jun 10 22:58:44 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 10 Jun 2025 22:58:44 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <fopFSoDFZHwFvMU9afn5Z0GeiECsjaMNr0ng4-rtXAQ=.72243a2e-a505-4e2b-943c-9ec644d47a4b@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <fopFSoDFZHwFvMU9afn5Z0GeiECsjaMNr0ng4-rtXAQ=.72243a2e-a505-4e2b-943c-9ec644d47a4b@github.com>
Message-ID: <oGSPDZ3vfqSMEE64wxCFmFw9MSgZV0eWGKbmvFQetXM=.ce8d8479-bbf8-4af2-8ed9-f70bfad1b8f3@github.com>

On Tue, 22 Apr 2025 19:36:00 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: improve H3ConnectionPoolTest.java
>>  - Fix snippet
>>  - Improve key destruction
>>  - merge latest changes from master branch
>>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>>  - http3: refactor HTTP/3 connection pool management in a separate class
>>  - Ignore DestroyFailedExceptions
>>  - Remove outdated TODO
>>  - Remove outdated TODO
>>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8
>
> src/java.base/share/classes/sun/security/ssl/CertificateMessage.java line 1221:
> 
>> 1219:                         tm.checkClientTrusted(
>> 1220:                                 certs.clone(),
>> 1221:                                 authType);
> 
> This call doesn't check against `SSLAlgorithmConstraints` unlike 2 calls for `SSLSocket` and `SSLEngine` above.

What would be the reason it's not addressed like in `checkServerCerts` below?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138892993

From duke at openjdk.org  Wed Jun 11 02:18:29 2025
From: duke at openjdk.org (erifan)
Date: Wed, 11 Jun 2025 02:18:29 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v8]
In-Reply-To: <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
Message-ID: <9LpnQrYLKKpYrKwERCehMmSTXm0-2pCjF0HRCU1AKh0=.9eb49965-268b-48f3-8c79-d05d4df93e25@github.com>

On Fri, 6 Jun 2025 10:38:11 GMT, erifan <duke at openjdk.org> wrote:

>> This patch optimizes the following patterns:
>> For integer types:
>> 
>> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> 
>> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond.
>> 
>> For float and double types:
>> 
>> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> 
>> cond can be eq or ne.
>> 
>> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`:
>> 
>> Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>> testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>> testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>> testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>> testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>> testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>> testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>> testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>> testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>> testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
>> testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
>> testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
>> testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
>> testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
>> testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
>> testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
>> testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
>> testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
>> testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
>> testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
>> testCompareLTMaskNotInt		ops/s	16721...
>
> erifan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Support negating unsigned comparison for BoolTest::mask
>   
>   Added a static method `negate_mask(mask btm)` into BoolTest class to
>   negate both signed and unsigned comparison.

Hi, any further comments?

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

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

From epeter at openjdk.org  Wed Jun 11 05:36:37 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 11 Jun 2025 05:36:37 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v8]
In-Reply-To: <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
Message-ID: <jBGor-lw-6172cZiQigShEbqfwFeW7b335JVFUgbjlM=.b789dec6-b202-4727-a59b-dd5e38e6921d@github.com>

On Fri, 6 Jun 2025 10:38:11 GMT, erifan <duke at openjdk.org> wrote:

>> This patch optimizes the following patterns:
>> For integer types:
>> 
>> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> 
>> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond.
>> 
>> For float and double types:
>> 
>> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> 
>> cond can be eq or ne.
>> 
>> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`:
>> 
>> Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>> testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>> testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>> testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>> testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>> testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>> testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>> testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>> testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>> testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
>> testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
>> testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
>> testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
>> testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
>> testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
>> testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
>> testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
>> testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
>> testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
>> testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
>> testCompareLTMaskNotInt		ops/s	16721...
>
> erifan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Support negating unsigned comparison for BoolTest::mask
>   
>   Added a static method `negate_mask(mask btm)` into BoolTest class to
>   negate both signed and unsigned comparison.

@erifan Thanks for the updates, I have some more comments :)

src/hotspot/share/opto/subnode.hpp line 333:

> 331:   mask negate( ) const { return mask(_test^4); }
> 332:   // Return the negative mask for the given mask, for both signed and unsigned comparison.
> 333:   static mask negate_mask(mask btm) { return mask(btm^4); }

Suggestion:

  static mask negate_mask(mask btm) { return mask(btm ^ 4); }


https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md

> Use spaces around operators, especially comparisons and assignments. (Relaxable for boolean expressions and high-precedence operators in classic math-style formulas.)

src/hotspot/share/opto/vectornode.cpp line 2226:

> 2224: 
> 2225:   const TypeVect* vector_mask_cast_vt = nullptr;
> 2226:   // in1 should be single used, otherwise the optimization may be unprofitable.

Suggestion:

  // in1 should only have a single use, otherwise the optimization may be unprofitable.

src/hotspot/share/opto/vectornode.cpp line 2227:

> 2225:   const TypeVect* vector_mask_cast_vt = nullptr;
> 2226:   // in1 should be single used, otherwise the optimization may be unprofitable.
> 2227:   if (in1->Opcode() == Op_VectorMaskCast && in1->outcnt() == 1 && in1->in(1)->Opcode() == Op_VectorMaskCmp) {

`in1->in(1)->Opcode() == Op_VectorMaskCmp`
Is this check here even necessary? Because we check it below again, right?
`in1->Opcode() != Op_VectorMaskCmp`

src/hotspot/share/opto/vectornode.cpp line 2237:

> 2235:       !VectorNode::is_all_ones_vector(in2)) {
> 2236:     return nullptr;
> 2237:   }

Similarly here: do you have tests for these conditions, that we do not optimize if any of these fail?

src/hotspot/share/opto/vectornode.cpp line 2239:

> 2237:   }
> 2238: 
> 2239:   BoolTest::mask neg_cond = BoolTest::negate_mask(((VectorMaskCmpNode*) in1)->get_predicate());

Suggestion:

  BoolTest::mask neg_cond = BoolTest::negate_mask((in1->as_VectorMaskCmp())->get_predicate());

Does that compile? It would be prefereable.

src/hotspot/share/opto/vectornode.cpp line 2243:

> 2241:   const TypeVect* vt = in1->as_Vector()->vect_type();
> 2242:   Node* res = new VectorMaskCmpNode(neg_cond, in1->in(1), in1->in(2),
> 2243:                                       predicate_node, vt);

Suggestion:

  Node* res = new VectorMaskCmpNode(neg_cond, in1->in(1), in1->in(2),
                                    predicate_node, vt);

Alignment

test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 158:

> 156:         } else if (op == VectorOperators.UGT) {
> 157:             Asserts.assertEquals(compareUnsigned(a, b) <= 0, r);
> 158:         }

Please refactor it as a `switch`. And add a `default` case where you throw some `RuntimeException`. just to make sure we are not missing anything :)

test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 244:

> 242:         testCompareMaskNotByte(VectorOperators.EQ, m -> m.not());
> 243:         testCompareMaskNotByte(VectorOperators.EQ, m -> m.xor(B_SPECIES.maskAll(true)));
> 244:     }

Could it happen that the verification is inlined in the test body?

Currently, the verification is probably inlined, but the code there is not vectorized. But what if one day the auto-vectorizer is smart enough and vectorizes it, and creates vectors that we currently check `count ...= 0`?

At least, you could ensure that the verification does not get inlined, with `@DontInline`.

What do you think?

test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 623:

> 621:         testCompareMaskNotFloat(VectorOperators.NE, fa, fninf, m -> m.not());
> 622:         testCompareMaskNotFloat(VectorOperators.NE, fa, fninf, m -> m.xor(F_SPECIES.maskAll(true)));
> 623:     }

Something makes me a little nervous about the correctness in these IR rules:

You are checking `IRNode.XOR_VL, "= 0"`. But you are comparing `floats`. Does that make sense?

Also: in the whole test, there is no single case where you expect the `XOR_V` to still be in the IR. I think it would be good to have one "control test" at least, where you test in a very similar pattern that this node is still there, and does not optimize. Maybe you can use a case where the construct has multiple uses, and is therefore not profitable to be optimized. What do you think?

test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 692:

> 690:         TestFramework testFramework = new TestFramework();
> 691:         testFramework.addFlags("--add-modules=jdk.incubator.vector");
> 692:         testFramework.setDefaultWarmup(10000);

The default is `2000` is that not enough?

Increasing it means the test runs slower, here probably about 5x.

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24674#pullrequestreview-2915634768
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2139189790
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2139199315
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2139201553
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2139206813
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2139216182
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2139217776
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2139227321
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2139234183
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2139239614
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2139243617

From epeter at openjdk.org  Wed Jun 11 05:36:37 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 11 Jun 2025 05:36:37 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v8]
In-Reply-To: <jBGor-lw-6172cZiQigShEbqfwFeW7b335JVFUgbjlM=.b789dec6-b202-4727-a59b-dd5e38e6921d@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
 <jBGor-lw-6172cZiQigShEbqfwFeW7b335JVFUgbjlM=.b789dec6-b202-4727-a59b-dd5e38e6921d@github.com>
Message-ID: <KIjODP3Wtiz5ru6MEADefhw2k4VQutP8Vb2q2e3Ov00=.3a3f7d55-d558-405d-b6e5-58bf3541d3f1@github.com>

On Wed, 11 Jun 2025 05:08:35 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> erifan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Support negating unsigned comparison for BoolTest::mask
>>   
>>   Added a static method `negate_mask(mask btm)` into BoolTest class to
>>   negate both signed and unsigned comparison.
>
> src/hotspot/share/opto/vectornode.cpp line 2227:
> 
>> 2225:   const TypeVect* vector_mask_cast_vt = nullptr;
>> 2226:   // in1 should be single used, otherwise the optimization may be unprofitable.
>> 2227:   if (in1->Opcode() == Op_VectorMaskCast && in1->outcnt() == 1 && in1->in(1)->Opcode() == Op_VectorMaskCmp) {
> 
> `in1->in(1)->Opcode() == Op_VectorMaskCmp`
> Is this check here even necessary? Because we check it below again, right?
> `in1->Opcode() != Op_VectorMaskCmp`

Btw: do you have a test where `in1->outcnt() > 1`, and you check that the optimization does not happen with an IR test?

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

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

From syan at openjdk.org  Wed Jun 11 07:20:40 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 11 Jun 2025 07:20:40 GMT
Subject: RFR: 8359182: Use @requires instead of SkippedException for
 MaxPath.java
Message-ID: <d0ot80Ub_x8xbRMQSNxUKV2O27RjN8Z1nXvjznDPdi4=.2617694b-535e-4140-a120-6914bb5d20cc@github.com>

Hi all,

I think use `@requires (os.family == "windows")` is more elegrant than thow jtreg.SkippedException in test java/io/File/MaxPath.java.

On linux before this PR, run this test jtreg report:


TEST: java/io/File/MaxPath.java
TEST RESULT: Passed. Skipped: jtreg.SkippedException: This test is run only on Windows


On linux after this PR, run this test jtreg report:


Test results: no tests selected


Change has been verified locally both on linux and windows, test-fix only, no risk.

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

Commit messages:
 - 8359182: Use @requires instead of SkippedException for MaxPath.java

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

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

From duke at openjdk.org  Wed Jun 11 07:34:33 2025
From: duke at openjdk.org (erifan)
Date: Wed, 11 Jun 2025 07:34:33 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v8]
In-Reply-To: <jBGor-lw-6172cZiQigShEbqfwFeW7b335JVFUgbjlM=.b789dec6-b202-4727-a59b-dd5e38e6921d@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
 <jBGor-lw-6172cZiQigShEbqfwFeW7b335JVFUgbjlM=.b789dec6-b202-4727-a59b-dd5e38e6921d@github.com>
Message-ID: <u89ZdaEF_F-mqIgWOFMQJScOQ7Phzrc3Dbus0KXTuyY=.7366ba41-0e0f-4a15-9fa5-dea626fc3c35@github.com>

On Wed, 11 Jun 2025 05:23:12 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> erifan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Support negating unsigned comparison for BoolTest::mask
>>   
>>   Added a static method `negate_mask(mask btm)` into BoolTest class to
>>   negate both signed and unsigned comparison.
>
> test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 158:
> 
>> 156:         } else if (op == VectorOperators.UGT) {
>> 157:             Asserts.assertEquals(compareUnsigned(a, b) <= 0, r);
>> 158:         }
> 
> Please refactor it as a `switch`. And add a `default` case where you throw some `RuntimeException`. just to make sure we are not missing anything :)

`VectorOperators.XXX` is not compile time constants, we can't use `switch` here.

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

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

From epeter at openjdk.org  Wed Jun 11 07:46:31 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 11 Jun 2025 07:46:31 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v8]
In-Reply-To: <u89ZdaEF_F-mqIgWOFMQJScOQ7Phzrc3Dbus0KXTuyY=.7366ba41-0e0f-4a15-9fa5-dea626fc3c35@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
 <jBGor-lw-6172cZiQigShEbqfwFeW7b335JVFUgbjlM=.b789dec6-b202-4727-a59b-dd5e38e6921d@github.com>
 <u89ZdaEF_F-mqIgWOFMQJScOQ7Phzrc3Dbus0KXTuyY=.7366ba41-0e0f-4a15-9fa5-dea626fc3c35@github.com>
Message-ID: <EwOewewGUFn8uHpqxIM5zVBkXeKcGv4N93IUVZhmF1g=.c293bae4-f54f-4e9d-a581-1073803b8bf3@github.com>

On Wed, 11 Jun 2025 07:31:48 GMT, erifan <duke at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 158:
>> 
>>> 156:         } else if (op == VectorOperators.UGT) {
>>> 157:             Asserts.assertEquals(compareUnsigned(a, b) <= 0, r);
>>> 158:         }
>> 
>> Please refactor it as a `switch`. And add a `default` case where you throw some `RuntimeException`. just to make sure we are not missing anything :)
>
> `VectorOperators.XXX` is not compile time constants, we can't use `switch` here.

Oh. Ok. Well at least add a `RuntimeException` to an `else` branch then, I would suggest :)

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

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

From jlu at openjdk.org  Wed Jun 11 07:49:29 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 11 Jun 2025 07:49:29 GMT
Subject: RFR: 8358819: The first year is not displayed correctly in
 Japanese Calendar
In-Reply-To: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
References: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
Message-ID: <9SlpSwJRk_-ykaByQT771ZeFCvFXWsvdnex127x31_w=.5dde6765-5366-425c-a425-d67e2e57b4fe@github.com>

On Tue, 10 Jun 2025 18:36:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This regression was introduced by the removal of the COMPAT locale provider, which partially broke support for the first year in the Japanese calendar. In the Japanese calendar system, the first year of an era should be formatted using the character "?" rather than the numeral "1". The issue arises from a difference in how pattern character lengths are interpreted between CLDR and SimpleDateFormat. The existing `JapaneseEraNameTest` has been updated to cover this fix.

OK, I think I understand the general idea. Japanese Imperial Calendar only returns ? for first year display name when the style is LONG.


// "GanNen" is supported only in the LONG style.
if (field == YEAR
    && (getBaseStyle(style) != LONG || fieldValue != 1 || get(ERA) == 0)) {
    return null;
}


Thus, when `SimpleDateFormat`s rely on the underlying Japanese Calendar, they fetch incorrect results since their CLDR pattern defaults to "y" for LONG and FULL, unlike COMPAT which was "yyyy".

So we are updating the CLDRConverter to adapt the old COMPAT style pattern: "yyyy" when using Japanese calendar for LONG or FULL `SimpleDateFormat` patterns, such that it can replicate the old "gannen" style which emits the ?.

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25732#pullrequestreview-2916023605
PR Review: https://git.openjdk.org/jdk/pull/25732#pullrequestreview-2916024618

From duke at openjdk.org  Wed Jun 11 08:22:31 2025
From: duke at openjdk.org (erifan)
Date: Wed, 11 Jun 2025 08:22:31 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v8]
In-Reply-To: <jBGor-lw-6172cZiQigShEbqfwFeW7b335JVFUgbjlM=.b789dec6-b202-4727-a59b-dd5e38e6921d@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
 <jBGor-lw-6172cZiQigShEbqfwFeW7b335JVFUgbjlM=.b789dec6-b202-4727-a59b-dd5e38e6921d@github.com>
Message-ID: <BaSl-RVk4nOD6oXRKr7_0HdDKeWszmmDxU51w6uBPAs=.7cee1649-d2db-4c31-aba1-38423ac17c88@github.com>

On Wed, 11 Jun 2025 05:31:00 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> You are checking IRNode.XOR_VL, "= 0". But you are comparing floats. Does that make sense?

The bottom types of `float` and `double` vector masks are casted to `int` and `long`. Seems this is by design? So this is correct.

As for `control test`, yes for now I didn't add any such kind of test, because I personally think it's unnecessary. For specific code, it won't trigger this optimization now, but new optimizations in the future may cause this test to fail.

Anyway I've tested the case where `vectormaskcmp` is multi used locally, and this optimization won't be triggered. 

Do you think it's necessary to add such a control test?

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

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

From cstein at openjdk.org  Wed Jun 11 08:30:18 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 11 Jun 2025 08:30:18 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment [v2]
In-Reply-To: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
Message-ID: <WDT4hGnZmonDpTycLenA9jd_OCqJ2jrmgLAXfd6TxtA=.925df0d9-12d2-403d-92c6-26f927585f1b@github.com>

> Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign.
> 
> The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files):
> 
> Use the number sign `#` in the argument file to identify comments.
> All characters following the `#` are ignored until the end of line.
> 
> There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters.

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

  Extract shared function to compute current token

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25589/files
  - new: https://git.openjdk.org/jdk/pull/25589/files/21afeb37..bea8cc79

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

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

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

From epeter at openjdk.org  Wed Jun 11 08:33:32 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 11 Jun 2025 08:33:32 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v8]
In-Reply-To: <BaSl-RVk4nOD6oXRKr7_0HdDKeWszmmDxU51w6uBPAs=.7cee1649-d2db-4c31-aba1-38423ac17c88@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
 <jBGor-lw-6172cZiQigShEbqfwFeW7b335JVFUgbjlM=.b789dec6-b202-4727-a59b-dd5e38e6921d@github.com>
 <BaSl-RVk4nOD6oXRKr7_0HdDKeWszmmDxU51w6uBPAs=.7cee1649-d2db-4c31-aba1-38423ac17c88@github.com>
Message-ID: <nJ6O5DhqRLAPw76CAJ5I-w02z_2XbH9P_iWrEm2tQ4I=.6146106a-1d3c-4285-8d42-efe3e5ab8f06@github.com>

On Wed, 11 Jun 2025 08:20:20 GMT, erifan <duke at openjdk.org> wrote:

> > You are checking IRNode.XOR_VL, "= 0". But you are comparing floats. Does that make sense?

> The bottom types of float and double vector masks are casted to int and long. Seems this is by design? So this is correct.

This is a `float` test. What is the bottom type for the mask here?

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

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

From cstein at openjdk.org  Wed Jun 11 08:35:29 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 11 Jun 2025 08:35:29 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment [v2]
In-Reply-To: <IqvVkOj7xntKKswD9SJsGwSyI7gDgHYHWfCrkgh1zjY=.0dbce17a-81e5-41e5-8bfd-a95d01230b3e@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
 <tO_z8q0cawzrkDP_z__sUZbM2sWejgIHdwksIbFboUI=.1b657729-6541-4310-9117-d4f7f0d75a7a@github.com>
 <4Xzu7FifgELCGKkOTBMCpcgYwwKuqymJBpMSQHVFbcA=.95d8329e-453e-439f-a628-149ce8c22a51@github.com>
 <1aNuDmukQdUIs83wrKGgzmEHIOgMMUtTtePU9dHsUyE=.6b73641a-ab98-4b37-af3d-08b06d73533b@github.com>
 <IqvVkOj7xntKKswD9SJsGwSyI7gDgHYHWfCrkgh1zjY=.0dbce17a-81e5-41e5-8bfd-a95d01230b3e@github.com>
Message-ID: <7Es28Ts_GeDSE5WMTb6XPEy7OnT71Wouv07AGrlMSwA=.734b2270-d85d-4b26-ac3f-a6bdcb1a2d17@github.com>

On Tue, 10 Jun 2025 08:15:58 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Or the handling of `#` can be merged with the previous case ... somehow.
>
> Extracting a method wouldn't really simplify the code, as many local variables are in play.
> 
> Merging the cases also ends up in more if-else constructs in the case block that counter-act readability.
> 
> So, perhaps, the duplication is goog-enough here?

Created an internal shared function in https://github.com/openjdk/jdk/pull/25589/commits/bea8cc7905541e339ed30d0618e70ab6db7b6da6

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2139538469

From xgong at openjdk.org  Wed Jun 11 08:56:39 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 11 Jun 2025 08:56:39 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v8]
In-Reply-To: <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
Message-ID: <bPbifNys_IhP0FdeGMfn_2KXTtC-KbzoXBg8V7vdKJE=.f0e03829-dd44-4da2-9b96-0cb3cbeb6804@github.com>

On Fri, 6 Jun 2025 10:38:11 GMT, erifan <duke at openjdk.org> wrote:

>> This patch optimizes the following patterns:
>> For integer types:
>> 
>> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>>     => (VectorMaskCmp src1 src2 ncond)
>> 
>> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond.
>> 
>> For float and double types:
>> 
>> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
>> 
>> cond can be eq or ne.
>> 
>> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`:
>> 
>> Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
>> testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
>> testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
>> testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
>> testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
>> testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
>> testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
>> testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
>> testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
>> testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
>> testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
>> testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
>> testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
>> testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
>> testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
>> testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
>> testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
>> testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
>> testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
>> testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
>> testCompareLTMaskNotInt		ops/s	16721...
>
> erifan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Support negating unsigned comparison for BoolTest::mask
>   
>   Added a static method `negate_mask(mask btm)` into BoolTest class to
>   negate both signed and unsigned comparison.

src/hotspot/share/opto/vectornode.cpp line 2221:

> 2219:   // XorV/XorVMask is commutative, swap VectorMaskCmp/VectorMaskCast to in1.
> 2220:   if (in2->Opcode() == Op_VectorMaskCmp ||
> 2221:       (in2->Opcode() == Op_VectorMaskCast && in2->in(1)->Opcode() == Op_VectorMaskCmp)) {

We may need to consider cases that a `VectorMaskCast` is generated between `compare + not`, such as `compare + cast + not`. For such cases, the element size maybe different for input and output of a `cast`.  Although this patch's intention is not for the latter pattern, current change have also covered it well. Could you please add more test/jmh for all kinds of `cast` pattern here? And I think the scope of this PR could be also extended to `compare + cast + not`. WDYT?

src/hotspot/share/opto/vectornode.cpp line 2237:

> 2235:       !VectorNode::is_all_ones_vector(in2)) {
> 2236:     return nullptr;
> 2237:   }

This part can be refined more clearly:

// Swap and put all_ones_vector to right
if (!VectorNode::is_all_ones_vector(in1)) {
   swap(in1, in2);
}

// uncast mask
bool need_cast = false;
if (in1->Opcode() == Op_VectorMaskCast &&
    in1->outcnt() == 1) {
    assert(in1->bottom_type()->eq(bottom_type()), "");
    need_cast = true;
    in1 = in1->in(1);
}

// Check mask cmp pattern
if (in1->Opcode() != Op_VectorMaskCmp ||
    in1->outcnt() > 1 ||
    !in1->as_VectorMaskCmp()->predicate_can_be_negated()) {
    return nullptr;    
}

// Convert VectorMaskCmp + not


// Cast back
if (need_cast) {
  res = new VectorMaskCastNode(phase->transform(res), vect_type());
}

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

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

From duke at openjdk.org  Wed Jun 11 08:56:40 2025
From: duke at openjdk.org (erifan)
Date: Wed, 11 Jun 2025 08:56:40 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v8]
In-Reply-To: <nJ6O5DhqRLAPw76CAJ5I-w02z_2XbH9P_iWrEm2tQ4I=.6146106a-1d3c-4285-8d42-efe3e5ab8f06@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
 <jBGor-lw-6172cZiQigShEbqfwFeW7b335JVFUgbjlM=.b789dec6-b202-4727-a59b-dd5e38e6921d@github.com>
 <BaSl-RVk4nOD6oXRKr7_0HdDKeWszmmDxU51w6uBPAs=.7cee1649-d2db-4c31-aba1-38423ac17c88@github.com>
 <nJ6O5DhqRLAPw76CAJ5I-w02z_2XbH9P_iWrEm2tQ4I=.6146106a-1d3c-4285-8d42-efe3e5ab8f06@github.com>
Message-ID: <9EOB4uZ1q0v_9xw_gUslYls90Np2WK7K6cOgJ8KKYBQ=.91ec53d2-912f-4832-8570-7edf5c50b65f@github.com>

On Wed, 11 Jun 2025 08:30:51 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>>> You are checking IRNode.XOR_VL, "= 0". But you are comparing floats. Does that make sense?
>> 
>> The bottom types of `float` and `double` vector masks are casted to `int` and `long`. Seems this is by design? So this is correct.
>> 
>> As for `control test`, yes for now I didn't add any such kind of test, because I personally think it's unnecessary. For specific code, it won't trigger this optimization now, but new optimizations in the future may cause this test to fail.
>> 
>> Anyway I've tested the case where `vectormaskcmp` is multi used locally, and this optimization won't be triggered. 
>> 
>> Do you think it's necessary to add such a control test?
>
>> > You are checking IRNode.XOR_VL, "= 0". But you are comparing floats. Does that make sense?
> 
>> The bottom types of float and double vector masks are casted to int and long. Seems this is by design? So this is correct.
> 
> This is a `float` test. What is the bottom type for the mask here?

Oh, this is a stupid copy-paste mistake. Good catch, thanks! I'll double check them all.

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

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

From duke at openjdk.org  Wed Jun 11 09:09:33 2025
From: duke at openjdk.org (erifan)
Date: Wed, 11 Jun 2025 09:09:33 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v8]
In-Reply-To: <EwOewewGUFn8uHpqxIM5zVBkXeKcGv4N93IUVZhmF1g=.c293bae4-f54f-4e9d-a581-1073803b8bf3@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
 <jBGor-lw-6172cZiQigShEbqfwFeW7b335JVFUgbjlM=.b789dec6-b202-4727-a59b-dd5e38e6921d@github.com>
 <u89ZdaEF_F-mqIgWOFMQJScOQ7Phzrc3Dbus0KXTuyY=.7366ba41-0e0f-4a15-9fa5-dea626fc3c35@github.com>
 <EwOewewGUFn8uHpqxIM5zVBkXeKcGv4N93IUVZhmF1g=.c293bae4-f54f-4e9d-a581-1073803b8bf3@github.com>
Message-ID: <-Njau47iLgFUOIQEnZDrkzZKIjPEk3ErFIenrs6AelM=.2624ea9a-6b6c-4a07-85e4-2fa7334754dd@github.com>

On Wed, 11 Jun 2025 07:43:55 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> `VectorOperators.XXX` is not compile time constants, we can't use `switch` here.
>
> Oh. Ok. Well at least add a `RuntimeException` to an `else` branch then, I would suggest :)

Make sense!

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

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

From duke at openjdk.org  Wed Jun 11 09:12:33 2025
From: duke at openjdk.org (erifan)
Date: Wed, 11 Jun 2025 09:12:33 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v8]
In-Reply-To: <bPbifNys_IhP0FdeGMfn_2KXTtC-KbzoXBg8V7vdKJE=.f0e03829-dd44-4da2-9b96-0cb3cbeb6804@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <GQGN834tTFrgDkXva3k7hRJ1neEbsorm-XZg-4lKX68=.4639ff69-f114-4c54-85c5-f109d1e98631@github.com>
 <bPbifNys_IhP0FdeGMfn_2KXTtC-KbzoXBg8V7vdKJE=.f0e03829-dd44-4da2-9b96-0cb3cbeb6804@github.com>
Message-ID: <z-rcdjlWMYcxw9J6gHWIIfjuQy9r_oezikNtCcphZmE=.54a97f90-14ae-4b67-b455-3551f5b2d141@github.com>

On Wed, 11 Jun 2025 08:47:56 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> erifan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Support negating unsigned comparison for BoolTest::mask
>>   
>>   Added a static method `negate_mask(mask btm)` into BoolTest class to
>>   negate both signed and unsigned comparison.
>
> src/hotspot/share/opto/vectornode.cpp line 2221:
> 
>> 2219:   // XorV/XorVMask is commutative, swap VectorMaskCmp/VectorMaskCast to in1.
>> 2220:   if (in2->Opcode() == Op_VectorMaskCmp ||
>> 2221:       (in2->Opcode() == Op_VectorMaskCast && in2->in(1)->Opcode() == Op_VectorMaskCmp)) {
> 
> We may need to consider cases that a `VectorMaskCast` is generated between `compare + not`, such as `compare + cast + not`. For such cases, the element size maybe different for input and output of a `cast`.  Although this patch's intention is not for the latter pattern, current change have also covered it well. Could you please add more test/jmh for all kinds of `cast` pattern here? And I think the scope of this PR could be also extended to `compare + cast + not`. WDYT?

Good catch, I'll add more tests and check the correctness. Thanks~

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

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

From vklang at openjdk.org  Wed Jun 11 09:21:34 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 11 Jun 2025 09:21:34 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v8]
In-Reply-To: <rDk8LnLdEkVX8CZVJq8TefwV8ZIPFeRCDztsO1d9Gn0=.d0270e62-dc29-44cd-934b-5848c9f02efb@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <rDk8LnLdEkVX8CZVJq8TefwV8ZIPFeRCDztsO1d9Gn0=.d0270e62-dc29-44cd-934b-5848c9f02efb@github.com>
Message-ID: <7YXlCIfAhLSr1nYtxXI_e347NSgdv3AdU4e7uOevoMg=.2a49bcc8-42c4-4a68-a055-b04c7b25adab@github.com>

On Tue, 10 Jun 2025 16:03:47 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 hol...
>
> kabutz has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Removed sizes from LBD constructors - not necessary
>  - More optimizing volatile reads

test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java line 1904:

> 1902:                     fail("Expected InterruptedException in putFirst()");
> 1903:                 } catch (InterruptedException expected) {
> 1904:                     // good that's what we want

@kabutz I think it makes sense to verify that throwing the exception also clears the interrupt.

Suggestion:

                    // good that's what we want
                    assertFalse(Thread.currentThread().isInterrupted());

test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java line 1912:

> 1910:                     fail("Expected InterruptedException in putLast()");
> 1911:                 } catch (InterruptedException expected) {
> 1912:                     // good that's what we want

Suggestion:

                    // good that's what we want
                    assertFalse(Thread.currentThread().isInterrupted());

test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java line 1921:

> 1919:                     fail("Expected InterruptedException in takeFirst()");
> 1920:                 } catch (InterruptedException expected) {
> 1921:                     // good that's what we want

Suggestion:

                    // good that's what we want
                    assertFalse(Thread.currentThread().isInterrupted());

test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java line 1930:

> 1928:                     fail("Expected InterruptedException in takeLast()");
> 1929:                 } catch (InterruptedException expected) {
> 1930:                     // good that's what we want

Suggestion:

                    // good that's what we want
                    assertFalse(Thread.currentThread().isInterrupted());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2139634311
PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2139636727
PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2139637138
PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2139637525

From duke at openjdk.org  Wed Jun 11 09:52:19 2025
From: duke at openjdk.org (kabutz)
Date: Wed, 11 Jun 2025 09:52:19 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v9]
In-Reply-To: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
Message-ID: <o1XPbr2SrRMgmkjQyBE1hxPlxjLR7E0CxGjQllzsGfQ=.d12177f6-1836-4cc2-bf81-1421f25b9628@github.com>

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

kabutz has updated the pull request incrementally with four additional commits since the last revision:

 - Update test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java
   
   Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
 - Update test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java
   
   Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
 - Update test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java
   
   Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
 - Update test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java
   
   Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24925/files
  - new: https://git.openjdk.org/jdk/pull/24925/files/91e48a5a..16095666

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

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

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

From duke at openjdk.org  Wed Jun 11 09:52:19 2025
From: duke at openjdk.org (kabutz)
Date: Wed, 11 Jun 2025 09:52:19 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v8]
In-Reply-To: <7YXlCIfAhLSr1nYtxXI_e347NSgdv3AdU4e7uOevoMg=.2a49bcc8-42c4-4a68-a055-b04c7b25adab@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <rDk8LnLdEkVX8CZVJq8TefwV8ZIPFeRCDztsO1d9Gn0=.d0270e62-dc29-44cd-934b-5848c9f02efb@github.com>
 <7YXlCIfAhLSr1nYtxXI_e347NSgdv3AdU4e7uOevoMg=.2a49bcc8-42c4-4a68-a055-b04c7b25adab@github.com>
Message-ID: <YiRPXmIubiGHdCFoMNV7vo1amIPYrAOha6WL79ve_hQ=.e90b3b89-9f88-4fb0-99bb-40492eee1f3b@github.com>

On Wed, 11 Jun 2025 09:17:57 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> kabutz has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Removed sizes from LBD constructors - not necessary
>>  - More optimizing volatile reads
>
> test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java line 1904:
> 
>> 1902:                     fail("Expected InterruptedException in putFirst()");
>> 1903:                 } catch (InterruptedException expected) {
>> 1904:                     // good that's what we want
> 
> @kabutz I think it makes sense to verify that throwing the exception also clears the interrupt.
> 
> Suggestion:
> 
>                     // good that's what we want
>                     assertFalse(Thread.currentThread().isInterrupted());

Good idea, why not?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2139708615

From vyazici at openjdk.org  Wed Jun 11 10:32:32 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 10:32:32 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v5]
In-Reply-To: <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>
Message-ID: <E2xTeHEtEObgciaqOrdjj-xGRdq1ZugtdzM7XQFvMvA=.f5defb51-2610-473d-89e7-1f6f178d7b9c@github.com>

On Thu, 5 Jun 2025 10:13:24 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve code style
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/javax/script/MyContext.java line 52:

> 50:         engineScope = new SimpleBindings();
> 51:         globalScope = null;
> 52:         reader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));

I will revert this change, since

1. AFAICT, this file is not used anymore
2. Neither `std{out,err}.encoding` were used while creating `PrintWriter`s below

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2139786341

From vyazici at openjdk.org  Wed Jun 11 10:37:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 10:37:30 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v5]
In-Reply-To: <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>
Message-ID: <v97kiJfbm4kka6qtgVKr30XtA_BIPRQ26QVLuGdwzJY=.040aee98-63fc-469a-ab1b-d82daf9ecd46@github.com>

On Thu, 5 Jun 2025 10:13:24 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve code style
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/javax/security/auth/login/LoginContext/DefaultHandlerImpl.java line 80:

> 78:                 System.err.flush();
> 79:                 Reader stdinReader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
> 80:                 nc.setName(new BufferedReader(stdinReader).readLine());

Will revert this change, it is superfluous. As a matter of fact, there is a `readPassword(System.in)` down below that could have also been addressed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2139795483

From vyazici at openjdk.org  Wed Jun 11 10:43:47 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 10:43:47 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v6]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <7XLzfBmB2raJzcZP4NtaaWxQX2gYDrdd8Z1FzhTRmTg=.cfe1fb59-e062-45c4-9410-f5164c2cf479@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Revert superfluous test changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25544/files
  - new: https://git.openjdk.org/jdk/pull/25544/files/92248bb3..ca96e12b

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

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

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

From vyazici at openjdk.org  Wed Jun 11 10:43:48 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 10:43:48 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v5]
In-Reply-To: <E2xTeHEtEObgciaqOrdjj-xGRdq1ZugtdzM7XQFvMvA=.f5defb51-2610-473d-89e7-1f6f178d7b9c@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>
 <E2xTeHEtEObgciaqOrdjj-xGRdq1ZugtdzM7XQFvMvA=.f5defb51-2610-473d-89e7-1f6f178d7b9c@github.com>
Message-ID: <jOged_3bL5xjITokxOe5yzZ-gIUw1VeLnjiyqQrgSn4=.961fb018-8482-45a7-8f67-dad86cb59b23@github.com>

On Wed, 11 Jun 2025 10:29:52 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve code style
>>   
>>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> test/jdk/javax/script/MyContext.java line 52:
> 
>> 50:         engineScope = new SimpleBindings();
>> 51:         globalScope = null;
>> 52:         reader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
> 
> I will revert this change, since
> 
> 1. AFAICT, this file is not used anymore
> 2. Neither `std{out,err}.encoding` were used while creating `PrintWriter`s below

Reverted in ca96e12be8e.

> test/jdk/javax/security/auth/login/LoginContext/DefaultHandlerImpl.java line 80:
> 
>> 78:                 System.err.flush();
>> 79:                 Reader stdinReader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
>> 80:                 nc.setName(new BufferedReader(stdinReader).readLine());
> 
> Will revert this change, it is superfluous. As a matter of fact, there is a `readPassword(System.in)` down below that could have also been addressed.

Reverted in ca96e12be8e.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2139804910
PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2139804751

From rriggs at openjdk.org  Wed Jun 11 11:11:33 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 11 Jun 2025 11:11:33 GMT
Subject: RFR: 8357823: Changes in StringBuilder (JDK-8351443) caused a 1-3%
 regression in biojava
In-Reply-To: <lhUQ3O7VzHadMIWXzDahHX_DMC8Knwocq7-22ZeYebE=.03300e8d-f9ec-4465-9de2-960c5a55da0a@github.com>
References: <EqrJvAzbQYoe6SnQhsy9_KmtAhqJI4jGMaHOztKb0n8=.99ee9a06-04d4-499b-976c-74da3314f4b5@github.com>
 <lhUQ3O7VzHadMIWXzDahHX_DMC8Knwocq7-22ZeYebE=.03300e8d-f9ec-4465-9de2-960c5a55da0a@github.com>
Message-ID: <NLwbyqslfUHvwfzuyC7XRkd4dAJv1ErQfCF64EL_-Kc=.63a053f9-ed2f-4142-8efb-a53699623df0@github.com>

On Mon, 2 Jun 2025 23:32:39 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The performance figures under x64 show that the performance of StringBuilders.appendWithIntLatin1 scenario drops by about 6%, but the performance of StringBuilders.appendWithLongLatin1 does not drop.

All of the JMH tests for StringBuilders.appendWith* are unreliable. 
They modify StringBuilders (sbLatin1 and sbUtf16) that are supposed to be read-only by calling `setLength(0)`.
As a result, depending on the order of execution of the benchmarks, the buffer may or may not have to be re-sized.
fyi, That may not account for all of the differences.

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

PR Comment: https://git.openjdk.org/jdk/pull/25550#issuecomment-2962261862

From vyazici at openjdk.org  Wed Jun 11 11:28:38 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 11:28:38 GMT
Subject: RFR: 8359225: Remove unused test/jdk/javax/script/MyContext.java
Message-ID: <9g63ztmitzJUv3-Jg6vg5lUqlGsbuK4gp600G6auqaE=.5701becc-7bfc-4ece-8cf0-1833b9bd5d5a@github.com>

Both `javax/script/PluggableContextTest.java` and its companion `test/jdk/javax/script/MyContext.java` were added in [JDK-6398614](https://bugs.openjdk.org/browse/JDK-6398614). [JDK-8246113](https://bugs.openjdk.org/browse/JDK-8246113) removed `PluggableContextTest`, yet forgot `MyContext`, and rendered it redundant. Remove `MyContext` too.

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

Commit messages:
 - Remove unused `test/jdk/javax/script/MyContext.java`

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

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

From rriggs at openjdk.org  Wed Jun 11 11:35:09 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 11 Jun 2025 11:35:09 GMT
Subject: RFR: 8357823: Changes in StringBuilder (JDK-8351443) caused a 1-3%
 regression in biojava [v2]
In-Reply-To: <EqrJvAzbQYoe6SnQhsy9_KmtAhqJI4jGMaHOztKb0n8=.99ee9a06-04d4-499b-976c-74da3314f4b5@github.com>
References: <EqrJvAzbQYoe6SnQhsy9_KmtAhqJI4jGMaHOztKb0n8=.99ee9a06-04d4-499b-976c-74da3314f4b5@github.com>
Message-ID: <WzoAuynrcGPSOU45b0ZIVCrfLB8BCWLXGKIb57N2RnY=.bbcd4e75-8e1d-4faa-a657-af9f14934b8c@github.com>

> Comment out assertions added in JDK-8351443 from AbstractStringBuilder.ensureCapacityNewCoder that increase the codesize, preventing some inlining, and reducing performance
> 
>        assert coder == newCoder || newCoder == UTF16 : "bad new coder UTF16 -> LATIN1";
>        assert count <= newCapacity : "count exceeds new capacity";

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

  Microbenchmark java.lang.StringBuilders is modified to not re-use existing StringBuilders
  in the appendWithXXX benchmarks.
  The StringBuilders sbLatin1 and sbUtf15 are created as re-only for specific test cases.
  Re-using and setting the length to zero, makes the test suseptable to variations
  depend on the order of execution of the the benchmarks because the buffers may or
  may not have to been re-sized based on the previous test cases.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25550/files
  - new: https://git.openjdk.org/jdk/pull/25550/files/b51f52c9..e90e4010

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

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

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

From duke at openjdk.org  Wed Jun 11 11:44:29 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 11 Jun 2025 11:44:29 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment [v2]
In-Reply-To: <WDT4hGnZmonDpTycLenA9jd_OCqJ2jrmgLAXfd6TxtA=.925df0d9-12d2-403d-92c6-26f927585f1b@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
 <WDT4hGnZmonDpTycLenA9jd_OCqJ2jrmgLAXfd6TxtA=.925df0d9-12d2-403d-92c6-26f927585f1b@github.com>
Message-ID: <nLfsz3_WW_ULOEnLGN8xI8T_DkaqQmhReBEUh4f9whM=.6e91eba1-5ef6-4670-852d-0c00eff40ac7@github.com>

On Wed, 11 Jun 2025 08:30:18 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign.
>> 
>> The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files):
>> 
>> Use the number sign `#` in the argument file to identify comments.
>> All characters following the `#` are ignored until the end of line.
>> 
>> There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extract shared function to compute current token

test/jdk/tools/launcher/ArgFileSyntax.java line 177:

> 175:         },
> 176:         { // multiple args in one line and comments without preceding whitespace
> 177:             { "-Xmx32m -XshowSettings#COMMENT 1",

First case feels like a duplicate of the test at line 73. What's different?
Maybe this case should just live next to that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2139921427

From vklang at openjdk.org  Wed Jun 11 11:53:33 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 11 Jun 2025 11:53:33 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v9]
In-Reply-To: <o1XPbr2SrRMgmkjQyBE1hxPlxjLR7E0CxGjQllzsGfQ=.d12177f6-1836-4cc2-bf81-1421f25b9628@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <o1XPbr2SrRMgmkjQyBE1hxPlxjLR7E0CxGjQllzsGfQ=.d12177f6-1836-4cc2-bf81-1421f25b9628@github.com>
Message-ID: <0dC68qebawZ7fJvWUNO4LFqpTqK0P3v0Mr5XyBFJa3M=.9e5bfe0d-b44e-47bf-8e1d-70d0ee8ec260@github.com>

On Wed, 11 Jun 2025 09:52:19 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 hol...
>
> kabutz has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
>  - Update test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
>  - Update test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
>  - Update test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 884:

> 882:         try {
> 883:             int cnt;
> 884:             if ((cnt = count) + n <= capacity) {

Suggestion:

            long cnt;
            if ((cnt = count + n) <= capacity) {

src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 891:

> 889:                     last.next = beg;
> 890:                 last = end;
> 891:                 count = (int) (cnt + n);

Suggestion:

                count = (int)cnt;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2139936999
PR Review Comment: https://git.openjdk.org/jdk/pull/24925#discussion_r2139937484

From vklang at openjdk.org  Wed Jun 11 11:56:37 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 11 Jun 2025 11:56:37 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v9]
In-Reply-To: <o1XPbr2SrRMgmkjQyBE1hxPlxjLR7E0CxGjQllzsGfQ=.d12177f6-1836-4cc2-bf81-1421f25b9628@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <o1XPbr2SrRMgmkjQyBE1hxPlxjLR7E0CxGjQllzsGfQ=.d12177f6-1836-4cc2-bf81-1421f25b9628@github.com>
Message-ID: <OKcT5heTG3hDHHjOrOAW5t4fmqd0Xc6y4dogT45RcXU=.4b8df348-f99c-4e59-9622-11503485bed1@github.com>

On Wed, 11 Jun 2025 09:52:19 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 hol...
>
> kabutz has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
>  - Update test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
>  - Update test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
>  - Update test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

Just made some final suggestions, then I think this is good to go.
Great job on this, @kabutz?I really appreciate you taking this on!

I'll have a look once you've commented/addressed the comments, and I'll move this forward after that.

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

PR Review: https://git.openjdk.org/jdk/pull/24925#pullrequestreview-2916825665

From cstein at openjdk.org  Wed Jun 11 12:04:33 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 11 Jun 2025 12:04:33 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment [v2]
In-Reply-To: <nLfsz3_WW_ULOEnLGN8xI8T_DkaqQmhReBEUh4f9whM=.6e91eba1-5ef6-4670-852d-0c00eff40ac7@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
 <WDT4hGnZmonDpTycLenA9jd_OCqJ2jrmgLAXfd6TxtA=.925df0d9-12d2-403d-92c6-26f927585f1b@github.com>
 <nLfsz3_WW_ULOEnLGN8xI8T_DkaqQmhReBEUh4f9whM=.6e91eba1-5ef6-4670-852d-0c00eff40ac7@github.com>
Message-ID: <AsMhBQ_8RMzAI0me2ZF-rWM8WGtzfIfArvIW4I8EHs0=.1844621f-36c4-4ca9-9ec0-c6215c0855ba@github.com>

On Wed, 11 Jun 2025 11:41:41 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Extract shared function to compute current token
>
> test/jdk/tools/launcher/ArgFileSyntax.java line 177:
> 
>> 175:         },
>> 176:         { // multiple args in one line and comments without preceding whitespace
>> 177:             { "-Xmx32m -XshowSettings#COMMENT 1",
> 
> First case feels like a duplicate of the test at line 73. What's different?
> Maybe this case should just live next to that?

It only _feels_ so. Mind the gap(s) before the `#` number signs in the test at line 73: they were and are still supported. This fix and test now ensures that comments without gaps (read: whitespace) are supported.

> Maybe this case should just live next to that?

The location of the new test data is next to another "whitespace-related" use-case. So, it's also related.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2139957273

From joehw at openjdk.org  Wed Jun 11 16:02:27 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 11 Jun 2025 16:02:27 GMT
Subject: RFR: 8358819: The first year is not displayed correctly in
 Japanese Calendar
In-Reply-To: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
References: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
Message-ID: <8m4PUpNUOMs2rbKcqJHazmWEdWfTgJvmYGeTXY66QR4=.560130ed-9050-4570-8e3f-a414b85e0229@github.com>

On Tue, 10 Jun 2025 18:36:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This regression was introduced by the removal of the COMPAT locale provider, which partially broke support for the first year in the Japanese calendar. In the Japanese calendar system, the first year of an era should be formatted using the character "?" rather than the numeral "1". The issue arises from a difference in how pattern character lengths are interpreted between CLDR and SimpleDateFormat. The existing `JapaneseEraNameTest` has been updated to cover this fix.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25732#pullrequestreview-2917827987

From naoto at openjdk.org  Wed Jun 11 16:06:40 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Jun 2025 16:06:40 GMT
Subject: RFR: 8358734: Remove JavaTimeSupplementary resource bundles [v2]
In-Reply-To: <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
References: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
 <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
Message-ID: <Yt_KRdsimBaJrGR7qEGyaHtRhM_mZme2el-Om6LD8xQ=.9430597c-4aa4-4269-97b3-0e326748a5cc@github.com>

On Mon, 9 Jun 2025 20:07:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The parallel loading of JavaTimeSupplementary was a historical artifact from the introduction of JSR 310, which additionally loads resouces that had not existed before. Since the COMPAT locale provider which relied on this mechanism has been removed, and the CLDR resource bundles now include those resources by default, removing the parallel loading mechanism simplifies the implementation
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the bundle

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25699#issuecomment-2963386589

From naoto at openjdk.org  Wed Jun 11 16:06:40 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Jun 2025 16:06:40 GMT
Subject: Integrated: 8358734: Remove JavaTimeSupplementary resource bundles
In-Reply-To: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
References: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
Message-ID: <dsQ2hgsAnMnxjrv3_TG0356h1X6hYyvaaI9ObE6cV78=.19a09ca2-2e88-447b-9612-e0578402b2a0@github.com>

On Mon, 9 Jun 2025 19:04:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The parallel loading of JavaTimeSupplementary was a historical artifact from the introduction of JSR 310, which additionally loads resouces that had not existed before. Since the COMPAT locale provider which relied on this mechanism has been removed, and the CLDR resource bundles now include those resources by default, removing the parallel loading mechanism simplifies the implementation

This pull request has now been integrated.

Changeset: e9216efe
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e9216efefc12b04c372a0a7f47167c984be544b7
Stats:     1093 lines in 11 files changed: 263 ins; 792 del; 38 mod

8358734: Remove JavaTimeSupplementary resource bundles

Reviewed-by: jlu, joehw, iris

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

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

From duke at openjdk.org  Wed Jun 11 16:08:30 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Wed, 11 Jun 2025 16:08:30 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks
In-Reply-To: <FfiQ25MUw5uoY6GQy6eBVQLyD6yQ1uEJjjaZUXIn_4k=.c62d4703-b6e5-4b90-b1e4-b5d359c4459e@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <RSw6f0K6lXGV1W1l3aA0dC6Pf8317W_caoDKCW3gEYs=.48da9942-f2c4-47e8-94df-b1e22721d70e@github.com>
 <FfiQ25MUw5uoY6GQy6eBVQLyD6yQ1uEJjjaZUXIn_4k=.c62d4703-b6e5-4b90-b1e4-b5d359c4459e@github.com>
Message-ID: <ujkGW61wwGpe-bsfif0OKciM10D-g02ujpqWnjCMdeo=.3aedabbc-f00f-4fb1-ae20-40a84e5ff13b@github.com>

On Thu, 8 May 2025 13:58:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Would it be possible to paste in here, or in the JBS issue, some examples of the path provided to LoadLibrary with some commentary on the sym links created on the file system.
>
>> You might be correct. We'll see what @AlanBateman and others have to say about it.
> 
> I'm still puzzled as to why the DLLs have been moved from the JDK bin directory to some other location, and renamed so they don't have the ".dll" suffix. There most be some other product in the picture that we can't see. The quoted text from the Windows LoadLibrary documentation, where it appends the ".dll" suffix when not provided, is very useful as it  helps us understand why it fails.
> 
> As regards dropping the canonicalization then it would require thinking about the lock map used for mapping the library names to locks. It would need checking if it would break concurrent loading when using different names / file paths to the same DLL. There may be a route that involves adding a method to ClassLoaderHelper to post-process the path and the Windows version could add the "." when it doesn't have the ".dll" suffix.

@AlanBateman any further feedback here?

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

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2963394413

From jpai at openjdk.org  Wed Jun 11 16:09:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 16:09:28 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet
In-Reply-To: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
Message-ID: <kJOJZk4TWH4Fzw7hCawLZlfXXcVK6itZlG5JIRWowEY=.35e8a56b-1d52-41f1-b336-b5b8dc95441e@github.com>

On Mon, 9 Jun 2025 20:42:43 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
> 
> `testclasses.jar` is updated such that the two classes no longer extend Applet.
> 
> 
> $ javap fo\ o.class 
> public class fo o {
> }
> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
> public class ?? {
> }
> 
> 
> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
> 
> Additionally, the security APIs that were marked for removal are also removed from this test as well.

Hello Justin, how was the class file with those space characters in the method name and the class name generated? If we can do that within the test itself then I think it should also allow us to generate that JAR file dynamically in the test instead of having to continue maintaining this binary file.

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

PR Comment: https://git.openjdk.org/jdk/pull/25703#issuecomment-2963398242

From naoto at openjdk.org  Wed Jun 11 16:13:32 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Jun 2025 16:13:32 GMT
Subject: RFR: 8358819: The first year is not displayed correctly in
 Japanese Calendar
In-Reply-To: <9SlpSwJRk_-ykaByQT771ZeFCvFXWsvdnex127x31_w=.5dde6765-5366-425c-a425-d67e2e57b4fe@github.com>
References: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
 <9SlpSwJRk_-ykaByQT771ZeFCvFXWsvdnex127x31_w=.5dde6765-5366-425c-a425-d67e2e57b4fe@github.com>
Message-ID: <-T2XZBJMsg_Vje6yi-FbXkAwXf5LNxezXirf4adYAvw=.6675e4e0-99cb-4331-810e-7376d515dd5c@github.com>

On Wed, 11 Jun 2025 07:46:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> So we are updating the CLDRConverter to adapt the old COMPAT style pattern: "yyyy" when using Japanese calendar for LONG or FULL `SimpleDateFormat` patterns, such that it can replicate the old "gannen" style which emits the ?.

Yes, that?s correct. The patterns used in CLDR, SimpleDateFormat, and DateTimeFormatterBuilder are similar, but there are some differences that can be quite a pain. CLDRConverter tries to handle these differences, but I don?t think it?s entirely accurate. This case falls into that category.

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

PR Comment: https://git.openjdk.org/jdk/pull/25732#issuecomment-2963411259

From jlu at openjdk.org  Wed Jun 11 16:59:34 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 11 Jun 2025 16:59:34 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet
In-Reply-To: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
Message-ID: <aXL7ZsYAPVWadbsluxuAg4FPsXdL-UBHhRkqWdHwkMQ=.961a600a-d69e-4433-ba12-8c5d1c03a027@github.com>

On Mon, 9 Jun 2025 20:42:43 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
> 
> `testclasses.jar` is updated such that the two classes no longer extend Applet.
> 
> 
> $ javap fo\ o.class 
> public class fo o {
> }
> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
> public class ?? {
> }
> 
> 
> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
> 
> Additionally, the security APIs that were marked for removal are also removed from this test as well.

Hi Jai, I had trouble creating class "fo o" through traditional means, so I used the ClassFile API to create those class files. Using `JDKToolFinder.getCompileJDKTool("jar")` with the CF API seems reasonable to do all the work dynamically. I will take a look, thanks for the idea.

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

PR Comment: https://git.openjdk.org/jdk/pull/25703#issuecomment-2963544294

From vromero at openjdk.org  Wed Jun 11 17:02:28 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 11 Jun 2025 17:02:28 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment [v2]
In-Reply-To: <WDT4hGnZmonDpTycLenA9jd_OCqJ2jrmgLAXfd6TxtA=.925df0d9-12d2-403d-92c6-26f927585f1b@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
 <WDT4hGnZmonDpTycLenA9jd_OCqJ2jrmgLAXfd6TxtA=.925df0d9-12d2-403d-92c6-26f927585f1b@github.com>
Message-ID: <eFpBQC2CKyUxLn-mDn6geKi4wVMxIss3xpoEpCwaKF0=.689397c3-bbf3-4496-93d2-8901225df113@github.com>

On Wed, 11 Jun 2025 08:30:18 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign.
>> 
>> The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files):
>> 
>> Use the number sign `#` in the argument file to identify comments.
>> All characters following the `#` are ignored until the end of line.
>> 
>> There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extract shared function to compute current token

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25589#pullrequestreview-2918023875

From jpai at openjdk.org  Wed Jun 11 17:07:30 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 17:07:30 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet
In-Reply-To: <aXL7ZsYAPVWadbsluxuAg4FPsXdL-UBHhRkqWdHwkMQ=.961a600a-d69e-4433-ba12-8c5d1c03a027@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <aXL7ZsYAPVWadbsluxuAg4FPsXdL-UBHhRkqWdHwkMQ=.961a600a-d69e-4433-ba12-8c5d1c03a027@github.com>
Message-ID: <abM66wQ02tNsHURgBpTuGphDKoNALHkVpKWXOkHN_iQ=.f397b4ac-9d21-4fa1-a2f8-1a80c3d13da5@github.com>

On Wed, 11 Jun 2025 16:56:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

> so I used the ClassFile API to create those class files.

Use of ClassFile API I think is a good approach.

> Using JDKToolFinder.getCompileJDKTool("jar") with the CF API seems reasonable to do all the work dynamically. I will take a look, thanks for the idea.

If you run into trouble using the `jar` tool, then we have other APIs/ways to generate such JAR file within the test. I'll let you continue experimenting with the `jar` tool and if you think you will need help at some point, then let me know and I can try a few things in this test.

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

PR Comment: https://git.openjdk.org/jdk/pull/25703#issuecomment-2963567634

From jvernee at openjdk.org  Wed Jun 11 17:14:29 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 11 Jun 2025 17:14:29 GMT
Subject: RFR: 8345292: Improve javadocs for MemorySegment::getStrings
 defining word boundary cases [v2]
In-Reply-To: <FVDMRZXsGbZRCYYdv_lk2vuR18T3_a0jHSsLG-JUxbU=.022a0fd7-0a53-4375-9db1-672d17e94996@github.com>
References: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
 <FVDMRZXsGbZRCYYdv_lk2vuR18T3_a0jHSsLG-JUxbU=.022a0fd7-0a53-4375-9db1-672d17e94996@github.com>
Message-ID: <tGQcMvM_Xzm1ssUEVGNLwtR5fhOKbynCxjVBtWkbFdE=.be7dd033-8e23-48ab-abb1-c22315cab9a8@github.com>

On Tue, 10 Jun 2025 17:01:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset charset)` method documentation with respect to multi-octet concerns.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after comments

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1311:

> 1309:      *           bytes of this segment are not accessed. For multi-octet charset,
> 1310:      *           {@code '\0'} terminator characters are only detected on
> 1311:      *           multi-octet-aligned boundaries.

Typo:

Suggestion:

     * @implNote If the {@linkplain #byteSize()} of this segment is not evenly dividable
     *           by the number of octets used by the provided {@code charset}, the remaining
     *           bytes of this segment are not accessed. For multi-octet charset,
     *           {@code '\0'} terminator characters are only detected on
     *           multi-octet-aligned boundaries.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25715#discussion_r2140698024

From pminborg at openjdk.org  Wed Jun 11 17:20:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Jun 2025 17:20:14 GMT
Subject: RFR: 8345292: Improve javadocs for MemorySegment::getStrings
 defining word boundary cases [v3]
In-Reply-To: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
References: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
Message-ID: <tETizozG4QYwH3blCHYSxhhbPyOzbqOIAaiPPGYsKIA=.f95a0abd-d029-457f-a81a-fef822512b65@github.com>

> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset charset)` method documentation with respect to multi-octet concerns.

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

  Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
  
  Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25715/files
  - new: https://git.openjdk.org/jdk/pull/25715/files/86b891a2..928e41f7

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

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

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

From mcimadamore at openjdk.org  Wed Jun 11 17:20:14 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jun 2025 17:20:14 GMT
Subject: RFR: 8345292: Improve javadocs for MemorySegment::getStrings
 defining word boundary cases [v2]
In-Reply-To: <FVDMRZXsGbZRCYYdv_lk2vuR18T3_a0jHSsLG-JUxbU=.022a0fd7-0a53-4375-9db1-672d17e94996@github.com>
References: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
 <FVDMRZXsGbZRCYYdv_lk2vuR18T3_a0jHSsLG-JUxbU=.022a0fd7-0a53-4375-9db1-672d17e94996@github.com>
Message-ID: <0NMH-KJhUXS4pmlucsPr35mPwAk6cFLK9DZKdNVKcXA=.3eb5bbdc-5bec-4d8a-9770-c3440c847c55@github.com>

On Tue, 10 Jun 2025 17:01:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset charset)` method documentation with respect to multi-octet concerns.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after comments

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1307:

> 1305:      *     return new String(bytes, charset);
> 1306:      * }
> 1307:      * @implNote If the {@linkplain #byteSize()} of this segment is not evenly dividable

can we say more directly "if the size is not a multiple of ..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25715#discussion_r2140703485

From pminborg at openjdk.org  Wed Jun 11 17:24:11 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Jun 2025 17:24:11 GMT
Subject: RFR: 8345292: Improve javadocs for MemorySegment::getStrings
 defining word boundary cases [v4]
In-Reply-To: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
References: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
Message-ID: <j-Phku1ENANL6JYUYbWOlJ9R9hNkCyoyXKlPszMDGy0=.59bbb893-1fcc-4ec7-86ac-90edcce92948@github.com>

> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset charset)` method documentation with respect to multi-octet concerns.

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

  Improve wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25715/files
  - new: https://git.openjdk.org/jdk/pull/25715/files/928e41f7..4ea36452

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

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

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

From iris at openjdk.org  Wed Jun 11 17:47:29 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 11 Jun 2025 17:47:29 GMT
Subject: RFR: 8358819: The first year is not displayed correctly in
 Japanese Calendar
In-Reply-To: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
References: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
Message-ID: <tc36KXewrRNJeCnGED9Tfg5JT9IhDY8Xw9XFb9FJf7M=.83fd1338-eb53-4ac9-b442-cd4e24b40063@github.com>

On Tue, 10 Jun 2025 18:36:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This regression was introduced by the removal of the COMPAT locale provider, which partially broke support for the first year in the Japanese calendar. In the Japanese calendar system, the first year of an era should be formatted using the character "?" rather than the numeral "1". The issue arises from a difference in how pattern character lengths are interpreted between CLDR and SimpleDateFormat. The existing `JapaneseEraNameTest` has been updated to cover this fix.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25732#pullrequestreview-2918162430

From duke at openjdk.org  Wed Jun 11 19:44:20 2025
From: duke at openjdk.org (kabutz)
Date: Wed, 11 Jun 2025 19:44:20 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v10]
In-Reply-To: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
Message-ID: <V-TBm1w3a9dyFlCsfMqcLbe874bc4wjIUzwkk5UczNA=.99f7ebea-af93-4078-8614-bb4a838d250f@github.com>

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

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

 - Update src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java
   
   Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
 - Update src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java
   
   Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24925/files
  - new: https://git.openjdk.org/jdk/pull/24925/files/16095666..6bdd22f2

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

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

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

From mcimadamore at openjdk.org  Wed Jun 11 21:29:29 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jun 2025 21:29:29 GMT
Subject: RFR: 8345292: Improve javadocs for MemorySegment::getStrings
 defining word boundary cases [v4]
In-Reply-To: <j-Phku1ENANL6JYUYbWOlJ9R9hNkCyoyXKlPszMDGy0=.59bbb893-1fcc-4ec7-86ac-90edcce92948@github.com>
References: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
 <j-Phku1ENANL6JYUYbWOlJ9R9hNkCyoyXKlPszMDGy0=.59bbb893-1fcc-4ec7-86ac-90edcce92948@github.com>
Message-ID: <Kiy4jMkaI4XAlw5IL6Wy4Z7Vo2hppwWd5YDq_nrDjc4=.bae953f3-c8b8-4350-a8f6-d1035f6ee3bb@github.com>

On Wed, 11 Jun 2025 17:24:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset charset)` method documentation with respect to multi-octet concerns.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve wording

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1307:

> 1305:      *     return new String(bytes, charset);
> 1306:      * }
> 1307:      * @implNote If the segment size is not evenly dividable by the number of octets used

I think the relevant concepts here are:
* a valid charset has a fixed encoding where each character is turned into N bytes
* the terminator is also N bytes long
* the number of bytes read is given by the result of the integer division `S / N`, where `S` is the size of the segment (because if we have a remainder R < N, then we know it can't be a valid terminator)
* I'm not sure what you mean by that last sentence. Maybe that if you have `N = 4`, and you have `AA00`, `00BB`, those four zeros are not considered a terminator? I think speaking of alignment here is misleading, because we're not really suggesting that a terminator in a `N = 4` charset should start at an address that is 4-byte aligned -- we're just saying that the _offset_ at which that terminator starts (relative to the start of the segment) is a multiple of 4.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25715#discussion_r2141145457

From bpb at openjdk.org  Wed Jun 11 21:34:27 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Jun 2025 21:34:27 GMT
Subject: RFR: 8359182: Use @requires instead of SkippedException for
 MaxPath.java
In-Reply-To: <d0ot80Ub_x8xbRMQSNxUKV2O27RjN8Z1nXvjznDPdi4=.2617694b-535e-4140-a120-6914bb5d20cc@github.com>
References: <d0ot80Ub_x8xbRMQSNxUKV2O27RjN8Z1nXvjznDPdi4=.2617694b-535e-4140-a120-6914bb5d20cc@github.com>
Message-ID: <i3HuujH0dJ7cNEOrg5iXtYG3Guu--3yqgjwfUVpKMEc=.a4b4457c-6ab6-4790-8e7a-e1a388452c00@github.com>

On Wed, 11 Jun 2025 07:15:43 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> I think use `@requires (os.family == "windows")` is more elegant than thow jtreg.SkippedException in test java/io/File/MaxPath.java.
> 
> On linux before this PR, run this test jtreg report:
> 
> 
> TEST: java/io/File/MaxPath.java
> TEST RESULT: Passed. Skipped: jtreg.SkippedException: This test is run only on Windows
> 
> 
> On linux after this PR, run this test jtreg report:
> 
> 
> Test results: no tests selected
> 
> 
> Change has been verified locally both on linux and windows, test-fix only, no risk.

Looks fine. I also verified on Linux and Windows.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25742#pullrequestreview-2918800295

From bchristi at openjdk.org  Wed Jun 11 22:40:28 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 11 Jun 2025 22:40:28 GMT
Subject: RFR: 8359182: Use @requires instead of SkippedException for
 MaxPath.java
In-Reply-To: <d0ot80Ub_x8xbRMQSNxUKV2O27RjN8Z1nXvjznDPdi4=.2617694b-535e-4140-a120-6914bb5d20cc@github.com>
References: <d0ot80Ub_x8xbRMQSNxUKV2O27RjN8Z1nXvjznDPdi4=.2617694b-535e-4140-a120-6914bb5d20cc@github.com>
Message-ID: <Zzc4cjoREL0q2WykRZI3TpnA3th6CHel-PMtwqM2MPw=.a3e04662-c1ae-4fcd-a1aa-2ebf9f2c68cb@github.com>

On Wed, 11 Jun 2025 07:15:43 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> I think use `@requires (os.family == "windows")` is more elegant than thow jtreg.SkippedException in test java/io/File/MaxPath.java.
> 
> On linux before this PR, run this test jtreg report:
> 
> 
> TEST: java/io/File/MaxPath.java
> TEST RESULT: Passed. Skipped: jtreg.SkippedException: This test is run only on Windows
> 
> 
> On linux after this PR, run this test jtreg report:
> 
> 
> Test results: no tests selected
> 
> 
> Change has been verified locally both on linux and windows, test-fix only, no risk.

Marked as reviewed by bchristi (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25742#pullrequestreview-2918913804

From jlu at openjdk.org  Wed Jun 11 22:40:43 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 11 Jun 2025 22:40:43 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v2]
In-Reply-To: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
Message-ID: <XyQDGxDBfdASO7mHAj8BqpHxPESugXyRwf6y_5S2aVs=.d6f45bb5-98f6-4996-a4b1-a8f6049bf7f1@github.com>

> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
> 
> `testclasses.jar` is updated such that the two classes no longer extend Applet.
> 
> 
> $ javap fo\ o.class 
> public class fo o {
> }
> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
> public class ?? {
> }
> 
> 
> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
> 
> Additionally, the security APIs that were marked for removal are also removed from this test as well.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Jai's review - dynamically create jar file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25703/files
  - new: https://git.openjdk.org/jdk/pull/25703/files/5d4faa36..ab8785cc

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

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

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

From jlu at openjdk.org  Wed Jun 11 22:40:44 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 11 Jun 2025 22:40:44 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet
In-Reply-To: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
Message-ID: <nvCWx_R-52C09lls5FtHXqjK0Pkxly5yjN4l7Co8KYM=.777b154d-b918-496e-9838-7cecafdd758d@github.com>

On Mon, 9 Jun 2025 20:42:43 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
> 
> `testclasses.jar` is updated such that the two classes no longer extend Applet.
> 
> 
> $ javap fo\ o.class 
> public class fo o {
> }
> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
> public class ?? {
> }
> 
> 
> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
> 
> Additionally, the security APIs that were marked for removal are also removed from this test as well.

Hi Jai,

https://github.com/openjdk/jdk/pull/25703/commits/ab8785ccf068d19da049ca9233311b50a680f799 dynamically creates the class and jar file. I decided not to write "??" as a Jar entry, since it's commented out in the test. It should be trivial to dynamically create an entry for that class in the future if needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25703#issuecomment-2964463834

From smarks at openjdk.org  Wed Jun 11 23:18:41 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 11 Jun 2025 23:18:41 GMT
Subject: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty
 pointing to newer APIs
Message-ID: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>

Add a note to String.trim pointing to the String.strip family of methods.

Add notes cross-linking String.isBlank and String.isEmpty.

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

Commit messages:
 - Updates to String javadoc.

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

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

From bpb at openjdk.org  Wed Jun 11 23:46:27 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Jun 2025 23:46:27 GMT
Subject: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty
 pointing to newer APIs
In-Reply-To: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
References: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
Message-ID: <8RLyq6RUkKSV14yisVjqP13fGIzZUKhotSRQAaeVmgc=.f15f1ae5-c20a-429a-a2f4-2994943a76a1@github.com>

On Wed, 11 Jun 2025 22:39:48 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Add a note to String.trim pointing to the String.strip family of methods.
> 
> Add notes cross-linking String.isBlank and String.isEmpty.

src/java.base/share/classes/java/lang/String.java line 3837:

> 3835:      *
> 3836:      * @apiNote
> 3837:      * This method uses a ASCII-based definition of space characters that are to be

"a ASCII" or "an ASCII"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25762#discussion_r2141272697

From jlu at openjdk.org  Wed Jun 11 23:54:30 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 11 Jun 2025 23:54:30 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v3]
In-Reply-To: <-6TYWikmLNBtyQt6_xeJ8KoziHxA8Ijr067NIc740X0=.2f9e4cae-7f39-46b8-b3a9-f381fb2e0518@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <-6TYWikmLNBtyQt6_xeJ8KoziHxA8Ijr067NIc740X0=.2f9e4cae-7f39-46b8-b3a9-f381fb2e0518@github.com>
Message-ID: <JNEKtkhrEYnS1SvaSz7GhcS4FQGkQXma4nY_Wo0T18A=.3dce72d9-7250-4672-adad-13db79e3150c@github.com>

On Tue, 10 Jun 2025 15:41:47 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>> 
>> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
>> 
>> Testing:
>> - GHA
>> - Local run of tier 2 and jtreg:jdk/java/text
>> - New benchmark: DecimalFormatParseBench
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

On our CI, I did a java_text JCK run as well as tiers 1-3 on all platforms which both came back good. I just have a final comment.

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1841:

> 1839: 
> 1840:     static ASCIIToBinaryConverter readDoubleSignlessDigits(int decExp, char[] digits, int length) {
> 1841:         if (decExp < MIN_DECIMAL_EXPONENT) {

Is this check needed? I think `ASCIIToBinaryConverter` will return the proper zero value when `doubleValue()` is invoked. 


  if (decExponent < MIN_DECIMAL_EXPONENT - 1) {
      return (isNegative) ? -0.0 : 0.0;


And if this explicit check is a shortcut, I don't think we would need one for an edge case.

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

PR Review: https://git.openjdk.org/jdk/pull/25644#pullrequestreview-2918990809
PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2141274926

From jlu at openjdk.org  Wed Jun 11 23:54:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 11 Jun 2025 23:54:31 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v2]
In-Reply-To: <Du9MYXbdEwDCcfImykmsIkXrXYB59O2VZwd3bH3YbNk=.c77cc3ab-5a5f-457e-9239-a23127587cf4@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <jNo1y3QVwzaJ-e2yXXZH-hFmbtRerqT4vSytEHBN2x0=.9725dfee-cd87-4739-b313-c23af309d4ea@github.com>
 <Du9MYXbdEwDCcfImykmsIkXrXYB59O2VZwd3bH3YbNk=.c77cc3ab-5a5f-457e-9239-a23127587cf4@github.com>
Message-ID: <2KakG2f6v5WErZ_1oABFztNLVjk3qu4yO0gPZhzJxE4=.8fe81659-53fb-4ff7-91ab-401296786278@github.com>

On Mon, 9 Jun 2025 23:44:20 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   catch ArithmeticException
>
> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1848:
> 
>> 1846:             buf[i] = (byte) digits[i];
>> 1847:         }
>> 1848:         return new ASCIIToBinaryBuffer(false, decExp, buf, length);
> 
> Since `negSign` is always false, adding a _positive_ somewhere to the method name might be helpful/explicit. Although you could argue that the array parameter itself is telling enough, but one could misinterpret the char array as including a sign character.

Thanks, I think "signless" is better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2141278327

From naoto at openjdk.org  Thu Jun 12 00:00:28 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 12 Jun 2025 00:00:28 GMT
Subject: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty
 pointing to newer APIs
In-Reply-To: <8RLyq6RUkKSV14yisVjqP13fGIzZUKhotSRQAaeVmgc=.f15f1ae5-c20a-429a-a2f4-2994943a76a1@github.com>
References: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
 <8RLyq6RUkKSV14yisVjqP13fGIzZUKhotSRQAaeVmgc=.f15f1ae5-c20a-429a-a2f4-2994943a76a1@github.com>
Message-ID: <fVv_kpXk24tTzRzQM2jAAenJkx4t9oDi-SHkmd6UnIY=.cdf165c4-8def-448b-9e21-3cc5e937fa8c@github.com>

On Wed, 11 Jun 2025 23:43:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a note to String.trim pointing to the String.strip family of methods.
>> 
>> Add notes cross-linking String.isBlank and String.isEmpty.
>
> src/java.base/share/classes/java/lang/String.java line 3837:
> 
>> 3835:      *
>> 3836:      * @apiNote
>> 3837:      * This method uses a ASCII-based definition of space characters that are to be
> 
> "a ASCII" or "an ASCII"?

In fact, "ASCII-based definition of space characters" is kind of unclear to me. How about explicitly specify them as C0 controls and the space, or exactly quote the space definition in the first paragraph?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25762#discussion_r2141282711

From jlu at openjdk.org  Thu Jun 12 00:00:29 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 12 Jun 2025 00:00:29 GMT
Subject: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty
 pointing to newer APIs
In-Reply-To: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
References: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
Message-ID: <ibreU-Y-UANKIvbgW60R7ZypVuZRuMsKjzcIo_QH1uU=.0ab0dc3b-6303-4307-bec4-cbc1a88ad480@github.com>

On Wed, 11 Jun 2025 22:39:48 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Add a note to String.trim pointing to the String.strip family of methods.
> 
> Add notes cross-linking String.isBlank and String.isEmpty.

src/java.base/share/classes/java/lang/String.java line 3937:

> 3935: 
> 3936:     /**
> 3937:      * Returns {@code true} if the string is empty or contains only

This method seems like a good candidate to use `{@return ...}`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25762#discussion_r2141282138

From smarks at openjdk.org  Thu Jun 12 00:37:30 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 12 Jun 2025 00:37:30 GMT
Subject: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty
 pointing to newer APIs
In-Reply-To: <fVv_kpXk24tTzRzQM2jAAenJkx4t9oDi-SHkmd6UnIY=.cdf165c4-8def-448b-9e21-3cc5e937fa8c@github.com>
References: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
 <8RLyq6RUkKSV14yisVjqP13fGIzZUKhotSRQAaeVmgc=.f15f1ae5-c20a-429a-a2f4-2994943a76a1@github.com>
 <fVv_kpXk24tTzRzQM2jAAenJkx4t9oDi-SHkmd6UnIY=.cdf165c4-8def-448b-9e21-3cc5e937fa8c@github.com>
Message-ID: <SL0JKOABu7PRL2JEQwPp6M6vTl5A8yDMls9_5wRl4As=.c8982000-ebde-487f-acd6-4b27d67a2110@github.com>

On Wed, 11 Jun 2025 23:57:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 3837:
>> 
>>> 3835:      *
>>> 3836:      * @apiNote
>>> 3837:      * This method uses a ASCII-based definition of space characters that are to be
>> 
>> "a ASCII" or "an ASCII"?
>
> In fact, "ASCII-based definition of space characters" is kind of unclear to me. How about explicitly specify them as C0 controls and the space, or exactly quote the space definition in the first paragraph?

Oh yeah, that should be "an ASCII...."

But maybe we should change the wording per @naotoj's comment. I don't want to repeat the specification above, but rather I want to describe it in terms of what the thinking was at the time it was introduced in JDK 1.0. For comparison, in JDK 1.0, the way to create a String from bytes was to fill in the upper 8 bits of a char using a constant "hibyte" parameter of the String(byte[], int) constructor, which is now deprecated. So this was very much an ASCII-centric view of the world.

The trim() method first appeared in 1.0 but its original specification mentioned white space without defining it. The 1.1 specification gained some details, saying

> Removes white space from both ends of this string.
>
> All characters that have codes less than or equal to '\u0020' (the space character) are considered to be white space. 

>From the 1996 or 1997 view of the world, I'd describe this as "space plus ASCII control characters." Would something like that make more sense?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25762#discussion_r2141308311

From smarks at openjdk.org  Thu Jun 12 00:37:31 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 12 Jun 2025 00:37:31 GMT
Subject: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty
 pointing to newer APIs
In-Reply-To: <ibreU-Y-UANKIvbgW60R7ZypVuZRuMsKjzcIo_QH1uU=.0ab0dc3b-6303-4307-bec4-cbc1a88ad480@github.com>
References: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
 <ibreU-Y-UANKIvbgW60R7ZypVuZRuMsKjzcIo_QH1uU=.0ab0dc3b-6303-4307-bec4-cbc1a88ad480@github.com>
Message-ID: <VyUtqQrLOh5bAJPzSvPz1Q6VP60oyigOy6NrNzF3CeA=.2503e2ef-244c-459e-8fcf-4d29db6d4739@github.com>

On Wed, 11 Jun 2025 23:57:02 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Add a note to String.trim pointing to the String.strip family of methods.
>> 
>> Add notes cross-linking String.isBlank and String.isEmpty.
>
> src/java.base/share/classes/java/lang/String.java line 3937:
> 
>> 3935: 
>> 3936:     /**
>> 3937:      * Returns {@code true} if the string is empty or contains only
> 
> This method seems like a good candidate to use `{@return ...}`.

I'll give this a try.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25762#discussion_r2141308957

From smarks at openjdk.org  Thu Jun 12 00:53:13 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 12 Jun 2025 00:53:13 GMT
Subject: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty
 pointing to newer APIs [v2]
In-Reply-To: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
References: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
Message-ID: <CSDVc501q8GwjRz8toAjj-L5w-P9fdmU2Ys2j7jbziM=.a86ba022-d535-481d-89d9-ae570994e363@github.com>

> Add a note to String.trim pointing to the String.strip family of methods.
> 
> Add notes cross-linking String.isBlank and String.isEmpty.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Use {@return ...} inline tag.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25762/files
  - new: https://git.openjdk.org/jdk/pull/25762/files/f963fe89..96c15c33

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

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

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

From smarks at openjdk.org  Thu Jun 12 00:53:13 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 12 Jun 2025 00:53:13 GMT
Subject: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty
 pointing to newer APIs [v2]
In-Reply-To: <VyUtqQrLOh5bAJPzSvPz1Q6VP60oyigOy6NrNzF3CeA=.2503e2ef-244c-459e-8fcf-4d29db6d4739@github.com>
References: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
 <ibreU-Y-UANKIvbgW60R7ZypVuZRuMsKjzcIo_QH1uU=.0ab0dc3b-6303-4307-bec4-cbc1a88ad480@github.com>
 <VyUtqQrLOh5bAJPzSvPz1Q6VP60oyigOy6NrNzF3CeA=.2503e2ef-244c-459e-8fcf-4d29db6d4739@github.com>
Message-ID: <yutDsgirXsH2BWoU8MkhiO8YPd_7AK5EUnxD7zFgCkE=.ae344cb4-40cd-4baa-afe2-05fc0248151a@github.com>

On Thu, 12 Jun 2025 00:35:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 3937:
>> 
>>> 3935: 
>>> 3936:     /**
>>> 3937:      * Returns {@code true} if the string is empty or contains only
>> 
>> This method seems like a good candidate to use `{@return ...}`.
>
> I'll give this a try.

Thanks, this is a nice simplification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25762#discussion_r2141318925

From naoto at openjdk.org  Thu Jun 12 01:57:34 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 12 Jun 2025 01:57:34 GMT
Subject: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty
 pointing to newer APIs [v2]
In-Reply-To: <SL0JKOABu7PRL2JEQwPp6M6vTl5A8yDMls9_5wRl4As=.c8982000-ebde-487f-acd6-4b27d67a2110@github.com>
References: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
 <8RLyq6RUkKSV14yisVjqP13fGIzZUKhotSRQAaeVmgc=.f15f1ae5-c20a-429a-a2f4-2994943a76a1@github.com>
 <fVv_kpXk24tTzRzQM2jAAenJkx4t9oDi-SHkmd6UnIY=.cdf165c4-8def-448b-9e21-3cc5e937fa8c@github.com>
 <SL0JKOABu7PRL2JEQwPp6M6vTl5A8yDMls9_5wRl4As=.c8982000-ebde-487f-acd6-4b27d67a2110@github.com>
Message-ID: <zNf4IR9I87TVLLlbQ0HvmPD6bc3LQ0PWxsIz58uA0yw=.016cef8b-45f1-476d-8bcc-eadbd14d3f37@github.com>

On Thu, 12 Jun 2025 00:34:11 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> I'd describe this as "space plus ASCII control characters." Would something like that make more sense?

Yeah, I think so

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25762#discussion_r2141368745

From stuefe at openjdk.org  Thu Jun 12 03:33:35 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 12 Jun 2025 03:33:35 GMT
Subject: Withdrawn: 8357089: Remove VFORK launch mechanism from Process
 implementation (linux)
In-Reply-To: <ai9TtPMOdbPnuc90ciCMD-0p1rO7Bu8gwFF-HrsQ1Zo=.f1a209d7-2aae-49ea-b058-73a1b27ad752@github.com>
References: <ai9TtPMOdbPnuc90ciCMD-0p1rO7Bu8gwFF-HrsQ1Zo=.f1a209d7-2aae-49ea-b058-73a1b27ad752@github.com>
Message-ID: <TThwKW7x7yhVDUsvLtDJSs4AOdBi2bRs4LajvZsB3kc=.feaac7a1-6003-4858-93c2-8ef66fba471b@github.com>

On Fri, 16 May 2025 06:14:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Not for JDK 25
> 
> See  the companion CSR (https://bugs.openjdk.org/browse/JDK-8357090) for the ratio behind this removal.
> 
> Patch
> 
> - removes all code handling the VFORK mode.
> - removes or rewrites comments explaining use of vfork by the JVM.
> - we now print out an error message to stderr if the user still specifies `-Djdk.lang.Process.launchMechanism=vfork`.

This pull request has been closed without being integrated.

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

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

From stuefe at openjdk.org  Thu Jun 12 05:30:05 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 12 Jun 2025 05:30:05 GMT
Subject: RFR: 8357089: Remove VFORK launch mechanism from Process
 implementation (linux)
Message-ID: <lg36ykgPsg2YFoiAxnovr7Ix3GPbUBYWFsjE8i5wl5s=.fe37a5a0-223a-4b8f-810f-e529420bf46b@github.com>

(for JDK 26)

Note: This PR is a continuation of the old PR here: https://github.com/openjdk/jdk/pull/25260; had to close the old one since I had Skara problems after the JDK25 split-off.

See the companion CSR (https://bugs.openjdk.org/browse/JDK-8357090) for the ratio behind this removal.

Patch

- removes all code handling the VFORK mode.
- removes or clarifies comments explaining use of vfork by the JVM.
- we now print out an error message to stderr if the user still specifies -Djdk.lang.Process.launchMechanism=vfork.

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

Commit messages:
 - warning message
 - remove-vfork

Changes: https://git.openjdk.org/jdk/pull/25768/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25768&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357089
  Stats: 122 lines in 4 files changed: 1 ins; 93 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/25768.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25768/head:pull/25768

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

From syan at openjdk.org  Thu Jun 12 07:54:34 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 12 Jun 2025 07:54:34 GMT
Subject: RFR: 8359182: Use @requires instead of SkippedException for
 MaxPath.java
In-Reply-To: <Zzc4cjoREL0q2WykRZI3TpnA3th6CHel-PMtwqM2MPw=.a3e04662-c1ae-4fcd-a1aa-2ebf9f2c68cb@github.com>
References: <d0ot80Ub_x8xbRMQSNxUKV2O27RjN8Z1nXvjznDPdi4=.2617694b-535e-4140-a120-6914bb5d20cc@github.com>
 <Zzc4cjoREL0q2WykRZI3TpnA3th6CHel-PMtwqM2MPw=.a3e04662-c1ae-4fcd-a1aa-2ebf9f2c68cb@github.com>
Message-ID: <cLiKh52ZLmwYoOFXw3uxfECX4O1VkgcAYb9z4Im5SB8=.9d66f6c3-0379-482f-85c8-b982ab8cbadc@github.com>

On Wed, 11 Jun 2025 22:37:53 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Hi all,
>> 
>> I think use `@requires (os.family == "windows")` is more elegant than thow jtreg.SkippedException in test java/io/File/MaxPath.java.
>> 
>> On linux before this PR, run this test jtreg report:
>> 
>> 
>> TEST: java/io/File/MaxPath.java
>> TEST RESULT: Passed. Skipped: jtreg.SkippedException: This test is run only on Windows
>> 
>> 
>> On linux after this PR, run this test jtreg report:
>> 
>> 
>> Test results: no tests selected
>> 
>> 
>> Change has been verified locally both on linux and windows, test-fix only, no risk.
>
> Marked as reviewed by bchristi (Reviewer).

Thanks @bchristi-git @bplb for the verify and reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/25742#issuecomment-2965520823

From syan at openjdk.org  Thu Jun 12 07:54:35 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 12 Jun 2025 07:54:35 GMT
Subject: Integrated: 8359182: Use @requires instead of SkippedException for
 MaxPath.java
In-Reply-To: <d0ot80Ub_x8xbRMQSNxUKV2O27RjN8Z1nXvjznDPdi4=.2617694b-535e-4140-a120-6914bb5d20cc@github.com>
References: <d0ot80Ub_x8xbRMQSNxUKV2O27RjN8Z1nXvjznDPdi4=.2617694b-535e-4140-a120-6914bb5d20cc@github.com>
Message-ID: <6cr2c04QOG83b_GCTLkWWwIDChkKk1V6rgKzyVeFDyA=.09c2a5f1-63a0-4a63-9b0c-ea27db4b7d2d@github.com>

On Wed, 11 Jun 2025 07:15:43 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> I think use `@requires (os.family == "windows")` is more elegant than thow jtreg.SkippedException in test java/io/File/MaxPath.java.
> 
> On linux before this PR, run this test jtreg report:
> 
> 
> TEST: java/io/File/MaxPath.java
> TEST RESULT: Passed. Skipped: jtreg.SkippedException: This test is run only on Windows
> 
> 
> On linux after this PR, run this test jtreg report:
> 
> 
> Test results: no tests selected
> 
> 
> Change has been verified locally both on linux and windows, test-fix only, no risk.

This pull request has now been integrated.

Changeset: 5886ef72
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5886ef728fc1efe43e90e056c03725c3ee982ad6
Stats:     8 lines in 1 file changed: 0 ins; 7 del; 1 mod

8359182: Use @requires instead of SkippedException for MaxPath.java

Reviewed-by: bpb, bchristi

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

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

From duke at openjdk.org  Thu Jun 12 09:24:05 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Thu, 12 Jun 2025 09:24:05 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page
Message-ID: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>

Please review my PR. This PR includes the following:

- [ ] Fix a small typo in a word and copyright

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

Commit messages:
 - Attempt to fix whitespaces
 - Apply suggestions from code review
 - Update jmod create examples
 - Update copyright text
 - Fix a small typo

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

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

From cstein at openjdk.org  Thu Jun 12 09:24:05 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 12 Jun 2025 09:24:05 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page
In-Reply-To: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
Message-ID: <eoexu5qxt9u0MUDDLGeCPAct6BVxz0TgcCfBRWmCr70=.a52d07ee-382b-4ce9-805b-94c19eb8053d@github.com>

On Thu, 12 Jun 2025 07:57:20 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

> Please review my PR. This PR includes the following:
> 
> - [ ] Fix a small typo in a word and copyright

src/jdk.jlink/share/man/jmod.md line 183:

> 181: `--target-platform` *platform*
> 182: :   Specifies the target platform. The value is a string that identifies 
> 183:     the plarform the module is intended for, typically in the form `<os>-<arch>`.

Suggestion:

    the platform this module is intended for, typically in the form `<os>-<arch>`.

src/jdk.jlink/share/man/jmod.md line 194:

> 192:     you would ordinarily enter in a command prompt. Options may appear on one
> 193:     line or on several lines. You may not specify environment variables for
> 194:     path names. You may comment out lines by prefixing a hash symbol (`#`) to

_Baxinga!_

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2142129840
PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2142130779

From duke at openjdk.org  Thu Jun 12 09:44:38 2025
From: duke at openjdk.org (duke)
Date: Thu, 12 Jun 2025 09:44:38 GMT
Subject: Withdrawn: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe
In-Reply-To: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
References: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
Message-ID: <BCBZuN-yf7YnTv8196UNLJZj1J9t7eYwkms26iKcU3A=.e51db459-5611-40fc-bd81-18126940843b@github.com>

On Wed, 19 Feb 2025 07:53:15 GMT, Nicole Xu <duke at openjdk.org> wrote:

> The UnsafeOps JMH benchmark fails with the following error:
> 
>       ```
>       java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>       ```
> 
> Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
> `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
> 
> Note that even it will raise "proprietary API" warnings after this
> patch, it is acceptable because the relevant APIs are bound for removal
> for the integrity of the platform.

This pull request has been closed without being integrated.

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

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

From vklang at openjdk.org  Thu Jun 12 09:48:39 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 12 Jun 2025 09:48:39 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v10]
In-Reply-To: <V-TBm1w3a9dyFlCsfMqcLbe874bc4wjIUzwkk5UczNA=.99f7ebea-af93-4078-8614-bb4a838d250f@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <V-TBm1w3a9dyFlCsfMqcLbe874bc4wjIUzwkk5UczNA=.99f7ebea-af93-4078-8614-bb4a838d250f@github.com>
Message-ID: <meunx3yWp1HowEzznT7wwbNuws5FJ5Pyho5sdbafVWU=.6292a894-390b-4bad-83c0-61b898dc342c@github.com>

On Wed, 11 Jun 2025 19:44:20 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 hol...
>
> kabutz has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
>  - Update src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

Great work, @kabutz ? this is now ready to integrate.

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

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24925#pullrequestreview-2920336864

From cstein at openjdk.org  Thu Jun 12 09:53:27 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 12 Jun 2025 09:53:27 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page
In-Reply-To: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
Message-ID: <hutMx3jrb7wUnQfKZFIfuRcckZTtIRVtAypUSXbaILE=.3fcd61bd-3c9f-4a03-a36d-52ff8424fc82@github.com>

On Thu, 12 Jun 2025 07:57:20 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

> Please review my PR. This PR includes the following:
> 
> - [x] Fix a small typo in a word and copyright.
> - [x] Enhance description for `--target-platform`.
> - [x] Rearrange `jmod create` example from basic to complex.

Marked as reviewed by cstein (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25772#pullrequestreview-2920350636

From duke at openjdk.org  Thu Jun 12 09:57:30 2025
From: duke at openjdk.org (kabutz)
Date: Thu, 12 Jun 2025 09:57:30 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <Zyz8nyCssvU32SJGYXRHwq6vbTUR1x5gBZmBnDYPC7Y=.97852347-7820-489c-a9b7-1d2448c5f4cc@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com>
 <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com>
 <YhkDQaU0FTyyP_42JTmUxM5x97rwSAHQbVYPJxRv3cI=.d70127c6-4f45-48b4-8b6c-eebad4084a34@github.com>
 <fT_4bHAK3fI6N5eRE7LgQ7FMt6o9C3WgTpfEh0ZbDkE=.579c1c92-0173-4f85-b7ff-83cbdf05b630@github.com>
 <LyZhpoeP4NnTHa0mSzdcRfEdvrtb3nvJST8yCz62XDo=.327dd96c-ab3a-4251-a7bd-8a23b92b2731@github.com>
 <Zyz8nyCssvU32SJGYXRHwq6vbTUR1x5gBZmBnDYPC7Y=.97852347-7820-489c-a9b7-1d2448c5f4cc@github.com>
Message-ID: <gxTmdXqWBbaR3piyiQKeezRKDSbaxxE-K4BPLV4CZSA=.72fc2c2a-ff66-489b-9533-431495546d09@github.com>

On Tue, 13 May 2025 13:16:45 GMT, kabutz <duke at openjdk.org> wrote:

>>> > @kabutz I think @AlanBateman might be able to have a look as well.
>>> > As for timing, it seems to me most reasonable if this PR (if it is to be integrated) to go in _after_ JDK25 has been forked, to give enough time for JDK26 early access feedback and giving the changes time to harden. I hope that makes sense.
>>> 
>>> That sound reasonable. When would this be?
>> 
>> About a month or so.
>
>> About a month or so.
> 
> Perfect, thanks @viktorklang-ora. I've marked the other issues as closed - duplicates, and referenced this single umbrella PR.

> Great work, @kabutz ? this is now ready to integrate.

What are the next steps for me to do ?

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

PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2965947350

From vklang at openjdk.org  Thu Jun 12 11:21:31 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 12 Jun 2025 11:21:31 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <gxTmdXqWBbaR3piyiQKeezRKDSbaxxE-K4BPLV4CZSA=.72fc2c2a-ff66-489b-9533-431495546d09@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com>
 <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com>
 <YhkDQaU0FTyyP_42JTmUxM5x97rwSAHQbVYPJxRv3cI=.d70127c6-4f45-48b4-8b6c-eebad4084a34@github.com>
 <fT_4bHAK3fI6N5eRE7LgQ7FMt6o9C3WgTpfEh0ZbDkE=.579c1c92-0173-4f85-b7ff-83cbdf05b630@github.com>
 <LyZhpoeP4NnTHa0mSzdcRfEdvrtb3nvJST8yCz62XDo=.327dd96c-ab3a-4251-a7bd-8a23b92b2731@github.com>
 <Zyz8nyCssvU32SJGYXRHwq6vbTUR1x5gBZmBnDYPC7Y=.97852347-7820-489c-a9b7-1d2448c5f4cc@github.com>
 <gxTmdXqWBbaR3piyiQKeezRKDSbaxxE-K4BPLV4CZSA=.72fc2c2a-ff66-489b-9533-431495546d09@github.com>
Message-ID: <pE5NC-Hit7cl8rgo6ZeBYdYat-JiQ-xcVI3RTbpXz08=.5ec7f660-2de2-48a6-937c-8df464d1f415@github.com>

On Thu, 12 Jun 2025 09:54:57 GMT, kabutz <duke at openjdk.org> wrote:

>>> About a month or so.
>> 
>> Perfect, thanks @viktorklang-ora. I've marked the other issues as closed - duplicates, and referenced this single umbrella PR.
>
>> Great work, @kabutz ? this is now ready to integrate.
> 
> What are the next steps for me to do ?

@kabutz Apologies, I'll let you know as soon as you can /integrate this.

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

PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2966227066

From vklang at openjdk.org  Thu Jun 12 11:38:40 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 12 Jun 2025 11:38:40 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements [v10]
In-Reply-To: <V-TBm1w3a9dyFlCsfMqcLbe874bc4wjIUzwkk5UczNA=.99f7ebea-af93-4078-8614-bb4a838d250f@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <V-TBm1w3a9dyFlCsfMqcLbe874bc4wjIUzwkk5UczNA=.99f7ebea-af93-4078-8614-bb4a838d250f@github.com>
Message-ID: <oKC-iwZ549osZRqOaKU_hE9I1EdNcUOo9oC6mpQ3CoU=.98d68bfd-3528-431e-b278-40a86322a922@github.com>

On Wed, 11 Jun 2025 19:44:20 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 hol...
>
> kabutz has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>
>  - Update src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java
>    
>    Co-authored-by: Viktor Klang <viktor.klang at oracle.com>

Changing to 1 reviewer after discussing with @AlanBateman

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

PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2966289080

From vklang at openjdk.org  Thu Jun 12 11:42:36 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 12 Jun 2025 11:42:36 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <gxTmdXqWBbaR3piyiQKeezRKDSbaxxE-K4BPLV4CZSA=.72fc2c2a-ff66-489b-9533-431495546d09@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com>
 <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com>
 <YhkDQaU0FTyyP_42JTmUxM5x97rwSAHQbVYPJxRv3cI=.d70127c6-4f45-48b4-8b6c-eebad4084a34@github.com>
 <fT_4bHAK3fI6N5eRE7LgQ7FMt6o9C3WgTpfEh0ZbDkE=.579c1c92-0173-4f85-b7ff-83cbdf05b630@github.com>
 <LyZhpoeP4NnTHa0mSzdcRfEdvrtb3nvJST8yCz62XDo=.327dd96c-ab3a-4251-a7bd-8a23b92b2731@github.com>
 <Zyz8nyCssvU32SJGYXRHwq6vbTUR1x5gBZmBnDYPC7Y=.97852347-7820-489c-a9b7-1d2448c5f4cc@github.com>
 <gxTmdXqWBbaR3piyiQKeezRKDSbaxxE-K4BPLV4CZSA=.72fc2c2a-ff66-489b-9533-431495546d09@github.com>
Message-ID: <4lnyqbSHVuZqZxcRlDSS8JHrZxsAZG2pEup7ISU5hJk=.7dfec314-499e-43f0-b181-0984cce11cf6@github.com>

On Thu, 12 Jun 2025 09:54:57 GMT, kabutz <duke at openjdk.org> wrote:

>>> About a month or so.
>> 
>> Perfect, thanks @viktorklang-ora. I've marked the other issues as closed - duplicates, and referenced this single umbrella PR.
>
>> Great work, @kabutz ? this is now ready to integrate.
> 
> What are the next steps for me to do ?

@kabutz This is now ready for integration. After you've commented with "/integrate", I'll sponsor the integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2966311125

From vklang at openjdk.org  Thu Jun 12 11:46:43 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 12 Jun 2025 11:46:43 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <gxTmdXqWBbaR3piyiQKeezRKDSbaxxE-K4BPLV4CZSA=.72fc2c2a-ff66-489b-9533-431495546d09@github.com>
References: <VZ72kug1mDC8YcakCCrfHDB6aq1A-HXWlwaUYj6TrR4=.392fcac2-6709-46a8-817a-54c5ca1bca3b@github.com>
 <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com>
 <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com>
 <YhkDQaU0FTyyP_42JTmUxM5x97rwSAHQbVYPJxRv3cI=.d70127c6-4f45-48b4-8b6c-eebad4084a34@github.com>
 <fT_4bHAK3fI6N5eRE7LgQ7FMt6o9C3WgTpfEh0ZbDkE=.579c1c92-0173-4f85-b7ff-83cbdf05b630@github.com>
 <LyZhpoeP4NnTHa0mSzdcRfEdvrtb3nvJST8yCz62XDo=.327dd96c-ab3a-4251-a7bd-8a23b92b2731@github.com>
 <Zyz8nyCssvU32SJGYXRHwq6vbTUR1x5gBZmBnDYPC7Y=.97852347-7820-489c-a9b7-1d2448c5f4cc@github.com>
 <gxTmdXqWBbaR3piyiQKeezRKDSbaxxE-K4BPLV4CZSA=.72fc2c2a-ff66-489b-9533-431495546d09@github.com>
Message-ID: <KVWpv-_evTcE-BQAxfEPX4CpYOEpitaGaS4RQHJ3fcY=.8e98e5c1-7589-4dd7-8ba7-69325231e039@github.com>

On Thu, 12 Jun 2025 09:54:57 GMT, kabutz <duke at openjdk.org> wrote:

>>> About a month or so.
>> 
>> Perfect, thanks @viktorklang-ora. I've marked the other issues as closed - duplicates, and referenced this single umbrella PR.
>
>> Great work, @kabutz ? this is now ready to integrate.
> 
> What are the next steps for me to do ?

Thanks @kabutz!

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

PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2966341310

From duke at openjdk.org  Thu Jun 12 11:46:44 2025
From: duke at openjdk.org (kabutz)
Date: Thu, 12 Jun 2025 11:46:44 GMT
Subject: Integrated: 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: <meJjWUwrup3rVR8LE3AtTIv-twIqLcqh8BCXqEC5pV8=.cd85ee19-55d2-4f82-927b-9b4caef769a0@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...

This pull request has now been integrated.

Changeset: 91fdd72c
Author:    kabutz <heinz at javaspecialists.eu>
Committer: Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/91fdd72c97ab109c08893e5b613cbe4412b645aa
Stats:     154 lines in 2 files changed: 126 ins; 12 del; 16 mod

8355726: LinkedBlockingDeque fixes and improvements

Reviewed-by: vklang, dl

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

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

From jpai at openjdk.org  Thu Jun 12 15:13:32 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Jun 2025 15:13:32 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v2]
In-Reply-To: <XyQDGxDBfdASO7mHAj8BqpHxPESugXyRwf6y_5S2aVs=.d6f45bb5-98f6-4996-a4b1-a8f6049bf7f1@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <XyQDGxDBfdASO7mHAj8BqpHxPESugXyRwf6y_5S2aVs=.d6f45bb5-98f6-4996-a4b1-a8f6049bf7f1@github.com>
Message-ID: <Ba91teJ0I8Qdu_RWXrSWhfa1b3wGzzwQ5J56MF-dG7U=.b201efe0-6943-495a-b4cd-4ad0a587146e@github.com>

On Wed, 11 Jun 2025 22:40:43 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
>> 
>> `testclasses.jar` is updated such that the two classes no longer extend Applet.
>> 
>> 
>> $ javap fo\ o.class 
>> public class fo o {
>> }
>> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
>> public class ?? {
>> }
>> 
>> 
>> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
>> 
>> Additionally, the security APIs that were marked for removal are also removed from this test as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Jai's review - dynamically create jar file

test/jdk/jdk/internal/loader/URLClassPath/ClassnameCharTest.java line 31:

> 29:  * @modules java.base/sun.net.www
> 30:  *          jdk.httpserver
> 31:  * @compile -XDignore.symbol.file=true ClassnameCharTest.java

Hello Justin, this is pre-existing but since we are updating this test, I think it better to remove this `@compile` line altogether. It isn't needed for this test.

test/jdk/jdk/internal/loader/URLClassPath/ClassnameCharTest.java line 138:

> 136:                 }
> 137:             } catch (Exception _) {}
> 138:             throw new ClassNotFoundException(name);

I think we should propagate the underlying cause too, to help debugging if it fails for whatever reason. So something like:


catch (Exception e) {
   throw new ClassNotFoundException(name, e);
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25703#discussion_r2143020492
PR Review Comment: https://git.openjdk.org/jdk/pull/25703#discussion_r2143023616

From jpai at openjdk.org  Thu Jun 12 15:18:32 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Jun 2025 15:18:32 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v2]
In-Reply-To: <XyQDGxDBfdASO7mHAj8BqpHxPESugXyRwf6y_5S2aVs=.d6f45bb5-98f6-4996-a4b1-a8f6049bf7f1@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <XyQDGxDBfdASO7mHAj8BqpHxPESugXyRwf6y_5S2aVs=.d6f45bb5-98f6-4996-a4b1-a8f6049bf7f1@github.com>
Message-ID: <EvDAtaDRhUr0kngfbX-w24lK93vDZF84mWP6hoxhM3c=.d235f644-cffd-4681-9066-93ffbac9128b@github.com>

On Wed, 11 Jun 2025 22:40:43 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
>> 
>> `testclasses.jar` is updated such that the two classes no longer extend Applet.
>> 
>> 
>> $ javap fo\ o.class 
>> public class fo o {
>> }
>> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
>> public class ?? {
>> }
>> 
>> 
>> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
>> 
>> Additionally, the security APIs that were marked for removal are also removed from this test as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Jai's review - dynamically create jar file

test/jdk/jdk/internal/loader/URLClassPath/ClassnameCharTest.java line 46:

> 44: 
> 45: public class ClassnameCharTest {
> 46:     private static final String JAR_PATH = Utils.TEST_CLASSES + Utils.FILE_SEPARATOR + "testclasses.jar";

I think it would be better to use `java.nio.file.Path` which is like:


private static final Path JAR_PATH = Path.of(".").resolve("testclasses.jar");

That way we don't have to reference the `Utils.TEST_CLASSES`. `Path.of(".")` will end up being the scratch directory of the test so jtreg can then retain this JAR file if the test fails for any reason.

test/jdk/jdk/internal/loader/URLClassPath/ClassnameCharTest.java line 47:

> 45: public class ClassnameCharTest {
> 46:     private static final String JAR_PATH = Utils.TEST_CLASSES + Utils.FILE_SEPARATOR + "testclasses.jar";
> 47:     static File classesJar = new File(JAR_PATH);

If we switch to using `Path` for `JAR_PATH`, like I suggest above, then we can get rid of this field altogether and at the call site, we can just to `JAR_PATH.toFile()` if we want to have a `File` instance corresponding to that `Path`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25703#discussion_r2143030617
PR Review Comment: https://git.openjdk.org/jdk/pull/25703#discussion_r2143032390

From duke at openjdk.org  Thu Jun 12 15:25:19 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 12 Jun 2025 15:25:19 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v4]
In-Reply-To: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
Message-ID: <SzEeK541fLr6annFGlSdPYm1XMcAzEL1alLFc3QITdw=.58384a94-f3da-4491-aa96-b2adab34b871@github.com>

> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
> 
> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
> 
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  fix overflow check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25644/files
  - new: https://git.openjdk.org/jdk/pull/25644/files/6953dcfc..6a072873

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

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

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

From duke at openjdk.org  Thu Jun 12 15:29:33 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 12 Jun 2025 15:29:33 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v3]
In-Reply-To: <JNEKtkhrEYnS1SvaSz7GhcS4FQGkQXma4nY_Wo0T18A=.3dce72d9-7250-4672-adad-13db79e3150c@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <-6TYWikmLNBtyQt6_xeJ8KoziHxA8Ijr067NIc740X0=.2f9e4cae-7f39-46b8-b3a9-f381fb2e0518@github.com>
 <JNEKtkhrEYnS1SvaSz7GhcS4FQGkQXma4nY_Wo0T18A=.3dce72d9-7250-4672-adad-13db79e3150c@github.com>
Message-ID: <tCE4NXNXnwQro2lXxzJbDuJzrcTt3k2bNrR8wk54jX8=.6a749f99-e70b-426b-ad9d-e077c115f42d@github.com>

On Wed, 11 Jun 2025 23:47:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1841:
> 
>> 1839: 
>> 1840:     static ASCIIToBinaryConverter readDoubleSignlessDigits(int decExp, char[] digits, int length) {
>> 1841:         if (decExp < MIN_DECIMAL_EXPONENT) {
> 
> Is this check needed? I think `ASCIIToBinaryConverter` will return the proper zero value when `doubleValue()` is invoked. 
> 
> 
>   if (decExponent < MIN_DECIMAL_EXPONENT - 1) {
>       return (isNegative) ? -0.0 : 0.0;
> 
> 
> And if this explicit check is a shortcut, I don't think we would need one for an edge case.

Unfortunately some check is required (a test fails), but I now realize what I had was wrong. The issue is that on line 1084 (https://github.com/openjdk/jdk/pull/25644/files#diff-79e6fd549b5ec5e7f49658581beddcb07fcbb0c09ae8e1117c385b66514da6d2R1084)) exp can overflow and become positive again. I've updated the check to avoid the overflow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2143060934

From jpai at openjdk.org  Thu Jun 12 15:32:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Jun 2025 15:32:28 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v2]
In-Reply-To: <XyQDGxDBfdASO7mHAj8BqpHxPESugXyRwf6y_5S2aVs=.d6f45bb5-98f6-4996-a4b1-a8f6049bf7f1@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <XyQDGxDBfdASO7mHAj8BqpHxPESugXyRwf6y_5S2aVs=.d6f45bb5-98f6-4996-a4b1-a8f6049bf7f1@github.com>
Message-ID: <qhj93MMGIJdu0VHsiSarvBUWRPD-wXwVKpQQdMRj0HQ=.fe204c78-69f4-4fc7-a789-3f0c4d9289e2@github.com>

On Wed, 11 Jun 2025 22:40:43 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
>> 
>> `testclasses.jar` is updated such that the two classes no longer extend Applet.
>> 
>> 
>> $ javap fo\ o.class 
>> public class fo o {
>> }
>> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
>> public class ?? {
>> }
>> 
>> 
>> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
>> 
>> Additionally, the security APIs that were marked for removal are also removed from this test as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Jai's review - dynamically create jar file

Thank you Justin for these changes. Overall I believe these are the correct changes to do. I have some review suggestions which I've added inline.

I went back and looked at the JDK-5017871 issue through which the `fo o.class` was being tested and from what I see in there, the current test changes continue to test that issue. I think there might be better ways to test that original use case and this test could be simplified a lot, but it's certainly not for this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25703#issuecomment-2967307795

From jlu at openjdk.org  Thu Jun 12 16:36:11 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 12 Jun 2025 16:36:11 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v3]
In-Reply-To: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
Message-ID: <XGDqSjUi0sjWu5B9MxPJgiT55HSqjrL7gCSAbWwO6Oo=.de4788b9-f1ca-412c-9fc9-455ae783591d@github.com>

> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
> 
> `testclasses.jar` is updated such that the two classes no longer extend Applet.
> 
> 
> $ javap fo\ o.class 
> public class fo o {
> }
> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
> public class ?? {
> }
> 
> 
> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
> 
> Additionally, the security APIs that were marked for removal are also removed from this test as well.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - removing a typo
 - Jai's review - Cleanup & JAR_PATH String -> Path

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25703/files
  - new: https://git.openjdk.org/jdk/pull/25703/files/ab8785cc..a9cad716

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

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

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

From jlu at openjdk.org  Thu Jun 12 16:36:11 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 12 Jun 2025 16:36:11 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v2]
In-Reply-To: <EvDAtaDRhUr0kngfbX-w24lK93vDZF84mWP6hoxhM3c=.d235f644-cffd-4681-9066-93ffbac9128b@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <XyQDGxDBfdASO7mHAj8BqpHxPESugXyRwf6y_5S2aVs=.d6f45bb5-98f6-4996-a4b1-a8f6049bf7f1@github.com>
 <EvDAtaDRhUr0kngfbX-w24lK93vDZF84mWP6hoxhM3c=.d235f644-cffd-4681-9066-93ffbac9128b@github.com>
Message-ID: <O_wXfh_mKP95zg_D6ZV_tL62z-lg1bNEDdr-lzMJM5g=.6975b708-b85b-4726-a1f1-43211eb279a7@github.com>

On Thu, 12 Jun 2025 15:14:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Jai's review - dynamically create jar file
>
> test/jdk/jdk/internal/loader/URLClassPath/ClassnameCharTest.java line 46:
> 
>> 44: 
>> 45: public class ClassnameCharTest {
>> 46:     private static final String JAR_PATH = Utils.TEST_CLASSES + Utils.FILE_SEPARATOR + "testclasses.jar";
> 
> I think it would be better to use `java.nio.file.Path` which is like:
> 
> 
> private static final Path JAR_PATH = Path.of(".").resolve("testclasses.jar");
> 
> That way we don't have to reference the `Utils.TEST_CLASSES`. `Path.of(".")` will end up being the scratch directory of the test so jtreg can then retain this JAR file if the test fails for any reason.

Thanks, this is cleaner.

> test/jdk/jdk/internal/loader/URLClassPath/ClassnameCharTest.java line 138:
> 
>> 136:                 }
>> 137:             } catch (Exception _) {}
>> 138:             throw new ClassNotFoundException(name);
> 
> I think we should propagate the underlying cause too, to help debugging if it fails for whatever reason. So something like:
> 
> 
> catch (Exception e) {
>    throw new ClassNotFoundException(name, e);
> }

Good point, also gave the other exception a more helpful message as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25703#discussion_r2143188388
PR Review Comment: https://git.openjdk.org/jdk/pull/25703#discussion_r2143188431

From jlu at openjdk.org  Thu Jun 12 18:05:04 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 12 Jun 2025 18:05:04 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v4]
In-Reply-To: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
Message-ID: <5V1P4tJxU2e5kFf4sP5gIzjE_9ZQTXCmvZb7vrz9LjU=.c9b93f89-68d3-4baf-a7b5-d9a008b0bb11@github.com>

> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
> 
> `testclasses.jar` is updated such that the two classes no longer extend Applet.
> 
> 
> $ javap fo\ o.class 
> public class fo o {
> }
> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
> public class ?? {
> }
> 
> 
> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
> 
> Additionally, the security APIs that were marked for removal are also removed from this test as well.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Address offline review -> comments for maintainers, simplify exc and JAR_PATH

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25703/files
  - new: https://git.openjdk.org/jdk/pull/25703/files/a9cad716..47f62aa2

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

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

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

From naoto at openjdk.org  Thu Jun 12 18:07:38 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 12 Jun 2025 18:07:38 GMT
Subject: RFR: 8358819: The first year is not displayed correctly in
 Japanese Calendar
In-Reply-To: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
References: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
Message-ID: <f34iT2pVfpsoPi1sXUCKeftzTmxdiozeUrrPkK022SE=.40082631-d24b-481e-84ac-495f123b8dd8@github.com>

On Tue, 10 Jun 2025 18:36:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This regression was introduced by the removal of the COMPAT locale provider, which partially broke support for the first year in the Japanese calendar. In the Japanese calendar system, the first year of an era should be formatted using the character "?" rather than the numeral "1". The issue arises from a difference in how pattern character lengths are interpreted between CLDR and SimpleDateFormat. The existing `JapaneseEraNameTest` has been updated to cover this fix.

Thanks for the reviews!

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25732#issuecomment-2967394556
PR Comment: https://git.openjdk.org/jdk/pull/25732#issuecomment-2967755497

From naoto at openjdk.org  Thu Jun 12 18:07:39 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 12 Jun 2025 18:07:39 GMT
Subject: Integrated: 8358819: The first year is not displayed correctly in
 Japanese Calendar
In-Reply-To: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
References: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
Message-ID: <vi_9s0lZdEAWy12_AOWN6UwJD9V-S7VIT7zXDfAOVro=.b076c698-9160-4839-b177-6be00ad3daee@github.com>

On Tue, 10 Jun 2025 18:36:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This regression was introduced by the removal of the COMPAT locale provider, which partially broke support for the first year in the Japanese calendar. In the Japanese calendar system, the first year of an era should be formatted using the character "?" rather than the numeral "1". The issue arises from a difference in how pattern character lengths are interpreted between CLDR and SimpleDateFormat. The existing `JapaneseEraNameTest` has been updated to cover this fix.

This pull request has now been integrated.

Changeset: 99829950
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/99829950f680936489048a1ad4ce12f166805e4d
Stats:     197 lines in 3 files changed: 120 ins; 66 del; 11 mod

8358819: The first year is not displayed correctly in Japanese Calendar

Reviewed-by: jlu, joehw, iris

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

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

From dfuchs at openjdk.org  Thu Jun 12 18:53:18 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Jun 2025 18:53:18 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v8]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <bttVrklfkEVMhRXGDs3ombxBWKJXkX3PFG9dg1qJyJo=.99d3a625-d679-43d7-9f2b-25ce105f521c@github.com>

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

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

 - merge latest changes from master branch
 - http3: update H3InsertionsLimitTest to start after receival of client settings
 - merge latest changes from master branch
 - quic: separate out the idle termination timer and the STREAM_DATA_BLOCKED timer
 - quic: simplify idle timeout management
 - http3: rely on the sole isOpen() method instead of isOpen() and isClosed()
 - quic: do not let h3 idle (in pool) timeout to influence the quic transport idle timeout
 - merge latest changes from master branch
 - http3: improve H3ConnectionPoolTest.java
 - Fix snippet
 - ... and 496 more: https://git.openjdk.org/jdk/compare/8d33ea73...d4984d5e

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=07
  Stats: 103752 lines in 472 files changed: 100891 ins; 1345 del; 1516 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

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

From naoto at openjdk.org  Thu Jun 12 20:08:31 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 12 Jun 2025 20:08:31 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v6]
In-Reply-To: <7XLzfBmB2raJzcZP4NtaaWxQX2gYDrdd8Z1FzhTRmTg=.cfe1fb59-e062-45c4-9410-f5164c2cf479@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <7XLzfBmB2raJzcZP4NtaaWxQX2gYDrdd8Z1FzhTRmTg=.cfe1fb59-e062-45c4-9410-f5164c2cf479@github.com>
Message-ID: <Z13w_jQPyUsasMyTRcXDJDwdlCNZImVLdJz9xUjY_rg=.5b78eb62-0344-4ebf-9c34-98e4b471dea7@github.com>

On Wed, 11 Jun 2025 10:43:47 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert superfluous test changes

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25544#pullrequestreview-2922513387

From bpb at openjdk.org  Thu Jun 12 21:17:40 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Jun 2025 21:17:40 GMT
Subject: RFR: 8191963: Path.equals() and File.equals() return true for two
 different files on Windows
Message-ID: <SajkurwYpwnPA2of1eJk47j813Xm7otCmkk5fDXrKGs=.ca848b55-4134-48fa-9d24-11e81d1871c2@github.com>

Replace logic in `java.io.WinNTFileSystems.compare(File,File)` with that from `sun.nio.fs.WindowsPath.compareTo(Path)`.

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

Commit messages:
 - 8191963: Path.equals() and File.equals() return true for two different files on Windows

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

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

From jlu at openjdk.org  Thu Jun 12 22:54:32 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 12 Jun 2025 22:54:32 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v3]
In-Reply-To: <tCE4NXNXnwQro2lXxzJbDuJzrcTt3k2bNrR8wk54jX8=.6a749f99-e70b-426b-ad9d-e077c115f42d@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <-6TYWikmLNBtyQt6_xeJ8KoziHxA8Ijr067NIc740X0=.2f9e4cae-7f39-46b8-b3a9-f381fb2e0518@github.com>
 <JNEKtkhrEYnS1SvaSz7GhcS4FQGkQXma4nY_Wo0T18A=.3dce72d9-7250-4672-adad-13db79e3150c@github.com>
 <tCE4NXNXnwQro2lXxzJbDuJzrcTt3k2bNrR8wk54jX8=.6a749f99-e70b-426b-ad9d-e077c115f42d@github.com>
Message-ID: <Tv8HMWAw2YxNwcjL3_8ZoELHZZHCI-RSeMNbN-NBU5g=.dac7959c-1d74-47c3-a283-fe212dcd3705@github.com>

On Thu, 12 Jun 2025 15:26:55 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1841:
>> 
>>> 1839: 
>>> 1840:     static ASCIIToBinaryConverter readDoubleSignlessDigits(int decExp, char[] digits, int length) {
>>> 1841:         if (decExp < MIN_DECIMAL_EXPONENT) {
>> 
>> Is this check needed? I think `ASCIIToBinaryConverter` will return the proper zero value when `doubleValue()` is invoked. 
>> 
>> 
>>   if (decExponent < MIN_DECIMAL_EXPONENT - 1) {
>>       return (isNegative) ? -0.0 : 0.0;
>> 
>> 
>> And if this explicit check is a shortcut, I don't think we would need one for an edge case.
>
> Unfortunately some check is required (a test fails), but I now realize what I had was wrong. The issue is that on line 1084 (https://github.com/openjdk/jdk/pull/25644/files#diff-79e6fd549b5ec5e7f49658581beddcb07fcbb0c09ae8e1117c385b66514da6d2R1084)) exp can overflow and become positive again. I've updated the check to avoid the overflow.

Ah got it, I see your point. We would have goten underflow in `ASCIIToBinaryConverter.doubleValue()` for some extreme cases without a check. 

Is there a specific example you have that requires the switch to the newer check? Adding a comment along those lines might be helpful. Actually, I thought DigitList caps `decimalAt` to Integer.MIN/MAX, so then the first check you had would have been fine. (Maybe I am missing something?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2143781479

From smarks at openjdk.org  Thu Jun 12 23:23:46 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 12 Jun 2025 23:23:46 GMT
Subject: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty
 pointing to newer APIs [v3]
In-Reply-To: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
References: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
Message-ID: <4MflY-E32YtWt-ROFpp33vlXYKXPBj6UbKkA0KsSg5E=.d6738105-fd00-4693-980e-db6e53163b21@github.com>

> Add a note to String.trim pointing to the String.strip family of methods.
> 
> Add notes cross-linking String.isBlank and String.isEmpty.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Update wording per suggestion.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25762/files
  - new: https://git.openjdk.org/jdk/pull/25762/files/96c15c33..2aa43d12

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25762.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25762/head:pull/25762

PR: https://git.openjdk.org/jdk/pull/25762

From smarks at openjdk.org  Thu Jun 12 23:23:46 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 12 Jun 2025 23:23:46 GMT
Subject: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty
 pointing to newer APIs [v3]
In-Reply-To: <zNf4IR9I87TVLLlbQ0HvmPD6bc3LQ0PWxsIz58uA0yw=.016cef8b-45f1-476d-8bcc-eadbd14d3f37@github.com>
References: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
 <8RLyq6RUkKSV14yisVjqP13fGIzZUKhotSRQAaeVmgc=.f15f1ae5-c20a-429a-a2f4-2994943a76a1@github.com>
 <fVv_kpXk24tTzRzQM2jAAenJkx4t9oDi-SHkmd6UnIY=.cdf165c4-8def-448b-9e21-3cc5e937fa8c@github.com>
 <SL0JKOABu7PRL2JEQwPp6M6vTl5A8yDMls9_5wRl4As=.c8982000-ebde-487f-acd6-4b27d67a2110@github.com>
 <zNf4IR9I87TVLLlbQ0HvmPD6bc3LQ0PWxsIz58uA0yw=.016cef8b-45f1-476d-8bcc-eadbd14d3f37@github.com>
Message-ID: <Bxpl1xbrxolnirYXcXXNxydT1t1Y56gpqU8TOuF1bq0=.88d524e4-2cea-4030-b324-cc01887039b6@github.com>

On Thu, 12 Jun 2025 01:54:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Oh yeah, that should be "an ASCII...."
>> 
>> But maybe we should change the wording per @naotoj's comment. I don't want to repeat the specification above, but rather I want to describe it in terms of what the thinking was at the time it was introduced in JDK 1.0. For comparison, in JDK 1.0, the way to create a String from bytes was to fill in the upper 8 bits of a char using a constant "hibyte" parameter of the String(byte[], int) constructor, which is now deprecated. So this was very much an ASCII-centric view of the world.
>> 
>> The trim() method first appeared in 1.0 but its original specification mentioned white space without defining it. The 1.1 specification gained some details, saying
>> 
>>> Removes white space from both ends of this string.
>>>
>>> All characters that have codes less than or equal to '\u0020' (the space character) are considered to be white space. 
>> 
>> From the 1996 or 1997 view of the world, I'd describe this as "space plus ASCII control characters." Would something like that make more sense?
>
>> I'd describe this as "space plus ASCII control characters." Would something like that make more sense?
> 
> Yeah, I think so

OK, I've updated the wording. Let me know if this is OK and I'll update the CSR accordingly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25762#discussion_r2143809703

From smarks at openjdk.org  Thu Jun 12 23:39:44 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 12 Jun 2025 23:39:44 GMT
Subject: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty
 pointing to newer APIs [v4]
In-Reply-To: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
References: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
Message-ID: <G7_CxNre9z6bDO7dtMkCHN9zWxmrseIprz3RQMfUDv0=.fd318eef-3654-4f86-b904-6eb4b1b6376c@github.com>

> Add a note to String.trim pointing to the String.strip family of methods.
> 
> Add notes cross-linking String.isBlank and String.isEmpty.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  More wording updates.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25762/files
  - new: https://git.openjdk.org/jdk/pull/25762/files/2aa43d12..fd3967a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25762&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25762&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25762.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25762/head:pull/25762

PR: https://git.openjdk.org/jdk/pull/25762

From smarks at openjdk.org  Thu Jun 12 23:39:44 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 12 Jun 2025 23:39:44 GMT
Subject: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty
 pointing to newer APIs [v4]
In-Reply-To: <Bxpl1xbrxolnirYXcXXNxydT1t1Y56gpqU8TOuF1bq0=.88d524e4-2cea-4030-b324-cc01887039b6@github.com>
References: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
 <8RLyq6RUkKSV14yisVjqP13fGIzZUKhotSRQAaeVmgc=.f15f1ae5-c20a-429a-a2f4-2994943a76a1@github.com>
 <fVv_kpXk24tTzRzQM2jAAenJkx4t9oDi-SHkmd6UnIY=.cdf165c4-8def-448b-9e21-3cc5e937fa8c@github.com>
 <SL0JKOABu7PRL2JEQwPp6M6vTl5A8yDMls9_5wRl4As=.c8982000-ebde-487f-acd6-4b27d67a2110@github.com>
 <zNf4IR9I87TVLLlbQ0HvmPD6bc3LQ0PWxsIz58uA0yw=.016cef8b-45f1-476d-8bcc-eadbd14d3f37@github.com>
 <Bxpl1xbrxolnirYXcXXNxydT1t1Y56gpqU8TOuF1bq0=.88d524e4-2cea-4030-b324-cc01887039b6@github.com>
Message-ID: <n0TohkR8D8LiMffM_1EXsmIvRxAlL_WjTbAES0SXij4=.ae5835b8-5466-40ee-99ca-ff537bc8e4ef@github.com>

On Thu, 12 Jun 2025 23:21:15 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>>> I'd describe this as "space plus ASCII control characters." Would something like that make more sense?
>> 
>> Yeah, I think so
>
> OK, I've updated the wording. Let me know if this is OK and I'll update the CSR accordingly.

Made additional updates.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25762#discussion_r2143825798

From naoto at openjdk.org  Fri Jun 13 00:32:28 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 13 Jun 2025 00:32:28 GMT
Subject: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty
 pointing to newer APIs [v4]
In-Reply-To: <G7_CxNre9z6bDO7dtMkCHN9zWxmrseIprz3RQMfUDv0=.fd318eef-3654-4f86-b904-6eb4b1b6376c@github.com>
References: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
 <G7_CxNre9z6bDO7dtMkCHN9zWxmrseIprz3RQMfUDv0=.fd318eef-3654-4f86-b904-6eb4b1b6376c@github.com>
Message-ID: <d_TsH2DIPilqohjMfBRIdIpBjuq5eVZ7CTUINVnBMaM=.01c30f38-3272-457c-ad1c-50303d68f601@github.com>

On Thu, 12 Jun 2025 23:39:44 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Add a note to String.trim pointing to the String.strip family of methods.
>> 
>> Add notes cross-linking String.isBlank and String.isEmpty.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More wording updates.

Looks fine to me. Thanks for the changes!

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25762#pullrequestreview-2923057295

From bpb at openjdk.org  Fri Jun 13 00:32:29 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Jun 2025 00:32:29 GMT
Subject: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty
 pointing to newer APIs [v4]
In-Reply-To: <G7_CxNre9z6bDO7dtMkCHN9zWxmrseIprz3RQMfUDv0=.fd318eef-3654-4f86-b904-6eb4b1b6376c@github.com>
References: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
 <G7_CxNre9z6bDO7dtMkCHN9zWxmrseIprz3RQMfUDv0=.fd318eef-3654-4f86-b904-6eb4b1b6376c@github.com>
Message-ID: <u5mkD7Wg8v4dxaqTaVydGR4NKKIG0UZFyXIC3n8COD8=.d2310fdf-4fc5-4297-82fc-57b0b046a384@github.com>

On Thu, 12 Jun 2025 23:39:44 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Add a note to String.trim pointing to the String.strip family of methods.
>> 
>> Add notes cross-linking String.isBlank and String.isEmpty.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More wording updates.

Looks fine to me, as well.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25762#pullrequestreview-2923064187

From smarks at openjdk.org  Fri Jun 13 04:31:28 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 13 Jun 2025 04:31:28 GMT
Subject: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty
 pointing to newer APIs [v4]
In-Reply-To: <G7_CxNre9z6bDO7dtMkCHN9zWxmrseIprz3RQMfUDv0=.fd318eef-3654-4f86-b904-6eb4b1b6376c@github.com>
References: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
 <G7_CxNre9z6bDO7dtMkCHN9zWxmrseIprz3RQMfUDv0=.fd318eef-3654-4f86-b904-6eb4b1b6376c@github.com>
Message-ID: <ZIpPuntBeJ0MyoQydvUidsBn4G5zdjHF_KrZDahhdPE=.9f0efc6e-26cc-4035-b50e-bd7d368f42cf@github.com>

On Thu, 12 Jun 2025 23:39:44 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Add a note to String.trim pointing to the String.strip family of methods.
>> 
>> Add notes cross-linking String.isBlank and String.isEmpty.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More wording updates.

Thanks. CSR [JDK-8359267](https://bugs.openjdk.org/browse/JDK-8359267) is now updated. Please review at your convenience.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25762#issuecomment-2968991523

From jpai at openjdk.org  Fri Jun 13 06:05:34 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Jun 2025 06:05:34 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v4]
In-Reply-To: <5V1P4tJxU2e5kFf4sP5gIzjE_9ZQTXCmvZb7vrz9LjU=.c9b93f89-68d3-4baf-a7b5-d9a008b0bb11@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <5V1P4tJxU2e5kFf4sP5gIzjE_9ZQTXCmvZb7vrz9LjU=.c9b93f89-68d3-4baf-a7b5-d9a008b0bb11@github.com>
Message-ID: <S5nqEX2ETnP_phQmccpJr-audF4k7k3If-J47Z8clCs=.bf93aa64-50de-400d-89c9-41e381b48d31@github.com>

On Thu, 12 Jun 2025 18:05:04 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
>> 
>> `testclasses.jar` is updated such that the two classes no longer extend Applet.
>> 
>> 
>> $ javap fo\ o.class 
>> public class fo o {
>> }
>> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
>> public class ?? {
>> }
>> 
>> 
>> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
>> 
>> Additionally, the security APIs that were marked for removal are also removed from this test as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address offline review -> comments for maintainers, simplify exc and JAR_PATH

Hello Justin, the changes look OK to me. Please wait for a Lance to take a look too.

test/jdk/jdk/internal/loader/URLClassPath/ClassnameCharTest.java line 136:

> 134:                     return defineClass(name, b, 0, b.length, codesource);
> 135:                 }
> 136:                 // protocol/host/port mismatch, fail with RuntimeExc

Looks like a typo - should have been `RuntimeException`?

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25703#pullrequestreview-2923510090
PR Review Comment: https://git.openjdk.org/jdk/pull/25703#discussion_r2144266894

From stuefe at openjdk.org  Fri Jun 13 06:40:29 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 13 Jun 2025 06:40:29 GMT
Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(),
 use FD_CLOEXEC instead of close() [v4]
In-Reply-To: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
References: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
Message-ID: <vtw1acKMe69fcntcaQ_PYt6_AneS7YfiF18KfN9KAPg=.aa646f10-08d3-421e-933c-5c80906613c5@github.com>

> Hi, please consider the following patch.
> 
> This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc.
> 
> This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens).
> 
> Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409
> 
> This patch also fixes two subtle bugs:
> - we didn't check the return value of the close() inside closeAllFileDescriptors
> - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it)
> 
> ----
> 
> Testing:
> 
> We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC.
> 
> - in the parent JVM, the test opens a file in native code without FD_CLOEXEC
> - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open
> 
> I verified that the test correctly detects a broken implementation that leaks file descriptors. 
> 
> I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX).
> 
> I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green.

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close-
 - Merge branch 'openjdk:master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close-
 - Merge branch 'openjdk:master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close-
 - close dir fd on fcntl error
 - Mark fds with cloexec, plus test

-------------

Changes: https://git.openjdk.org/jdk/pull/25301/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25301&range=03
  Stats: 204 lines in 5 files changed: 181 ins; 9 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25301/head:pull/25301

PR: https://git.openjdk.org/jdk/pull/25301

From vyazici at openjdk.org  Fri Jun 13 08:15:44 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 13 Jun 2025 08:15:44 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v7]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <8Cr08eX4jZi0YBrIUAWJqV8q3xZxdSCvm7t6_4ch-Jw=.299b1af4-e363-4669-9f3c-8f37d27bc068@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge remote-tracking branch 'upstream/master' into stdinEnc-core
 - Revert superfluous test changes
 - Improve code style
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Fix missing `java.io.Reader` import in `Ktab`
 - Clean-up `MultiBreakpointsTarg`
 - Provide fallback for `stdin.encoding`
 - Revert changes to `Application` and `JavaChild`
   
   There stdin is connected to the parent process rather than the console.
 - Revert more superfluous changes
 - Fix code typo
 - Discard changes unrelated with core libraries
 - ... and 4 more: https://git.openjdk.org/jdk/compare/9aeacf2d...d36e0bd5

-------------

Changes: https://git.openjdk.org/jdk/pull/25544/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25544&range=06
  Stats: 130 lines in 11 files changed: 33 ins; 28 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/25544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25544/head:pull/25544

PR: https://git.openjdk.org/jdk/pull/25544

From sundar at openjdk.org  Fri Jun 13 08:55:29 2025
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 13 Jun 2025 08:55:29 GMT
Subject: RFR: 8359225: Remove unused test/jdk/javax/script/MyContext.java
In-Reply-To: <9g63ztmitzJUv3-Jg6vg5lUqlGsbuK4gp600G6auqaE=.5701becc-7bfc-4ece-8cf0-1833b9bd5d5a@github.com>
References: <9g63ztmitzJUv3-Jg6vg5lUqlGsbuK4gp600G6auqaE=.5701becc-7bfc-4ece-8cf0-1833b9bd5d5a@github.com>
Message-ID: <1psf5V5F6r8iT6daKOkS_d4InVDWnw7zITOKv0wi8AQ=.3cd29fd9-0896-4247-b637-61823d29a1b3@github.com>

On Wed, 11 Jun 2025 11:22:57 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Both `javax/script/PluggableContextTest.java` and its companion `test/jdk/javax/script/MyContext.java` were added in [JDK-6398614](https://bugs.openjdk.org/browse/JDK-6398614). [JDK-8246113](https://bugs.openjdk.org/browse/JDK-8246113) removed `PluggableContextTest`, yet forgot `MyContext`, and rendered it redundant. Remove `MyContext` too.

LGTM

-------------

Marked as reviewed by sundar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25748#pullrequestreview-2923915788

From vyazici at openjdk.org  Fri Jun 13 09:14:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 13 Jun 2025 09:14:34 GMT
Subject: RFR: 8359225: Remove unused test/jdk/javax/script/MyContext.java
In-Reply-To: <1psf5V5F6r8iT6daKOkS_d4InVDWnw7zITOKv0wi8AQ=.3cd29fd9-0896-4247-b637-61823d29a1b3@github.com>
References: <9g63ztmitzJUv3-Jg6vg5lUqlGsbuK4gp600G6auqaE=.5701becc-7bfc-4ece-8cf0-1833b9bd5d5a@github.com>
 <1psf5V5F6r8iT6daKOkS_d4InVDWnw7zITOKv0wi8AQ=.3cd29fd9-0896-4247-b637-61823d29a1b3@github.com>
Message-ID: <JpRkWciNj2MaLvJuP0ky5JjSNVC4YAgda2cfkf2diXo=.a3b95313-6f6d-4d9c-a034-46f13a4e9cdf@github.com>

On Fri, 13 Jun 2025 08:52:37 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> Both `javax/script/PluggableContextTest.java` and its companion `test/jdk/javax/script/MyContext.java` were added in [JDK-6398614](https://bugs.openjdk.org/browse/JDK-6398614). [JDK-8246113](https://bugs.openjdk.org/browse/JDK-8246113) removed `PluggableContextTest`, yet forgot `MyContext`, and rendered it redundant. Remove `MyContext` too.
>
> LGTM

@sundararajana, thanks for the review.

For completeness, `tier1,2` results are attached to the ticket.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25748#issuecomment-2969655592

From vyazici at openjdk.org  Fri Jun 13 09:14:36 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 13 Jun 2025 09:14:36 GMT
Subject: Integrated: 8359225: Remove unused
 test/jdk/javax/script/MyContext.java
In-Reply-To: <9g63ztmitzJUv3-Jg6vg5lUqlGsbuK4gp600G6auqaE=.5701becc-7bfc-4ece-8cf0-1833b9bd5d5a@github.com>
References: <9g63ztmitzJUv3-Jg6vg5lUqlGsbuK4gp600G6auqaE=.5701becc-7bfc-4ece-8cf0-1833b9bd5d5a@github.com>
Message-ID: <_4D3oNzGeEEM84v7tkfEJLFGRHQyk97WBCE6-Hd5Foc=.be9afabe-7786-4d71-a70e-2234ca56596b@github.com>

On Wed, 11 Jun 2025 11:22:57 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Both `javax/script/PluggableContextTest.java` and its companion `test/jdk/javax/script/MyContext.java` were added in [JDK-6398614](https://bugs.openjdk.org/browse/JDK-6398614). [JDK-8246113](https://bugs.openjdk.org/browse/JDK-8246113) removed `PluggableContextTest`, yet forgot `MyContext`, and rendered it redundant. Remove `MyContext` too.

This pull request has now been integrated.

Changeset: 3a188726
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3a1887269b9cecf9dea68637f99b0b103baafbdb
Stats:     222 lines in 1 file changed: 0 ins; 222 del; 0 mod

8359225: Remove unused test/jdk/javax/script/MyContext.java

Reviewed-by: sundar

-------------

PR: https://git.openjdk.org/jdk/pull/25748

From swen at openjdk.org  Fri Jun 13 12:07:21 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 13 Jun 2025 12:07:21 GMT
Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString
In-Reply-To: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
References: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
Message-ID: <eDv7MzYtG4VitPO4u60P4AUyGdox2p6RYVANC1NxPoU=.5e1f091c-83e3-4d0b-957c-f77c8ccbcf33@github.com>

On Tue, 7 Jan 2025 10:39:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In PR #22928, UUID introduced long-based vectorized hexadecimal to string conversion, which can also be used in Integer::toHexString and Long::toHexString to eliminate table lookups. The benefit of eliminating table lookups is that the performance is better when cache misses occur.

The testing data from both aarch64 and x64 architectures indicates a performance improvement of 10% to 20%. However, under the MacBook M1 Pro environment, the performance enhancement for the Integer.toHexString scenario has reached 100%.

## 1. Script

git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

# baseline 91db7c0877a
git checkout 91db7c0877a68ad171da2b4501280fc24630ae83
make test TEST="micro:java.lang.Integers.toHexString"
make test TEST="micro:java.lang.Longs.toHexString"

 # current 1788d09787c
git checkout 1788d09787cadfe6ec23b9b10bef87a2cdc029a3
make test TEST="micro:java.lang.Integers.toHexString"
make test TEST="micro:java.lang.Longs.toHexString"


## 2. aliyun_ecs_c8a_x64 (CPU AMD EPYC? Genoa)

-Benchmark             (size)  Mode  Cnt  Score   Error  Units (baseline 91db7c0877a)
-Integers.toHexString     500  avgt   15  4.855 ? 0.058  us/op
-Longs.toHexString        500  avgt   15  6.098 ? 0.034  us/op


+Benchmark             (size)  Mode  Cnt  Score   Error  Units (current 1788d09787c)
+Integers.toHexString     500  avgt   15  4.105 ? 0.010  us/op +18.27%
+Longs.toHexString        500  avgt   15  4.682 ? 0.116  us/op +30.24%



## 3. aliyun_ecs_c8i_x64 (CPU Intel?Xeon?Emerald Rapids)

-Benchmark             (size)  Mode  Cnt  Score   Error  Units
-Integers.toHexString     500  avgt   15  5.158 ? 0.025  us/op
-Longs.toHexString        500  avgt   15  6.072 ? 0.020  us/op

+Benchmark             (size)  Mode  Cnt  Score   Error  Units
+Integers.toHexString     500  avgt   15  4.691 ? 0.024  us/op  +9.95%
+Longs.toHexString        500  avgt   15  4.947 ? 0.024  us/op +22.74%



## 4. aliyun_ecs_c8y_aarch64 (CPU Aliyun Yitian 710)

-Benchmark             (size)  Mode  Cnt  Score   Error  Units
-Integers.toHexString     500  avgt   15  5.880 ? 0.017  us/op
-Longs.toHexString        500  avgt   15  7.183 ? 0.013  us/op

+Benchmark             (size)  Mode  Cnt  Score   Error  Units
+Integers.toHexString     500  avgt   15  5.282 ? 0.012  us/op +11.32%
+Longs.toHexString        500  avgt   15  5.530 ? 0.013  us/op +29.89%




## 5. MacBook M1 Pro (aarch64)

-Benchmark             (size)  Mode  Cnt   Score   Error  Units (baseline 91db7c0877a)
-Integers.toHexString     500  avgt   15  10.519 ? 1.573  us/op
-Longs.toHexString        500  avgt   15  5.754 ? 0.264  us/op

+Benchmark             (size)  Mode  Cnt  Score   Error  Units (current 1788d09787c)
+Integers.toHexString     500  avgt   15  5.057 ? 0.015  us/op +108.00%
+Longs.toHexString        500  avgt   15  5.147 ? 0.095  us/op  +11.79%

Because this algorithm underperforms compared to the original version when handling smaller numbers, I have marked this PR as draft. 

Additionally, this algorithm is used in another PR #22928 [Speed ??up UUID::toString](https://github.com/openjdk/jdk/pull/22928) , and it still experiences performance degradation with Long.expand on older CPU architectures.


// Method 1:
i = Long.reverseBytes(Long.expand(i, 0x0F0F_0F0F_0F0F_0F0FL));

// Method 2:
i = ((i & 0xF0000000L) >> 28)
  | ((i & 0xF000000L) >> 16)
  | ((i & 0xF00000L) >> 4)
  | ((i & 0xF0000L) << 8)
  | ((i & 0xF000L) << 20)
  | ((i & 0xF00L) << 32)
  | ((i & 0xF0L) << 44)
  | ((i & 0xFL) << 56);


Note: Using Long.reverseBytes + Long.expand is faster on x64 and ARMv9.
However, on AArch64 with ARMv8, it will be slower compared to the manual unrolling shown in Method 2.
ARMv8 includes Apple M1/M2, AWS Graviton 3; ARMv9.0 includes Apple M3/M4, Aliyun Yitian 710.

I haven't tested this on older x64 CPUs, like the AMD ZEN1, but it's possible that they experience the same issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22942#issuecomment-2576197320
PR Comment: https://git.openjdk.org/jdk/pull/22942#issuecomment-2578863538

From liach at openjdk.org  Fri Jun 13 12:07:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 13 Jun 2025 12:07:25 GMT
Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString
In-Reply-To: <M7quVJyQL3LjWA0l1z0T49EbGxnf6YVt1UI7oTxd25I=.0810b4e5-2f9e-4ccc-8925-1439113c00f8@github.com>
References: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
 <M7quVJyQL3LjWA0l1z0T49EbGxnf6YVt1UI7oTxd25I=.0810b4e5-2f9e-4ccc-8925-1439113c00f8@github.com>
Message-ID: <g0yQ9rc5W1vTt4OiVy_Pf__CrF6t0RYxwSOcnbm7zoA=.5c25e1d0-3e6f-4f2f-afb3-b11d7a173713@github.com>

On Tue, 7 Jan 2025 22:16:19 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> In PR #22928, UUID introduced long-based vectorized hexadecimal to string conversion, which can also be used in Integer::toHexString and Long::toHexString to eliminate table lookups. The benefit of eliminating table lookups is that the performance is better when cache misses occur.
>
> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 204:
> 
>> 202:      */
>> 203:     public static long hex8(long i) {
>> 204:         long x = Long.expand(i, 0x0F0F_0F0F_0F0F_0F0FL);
> 
> x86 should use  pepd - but aarch64?

Seems there is no good way to do so on aarch; raw shifts and going through VPU both seem to be slower.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22942#discussion_r1906141022

From swen at openjdk.org  Fri Jun 13 12:07:21 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 13 Jun 2025 12:07:21 GMT
Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString
Message-ID: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>

In PR #22928, UUID introduced long-based vectorized hexadecimal to string conversion, which can also be used in Integer::toHexString and Long::toHexString to eliminate table lookups. The benefit of eliminating table lookups is that the performance is better when cache misses occur.

-------------

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into optim_to_hex_202501
 - use right shift
 - use right shift
 - fix benchmark
 - Merge remote-tracking branch 'upstream/master' into optim_to_hex_202501
 - Merge remote-tracking branch 'upstream/master' into optim_to_hex_202501
 - Merge remote-tracking branch 'upstream/master' into optim_to_hex_202501
 - reverseBytes
 - reverseBytes
 - public hex8
 - ... and 9 more: https://git.openjdk.org/jdk/compare/e18277b4...6f491ced

Changes: https://git.openjdk.org/jdk/pull/22942/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22942&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359424
  Stats: 262 lines in 6 files changed: 178 ins; 77 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/22942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22942/head:pull/22942

PR: https://git.openjdk.org/jdk/pull/22942

From duke at openjdk.org  Fri Jun 13 12:07:23 2025
From: duke at openjdk.org (Francesco Nigro)
Date: Fri, 13 Jun 2025 12:07:23 GMT
Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString
In-Reply-To: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
References: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
Message-ID: <M7quVJyQL3LjWA0l1z0T49EbGxnf6YVt1UI7oTxd25I=.0810b4e5-2f9e-4ccc-8925-1439113c00f8@github.com>

On Tue, 7 Jan 2025 10:39:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In PR #22928, UUID introduced long-based vectorized hexadecimal to string conversion, which can also be used in Integer::toHexString and Long::toHexString to eliminate table lookups. The benefit of eliminating table lookups is that the performance is better when cache misses occur.

I think that without proper assembly analysis won't be easy to check why...


And yes, pdep is bad in old Ryzen @SirYwell :"( 

It could be either a branch prediction problem too (perfnorm would help) if the list of longs can produce small/big hex strings

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 199:

> 197: 
> 198:     /**
> 199:      * Extract the least significant 8 bytes from the input integer i, convert each byte into its corresponding 2-digit

The least significant 4 bytes

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 204:

> 202:      */
> 203:     public static long hex8(long i) {
> 204:         long x = Long.expand(i, 0x0F0F_0F0F_0F0F_0F0FL);

x86 should use  pepd - but aarch64?

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 228:

> 226:         return ((m << 1) + (m >> 1) - (m >> 4))
> 227:                 + 0x3030_3030_3030_3030L
> 228:                 + (x & 0x0F0F_0F0F_0F0F_0F0FL);

x is already expanded at 0x0F0F_0F0F_0F0F_0F0FL, why & it again?

Another thing: IDK how C2 does math here, but on the assembly it should be straightforward to check if we have some register data dep while performing these series of addition/subtraction.
Usually x86 is more affected by this since it has less register available

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22942#issuecomment-2577178403
PR Review Comment: https://git.openjdk.org/jdk/pull/22942#discussion_r1906110618
PR Review Comment: https://git.openjdk.org/jdk/pull/22942#discussion_r1906104894
PR Review Comment: https://git.openjdk.org/jdk/pull/22942#discussion_r1906103700

From lancea at openjdk.org  Fri Jun 13 12:08:29 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 13 Jun 2025 12:08:29 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v4]
In-Reply-To: <5V1P4tJxU2e5kFf4sP5gIzjE_9ZQTXCmvZb7vrz9LjU=.c9b93f89-68d3-4baf-a7b5-d9a008b0bb11@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <5V1P4tJxU2e5kFf4sP5gIzjE_9ZQTXCmvZb7vrz9LjU=.c9b93f89-68d3-4baf-a7b5-d9a008b0bb11@github.com>
Message-ID: <Kf0rLIAonpG_yFrFtFPKKw9_f7S6g9pzY-SCYYb_8y4=.417f0d22-e6b1-4e04-8a52-b5f004875eff@github.com>

On Thu, 12 Jun 2025 18:05:04 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
>> 
>> `testclasses.jar` is updated such that the two classes no longer extend Applet.
>> 
>> 
>> $ javap fo\ o.class 
>> public class fo o {
>> }
>> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
>> public class ?? {
>> }
>> 
>> 
>> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
>> 
>> Additionally, the security APIs that were marked for removal are also removed from this test as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address offline review -> comments for maintainers, simplify exc and JAR_PATH

Thank you for the updates Justin.  





Looks good overall.  If you have to update this test again, it might be worthwhile considering converting to a junit test

test/jdk/jdk/internal/loader/URLClassPath/ClassnameCharTest.java line 136:

> 134:                     return defineClass(name, b, 0, b.length, codesource);
> 135:                 }
> 136:                 // protocol/host/port mismatch, fail with RuntimeExc

Typo RuntimeExc?

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25703#pullrequestreview-2922739662
PR Review Comment: https://git.openjdk.org/jdk/pull/25703#discussion_r2143711460

From hgreule at openjdk.org  Fri Jun 13 12:07:21 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Fri, 13 Jun 2025 12:07:21 GMT
Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString
In-Reply-To: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
References: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
Message-ID: <Usc614wJc-C3S2WzlPKZNEjc33f8mB18y1JIPJqGtiY=.9a8e7c83-8ffa-42ad-a092-a296ba9cb1c3@github.com>

On Tue, 7 Jan 2025 10:39:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In PR #22928, UUID introduced long-based vectorized hexadecimal to string conversion, which can also be used in Integer::toHexString and Long::toHexString to eliminate table lookups. The benefit of eliminating table lookups is that the performance is better when cache misses occur.

Running it on my machine (Ryzen 9 3900X):

baseline (91db7c0877a68ad171da2b4501280fc24630ae83):
Integers.toHexString     500  avgt   15  5.717 ? 0.274  us/op
Longs.toHexString        500  avgt   15  6.851 ? 0.214  us/op

this change (1788d09787cadfe6ec23b9b10bef87a2cdc029a3):
Integers.toHexString     500  avgt   15  21.334 ? 0.268  us/op
Longs.toHexString        500  avgt   15  38.907 ? 0.589  us/op

I know that this processor has an extremely slow implementation of the `PDEP` instruction, but I'm kinda surprised you're seeing better results on aarch64. But I think Zen1 and Zen2 should considered here to avoid regressions on those architectures.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22942#issuecomment-2577153462

From liach at openjdk.org  Fri Jun 13 12:07:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 13 Jun 2025 12:07:25 GMT
Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString
In-Reply-To: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
References: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
Message-ID: <-x5hXYEtYkxrUQybOwEGrqgBAtpTZnwrLyvuIO7szdo=.4a27c17c-b362-437d-9a01-1eadf35f3042@github.com>

On Tue, 7 Jan 2025 10:39:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In PR #22928, UUID introduced long-based vectorized hexadecimal to string conversion, which can also be used in Integer::toHexString and Long::toHexString to eliminate table lookups. The benefit of eliminating table lookups is that the performance is better when cache misses occur.

src/java.base/share/classes/java/lang/Integer.java line 312:

> 310:      * this string as a hexadecimal number to form and return a long value.
> 311:      */
> 312:     static long hex8(long i) {

I think we should move this to HexDigits.

src/java.base/share/classes/java/lang/Long.java line 325:

> 323:             if (COMPACT_STRINGS) {
> 324:                 len -= 8;
> 325:                 Unsafe.getUnsafe().putLong(chars, ARRAY_BYTE_BASE_OFFSET + len, Long.reverseBytes(x));

We only need to reverse on small endian platforms right? We can use putLongUnaligned which takes a boolean for big endian so conversion is automatic.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22942#discussion_r1905774332
PR Review Comment: https://git.openjdk.org/jdk/pull/22942#discussion_r1905786538

From swen at openjdk.org  Fri Jun 13 13:25:29 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 13 Jun 2025 13:25:29 GMT
Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString
In-Reply-To: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
References: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
Message-ID: <hqvM4k2Ch7P-SnMdMmdhAusYWIgPJzSmlxBPNUlgQVA=.2cad1193-f91b-47f4-b0b5-ea5a1b075911@github.com>

On Tue, 7 Jan 2025 10:39:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In PR #22928, UUID introduced long-based vectorized hexadecimal to string conversion, which can also be used in Integer::toHexString and Long::toHexString to eliminate table lookups. The benefit of eliminating table lookups is that the performance is better when cache misses occur.

Performance test figures show that using the vectorized method toHex can improve performance in most cases by eliminating table lookups.

## 1. Script

git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

# baseline
git checkout 7731f4df6ba12b4e38f17f87bd42b1da6dc68f95
make test TEST="micro:java.lang.Integers.toHexString"
make test TEST="micro:java.lang.Longs.toHexString"
           
 # current
git checkout 6f491cedc2311115ab81b479620da3eb71385fc8
make test TEST="micro:java.lang.Integers.toHexString"
make test TEST="micro:java.lang.Longs.toHexString"


## 2. aliyun_ecs_c8a_x64 (CPU AMD EPYC? Genoa)

-# 7731f4df6ba12b4e38f17f87bd42b1da6dc68f95
-Benchmark                  (size)  Mode  Cnt  Score   Error  Units
-Longs.toHexStringBig          500  avgt   15  5.984 ? 0.009  us/op
-Longs.toHexStringSmall        500  avgt   15  3.989 ? 0.036  us/op
-Integers.toHexStringBig       500  avgt   15  4.473 ? 0.029  us/op
-Integers.toHexStringSmall     500  avgt   15  4.166 ? 0.120  us/op
-Integers.toHexStringTiny      500  avgt   15  3.394 ? 0.014  us/op

+# 6f491cedc2311115ab81b479620da3eb71385fc8
+Benchmark                  (size)  Mode  Cnt  Score   Error  Units
+Longs.toHexStringBig          500  avgt   15  4.622 ? 0.011  us/op +29%
+Longs.toHexStringSmall        500  avgt   15  3.957 ? 0.035  us/op +0.8%
+Integers.toHexStringBig       500  avgt   15  3.985 ? 0.019  us/op +12.24%
+Integers.toHexStringSmall     500  avgt   15  3.617 ? 0.020  us/op +15.17%
+Integers.toHexStringTiny      500  avgt   15  3.033 ? 0.015  us/op +11.90%



## 3. aliyun_ecs_c8i_x64 (CPU Intel?Xeon?Emerald Rapids)

-# 7731f4df6ba12b4e38f17f87bd42b1da6dc68f95
-Benchmark                  (size)  Mode  Cnt  Score   Error  Units
-Longs.toHexStringBig          500  avgt   15  5.685 ? 0.019  us/op
-Longs.toHexStringSmall        500  avgt   15  3.914 ? 0.009  us/op
-Integers.toHexStringBig       500  avgt   15  4.262 ? 0.025  us/op
-Integers.toHexStringSmall     500  avgt   15  4.049 ? 0.012  us/op
-Integers.toHexStringTiny      500  avgt   15  3.323 ? 0.015  us/op

+# 6f491cedc2311115ab81b479620da3eb71385fc8
+Benchmark                  (size)  Mode  Cnt  Score   Error  Units
+Longs.toHexStringBig          500  avgt   15  4.791 ? 0.005  us/op
+Longs.toHexStringSmall        500  avgt   15  3.994 ? 0.022  us/op
+Integers.toHexStringBig       500  avgt   15  4.184 ? 0.034  us/op
+Integers.toHexStringSmall     500  avgt   15  3.771 ? 0.019  us/op
+Integers.toHexStringTiny      500  avgt   15  3.133 ? 0.021  us/op



## 4. aliyun_ecs_c8y_aarch64 (CPU Aliyun Yitian 710)

-# 7731f4df6ba12b4e38f17f87bd42b1da6dc68f95
-Benchmark                  (size)  Mode  Cnt  Score   Error  Units
-Longs.toHexStringBig          500  avgt   15  8.319 ? 0.139  us/op
-Longs.toHexStringSmall        500  avgt   15  4.985 ? 0.028  us/op
-Integers.toHexStringBig       500  avgt   15  5.489 ? 0.041  us/op
-Integers.toHexStringSmall     500  avgt   15  5.028 ? 0.033  us/op
-Integers.toHexStringTiny      500  avgt   15  3.921 ? 0.023  us/op

+# 6f491cedc2311115ab81b479620da3eb71385fc8
+Benchmark                  (size)  Mode  Cnt  Score   Error  Units
+Longs.toHexStringBig          500  avgt   15  5.346 ? 0.033  us/op
+Longs.toHexStringSmall        500  avgt   15  4.383 ? 0.027  us/op
+Integers.toHexStringBig       500  avgt   15  4.821 ? 0.052  us/op
+Integers.toHexStringSmall     500  avgt   15  4.428 ? 0.036  us/op
+Integers.toHexStringTiny      500  avgt   15  3.800 ? 0.046  us/op




## 5. MacBook M1 Pro (aarch64)

-# 7731f4df6ba12b4e38f17f87bd42b1da6dc68f95
-Benchmark                  (size)  Mode  Cnt   Score   Error  Units
-Longs.toHexStringBig          500  avgt   15  6.878 ? 0.230  us/op
-Longs.toHexStringSmall        500  avgt   15  4.975 ? 0.381  us/op
-Integers.toHexStringBig       500  avgt   15  11.646 ? 2.699  us/op
-Integers.toHexStringSmall     500  avgt   15   5.040 ? 0.319  us/op
-Integers.toHexStringTiny      500  avgt   15   2.717 ? 0.023  us/op

+# 6f491cedc2311115ab81b479620da3eb71385fc8
+Benchmark                  (size)  Mode  Cnt  Score   Error  Units
+Longs.toHexStringBig          500  avgt   15  4.007 ? 0.023  us/op
+Longs.toHexStringSmall        500  avgt   15  3.058 ? 0.024  us/op
+Integers.toHexStringBig       500  avgt   15  3.399 ? 0.017  us/op
+Integers.toHexStringSmall     500  avgt   15  3.163 ? 0.026  us/op
+Integers.toHexStringTiny      500  avgt   15  2.909 ? 0.026  us/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22942#issuecomment-2970383406

From rgiulietti at openjdk.org  Fri Jun 13 15:26:58 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 13 Jun 2025 15:26:58 GMT
Subject: RFR: 8358804: Improve the API Note of BigDecimal.valueOf(double)
Message-ID: <rA03Hheb1nuUcqdJdVnqcOSpvFjt2z3hFzMjgbtC6FI=.f5d60aa7-58f7-4b51-90c1-4b8b31a23a98@github.com>

Documenting a suggestion for `float` arguments.

-------------

Commit messages:
 - 8358804: Improve the API Note of BigDecimal.valueOf(double)

Changes: https://git.openjdk.org/jdk/pull/25805/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25805&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358804
  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25805.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25805/head:pull/25805

PR: https://git.openjdk.org/jdk/pull/25805

From bpb at openjdk.org  Fri Jun 13 17:42:41 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Jun 2025 17:42:41 GMT
Subject: RFR: 8358804: Improve the API Note of BigDecimal.valueOf(double)
In-Reply-To: <rA03Hheb1nuUcqdJdVnqcOSpvFjt2z3hFzMjgbtC6FI=.f5d60aa7-58f7-4b51-90c1-4b8b31a23a98@github.com>
References: <rA03Hheb1nuUcqdJdVnqcOSpvFjt2z3hFzMjgbtC6FI=.f5d60aa7-58f7-4b51-90c1-4b8b31a23a98@github.com>
Message-ID: <x7MaBReC49K0Fvz105zPC4PUy9H06SS_BVMFZbJJqCU=.7c7eb6d4-60ca-452e-9982-4cb812e34ccf@github.com>

On Fri, 13 Jun 2025 15:21:38 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Documenting a suggestion for `float` arguments.

src/java.base/share/classes/java/math/BigDecimal.java line 1383:

> 1381:      * the result usually contains too many trailing digits compared
> 1382:      * to the precision of a {@code float}.
> 1383:      * Consider using {@code new BigDecimal(Float.toString(v))} instead.

Perhaps move "Consider using" to the previous line; otherwise, looks fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25805#discussion_r2145650829

From jlu at openjdk.org  Fri Jun 13 17:47:16 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 13 Jun 2025 17:47:16 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v5]
In-Reply-To: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
Message-ID: <lEK6--77fLT1fBhemFGaAXXNMuKuXogv9JNVK_V1PZQ=.b14543f4-ef63-4197-8d2b-d18626a4a0df@github.com>

> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
> 
> `testclasses.jar` is updated such that the two classes no longer extend Applet.
> 
> 
> $ javap fo\ o.class 
> public class fo o {
> }
> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
> public class ?? {
> }
> 
> 
> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
> 
> Additionally, the security APIs that were marked for removal are also removed from this test as well.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Address review - Convert to JUnit, correct comment typo, remove 'Infra' methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25703/files
  - new: https://git.openjdk.org/jdk/pull/25703/files/47f62aa2..02c76c74

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25703&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25703&range=03-04

  Stats: 110 lines in 1 file changed: 22 ins; 61 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/25703.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25703/head:pull/25703

PR: https://git.openjdk.org/jdk/pull/25703

From jlu at openjdk.org  Fri Jun 13 17:47:16 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 13 Jun 2025 17:47:16 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v4]
In-Reply-To: <Kf0rLIAonpG_yFrFtFPKKw9_f7S6g9pzY-SCYYb_8y4=.417f0d22-e6b1-4e04-8a52-b5f004875eff@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <5V1P4tJxU2e5kFf4sP5gIzjE_9ZQTXCmvZb7vrz9LjU=.c9b93f89-68d3-4baf-a7b5-d9a008b0bb11@github.com>
 <Kf0rLIAonpG_yFrFtFPKKw9_f7S6g9pzY-SCYYb_8y4=.417f0d22-e6b1-4e04-8a52-b5f004875eff@github.com>
Message-ID: <cxo9h4BD6goSi9efsHST8E9Edca-0OPj_wKx-Bl5r1A=.fc16d7f1-e705-4e01-b7f2-6f39cd0e367c@github.com>

On Thu, 12 Jun 2025 21:42:26 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address offline review -> comments for maintainers, simplify exc and JAR_PATH
>
> test/jdk/jdk/internal/loader/URLClassPath/ClassnameCharTest.java line 136:
> 
>> 134:                     return defineClass(name, b, 0, b.length, codesource);
>> 135:                 }
>> 136:                 // protocol/host/port mismatch, fail with RuntimeExc
> 
> Typo RuntimeExc?

https://github.com/openjdk/jdk/pull/25703/commits/02c76c749015fc7d59992036625363d16773595f corrects the comment typo and also makes a conversion of this test to JUnit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25703#discussion_r2145674512

From iris at openjdk.org  Fri Jun 13 17:49:33 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 13 Jun 2025 17:49:33 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page
In-Reply-To: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
Message-ID: <o7RDH55N6lVO_SrAJ5pFnjDJffcX4YKPOUgOgTjPrEc=.d0d98022-c3c8-468b-a491-e2131ce3b76b@github.com>

On Thu, 12 Jun 2025 07:57:20 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

> Please review my PR. This PR includes the following:
> 
> - [x] Fix a small typo in a word and copyright.
> - [x] Enhance description for `--target-platform`.
> - [x] Rearrange `jmod create` example from basic to complex.

Changes requested by iris (Reviewer).

src/jdk.jlink/share/man/jmod.md line 183:

> 181: `--target-platform` *platform*
> 182: :   Specifies the target platform. The value is a string that identifies
> 183:     the platform this module is intended for, typically in the form `<os>-<arch>`.

Consider: "The value is a string identifying the module's intended platform, typically of the form `<os>-<arch>`.

src/jdk.jlink/share/man/jmod.md line 220:

> 218:     deprecated, deprecated-for-removal, or incubating.
> 219: 
> 220: ## jmod Create Example

"Example" -> "Examples"

src/jdk.jlink/share/man/jmod.md line 222:

> 220: ## jmod Create Example
> 221: 
> 222: The basic manner to create a JMOD file is by including only compiled classes:

I"m not sure what this is supposed to describe, perhaps something like this is more clear:  "Create a JMOD file containing only compiled classes:".

Whatever you choose should be parallel to the descriptions of the other create examples.  (My later comments are parallel to my suggestion for this line.)

src/jdk.jlink/share/man/jmod.md line 228:

> 226: ```
> 227: 
> 228: To ensure reproducible artifacts, the following command creates

Is it necessary to provide a reason to use this option rather than just describe what the example does?  For parallelization, I'd retain the text in old line 231.

src/jdk.jlink/share/man/jmod.md line 237:

> 235: 
> 236: The command below creates a platform-specific JMOD file, bundling class files,
> 237: user-editable configuration files, header files, native commands and libraries:

Your description for the more complex command line should either list all or none of the options.

If you chose the "none" approach, consider "Create a platform-specific JMOD file containing multiple artifacts."

If you chose the "all" approach, you'll need to add references to the  options on line 242, e.g. "Create a platform-specific JMOD file containing class files, user-editable configuration files, header files, ... ".

-------------

PR Review: https://git.openjdk.org/jdk/pull/25772#pullrequestreview-2925555112
PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2145550424
PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2145564293
PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2145578809
PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2145585506
PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2145676273

From lancea at openjdk.org  Fri Jun 13 17:57:34 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 13 Jun 2025 17:57:34 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v5]
In-Reply-To: <lEK6--77fLT1fBhemFGaAXXNMuKuXogv9JNVK_V1PZQ=.b14543f4-ef63-4197-8d2b-d18626a4a0df@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <lEK6--77fLT1fBhemFGaAXXNMuKuXogv9JNVK_V1PZQ=.b14543f4-ef63-4197-8d2b-d18626a4a0df@github.com>
Message-ID: <l8dqnTI__iVwuk9aK-WEC8mGdsHwORjMZlSGwVerpR0=.e92d8b55-de3a-4db5-a017-acd8d3f6a12e@github.com>

On Fri, 13 Jun 2025 17:47:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
>> 
>> `testclasses.jar` is updated such that the two classes no longer extend Applet.
>> 
>> 
>> $ javap fo\ o.class 
>> public class fo o {
>> }
>> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
>> public class ?? {
>> }
>> 
>> 
>> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
>> 
>> Additionally, the security APIs that were marked for removal are also removed from this test as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review - Convert to JUnit, correct comment typo, remove 'Infra' methods

Thank you for the changes Justin

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25703#pullrequestreview-2925755658

From rgiulietti at openjdk.org  Fri Jun 13 18:12:29 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 13 Jun 2025 18:12:29 GMT
Subject: RFR: 8358804: Improve the API Note of BigDecimal.valueOf(double)
In-Reply-To: <x7MaBReC49K0Fvz105zPC4PUy9H06SS_BVMFZbJJqCU=.7c7eb6d4-60ca-452e-9982-4cb812e34ccf@github.com>
References: <rA03Hheb1nuUcqdJdVnqcOSpvFjt2z3hFzMjgbtC6FI=.f5d60aa7-58f7-4b51-90c1-4b8b31a23a98@github.com>
 <x7MaBReC49K0Fvz105zPC4PUy9H06SS_BVMFZbJJqCU=.7c7eb6d4-60ca-452e-9982-4cb812e34ccf@github.com>
Message-ID: <1D6E5pt-gI54xysVmipDFIE3eqf4e7YjU0YV2DFI4cE=.49bef2d5-ecd2-47a4-be5d-b2cb56f27af8@github.com>

On Fri, 13 Jun 2025 17:39:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Documenting a suggestion for `float` arguments.
>
> src/java.base/share/classes/java/math/BigDecimal.java line 1383:
> 
>> 1381:      * the result usually contains too many trailing digits compared
>> 1382:      * to the precision of a {@code float}.
>> 1383:      * Consider using {@code new BigDecimal(Float.toString(v))} instead.
> 
> Perhaps move "Consider using" to the previous line; otherwise, looks fine.

I usually start a sentence on a new line because that generates less noise when diffing in the future.
The HTML renders it in the same paragraph as the preceding text.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25805#discussion_r2145721480

From bpb at openjdk.org  Fri Jun 13 18:42:37 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Jun 2025 18:42:37 GMT
Subject: RFR: 8358804: Improve the API Note of BigDecimal.valueOf(double)
In-Reply-To: <rA03Hheb1nuUcqdJdVnqcOSpvFjt2z3hFzMjgbtC6FI=.f5d60aa7-58f7-4b51-90c1-4b8b31a23a98@github.com>
References: <rA03Hheb1nuUcqdJdVnqcOSpvFjt2z3hFzMjgbtC6FI=.f5d60aa7-58f7-4b51-90c1-4b8b31a23a98@github.com>
Message-ID: <KXZCeQAsfilsikly-V9tomthLy6Tahchz9hjhcBNMzA=.9e7770c5-c66b-48a3-9993-e378f30a7635@github.com>

On Fri, 13 Jun 2025 15:21:38 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Documenting a suggestion for `float` arguments.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25805#pullrequestreview-2925970196

From bpb at openjdk.org  Fri Jun 13 18:42:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Jun 2025 18:42:38 GMT
Subject: RFR: 8358804: Improve the API Note of BigDecimal.valueOf(double)
In-Reply-To: <1D6E5pt-gI54xysVmipDFIE3eqf4e7YjU0YV2DFI4cE=.49bef2d5-ecd2-47a4-be5d-b2cb56f27af8@github.com>
References: <rA03Hheb1nuUcqdJdVnqcOSpvFjt2z3hFzMjgbtC6FI=.f5d60aa7-58f7-4b51-90c1-4b8b31a23a98@github.com>
 <x7MaBReC49K0Fvz105zPC4PUy9H06SS_BVMFZbJJqCU=.7c7eb6d4-60ca-452e-9982-4cb812e34ccf@github.com>
 <1D6E5pt-gI54xysVmipDFIE3eqf4e7YjU0YV2DFI4cE=.49bef2d5-ecd2-47a4-be5d-b2cb56f27af8@github.com>
Message-ID: <9vgr2yCDUPGotTDyZzt1xf1EPzvEBTsTVdZr-9X_rxk=.ab4c0204-4cbb-498c-babd-46ea63737729@github.com>

On Fri, 13 Jun 2025 18:10:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 1383:
>> 
>>> 1381:      * the result usually contains too many trailing digits compared
>>> 1382:      * to the precision of a {@code float}.
>>> 1383:      * Consider using {@code new BigDecimal(Float.toString(v))} instead.
>> 
>> Perhaps move "Consider using" to the previous line; otherwise, looks fine.
>
> I usually start a sentence on a new line because that generates less noise when diffing in the future.
> The HTML renders it in the same paragraph as the preceding text.

Makes sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25805#discussion_r2145854316

From duke at openjdk.org  Fri Jun 13 19:26:38 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Fri, 13 Jun 2025 19:26:38 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v5]
In-Reply-To: <lEK6--77fLT1fBhemFGaAXXNMuKuXogv9JNVK_V1PZQ=.b14543f4-ef63-4197-8d2b-d18626a4a0df@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <lEK6--77fLT1fBhemFGaAXXNMuKuXogv9JNVK_V1PZQ=.b14543f4-ef63-4197-8d2b-d18626a4a0df@github.com>
Message-ID: <NZNgRCS3BXmuYT5HySkTG7KqW9Qmamade4dN6fvbtcM=.d26eafad-3906-4e1b-a13f-9332867a3742@github.com>

On Fri, 13 Jun 2025 17:47:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
>> 
>> `testclasses.jar` is updated such that the two classes no longer extend Applet.
>> 
>> 
>> $ javap fo\ o.class 
>> public class fo o {
>> }
>> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
>> public class ?? {
>> }
>> 
>> 
>> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
>> 
>> Additionally, the security APIs that were marked for removal are also removed from this test as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review - Convert to JUnit, correct comment typo, remove 'Infra' methods

test/jdk/jdk/internal/loader/URLClassPath/ClassnameCharTest.java line 57:

> 55:     static void setup() throws IOException {
> 56:         var bytes = ClassFile.of().build(ClassDesc.of("fo o"), _ -> {});
> 57:         try (JarOutputStream jos = new JarOutputStream(new FileOutputStream(JAR_PATH.toFile()))) {

Suggestion: The original test used testclasses.jar to provide two class files with invalid names packaged in a jar. Since you now dynamically construct the class files, there is no need to write them to disk as a jar. Why not have a Map<String,bytes[]), mapping a resource path to bytes, to store all used class files in memory.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25703#discussion_r2145924359

From duke at openjdk.org  Fri Jun 13 19:33:18 2025
From: duke at openjdk.org (Johannes Graham)
Date: Fri, 13 Jun 2025 19:33:18 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v5]
In-Reply-To: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
Message-ID: <Ak8ex7_jSxy75IEIdfCBSeZh2qd103F5--f3s4h_Gho=.aa54d788-a687-49fa-bb35-a14871af7f40@github.com>

> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
> 
> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
> 
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  Revert "fix overflow check"
  
  This reverts commit 6a072873ffa87d1191b42053b9f5d955f0119057.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25644/files
  - new: https://git.openjdk.org/jdk/pull/25644/files/6a072873..c87a3ded

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25644&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25644&range=03-04

  Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25644/head:pull/25644

PR: https://git.openjdk.org/jdk/pull/25644

From duke at openjdk.org  Fri Jun 13 19:37:32 2025
From: duke at openjdk.org (Johannes Graham)
Date: Fri, 13 Jun 2025 19:37:32 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v3]
In-Reply-To: <Tv8HMWAw2YxNwcjL3_8ZoELHZZHCI-RSeMNbN-NBU5g=.dac7959c-1d74-47c3-a283-fe212dcd3705@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <-6TYWikmLNBtyQt6_xeJ8KoziHxA8Ijr067NIc740X0=.2f9e4cae-7f39-46b8-b3a9-f381fb2e0518@github.com>
 <JNEKtkhrEYnS1SvaSz7GhcS4FQGkQXma4nY_Wo0T18A=.3dce72d9-7250-4672-adad-13db79e3150c@github.com>
 <tCE4NXNXnwQro2lXxzJbDuJzrcTt3k2bNrR8wk54jX8=.6a749f99-e70b-426b-ad9d-e077c115f42d@github.com>
 <Tv8HMWAw2YxNwcjL3_8ZoELHZZHCI-RSeMNbN-NBU5g=.dac7959c-1d74-47c3-a283-fe212dcd3705@github.com>
Message-ID: <hzCwNHUbtMWh_V3rtnMipAOj2_bB1UF-Sewy2kttvH4=.d29dac97-b7df-4a17-94ff-36c4ce8cbed1@github.com>

On Thu, 12 Jun 2025 22:52:21 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Unfortunately some check is required (a test fails), but I now realize what I had was wrong. The issue is that on line 1084 (https://github.com/openjdk/jdk/pull/25644/files#diff-79e6fd549b5ec5e7f49658581beddcb07fcbb0c09ae8e1117c385b66514da6d2R1084)) exp can overflow and become positive again. I've updated the check to avoid the overflow.
>
> Ah got it, I see your point. We would have goten underflow in `ASCIIToBinaryConverter.doubleValue()` for some extreme cases without a check. 
> 
> Is there a specific example you have that requires the switch to the newer check? Adding a comment along those lines might be helpful. Actually, I thought DigitList caps `decimalAt` to Integer.MIN/MAX, so then the first check you had would have been fine. (Maybe I am missing something?)

I don't have a specific example, so I've reverted to my original check. I'm a bit unsettled by the check for an extreme value later in `doubleValue()` comparing against `MIN_DECIMAL_EXPONENT - 1`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2145942325

From duke at openjdk.org  Fri Jun 13 20:59:57 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Fri, 13 Jun 2025 20:59:57 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v5]
In-Reply-To: <lEK6--77fLT1fBhemFGaAXXNMuKuXogv9JNVK_V1PZQ=.b14543f4-ef63-4197-8d2b-d18626a4a0df@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <lEK6--77fLT1fBhemFGaAXXNMuKuXogv9JNVK_V1PZQ=.b14543f4-ef63-4197-8d2b-d18626a4a0df@github.com>
Message-ID: <AaGpPwnSaIKPiuFxNN30n5Oj_y3WP6DUmbNT_jMF4l8=.f49cca8a-bd55-46a5-aab5-682413421187@github.com>

On Fri, 13 Jun 2025 17:47:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
>> 
>> `testclasses.jar` is updated such that the two classes no longer extend Applet.
>> 
>> 
>> $ javap fo\ o.class 
>> public class fo o {
>> }
>> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
>> public class ?? {
>> }
>> 
>> 
>> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
>> 
>> Additionally, the security APIs that were marked for removal are also removed from this test as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review - Convert to JUnit, correct comment typo, remove 'Infra' methods

test/jdk/jdk/internal/loader/URLClassPath/ClassnameCharTest.java line 57:

> 55:     static void setup() throws IOException {
> 56:         var bytes = ClassFile.of().build(ClassDesc.of("fo o"), _ -> {});
> 57:         try (JarOutputStream jos = new JarOutputStream(new FileOutputStream(JAR_PATH.toFile()))) {

Suggestion: The original test used testclasses.jar to provide two class files with invalid names packaged in a jar. Since you now dynamically construct the class files, there is no need to write them to disk as a jar. Why not have a Map<String,byte[]), mapping a resource path to bytes, to store all used class files in memory.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25703#discussion_r2146081990

From darcy at openjdk.org  Fri Jun 13 21:05:28 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Jun 2025 21:05:28 GMT
Subject: RFR: 8358804: Improve the API Note of BigDecimal.valueOf(double)
In-Reply-To: <9vgr2yCDUPGotTDyZzt1xf1EPzvEBTsTVdZr-9X_rxk=.ab4c0204-4cbb-498c-babd-46ea63737729@github.com>
References: <rA03Hheb1nuUcqdJdVnqcOSpvFjt2z3hFzMjgbtC6FI=.f5d60aa7-58f7-4b51-90c1-4b8b31a23a98@github.com>
 <x7MaBReC49K0Fvz105zPC4PUy9H06SS_BVMFZbJJqCU=.7c7eb6d4-60ca-452e-9982-4cb812e34ccf@github.com>
 <1D6E5pt-gI54xysVmipDFIE3eqf4e7YjU0YV2DFI4cE=.49bef2d5-ecd2-47a4-be5d-b2cb56f27af8@github.com>
 <9vgr2yCDUPGotTDyZzt1xf1EPzvEBTsTVdZr-9X_rxk=.ab4c0204-4cbb-498c-babd-46ea63737729@github.com>
Message-ID: <iHnZ-AnxKO8mPYdcHvQx0e9xU5_qbI_8IsIPjWgmnrU=.04463e1c-3268-45eb-bd03-c7d116b2da97@github.com>

On Fri, 13 Jun 2025 18:39:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I usually start a sentence on a new line because that generates less noise when diffing in the future.
>> The HTML renders it in the same paragraph as the preceding text.
>
> Makes sense.

> I usually start a sentence on a new line because that generates less noise when diffing in the future. The HTML renders it in the same paragraph as the preceding text.

I use that authoring convention too; leads to clearer diffs on any future edits.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25805#discussion_r2146089711

From duke at openjdk.org  Fri Jun 13 21:10:30 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Fri, 13 Jun 2025 21:10:30 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v2]
In-Reply-To: <qhj93MMGIJdu0VHsiSarvBUWRPD-wXwVKpQQdMRj0HQ=.fe204c78-69f4-4fc7-a789-3f0c4d9289e2@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <XyQDGxDBfdASO7mHAj8BqpHxPESugXyRwf6y_5S2aVs=.d6f45bb5-98f6-4996-a4b1-a8f6049bf7f1@github.com>
 <qhj93MMGIJdu0VHsiSarvBUWRPD-wXwVKpQQdMRj0HQ=.fe204c78-69f4-4fc7-a789-3f0c4d9289e2@github.com>
Message-ID: <ewNUO1OhZd8P5h3rGhy7IGhpB5TQAemNFzWx7jw-b40=.e7c49e0e-1adb-461e-9005-aebd628bf31c@github.com>

On Thu, 12 Jun 2025 15:29:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I went back and looked at the JDK-5017871 issue through which the `fo o.class` was being tested and from what I see in there, the current test changes continue to test that issue. I think there might be better ways to test that original use case and this test could be simplified a lot, but it's certainly not for this PR.

Maybe labelling this test with  `@bug 4957669 5017871` was a mistake, test/jdk/java/net/Socket/IDNTest.java does address 4957669 and 5017871.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25703#issuecomment-2971687510

From darcy at openjdk.org  Fri Jun 13 21:23:37 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Jun 2025 21:23:37 GMT
Subject: RFR: 8358804: Improve the API Note of BigDecimal.valueOf(double)
In-Reply-To: <rA03Hheb1nuUcqdJdVnqcOSpvFjt2z3hFzMjgbtC6FI=.f5d60aa7-58f7-4b51-90c1-4b8b31a23a98@github.com>
References: <rA03Hheb1nuUcqdJdVnqcOSpvFjt2z3hFzMjgbtC6FI=.f5d60aa7-58f7-4b51-90c1-4b8b31a23a98@github.com>
Message-ID: <A-an0-dvrtFTKAdAKbO1ymkNtoovEh7_-agHCLCZil4=.e8d2c6a7-995b-43df-a703-1b3ccc22062f@github.com>

On Fri, 13 Jun 2025 15:21:38 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Documenting a suggestion for `float` arguments.

src/java.base/share/classes/java/math/BigDecimal.java line 1380:

> 1378:      * Double#toString(double)}.
> 1379:      * <p>
> 1380:      * While a {@code float} argument {@code v} can be passed to this method,

I recommend a slightly different wording; suggestion:

"...the result often contains many more trailing digits than the precision of a `float`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25805#discussion_r2146108818

From rgiulietti at openjdk.org  Fri Jun 13 21:46:42 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 13 Jun 2025 21:46:42 GMT
Subject: RFR: 8358804: Improve the API Note of BigDecimal.valueOf(double)
 [v2]
In-Reply-To: <rA03Hheb1nuUcqdJdVnqcOSpvFjt2z3hFzMjgbtC6FI=.f5d60aa7-58f7-4b51-90c1-4b8b31a23a98@github.com>
References: <rA03Hheb1nuUcqdJdVnqcOSpvFjt2z3hFzMjgbtC6FI=.f5d60aa7-58f7-4b51-90c1-4b8b31a23a98@github.com>
Message-ID: <OKYou_S726jIvgFYy9DqsW1MqwZlwpe57hVx-CdIOlU=.842e8518-0e38-41a3-9957-27cffbfdb488@github.com>

> Documenting a suggestion for `float` arguments.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Suggestion by reviewer.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25805/files
  - new: https://git.openjdk.org/jdk/pull/25805/files/9a5ff7c1..36b9a01e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25805&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25805&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25805.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25805/head:pull/25805

PR: https://git.openjdk.org/jdk/pull/25805

From bpb at openjdk.org  Fri Jun 13 23:10:28 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Jun 2025 23:10:28 GMT
Subject: RFR: 8358804: Improve the API Note of BigDecimal.valueOf(double)
 [v2]
In-Reply-To: <OKYou_S726jIvgFYy9DqsW1MqwZlwpe57hVx-CdIOlU=.842e8518-0e38-41a3-9957-27cffbfdb488@github.com>
References: <rA03Hheb1nuUcqdJdVnqcOSpvFjt2z3hFzMjgbtC6FI=.f5d60aa7-58f7-4b51-90c1-4b8b31a23a98@github.com>
 <OKYou_S726jIvgFYy9DqsW1MqwZlwpe57hVx-CdIOlU=.842e8518-0e38-41a3-9957-27cffbfdb488@github.com>
Message-ID: <Oa0I9TQ9EkpVWDycm9MwhFLFRg_BMXGX1YP-cU21W2Y=.eb76e4e0-8fc9-449b-8b3d-c8a1d8b766e8@github.com>

On Fri, 13 Jun 2025 21:46:42 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Documenting a suggestion for `float` arguments.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggestion by reviewer.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25805#pullrequestreview-2926737056

From darcy at openjdk.org  Fri Jun 13 23:53:28 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Jun 2025 23:53:28 GMT
Subject: RFR: 8358804: Improve the API Note of BigDecimal.valueOf(double)
 [v2]
In-Reply-To: <OKYou_S726jIvgFYy9DqsW1MqwZlwpe57hVx-CdIOlU=.842e8518-0e38-41a3-9957-27cffbfdb488@github.com>
References: <rA03Hheb1nuUcqdJdVnqcOSpvFjt2z3hFzMjgbtC6FI=.f5d60aa7-58f7-4b51-90c1-4b8b31a23a98@github.com>
 <OKYou_S726jIvgFYy9DqsW1MqwZlwpe57hVx-CdIOlU=.842e8518-0e38-41a3-9957-27cffbfdb488@github.com>
Message-ID: <yX963sli0kk4uStdbswTRZNjg1Gs9YgzrLlyEGKaMGY=.9899aae9-9297-449d-a9d3-29b8027bfe2c@github.com>

On Fri, 13 Jun 2025 21:46:42 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Documenting a suggestion for `float` arguments.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggestion by reviewer.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25805#pullrequestreview-2926804580

From iris at openjdk.org  Sat Jun 14 11:10:39 2025
From: iris at openjdk.org (Iris Clark)
Date: Sat, 14 Jun 2025 11:10:39 GMT
Subject: RFR: 8358804: Improve the API Note of BigDecimal.valueOf(double)
 [v2]
In-Reply-To: <OKYou_S726jIvgFYy9DqsW1MqwZlwpe57hVx-CdIOlU=.842e8518-0e38-41a3-9957-27cffbfdb488@github.com>
References: <rA03Hheb1nuUcqdJdVnqcOSpvFjt2z3hFzMjgbtC6FI=.f5d60aa7-58f7-4b51-90c1-4b8b31a23a98@github.com>
 <OKYou_S726jIvgFYy9DqsW1MqwZlwpe57hVx-CdIOlU=.842e8518-0e38-41a3-9957-27cffbfdb488@github.com>
Message-ID: <86U91QbJYoLwOUrkGS6kkl8KUaBopCigUqdDmwDVS18=.17430a08-72b6-43a5-ac50-b21761671a29@github.com>

On Fri, 13 Jun 2025 21:46:42 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Documenting a suggestion for `float` arguments.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggestion by reviewer.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25805#pullrequestreview-2927199068

From rgiulietti at openjdk.org  Sat Jun 14 11:10:39 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sat, 14 Jun 2025 11:10:39 GMT
Subject: Integrated: 8358804: Improve the API Note of
 BigDecimal.valueOf(double)
In-Reply-To: <rA03Hheb1nuUcqdJdVnqcOSpvFjt2z3hFzMjgbtC6FI=.f5d60aa7-58f7-4b51-90c1-4b8b31a23a98@github.com>
References: <rA03Hheb1nuUcqdJdVnqcOSpvFjt2z3hFzMjgbtC6FI=.f5d60aa7-58f7-4b51-90c1-4b8b31a23a98@github.com>
Message-ID: <2qAa9KFCjDTG3KCSRvJd_wXt9v_tHetQwLz5EehyFk4=.8cc615f4-93d3-4aa1-a36a-22dc3e8af367@github.com>

On Fri, 13 Jun 2025 15:21:38 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Documenting a suggestion for `float` arguments.

This pull request has now been integrated.

Changeset: 26848a7d
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/26848a7d6ce4c573b679a690fd36e6d7082243f6
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8358804: Improve the API Note of BigDecimal.valueOf(double)

Reviewed-by: bpb, darcy, iris

-------------

PR: https://git.openjdk.org/jdk/pull/25805

From swen at openjdk.org  Sat Jun 14 11:53:48 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 14 Jun 2025 11:53:48 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v22]
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: <LF8JdVZBql7LjaNBIIxwUhI2JZeGUkLLIXqCDeA16Ns=.e962e4a6-bb4b-4bc7-aea8-8c6dfd86173d@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 41 commits:

 - Merge remote-tracking branch 'origin/optim_parse_int_long_202501' into optim_parse_int_long_202501
 - 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
 - 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
 - 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
 - ... and 31 more: https://git.openjdk.org/jdk/compare/26848a7d...f2920e0a

-------------

Changes: https://git.openjdk.org/jdk/pull/22919/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=21
  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 duke at openjdk.org  Sat Jun 14 16:47:29 2025
From: duke at openjdk.org (ExE Boss)
Date: Sat, 14 Jun 2025 16:47:29 GMT
Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString
In-Reply-To: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
References: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
Message-ID: <Uq33oKjF5gjqMXpMQG7CNOTN4TLkPB0GVWXu2v4gY5U=.06d53388-3327-4611-a363-9de8d1ead14a@github.com>

On Tue, 7 Jan 2025 10:39:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In PR #22928, UUID introduced long-based vectorized hexadecimal to string conversion, which can also be used in Integer::toHexString and Long::toHexString to eliminate table lookups. The benefit of eliminating table lookups is that the performance is better when cache misses occur.

src/java.base/share/classes/java/util/UUID.java line 472:

> 470: 
> 471:         // Although the UUID byte ordering is defined to be big-endian, ByteArrayLittleEndian is used here to optimize
> 472:         // for the most common architectures. hex8 reverses the order internally.

No?longer the?case:
Suggestion:

        // Although the UUID byte ordering is defined to be big-endian, ByteArrayLittleEndian is used here to optimize
        // for the most common architectures.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22942#discussion_r2147022803

From duke at openjdk.org  Sat Jun 14 18:16:46 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Sat, 14 Jun 2025 18:16:46 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page [v2]
In-Reply-To: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
Message-ID: <vtzCxee8lD0LksjUarFidGRyNLyKnExWzPCLhMFIId8=.ecc3eab6-34d3-472e-a05c-d7f5c3f84f51@github.com>

> Please review my PR. This PR includes the following:
> 
> - [x] Fix a small typo in a word and copyright.
> - [x] Enhance description for `--target-platform`.
> - [x] Rearrange `jmod create` example from basic to complex.

Ana Maria Mihalceanu has updated the pull request incrementally with two additional commits since the last revision:

 - Fix whitespaces.
 - Update description of commands as per code review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25772/files
  - new: https://git.openjdk.org/jdk/pull/25772/files/71cb672e..b6a9bc8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25772&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25772&range=00-01

  Stats: 9 lines in 1 file changed: 1 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25772/head:pull/25772

PR: https://git.openjdk.org/jdk/pull/25772

From duke at openjdk.org  Sat Jun 14 18:16:47 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Sat, 14 Jun 2025 18:16:47 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page [v2]
In-Reply-To: <o7RDH55N6lVO_SrAJ5pFnjDJffcX4YKPOUgOgTjPrEc=.d0d98022-c3c8-468b-a491-e2131ce3b76b@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
 <o7RDH55N6lVO_SrAJ5pFnjDJffcX4YKPOUgOgTjPrEc=.d0d98022-c3c8-468b-a491-e2131ce3b76b@github.com>
Message-ID: <3UYa1-r6q2-9cZW3Q8Vss_AaQ7kpdV62vtLUZDuD6nA=.53a6acd1-4c55-405e-8d3e-7d20e105ce6e@github.com>

On Fri, 13 Jun 2025 17:07:20 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Ana Maria Mihalceanu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix whitespaces.
>>  - Update description of commands as per code review
>
> src/jdk.jlink/share/man/jmod.md line 183:
> 
>> 181: `--target-platform` *platform*
>> 182: :   Specifies the target platform. The value is a string that identifies
>> 183:     the platform this module is intended for, typically in the form `<os>-<arch>`.
> 
> Consider: "The value is a string identifying the module's intended platform, typically of the form `<os>-<arch>`.

Thank you for the suggestion, Iris. I've incorporated it.

> src/jdk.jlink/share/man/jmod.md line 220:
> 
>> 218:     deprecated, deprecated-for-removal, or incubating.
>> 219: 
>> 220: ## jmod Create Example
> 
> "Example" -> "Examples"

Well spotted. Thank you ? .

> src/jdk.jlink/share/man/jmod.md line 222:
> 
>> 220: ## jmod Create Example
>> 221: 
>> 222: The basic manner to create a JMOD file is by including only compiled classes:
> 
> I"m not sure what this is supposed to describe, perhaps something like this is more clear:  "Create a JMOD file containing only compiled classes:".
> 
> Whatever you choose should be parallel to the descriptions of the other create examples.  (My later comments are parallel to my suggestion for this line.)

I followed the pattern you suggested. Thank you.

> src/jdk.jlink/share/man/jmod.md line 228:
> 
>> 226: ```
>> 227: 
>> 228: To ensure reproducible artifacts, the following command creates
> 
> Is it necessary to provide a reason to use this option rather than just describe what the example does?  For parallelization, I'd retain the text in old line 231.

Thought it would be good to provide a reason for _why_ as well. But will keep the pattern for describing the command.

> src/jdk.jlink/share/man/jmod.md line 237:
> 
>> 235: 
>> 236: The command below creates a platform-specific JMOD file, bundling class files,
>> 237: user-editable configuration files, header files, native commands and libraries:
> 
> Your description for the more complex command line should either list all or none of the options.
> 
> If you chose the "none" approach, consider "Create a platform-specific JMOD file containing multiple artifacts."
> 
> If you chose the "all" approach, you'll need to add references to the  options on line 242, e.g. "Create a platform-specific JMOD file containing class files, user-editable configuration files, header files, ... ".

Thank you for the suggestions. I preferred to go ahead with _all_ approach. Can you please take a look again at the changes?

Thank you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2147082608
PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2147083353
PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2147086816
PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2147087912
PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2147089570

From swen at openjdk.org  Sun Jun 15 05:53:26 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 15 Jun 2025 05:53:26 GMT
Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString
 [v2]
In-Reply-To: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
References: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
Message-ID: <TwdDJGVcdwoL0rZFfzm_aeXcKiQN9KZ6uCD6v0Okk8A=.4737a2ee-1169-4b6b-bb5c-63a0cad0defe@github.com>

> In PR #22928, UUID introduced long-based vectorized hexadecimal to string conversion, which can also be used in Integer::toHexString and Long::toHexString to eliminate table lookups. The benefit of eliminating table lookups is that the performance is better when cache misses occur.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/util/UUID.java
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22942/files
  - new: https://git.openjdk.org/jdk/pull/22942/files/6f491ced..9b9bfb1d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22942&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22942&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22942/head:pull/22942

PR: https://git.openjdk.org/jdk/pull/22942

From markus at headcrashing.eu  Sun Jun 15 16:08:38 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Sun, 15 Jun 2025 18:08:38 +0200
Subject: Best Practice for Busy Waiting in Java
Message-ID: <8a6b6d84-c0a7-4892-847c-71277d2f50af@headcrashing.eu>

Recently I was asked by a programmer, what to do if there simply is no 
other way than actually busy-wait.

I see several options:

* Do nothing: Costs valuable CPU time and increases carbon footprint.

* Do a power-nap: Thread.sleep(1)

* Be fair: Thread.yield() gives other threads a chance to execute in 
this time slot.

* Be eco-friendly: Thread.onSpinWait() could reduce carbon footprint.

* A combination of that, like "Thread.yield(); Thread.onSpinWait();"

As all of that has its pros and cons, and as all of that works 
differently on each hardware platform, I do wonder if there is some 
common sense / best practice for busy wait (other than "Replace it using 
async") in the core-libs team?

Thanks!

-Markus




From archie.cobbs at gmail.com  Sun Jun 15 16:40:50 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Sun, 15 Jun 2025 11:40:50 -0500
Subject: Best Practice for Busy Waiting in Java
In-Reply-To: <8a6b6d84-c0a7-4892-847c-71277d2f50af@headcrashing.eu>
References: <8a6b6d84-c0a7-4892-847c-71277d2f50af@headcrashing.eu>
Message-ID: <CANSoFxtKJkQbFsq5+gmdDb=cQ_7pv=ZGJGqV_XZ0FxFyX5wX9g@mail.gmail.com>

Just MHO...

This is kind of like asking "What's the best way to waste electricity?"

It's a nebulous question until you specify what "best" means in this odd
scenario....

-Archie

On Sun, Jun 15, 2025 at 11:09?AM Markus KARG <markus at headcrashing.eu> wrote:

> Recently I was asked by a programmer, what to do if there simply is no
> other way than actually busy-wait.
>
> I see several options:
>
> * Do nothing: Costs valuable CPU time and increases carbon footprint.
>
> * Do a power-nap: Thread.sleep(1)
>
> * Be fair: Thread.yield() gives other threads a chance to execute in
> this time slot.
>
> * Be eco-friendly: Thread.onSpinWait() could reduce carbon footprint.
>
> * A combination of that, like "Thread.yield(); Thread.onSpinWait();"
>
> As all of that has its pros and cons, and as all of that works
> differently on each hardware platform, I do wonder if there is some
> common sense / best practice for busy wait (other than "Replace it using
> async") in the core-libs team?
>
> Thanks!
>
> -Markus
>
>
>
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250615/ecee4a18/attachment-0001.htm>

From markus at headcrashing.eu  Sun Jun 15 16:49:52 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Sun, 15 Jun 2025 18:49:52 +0200
Subject: Best Practice for Busy Waiting in Java
In-Reply-To: <CANSoFxtKJkQbFsq5+gmdDb=cQ_7pv=ZGJGqV_XZ0FxFyX5wX9g@mail.gmail.com>
References: <8a6b6d84-c0a7-4892-847c-71277d2f50af@headcrashing.eu>
 <CANSoFxtKJkQbFsq5+gmdDb=cQ_7pv=ZGJGqV_XZ0FxFyX5wX9g@mail.gmail.com>
Message-ID: <de2779e4-2b62-488d-88ce-7e1c20d886be@headcrashing.eu>

Seems you misunderstood my question. It was *not* what is best to do. It 
was: "Does the core-libs team have a common-sense / best practice for 
busy-wait.". The latter is a clear and concise question, and the answer 
could be as simple as "yes" or "no".

Am 15.06.2025 um 18:40 schrieb Archie Cobbs:
> Just MHO...
>
> This is kind of like asking "What's the best way to waste electricity?"
>
> It's a nebulous question until you specify what "best" means in this 
> odd scenario....
>
> -Archie
>
> On Sun, Jun 15, 2025 at 11:09?AM Markus KARG <markus at headcrashing.eu> 
> wrote:
>
>     Recently I was asked by a programmer, what to do if there simply
>     is no
>     other way than actually busy-wait.
>
>     I see several options:
>
>     * Do nothing: Costs valuable CPU time and increases carbon footprint.
>
>     * Do a power-nap: Thread.sleep(1)
>
>     * Be fair: Thread.yield() gives other threads a chance to execute in
>     this time slot.
>
>     * Be eco-friendly: Thread.onSpinWait() could reduce carbon footprint.
>
>     * A combination of that, like "Thread.yield(); Thread.onSpinWait();"
>
>     As all of that has its pros and cons, and as all of that works
>     differently on each hardware platform, I do wonder if there is some
>     common sense / best practice for busy wait (other than "Replace it
>     using
>     async") in the core-libs team?
>
>     Thanks!
>
>     -Markus
>
>
>
>
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250615/4ddd6d2c/attachment.htm>

From chen.l.liang at oracle.com  Sun Jun 15 20:42:31 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sun, 15 Jun 2025 20:42:31 +0000
Subject: Best Practice for Busy Waiting in Java
In-Reply-To: <de2779e4-2b62-488d-88ce-7e1c20d886be@headcrashing.eu>
References: <8a6b6d84-c0a7-4892-847c-71277d2f50af@headcrashing.eu>
 <CANSoFxtKJkQbFsq5+gmdDb=cQ_7pv=ZGJGqV_XZ0FxFyX5wX9g@mail.gmail.com>
 <de2779e4-2b62-488d-88ce-7e1c20d886be@headcrashing.eu>
Message-ID: <SJ2PR10MB7669E657CF4E976B54F5F122A271A@SJ2PR10MB7669.namprd10.prod.outlook.com>

Not a concurrency professional, but my first impression is whether to yield or spin depends on how costly the task you are waiting is - I know yield involves a context switch and can be problematic for small waits.

In addition, in Java, many blocking happens in a way users cannot control - for example, class initialization. Those might be bigger bottlenecks compared to the explicit busy waits.

Chen


Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Markus KARG <markus at headcrashing.eu>
Sent: Sunday, June 15, 2025 11:49:52 AM
To: Archie Cobbs <archie.cobbs at gmail.com>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: Best Practice for Busy Waiting in Java


Seems you misunderstood my question. It was *not* what is best to do. It was: "Does the core-libs team have a common-sense / best practice for busy-wait.". The latter is a clear and concise question, and the answer could be as simple as "yes" or "no".

Am 15.06.2025 um 18:40 schrieb Archie Cobbs:
Just MHO...

This is kind of like asking "What's the best way to waste electricity?"

It's a nebulous question until you specify what "best" means in this odd scenario....

-Archie

On Sun, Jun 15, 2025 at 11:09?AM Markus KARG <markus at headcrashing.eu<mailto:markus at headcrashing.eu>> wrote:
Recently I was asked by a programmer, what to do if there simply is no
other way than actually busy-wait.

I see several options:

* Do nothing: Costs valuable CPU time and increases carbon footprint.

* Do a power-nap: Thread.sleep(1)

* Be fair: Thread.yield() gives other threads a chance to execute in
this time slot.

* Be eco-friendly: Thread.onSpinWait() could reduce carbon footprint.

* A combination of that, like "Thread.yield(); Thread.onSpinWait();"

As all of that has its pros and cons, and as all of that works
differently on each hardware platform, I do wonder if there is some
common sense / best practice for busy wait (other than "Replace it using
async") in the core-libs team?

Thanks!

-Markus





--
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250615/cb96a8c8/attachment-0001.htm>

From kbarrett at openjdk.org  Mon Jun 16 07:09:39 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 16 Jun 2025 07:09:39 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v11]
In-Reply-To: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
Message-ID: <RHurPYBFXHy5WRNAU3Gw026di7-xtOox6ftoN9sxcX0=.e96117f3-ba8f-4365-a53e-92d003f5d92d@github.com>

> Please review this change which adds a native method providing the
> implementation of Reference::get.  Referece::get is an intrinsic candidate, so
> this native method implementation is only used when the intrinsic is not.
> 
> Currently there is intrinsic support by the interpreter, C1, C2, and graal,
> which are always used.  With this change we can later remove all the
> per-platform interpreter intrinsic implementations, and might also remove the
> C1 intrinsic implementation.
> 
> Testing:
> (1) mach5 tier1-6 normal (so using all the existing intrinsics).
> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:

 - Merge branch 'master' into native-reference-get
 - add pseudo-native entry for Reference.get0
 - tidy CallGenerator lookup in Compile ctor
 - fix comment alignment
 - Merge branch 'master' into native-reference-get
 - make private native Reference.get0 the intrinsic
 - Merge branch 'master' into native-reference-get
 - Merge branch 'master' into native-reference-get
 - use new waitForRefProc, some tidying
 - Merge branch 'master' into native-reference-get
 - ... and 7 more: https://git.openjdk.org/jdk/compare/594b4b31...877e64ca

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24315/files
  - new: https://git.openjdk.org/jdk/pull/24315/files/46ba079f..877e64ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=09-10

  Stats: 39280 lines in 872 files changed: 30089 ins; 5915 del; 3276 mod
  Patch: https://git.openjdk.org/jdk/pull/24315.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24315/head:pull/24315

PR: https://git.openjdk.org/jdk/pull/24315

From vyazici at openjdk.org  Mon Jun 16 07:29:43 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 16 Jun 2025 07:29:43 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v4]
In-Reply-To: <0r4lN4voPGXnF1IPlmMGgdyZd54Y4a5GdOsngNbSGlY=.03c9a53f-b044-44d3-affa-4542a7711d8c@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
 <0r4lN4voPGXnF1IPlmMGgdyZd54Y4a5GdOsngNbSGlY=.03c9a53f-b044-44d3-affa-4542a7711d8c@github.com>
Message-ID: <hZ604vk0v1SI0nglx9lAGDH4A0ljfgAZBBxD0fVFfPE=.fd2e67cc-8454-4b00-86ed-7dbc2c18851c@github.com>

On Tue, 3 Jun 2025 20:09:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix missing `java.io.Reader` import in `Ktab`
>
> I was thinking if someone made a typo for "stdin.encoding" and then it unknowingly defaults to the fallback. Turned out it immediately fails with "java.lang.IllegalArgumentException: Null charset name" so I think it should be OK.

@naotoj, @turbanoff, @wangweij, @plummercj, @AlanBateman, thanks so much for the reviews.

`tier1,2,3` pass ? results are attached to the ticket.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2969879685

From vyazici at openjdk.org  Mon Jun 16 07:29:44 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 16 Jun 2025 07:29:44 GMT
Subject: Integrated: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <2bZxFXAIgff0dW80SQs1nnYNEarkBmhThnJ4pkmHre4=.de088625-d9ef-442d-9be5-70725a6000f6@github.com>

On Fri, 30 May 2025 11:07:30 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

This pull request has now been integrated.

Changeset: eacfcd86
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eacfcd86d38f4acf0165275a42d246ba6c5fae56
Stats:     130 lines in 11 files changed: 33 ins; 28 del; 69 mod

8357995: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [core]

Reviewed-by: naoto, cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/25544

From per-ake.minborg at oracle.com  Mon Jun 16 10:22:42 2025
From: per-ake.minborg at oracle.com (Per-Ake Minborg)
Date: Mon, 16 Jun 2025 10:22:42 +0000
Subject: Best Practice for Busy Waiting in Java
In-Reply-To: <SJ2PR10MB7669E657CF4E976B54F5F122A271A@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <8a6b6d84-c0a7-4892-847c-71277d2f50af@headcrashing.eu>
 <CANSoFxtKJkQbFsq5+gmdDb=cQ_7pv=ZGJGqV_XZ0FxFyX5wX9g@mail.gmail.com>
 <de2779e4-2b62-488d-88ce-7e1c20d886be@headcrashing.eu>
 <SJ2PR10MB7669E657CF4E976B54F5F122A271A@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <SA1PR10MB7832C9FE08B822E090C61743DA70A@SA1PR10MB7832.namprd10.prod.outlook.com>

Hi Markus, and thank you for your question, which I think is a very relevant one.

There is no silver bullet here. It all depends on the problem at hand. One of the major questions to ask is what the aim of the solution is: are you optimizing latency, throughput, power efficiency, fairness, a certain SLA etc.

If you have considered asynchronous programming, I would encourage you to instead take a look at virtual threads, which provide a much more robust programming model. I think this is, indeed, a best practice approach in this type of choices.

If you are dealing with latency sensitive stuff, sometimes starting out with a busy wait (calling Thread.onSpinWait()) and then progressively backing off to yield() and wait() could be a good strategy. This can be combined with thread pinning and CPU isolation on the OS level to get improved latency metrics. Sometimes, event loops are a good choice in this domain.

Best, Per Minborg
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Chen Liang <chen.l.liang at oracle.com>
Sent: Sunday, June 15, 2025 10:42 PM
To: Markus KARG <markus at headcrashing.eu>; Archie Cobbs <archie.cobbs at gmail.com>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: Best Practice for Busy Waiting in Java

Not a concurrency professional, but my first impression is whether to yield or spin depends on how costly the task you are waiting is - I know yield involves a context switch and can be problematic for small waits.

In addition, in Java, many blocking happens in a way users cannot control - for example, class initialization. Those might be bigger bottlenecks compared to the explicit busy waits.

Chen


Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Markus KARG <markus at headcrashing.eu>
Sent: Sunday, June 15, 2025 11:49:52 AM
To: Archie Cobbs <archie.cobbs at gmail.com>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: Best Practice for Busy Waiting in Java


Seems you misunderstood my question. It was *not* what is best to do. It was: "Does the core-libs team have a common-sense / best practice for busy-wait.". The latter is a clear and concise question, and the answer could be as simple as "yes" or "no".

Am 15.06.2025 um 18:40 schrieb Archie Cobbs:
Just MHO...

This is kind of like asking "What's the best way to waste electricity?"

It's a nebulous question until you specify what "best" means in this odd scenario....

-Archie

On Sun, Jun 15, 2025 at 11:09?AM Markus KARG <markus at headcrashing.eu<mailto:markus at headcrashing.eu>> wrote:
Recently I was asked by a programmer, what to do if there simply is no
other way than actually busy-wait.

I see several options:

* Do nothing: Costs valuable CPU time and increases carbon footprint.

* Do a power-nap: Thread.sleep(1)

* Be fair: Thread.yield() gives other threads a chance to execute in
this time slot.

* Be eco-friendly: Thread.onSpinWait() could reduce carbon footprint.

* A combination of that, like "Thread.yield(); Thread.onSpinWait();"

As all of that has its pros and cons, and as all of that works
differently on each hardware platform, I do wonder if there is some
common sense / best practice for busy wait (other than "Replace it using
async") in the core-libs team?

Thanks!

-Markus





--
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250616/a70e5781/attachment-0001.htm>

From mli at openjdk.org  Mon Jun 16 10:23:39 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 16 Jun 2025 10:23:39 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: <XpqzxQTcnJFGXfc0DKgvue4GCMUN3Py-eY6DJanaotk=.8bc03de9-fec3-46ec-a916-5000444392ef@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'll close this pr, as seems to us it's also helpful to push the jdk vendors to support sleef when they release.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2975981848

From mli at openjdk.org  Mon Jun 16 10:23:40 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 16 Jun 2025 10:23:40 GMT
Subject: Withdrawn: 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: <M1JLNKEjffaJl-N4V6QqDZyV-POlNcrjfnaFYZVoHSw=.3fd00c07-fdb7-47df-9a6f-ab329729d743@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!

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24914

From markus at headcrashing.eu  Mon Jun 16 11:09:45 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Mon, 16 Jun 2025 13:09:45 +0200
Subject: Best Practice for Busy Waiting in Java
In-Reply-To: <SA1PR10MB7832C9FE08B822E090C61743DA70A@SA1PR10MB7832.namprd10.prod.outlook.com>
References: <8a6b6d84-c0a7-4892-847c-71277d2f50af@headcrashing.eu>
 <CANSoFxtKJkQbFsq5+gmdDb=cQ_7pv=ZGJGqV_XZ0FxFyX5wX9g@mail.gmail.com>
 <de2779e4-2b62-488d-88ce-7e1c20d886be@headcrashing.eu>
 <SJ2PR10MB7669E657CF4E976B54F5F122A271A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <SA1PR10MB7832C9FE08B822E090C61743DA70A@SA1PR10MB7832.namprd10.prod.outlook.com>
Message-ID: <e7078f29-a288-4ba8-a386-33c72b46109f@headcrashing.eu>

Thank you, everybody, for your kind input!


Having said that, I fully agree with all your proposals, but need to 
say: I already knew them, and it was **not** what I actually asked for. 
To repeat: "Is there a *best practice*". If the question is unclear, let 
me rephrase it using an example:


"Is there a document that contains a short and simple rule set that we 
(the core-libs contributors) apply in busy-wait cases BY DEFAULT when we 
do *not* decide to explicitly optimize for any special case?"


It could look like this:


BUSY-WAIT BEST PRACICE


In case you MUST use busy-wait, apply the following rules:


* NEVER have EMPTY busy-wait loops, but ALWAYS put Thread.onSpinWait() 
into it. The performance drop is negligible but the CO2 footprint is 
considerably smaller.

* IF it is acceptable for the waiting thread to not have the *absolute* 
maximum throughput, put Thread.yield() before Thread.onSpinWait() in the 
busy-wait loop, so CPU cores are more efficiently used.

* Never use Thread.sleep() in busy-wait loops.

* If possible, pin current thread to current CPU core to prevent 
inefficient context switches.

* ...more rules...


THAT is what my question is targeting! :-)


Thanks!

-Markus


Am 16.06.2025 um 12:22 schrieb Per-Ake Minborg:
> Hi Markus, and thank?you for your question, which I think is a very 
> relevant?one.
>
> There is no silver bullet here. It all depends on the problem at hand. 
> One of the major questions to ask is what the aim of the solution is: 
> are you optimizing latency, throughput, power efficiency, fairness, a 
> certain SLA etc.
>
> If you have considered asynchronous programming, I would encourage?you 
> to instead take a?look at virtual threads, which provide a much more 
> robust programming model. I think this is, indeed, a best practice 
> approach in this type of choices.
>
> If you are dealing with latency sensitive stuff, sometimes starting 
> out with a busy wait (calling Thread.onSpinWait()) and then 
> progressively backing off to yield() and wait() could be a good 
> strategy. This can be combined with thread pinning and CPU isolation 
> on the OS level to get improved latency metrics. Sometimes, event 
> loops are a good choice in this domain.
>
> Best, Per Minborg
> ------------------------------------------------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of 
> Chen Liang <chen.l.liang at oracle.com>
> *Sent:* Sunday, June 15, 2025 10:42 PM
> *To:* Markus KARG <markus at headcrashing.eu>; Archie Cobbs 
> <archie.cobbs at gmail.com>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: Best Practice for Busy Waiting in Java
> Not a concurrency professional, but my first impression is whether to 
> yield or spin depends on how costly the task you are waiting is - I 
> know yield involves a context switch and can be problematic for small 
> waits.
>
> In addition, in Java, many blocking happens in a way users cannot 
> control - for example, class initialization. Those might be bigger 
> bottlenecks compared to the explicit busy waits.
>
> Chen
>
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> ------------------------------------------------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of 
> Markus KARG <markus at headcrashing.eu>
> *Sent:* Sunday, June 15, 2025 11:49:52 AM
> *To:* Archie Cobbs <archie.cobbs at gmail.com>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: Best Practice for Busy Waiting in Java
>
> Seems you misunderstood my question. It was *not* what is best to do. 
> It was: "Does the core-libs team have a common-sense / best practice 
> for busy-wait.". The latter is a clear and concise question, and the 
> answer could be as simple as "yes" or "no".
>
> Am 15.06.2025 um 18:40 schrieb Archie Cobbs:
>> Just MHO...
>>
>> This is kind of like asking "What's the best way to waste electricity?"
>>
>> It's a nebulous question until you specify what "best" means in this 
>> odd scenario....
>>
>> -Archie
>>
>> On Sun, Jun 15, 2025 at 11:09?AM Markus KARG <markus at headcrashing.eu 
>> <mailto:markus at headcrashing.eu>> wrote:
>>
>>     Recently I was asked by a programmer, what to do if there simply
>>     is no
>>     other way than actually busy-wait.
>>
>>     I see several options:
>>
>>     * Do nothing: Costs valuable CPU time and increases carbon footprint.
>>
>>     * Do a power-nap: Thread.sleep(1)
>>
>>     * Be fair: Thread.yield() gives other threads a chance to execute in
>>     this time slot.
>>
>>     * Be eco-friendly: Thread.onSpinWait() could reduce carbon footprint.
>>
>>     * A combination of that, like "Thread.yield(); Thread.onSpinWait();"
>>
>>     As all of that has its pros and cons, and as all of that works
>>     differently on each hardware platform, I do wonder if there is some
>>     common sense / best practice for busy wait (other than "Replace
>>     it using
>>     async") in the core-libs team?
>>
>>     Thanks!
>>
>>     -Markus
>>
>>
>>
>>
>>
>> -- 
>> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250616/de4870ea/attachment-0001.htm>

From alan.bateman at oracle.com  Mon Jun 16 15:23:02 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Jun 2025 16:23:02 +0100
Subject: Best Practice for Busy Waiting in Java
In-Reply-To: <e7078f29-a288-4ba8-a386-33c72b46109f@headcrashing.eu>
References: <8a6b6d84-c0a7-4892-847c-71277d2f50af@headcrashing.eu>
 <CANSoFxtKJkQbFsq5+gmdDb=cQ_7pv=ZGJGqV_XZ0FxFyX5wX9g@mail.gmail.com>
 <de2779e4-2b62-488d-88ce-7e1c20d886be@headcrashing.eu>
 <SJ2PR10MB7669E657CF4E976B54F5F122A271A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <SA1PR10MB7832C9FE08B822E090C61743DA70A@SA1PR10MB7832.namprd10.prod.outlook.com>
 <e7078f29-a288-4ba8-a386-33c72b46109f@headcrashing.eu>
Message-ID: <33147cf1-307e-4bc0-8284-6ce8f685cb01@oracle.com>

On 16/06/2025 12:09, Markus KARG wrote:
>
>
> In case you MUST use busy-wait, apply the following rules:
>
>
> * NEVER have EMPTY busy-wait loops, but ALWAYS put Thread.onSpinWait() 
> into it. The performance drop is negligible but the CO2 footprint is 
> considerably smaller.
>
> * IF it is acceptable for the waiting thread to not have the 
> *absolute* maximum throughput, put Thread.yield() before 
> Thread.onSpinWait() in the busy-wait loop, so CPU cores are more 
> efficiently used.
>
> * Never use Thread.sleep() in busy-wait loops.
>
> * If possible, pin current thread to current CPU core to prevent 
> inefficient context switches.
>
> * ...more rules...
>
>
> THAT is what my question is targeting! :-)
>

It may be possible to provide some guidelines but I don't think they can 
be turned into rules, e.g. the NEVER example is challenged by methods 
that do atomic increment/add/etc. as this read+CAS in a tight loop. 
There are also examples that of tight loops to CAS an object to the add 
it to a list. The examples of onSpinWait in the JDK might give you some 
ideas, e.g. using it in conjunction with a max spin count before timed 
back off or parking. One thing to add to your list is virtual threads 
where it may be better to park rather than Thread.yield.

-Alan




From smarks at openjdk.org  Mon Jun 16 15:58:43 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 16 Jun 2025 15:58:43 GMT
Subject: Integrated: 8338140: (str) Add notes to String.trim and String.isEmpty
 pointing to newer APIs
In-Reply-To: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
References: <-62VRGWmJ5wYeAYcvn6jgvw6u7xD3pyCMhhjq0gvDKg=.b66ed991-bf2c-4950-a202-06c781e0269f@github.com>
Message-ID: <hutb70rmTP86pKxhMys1k8Oho42sfitXSL6VJzETthk=.0fb5f7d9-8a65-4936-80ad-230355223722@github.com>

On Wed, 11 Jun 2025 22:39:48 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Add a note to String.trim pointing to the String.strip family of methods.
> 
> Add notes cross-linking String.isBlank and String.isEmpty.

This pull request has now been integrated.

Changeset: 06d804a0
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/06d804a0f004f9403c7c12e1a9f2ca8775c639f7
Stats:     19 lines in 1 file changed: 9 ins; 4 del; 6 mod

8338140: (str) Add notes to String.trim and String.isEmpty pointing to newer APIs

Reviewed-by: naoto, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/25762

From gkrishnan at openjdk.org  Mon Jun 16 16:43:00 2025
From: gkrishnan at openjdk.org (Gautham Krishnan)
Date: Mon, 16 Jun 2025 16:43:00 GMT
Subject: RFR: 8294226: Document missing UnsupportedTemporalTypeException
Message-ID: <vQnDqeqwMBOd-ezhmNDl0eb09e90WRUCYrt9jz_Wii0=.78c4fe19-6ada-4475-a69e-2ff8a487e125@github.com>

Some methods in the java.time.chrono interfaces?ChronoLocalDate, ChronoLocalDateTime, and ChronoZonedDateTime?override methods from the java.time.temporal.Temporal interface that are documented to throw UnsupportedTemporalTypeException when given unsupported fields or units.

These overridden methods include:

with(TemporalField, long)

plus(long, TemporalUnit)

minus(long, TemporalUnit)

However, their Javadoc in the chrono interfaces does not mention the possibility of this exception, resulting in incomplete or inconsistent documentation. This contrasts with the parent Temporal interface, which explicitly documents the exception.

-------------

Commit messages:
 - Documenting missing UnsupportedTemporalTypeException

Changes: https://git.openjdk.org/jdk/pull/25836/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25836&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294226
  Stats: 10 lines in 3 files changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25836.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25836/head:pull/25836

PR: https://git.openjdk.org/jdk/pull/25836

From pminborg at openjdk.org  Mon Jun 16 16:58:09 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 16 Jun 2025 16:58:09 GMT
Subject: RFR: 8345292: Improve javadocs for MemorySegment::getStrings
 defining word boundary cases [v5]
In-Reply-To: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
References: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
Message-ID: <phBZll-SVauXppPx18CrOUu9JmwRsLDhOKdAeEVTUxA=.fa5a5068-a96e-4d61-89d8-fcd49bd5b6ba@github.com>

> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset charset)` method documentation with respect to multi-octet concerns.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Remove imp note
 - Add text on N octets

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25715/files
  - new: https://git.openjdk.org/jdk/pull/25715/files/4ea36452..5f5b1473

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25715&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25715&range=03-04

  Stats: 12 lines in 1 file changed: 8 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25715.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25715/head:pull/25715

PR: https://git.openjdk.org/jdk/pull/25715

From jlu at openjdk.org  Mon Jun 16 17:30:12 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 16 Jun 2025 17:30:12 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v6]
In-Reply-To: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
Message-ID: <2LfJux69m6hGFaX_B6-tMjT4v1pUQmgSWXAUjNB04KY=.278f9126-b008-4a26-b594-85f4cdc8a5fb@github.com>

> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
> 
> `testclasses.jar` is updated such that the two classes no longer extend Applet.
> 
> 
> $ javap fo\ o.class 
> public class fo o {
> }
> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
> public class ?? {
> }
> 
> 
> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
> 
> Additionally, the security APIs that were marked for removal are also removed from this test as well.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Review suggestion - read class file from memory as bytes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25703/files
  - new: https://git.openjdk.org/jdk/pull/25703/files/02c76c74..9e395b2f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25703&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25703&range=04-05

  Stats: 64 lines in 1 file changed: 0 ins; 53 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/25703.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25703/head:pull/25703

PR: https://git.openjdk.org/jdk/pull/25703

From jlu at openjdk.org  Mon Jun 16 17:30:12 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 16 Jun 2025 17:30:12 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v5]
In-Reply-To: <AaGpPwnSaIKPiuFxNN30n5Oj_y3WP6DUmbNT_jMF4l8=.f49cca8a-bd55-46a5-aab5-682413421187@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <lEK6--77fLT1fBhemFGaAXXNMuKuXogv9JNVK_V1PZQ=.b14543f4-ef63-4197-8d2b-d18626a4a0df@github.com>
 <AaGpPwnSaIKPiuFxNN30n5Oj_y3WP6DUmbNT_jMF4l8=.f49cca8a-bd55-46a5-aab5-682413421187@github.com>
Message-ID: <rPmkK9waHu4QiFk11zqI5nMedzrHlEYvg-aiN_rffYo=.50c3f104-fec6-4830-a5cf-9209848b837c@github.com>

On Fri, 13 Jun 2025 20:56:49 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review - Convert to JUnit, correct comment typo, remove 'Infra' methods
>
> test/jdk/jdk/internal/loader/URLClassPath/ClassnameCharTest.java line 57:
> 
>> 55:     static void setup() throws IOException {
>> 56:         var bytes = ClassFile.of().build(ClassDesc.of("fo o"), _ -> {});
>> 57:         try (JarOutputStream jos = new JarOutputStream(new FileOutputStream(JAR_PATH.toFile()))) {
> 
> Suggestion: The original test used testclasses.jar to provide two class files with invalid names packaged in a jar. Since you now dynamically construct the class files, there is no need to write them to disk as a jar. Why not have a Map<String,byte[]), mapping a resource path to bytes, to store all used class files in memory.

Thanks, I think we can make this simplification because the original version of this test used to test directly against a "fo o.class" binary file, and changed overtime to adapt the jar. (Thanks @jaikiran for confirming). I updated it such that we just read the class file bytes directly, and all JAR related logic is dropped. I did not put it in a map, since the second class is commented out, and we have been testing only "fo o" for quite some time now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25703#discussion_r2150503122

From rriggs at openjdk.org  Mon Jun 16 17:47:28 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 16 Jun 2025 17:47:28 GMT
Subject: RFR: 8294226: Document missing UnsupportedTemporalTypeException
In-Reply-To: <vQnDqeqwMBOd-ezhmNDl0eb09e90WRUCYrt9jz_Wii0=.78c4fe19-6ada-4475-a69e-2ff8a487e125@github.com>
References: <vQnDqeqwMBOd-ezhmNDl0eb09e90WRUCYrt9jz_Wii0=.78c4fe19-6ada-4475-a69e-2ff8a487e125@github.com>
Message-ID: <DJf9iY_iNvzFr11mFO6DY8Mo2UVtv87V0dsE16v3K9I=.d30ce50d-190f-421c-9c1d-b44e88fa1aea@github.com>

On Mon, 16 Jun 2025 16:36:43 GMT, Gautham Krishnan <gkrishnan at openjdk.org> wrote:

> Some methods in the java.time.chrono interfaces?ChronoLocalDate, ChronoLocalDateTime, and ChronoZonedDateTime?override methods from the java.time.temporal.Temporal interface that are documented to throw UnsupportedTemporalTypeException when given unsupported fields or units.
> 
> These overridden methods include:
> 
> with(TemporalField, long)
> 
> plus(long, TemporalUnit)
> 
> minus(long, TemporalUnit)
> 
> However, their Javadoc in the chrono interfaces does not mention the possibility of this exception, resulting in incomplete or inconsistent documentation. This contrasts with the parent Temporal interface, which explicitly documents the exception.

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25836#pullrequestreview-2932969154

From jlu at openjdk.org  Mon Jun 16 18:22:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 16 Jun 2025 18:22:31 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v3]
In-Reply-To: <hzCwNHUbtMWh_V3rtnMipAOj2_bB1UF-Sewy2kttvH4=.d29dac97-b7df-4a17-94ff-36c4ce8cbed1@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <-6TYWikmLNBtyQt6_xeJ8KoziHxA8Ijr067NIc740X0=.2f9e4cae-7f39-46b8-b3a9-f381fb2e0518@github.com>
 <JNEKtkhrEYnS1SvaSz7GhcS4FQGkQXma4nY_Wo0T18A=.3dce72d9-7250-4672-adad-13db79e3150c@github.com>
 <tCE4NXNXnwQro2lXxzJbDuJzrcTt3k2bNrR8wk54jX8=.6a749f99-e70b-426b-ad9d-e077c115f42d@github.com>
 <Tv8HMWAw2YxNwcjL3_8ZoELHZZHCI-RSeMNbN-NBU5g=.dac7959c-1d74-47c3-a283-fe212dcd3705@github.com>
 <hzCwNHUbtMWh_V3rtnMipAOj2_bB1UF-Sewy2kttvH4=.d29dac97-b7df-4a17-94ff-36c4ce8cbed1@github.com>
Message-ID: <vEAT8VpjJFBMyG87cz0gBcu2zwzPDOXuZWKksj_UPiw=.d2b9f24e-9411-4969-a261-e5415aa18498@github.com>

On Fri, 13 Jun 2025 19:34:40 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Ah got it, I see your point. We would have goten underflow in `ASCIIToBinaryConverter.doubleValue()` for some extreme cases without a check. 
>> 
>> Is there a specific example you have that requires the switch to the newer check? Adding a comment along those lines might be helpful. Actually, I thought DigitList caps `decimalAt` to Integer.MIN/MAX, so then the first check you had would have been fine. (Maybe I am missing something?)
>
> I don't have a specific example, so I've reverted to my original check. I'm a bit unsettled by the check for an extreme value later in `doubleValue()` comparing against `MIN_DECIMAL_EXPONENT - 1`

IMO, the original check you had is easier to understand what is happening without further context, so I prefer your switch back. 

I think we are fine from (negative) "extreme values" in `doubleValue()` because of the check you have implemented in the first place. i.e. we avoid any potential underflow from `int exp = decExponent - kDigits;`. I think we do need a comment to accompany the check. (Why do we check? why not check the max exponent value?)

Also, should the check be against `MIN_DECIMAL_EXPONENT - 1` for consistency with `doubleValue()`? (Functionally, I don't think it matters.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2150586388

From rriggs at openjdk.org  Mon Jun 16 18:28:30 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 16 Jun 2025 18:28:30 GMT
Subject: RFR: 8357089: Remove VFORK launch mechanism from Process
 implementation (linux)
In-Reply-To: <lg36ykgPsg2YFoiAxnovr7Ix3GPbUBYWFsjE8i5wl5s=.fe37a5a0-223a-4b8f-810f-e529420bf46b@github.com>
References: <lg36ykgPsg2YFoiAxnovr7Ix3GPbUBYWFsjE8i5wl5s=.fe37a5a0-223a-4b8f-810f-e529420bf46b@github.com>
Message-ID: <4CHpab3IB3mveJ_hudaDS9ubN2gMm_XkdB1ngkd345w=.d0aa67fb-3dae-499b-9815-f9c1115f7d66@github.com>

On Thu, 12 Jun 2025 04:11:15 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> (for JDK 26)
> 
> Note: This PR is a continuation of the old PR here: https://github.com/openjdk/jdk/pull/25260; had to close the old one since I had Skara problems after the JDK25 split-off.
> 
> See the companion CSR (https://bugs.openjdk.org/browse/JDK-8357090) for the ratio behind this removal.
> 
> Patch
> 
> - removes all code handling the VFORK mode.
> - removes or clarifies comments explaining use of vfork by the JVM.
> - we now print out an error message to stderr if the user still specifies -Djdk.lang.Process.launchMechanism=vfork.

src/java.base/unix/native/libjava/ProcessImpl_md.c line 60:

> 58:  * - then exec(2) the target binary
> 59:  *
> 60:  * On the OS-side are four ways to fork off:

I would mention the two ways that are implemented, only mentioning vfork after the supported mechanisms to inhibit someone wanting to go backwards.

src/java.base/unix/native/libjava/ProcessImpl_md.c line 86:

> 84:  *    powerful, but Linux-specific.
> 85:  *
> 86:  * D) posix_spawn(3): Where fork/vfork/clone all fork off the process and leave

I would downplay the OS launch options we don't use, only saying that vfork is dangerous (and a bit as to why) but there's no need to mention clone. And there's no need to mention the the deprecation or removal, when this is integrated its gone.

src/java.base/unix/native/libjava/childproc.c line 207:

> 205:     vector[count] = NULL;
> 206: }
> 207: 

This mode should be mentioned in the CSR, even if no-one knew it was there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25768#discussion_r2150580874
PR Review Comment: https://git.openjdk.org/jdk/pull/25768#discussion_r2150578422
PR Review Comment: https://git.openjdk.org/jdk/pull/25768#discussion_r2150587579

From rriggs at openjdk.org  Mon Jun 16 18:35:37 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 16 Jun 2025 18:35:37 GMT
Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(),
 use FD_CLOEXEC instead of close() [v4]
In-Reply-To: <vtw1acKMe69fcntcaQ_PYt6_AneS7YfiF18KfN9KAPg=.aa646f10-08d3-421e-933c-5c80906613c5@github.com>
References: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
 <vtw1acKMe69fcntcaQ_PYt6_AneS7YfiF18KfN9KAPg=.aa646f10-08d3-421e-933c-5c80906613c5@github.com>
Message-ID: <VfzvYk3aWQKY3dqapq5g7Tki57EcVt7OAH2M2ttzuMg=.e583792d-f8d3-41b5-a0d0-9c3f92aaa33e@github.com>

On Fri, 13 Jun 2025 06:40:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi, please consider the following patch.
>> 
>> This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc.
>> 
>> This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens).
>> 
>> Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409
>> 
>> This patch also fixes two subtle bugs:
>> - we didn't check the return value of the close() inside closeAllFileDescriptors
>> - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it)
>> 
>> ----
>> 
>> Testing:
>> 
>> We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC.
>> 
>> - in the parent JVM, the test opens a file in native code without FD_CLOEXEC
>> - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open
>> 
>> I verified that the test correctly detects a broken implementation that leaks file descriptors. 
>> 
>> I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX).
>> 
>> I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green.
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close-
>  - Merge branch 'openjdk:master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close-
>  - Merge branch 'openjdk:master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close-
>  - close dir fd on fcntl error
>  - Mark fds with cloexec, plus test

Marked as reviewed by rriggs (Reviewer).

test/jdk/java/lang/ProcessBuilder/FDLeakTest/FDLeakTest.java line 59:

> 57:     //
> 58:     // What should happen: In the child process, between the initial fork and the exec of the target binary, we should
> 59:     // close all filedescriptors that are not stdin/out/err. If that works, the child process should not see any other

Can you shorten the long lines to < 100 chars. It makes side-by-side reviews easier.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25301#pullrequestreview-2933119140
PR Review Comment: https://git.openjdk.org/jdk/pull/25301#discussion_r2150613567

From kbarrett at openjdk.org  Mon Jun 16 18:44:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 16 Jun 2025 18:44:52 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v5]
In-Reply-To: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
Message-ID: <uCLXlynWcDwXg-be0n-QK-ruo3yUwztpiPcp3lY3Rd4=.de016ec1-4709-4f11-af62-c6ecf1467975@github.com>

> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
> use java.lang.ref.Cleaner.
> 
> This change is algorithmically similar to the two previous versions:
> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
> Bits::reserveMemory(). For both of those versions and this change, a thread
> calls that function and tries to reserve some space. If it fails, then it
> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
> cleaned. If reservation still fails, then it invokes the GC to try to
> deactivate more cleaners for cleaning. After that GC it keeps trying the
> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
> eventually either succeeding or giving up and throwing OOME.
> 
> Retaining that algorithmic approach is one of the goals of this change, since
> it has been successfully in use since JDK 9 (and was originally developed and
> extensively tested in JDK 8).
> 
> The key to this approach is having a way to determine that deactivated
> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
> threads help the reference processor until there was no available work.
> JDK-8156500 waits for the reference processor to quiesce, relying on its
> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
> to do this, which is why this change rolls its own Cleaner-like mechanism from
> the underlying primitives. Like JDK-6857566, this change has waiting threads
> help with cleaning references. This was a potentially undesirable feature of
> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
> became internal-only somewhere around that time as well.) That's not a concern
> here, as the cleaners involved are only from DBB, and we know what they look
> like.
> 
> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
> being done off the reference processing thread, as it may be expensive and
> slow down enqueuing other pending references. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
> 
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there is no available work whil...

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Merge branch 'master' into direct-buffer-cleaner
 - Merge branch 'master' into direct-buffer-cleaner
 - Merge branch 'master' into direct-buffer-cleaner
 - add description of BufferCleaner class
 - exception handling in cleaner for backward consistency
 - detabify
 - move jdk.internal.nio.Cleaner to sun.nio
 - copyrights
 - remove java.nio use of jdk.internal.ref.Cleaner
 - add micros from Shipilev

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25289/files
  - new: https://git.openjdk.org/jdk/pull/25289/files/13bf6c2d..b59a2a9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25289&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25289&range=03-04

  Stats: 87936 lines in 1480 files changed: 55905 ins; 20394 del; 11637 mod
  Patch: https://git.openjdk.org/jdk/pull/25289.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25289/head:pull/25289

PR: https://git.openjdk.org/jdk/pull/25289

From alanb at openjdk.org  Mon Jun 16 18:51:32 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Jun 2025 18:51:32 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page [v2]
In-Reply-To: <vtzCxee8lD0LksjUarFidGRyNLyKnExWzPCLhMFIId8=.ecc3eab6-34d3-472e-a05c-d7f5c3f84f51@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
 <vtzCxee8lD0LksjUarFidGRyNLyKnExWzPCLhMFIId8=.ecc3eab6-34d3-472e-a05c-d7f5c3f84f51@github.com>
Message-ID: <kf6CLXJQepR0G5J5YqduJqoCGgvHCwyoXEWAU0hadKQ=.f061004f-d277-4a64-8c40-b7f13141e152@github.com>

On Sat, 14 Jun 2025 18:16:46 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> Please review my PR. This PR includes the following:
>> 
>> - [x] Fix a small typo in a word and copyright.
>> - [x] Enhance description for `--target-platform`.
>> - [x] Rearrange `jmod create` example from basic to complex.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix whitespaces.
>  - Update description of commands as per code review

src/jdk.jlink/share/man/jmod.md line 205:

> 203:       --libs lib --main-class com.greetings.Main
> 204:       --man-pages man --module-version 1.0
> 205:       --target-platform "macOS-aarch64" greetingsmod

Can you change it to "macos-aarch64" as it is case sensitive.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2150642310

From alanb at openjdk.org  Mon Jun 16 18:54:30 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Jun 2025 18:54:30 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page [v2]
In-Reply-To: <vtzCxee8lD0LksjUarFidGRyNLyKnExWzPCLhMFIId8=.ecc3eab6-34d3-472e-a05c-d7f5c3f84f51@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
 <vtzCxee8lD0LksjUarFidGRyNLyKnExWzPCLhMFIId8=.ecc3eab6-34d3-472e-a05c-d7f5c3f84f51@github.com>
Message-ID: <ptnxSz3m7XAmc1tOJZ1Ov2PrGOaBz9WHZ_PR-n0j6RM=.7ba9fb48-43a3-493b-a275-9405563f6ede@github.com>

On Sat, 14 Jun 2025 18:16:46 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> Please review my PR. This PR includes the following:
>> 
>> - [x] Fix a small typo in a word and copyright.
>> - [x] Enhance description for `--target-platform`.
>> - [x] Rearrange `jmod create` example from basic to complex.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix whitespaces.
>  - Update description of commands as per code review

src/jdk.jlink/share/man/jmod.md line 183:

> 181: `--target-platform` *platform*
> 182: :   Specifies the target platform. The value is a string identifying
> 183:     the module's intended platform, typically in the form `<os>-<arch>`.

Maybe we could say that it specifies the target platform when creating a JMOD file that is platform specific. The value is `<os>-<arch>` where `<os>` is the operating system and `<arch>` is the architecture. Examples values are ...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2150648312

From pavel.rappo at gmail.com  Mon Jun 16 19:43:47 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Mon, 16 Jun 2025 20:43:47 +0100
Subject: concurrency-discuss mailing list
In-Reply-To: <ae3c1a69-53d9-4c4c-87e4-82415ac7d204@oracle.com>
References: <ae3c1a69-53d9-4c4c-87e4-82415ac7d204@oracle.com>
Message-ID: <20250616194406.27080-1-pavel.rappo@gmail.com>

> For many years, concurrency-interest was the mailing list to discuss 
> j.u.concurrent and related topics. The mailing list was hosted on a 
> server maintained by Prof. Doug Lea. Sadly, the mailing list didn't 
> survive an OS upgrade and has been unavailable for some time.
> 
> A new mailing list concurrency-discuss at openjdk.org [1] has been created 
> to replace the old list.? It's a completely new list, the archives and 
> subscribers from the previous mailing list have not carried over. As the 
> name suggests, the mailing list is for discussion of the j.u.concurrent 
> API/implementation and related topics. It's not the place for support 
> questions.
>
> -Alan
>
> [1] https://mail.openjdk.org/mailman/listinfo/concurrency-discuss

Replying to a year-old email. There might be a way to get the late list's
archives back:

  https://mail.openjdk.org/pipermail/discuss/2025-June/006511.html

-Pavel

From duke at openjdk.org  Mon Jun 16 19:59:06 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Mon, 16 Jun 2025 19:59:06 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page [v3]
In-Reply-To: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
Message-ID: <4jexZv1gfiybYoApPujxPTvGgsiQLO439jkHE4-l_sE=.1052a952-30e1-4fb0-81f0-52166bcda313@github.com>

> Please review my PR. This PR includes the following:
> 
> - [x] Fix a small typo in a word and copyright.
> - [x] Enhance description for `--target-platform`.
> - [x] Rearrange `jmod create` example from basic to complex.

Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:

  Enhance --target-platform explanation.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25772/files
  - new: https://git.openjdk.org/jdk/pull/25772/files/b6a9bc8e..d52f2ce2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25772&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25772&range=01-02

  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25772/head:pull/25772

PR: https://git.openjdk.org/jdk/pull/25772

From duke at openjdk.org  Mon Jun 16 19:59:07 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Mon, 16 Jun 2025 19:59:07 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page [v2]
In-Reply-To: <ptnxSz3m7XAmc1tOJZ1Ov2PrGOaBz9WHZ_PR-n0j6RM=.7ba9fb48-43a3-493b-a275-9405563f6ede@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
 <vtzCxee8lD0LksjUarFidGRyNLyKnExWzPCLhMFIId8=.ecc3eab6-34d3-472e-a05c-d7f5c3f84f51@github.com>
 <ptnxSz3m7XAmc1tOJZ1Ov2PrGOaBz9WHZ_PR-n0j6RM=.7ba9fb48-43a3-493b-a275-9405563f6ede@github.com>
Message-ID: <q4_ngKuY7cbwiPKlLcW3RaOMP4zZrKVBMZ2MB6xlQfk=.38bee3b5-7ec7-457c-9842-b3bd837ca234@github.com>

On Mon, 16 Jun 2025 18:52:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ana Maria Mihalceanu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix whitespaces.
>>  - Update description of commands as per code review
>
> src/jdk.jlink/share/man/jmod.md line 183:
> 
>> 181: `--target-platform` *platform*
>> 182: :   Specifies the target platform. The value is a string identifying
>> 183:     the module's intended platform, typically in the form `<os>-<arch>`.
> 
> Maybe we could say that it specifies the target platform when creating a JMOD file that is platform specific. The value is `<os>-<arch>` where `<os>` is the operating system and `<arch>` is the architecture. Examples values are ...

Thank you for the suggestion. Below is an excerpt from the update. Please let me know if it works.

Specifies the target platform when creating a JMOD file intended for a specific operating system and architecture. The value should follow the format `<os>-<arch>`, where `<os>` is the operating system and `<arch>` is the hardware architecture. Example values include`linux-x64`, `windows-x64`, and `macos-aarch64`.

> src/jdk.jlink/share/man/jmod.md line 205:
> 
>> 203:       --libs lib --main-class com.greetings.Main
>> 204:       --man-pages man --module-version 1.0
>> 205:       --target-platform "macOS-aarch64" greetingsmod
> 
> Can you change it to "macos-aarch64" as it is case sensitive.

Thank you for spotting this. I updated both areas related to the target platform.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2150762624
PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2150757942

From naoto at openjdk.org  Mon Jun 16 20:37:32 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 16 Jun 2025 20:37:32 GMT
Subject: RFR: 8294226: Document missing UnsupportedTemporalTypeException
In-Reply-To: <vQnDqeqwMBOd-ezhmNDl0eb09e90WRUCYrt9jz_Wii0=.78c4fe19-6ada-4475-a69e-2ff8a487e125@github.com>
References: <vQnDqeqwMBOd-ezhmNDl0eb09e90WRUCYrt9jz_Wii0=.78c4fe19-6ada-4475-a69e-2ff8a487e125@github.com>
Message-ID: <zvVwUWbQhHBKgssBBVkeaJpmiJUrKTbFgH3s2MJg6RQ=.0db256a4-cdb2-4c6c-8740-8115fb57eb89@github.com>

On Mon, 16 Jun 2025 16:36:43 GMT, Gautham Krishnan <gkrishnan at openjdk.org> wrote:

> Some methods in the java.time.chrono interfaces?ChronoLocalDate, ChronoLocalDateTime, and ChronoZonedDateTime?override methods from the java.time.temporal.Temporal interface that are documented to throw UnsupportedTemporalTypeException when given unsupported fields or units.
> 
> These overridden methods include:
> 
> with(TemporalField, long)
> 
> plus(long, TemporalUnit)
> 
> minus(long, TemporalUnit)
> 
> However, their Javadoc in the chrono interfaces does not mention the possibility of this exception, resulting in incomplete or inconsistent documentation. This contrasts with the parent Temporal interface, which explicitly documents the exception.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25836#pullrequestreview-2933434612

From duke at openjdk.org  Mon Jun 16 21:19:45 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 16 Jun 2025 21:19:45 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v6]
In-Reply-To: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
Message-ID: <JdxWpCBHtTssvz1lu08gRSrJr3So7vxoi5hiopLlxLo=.3931a767-c13c-455a-b631-616cbbd250ff@github.com>

> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
> 
> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
> 
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  add comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25644/files
  - new: https://git.openjdk.org/jdk/pull/25644/files/c87a3ded..b7faa3b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25644&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25644&range=04-05

  Stats: 6 lines in 2 files changed: 3 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25644/head:pull/25644

PR: https://git.openjdk.org/jdk/pull/25644

From sherman at openjdk.org  Mon Jun 16 22:53:27 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 16 Jun 2025 22:53:27 GMT
Subject: RFR: 8191963: Path.equals() and File.equals() return true for two
 different files on Windows
In-Reply-To: <SajkurwYpwnPA2of1eJk47j813Xm7otCmkk5fDXrKGs=.ca848b55-4134-48fa-9d24-11e81d1871c2@github.com>
References: <SajkurwYpwnPA2of1eJk47j813Xm7otCmkk5fDXrKGs=.ca848b55-4134-48fa-9d24-11e81d1871c2@github.com>
Message-ID: <z1DoFnDNPm8fEgVppuSdzUrlsrmLAPio74vBKqUKskU=.fab6e229-73d0-4d99-939b-9f751b74181e@github.com>

On Thu, 12 Jun 2025 21:12:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replace logic in `java.io.WinNTFileSystems.compare(File,File)` with that from `sun.nio.fs.WindowsPath.compareTo(Path)`.

Just wondering how Windows implementation really behaves for its 'case-insensitive-comparing" for "\u0131 vs "I"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25788#issuecomment-2978408882

From vpetko at openjdk.org  Tue Jun 17 01:55:23 2025
From: vpetko at openjdk.org (Vladimir Petko)
Date: Tue, 17 Jun 2025 01:55:23 GMT
Subject: RFR: 8359735: [Ubuntu 25.10] java/lang/ProcessBuilder/Basic.java,
 java/lang/ProcessHandle/InfoTest.java fail due to rust-coreutils
Message-ID: <3_AaRZDHCFUzB5DnsdruJRqPPCqjn_ylYPOA2qOf8ws=.2f5ffd56-7ad1-401f-a14c-4ed121a51e59@github.com>

To accommodate systems like Ubuntu 25.10 that use Rust coreutils, this PR updates tests that previously assumed BusyBox was the only environment to use symlinks for core utilities.

Changes:
-   `java/lang/ProcessBuilder/Basic.java`: The test is updated to simply verify that `/bin/true `and `/bin/false` are symlinks, removing the hardcoded check for a /bin/busybox target.
 -  ` java/lang/ProcessHandle/InfoTest.java`: The test logic is relaxed. It now confirms that `/bin/sleep` is a symlink and then uses the symlink's target as the expected executable name.

-------------

Commit messages:
 - chore: update copyright year
 - fix: read filename of the symbolic link
 - fix: relax test condition for TrueExe and FalsExe

Changes: https://git.openjdk.org/jdk/pull/25838/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25838&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359735
  Stats: 9 lines in 2 files changed: 2 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25838.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25838/head:pull/25838

PR: https://git.openjdk.org/jdk/pull/25838

From stuefe at openjdk.org  Tue Jun 17 05:56:15 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 17 Jun 2025 05:56:15 GMT
Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(),
 use FD_CLOEXEC instead of close() [v5]
In-Reply-To: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
References: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
Message-ID: <-I5U1mBEeRCAMkb6dIINRoyifi9S6dm3Qh9d3japTt0=.a077c0c8-9d16-4788-9a21-72eb0a014406@github.com>

> Hi, please consider the following patch.
> 
> This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc.
> 
> This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens).
> 
> Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409
> 
> This patch also fixes two subtle bugs:
> - we didn't check the return value of the close() inside closeAllFileDescriptors
> - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it)
> 
> ----
> 
> Testing:
> 
> We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC.
> 
> - in the parent JVM, the test opens a file in native code without FD_CLOEXEC
> - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open
> 
> I verified that the test correctly detects a broken implementation that leaks file descriptors. 
> 
> I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX).
> 
> I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Update FDLeakTest.java - shorten comment lines

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25301/files
  - new: https://git.openjdk.org/jdk/pull/25301/files/dee75d88..0c59d6f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25301&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25301&range=03-04

  Stats: 10 lines in 1 file changed: 2 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/25301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25301/head:pull/25301

PR: https://git.openjdk.org/jdk/pull/25301

From stuefe at openjdk.org  Tue Jun 17 05:56:17 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 17 Jun 2025 05:56:17 GMT
Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(),
 use FD_CLOEXEC instead of close() [v4]
In-Reply-To: <VfzvYk3aWQKY3dqapq5g7Tki57EcVt7OAH2M2ttzuMg=.e583792d-f8d3-41b5-a0d0-9c3f92aaa33e@github.com>
References: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
 <vtw1acKMe69fcntcaQ_PYt6_AneS7YfiF18KfN9KAPg=.aa646f10-08d3-421e-933c-5c80906613c5@github.com>
 <VfzvYk3aWQKY3dqapq5g7Tki57EcVt7OAH2M2ttzuMg=.e583792d-f8d3-41b5-a0d0-9c3f92aaa33e@github.com>
Message-ID: <aTV9F_kmfedsTb-oPZ7NsnhmPOuUt_Zt6tT98JKJ6Pk=.013a4879-7562-43bf-8443-74fa6e3ff1f0@github.com>

On Mon, 16 Jun 2025 18:32:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close-
>>  - Merge branch 'openjdk:master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close-
>>  - Merge branch 'openjdk:master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close-
>>  - close dir fd on fcntl error
>>  - Mark fds with cloexec, plus test
>
> test/jdk/java/lang/ProcessBuilder/FDLeakTest/FDLeakTest.java line 59:
> 
>> 57:     //
>> 58:     // What should happen: In the child process, between the initial fork and the exec of the target binary, we should
>> 59:     // close all filedescriptors that are not stdin/out/err. If that works, the child process should not see any other
> 
> Can you shorten the long lines to < 100 chars. It makes side-by-side reviews easier.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25301#discussion_r2151378709

From stuefe at openjdk.org  Tue Jun 17 06:37:31 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 17 Jun 2025 06:37:31 GMT
Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(),
 use FD_CLOEXEC instead of close() [v4]
In-Reply-To: <VfzvYk3aWQKY3dqapq5g7Tki57EcVt7OAH2M2ttzuMg=.e583792d-f8d3-41b5-a0d0-9c3f92aaa33e@github.com>
References: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
 <vtw1acKMe69fcntcaQ_PYt6_AneS7YfiF18KfN9KAPg=.aa646f10-08d3-421e-933c-5c80906613c5@github.com>
 <VfzvYk3aWQKY3dqapq5g7Tki57EcVt7OAH2M2ttzuMg=.e583792d-f8d3-41b5-a0d0-9c3f92aaa33e@github.com>
Message-ID: <1cC72iCjUNPwUlwVsrwDwZSIyeX1dBOXxSBYRAYQG0A=.1e4f3cf8-a727-4f47-aa1b-f7a33f57d226@github.com>

On Mon, 16 Jun 2025 18:32:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close-
>>  - Merge branch 'openjdk:master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close-
>>  - Merge branch 'openjdk:master' into JDK-8210549-Runtime-exec-in-closeDescriptors-use-FD_CLOEXEC-instead-of-close-
>>  - close dir fd on fcntl error
>>  - Mark fds with cloexec, plus test
>
> test/jdk/java/lang/ProcessBuilder/FDLeakTest/FDLeakTest.java line 59:
> 
>> 57:     //
>> 58:     // What should happen: In the child process, between the initial fork and the exec of the target binary, we should
>> 59:     // close all filedescriptors that are not stdin/out/err. If that works, the child process should not see any other
> 
> Can you shorten the long lines to < 100 chars. It makes side-by-side reviews easier.

@RogerRiggs need a re-review

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25301#discussion_r2151435602

From duke at openjdk.org  Tue Jun 17 07:54:33 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Tue, 17 Jun 2025 07:54:33 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v6]
In-Reply-To: <2LfJux69m6hGFaX_B6-tMjT4v1pUQmgSWXAUjNB04KY=.278f9126-b008-4a26-b594-85f4cdc8a5fb@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <2LfJux69m6hGFaX_B6-tMjT4v1pUQmgSWXAUjNB04KY=.278f9126-b008-4a26-b594-85f4cdc8a5fb@github.com>
Message-ID: <eGrNfWfovA5a1a5di8CAz3PFH55sOguf7th3GLSFdRo=.1fa68c74-22d3-440c-9a73-9b570a588a39@github.com>

On Mon, 16 Jun 2025 17:30:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
>> 
>> `testclasses.jar` is updated such that the two classes no longer extend Applet.
>> 
>> 
>> $ javap fo\ o.class 
>> public class fo o {
>> }
>> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
>> public class ?? {
>> }
>> 
>> 
>> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
>> 
>> Additionally, the security APIs that were marked for removal are also removed from this test as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestion - read class file from memory as bytes

test/jdk/jdk/internal/loader/URLClassPath/ClassnameCharTest.java line 101:

> 99:             //      final String path = name.replace('.', '/').concat(".class").concat(cookie);
> 100:             String encodedName = ParseUtil.encodePath(name.replace('.', '/'), false);
> 101:             final String path = (new StringBuffer(encodedName)).append(".class").append(cookie).toString();

Suggestion:  `final String path = encodedName + ".class" + cookie;`, avoiding StringBuffer

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25703#discussion_r2151577656

From duke at openjdk.org  Tue Jun 17 08:18:40 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Tue, 17 Jun 2025 08:18:40 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v6]
In-Reply-To: <2LfJux69m6hGFaX_B6-tMjT4v1pUQmgSWXAUjNB04KY=.278f9126-b008-4a26-b594-85f4cdc8a5fb@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <2LfJux69m6hGFaX_B6-tMjT4v1pUQmgSWXAUjNB04KY=.278f9126-b008-4a26-b594-85f4cdc8a5fb@github.com>
Message-ID: <B0QxGWjWg4Ld1aPxtTr28akfwKRM4bygQCPxP5vlEiU=.3a8faf67-12db-47e9-bf46-e941142a6731@github.com>

On Mon, 16 Jun 2025 17:30:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
>> 
>> `testclasses.jar` is updated such that the two classes no longer extend Applet.
>> 
>> 
>> $ javap fo\ o.class 
>> public class fo o {
>> }
>> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
>> public class ?? {
>> }
>> 
>> 
>> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
>> 
>> Additionally, the security APIs that were marked for removal are also removed from this test as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestion - read class file from memory as bytes

I am still wondering what this (old) test tries to proof. It is filed below jdk.onternal.loader.URLClassPath but doesn't use or test URLClassPath, and it succeeds to construct a Class with an invalid name "fo o".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25703#issuecomment-2979386913

From viktor.klang at oracle.com  Tue Jun 17 09:33:30 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 17 Jun 2025 09:33:30 +0000
Subject: Best Practice for Busy Waiting in Java
In-Reply-To: <33147cf1-307e-4bc0-8284-6ce8f685cb01@oracle.com>
References: <8a6b6d84-c0a7-4892-847c-71277d2f50af@headcrashing.eu>
 <CANSoFxtKJkQbFsq5+gmdDb=cQ_7pv=ZGJGqV_XZ0FxFyX5wX9g@mail.gmail.com>
 <de2779e4-2b62-488d-88ce-7e1c20d886be@headcrashing.eu>
 <SJ2PR10MB7669E657CF4E976B54F5F122A271A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <SA1PR10MB7832C9FE08B822E090C61743DA70A@SA1PR10MB7832.namprd10.prod.outlook.com>
 <e7078f29-a288-4ba8-a386-33c72b46109f@headcrashing.eu>
 <33147cf1-307e-4bc0-8284-6ce8f685cb01@oracle.com>
Message-ID: <MW4PR10MB5774E5EA72C88D075F10E624FF70A@MW4PR10MB5774.namprd10.prod.outlook.com>

I'll second what Alan said.

What I've found to be true, over and over, is that every API needs its own (broad) performance testing, since memory access patterns, instructions-under-critical-section, and differences in scheduling across different platforms all interact.

It's worth having a look at how busy-waiting is implemented in different java.util.concurrent constructs.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Alan Bateman <alan.bateman at oracle.com>
Sent: Monday, 16 June 2025 17:23
To: Markus KARG <markus at headcrashing.eu>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: Best Practice for Busy Waiting in Java

On 16/06/2025 12:09, Markus KARG wrote:
>
>
> In case you MUST use busy-wait, apply the following rules:
>
>
> * NEVER have EMPTY busy-wait loops, but ALWAYS put Thread.onSpinWait()
> into it. The performance drop is negligible but the CO2 footprint is
> considerably smaller.
>
> * IF it is acceptable for the waiting thread to not have the
> *absolute* maximum throughput, put Thread.yield() before
> Thread.onSpinWait() in the busy-wait loop, so CPU cores are more
> efficiently used.
>
> * Never use Thread.sleep() in busy-wait loops.
>
> * If possible, pin current thread to current CPU core to prevent
> inefficient context switches.
>
> * ...more rules...
>
>
> THAT is what my question is targeting! :-)
>

It may be possible to provide some guidelines but I don't think they can
be turned into rules, e.g. the NEVER example is challenged by methods
that do atomic increment/add/etc. as this read+CAS in a tight loop.
There are also examples that of tight loops to CAS an object to the add
it to a list. The examples of onSpinWait in the JDK might give you some
ideas, e.g. using it in conjunction with a max spin count before timed
back off or parking. One thing to add to your list is virtual threads
where it may be better to park rather than Thread.yield.

-Alan



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250617/1fa49bee/attachment-0001.htm>

From mistria at redhat.com  Tue Jun 17 09:36:03 2025
From: mistria at redhat.com (Mickael Istria)
Date: Tue, 17 Jun 2025 11:36:03 +0200
Subject: StableValue vs Optional
Message-ID: <CAFr6BZQQ-DmLi_5-P43iSTtvsCbECN8UjA03r6BYvHzZtZjdbQ@mail.gmail.com>

Hi all,

(I'm new around here, so please excuse me for this late comment or in case
this was already discussed in some place I missed; I have seached Jira and
the mailing-list via search engine unsuccessfully).

I just discovered the StableValue proposal of JEP-502, that's a preview
feature for Java 25. I really welcome such change as -like most Java
developers- I've had to repeat some boilerplate code to create cached
values.
However, I have the impression that StableValue is a bit redundant with
Optional, and that maybe another approach based on Optional could work.

Concretely, I'm thinking of just adding some static constructor to Optional
that would be like `Optional<T> Optional.supplyNullable(Supplier<T>
supplier)`, one would be able to use it in such way:
```
Optional.supplyNullable(() -> {
  String res;
  ...compute res...
  return res;
})
```
and for more complex cases
```
Optional.supplyNullable(new Supplier<String>() {
  private int state = 0;
  @Override
  String get() {
    return stateful() + stateful() + stateless();
  }

  private String part1() {
    return Integer.toString(state++);
  }
  private String part2() {
    return System.getProperty("jvm.vendor");
  }
})
```


and that would leave the ability to fully encapsulate/isolate the field
computation in the provided supplier (just like the StableValue) and that
would provide at least the immutability goal of StableValue. I'm not much
aware of the Optional internals to know whether it would fit other
requeirements (I actually didn't spot any other requirements on the JEP)
So I'm just sending that here so that this `Optional.supplyNullable(,,,)`
approach gets considered as an alternative. I honestly don't know whether
it'd be better, I just have a strong feeling that it can be worth having it
evaluated as an alternative in the JEP before things get final.

Cheers,
-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
<https://developers.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250617/fffdfcd8/attachment.htm>

From maurizio.cimadamore at oracle.com  Tue Jun 17 10:43:02 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 17 Jun 2025 11:43:02 +0100
Subject: StableValue vs Optional
In-Reply-To: <CAFr6BZQQ-DmLi_5-P43iSTtvsCbECN8UjA03r6BYvHzZtZjdbQ@mail.gmail.com>
References: <CAFr6BZQQ-DmLi_5-P43iSTtvsCbECN8UjA03r6BYvHzZtZjdbQ@mail.gmail.com>
Message-ID: <b5891df3-a59b-4afe-9378-0beae46995c8@oracle.com>

Hi Mickael,
I think at a very high level, a stable value is just a supplier of some 
value, lazily computed. So, the most minimalistic type to model that 
would be a Supplier<T>. In fact, this is what the StableValue provides 
as well (StableValue has a factory that takes a supplier and gives you 
back a lazy supplier).

But, if you zoom in, a stable value is also this "weird" 
mutable-only-once cell, which is effectively a safe wrapper around a JVM 
@Stable field.

When I think of Optional, I don't think of state transitions. An 
optional either is empty, or it's not empty -- pretty much like a Maybe 
type in a functional language. But, at this more fundamental, particle 
level, a stable value is very much a mutable beast, so we need an API 
that is able to model this at-most-once mutation. While in most cases 
the mutation is not really interesting (because clients are more 
interested in the laziness aspects), there are some use cases where 
clients might want to control mutation of a stable value more 
imperatively -- which is why just exposing a Supplier (or an Optional) 
is not enough to cover all possible uses.

The way I read what you write is that, maybe, it could be desirable to 
provide yet another view of a stable value -- e.g. like you can 
construct lazy lists, stable suppliers and functions, maybe being able 
to create a "lazy" optional backed by a stable value is a possibility. 
But I view this more as an interop move between two logically distinct 
APIs. In fact, if Optional had a supplier-accepting factory, then you 
could bridge the two APIs by passing a stable supplier to such a 
factory, and there's your lazy optional.

Maurizio

On 17/06/2025 10:36, Mickael Istria wrote:
> Hi all,
>
> (I'm new around here, so please excuse me for this late comment or in 
> case this was already discussed in some place I missed; I have seached 
> Jira and the mailing-list via search engine unsuccessfully).
>
> I just discovered the StableValue proposal of JEP-502, that's a 
> preview feature for Java 25. I really welcome such change as -like 
> most Java developers- I've had to repeat some boilerplate code to 
> create cached values.
> However, I have the impression that StableValue is a bit redundant 
> with Optional, and that maybe another approach based on Optional could 
> work.
>
> Concretely, I'm thinking of just adding some static constructor to 
> Optional that would be like `Optional<T> 
> Optional.supplyNullable(Supplier<T> supplier)`, one would be able to 
> use it in such way:
> ```
> Optional.supplyNullable(() -> {
> ? String res;
> ? ...compute res...
> ? return res;
> })
> ```
> and for more complex cases
> ```
> Optional.supplyNullable(new Supplier<String>() {
> ? private int state = 0;
> ??@Override
> ? String get() {
> ? ? return stateful()?+?stateful() + stateless();
> ? }
>
> ? private String part1() {
> ? ? return Integer.toString(state++);
> ? }
> ? private String part2() {
> ? ? return System.getProperty("jvm.vendor");
> ? }
> })
> ```
>
>
> and that would leave the ability to fully encapsulate/isolate the 
> field computation in the provided supplier (just like the StableValue) 
> and that would provide at least the immutability goal of StableValue. 
> I'm not much aware of the Optional internals to know whether it would 
> fit other requeirements (I actually didn't spot any other requirements 
> on the JEP)
> So I'm just sending that here so that this 
> `Optional.supplyNullable(,,,)` approach gets considered as an 
> alternative. I honestly don't know whether it'd be better, I just have 
> a strong feeling that it can be worth having it evaluated as an 
> alternative in the JEP before things get final.
>
> Cheers,
> -- 
> Mickael Istria
> Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red 
> Hat <https://developers.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250617/8ffde3d4/attachment-0001.htm>

From markus at headcrashing.eu  Tue Jun 17 11:03:36 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Tue, 17 Jun 2025 13:03:36 +0200
Subject: Best Practice for Busy Waiting in Java
In-Reply-To: <MW4PR10MB5774E5EA72C88D075F10E624FF70A@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <8a6b6d84-c0a7-4892-847c-71277d2f50af@headcrashing.eu>
 <CANSoFxtKJkQbFsq5+gmdDb=cQ_7pv=ZGJGqV_XZ0FxFyX5wX9g@mail.gmail.com>
 <de2779e4-2b62-488d-88ce-7e1c20d886be@headcrashing.eu>
 <SJ2PR10MB7669E657CF4E976B54F5F122A271A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <SA1PR10MB7832C9FE08B822E090C61743DA70A@SA1PR10MB7832.namprd10.prod.outlook.com>
 <e7078f29-a288-4ba8-a386-33c72b46109f@headcrashing.eu>
 <33147cf1-307e-4bc0-8284-6ce8f685cb01@oracle.com>
 <MW4PR10MB5774E5EA72C88D075F10E624FF70A@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <bd6f7242-b134-4ebf-a508-ac7bcbadb686@headcrashing.eu>

In general, I second do that. The point why I came up with a best 
practices document is that?in many companies the average programmer is 
not an engineer, and would be happy to have some rules at hand. It must 
not be perfect, it must be just better than "empty" busy-wait.


Am 17.06.2025 um 11:33 schrieb Viktor Klang:
> I'll second what Alan said.
>
> What I've found to be true, over and over, is that every API needs its 
> own (broad) performance testing, since memory access patterns, 
> instructions-under-critical-section, and differences in scheduling 
> across different platforms all interact.
>
> It's worth having a look at how busy-waiting is implemented in 
> different java.util.concurrent constructs.
>
> Cheers,
> ?
>
> *
> *
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------------------------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of 
> Alan Bateman <alan.bateman at oracle.com>
> *Sent:* Monday, 16 June 2025 17:23
> *To:* Markus KARG <markus at headcrashing.eu>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: Best Practice for Busy Waiting in Java
> On 16/06/2025 12:09, Markus KARG wrote:
> >
> >
> > In case you MUST use busy-wait, apply the following rules:
> >
> >
> > * NEVER have EMPTY busy-wait loops, but ALWAYS put Thread.onSpinWait()
> > into it. The performance drop is negligible but the CO2 footprint is
> > considerably smaller.
> >
> > * IF it is acceptable for the waiting thread to not have the
> > *absolute* maximum throughput, put Thread.yield() before
> > Thread.onSpinWait() in the busy-wait loop, so CPU cores are more
> > efficiently used.
> >
> > * Never use Thread.sleep() in busy-wait loops.
> >
> > * If possible, pin current thread to current CPU core to prevent
> > inefficient context switches.
> >
> > * ...more rules...
> >
> >
> > THAT is what my question is targeting! :-)
> >
>
> It may be possible to provide some guidelines but I don't think they can
> be turned into rules, e.g. the NEVER example is challenged by methods
> that do atomic increment/add/etc. as this read+CAS in a tight loop.
> There are also examples that of tight loops to CAS an object to the add
> it to a list. The examples of onSpinWait in the JDK might give you some
> ideas, e.g. using it in conjunction with a max spin count before timed
> back off or parking. One thing to add to your list is virtual threads
> where it may be better to park rather than Thread.yield.
>
> -Alan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250617/19b2a9cc/attachment.htm>

From mistria at redhat.com  Tue Jun 17 12:55:58 2025
From: mistria at redhat.com (Mickael Istria)
Date: Tue, 17 Jun 2025 14:55:58 +0200
Subject: StableValue vs Optional
In-Reply-To: <b5891df3-a59b-4afe-9378-0beae46995c8@oracle.com>
References: <CAFr6BZQQ-DmLi_5-P43iSTtvsCbECN8UjA03r6BYvHzZtZjdbQ@mail.gmail.com>
 <b5891df3-a59b-4afe-9378-0beae46995c8@oracle.com>
Message-ID: <CAFr6BZR6esGFcFDaCK0D-fZDZG+JzTEZovgzDY39m+ZxY48QYA@mail.gmail.com>

Thanks for your answer.

> the most minimalistic type to model that would be a Supplier<T>.

Indeed. I mentioned Optional, but as the discussion goes, what could work
instead of an Optional would be a constructor `Supplier.cache(Supplier<T>
computer)` that would cache the computed value. That would be even better
than Optional.

>  a stable value is also this "weird" mutable-only-once cell, which is
effectively a safe wrapper around a JVM @Stable field.

OK, for that part, as I have no knowledge of how @Stable works, I fully
trust you.

> a stable value is very much a mutable beast, so we need an API that is
able to model this at-most-once mutation.  While in most cases the mutation
is not really interesting (because clients are more interested in the
laziness aspects)

Indeed, I admit that my comment was only built on the use-case of lazily
initialized values; which seem to be only a corner case of StableValue's
goal; and I agree that some more dedicated API to lazily initialized value
(eg `Supplier.cache(Supplier<T> computer)` or
`Optional.supplyNullable(Supplier<T> computer)` still could make sense
independently of StableValue which has a slightly broader scope.

Thanks again.
Mickael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250617/9a0d9634/attachment.htm>

From maurizio.cimadamore at oracle.com  Tue Jun 17 13:34:28 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 17 Jun 2025 14:34:28 +0100
Subject: StableValue vs Optional
In-Reply-To: <CAFr6BZR6esGFcFDaCK0D-fZDZG+JzTEZovgzDY39m+ZxY48QYA@mail.gmail.com>
References: <CAFr6BZQQ-DmLi_5-P43iSTtvsCbECN8UjA03r6BYvHzZtZjdbQ@mail.gmail.com>
 <b5891df3-a59b-4afe-9378-0beae46995c8@oracle.com>
 <CAFr6BZR6esGFcFDaCK0D-fZDZG+JzTEZovgzDY39m+ZxY48QYA@mail.gmail.com>
Message-ID: <55254fbe-7679-41aa-9009-0cfabb0cc872@oracle.com>


On 17/06/2025 13:55, Mickael Istria wrote:
> Thanks for your answer.
>
> >?the most minimalistic type to model that would be a Supplier<T>.
>
> Indeed. I mentioned Optional, but as the discussion goes, what could 
> work instead of an Optional would be a constructor 
> `Supplier.cache(Supplier<T> computer)` that would cache the computed 
> value. That would be even better than Optional.

Note that this is already part of the StableValue API:

https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/lang/StableValue.html#supplier(java.util.function.Supplier)

>
> >? a stable value is also this "weird" mutable-only-once cell, which 
> is effectively a safe wrapper around a JVM @Stable field.
>
> OK, for that part, as I have no knowledge of how?@Stable works, I 
> fully trust you.

Some pointers:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java

(might be useful, as an exercise, to read through the documentation of 
that internal annotation, and connect the dots back to the StableValue API)

>
> > a stable value is very much a mutable beast, so we need an API that 
> is able to model this at-most-once mutation. While in most cases the 
> mutation is not really interesting (because clients are more 
> interested in the laziness aspects)
>
> Indeed, I admit that my comment was only built on the use-case of 
> lazily initialized values; which seem to be only a corner case of 
> StableValue's goal; and I agree that some more dedicated API to lazily 
> initialized value (eg?`Supplier.cache(Supplier<T> computer)` or 
> `Optional.supplyNullable(Supplier<T> computer)` still could make sense 
> independently of StableValue which has a slightly broader scope.
Cheers
Maurizio
>
> Thanks again.
> Mickael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250617/32bc9a9c/attachment-0001.htm>

From cstein at openjdk.org  Tue Jun 17 14:03:38 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 17 Jun 2025 14:03:38 GMT
Subject: Integrated: 8357862: Java argument file is parsed unexpectedly with
 trailing comment
In-Reply-To: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
Message-ID: <zHDzgy9rsA833UGhZKfiqPN5xwzglh00W-ZABFXH1f8=.8b1855e5-f7dd-4741-9d0a-38d5edead887@github.com>

On Mon, 2 Jun 2025 13:46:23 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign.
> 
> The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files):
> 
> Use the number sign `#` in the argument file to identify comments.
> All characters following the `#` are ignored until the end of line.
> 
> There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters.

This pull request has now been integrated.

Changeset: 21b72dea
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21b72dea7805357b3644161d1a158c52f49d0e6e
Stats:     40 lines in 2 files changed: 29 ins; 7 del; 4 mod

8357862: Java argument file is parsed unexpectedly with trailing comment

Co-authored-by: Stuart Marks <smarks at openjdk.org>
Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/25589

From mistria at redhat.com  Tue Jun 17 14:25:51 2025
From: mistria at redhat.com (Mickael Istria)
Date: Tue, 17 Jun 2025 16:25:51 +0200
Subject: StableValue vs Optional
In-Reply-To: <55254fbe-7679-41aa-9009-0cfabb0cc872@oracle.com>
References: <CAFr6BZQQ-DmLi_5-P43iSTtvsCbECN8UjA03r6BYvHzZtZjdbQ@mail.gmail.com>
 <b5891df3-a59b-4afe-9378-0beae46995c8@oracle.com>
 <CAFr6BZR6esGFcFDaCK0D-fZDZG+JzTEZovgzDY39m+ZxY48QYA@mail.gmail.com>
 <55254fbe-7679-41aa-9009-0cfabb0cc872@oracle.com>
Message-ID: <CAFr6BZTvH5OhWJ9gs7-BFqwWDD7e_+Ri8Vk9qH4LPCMsboNrqg@mail.gmail.com>

On Tue, Jun 17, 2025 at 3:34?PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Note that this is already part of the StableValue API:
> https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/lang/StableValue.html#supplier(java.util.function.Supplier)
>

Yes, that's where my thoughts incepted. When I noticed it, I wondered
whether a new type is the best solution for lazy initialization of final
values (and still believe a Supplier.cache(Supplier<T> computer) would be a
nice addition). But your answer about the scope of StableValue being
broader than just lazy initialization makes my comment not so relevant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250617/fd7ddf7d/attachment.htm>

From maurizio.cimadamore at oracle.com  Tue Jun 17 14:51:38 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 17 Jun 2025 15:51:38 +0100
Subject: StableValue vs Optional
In-Reply-To: <CAFr6BZTvH5OhWJ9gs7-BFqwWDD7e_+Ri8Vk9qH4LPCMsboNrqg@mail.gmail.com>
References: <CAFr6BZQQ-DmLi_5-P43iSTtvsCbECN8UjA03r6BYvHzZtZjdbQ@mail.gmail.com>
 <b5891df3-a59b-4afe-9378-0beae46995c8@oracle.com>
 <CAFr6BZR6esGFcFDaCK0D-fZDZG+JzTEZovgzDY39m+ZxY48QYA@mail.gmail.com>
 <55254fbe-7679-41aa-9009-0cfabb0cc872@oracle.com>
 <CAFr6BZTvH5OhWJ9gs7-BFqwWDD7e_+Ri8Vk9qH4LPCMsboNrqg@mail.gmail.com>
Message-ID: <f814fab7-be95-4a55-94c1-4900c16ff5d5@oracle.com>


On 17/06/2025 15:25, Mickael Istria wrote:
> (and still believe a Supplier.cache(Supplier<T> computer) would be a 
> nice addition).

Maybe I'm misunderstanding... what would be the difference between 
StableValue::supplier and Supplier::cache ?

Is it a discoverability issue you are pointing out (e.g. this factory 
would be more discoverable if it belonged to Supplier -- which is 
something we flipped-flopped several times about) or is there more, e.g. 
a semantics distinction?

Maurizio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250617/10b9e633/attachment-0001.htm>

From rriggs at openjdk.org  Tue Jun 17 14:57:36 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 17 Jun 2025 14:57:36 GMT
Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(),
 use FD_CLOEXEC instead of close() [v5]
In-Reply-To: <-I5U1mBEeRCAMkb6dIINRoyifi9S6dm3Qh9d3japTt0=.a077c0c8-9d16-4788-9a21-72eb0a014406@github.com>
References: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
 <-I5U1mBEeRCAMkb6dIINRoyifi9S6dm3Qh9d3japTt0=.a077c0c8-9d16-4788-9a21-72eb0a014406@github.com>
Message-ID: <zVdixbhWEt4UPAM5ba_EGMK3x14mhXtY455Kz0KDVf0=.b8b10f44-6885-4fa1-bbb2-e7664c94c03a@github.com>

On Tue, 17 Jun 2025 05:56:15 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi, please consider the following patch.
>> 
>> This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc.
>> 
>> This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens).
>> 
>> Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409
>> 
>> This patch also fixes two subtle bugs:
>> - we didn't check the return value of the close() inside closeAllFileDescriptors
>> - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it)
>> 
>> ----
>> 
>> Testing:
>> 
>> We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC.
>> 
>> - in the parent JVM, the test opens a file in native code without FD_CLOEXEC
>> - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open
>> 
>> I verified that the test correctly detects a broken implementation that leaks file descriptors. 
>> 
>> I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX).
>> 
>> I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update FDLeakTest.java - shorten comment lines

Thanks for the updates.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25301#pullrequestreview-2936020345

From mistria at redhat.com  Tue Jun 17 15:01:06 2025
From: mistria at redhat.com (Mickael Istria)
Date: Tue, 17 Jun 2025 17:01:06 +0200
Subject: StableValue vs Optional
In-Reply-To: <f814fab7-be95-4a55-94c1-4900c16ff5d5@oracle.com>
References: <CAFr6BZQQ-DmLi_5-P43iSTtvsCbECN8UjA03r6BYvHzZtZjdbQ@mail.gmail.com>
 <b5891df3-a59b-4afe-9378-0beae46995c8@oracle.com>
 <CAFr6BZR6esGFcFDaCK0D-fZDZG+JzTEZovgzDY39m+ZxY48QYA@mail.gmail.com>
 <55254fbe-7679-41aa-9009-0cfabb0cc872@oracle.com>
 <CAFr6BZTvH5OhWJ9gs7-BFqwWDD7e_+Ri8Vk9qH4LPCMsboNrqg@mail.gmail.com>
 <f814fab7-be95-4a55-94c1-4900c16ff5d5@oracle.com>
Message-ID: <CAFr6BZTOnjGUGuJ-z3ja5iLx2JZhg6xWWoDVdm+CnNM5ETZqZw@mail.gmail.com>

On Tue, Jun 17, 2025 at 4:51?PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Maybe I'm misunderstanding... what would be the difference between
> StableValue::supplier and Supplier::cache ?
>
> Is it a discoverability issue you are pointing out (e.g. this factory
> would be more discoverable if it belonged to Supplier -- which is something
> we flipped-flopped several times about) or is there more, e.g. a semantics
> distinction?
>
It's me who misunderstood: I misread StableValue::supplier signature and
had thought it would return a StableValue. And that is wrong, it does
indeed return a Supplier, my bad!
So I suspect the issue I faced is more an issue of discoverability or
consistency with existing APIs then: if I want a Supplier, the first thing
I'd try is to use my IDE to complete Supplier.| , I don't think I would
easily think of completng StableValue.| to get a Supplier.

>

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
<https://developers.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250617/c1fe03ab/attachment.htm>

From maurizio.cimadamore at oracle.com  Tue Jun 17 15:05:36 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 17 Jun 2025 16:05:36 +0100
Subject: StableValue vs Optional
In-Reply-To: <CAFr6BZTOnjGUGuJ-z3ja5iLx2JZhg6xWWoDVdm+CnNM5ETZqZw@mail.gmail.com>
References: <CAFr6BZQQ-DmLi_5-P43iSTtvsCbECN8UjA03r6BYvHzZtZjdbQ@mail.gmail.com>
 <b5891df3-a59b-4afe-9378-0beae46995c8@oracle.com>
 <CAFr6BZR6esGFcFDaCK0D-fZDZG+JzTEZovgzDY39m+ZxY48QYA@mail.gmail.com>
 <55254fbe-7679-41aa-9009-0cfabb0cc872@oracle.com>
 <CAFr6BZTvH5OhWJ9gs7-BFqwWDD7e_+Ri8Vk9qH4LPCMsboNrqg@mail.gmail.com>
 <f814fab7-be95-4a55-94c1-4900c16ff5d5@oracle.com>
 <CAFr6BZTOnjGUGuJ-z3ja5iLx2JZhg6xWWoDVdm+CnNM5ETZqZw@mail.gmail.com>
Message-ID: <3e6420ff-121c-4c57-b6e5-94183b26d0a1@oracle.com>


On 17/06/2025 16:01, Mickael Istria wrote:
>
>
> On Tue, Jun 17, 2025 at 4:51?PM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com> wrote:
>
>     Maybe I'm misunderstanding... what would be the difference between
>     StableValue::supplier and Supplier::cache ?
>
>     Is it a discoverability issue you are pointing out (e.g. this
>     factory would be more discoverable if it belonged to Supplier --
>     which is something we flipped-flopped several times about) or is
>     there more, e.g. a semantics distinction?
>
> It's me who misunderstood: I misread StableValue::supplier signature 
> and had thought it would return a StableValue. And that is wrong, it 
> does indeed return a Supplier, my bad!
> So I suspect the issue I faced is more an issue of discoverability or 
> consistency with existing APIs then: if I want a Supplier, the first 
> thing I'd try is to use my IDE to complete Supplier.| , I don't think 
> I would easily think of completng StableValue.| to get a Supplier.

Thanks for confirming. And this (e.g. location of factory methods) is 
indeed something that we might revisit in the second round of preview of 
this API.

Cheers
Maurizio

>
>
> -- 
> Mickael Istria
> Eclipse IDE 
> <https://urldefense.com/v3/__https://www.eclipse.org/eclipseide__;!!ACWV5N9M2RV99hQ!KwFyqDqtRLzFJU64SP8K6gAV3Ei3QVWcw7YA3_LCkKtMCgVWv_6hYnqnOJ-34wj1qtxrh8ODNXo8vKvbhtcCfEg$> 
> developer, for Red Hat 
> <https://urldefense.com/v3/__https://developers.redhat.com/__;!!ACWV5N9M2RV99hQ!KwFyqDqtRLzFJU64SP8K6gAV3Ei3QVWcw7YA3_LCkKtMCgVWv_6hYnqnOJ-34wj1qtxrh8ODNXo8vKvb40BCHX0$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250617/aac1aad7/attachment-0001.htm>

From rriggs at openjdk.org  Tue Jun 17 15:09:32 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 17 Jun 2025 15:09:32 GMT
Subject: RFR: 8359735: [Ubuntu 25.10] java/lang/ProcessBuilder/Basic.java, 
 java/lang/ProcessHandle/InfoTest.java fail due to rust-coreutils
In-Reply-To: <3_AaRZDHCFUzB5DnsdruJRqPPCqjn_ylYPOA2qOf8ws=.2f5ffd56-7ad1-401f-a14c-4ed121a51e59@github.com>
References: <3_AaRZDHCFUzB5DnsdruJRqPPCqjn_ylYPOA2qOf8ws=.2f5ffd56-7ad1-401f-a14c-4ed121a51e59@github.com>
Message-ID: <iYOrzc6vumqbfWJ27d2ueigoSMfzl2m1mvWudRYr5Y4=.aeb62dda-b83d-40b5-bfd0-5dc29a84a3b5@github.com>

On Mon, 16 Jun 2025 22:49:02 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> To accommodate systems like Ubuntu 25.10 that use Rust coreutils, this PR updates tests that previously assumed BusyBox was the only environment to use symlinks for core utilities.
> 
> Changes:
> -   `java/lang/ProcessBuilder/Basic.java`: The test is updated to simply verify that `/bin/true `and `/bin/false` are symlinks, removing the hardcoded check for a /bin/busybox target.
>  -  ` java/lang/ProcessHandle/InfoTest.java`: The test logic is relaxed. It now confirms that `/bin/sleep` is a symlink and then uses the symlink's target as the expected executable name.

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25838#pullrequestreview-2936067048

From iris at openjdk.org  Tue Jun 17 16:54:30 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 17 Jun 2025 16:54:30 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page [v3]
In-Reply-To: <4jexZv1gfiybYoApPujxPTvGgsiQLO439jkHE4-l_sE=.1052a952-30e1-4fb0-81f0-52166bcda313@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
 <4jexZv1gfiybYoApPujxPTvGgsiQLO439jkHE4-l_sE=.1052a952-30e1-4fb0-81f0-52166bcda313@github.com>
Message-ID: <gFN3XUuCFs7TKWeaBiMRUmPvVwbtiR9rf6xUzu_FPk8=.cdf16ce9-9972-4dc6-a774-ed7a277c189d@github.com>

On Mon, 16 Jun 2025 19:59:06 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> Please review my PR. This PR includes the following:
>> 
>> - [x] Fix a small typo in a word and copyright.
>> - [x] Enhance description for `--target-platform`.
>> - [x] Rearrange `jmod create` example from basic to complex.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Enhance --target-platform explanation.

Your updates look good.

I believe you've addressed @AlanBateman 's comments, but he should confirm.

src/jdk.jlink/share/man/jmod.md line 182:

> 180: 
> 181: `--target-platform` *platform*
> 182: :   Specifies the target platform when creating a JMOD file intended

Suggest (nit) from: "the target platform when creating a JMOD file" to "the target platform of a JMOD file"

src/jdk.jlink/share/man/jmod.md line 240:

> 238: Create a platform-specific JMOD file bundling compiled classes, configuration files,
> 239: native commands and libraries, header files, man pages, and metadata including the
> 240: main class, module version, and target platform details:

Sorry to be picky, but I just noticed that the order of the options in the description and the example don't match.  Also, since you're choosing the "all" option for this example, you should consider beginning the sentence with just "Create a JMOD file...".

-------------

PR Review: https://git.openjdk.org/jdk/pull/25772#pullrequestreview-2936389012
PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2152734413
PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2152722640

From duke at openjdk.org  Tue Jun 17 17:08:17 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Tue, 17 Jun 2025 17:08:17 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page [v4]
In-Reply-To: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
Message-ID: <lXq4ACbyvuBmykAmVhQUrp9WtmMFZTvpT8Fd5AH2wZY=.b646f5b8-3e4d-4fd6-ae8d-d63c1067fb81@github.com>

> Please review my PR. This PR includes the following:
> 
> - [x] Fix a small typo in a word and copyright.
> - [x] Enhance description for `--target-platform`.
> - [x] Rearrange `jmod create` example from basic to complex.

Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:

  Update commands and description according to review.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25772/files
  - new: https://git.openjdk.org/jdk/pull/25772/files/d52f2ce2..27052ebb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25772&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25772&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25772/head:pull/25772

PR: https://git.openjdk.org/jdk/pull/25772

From duke at openjdk.org  Tue Jun 17 17:08:17 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Tue, 17 Jun 2025 17:08:17 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page [v3]
In-Reply-To: <gFN3XUuCFs7TKWeaBiMRUmPvVwbtiR9rf6xUzu_FPk8=.cdf16ce9-9972-4dc6-a774-ed7a277c189d@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
 <4jexZv1gfiybYoApPujxPTvGgsiQLO439jkHE4-l_sE=.1052a952-30e1-4fb0-81f0-52166bcda313@github.com>
 <gFN3XUuCFs7TKWeaBiMRUmPvVwbtiR9rf6xUzu_FPk8=.cdf16ce9-9972-4dc6-a774-ed7a277c189d@github.com>
Message-ID: <U9_tRetOpzmuLMWP_mRvEwXFm2csv3nNN0tszL1MBOw=.ef444947-0a09-4051-8718-82e9c2cdfdd5@github.com>

On Tue, 17 Jun 2025 16:51:19 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Enhance --target-platform explanation.
>
> src/jdk.jlink/share/man/jmod.md line 182:
> 
>> 180: 
>> 181: `--target-platform` *platform*
>> 182: :   Specifies the target platform when creating a JMOD file intended
> 
> Suggest (nit) from: "the target platform when creating a JMOD file" to "the target platform of a JMOD file"

Modified according to review ? .

> src/jdk.jlink/share/man/jmod.md line 240:
> 
>> 238: Create a platform-specific JMOD file bundling compiled classes, configuration files,
>> 239: native commands and libraries, header files, man pages, and metadata including the
>> 240: main class, module version, and target platform details:
> 
> Sorry to be picky, but I just noticed that the order of the options in the description and the example don't match.  Also, since you're choosing the "all" option for this example, you should consider beginning the sentence with just "Create a JMOD file...".

Not a problem at all, is important to keep the order both in explanation and command. I modified accordingly. ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2152761067
PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2152762065

From smarks at openjdk.org  Tue Jun 17 17:21:01 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 17 Jun 2025 17:21:01 GMT
Subject: [jdk25] RFR: 8338140: (str) Add notes to String.trim and
 String.isEmpty pointing to newer APIs
Message-ID: <AM-xLw_DB5fkMA4qKMxRuzEQn-CPxiMW-K4waeM7ziU=.51238fbf-75db-415c-a0ee-996fa098d033@github.com>

Hi all,

This pull request contains a backport of commit [06d804a0](https://github.com/openjdk/jdk/commit/06d804a0f004f9403c7c12e1a9f2ca8775c639f7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Stuart Marks on 16 Jun 2025 and was reviewed by Naoto Sato @naotoj and Brian Burkhalter @bplb.

Thanks!

-------------

Commit messages:
 - Backport 06d804a0f004f9403c7c12e1a9f2ca8775c639f7

Changes: https://git.openjdk.org/jdk/pull/25858/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25858&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338140
  Stats: 19 lines in 1 file changed: 9 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25858.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25858/head:pull/25858

PR: https://git.openjdk.org/jdk/pull/25858

From naoto at openjdk.org  Tue Jun 17 17:34:31 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Jun 2025 17:34:31 GMT
Subject: [jdk25] RFR: 8338140: (str) Add notes to String.trim and
 String.isEmpty pointing to newer APIs
In-Reply-To: <AM-xLw_DB5fkMA4qKMxRuzEQn-CPxiMW-K4waeM7ziU=.51238fbf-75db-415c-a0ee-996fa098d033@github.com>
References: <AM-xLw_DB5fkMA4qKMxRuzEQn-CPxiMW-K4waeM7ziU=.51238fbf-75db-415c-a0ee-996fa098d033@github.com>
Message-ID: <0-fCY5KioXW9xnPlDyNRxjAGjxYqpcIKKxnW8Qb1fM8=.83ac7d32-182d-4a0f-8010-fbe27c3ee1cb@github.com>

On Tue, 17 Jun 2025 17:15:21 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [06d804a0](https://github.com/openjdk/jdk/commit/06d804a0f004f9403c7c12e1a9f2ca8775c639f7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Stuart Marks on 16 Jun 2025 and was reviewed by Naoto Sato @naotoj and Brian Burkhalter @bplb.
> 
> Thanks!

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25858#pullrequestreview-2936524075

From mdonovan at openjdk.org  Tue Jun 17 17:36:31 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 17 Jun 2025 17:36:31 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <8pLm1mah1JKonu3z5tWwIpU_J5jEggSiBst-PNEdG4s=.931782e4-3e34-4535-bc71-622d76b871a7@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
 <NBeas7VSHxEynwU9LXuGy-p9Lg9Tm5I9auSaHBExzRA=.effd0ad3-a5f2-4049-b4df-49030a0502ef@github.com>
 <v45mu9Zly3T9l94b-WP1p_4oB_Y2Pe0gdU6C3w_vRqM=.ebaa8261-3d70-43a1-82b2-bba9def061a2@github.com>
 <8pLm1mah1JKonu3z5tWwIpU_J5jEggSiBst-PNEdG4s=.931782e4-3e34-4535-bc71-622d76b871a7@github.com>
Message-ID: <I79KijRZOM7Stzc7Sax_hFgxyPD_sEV2xaHZVipl2y4=.6f2fbe79-555c-4d04-9c38-25cea18075c5@github.com>

On Tue, 10 Jun 2025 07:47:29 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

>> But isn't it the person running the tests that wants to set this, not an inherent property of a test itself? Or are you envisaging enabling it at the test-level so the person running the tests doesn't have to do so? But then how does that affect the overall jtreg log content. ??
>
> To add on this, I should mention that I noticed a lot of tests are using OutputAnalyzer indirectly, returned as a result of a utility function, for example `ProcessTools.execute{Process,Command}`
> 
> 
> git grep -E "ProcessTools.execute((Process)|(Command))" | wc -l
>      351
> 
> 
> Instead of calling one of OutputAnalyzer's constructors (700 invocations, but many of them are with the Eager, string based and not process based, constructor, which we don't care about)
> 
> 
> I'm not sure adding additional parameters also to that code is an ideal solution, I'd much prefer adding the command line parameter to the docs of the OutputAnalyzer class, so that one knows to enable it when running the single test through jtreg
> 
> ---
> 
> That said, if there are multiple OutputAnalyzers going in a single test, then it makes perfect sense to have (or at least use) a constructor argument

> But isn't it the person running the tests that wants to set this, not an inherent property of a test itself?

I'm not sure if I completely understand your question. A lot of tests use the `test.debug` system property to enable more verbose test output. It's enabled when someone runs the test e.g., `jtreg -Dtest.debug=true ...`

As you pointed out, a lot of tests may not care if the subprocess's output is cached or not, but for those that do, having to specify a second property could be onerous and using the same `test.debug` property inside OutputBuffer could result in unexpected output. If the OutputAnalyzer ctor took a boolean , a test could enable (or not) with something like `new OutputAnalyzer(childProc, Boolean.getBoolean("test.debug"))`

> I'm not sure adding additional parameters also to that code is an ideal solution,

There are two constructors that take Process objects as arguments. I was thinking that you could overload them to take the extra argument. 


public OutputAnalyzer(Process process, Charset cs, boolean flushOutput)
public OutputAnalyzer(Process process, boolean flushOutput)


None of the existing tests would be affected and those tests that could benefit from inline output could specify it as needed. You're right that the use of OutputAnalyzer is usually indirect so that would cause some other code to be changed as well, but it only has to change when it becomes necessary to enable it. (And it can be updated in the same way i.e., overloading the methods to take an extra argument.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2152810288

From bpb at openjdk.org  Tue Jun 17 17:38:29 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Jun 2025 17:38:29 GMT
Subject: [jdk25] RFR: 8338140: (str) Add notes to String.trim and
 String.isEmpty pointing to newer APIs
In-Reply-To: <AM-xLw_DB5fkMA4qKMxRuzEQn-CPxiMW-K4waeM7ziU=.51238fbf-75db-415c-a0ee-996fa098d033@github.com>
References: <AM-xLw_DB5fkMA4qKMxRuzEQn-CPxiMW-K4waeM7ziU=.51238fbf-75db-415c-a0ee-996fa098d033@github.com>
Message-ID: <cSoHx4WslMS5f3JI54_9I0jcasehlj0HJXSnCfbV5zw=.f54bbf76-8dc6-4853-9603-7ca13cf7da21@github.com>

On Tue, 17 Jun 2025 17:15:21 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [06d804a0](https://github.com/openjdk/jdk/commit/06d804a0f004f9403c7c12e1a9f2ca8775c639f7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Stuart Marks on 16 Jun 2025 and was reviewed by Naoto Sato @naotoj and Brian Burkhalter @bplb.
> 
> Thanks!

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25858#pullrequestreview-2936534326

From duke at openjdk.org  Tue Jun 17 17:47:00 2025
From: duke at openjdk.org (Dermot Boyle)
Date: Tue, 17 Jun 2025 17:47:00 GMT
Subject: RFR: 8359449: [TEST] open/test/jdk/java/io/File/SymLinks.java Refactor
 extract method for Windows specific test
Message-ID: <IPhwQBs8k-uM1M5wgH-0yDB__A73xcwcYYWbNUcp1mk=.62740094-384f-4893-bae8-4c44152bfc66@github.com>

? extract method for Windows specific test

-------------

Commit messages:
 - Removed more whitespace for JCheck
 - Removed whitespace for JCheck
 - JDK-8359449: [TEST] open/test/jdk/java/io/File/SymLinks.java Refactor extract method for Windows specific test

Changes: https://git.openjdk.org/jdk/pull/25853/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25853&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359449
  Stats: 37 lines in 1 file changed: 20 ins; 15 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25853.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25853/head:pull/25853

PR: https://git.openjdk.org/jdk/pull/25853

From bpb at openjdk.org  Tue Jun 17 17:57:31 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Jun 2025 17:57:31 GMT
Subject: RFR: 8359449: [TEST] open/test/jdk/java/io/File/SymLinks.java
 Refactor extract method for Windows specific test
In-Reply-To: <IPhwQBs8k-uM1M5wgH-0yDB__A73xcwcYYWbNUcp1mk=.62740094-384f-4893-bae8-4c44152bfc66@github.com>
References: <IPhwQBs8k-uM1M5wgH-0yDB__A73xcwcYYWbNUcp1mk=.62740094-384f-4893-bae8-4c44152bfc66@github.com>
Message-ID: <Luakjyx1sYBBIBEXZMr3g7u7VWiSyxPNMEo5WXtEwhs=.ac9545bd-7e49-4f61-ae21-32bb2922767f@github.com>

On Tue, 17 Jun 2025 14:56:59 GMT, Dermot Boyle <duke at openjdk.org> wrote:

> ? extract method for Windows specific test

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25853#pullrequestreview-2936585934

From duke at openjdk.org  Tue Jun 17 18:09:32 2025
From: duke at openjdk.org (duke)
Date: Tue, 17 Jun 2025 18:09:32 GMT
Subject: RFR: 8359449: [TEST] open/test/jdk/java/io/File/SymLinks.java
 Refactor extract method for Windows specific test
In-Reply-To: <IPhwQBs8k-uM1M5wgH-0yDB__A73xcwcYYWbNUcp1mk=.62740094-384f-4893-bae8-4c44152bfc66@github.com>
References: <IPhwQBs8k-uM1M5wgH-0yDB__A73xcwcYYWbNUcp1mk=.62740094-384f-4893-bae8-4c44152bfc66@github.com>
Message-ID: <4fwoavFkngkerlzJLUmNyHMf9SF3mg-Wilc_1OLIs6Q=.315ac4ea-08dc-4460-b973-b5c79e2b2c14@github.com>

On Tue, 17 Jun 2025 14:56:59 GMT, Dermot Boyle <duke at openjdk.org> wrote:

> ? extract method for Windows specific test

@dermotb 
Your change (at version 9f0647e6d7176c36e3acf93a4256d102f0867e0a) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25853#issuecomment-2981333773

From duke at openjdk.org  Tue Jun 17 18:24:35 2025
From: duke at openjdk.org (Dermot Boyle)
Date: Tue, 17 Jun 2025 18:24:35 GMT
Subject: Integrated: 8359449: [TEST] open/test/jdk/java/io/File/SymLinks.java
 Refactor extract method for Windows specific test
In-Reply-To: <IPhwQBs8k-uM1M5wgH-0yDB__A73xcwcYYWbNUcp1mk=.62740094-384f-4893-bae8-4c44152bfc66@github.com>
References: <IPhwQBs8k-uM1M5wgH-0yDB__A73xcwcYYWbNUcp1mk=.62740094-384f-4893-bae8-4c44152bfc66@github.com>
Message-ID: <TPtu1GJZxvOPwyWkkApWasOqJc2GUvK3VCQ4y6TTnFk=.ccdf9757-29d7-4d9f-aa8a-e1370d6bbade@github.com>

On Tue, 17 Jun 2025 14:56:59 GMT, Dermot Boyle <duke at openjdk.org> wrote:

> ? extract method for Windows specific test

This pull request has now been integrated.

Changeset: 49a82d88
Author:    dermster <dermot.boyle at oracle.com>
Committer: Mark Sheppard <msheppar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/49a82d880636a632f4a3471b14b1b1b29ce1d5e6
Stats:     37 lines in 1 file changed: 20 ins; 15 del; 2 mod

8359449: [TEST] open/test/jdk/java/io/File/SymLinks.java Refactor extract method for Windows specific test

Reviewed-by: bpb

-------------

PR: https://git.openjdk.org/jdk/pull/25853

From liach at openjdk.org  Tue Jun 17 18:40:28 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Jun 2025 18:40:28 GMT
Subject: [jdk25] RFR: 8338140: (str) Add notes to String.trim and
 String.isEmpty pointing to newer APIs
In-Reply-To: <AM-xLw_DB5fkMA4qKMxRuzEQn-CPxiMW-K4waeM7ziU=.51238fbf-75db-415c-a0ee-996fa098d033@github.com>
References: <AM-xLw_DB5fkMA4qKMxRuzEQn-CPxiMW-K4waeM7ziU=.51238fbf-75db-415c-a0ee-996fa098d033@github.com>
Message-ID: <RMi9JjrGRtPfRcHTJ_gzCq_XaXOTxyKegkNYcMtKoiY=.03251340-8332-4adf-95b8-6acb3eccfe3a@github.com>

On Tue, 17 Jun 2025 17:15:21 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [06d804a0](https://github.com/openjdk/jdk/commit/06d804a0f004f9403c7c12e1a9f2ca8775c639f7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Stuart Marks on 16 Jun 2025 and was reviewed by Naoto Sato @naotoj and Brian Burkhalter @bplb.
> 
> Thanks!

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25858#pullrequestreview-2936707045

From stuefe at openjdk.org  Tue Jun 17 20:09:28 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 17 Jun 2025 20:09:28 GMT
Subject: RFR: 8210549: Runtime.exec: in closeDescriptors(),
 use FD_CLOEXEC instead of close() [v5]
In-Reply-To: <-I5U1mBEeRCAMkb6dIINRoyifi9S6dm3Qh9d3japTt0=.a077c0c8-9d16-4788-9a21-72eb0a014406@github.com>
References: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
 <-I5U1mBEeRCAMkb6dIINRoyifi9S6dm3Qh9d3japTt0=.a077c0c8-9d16-4788-9a21-72eb0a014406@github.com>
Message-ID: <GJzjqZJFxZBASCl6T_tW7fkSG6JxaBm--PTRltrzOLA=.292e4109-e4ef-4360-8f55-86a6570f2a33@github.com>

On Tue, 17 Jun 2025 05:56:15 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi, please consider the following patch.
>> 
>> This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc.
>> 
>> This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens).
>> 
>> Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409
>> 
>> This patch also fixes two subtle bugs:
>> - we didn't check the return value of the close() inside closeAllFileDescriptors
>> - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it)
>> 
>> ----
>> 
>> Testing:
>> 
>> We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC.
>> 
>> - in the parent JVM, the test opens a file in native code without FD_CLOEXEC
>> - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open
>> 
>> I verified that the test correctly detects a broken implementation that leaks file descriptors. 
>> 
>> I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX).
>> 
>> I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update FDLeakTest.java - shorten comment lines

Thank you, Roger!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25301#issuecomment-2981688873

From stuefe at openjdk.org  Tue Jun 17 20:27:41 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 17 Jun 2025 20:27:41 GMT
Subject: Integrated: 8210549: Runtime.exec: in closeDescriptors(),
 use FD_CLOEXEC instead of close()
In-Reply-To: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
References: <aE1cQXunPmF-G6PKet1bg0jGPvZwmQ60tXQ-lq6l2tU=.698c799c-4e8d-482a-96f4-059b0e1965ca@github.com>
Message-ID: <6C3hb9ulbP1hHB7AVwjl6y4_zv1CcDEtrtugbFQKrig=.e6e00cbe-8d77-409a-95be-17fee73d86cc@github.com>

On Mon, 19 May 2025 12:23:07 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi, please consider the following patch.
> 
> This patch replaces the existing close-file-descriptors-logic we follow before exec'ing a target binary: instead of explicitly closing the file descriptors, we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward tiptoeing around the fact that we need to keep alive a few file descriptors: the fail pipe fd needs to be kept open right up to the exec(), and we cause opening internal file descriptors during our iteration of open file handles from /proc.
> 
> This patch also makes future developments easier: I am working on improving logging during child process spawning (https://bugs.openjdk.org/browse/JDK-8357100), and there we have a similar problem where we need to keep a logfile fd open right up to the point exec() happens).
> 
> Note: Using fcntl() with FD_CLOEXEC should work on all our POSIX platforms, since we rely on it already, see unconditional use of that flag here: https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/unix/native/libjava/childproc.c#L408-L409
> 
> This patch also fixes two subtle bugs:
> - we didn't check the return value of the close() inside closeAllFileDescriptors
> - the final fcntl for the fail pipe was subtly wrong (should have or'd the FD_CLOEXEC flag with the existing state before setting it)
> 
> ----
> 
> Testing:
> 
> We already have the PipelineLeak test, but I also added a new test that checks that we don't accidentally leak file descriptors even if those had been opened outside the JVM and without FD_CLOEXEC.
> 
> - in the parent JVM, the test opens a file in native code without FD_CLOEXEC
> - test then spawns a child program that checks that no file descriptors beyond the expected stdin/out/err are open
> 
> I verified that the test correctly detects a broken implementation that leaks file descriptors. 
> 
> I verified that with this patch, we close all file descriptors. I also verified the fallback path (where we brute-force-iterate all descriptors up to _SC_OPEN_MAX).
> 
> I ran manually all tests from test/jdk/java/base/Process*, and verified that these tests run as part of the GHAs, which are green.

This pull request has now been integrated.

Changeset: afa52e46
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/afa52e4681f5d0392c3fdfddf48b00a004d1280c
Stats:     206 lines in 5 files changed: 183 ins; 9 del; 14 mod

8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close()

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/25301

From duke at openjdk.org  Tue Jun 17 20:35:28 2025
From: duke at openjdk.org (duke)
Date: Tue, 17 Jun 2025 20:35:28 GMT
Subject: RFR: 8359735: [Ubuntu 25.10] java/lang/ProcessBuilder/Basic.java, 
 java/lang/ProcessHandle/InfoTest.java fail due to rust-coreutils
In-Reply-To: <3_AaRZDHCFUzB5DnsdruJRqPPCqjn_ylYPOA2qOf8ws=.2f5ffd56-7ad1-401f-a14c-4ed121a51e59@github.com>
References: <3_AaRZDHCFUzB5DnsdruJRqPPCqjn_ylYPOA2qOf8ws=.2f5ffd56-7ad1-401f-a14c-4ed121a51e59@github.com>
Message-ID: <_gwaZLU3lza4cqfM680mRTN2trrjLM9HVtPi2TV0Y1E=.77c82a9d-93d7-4417-94e1-2dd3673515f0@github.com>

On Mon, 16 Jun 2025 22:49:02 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> To accommodate systems like Ubuntu 25.10 that use Rust coreutils, this PR updates tests that previously assumed BusyBox was the only environment to use symlinks for core utilities.
> 
> Changes:
> -   `java/lang/ProcessBuilder/Basic.java`: The test is updated to simply verify that `/bin/true `and `/bin/false` are symlinks, removing the hardcoded check for a /bin/busybox target.
>  -  ` java/lang/ProcessHandle/InfoTest.java`: The test logic is relaxed. It now confirms that `/bin/sleep` is a symlink and then uses the symlink's target as the expected executable name.

@vpa1977 
Your change (at version 5d463d9a61232216c50899ac82446345caf72c1b) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25838#issuecomment-2981751843

From naoto at openjdk.org  Tue Jun 17 20:37:04 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Jun 2025 20:37:04 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
Message-ID: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>

Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

-------------

Commit messages:
 - Several more locations
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/25860/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25860&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359732
  Stats: 69 lines in 13 files changed: 50 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/25860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25860/head:pull/25860

PR: https://git.openjdk.org/jdk/pull/25860

From smarks at openjdk.org  Tue Jun 17 20:48:32 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 17 Jun 2025 20:48:32 GMT
Subject: [jdk25] Integrated: 8338140: (str) Add notes to String.trim and
 String.isEmpty pointing to newer APIs
In-Reply-To: <AM-xLw_DB5fkMA4qKMxRuzEQn-CPxiMW-K4waeM7ziU=.51238fbf-75db-415c-a0ee-996fa098d033@github.com>
References: <AM-xLw_DB5fkMA4qKMxRuzEQn-CPxiMW-K4waeM7ziU=.51238fbf-75db-415c-a0ee-996fa098d033@github.com>
Message-ID: <qghmZDttA_R6Esv8-vMApGGLkF2h_7O4TxcGm_dvKeQ=.bf4bbe68-57e4-4aac-b2e5-67cc8c48596b@github.com>

On Tue, 17 Jun 2025 17:15:21 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [06d804a0](https://github.com/openjdk/jdk/commit/06d804a0f004f9403c7c12e1a9f2ca8775c639f7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Stuart Marks on 16 Jun 2025 and was reviewed by Naoto Sato @naotoj and Brian Burkhalter @bplb.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 5bcea92e
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5bcea92eaa278f632be1fd7de91b57bce46e6680
Stats:     19 lines in 1 file changed: 9 ins; 4 del; 6 mod

8338140: (str) Add notes to String.trim and String.isEmpty pointing to newer APIs

Reviewed-by: naoto, bpb, liach
Backport-of: 06d804a0f004f9403c7c12e1a9f2ca8775c639f7

-------------

PR: https://git.openjdk.org/jdk/pull/25858

From smarks at openjdk.org  Tue Jun 17 20:48:32 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 17 Jun 2025 20:48:32 GMT
Subject: [jdk25] RFR: 8338140: (str) Add notes to String.trim and
 String.isEmpty pointing to newer APIs
In-Reply-To: <AM-xLw_DB5fkMA4qKMxRuzEQn-CPxiMW-K4waeM7ziU=.51238fbf-75db-415c-a0ee-996fa098d033@github.com>
References: <AM-xLw_DB5fkMA4qKMxRuzEQn-CPxiMW-K4waeM7ziU=.51238fbf-75db-415c-a0ee-996fa098d033@github.com>
Message-ID: <7t6WQdYD56MXjRMqj_YxbfXgsopSuiE6SrUgZ9-0agA=.80b329bc-2c7c-4d4a-83dc-8baf2f56b2e6@github.com>

On Tue, 17 Jun 2025 17:15:21 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [06d804a0](https://github.com/openjdk/jdk/commit/06d804a0f004f9403c7c12e1a9f2ca8775c639f7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Stuart Marks on 16 Jun 2025 and was reviewed by Naoto Sato @naotoj and Brian Burkhalter @bplb.
> 
> Thanks!

Thanks all for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25858#issuecomment-2981783816

From jlu at openjdk.org  Tue Jun 17 21:47:49 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jun 2025 21:47:49 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v7]
In-Reply-To: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
Message-ID: <EkTXfBg5WUXUSPG_xQByoXKHWdmPellpe8uZps3EmTQ=.dfdff0aa-8ffc-4478-b978-c3b3b4f926f0@github.com>

> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
> 
> `testclasses.jar` is updated such that the two classes no longer extend Applet.
> 
> 
> $ javap fo\ o.class 
> public class fo o {
> }
> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
> public class ?? {
> }
> 
> 
> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
> 
> Additionally, the security APIs that were marked for removal are also removed from this test as well.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  SB -> String

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25703/files
  - new: https://git.openjdk.org/jdk/pull/25703/files/9e395b2f..58c6c4ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25703&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25703&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25703.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25703/head:pull/25703

PR: https://git.openjdk.org/jdk/pull/25703

From jlu at openjdk.org  Tue Jun 17 21:50:28 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jun 2025 21:50:28 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v6]
In-Reply-To: <B0QxGWjWg4Ld1aPxtTr28akfwKRM4bygQCPxP5vlEiU=.3a8faf67-12db-47e9-bf46-e941142a6731@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <2LfJux69m6hGFaX_B6-tMjT4v1pUQmgSWXAUjNB04KY=.278f9126-b008-4a26-b594-85f4cdc8a5fb@github.com>
 <B0QxGWjWg4Ld1aPxtTr28akfwKRM4bygQCPxP5vlEiU=.3a8faf67-12db-47e9-bf46-e941142a6731@github.com>
Message-ID: <Lea3DMd7_zYi3m7XANdhdodrqCgv-46ON29sbJy3nsU=.036e1208-212b-4df9-84ea-d180b7173af1@github.com>

On Tue, 17 Jun 2025 08:16:15 GMT, Johannes D?bler <duke at openjdk.org> wrote:

> I am still wondering what this (old) test tries to proof. It is filed below jdk.onternal.loader.URLClassPath but doesn't use or test URLClassPath, and it succeeds to construct a Class with an invalid name "fo o".

URLClassPath is used in URLClassLoader, so I think this is OK in the current test structure. In any case, any re-examination would need to be done in a separate issue. The scope of this PR is to simply remove the remnants of Applet.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25703#issuecomment-2981931581

From achung at openjdk.org  Tue Jun 17 23:11:15 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 17 Jun 2025 23:11:15 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
Message-ID: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>

This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

-------------

Commit messages:
 - empty commit
 - redo ws fixes, add manual changes

Changes: https://git.openjdk.org/jdk/pull/25839/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359761
  Stats: 1574 lines in 76 files changed: 810 ins; 93 del; 671 mod
  Patch: https://git.openjdk.org/jdk/pull/25839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839

PR: https://git.openjdk.org/jdk/pull/25839

From jlu at openjdk.org  Tue Jun 17 23:18:29 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jun 2025 23:18:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties line 2:

> 1: #
> 2: # Copyright (c) 2012, 2021, Oracle and/or its affiliates. All rights reserved.

Same as my comment in `src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java`

src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan_de.properties line 26:

> 24: #
> 25: 
> 26: main.usage=Verwendung: jdeprscan [Optionen] ''{dir|jar|class}'' ...\n\nOptionen:\n        --class-path PATH\n        --for-removal\n        --full-version\n  -? -h --help\n  -l    --list\n        --release {0}\n  -v    --verbose\n        --version

Extra quotes, applies to other localized versions as well. (Usual change we revert)

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 2:

> 1: /*
> 2:  * Copyright (c) 2001, 2023, Oracle and/or its affiliates. All rights reserved.

Looks wrong but is correct. File had its copyright year updated in https://bugs.openjdk.org/browse/JDK-8345800, but the original is still 2023. Translation team is re-syncing it to match the original year.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153314389
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153313105
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153314152

From achung at openjdk.org  Tue Jun 17 23:18:27 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 17 Jun 2025 23:18:27 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <-07gTVUiE_k1Kfc5m2OgDlX6fj1hUMYWZqsSK2YFlYc=.0fc07185-3be2-4f7c-b24f-fca061924170@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

whitespace changes are fixed, PR is ready for review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2982077742

From jlu at openjdk.org  Tue Jun 17 23:24:28 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jun 2025 23:24:28 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <41BnI9ePFiQiYk_COU-Rrpz0qzr33GN0p9AfF38Fkmk=.0d9c1020-d538-41b2-a939-f7e296029ae0@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 30:

> 28: STARNN=*******************************************\n\n
> 29: # keytool: Help part
> 30: .OPTION.=\ [OPTION]...

We spoke about this offline. This is fine, property file values need to either start with a `\ `or `\u0020` to denote intentional leading white space. In this case, since we convert to UTF-8 native characters from escape sequences this gets included as well. Functionally, they are equivalent and the new form works well with the translation process.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153321343

From achung at openjdk.org  Tue Jun 17 23:34:52 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 17 Jun 2025 23:34:52 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  fix unicode escapes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/2dfac379..d8027691

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=00-01

  Stats: 459 lines in 3 files changed: 0 ins; 0 del; 459 mod
  Patch: https://git.openjdk.org/jdk/pull/25839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839

PR: https://git.openjdk.org/jdk/pull/25839

From almatvee at openjdk.org  Tue Jun 17 23:43:28 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 17 Jun 2025 23:43:28 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <uLYnpuvdWyGcO615myaP0lHZ9HMiX9Ag27OnViwh5Ik=.cb34bbec-542b-40a6-98ab-270e2b63bcae@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

jdk.jpackage changes looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2937331933

From bpb at openjdk.org  Wed Jun 18 00:10:08 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Jun 2025 00:10:08 GMT
Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines
Message-ID: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>

Replaces the implementation `readAllCharsAsString().lines().toList()` with reading into a temporary `char` array which is then processed to detect line terminators and copy non-terminating characters into strings which are added to the list.

-------------

Commit messages:
 - 8358533: Improve performance of java.io.Reader.readAllLines

Changes: https://git.openjdk.org/jdk/pull/25863/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25863&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358533
  Stats: 142 lines in 2 files changed: 130 ins; 10 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25863.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25863/head:pull/25863

PR: https://git.openjdk.org/jdk/pull/25863

From bpb at openjdk.org  Wed Jun 18 00:10:08 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Jun 2025 00:10:08 GMT
Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines
In-Reply-To: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
Message-ID: <Focq0-MjOiKoyWCibnMmnyW6alHsYhRVzL8TWrdoLVI=.25f8ea57-7f6f-4e51-a7d2-03bdaae28a15@github.com>

On Wed, 18 Jun 2025 00:04:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replaces the implementation `readAllCharsAsString().lines().toList()` with reading into a temporary `char` array which is then processed to detect line terminators and copy non-terminating characters into strings which are added to the list.

The throughput of the implementation as measured by the included benchmark appears to hover around 13% greater than that of the existing method. The updated method should also have a smaller memory footprint for streams of non-trivial length as it does not first create a single intermediate `String` containing all lines in the stream. Instead it uses a `char` array of size 8192 and a `StringBuilder` whose maximum length will be the length of the longest line in the input.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25863#issuecomment-2982169343

From rriggs at openjdk.org  Wed Jun 18 00:56:35 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Jun 2025 00:56:35 GMT
Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines
In-Reply-To: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
Message-ID: <hHU0EXWuvwHeAI3J_Kaqod4lmlg1PxPRp-bjoQIMxqY=.8d555c08-6aec-4fb2-ab66-6bde86ff91e9@github.com>

On Wed, 18 Jun 2025 00:04:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replaces the implementation `readAllCharsAsString().lines().toList()` with reading into a temporary `char` array which is then processed to detect line terminators and copy non-terminating characters into strings which are added to the list.

src/java.base/share/classes/java/io/Reader.java line 469:

> 467:                     if (c == '\r' || c == '\n')
> 468:                         break;
> 469:                     term++;

It might be worth adding a test of unconventional sequences or \r and \n, including \r\r and \n\n, \r.
The current ReadAll test cover the conventional sequences on Linux and Windows.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2153411639

From bpb at openjdk.org  Wed Jun 18 01:36:27 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Jun 2025 01:36:27 GMT
Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines
In-Reply-To: <hHU0EXWuvwHeAI3J_Kaqod4lmlg1PxPRp-bjoQIMxqY=.8d555c08-6aec-4fb2-ab66-6bde86ff91e9@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <hHU0EXWuvwHeAI3J_Kaqod4lmlg1PxPRp-bjoQIMxqY=.8d555c08-6aec-4fb2-ab66-6bde86ff91e9@github.com>
Message-ID: <Xxm7UWmkDuZ_S5kXIfVmmZhko2fH9fqYgHoxqHDd60Q=.4204a85e-74b4-4bab-ad84-8f1156a857e6@github.com>

On Wed, 18 Jun 2025 00:53:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Replaces the implementation `readAllCharsAsString().lines().toList()` with reading into a temporary `char` array which is then processed to detect line terminators and copy non-terminating characters into strings which are added to the list.
>
> src/java.base/share/classes/java/io/Reader.java line 469:
> 
>> 467:                     if (c == '\r' || c == '\n')
>> 468:                         break;
>> 469:                     term++;
> 
> It might be worth adding a test of unconventional sequences or \r and \n, including \r\r and \n\n, \r.
> The current ReadAll test cover the conventional sequences on Linux and Windows.

I agree. I was intending to follow up on @jaikiran's [comment](https://github.com/openjdk/jdk/pull/24728#discussion_r2112052404), probably in an update to this request.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2153448060

From naoto at openjdk.org  Wed Jun 18 01:56:30 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 01:56:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties line 1:

> 1: #

Just wondering why this resource file has not been translated into de/ja/zh_CN till now. Looks correct though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153463170

From swen at openjdk.org  Wed Jun 18 02:15:39 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 18 Jun 2025 02:15:39 GMT
Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines
In-Reply-To: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
Message-ID: <Y3W505-DbvoQsIy0FDuKykGPohLcgk6ijsF5fsEHVIg=.fbf55769-c9c0-478c-9846-6a0d78156245@github.com>

On Wed, 18 Jun 2025 00:04:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replaces the implementation `readAllCharsAsString().lines().toList()` with reading into a temporary `char` array which is then processed to detect line terminators and copy non-terminating characters into strings which are added to the list.

src/java.base/share/classes/java/io/Reader.java line 492:

> 490:                     // Buffer content consumed so reload it.
> 491:                     if ((n = read(cb, 0, cb.length)) < 0) {
> 492:                         eos = eol = true;

Suggestion:

                        eos = true;

The local variable eol assignment here is not used and can be removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2153483905

From swen at openjdk.org  Wed Jun 18 02:30:32 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 18 Jun 2025 02:30:32 GMT
Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines
In-Reply-To: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
Message-ID: <P6QP6uVrsp1O3PQEuzrKErNEzI-tm2gzKCPGaT19V5s=.67e5df0b-ca23-4a57-81ce-6b01d7e1d0f3@github.com>

On Wed, 18 Jun 2025 00:04:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replaces the implementation `readAllCharsAsString().lines().toList()` with reading into a temporary `char` array which is then processed to detect line terminators and copy non-terminating characters into strings which are added to the list.

src/java.base/share/classes/java/io/Reader.java line 505:

> 503:             }
> 504: 
> 505:             eol = false;

Suggestion:

            }

Same as above, the local variable eol is not used after being assigned and can be removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2153510269

From sherman at openjdk.org  Wed Jun 18 02:36:33 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Wed, 18 Jun 2025 02:36:33 GMT
Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines
In-Reply-To: <Xxm7UWmkDuZ_S5kXIfVmmZhko2fH9fqYgHoxqHDd60Q=.4204a85e-74b4-4bab-ad84-8f1156a857e6@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <hHU0EXWuvwHeAI3J_Kaqod4lmlg1PxPRp-bjoQIMxqY=.8d555c08-6aec-4fb2-ab66-6bde86ff91e9@github.com>
 <Xxm7UWmkDuZ_S5kXIfVmmZhko2fH9fqYgHoxqHDd60Q=.4204a85e-74b4-4bab-ad84-8f1156a857e6@github.com>
Message-ID: <xEDWkYkryzrtiIo0yiaOKgrl8C9kjzr_0JIsuxY4BB8=.f81538a6-f26c-4f82-92d5-fbe4c4884558@github.com>

On Wed, 18 Jun 2025 01:34:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 469:
>> 
>>> 467:                     if (c == '\r' || c == '\n')
>>> 468:                         break;
>>> 469:                     term++;
>> 
>> It might be worth adding a test of unconventional sequences or \r and \n, including \r\r and \n\n, \r.
>> The current ReadAll test cover the conventional sequences on Linux and Windows.
>
> I agree. I was intending to follow up on @jaikiran's [comment](https://github.com/openjdk/jdk/pull/24728#discussion_r2112052404), probably in an update to this request.

I think we should treat "\r\n" as a single line terminator? for example

 "hello\r\nworld".lines().forEach(line -> out.format("[%s]\n", line));
=>
[hello]
[world]

instead of 

[hello]
[]
[world]

or I misread the impl?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2153515129

From liach at openjdk.org  Wed Jun 18 02:42:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 18 Jun 2025 02:42:38 GMT
Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines
In-Reply-To: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
Message-ID: <EzaE4fjURV7jR4ihkgSJZiemmZw813zLQ3IOWAUmdqA=.29d77e27-5a9d-4931-adca-11064ffd4fe5@github.com>

On Wed, 18 Jun 2025 00:04:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replaces the implementation `readAllCharsAsString().lines().toList()` with reading into a temporary `char` array which is then processed to detect line terminators and copy non-terminating characters into strings which are added to the list.

src/java.base/share/classes/java/io/Reader.java line 453:

> 451:         char[] cb = new char[TRANSFER_BUFFER_SIZE];
> 452:         int pos = 0;
> 453:         List<String> lines = new ArrayList<String>();

Suggestion:

        List<String> lines = new ArrayList<>();

src/java.base/share/classes/java/io/Reader.java line 455:

> 453:         List<String> lines = new ArrayList<String>();
> 454: 
> 455:         StringBuilder sb = new StringBuilder(82);

Is there a reason for this pre-allocation? If the whole content is smaller than 8192 in size, this allocation would be redundant because we are going through the string constructor path.

src/java.base/share/classes/java/io/Reader.java line 499:

> 497:             }
> 498: 
> 499:             if (!stringAdded) {

Can we change the maintenancce of `stringAdded` condition to a check `sb.length() == 0`?

Edit: No, we need to check empty lines.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2153505559
PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2153509369
PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2153518622

From jpai at openjdk.org  Wed Jun 18 04:30:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Jun 2025 04:30:28 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v7]
In-Reply-To: <EkTXfBg5WUXUSPG_xQByoXKHWdmPellpe8uZps3EmTQ=.dfdff0aa-8ffc-4478-b978-c3b3b4f926f0@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <EkTXfBg5WUXUSPG_xQByoXKHWdmPellpe8uZps3EmTQ=.dfdff0aa-8ffc-4478-b978-c3b3b4f926f0@github.com>
Message-ID: <x1MoIFidC0DUYfvKjOTErRfUErtUWArhx5zq8caSY2A=.0428682a-c2e6-43d2-8cad-38f82afb9801@github.com>

On Tue, 17 Jun 2025 21:47:49 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
>> 
>> `testclasses.jar` is updated such that the two classes no longer extend Applet.
>> 
>> 
>> $ javap fo\ o.class 
>> public class fo o {
>> }
>> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
>> public class ?? {
>> }
>> 
>> 
>> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
>> 
>> Additionally, the security APIs that were marked for removal are also removed from this test as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SB -> String

Thank you for the updates Justin. This looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25703#pullrequestreview-2937689042

From dholmes at openjdk.org  Wed Jun 18 04:43:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Jun 2025 04:43:29 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
Message-ID: <_aliNvujYU-gs7CUS7oB8VPK595xV4OLnd82vJwYTIY=.6b041c7e-3907-4217-b8ef-a59404ac0a08@github.com>

On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

>> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
>> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
>> 
>> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.
>
> Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print
>  - Update test/lib/jdk/test/lib/process/OutputBuffer.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Initial working solution

> A lot of tests use the test.debug system property to enable more verbose test output. It's enabled when someone runs the test e.g., jtreg -Dtest.debug=true ...

I see a few tests that do that, nearly all of which are network tests. It is not something I was familiar with. But it doesn't seem right to me that a particular test would use that property to change the behaviour of `OutputAnalyzer`. I also don't think the test should have to opt-in to this kind of behaviour rather than it being directly controlled by the person running the tests. To that end I would see `OutputAnalyzer` examining a  specific property, e.g. `OutputAnalyzer.printToStdStreams` to control this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25587#issuecomment-2982650756

From admin at iseki.space  Fri Jun 13 09:45:21 2025
From: admin at iseki.space (iseki zero)
Date: Fri, 13 Jun 2025 17:45:21 +0800
Subject: We should convert ERROR_PRIVILEGE_NOT_HELD to AccessDeniedException
Message-ID: <dc02e100-9c32-4f06-8555-b464e07c2fe7@iseki.space>

Hello maintainers,

When we access a file that requires UAC upgrade on Windows, we will get 
error code ERROR_PRIVILEGE_NOT_HELD. But the 
src/java.base/windows/classes/sun/nio/fs/WindowsException.java haven't 
convert the error code to AccessDeniedException.

In 2 years ago I opened a PR on github 
https://github.com/openjdk/jdk/pull/15221, should I continue work for it?

Thank you.

iseki zero


From iris at openjdk.org  Wed Jun 18 05:27:29 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 18 Jun 2025 05:27:29 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page [v4]
In-Reply-To: <lXq4ACbyvuBmykAmVhQUrp9WtmMFZTvpT8Fd5AH2wZY=.b646f5b8-3e4d-4fd6-ae8d-d63c1067fb81@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
 <lXq4ACbyvuBmykAmVhQUrp9WtmMFZTvpT8Fd5AH2wZY=.b646f5b8-3e4d-4fd6-ae8d-d63c1067fb81@github.com>
Message-ID: <WD5ZXOfsRGDfWJtc8DX2tgbhc80Bnyirb-OkXdK3cjk=.d973f54e-a404-45f9-a6ec-d12de1fc3702@github.com>

On Tue, 17 Jun 2025 17:08:17 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> Please review my PR. This PR includes the following:
>> 
>> - [x] Fix a small typo in a word and copyright.
>> - [x] Enhance description for `--target-platform`.
>> - [x] Rearrange `jmod create` example from basic to complex.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update commands and description according to review.

Changes look good to me.

@AlanBateman any further comments/concerns?

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25772#pullrequestreview-2937772445

From enikitin at openjdk.org  Wed Jun 18 06:04:16 2025
From: enikitin at openjdk.org (Evgeny Nikitin)
Date: Wed, 18 Jun 2025 06:04:16 GMT
Subject: RFR: 8357739: [jittester] disable the hashCode method
Message-ID: <k0n2iREsDglQSchu2_XPV6lEw5eAZ6Q8jixAwibKs6w=.178844b9-d457-42ef-9f8f-9e9f6de530ab@github.com>

JITTester often uses the `hasCode` method (in fact, in almost every generated test). Given that the method can be unstable between runs or in interpreted vs compiled runs, it can create false-positives.

This PR fixes the issue by adding support for method templates similar to the ones used in CompilerCommands). All of those exclude templates match (and exclude) `String.indexOf(String)`, for example:

java/lang/::*(Ljava/lang/String;I)
*String::indexOf(*)
java/lang/*::indexOf


Additionally, the PR adds support for comments (starting from '#') and empty lines in the excludes file.

-------------

Commit messages:
 - Add unit tests
 - 8357739: [jittester] disable the hashCode method

Changes: https://git.openjdk.org/jdk/pull/25859/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25859&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357739
  Stats: 556 lines in 4 files changed: 402 ins; 121 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/25859.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25859/head:pull/25859

PR: https://git.openjdk.org/jdk/pull/25859

From jpai at openjdk.org  Wed Jun 18 06:07:14 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Jun 2025 06:07:14 GMT
Subject: RFR: 8359830: Incorrect os.version reported on macOS Tahoe 26 (Beta)
Message-ID: <dIYjIn7ZiNM0p0D0nTJN-B08KdxqZ-pPO__CRNrhgY0=.2f533c49-a9c1-4a03-9d69-eb747ef3e8a9@github.com>

Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8359830?

macOS operating system's newer version 26 (currently in Beta) is reported as a 16 by older versions of XCode. JDK internally uses the `NSProcessInfo` and `NSOperatingSystemVersion` APIs to identify the macOS version and set the `os.version` system property to that value. The current recommended version to build the JDK on macOS is XCode 15.4. The `NSOperatingSystemVersion` API on that version of XCode reports macOS version as 16 instead of 26.

The commit in this PR updates the JDK code to handle this mismatch and set the `os.version` appropriately to 26. This fix is similar to what we did with macOS BigSur when the macOS version 10.16 was meant to mean 11 https://bugs.openjdk.org/browse/JDK-8253702. 

The existing `OsVersionTest` has been updated for some trivial clean up. Existing tests in tier1, tier2 and tier3 continue to pass with this change. If anyone has access to a macOS 26 Beta, I request them to build this change and run `tier1` tests to help verify that there aren't any failures.

-------------

Commit messages:
 - update test
 - 8359830: Incorrect os.version reported on macOS Tahoe 26 (Beta)

Changes: https://git.openjdk.org/jdk/pull/25865/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25865&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359830
  Stats: 72 lines in 2 files changed: 34 ins; 13 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/25865.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25865/head:pull/25865

PR: https://git.openjdk.org/jdk/pull/25865

From tschatzl at openjdk.org  Wed Jun 18 06:48:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 18 Jun 2025 06:48:38 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v11]
In-Reply-To: <RHurPYBFXHy5WRNAU3Gw026di7-xtOox6ftoN9sxcX0=.e96117f3-ba8f-4365-a53e-92d003f5d92d@github.com>
References: <Tu8M7LFhMuV-c2h4vzClnqRt33B4rbvNUgPl0_8a6Dk=.f82c6c6f-270d-4400-8b4b-e178f8464f9d@github.com>
 <RHurPYBFXHy5WRNAU3Gw026di7-xtOox6ftoN9sxcX0=.e96117f3-ba8f-4365-a53e-92d003f5d92d@github.com>
Message-ID: <exAn6uUVfpyGaWEuw_kCSvRUr0NBr5LTbfoMcVnQM6Y=.d4040e19-1df1-439a-b023-0ff1058c42b8@github.com>

On Mon, 16 Jun 2025 07:09:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change which adds a native method providing the
>> implementation of Reference::get.  Referece::get is an intrinsic candidate, so
>> this native method implementation is only used when the intrinsic is not.
>> 
>> Currently there is intrinsic support by the interpreter, C1, C2, and graal,
>> which are always used.  With this change we can later remove all the
>> per-platform interpreter intrinsic implementations, and might also remove the
>> C1 intrinsic implementation.
>> 
>> Testing:
>> (1) mach5 tier1-6 normal (so using all the existing intrinsics).
>> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge branch 'master' into native-reference-get
>  - add pseudo-native entry for Reference.get0
>  - tidy CallGenerator lookup in Compile ctor
>  - fix comment alignment
>  - Merge branch 'master' into native-reference-get
>  - make private native Reference.get0 the intrinsic
>  - Merge branch 'master' into native-reference-get
>  - Merge branch 'master' into native-reference-get
>  - use new waitForRefProc, some tidying
>  - Merge branch 'master' into native-reference-get
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/3be7ee90...877e64ca

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24315#pullrequestreview-2937932097

From alanb at openjdk.org  Wed Jun 18 07:05:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jun 2025 07:05:44 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page [v4]
In-Reply-To: <lXq4ACbyvuBmykAmVhQUrp9WtmMFZTvpT8Fd5AH2wZY=.b646f5b8-3e4d-4fd6-ae8d-d63c1067fb81@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
 <lXq4ACbyvuBmykAmVhQUrp9WtmMFZTvpT8Fd5AH2wZY=.b646f5b8-3e4d-4fd6-ae8d-d63c1067fb81@github.com>
Message-ID: <MV7BKVHqz4UVEZrYS-Qi8OnItIcbJbYqeCsDSEgHrmg=.1d2565a0-9eb8-45b2-a659-7e5cfb171710@github.com>

On Tue, 17 Jun 2025 17:08:17 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> Please review my PR. This PR includes the following:
>> 
>> - [x] Fix a small typo in a word and copyright.
>> - [x] Enhance description for `--target-platform`.
>> - [x] Rearrange `jmod create` example from basic to complex.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update commands and description according to review.

src/jdk.jlink/share/man/jmod.md line 186:

> 184:     the format `<os>-<arch>`, where `<os>` is the operating system
> 185:     and `<arch>` is the hardware architecture. Example values include
> 186:     `linux-x64`, `windows-x64`, and `macos-aarch64`.

The values for x64 are actually linux-amd64 and windows-amd64.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2153806868

From vyazici at openjdk.org  Wed Jun 18 07:10:27 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 18 Jun 2025 07:10:27 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <cyKIsynr19VsmvHUmvEFP9RP56GFxojjJVQezBM41lg=.1aea0985-9284-43b7-8537-6a46149de0fd@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

I've verified that all relevant occurrences of `std{in,err,out}.encoding` are covered, except the ones `src/java.base/share/classes/java/lang/System.java`, which, I presume, is left out intentionally.

-------------

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25860#pullrequestreview-2937989243

From duke at openjdk.org  Wed Jun 18 07:17:13 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Wed, 18 Jun 2025 07:17:13 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page [v5]
In-Reply-To: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
Message-ID: <Ry0rKlbTVL-dejGVtVpSRl4WTmowF6yVsTmOM1lh_hk=.8129a6c0-13e8-4ede-922b-f61a1f2fc783@github.com>

> Please review my PR. This PR includes the following:
> 
> - [x] Fix a small typo in a word and copyright.
> - [x] Enhance description for `--target-platform`.
> - [x] Rearrange `jmod create` example from basic to complex.

Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:

  Update values for Linux and Windows examples.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25772/files
  - new: https://git.openjdk.org/jdk/pull/25772/files/27052ebb..04131e9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25772&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25772&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25772/head:pull/25772

PR: https://git.openjdk.org/jdk/pull/25772

From duke at openjdk.org  Wed Jun 18 07:17:13 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Wed, 18 Jun 2025 07:17:13 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page [v4]
In-Reply-To: <MV7BKVHqz4UVEZrYS-Qi8OnItIcbJbYqeCsDSEgHrmg=.1d2565a0-9eb8-45b2-a659-7e5cfb171710@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
 <lXq4ACbyvuBmykAmVhQUrp9WtmMFZTvpT8Fd5AH2wZY=.b646f5b8-3e4d-4fd6-ae8d-d63c1067fb81@github.com>
 <MV7BKVHqz4UVEZrYS-Qi8OnItIcbJbYqeCsDSEgHrmg=.1d2565a0-9eb8-45b2-a659-7e5cfb171710@github.com>
Message-ID: <KudMCkT7argnCSR8TnPbXIt1FpF9oNdyFSH4uHSIVmw=.195b8484-4991-4075-8a1f-c29ba338a668@github.com>

On Wed, 18 Jun 2025 07:02:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update commands and description according to review.
>
> src/jdk.jlink/share/man/jmod.md line 186:
> 
>> 184:     the format `<os>-<arch>`, where `<os>` is the operating system
>> 185:     and `<arch>` is the hardware architecture. Example values include
>> 186:     `linux-x64`, `windows-x64`, and `macos-aarch64`.
> 
> The values for x64 are actually linux-amd64 and windows-amd64.

I updated the values.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25772#discussion_r2153825262

From alanb at openjdk.org  Wed Jun 18 07:41:31 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jun 2025 07:41:31 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page [v5]
In-Reply-To: <Ry0rKlbTVL-dejGVtVpSRl4WTmowF6yVsTmOM1lh_hk=.8129a6c0-13e8-4ede-922b-f61a1f2fc783@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
 <Ry0rKlbTVL-dejGVtVpSRl4WTmowF6yVsTmOM1lh_hk=.8129a6c0-13e8-4ede-922b-f61a1f2fc783@github.com>
Message-ID: <uQ_KrFD8olKSf3Lny8_WPSgdJiAZ1THs13Kkxv4Shvs=.88ebbca8-c47a-46a4-9804-b2b53a0cd289@github.com>

On Wed, 18 Jun 2025 07:17:13 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> Please review my PR. This PR includes the following:
>> 
>> - [x] Fix a small typo in a word and copyright.
>> - [x] Enhance description for `--target-platform`.
>> - [x] Rearrange `jmod create` example from basic to complex.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update values for Linux and Windows examples.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25772#pullrequestreview-2938079356

From cstein at openjdk.org  Wed Jun 18 07:44:29 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 18 Jun 2025 07:44:29 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page [v5]
In-Reply-To: <Ry0rKlbTVL-dejGVtVpSRl4WTmowF6yVsTmOM1lh_hk=.8129a6c0-13e8-4ede-922b-f61a1f2fc783@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
 <Ry0rKlbTVL-dejGVtVpSRl4WTmowF6yVsTmOM1lh_hk=.8129a6c0-13e8-4ede-922b-f61a1f2fc783@github.com>
Message-ID: <_sitmgEahUgf3YNB5zFpU2sid-WvBPv9MwtYQzQ17t0=.44c47fe5-e6d2-47d5-9c13-f1d587b248fa@github.com>

On Wed, 18 Jun 2025 07:17:13 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> Please review my PR. This PR includes the following:
>> 
>> - [x] Fix a small typo in a word and copyright.
>> - [x] Enhance description for `--target-platform`.
>> - [x] Rearrange `jmod create` example from basic to complex.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update values for Linux and Windows examples.

Marked as reviewed by cstein (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25772#pullrequestreview-2938093537

From alanb at openjdk.org  Wed Jun 18 07:55:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jun 2025 07:55:28 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <dViJkSq-Fnckq_r2ODs-kuYsCDfGhe2rX3BZS9h255c=.ae48363a-f6a2-4b91-9455-c66c512f303a@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

src/java.base/share/classes/module-info.java line 287:

> 285:         jdk.jpackage,
> 286:         jdk.jshell,
> 287:         jdk.net;

At some point we will need to re-visit all these qualified exports so that java.base exports as few of these internal packages as possible.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 111:

> 109: 
> 110: 
> 111:         Charset charset = Charset.forName(StaticProperty.stdinEncoding(), Charset.defaultCharset());

This is the jhsdb tool, just wondering why it needs to be changed.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java line 802:

> 800:         }
> 801:         try {
> 802:             Charset charset = Charset.forName(StaticProperty.stdinEncoding(), Charset.defaultCharset());

This is the example jdb debugger, I assume okay to let it read the stdin.encoding property.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153907749
PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153910478
PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153913162

From alanb at openjdk.org  Wed Jun 18 07:59:27 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jun 2025 07:59:27 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <HS_moiW1ZXnwCePhJrtlJTtiwO37FEHMKxldVBPgDcw=.d649f3bf-3ce2-44d9-bc5c-9ed5f74b333d@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

src/java.scripting/share/classes/javax/script/SimpleScriptContext.java line 100:

> 98: 
> 99:     private static InputStreamReader stdinReader() {
> 100:         Charset charset = Charset.forName(StaticProperty.stdinEncoding(), Charset.defaultCharset());

This is the jrunscript command line tool. I suppose it's possible it could run a script that changes stdin.encoding.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153921907

From nbenalla at openjdk.org  Wed Jun 18 08:24:09 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 18 Jun 2025 08:24:09 GMT
Subject: RFR: 8358627:
 tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 26
Message-ID: <mcPF1ypiHlYI3H4kgl0bwvU3KF_YO40Yo6aY6w1LX4c=.4376bebf-3397-4354-be3e-9fd0719b24db@github.com>

Once [8346295](https://bugs.openjdk.org/browse/JDK-8346295) is resolved, JavaBaseCheckSince no longer needs to be problemlisted.

-------------

Depends on: https://git.openjdk.org/jdk/pull/25854

Commit messages:
 - this test no longer needs to be problem listed

Changes: https://git.openjdk.org/jdk/pull/25855/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25855&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358627
  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25855.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25855/head:pull/25855

PR: https://git.openjdk.org/jdk/pull/25855

From syan at openjdk.org  Wed Jun 18 08:24:09 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 18 Jun 2025 08:24:09 GMT
Subject: RFR: 8358627:
 tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 26
In-Reply-To: <mcPF1ypiHlYI3H4kgl0bwvU3KF_YO40Yo6aY6w1LX4c=.4376bebf-3397-4354-be3e-9fd0719b24db@github.com>
References: <mcPF1ypiHlYI3H4kgl0bwvU3KF_YO40Yo6aY6w1LX4c=.4376bebf-3397-4354-be3e-9fd0719b24db@github.com>
Message-ID: <pIXyfeX8Y6s_SUXaHrHY0qtGEWiKtsDC8XKO-XYX4oE=.bd768ada-25e9-4e63-a3a2-a8c1a700c012@github.com>

On Tue, 17 Jun 2025 15:22:24 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Once [8346295](https://bugs.openjdk.org/browse/JDK-8346295) is resolved, JavaBaseCheckSince no longer needs to be problemlisted.

Marked as reviewed by syan (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25855#pullrequestreview-2937604336

From nbenalla at openjdk.org  Wed Jun 18 09:08:29 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 18 Jun 2025 09:08:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <xcSAVqLxI2phW8UCEHcDpUMeFySiy0zigXx-MPkt5aU=.0c203d6f-60e1-41d1-82d5-a93bba898f5f@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

I'm unable to confirm the accuracy of the translations, since I don't speak the target languages. I've only reviewed the `jdk.javadoc` sources.

All keys in the English property files match one-to-one with those in the non-English files: there are no missing or extra entries. The only changes are to the `.properties` files, exactly as the PR title suggests.

>From the `jdk.javadoc` perspective, this looks good, so I'm happy to approve this PR.

-------------

Marked as reviewed by nbenalla (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2938377311

From swen at openjdk.org  Wed Jun 18 09:22:29 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 18 Jun 2025 09:22:29 GMT
Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines
In-Reply-To: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
Message-ID: <kUOGoenuuC7O-40Q-zxQWpeSKFp0i9gSB0Fh7SfVeF8=.b5e6a6ac-29b8-449f-a68d-0230688f51ba@github.com>

On Wed, 18 Jun 2025 00:04:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replaces the implementation `readAllCharsAsString().lines().toList()` with reading into a temporary `char` array which is then processed to detect line terminators and copy non-terminating characters into strings which are added to the list.

If we want better performance, we should go a step further and overload the readAllLines method in the Reader implementation class.

For example, in the most commonly used InputStreamReader, overload readAllLines through StreamDecoder and make special optimizations for UTF8/ISO_8859_1 encoding.

In StringReader, special overload methods can also be used for optimization.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25863#issuecomment-2983379522

From duke at openjdk.org  Wed Jun 18 09:41:35 2025
From: duke at openjdk.org (duke)
Date: Wed, 18 Jun 2025 09:41:35 GMT
Subject: Withdrawn: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
Message-ID: <2x0dTfpcu1MdxTVpRSizOlN_dEsobjFzk2uXRNu3-D0=.06f77c08-90d1-4b0c-8aab-603eb1d530bb@github.com>

On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
> 
> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
> 
> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24242

From jsikstro at openjdk.org  Wed Jun 18 09:50:30 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 18 Jun 2025 09:50:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <zJCQh_R1fU5XdBZNfVyW5e-hk_mRcfnjPASPqzu-t3s=.8b34a54f-3ae2-4516-a2b6-d5c32b3891b8@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

Should the other localizations for the launcher help text (in `launcher_<lang>.properties`) also be updated? I see that only the German, Japanese and Chinese localizations have been updated so far.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2983504760

From dl at openjdk.org  Wed Jun 18 11:12:28 2025
From: dl at openjdk.org (Doug Lea)
Date: Wed, 18 Jun 2025 11:12:28 GMT
Subject: RFR: 8359067: Fix typo in DelayScheduler.java
In-Reply-To: <CvaLMuKZ72CTQVOaAxeJyS8pGWcbev9SwyTkwpiSiBs=.61a0a2ce-6816-45a0-bd84-85c6ed7ecf23@github.com>
References: <CvaLMuKZ72CTQVOaAxeJyS8pGWcbev9SwyTkwpiSiBs=.61a0a2ce-6816-45a0-bd84-85c6ed7ecf23@github.com>
Message-ID: <XB61rsaT0f8pZLFi9v6MSERVzmaoRE0V22H7gASLk_0=.1ebce99c-8b8d-4881-89d3-eb21c4efc123@github.com>

On Sun, 8 Jun 2025 09:07:11 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

> Rename auxilliary to  auxiliary

@He-Pin please /integrate

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25685#issuecomment-2983757923

From duke at openjdk.org  Wed Jun 18 11:28:31 2025
From: duke at openjdk.org (He-Pin (kerr))
Date: Wed, 18 Jun 2025 11:28:31 GMT
Subject: Integrated: 8359067: Fix typo in DelayScheduler.java
In-Reply-To: <CvaLMuKZ72CTQVOaAxeJyS8pGWcbev9SwyTkwpiSiBs=.61a0a2ce-6816-45a0-bd84-85c6ed7ecf23@github.com>
References: <CvaLMuKZ72CTQVOaAxeJyS8pGWcbev9SwyTkwpiSiBs=.61a0a2ce-6816-45a0-bd84-85c6ed7ecf23@github.com>
Message-ID: <2KU-0R0HNUFhPk8_0vVdETLHiBgnRU4XQlNqesNole4=.3127811b-d919-4491-b662-f945742b1add@github.com>

On Sun, 8 Jun 2025 09:07:11 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

> Rename auxilliary to  auxiliary

This pull request has now been integrated.

Changeset: f07f5ce9
Author:    He-Pin(kerr) <hepin1989 at gmail.com>
Committer: Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f07f5ce9845c59348dc785cd5ee26391dd7e36c8
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8359067: Fix typo in DelayScheduler.java

Reviewed-by: syan, dl, rriggs, vklang

-------------

PR: https://git.openjdk.org/jdk/pull/25685

From pavel.rappo at gmail.com  Wed Jun 18 11:29:23 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Wed, 18 Jun 2025 12:29:23 +0100
Subject: On Period and DateTimeFormatter
Message-ID: <CAChcVuk=VsLQN6sm4SBd2XKbW_m3+rBrxkx4QxsG7rT10KHiJw@mail.gmail.com>

Hello, I have two questions on java.time API.

The first one is about documentation for java.time.Period. When I get
back to the API after a long period (no pun intended) of not using it,
it takes me a while to recall that Period does __NOT__ model an
interval between two specific points in time, such as vacation dates.
And the signature of the Period.between(LocalDate, LocalDate) method
makes it even harder.

I'm not sure what it is. Is it because I'm a non-native English
speaker or it's some idiosyncrasy? Anyway, if it's not just me, then
my question is: would it make sense to provide a few short and punchy
notes to the reader to quickly rectify this misconception that might
be forming in their head while they are reading the documentation?
Sometimes it's helpful to say what something isn't in addition to
saying what something is.


The second question is about DateTimeFormatter. I recently had to
parse a date that resembles output of asctime: Sat Jul 16 02:03:55
+0000 1994. It's fine and dandy until you parse a date in September.
That time format expects "Sep", while the formatter expects "Sept".

Now, I'm aware that it's a known issue [^1]. Still, I wonder if we can
do anything better than suggest using a specific locale, which is not
bulletproof, or going to the DateTimeFormatterBuilder route.

Thanks,
-Pavel

[^1]: See https://bugs.openjdk.org/browse/JDK-8256837 and its numerous
duplicates.

From jpai at openjdk.org  Wed Jun 18 13:57:30 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Jun 2025 13:57:30 GMT
Subject: RFR: 8359830: Incorrect os.version reported on macOS Tahoe 26
 (Beta)
In-Reply-To: <dIYjIn7ZiNM0p0D0nTJN-B08KdxqZ-pPO__CRNrhgY0=.2f533c49-a9c1-4a03-9d69-eb747ef3e8a9@github.com>
References: <dIYjIn7ZiNM0p0D0nTJN-B08KdxqZ-pPO__CRNrhgY0=.2f533c49-a9c1-4a03-9d69-eb747ef3e8a9@github.com>
Message-ID: <Og7IVgx30KGjI_M3SyH6wDOK-n9IezhqMJW3S8BTdqs=.d7e188e9-6d5a-4c21-8099-70c0c396d0d6@github.com>

On Wed, 18 Jun 2025 06:01:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Existing tests in tier1, tier2 and tier3 continue to pass with this change. If anyone has access to a macOS 26 Beta, I request them to build this change and run tier1 tests to help verify that there aren't any failures.

I got access to a macOS 26 Beta and ran `tier1` tests on it with this change. The tests completed fine. Only one CDS test is failing `runtime/cds/DeterministicDump.java`, but that doesn't look related to this change (I haven't completed analyzed that failure so far):


==============================
Test summary
==============================
   TEST                                         TOTAL  PASS  FAIL ERROR  SKIP   
>> jtreg:test/hotspot/jtreg:tier1                3022  2574     1     0   447 <<
   jtreg:test/jdk:tier1                          2525  2469     0     0    56   
   jtreg:test/langtools:tier1                    4651  4642     0     0     9   
   jtreg:test/jaxp:tier1                            0     0     0     0     0   
   jtreg:test/lib-test:tier1                       37    37     0     0     0   
==============================

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25865#issuecomment-2984324205

From bpb at openjdk.org  Wed Jun 18 14:36:29 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Jun 2025 14:36:29 GMT
Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines
In-Reply-To: <kUOGoenuuC7O-40Q-zxQWpeSKFp0i9gSB0Fh7SfVeF8=.b5e6a6ac-29b8-449f-a68d-0230688f51ba@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <kUOGoenuuC7O-40Q-zxQWpeSKFp0i9gSB0Fh7SfVeF8=.b5e6a6ac-29b8-449f-a68d-0230688f51ba@github.com>
Message-ID: <jp6vr4PS99XIAVYZWpzUvGLhiFRJb2QruqQPvgMEsqM=.bc998c23-95b0-4781-b00b-73a0e303e96d@github.com>

On Wed, 18 Jun 2025 09:20:12 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> If we want better performance, we should go a step further and overload the readAllLines method in the Reader implementation class.

Perhaps, but not in this request. A separate issue should be filed and addressed subsequently.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25863#issuecomment-2984472407

From rriggs at openjdk.org  Wed Jun 18 14:56:30 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Jun 2025 14:56:30 GMT
Subject: RFR: 8359830: Incorrect os.version reported on macOS Tahoe 26
 (Beta)
In-Reply-To: <dIYjIn7ZiNM0p0D0nTJN-B08KdxqZ-pPO__CRNrhgY0=.2f533c49-a9c1-4a03-9d69-eb747ef3e8a9@github.com>
References: <dIYjIn7ZiNM0p0D0nTJN-B08KdxqZ-pPO__CRNrhgY0=.2f533c49-a9c1-4a03-9d69-eb747ef3e8a9@github.com>
Message-ID: <5PdHjR2w8-UR-TbEIXpyduqq4tb9Ky12wQWUzYDLp2E=.0faae087-bf43-4938-bf4f-02db359900c0@github.com>

On Wed, 18 Jun 2025 06:01:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8359830?
> 
> macOS operating system's newer version 26 (currently in Beta) is reported as a 16 by older versions of XCode. JDK internally uses the `NSProcessInfo` and `NSOperatingSystemVersion` APIs to identify the macOS version and set the `os.version` system property to that value. The current recommended version to build the JDK on macOS is XCode 15.4. The `NSOperatingSystemVersion` API on that version of XCode reports macOS version as 16 instead of 26.
> 
> The commit in this PR updates the JDK code to handle this mismatch and set the `os.version` appropriately to 26. This fix is similar to what we did with macOS BigSur when the macOS version 10.16 was meant to mean 11 https://bugs.openjdk.org/browse/JDK-8253702. 
> 
> The existing `OsVersionTest` has been updated for some trivial clean up. Existing tests in tier1, tier2 and tier3 continue to pass with this change. If anyone has access to a macOS 26 Beta, I request them to build this change and run `tier1` tests to help verify that there aren't any failures.

Looks good.  Give it a day or so for others to review.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25865#pullrequestreview-2939582763

From rriggs at openjdk.org  Wed Jun 18 15:08:28 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Jun 2025 15:08:28 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <LbRBF6gknL_SsjFh_wALuLuFGTOFzDNYTUikL7MbvA8=.f0b9e433-da69-4280-9a3d-9150dfaa1b80@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

Static properties should not be used outside of java.base.
The "for internal use only" should have said "java.base internal use only"
Adding a comment to that effect would be a good idea.

-------------

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25860#pullrequestreview-2939624079

From rriggs at openjdk.org  Wed Jun 18 15:08:30 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Jun 2025 15:08:30 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <dViJkSq-Fnckq_r2ODs-kuYsCDfGhe2rX3BZS9h255c=.ae48363a-f6a2-4b91-9455-c66c512f303a@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
 <dViJkSq-Fnckq_r2ODs-kuYsCDfGhe2rX3BZS9h255c=.ae48363a-f6a2-4b91-9455-c66c512f303a@github.com>
Message-ID: <0gpDp3XapnEa-4BfqTDt7AAHV7_qDLoKHy3-2xzJ7ro=.faa1279d-82a8-4a68-a026-94f325f904e7@github.com>

On Wed, 18 Jun 2025 07:50:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.
>
> src/java.base/share/classes/module-info.java line 287:
> 
>> 285:         jdk.jpackage,
>> 286:         jdk.jshell,
>> 287:         jdk.net;
> 
> At some point we will need to re-visit all these qualified exports so that java.base exports as few of these internal packages as possible.

The original intent of StaticProperties was to limit it to the base module.
Other modules are free to read the property themselves.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2154852609

From davidalayachew at gmail.com  Wed Jun 18 15:15:26 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 18 Jun 2025 11:15:26 -0400
Subject: On Period and DateTimeFormatter
In-Reply-To: <CAChcVuk=VsLQN6sm4SBd2XKbW_m3+rBrxkx4QxsG7rT10KHiJw@mail.gmail.com>
References: <CAChcVuk=VsLQN6sm4SBd2XKbW_m3+rBrxkx4QxsG7rT10KHiJw@mail.gmail.com>
Message-ID: <CAA9v-_MrBWFJBhTorti+THwTecrQpYQi8+hh6EzxbaF+pA3Cbw@mail.gmail.com>

How does it not model an interval?

Here is the official documentation.

*Obtains a Period consisting of the number of years, months, and days
between two dates.*

https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/time/Period.html#between(java.time.LocalDate,java.time.LocalDate)

And here is the dictionary definition.

*a space of time between events or states*

https://www.merriam-webster.com/dictionary/interval

On Wed, Jun 18, 2025, 7:30?AM Pavel Rappo <pavel.rappo at gmail.com> wrote:

> Hello, I have two questions on java.time API.
>
> The first one is about documentation for java.time.Period. When I get
> back to the API after a long period (no pun intended) of not using it,
> it takes me a while to recall that Period does __NOT__ model an
> interval between two specific points in time, such as vacation dates.
> And the signature of the Period.between(LocalDate, LocalDate) method
> makes it even harder.
>
> I'm not sure what it is. Is it because I'm a non-native English
> speaker or it's some idiosyncrasy? Anyway, if it's not just me, then
> my question is: would it make sense to provide a few short and punchy
> notes to the reader to quickly rectify this misconception that might
> be forming in their head while they are reading the documentation?
> Sometimes it's helpful to say what something isn't in addition to
> saying what something is.
>
>
> The second question is about DateTimeFormatter. I recently had to
> parse a date that resembles output of asctime: Sat Jul 16 02:03:55
> +0000 1994. It's fine and dandy until you parse a date in September.
> That time format expects "Sep", while the formatter expects "Sept".
>
> Now, I'm aware that it's a known issue [^1]. Still, I wonder if we can
> do anything better than suggest using a specific locale, which is not
> bulletproof, or going to the DateTimeFormatterBuilder route.
>
> Thanks,
> -Pavel
>
> [^1]: See https://bugs.openjdk.org/browse/JDK-8256837 and its numerous
> duplicates.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250618/21656a4c/attachment-0001.htm>

From lancea at openjdk.org  Wed Jun 18 15:37:31 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 18 Jun 2025 15:37:31 GMT
Subject: RFR: 8358729:
 jdk/internal/loader/URLClassPath/ClassnameCharTest.java depends on Applet [v7]
In-Reply-To: <EkTXfBg5WUXUSPG_xQByoXKHWdmPellpe8uZps3EmTQ=.dfdff0aa-8ffc-4478-b978-c3b3b4f926f0@github.com>
References: <83bm-oTmcBvWgwYPQN2L7YuCyOu8wDgCT4YUkq1e3fg=.f3b2e909-b4c0-4f4c-9df8-9b427c952d09@github.com>
 <EkTXfBg5WUXUSPG_xQByoXKHWdmPellpe8uZps3EmTQ=.dfdff0aa-8ffc-4478-b978-c3b3b4f926f0@github.com>
Message-ID: <5TzS7H_06QjScHrjTd9G1ZS8nLkvCHhDOSJNm04-BTY=.75e7f296-3354-424b-9e8a-9624d0c55cda@github.com>

On Tue, 17 Jun 2025 21:47:49 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which finishes Applet removal for the test: jdk/internal/loader/URLClassPath/ClassnameCharTest.java.
>> 
>> `testclasses.jar` is updated such that the two classes no longer extend Applet.
>> 
>> 
>> $ javap fo\ o.class 
>> public class fo o {
>> }
>> $ javap ?$'\302\211'$'\302\213'?$'\302\206'$'\302\214'.class 
>> public class ?? {
>> }
>> 
>> 
>> The bug description of [JDK-8358729](https://bugs.openjdk.org/browse/JDK-8358729) contains the original `javap` output for those classes.
>> 
>> Additionally, the security APIs that were marked for removal are also removed from this test as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SB -> String

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25703#pullrequestreview-2939754360

From pminborg at openjdk.org  Wed Jun 18 15:47:10 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Jun 2025 15:47:10 GMT
Subject: RFR: 8359936: StableValues can release the underlying function after
 complete computation
Message-ID: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>

This PR proposes to release the underlying function if a stable function or collection has invoked its underlying supplier exhaustively so that it can be collected.

-------------

Commit messages:
 - Clean up
 - Fix bug
 - Simplify
 - Revert to records
 - Make code more like the old one
 - Add removable underlying functions

Changes: https://git.openjdk.org/jdk/pull/25878/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25878&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359936
  Stats: 294 lines in 14 files changed: 238 ins; 9 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/25878.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25878/head:pull/25878

PR: https://git.openjdk.org/jdk/pull/25878

From aivanov at openjdk.org  Wed Jun 18 16:15:35 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jun 2025 16:15:35 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1:

> 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved.

Shall the copyright year be updated?

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 460:

> 458: SliderDemo.a_plain_slider=Ein einfacher Schieberegler
> 459: SliderDemo.majorticks=Grobteilungen
> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen

Should the translation of `SliderDemo.majorticks` also be updated?

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462:

> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels
> 462: SliderDemo.minorticks=Feinteilungen

The following description uses different words now:

Feinteilungen -> Teilstrichen
Teilungen -> Teilstrichen

src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 183:

> 181: size.bit.alg=%1$d-Bit-%2$s
> 182: Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und selbstsigniertem Zertifikat ({1}) mit einer G?ltigkeit von {2} Tagen\n\tf?r: {3}
> 183: Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und einem von <{2}> ausgestellten Zertifikat ({1}) mit einer G?ltigkeit von {3} Tagen\n\tf?r: {4}

It feels as if there's something missing after _?einem?_.

src/java.base/share/classes/sun/security/util/resources/security_de.properties line 46:

> 44: invalid.null.action.provided=Ung?ltige Nullaktion angegeben
> 45: invalid.null.Class.provided=Ung?ltige Nullklasse angegeben
> 46: Subject.=Subject:\n

Is it correct? German usually uses `k`.

src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56:

> 54: 
> 55: # javax.security.auth.login.AppConfigurationEntry
> 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020

Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently.

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 220:

> 218: entry.1.is.signed.in.jarfile.but.is.not.signed.in.jarinputstream=Eintrag %s ist in JarFile, aber nicht in JarInputStream signiert
> 219: entry.1.is.signed.in.jarinputstream.but.is.not.signed.in.jarfile=Eintrag %s ist in JarInputStream, aber nicht in JarFile signiert
> 220: jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream=Diese JAR-Datei enth?lt interne Inkonsistenzen, die zu anderem Inhalt beim Lesen ?ber JarFile als beim Lesen ?ber JarInputStream f?hren k?nnen:

Is it expected to have ?JAR_-Datei_?? It was removed from `.verified` and `.signed` strings.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties line 229:

> 227: doclet.search_in_documentation=In Dokumentation suchen
> 228: doclet.search_reset=Zur?cksetzen
> 229: doclet.Member=Member

Is `Member` translated? Should it be _?Mitglied?_?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154931256
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154807291
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154813672
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154907979
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154905960
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154915395
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154968902
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154985100

From jlu at openjdk.org  Wed Jun 18 16:24:29 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jun 2025 16:24:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <epU16E3XQ7BNcECTdZbJJpdFw05jYxEZ8Kt1yRx34nY=.a5624636-51ea-4466-83c2-6e0f7aa6aca1@github.com>

On Wed, 18 Jun 2025 15:28:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56:
> 
>> 54: 
>> 55: # javax.security.auth.login.AppConfigurationEntry
>> 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020
> 
> Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently.

There is still only one space, the new one is a full width colon (U+FF1A). Localization rules have been observed to make the switch from regular colons (U+003A) into the full width version depending on the language.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155032074

From jlu at openjdk.org  Wed Jun 18 16:28:30 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jun 2025 16:28:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>

On Wed, 18 Jun 2025 15:34:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1:
> 
>> 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Shall the copyright year be updated?

In the past, we usually don't modify the copyright years and the translation team syncs the localized variants with the original file. In this case the original file did not have a change, simply the translations were updated with a "newer version".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155038247

From aivanov at openjdk.org  Wed Jun 18 16:45:29 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jun 2025 16:45:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
Message-ID: <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>

On Wed, 18 Jun 2025 16:25:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1:
>> 
>>> 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved.
>> 
>> Shall the copyright year be updated?
>
> In the past, we usually don't modify the copyright years and the translation team syncs the localized variants with the original file. In this case the original file did not have a change, simply the translations were updated with a "newer version".

This is weird? Usually, the copyright year is bumped up whenever the file is edited.

>> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56:
>> 
>>> 54: 
>>> 55: # javax.security.auth.login.AppConfigurationEntry
>>> 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020
>> 
>> Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently.
>
> There is still only one space, the new one is a full width colon (U+FF1A). Localization rules have been observed to make the switch from regular colons (U+003A) into the full width version depending on the language.

Thank you for clarification.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155071387
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155071915

From bpb at openjdk.org  Wed Jun 18 16:48:29 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Jun 2025 16:48:29 GMT
Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines
In-Reply-To: <xEDWkYkryzrtiIo0yiaOKgrl8C9kjzr_0JIsuxY4BB8=.f81538a6-f26c-4f82-92d5-fbe4c4884558@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <hHU0EXWuvwHeAI3J_Kaqod4lmlg1PxPRp-bjoQIMxqY=.8d555c08-6aec-4fb2-ab66-6bde86ff91e9@github.com>
 <Xxm7UWmkDuZ_S5kXIfVmmZhko2fH9fqYgHoxqHDd60Q=.4204a85e-74b4-4bab-ad84-8f1156a857e6@github.com>
 <xEDWkYkryzrtiIo0yiaOKgrl8C9kjzr_0JIsuxY4BB8=.f81538a6-f26c-4f82-92d5-fbe4c4884558@github.com>
Message-ID: <ygpBWJcYr4SvICJAvwIxcluMvqA6jWUp0BECx_LTBZE=.b16a4826-2458-4c54-a85d-59a5dd09d2f3@github.com>

On Wed, 18 Jun 2025 02:33:40 GMT, Xueming Shen <sherman at openjdk.org> wrote:

> I think we should treat "\r\n" as a single line terminator?

You are correct: that needs to be fixed:

jshell> Reader r = new StringReader("hello\r\nworld")
r ==> java.io.StringReader at 480bdb19

jshell> r.readAllLines()
$3 ==> [hello, , world]

Thanks for the catch!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2155076355

From kcr at openjdk.org  Wed Jun 18 16:49:32 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 18 Jun 2025 16:49:32 GMT
Subject: RFR: 8359830: Incorrect os.version reported on macOS Tahoe 26
 (Beta)
In-Reply-To: <dIYjIn7ZiNM0p0D0nTJN-B08KdxqZ-pPO__CRNrhgY0=.2f533c49-a9c1-4a03-9d69-eb747ef3e8a9@github.com>
References: <dIYjIn7ZiNM0p0D0nTJN-B08KdxqZ-pPO__CRNrhgY0=.2f533c49-a9c1-4a03-9d69-eb747ef3e8a9@github.com>
Message-ID: <jArj3ULRv0HaHFXfTiAnMCz9ES-SN0ZMZFkgowHZixs=.86eb1728-e4b0-479f-b772-15a332ab70d6@github.com>

On Wed, 18 Jun 2025 06:01:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8359830?
> 
> macOS operating system's newer version 26 (currently in Beta) is reported as a 16 by older versions of XCode. JDK internally uses the `NSProcessInfo` and `NSOperatingSystemVersion` APIs to identify the macOS version and set the `os.version` system property to that value. The current recommended version to build the JDK on macOS is XCode 15.4. The `NSOperatingSystemVersion` API on that version of XCode reports macOS version as 16 instead of 26.
> 
> The commit in this PR updates the JDK code to handle this mismatch and set the `os.version` appropriately to 26. This fix is similar to what we did with macOS BigSur when the macOS version 10.16 was meant to mean 11 https://bugs.openjdk.org/browse/JDK-8253702. 
> 
> The existing `OsVersionTest` has been updated for some trivial clean up. Existing tests in tier1, tier2 and tier3 continue to pass with this change. If anyone has access to a macOS 26 Beta, I request them to build this change and run `tier1` tests to help verify that there aren't any failures.

LGTM

I tested this on macOS 26. Without this patch `os.version` is set to `16`; with this patch, it is correctly set to `26`.

I left one possible suggestion, if you want to consider it.

src/java.base/macosx/native/libjava/java_props_macosx.c line 242:

> 240:     const bool versionCompatEnabled = envVal != NULL && strncmp(envVal, "1", 1) == 0;
> 241:     const bool requiresSpecialHandling = ((long) osVer.majorVersion == 10 && (long) osVer.minorVersion >= 16)
> 242:                                          || ((long) osVer.majorVersion == 16 && (long) osVer.minorVersion >= 0);

Since we know Apple jumped from 15 --> 26, would it be more future-proof to change this test to something like this?


    osVer.majorVersion >= 16 && osVer.majorVersion < 26 


This would allow us to work when macOS 27 comes out, in case it reports itself as "17.0" if we don't update the version of Xcode before then.

I can also see the argument for leaving it as you have done. And my guess is that Apple will report macOS 27 as 27 regardless, so this probably doesn't matter.

-------------

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/25865#pullrequestreview-2939998221
PR Review Comment: https://git.openjdk.org/jdk/pull/25865#discussion_r2155070320

From bpb at openjdk.org  Wed Jun 18 16:54:36 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Jun 2025 16:54:36 GMT
Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines
In-Reply-To: <EzaE4fjURV7jR4ihkgSJZiemmZw813zLQ3IOWAUmdqA=.29d77e27-5a9d-4931-adca-11064ffd4fe5@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <EzaE4fjURV7jR4ihkgSJZiemmZw813zLQ3IOWAUmdqA=.29d77e27-5a9d-4931-adca-11064ffd4fe5@github.com>
Message-ID: <VVc4O-3C1UA69ROyDe2TmGGKF1xBa3t7CN5CQ46oGCA=.fc127d31-dbeb-458a-8446-5fe7da65c2f9@github.com>

On Wed, 18 Jun 2025 02:38:04 GMT, Chen Liang <liach at openjdk.org> wrote:

> Edit: No, we need to check empty lines.

Right. I caught this during testing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2155088265

From naoto at openjdk.org  Wed Jun 18 16:58:34 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 16:58:34 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <zJCQh_R1fU5XdBZNfVyW5e-hk_mRcfnjPASPqzu-t3s=.8b34a54f-3ae2-4516-a2b6-d5c32b3891b8@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <zJCQh_R1fU5XdBZNfVyW5e-hk_mRcfnjPASPqzu-t3s=.8b34a54f-3ae2-4516-a2b6-d5c32b3891b8@github.com>
Message-ID: <GMreFXOIVIHSDY6c8Vcze6uvKnnsOAaNIH6G5rBfkQA=.507f3521-b8a6-4024-a1ed-d41f71a9c1e1@github.com>

On Wed, 18 Jun 2025 09:47:57 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Should the other localizations for the launcher help text (in `launcher_<lang>.properties`) also be updated? I see that only the German, Japanese and Chinese localizations have been updated so far.

Those languages (de/ja/zh-CN) are the ones we (Oracle) support. Other entities would be welcome to provide l10n for other languages (not a sporadic l10n, but commit to update/maintain).

> 
> Edit: I see that the other localizations haven't been updated for the last few releases, so maybe this is intentional. Still interested to know why we have the other localizations if they aren't updated.

Usuallly l10n resource updates are additions, so those old l10ns still have values for those languages. New additions will simply fall back to English.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2985038815

From bpb at openjdk.org  Wed Jun 18 17:00:45 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Jun 2025 17:00:45 GMT
Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines
In-Reply-To: <EzaE4fjURV7jR4ihkgSJZiemmZw813zLQ3IOWAUmdqA=.29d77e27-5a9d-4931-adca-11064ffd4fe5@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <EzaE4fjURV7jR4ihkgSJZiemmZw813zLQ3IOWAUmdqA=.29d77e27-5a9d-4931-adca-11064ffd4fe5@github.com>
Message-ID: <_aaiFefzPrulZGe08LyyU_iXOlj1nWWzfOs7fMm6jFI=.9737e245-42b2-4b78-bfc0-8cc880163b55@github.com>

On Wed, 18 Jun 2025 02:26:48 GMT, Chen Liang <liach at openjdk.org> wrote:

> Is there a reason for this pre-allocation?

What would you suggest? Start with a smaller allocation and increase it if needed? There is no possibility of knowing the length of the stream.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2155097993

From pavel.rappo at gmail.com  Wed Jun 18 17:23:38 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Wed, 18 Jun 2025 18:23:38 +0100
Subject: On Period and DateTimeFormatter
In-Reply-To: <CAA9v-_MrBWFJBhTorti+THwTecrQpYQi8+hh6EzxbaF+pA3Cbw@mail.gmail.com>
References: <CAChcVuk=VsLQN6sm4SBd2XKbW_m3+rBrxkx4QxsG7rT10KHiJw@mail.gmail.com>
 <CAA9v-_MrBWFJBhTorti+THwTecrQpYQi8+hh6EzxbaF+pA3Cbw@mail.gmail.com>
Message-ID: <CAChcVunvn4sZcN0-=474642vd8WnBrxQ2k3yF-ddUeG+F3fFbQ@mail.gmail.com>

We are talking about a period, not an interval. I used the word
"interval" in my previous email in the sense close to that def. #5
from your dictionary link:

> : a set of real numbers between two numbers either including or excluding one or both of them

So to me, an interval between two dates logically consists of all
(time) instants between its both ends.

Alright, your reply kinda tips the scales in favour of "it's just me".
Perhaps others don't have a similar issue with java.util.Period.

On Wed, Jun 18, 2025 at 4:15?PM David Alayachew
<davidalayachew at gmail.com> wrote:
>
> How does it not model an interval?
>
> Here is the official documentation.
>
> Obtains a Period consisting of the number of years, months, and days between two dates.
>
> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/time/Period.html#between(java.time.LocalDate,java.time.LocalDate)
>
> And here is the dictionary definition.
>
> a space of time between events or states
>
> https://www.merriam-webster.com/dictionary/interval
>
>
> On Wed, Jun 18, 2025, 7:30?AM Pavel Rappo <pavel.rappo at gmail.com> wrote:
>>
>> Hello, I have two questions on java.time API.
>>
>> The first one is about documentation for java.time.Period. When I get
>> back to the API after a long period (no pun intended) of not using it,
>> it takes me a while to recall that Period does __NOT__ model an
>> interval between two specific points in time, such as vacation dates.
>> And the signature of the Period.between(LocalDate, LocalDate) method
>> makes it even harder.
>>
>> I'm not sure what it is. Is it because I'm a non-native English
>> speaker or it's some idiosyncrasy? Anyway, if it's not just me, then
>> my question is: would it make sense to provide a few short and punchy
>> notes to the reader to quickly rectify this misconception that might
>> be forming in their head while they are reading the documentation?
>> Sometimes it's helpful to say what something isn't in addition to
>> saying what something is.
>>
>>
>> The second question is about DateTimeFormatter. I recently had to
>> parse a date that resembles output of asctime: Sat Jul 16 02:03:55
>> +0000 1994. It's fine and dandy until you parse a date in September.
>> That time format expects "Sep", while the formatter expects "Sept".
>>
>> Now, I'm aware that it's a known issue [^1]. Still, I wonder if we can
>> do anything better than suggest using a specific locale, which is not
>> bulletproof, or going to the DateTimeFormatterBuilder route.
>>
>> Thanks,
>> -Pavel
>>
>> [^1]: See https://bugs.openjdk.org/browse/JDK-8256837 and its numerous
>> duplicates.

From archie.cobbs at gmail.com  Wed Jun 18 17:53:08 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 18 Jun 2025 12:53:08 -0500
Subject: On Period and DateTimeFormatter
In-Reply-To: <CAChcVunvn4sZcN0-=474642vd8WnBrxQ2k3yF-ddUeG+F3fFbQ@mail.gmail.com>
References: <CAChcVuk=VsLQN6sm4SBd2XKbW_m3+rBrxkx4QxsG7rT10KHiJw@mail.gmail.com>
 <CAA9v-_MrBWFJBhTorti+THwTecrQpYQi8+hh6EzxbaF+pA3Cbw@mail.gmail.com>
 <CAChcVunvn4sZcN0-=474642vd8WnBrxQ2k3yF-ddUeG+F3fFbQ@mail.gmail.com>
Message-ID: <CANSoFxv0LcA5B+cNnhH9jqr8prMT==77PR+Zq2VTMYo9vU_EuQ@mail.gmail.com>

Period is like Duration - they are both "lengths of time", just using
different units (so they are both a TemporalAmount).

Similar to how LocalDateTime vs. Instant are both "points in time", just
using different units (so they are both a Temporal).

But you bring up a good point - perhaps CalendarDuration would have been a
better name than Period...

-Archie

On Wed, Jun 18, 2025 at 12:24?PM Pavel Rappo <pavel.rappo at gmail.com> wrote:

> We are talking about a period, not an interval. I used the word
> "interval" in my previous email in the sense close to that def. #5
> from your dictionary link:
>
> > : a set of real numbers between two numbers either including or
> excluding one or both of them
>
> So to me, an interval between two dates logically consists of all
> (time) instants between its both ends.
>
> Alright, your reply kinda tips the scales in favour of "it's just me".
> Perhaps others don't have a similar issue with java.util.Period.
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250618/b855732d/attachment.htm>

From naoto at openjdk.org  Wed Jun 18 18:01:24 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 18:01:24 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty` [v2]
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <agXiLTe_M1yttluXMMT9poQdr_hJmr-nghlR5bccgMI=.badaf025-60d0-474f-8ddb-b8d18e2af33b@github.com>

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25860/files
  - new: https://git.openjdk.org/jdk/pull/25860/files/9d1dbf3a..c5c93387

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25860&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25860&range=00-01

  Stats: 25 lines in 9 files changed: 0 ins; 16 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25860/head:pull/25860

PR: https://git.openjdk.org/jdk/pull/25860

From naoto at openjdk.org  Wed Jun 18 18:01:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 18:01:25 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty` [v2]
In-Reply-To: <0gpDp3XapnEa-4BfqTDt7AAHV7_qDLoKHy3-2xzJ7ro=.faa1279d-82a8-4a68-a026-94f325f904e7@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
 <dViJkSq-Fnckq_r2ODs-kuYsCDfGhe2rX3BZS9h255c=.ae48363a-f6a2-4b91-9455-c66c512f303a@github.com>
 <0gpDp3XapnEa-4BfqTDt7AAHV7_qDLoKHy3-2xzJ7ro=.faa1279d-82a8-4a68-a026-94f325f904e7@github.com>
Message-ID: <0wpPbk27NF8jkG1A3Za6Txg7WYCbCZwMS8WlyWIx4ZM=.f58e6a1a-70ab-4513-89ea-6e02ba69fac9@github.com>

On Wed, 18 Jun 2025 15:03:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/module-info.java line 287:
>> 
>>> 285:         jdk.jpackage,
>>> 286:         jdk.jshell,
>>> 287:         jdk.net;
>> 
>> At some point we will need to re-visit all these qualified exports so that java.base exports as few of these internal packages as possible.
>
> The original intent of StaticProperties was to limit it to the base module.
> Other modules are free to read the property themselves.

Thanks, Alan and Roger. Limited the modification within the `java.base` module.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2155190046

From dl at openjdk.org  Wed Jun 18 18:05:42 2025
From: dl at openjdk.org (Doug Lea)
Date: Wed, 18 Jun 2025 18:05:42 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements
Message-ID: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>

This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers

-------------

Commit messages:
 - Revert
 - Merge remote-tracking branch 'refs/remotes/origin/master' into JDK-8359919
 - Initial set of doc updates
 - Merge branch 'openjdk:master' into JDK-8355026
 - Reduce branchiness of Exchanger

Changes: https://git.openjdk.org/jdk/pull/25880/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25880&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359919
  Stats: 164 lines in 7 files changed: 15 ins; 1 del; 148 mod
  Patch: https://git.openjdk.org/jdk/pull/25880.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25880/head:pull/25880

PR: https://git.openjdk.org/jdk/pull/25880

From liach at openjdk.org  Wed Jun 18 18:23:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 18 Jun 2025 18:23:30 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements
In-Reply-To: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
Message-ID: <bTzuEtkfMxypsQxwT69By3k6ixDrLvfFPgW3J1xP49A=.9aad7edd-0060-4bfc-adfc-a88bbf139eca@github.com>

On Wed, 18 Jun 2025 17:51:20 GMT, Doug Lea <dl at openjdk.org> wrote:

> This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers

I think the problem in `AtomicReferenceFieldUpdater` being passed a static field exists for the other kinds of field updaters too. Currently the IAE is thrown by Unsafe, which is a hidden contract and can be inadvertently changed and affect the APIs; we might consider throwing IAE for static fields explicitly instead to avoid this pitfall.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25880#issuecomment-2985285177

From naoto at openjdk.org  Wed Jun 18 18:24:43 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 18:24:43 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty` [v3]
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <gTvwrNT5Dldji_dh947tl1S8TM3YRAyAqNfAShdA0_c=.1854389c-926d-4d8a-83da-0a73dc11853f@github.com>

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Replaces a couple more

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25860/files
  - new: https://git.openjdk.org/jdk/pull/25860/files/c5c93387..278628b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25860&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25860&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25860/head:pull/25860

PR: https://git.openjdk.org/jdk/pull/25860

From naoto at openjdk.org  Wed Jun 18 18:24:43 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 18:24:43 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty` [v3]
In-Reply-To: <cyKIsynr19VsmvHUmvEFP9RP56GFxojjJVQezBM41lg=.1aea0985-9284-43b7-8537-6a46149de0fd@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
 <cyKIsynr19VsmvHUmvEFP9RP56GFxojjJVQezBM41lg=.1aea0985-9284-43b7-8537-6a46149de0fd@github.com>
Message-ID: <VBgmWliUGCLfIt2pyF9Nka7AWZsoLjigjAk7JGRgmDM=.c009cd74-61f6-4e79-84a3-8dd5103476c5@github.com>

On Wed, 18 Jun 2025 07:08:21 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> I've verified that all relevant occurrences of `std{in,err,out}.encoding` are covered, except the ones `src/java.base/share/classes/java/lang/System.java`, which, I presume, is left out intentionally.

Initially I left them as it is too early to call, but just noticed StaticProperty class was initialized a few lines above, so it is safe to call them. Replaced.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25860#issuecomment-2985288682

From prappo at openjdk.org  Wed Jun 18 18:31:28 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 18 Jun 2025 18:31:28 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements
In-Reply-To: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
Message-ID: <3sl8UJoui43RGKoN7M7zRjpeyZT3B5F_9_5xyIC3RxE=.4c53e0e9-bbe9-4357-b210-38c03ea1a922@github.com>

On Wed, 18 Jun 2025 17:51:20 GMT, Doug Lea <dl at openjdk.org> wrote:

> This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 143:

> 141:  * that take too long. The scheduled functions or actions may create
> 142:  * and invoke other {@linkplain ForkJoinTask ForkJoinTasks}. Delayed
> 143:  * actions become <em>enabled</em> for execution and behave as ordinary submitted

Does it make sense to retain `<em>`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25880#discussion_r2155236845

From achung at openjdk.org  Wed Jun 18 18:42:54 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 18 Jun 2025 18:42:54 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v3]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <3Sb_Nj53MtMZRoKypbBFn0yumsFtiGJzY5fv60CilwA=.4ee9201b-0657-484b-8e69-01306c131b39@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  remove double quotes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/d8027691..66c34e7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=01-02

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839

PR: https://git.openjdk.org/jdk/pull/25839

From naoto.sato at oracle.com  Wed Jun 18 18:44:52 2025
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 18 Jun 2025 11:44:52 -0700
Subject: On Period and DateTimeFormatter
In-Reply-To: <CAChcVuk=VsLQN6sm4SBd2XKbW_m3+rBrxkx4QxsG7rT10KHiJw@mail.gmail.com>
References: <CAChcVuk=VsLQN6sm4SBd2XKbW_m3+rBrxkx4QxsG7rT10KHiJw@mail.gmail.com>
Message-ID: <5d921c46-cb03-429b-b853-a1bff9b1deca@oracle.com>

Hi Pavel,

On 6/18/25 4:29 AM, Pavel Rappo wrote:
> The second question is about DateTimeFormatter. I recently had to
> parse a date that resembles output of asctime: Sat Jul 16 02:03:55
> +0000 1994. It's fine and dandy until you parse a date in September.
> That time format expects "Sep", while the formatter expects "Sept".
> 
> Now, I'm aware that it's a known issue [^1]. Still, I wonder if we can
> do anything better than suggest using a specific locale, which is not
> bulletproof, or going to the DateTimeFormatterBuilder route.

Yes, I do understand the pain. This is all due to CLDR changing the 
abbreviation for September, and looks like not only Java, but many other 
software products have suffered with this change. We discussed this a 
lot internally. The fact is that the localization may change thus the 
users should not assume its stability. This kind of change could happen 
in any format/parse situations and unfortunately there is not a generic 
solution IMO.

Naoto

From dnguyen at openjdk.org  Wed Jun 18 18:50:29 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 18 Jun 2025 18:50:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v3]
In-Reply-To: <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>
Message-ID: <dWF_2vYxbax6VWDCokd4Mlhsn3H7PV3crLJAofEfr90=.231f96e1-6130-41f4-abc5-53166ca93f48@github.com>

On Tue, 17 Jun 2025 23:15:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove double quotes
>
> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2001, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Looks wrong but is correct. File had its copyright year updated in https://bugs.openjdk.org/browse/JDK-8345800, but the original is still 2023. Translation team is re-syncing it to match the original year.

Is there any way to prevent this or do we just change it back when we do a drop and explain why each time?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155272483

From prappo at openjdk.org  Wed Jun 18 18:57:28 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 18 Jun 2025 18:57:28 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements
In-Reply-To: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
Message-ID: <iRY8gv9APDLWpZQh2QyWdd4jl0_Ugpftf6gzaU6m3wc=.e9b6bf3c-f302-4bb6-b69a-f6a5eab6d2d8@github.com>

On Wed, 18 Jun 2025 17:51:20 GMT, Doug Lea <dl at openjdk.org> wrote:

> This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers

src/java.base/share/classes/java/util/concurrent/Flow.java line 64:

> 62:  * control required in most implementations (for example {@link
> 63:  * SubmissionPublisher}), and omits some error processing needed to
> 64:  * fully conform to ReactiveStream rules.

I had to re-read the comments on the relevant [issue] from 2018; thanks for fixing it.

Nit: ReactiveStream. Earlier in that doc comment, it is referred to as "reactive-streams". We should choose one of those.

We can say reactive-streams or Reactive Streams. The latter seems to be the term of choice at https://github.com/reactive-streams/reactive-streams-jvm/.

@viktorklang-ora, thoughts?

[issue]: https://bugs.openjdk.org/browse/JDK-8210149

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25880#discussion_r2155283691

From rriggs at openjdk.org  Wed Jun 18 20:29:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Jun 2025 20:29:53 GMT
Subject: RFR: 8354872: Clarify java.lang.Process resource cleanup
Message-ID: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com>

Improve the documentation of Process use of system resources.

Describe the implementation closing streams when no longer referenced.
Clarify the interactions between inputStream and inputReader and errorStream and errorReader.
Add advice and example using try-with-resources to open and close streams.
Recommend closing streams when no longer in use.

-------------

Commit messages:
 - 8354872: Clarify java.lang.Process resource cleanup

Changes: https://git.openjdk.org/jdk/pull/25884/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25884&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354872
  Stats: 151 lines in 2 files changed: 71 ins; 3 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/25884.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25884/head:pull/25884

PR: https://git.openjdk.org/jdk/pull/25884

From prr at openjdk.org  Wed Jun 18 20:40:29 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Jun 2025 20:40:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>

On Wed, 18 Jun 2025 14:45:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 460:
> 
>> 458: SliderDemo.a_plain_slider=Ein einfacher Schieberegler
>> 459: SliderDemo.majorticks=Grobteilungen
>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
> 
> Should the translation of `SliderDemo.majorticks` also be updated?

I agree. I'd expect consistency here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155451453

From davidalayachew at gmail.com  Wed Jun 18 20:56:58 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 18 Jun 2025 16:56:58 -0400
Subject: On Period and DateTimeFormatter
In-Reply-To: <CANSoFxv0LcA5B+cNnhH9jqr8prMT==77PR+Zq2VTMYo9vU_EuQ@mail.gmail.com>
References: <CAChcVuk=VsLQN6sm4SBd2XKbW_m3+rBrxkx4QxsG7rT10KHiJw@mail.gmail.com>
 <CAA9v-_MrBWFJBhTorti+THwTecrQpYQi8+hh6EzxbaF+pA3Cbw@mail.gmail.com>
 <CAChcVunvn4sZcN0-=474642vd8WnBrxQ2k3yF-ddUeG+F3fFbQ@mail.gmail.com>
 <CANSoFxv0LcA5B+cNnhH9jqr8prMT==77PR+Zq2VTMYo9vU_EuQ@mail.gmail.com>
Message-ID: <CAA9v-_MOgWOReViCuMzM5gSC5Yop3cqSrm0GV2FC4bbmpZgwUA@mail.gmail.com>

I can certainly agree that there might have been a better name than Period.
I like your suggestion, and I would even go further and suggest that
Interval would have been a better term.

But Period is certainly acceptable. It captures the meaning well enough --
a period of time between 2 events.

https://www.thefreedictionary.com/period+of+time

On Wed, Jun 18, 2025, 1:54?PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> Period is like Duration - they are both "lengths of time", just using
> different units (so they are both a TemporalAmount).
>
> Similar to how LocalDateTime vs. Instant are both "points in time", just
> using different units (so they are both a Temporal).
>
> But you bring up a good point - perhaps CalendarDuration would have been
> a better name than Period...
>
> -Archie
>
> On Wed, Jun 18, 2025 at 12:24?PM Pavel Rappo <pavel.rappo at gmail.com>
> wrote:
>
>> We are talking about a period, not an interval. I used the word
>> "interval" in my previous email in the sense close to that def. #5
>> from your dictionary link:
>>
>> > : a set of real numbers between two numbers either including or
>> excluding one or both of them
>>
>> So to me, an interval between two dates logically consists of all
>> (time) instants between its both ends.
>>
>> Alright, your reply kinda tips the scales in favour of "it's just me".
>> Perhaps others don't have a similar issue with java.util.Period.
>>
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250618/e8d85698/attachment.htm>

From duke at openjdk.org  Thu Jun 19 05:58:57 2025
From: duke at openjdk.org (duke)
Date: Thu, 19 Jun 2025 05:58:57 GMT
Subject: RFR: 8359123: Misleading examples in jmod man page [v5]
In-Reply-To: <Ry0rKlbTVL-dejGVtVpSRl4WTmowF6yVsTmOM1lh_hk=.8129a6c0-13e8-4ede-922b-f61a1f2fc783@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
 <Ry0rKlbTVL-dejGVtVpSRl4WTmowF6yVsTmOM1lh_hk=.8129a6c0-13e8-4ede-922b-f61a1f2fc783@github.com>
Message-ID: <71dkA3HDoCRvR-S5W9oc3Y2LoSPiH5UkQwRvwJAifQg=.71269e8e-5883-4844-9ea1-e839b3894c87@github.com>

On Wed, 18 Jun 2025 07:17:13 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> Please review my PR. This PR includes the following:
>> 
>> - [x] Fix a small typo in a word and copyright.
>> - [x] Enhance description for `--target-platform`.
>> - [x] Rearrange `jmod create` example from basic to complex.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update values for Linux and Windows examples.

@ammbra 
Your change (at version 04131e9b3577356e5a967094403ac6188fca7186) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25772#issuecomment-2986722905

From pminborg at openjdk.org  Thu Jun 19 06:59:31 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 19 Jun 2025 06:59:31 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v2]
In-Reply-To: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
Message-ID: <CQuqRIg0TQ7dWoonF1Lai8pH42tvZXf04w3IBAo2vKE=.07b8da0f-a8e4-4cd8-b48a-5ac5c547334e@github.com>

> This PR proposes to release the underlying function if a stable function or collection has invoked its underlying supplier exhaustively so that it can be collected.
> 
> This PR passes tier1, tier2, and tier3 testing on multiple platforms.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix performance regression

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25878/files
  - new: https://git.openjdk.org/jdk/pull/25878/files/62e948d4..f4fb53ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25878&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25878&range=00-01

  Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25878.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25878/head:pull/25878

PR: https://git.openjdk.org/jdk/pull/25878

From duke at openjdk.org  Thu Jun 19 07:47:42 2025
From: duke at openjdk.org (Ana Maria Mihalceanu)
Date: Thu, 19 Jun 2025 07:47:42 GMT
Subject: Integrated: 8359123: Misleading examples in jmod man page
In-Reply-To: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
References: <rZ8XC5vswOWcLnsg70tVL8o1zR6UDAUvlR2v0OaIjuU=.8d96276d-11be-4d73-bf1a-65eada5e576c@github.com>
Message-ID: <tYShGLDLXuBsMGdeAcloecnscO9O4edFCmIXHsBVKFA=.435dd401-2193-4d1d-a21c-d47acf510568@github.com>

On Thu, 12 Jun 2025 07:57:20 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

> Please review my PR. This PR includes the following:
> 
> - [x] Fix a small typo in a word and copyright.
> - [x] Enhance description for `--target-platform`.
> - [x] Rearrange `jmod create` example from basic to complex.

This pull request has now been integrated.

Changeset: 0dce98b7
Author:    Ana Maria Mihalceanu <ana-maria.m.mihalceanu at oracle.com>
Committer: Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0dce98b71648f270dca7395e7ab5451011b14b45
Stats:     30 lines in 1 file changed: 17 ins; 5 del; 8 mod

8359123: Misleading examples in jmod man page

Reviewed-by: cstein, alanb, iris

-------------

PR: https://git.openjdk.org/jdk/pull/25772

From vklang at openjdk.org  Thu Jun 19 09:02:52 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 19 Jun 2025 09:02:52 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v2]
In-Reply-To: <CQuqRIg0TQ7dWoonF1Lai8pH42tvZXf04w3IBAo2vKE=.07b8da0f-a8e4-4cd8-b48a-5ac5c547334e@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
 <CQuqRIg0TQ7dWoonF1Lai8pH42tvZXf04w3IBAo2vKE=.07b8da0f-a8e4-4cd8-b48a-5ac5c547334e@github.com>
Message-ID: <auzqL00xJLJ4qimzvrNKtE0LvvUL1G4VYLUSgItSNu8=.0b8a0ca1-58c3-4083-9b41-d4c8fc97991e@github.com>

On Thu, 19 Jun 2025 06:59:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to release the underlying function if a stable function or collection has invoked its underlying supplier exhaustively so that it can be collected.
>> 
>> This PR passes tier1, tier2, and tier3 testing on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix performance regression

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 150:

> 148:                 // The mutex is not reentrant so we know newValue should be returned
> 149:                 wrapAndSet(newValue);
> 150:                 if (underlyingHolder != null) {

Under what circumstances can the underlyingHolder be null here?

src/java.base/share/classes/jdk/internal/lang/stable/UnderlyingHolder.java line 35:

> 33:         this.counter = counter;
> 34:         // Safe publication
> 35:         UNSAFE.storeStoreFence();

This may actually be substitutable by making the initial write to counter a volatile write:

Suggestion:

        Unsafe.putIntVolatile(this, COUNTER_OFFSET, counter); // Safe publication of underlying and counter

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2156504893
PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2156509309

From pminborg at openjdk.org  Thu Jun 19 09:11:40 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 19 Jun 2025 09:11:40 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v2]
In-Reply-To: <auzqL00xJLJ4qimzvrNKtE0LvvUL1G4VYLUSgItSNu8=.0b8a0ca1-58c3-4083-9b41-d4c8fc97991e@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
 <CQuqRIg0TQ7dWoonF1Lai8pH42tvZXf04w3IBAo2vKE=.07b8da0f-a8e4-4cd8-b48a-5ac5c547334e@github.com>
 <auzqL00xJLJ4qimzvrNKtE0LvvUL1G4VYLUSgItSNu8=.0b8a0ca1-58c3-4083-9b41-d4c8fc97991e@github.com>
Message-ID: <_3LEIZYWVw8dMKAy-QVx_lS3M55DDtMWZ197i2zol84=.c4e32d80-e4aa-49b8-887f-2392cf7c7758@github.com>

On Thu, 19 Jun 2025 08:57:44 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix performance regression
>
> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 150:
> 
>> 148:                 // The mutex is not reentrant so we know newValue should be returned
>> 149:                 wrapAndSet(newValue);
>> 150:                 if (underlyingHolder != null) {
> 
> Under what circumstances can the underlyingHolder be null here?

If we call this method via the public `StableValue::orElseSet`, the underlying holder will be `null`. In this case, there is no underlying function stored. Instead, it is typically a lambda or an anonymous class provided on the fly.

> src/java.base/share/classes/jdk/internal/lang/stable/UnderlyingHolder.java line 35:
> 
>> 33:         this.counter = counter;
>> 34:         // Safe publication
>> 35:         UNSAFE.storeStoreFence();
> 
> This may actually be substitutable by making the initial write to counter a volatile write:
> 
> Suggestion:
> 
>         Unsafe.putIntVolatile(this, COUNTER_OFFSET, counter); // Safe publication of underlying and counter

True. We could also use piggybacking.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2156518370
PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2156520221

From vklang at openjdk.org  Thu Jun 19 09:35:58 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 19 Jun 2025 09:35:58 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements
In-Reply-To: <iRY8gv9APDLWpZQh2QyWdd4jl0_Ugpftf6gzaU6m3wc=.e9b6bf3c-f302-4bb6-b69a-f6a5eab6d2d8@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
 <iRY8gv9APDLWpZQh2QyWdd4jl0_Ugpftf6gzaU6m3wc=.e9b6bf3c-f302-4bb6-b69a-f6a5eab6d2d8@github.com>
Message-ID: <J8dOdUhLhBpclDraXUjV-KYg8liucNTP2IunN92oPxc=.22be9fe0-e255-44f5-b841-94d6926f7062@github.com>

On Wed, 18 Jun 2025 18:55:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers
>
> src/java.base/share/classes/java/util/concurrent/Flow.java line 64:
> 
>> 62:  * control required in most implementations (for example {@link
>> 63:  * SubmissionPublisher}), and omits some error processing needed to
>> 64:  * fully conform to ReactiveStream rules.
> 
> I had to re-read the comments on the relevant [issue] from 2018; thanks for fixing it.
> 
> Nit: ReactiveStream. Earlier in that doc comment, it is referred to as "reactive-streams". We should choose one of those.
> 
> We can say reactive-streams or Reactive Streams. The latter seems to be the term of choice at https://github.com/reactive-streams/reactive-streams-jvm/.
> 
> @viktorklang-ora, thoughts?
> 
> [issue]: https://bugs.openjdk.org/browse/JDK-8210149

@pavelrappo Indeed, "Reactive Streams" would be better. Perhaps something like this:

Suggestion:

 * fully conform to the Reactive Streams specification.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25880#discussion_r2156574214

From pminborg at openjdk.org  Thu Jun 19 09:59:41 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 19 Jun 2025 09:59:41 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v3]
In-Reply-To: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
Message-ID: <9rPmkCvviEZbIZr8JtKXOSQrwJu9_zbsu3U078ZUC2c=.910074e7-bb10-4a96-98e9-29ac7ad4df2f@github.com>

> This PR proposes to release the underlying function if a stable function or collection has invoked its underlying supplier exhaustively so that it can be collected.
> 
> This PR passes tier1, tier2, and tier3 testing on multiple platforms.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'master' into sv-release-supplier2
 - Fix performance regression
 - Clean up
 - Fix bug
 - Simplify
 - Revert to records
 - Make code more like the old one
 - Add removable underlying functions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25878/files
  - new: https://git.openjdk.org/jdk/pull/25878/files/f4fb53ae..d585f712

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25878&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25878&range=01-02

  Stats: 6804 lines in 183 files changed: 1660 ins; 3977 del; 1167 mod
  Patch: https://git.openjdk.org/jdk/pull/25878.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25878/head:pull/25878

PR: https://git.openjdk.org/jdk/pull/25878

From vklang at openjdk.org  Thu Jun 19 10:06:54 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 19 Jun 2025 10:06:54 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements
In-Reply-To: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
Message-ID: <-Srl4rBMKaePK43P9eti6IIhToplbQI4b8s0RN7vj0w=.f40c37f8-7b16-44e7-b7ab-ceeb7e272fb9@github.com>

On Wed, 18 Jun 2025 17:51:20 GMT, Doug Lea <dl at openjdk.org> wrote:

> This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers

src/java.base/share/classes/java/util/concurrent/CompletionStage.java line 103:

> 101:  * cause. This distinguishes exceptions in an action itself from those
> 102:  * it depends on. If you want them handled in the same way, you might
> 103:  * choose to catch {@link RuntimeException}.  If a stage is dependent

Perhaps something like the following:

Suggestion:

 * it depends on. If they are to be handled the same, instead catch {@link RuntimeException}.
 *  If a stage is dependent


?

src/java.base/share/classes/java/util/concurrent/CompletionStage.java line 153:

> 151:  * <p>Memory consistency effects: Actions in a thread prior to the
> 152:  * submission of a computation producing a {@code CompletionStage}
> 153:  * <i>happen-before</I> that computation begins. And actions taken by

Suggestion:

 * <i>happen-before</i> that computation begins. And actions taken by

src/java.base/share/classes/java/util/concurrent/CompletionStage.java line 155:

> 153:  * <i>happen-before</I> that computation begins. And actions taken by
> 154:  * a {@code CompletionStage} <i>happen-before</i> actions of any
> 155:  * dependent stage subsequent to its completion.

I found "its" ambiguous in that sentence, does it mean:

Suggestion:

 * dependent stage subsequent to that stage's completion.


?

src/java.base/share/classes/java/util/concurrent/SubmissionPublisher.java line 166:

> 164:  *   public void onNext(S item) {
> 165:  *     submit(function.apply(item));
> 166:  *     subscription.request(1);

?

src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java line 49:

> 47: /**
> 48:  * A reflection-based utility that enables atomic updates to
> 49:  * designated non-static {@code volatile} reference fields of designated

Wouldn't this change also apply to the other AtomicXFieldUpdaters?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25880#discussion_r2156580467
PR Review Comment: https://git.openjdk.org/jdk/pull/25880#discussion_r2156585287
PR Review Comment: https://git.openjdk.org/jdk/pull/25880#discussion_r2156590878
PR Review Comment: https://git.openjdk.org/jdk/pull/25880#discussion_r2156627931
PR Review Comment: https://git.openjdk.org/jdk/pull/25880#discussion_r2156630586

From vklang at openjdk.org  Thu Jun 19 10:06:55 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 19 Jun 2025 10:06:55 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements
In-Reply-To: <3sl8UJoui43RGKoN7M7zRjpeyZT3B5F_9_5xyIC3RxE=.4c53e0e9-bbe9-4357-b210-38c03ea1a922@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
 <3sl8UJoui43RGKoN7M7zRjpeyZT3B5F_9_5xyIC3RxE=.4c53e0e9-bbe9-4357-b210-38c03ea1a922@github.com>
Message-ID: <-6rmOgZl8rnarLxXZpoYkR3pgqmCDwK6hc0GBpaeQ1s=.13fe924b-9f8c-49f2-a756-8a174ee2274f@github.com>

On Wed, 18 Jun 2025 18:25:39 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 143:
> 
>> 141:  * that take too long. The scheduled functions or actions may create
>> 142:  * and invoke other {@linkplain ForkJoinTask ForkJoinTasks}. Delayed
>> 143:  * actions become <em>enabled</em> for execution and behave as ordinary submitted
> 
> Does it make sense to retain `<em>`?

Might make sense to remove it if we always spell it out at "enabled for execution"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25880#discussion_r2156618787

From cay.horstmann at gmail.com  Thu Jun 19 10:25:05 2025
From: cay.horstmann at gmail.com (Cay Horstmann)
Date: Thu, 19 Jun 2025 12:25:05 +0200
Subject: Gatherer JavaDoc
Message-ID: <71cad51c-5928-478b-a2dc-5071d6e44b56@gmail.com>

Hi, I have trio of minor questions about the Gatherer JavaDoc at https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/util/stream/Gatherer.html

1. "Gatherers whose integrator is an instance of Gatherer.Integrator.Greedy can be assumed not to short-circuit, *and the return value of invoking Gatherer.Integrator.integrate(Object, Object, Downstream) does not need to be inspected*."

The way it is worded, I get the impression that a greedy integrator could simply return false (or to save a letter, true), because, not inspected. But I am confused. It was my impression that any integrator, greedy or not, should return false if downstream.push returns false. Why would the implementation not want to know? (The current implementation does inspect the return value.)

2. "Gatherers whose finisher is defaultFinisher() are considered to not have an end-of-stream hook *and invoking their finisher is optional.*"

I don't get the significance of the "and" part. Why would anyone care if defaultFinisher is invoked? It's a no-op.

3. What is the use case for

static <T,R> Gatherer<T,Void,R>
of(Gatherer.Integrator<Void,T,R> integrator, BiConsumer<Void, Gatherer.Downstream<? super R>> finisher)

If there is no state, what can the finisher do?

Thanks,

Cay

-- 

Cay S. Horstmann | https://horstmann.com


From scolebourne at joda.org  Thu Jun 19 10:52:04 2025
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 19 Jun 2025 11:52:04 +0100
Subject: On Period and DateTimeFormatter
In-Reply-To: <CANSoFxv0LcA5B+cNnhH9jqr8prMT==77PR+Zq2VTMYo9vU_EuQ@mail.gmail.com>
References: <CAChcVuk=VsLQN6sm4SBd2XKbW_m3+rBrxkx4QxsG7rT10KHiJw@mail.gmail.com>
 <CAA9v-_MrBWFJBhTorti+THwTecrQpYQi8+hh6EzxbaF+pA3Cbw@mail.gmail.com>
 <CAChcVunvn4sZcN0-=474642vd8WnBrxQ2k3yF-ddUeG+F3fFbQ@mail.gmail.com>
 <CANSoFxv0LcA5B+cNnhH9jqr8prMT==77PR+Zq2VTMYo9vU_EuQ@mail.gmail.com>
Message-ID: <CACzrW9C4_HtQuV9uvJh=+VhA9qFD2CYjkn62M==jMVqVxprqGQ@mail.gmail.com>

The term "Period" derives from early versions of ISO-8601. You will
note that the standard ISO-8601 format for Period is P1Y2M3D, where
the "P" stands for "Period".

The spec has changed over time. The original 1998 version [1] is where
Joda-Time, and thus Java-Time derive their names. The 2016 version [2]
has different terminology.

* Period - a descriptive quantity of time based on fields (from years
to seconds in Joda-Time, from years to days in Java-Time)
* Duration - a precise quantity of time based on seconds
* Interval - a section of the time-line specified by the start and end
instants (not in Java-Time ATM)

Stephen

[1] https://www.webaugur.com/bibliotheca/standards/iso8601/8601.pdf
[2] https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_iso_wd_8601-1_2016-02-16.pdf


On Wed, 18 Jun 2025 at 18:54, Archie Cobbs <archie.cobbs at gmail.com> wrote:
>
> Period is like Duration - they are both "lengths of time", just using different units (so they are both a TemporalAmount).
>
> Similar to how LocalDateTime vs. Instant are both "points in time", just using different units (so they are both a Temporal).
>
> But you bring up a good point - perhaps CalendarDuration would have been a better name than Period...
>
> -Archie
>
> On Wed, Jun 18, 2025 at 12:24?PM Pavel Rappo <pavel.rappo at gmail.com> wrote:
>>
>> We are talking about a period, not an interval. I used the word
>> "interval" in my previous email in the sense close to that def. #5
>> from your dictionary link:
>>
>> > : a set of real numbers between two numbers either including or excluding one or both of them
>>
>> So to me, an interval between two dates logically consists of all
>> (time) instants between its both ends.
>>
>> Alright, your reply kinda tips the scales in favour of "it's just me".
>> Perhaps others don't have a similar issue with java.util.Period.
>
>
> --
> Archie L. Cobbs

From dl at openjdk.org  Thu Jun 19 10:57:56 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 19 Jun 2025 10:57:56 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements
In-Reply-To: <J8dOdUhLhBpclDraXUjV-KYg8liucNTP2IunN92oPxc=.22be9fe0-e255-44f5-b841-94d6926f7062@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
 <iRY8gv9APDLWpZQh2QyWdd4jl0_Ugpftf6gzaU6m3wc=.e9b6bf3c-f302-4bb6-b69a-f6a5eab6d2d8@github.com>
 <J8dOdUhLhBpclDraXUjV-KYg8liucNTP2IunN92oPxc=.22be9fe0-e255-44f5-b841-94d6926f7062@github.com>
Message-ID: <S5kmiiVMZPvx3Kk4Z3ybTkf9qK4LqRIaXMmC-a8D92k=.6dab7af8-a2e6-4216-8c35-f983ec3d1076@github.com>

On Thu, 19 Jun 2025 09:32:43 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/Flow.java line 64:
>> 
>>> 62:  * control required in most implementations (for example {@link
>>> 63:  * SubmissionPublisher}), and omits some error processing needed to
>>> 64:  * fully conform to ReactiveStream rules.
>> 
>> I had to re-read the comments on the relevant [issue] from 2018; thanks for fixing it.
>> 
>> Nit: ReactiveStream. Earlier in that doc comment, it is referred to as "reactive-streams". We should choose one of those.
>> 
>> We can say reactive-streams or Reactive Streams. The latter seems to be the term of choice at https://github.com/reactive-streams/reactive-streams-jvm/.
>> 
>> @viktorklang-ora, thoughts?
>> 
>> [issue]: https://bugs.openjdk.org/browse/JDK-8210149
>
> @pavelrappo Indeed, "Reactive Streams" would be better. Perhaps something like this:
> 
> Suggestion:
> 
>  * fully conform to the Reactive Streams specification.

Thanks; done.

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 143:
>> 
>>> 141:  * that take too long. The scheduled functions or actions may create
>>> 142:  * and invoke other {@linkplain ForkJoinTask ForkJoinTasks}. Delayed
>>> 143:  * actions become <em>enabled</em> for execution and behave as ordinary submitted
>> 
>> Does it make sense to retain `<em>`?
>
> Might make sense to remove it if we always spell it out at "enabled for execution"

OK; done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25880#discussion_r2156715166
PR Review Comment: https://git.openjdk.org/jdk/pull/25880#discussion_r2156721548

From dl at openjdk.org  Thu Jun 19 10:57:54 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 19 Jun 2025 10:57:54 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements
In-Reply-To: <-Srl4rBMKaePK43P9eti6IIhToplbQI4b8s0RN7vj0w=.f40c37f8-7b16-44e7-b7ab-ceeb7e272fb9@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
 <-Srl4rBMKaePK43P9eti6IIhToplbQI4b8s0RN7vj0w=.f40c37f8-7b16-44e7-b7ab-ceeb7e272fb9@github.com>
Message-ID: <tgTBC_fp66wuWt9ZIdRgI-1YGHju9dJNPmDeZYkAR50=.ee8ca69c-3e61-4fe3-a646-b08d8cc2bd05@github.com>

On Thu, 19 Jun 2025 09:36:19 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers
>
> src/java.base/share/classes/java/util/concurrent/CompletionStage.java line 103:
> 
>> 101:  * cause. This distinguishes exceptions in an action itself from those
>> 102:  * it depends on. If you want them handled in the same way, you might
>> 103:  * choose to catch {@link RuntimeException}.  If a stage is dependent
> 
> Perhaps something like the following:
> 
> Suggestion:
> 
>  * it depends on. If they are to be handled the same, instead catch {@link RuntimeException}.
>  *  If a stage is dependent
> 
> 
> ?

Done

> src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java line 49:
> 
>> 47: /**
>> 48:  * A reflection-based utility that enables atomic updates to
>> 49:  * designated non-static {@code volatile} reference fields of designated
> 
> Wouldn't this change also apply to the other AtomicXFieldUpdaters?

Yes. Will do. Also, as mentioned by @liach we could trap violations by throwing a better exception. But considering that people should be using VarHandles instead anyway these days, and old uses might depend on current behavior, it doesn't seem worthwhile to add? (line 338)
+            if (Modifier.isStatic(modifiers))
+                throw new IllegalArgumentException("Must not be static");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25880#discussion_r2156718705
PR Review Comment: https://git.openjdk.org/jdk/pull/25880#discussion_r2156709501

From duke at openjdk.org  Thu Jun 19 11:08:04 2025
From: duke at openjdk.org (ExE Boss)
Date: Thu, 19 Jun 2025 11:08:04 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v3]
In-Reply-To: <9rPmkCvviEZbIZr8JtKXOSQrwJu9_zbsu3U078ZUC2c=.910074e7-bb10-4a96-98e9-29ac7ad4df2f@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
 <9rPmkCvviEZbIZr8JtKXOSQrwJu9_zbsu3U078ZUC2c=.910074e7-bb10-4a96-98e9-29ac7ad4df2f@github.com>
Message-ID: <FZcnbKswDk3KKXUNQg9ht-J_p1AzKI7BVZ3kcP3U_2E=.6ef90d5b-23b4-4237-9359-1e7c741b3358@github.com>

On Thu, 19 Jun 2025 09:59:41 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to release the underlying function if a stable function or collection has invoked its underlying supplier exhaustively so that it can be collected.
>> 
>> This PR passes tier1, tier2, and tier3 testing on multiple platforms.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into sv-release-supplier2
>  - Fix performance regression
>  - Clean up
>  - Fix bug
>  - Simplify
>  - Revert to records
>  - Make code more like the old one
>  - Add removable underlying functions

src/java.base/share/classes/jdk/internal/lang/stable/StableSupplier.java line 46:

> 44:     @Override
> 45:     public T get() {
> 46:         return delegate.orElseSet(underlyingHolder.underlying(), underlyingHolder);

By?avoiding?reading from?`underlyingHolder` when?the?`StableValue` is?already?set, this?can?avoid the?overhead of?a?field?read from?`underlyingHolder`:
Suggestion:

        final Object t = delegate.wrappedContentsAcquire();
        if (t != null) {
            return unwrap(t);
        }
        return delegate.orElseSet(underlyingHolder.underlying(), underlyingHolder);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2156730614

From alanb at openjdk.org  Thu Jun 19 11:08:04 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 19 Jun 2025 11:08:04 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty` [v3]
In-Reply-To: <gTvwrNT5Dldji_dh947tl1S8TM3YRAyAqNfAShdA0_c=.1854389c-926d-4d8a-83da-0a73dc11853f@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
 <gTvwrNT5Dldji_dh947tl1S8TM3YRAyAqNfAShdA0_c=.1854389c-926d-4d8a-83da-0a73dc11853f@github.com>
Message-ID: <eGqGLsVpzdsqe5Vx1Umti4nNEerLW0SyF_xURDpAUy4=.734106e3-4862-43c5-8eaa-e6d5d93b98d4@github.com>

On Wed, 18 Jun 2025 18:24:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaces a couple more

Latest version looks okay but I think better to drop the change to System.initPhase1.

src/java.base/share/classes/java/lang/System.java line 1820:

> 1818:         // of those properties default to native.encoding
> 1819:         setOut0(newPrintStream(fdOut, StaticProperty.stdoutEncoding()));
> 1820:         initialErr = newPrintStream(fdErr, StaticProperty.stderrEncoding());

This is initPhase1 where we've just saved the initial properties. I think it would be better to not change this. It would be okay to use tempProps here too, but I think clearer as is.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25860#pullrequestreview-2942535422
PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2156732745

From dl at openjdk.org  Thu Jun 19 11:08:46 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 19 Jun 2025 11:08:46 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements [v2]
In-Reply-To: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
Message-ID: <YEBQrH7dVRrOZgVmkkqyTG0LtMc2svngc_DGUWvCYug=.bf91f17f-bcc1-4508-89b1-db69f2ede4e1@github.com>

> This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25880/files
  - new: https://git.openjdk.org/jdk/pull/25880/files/519c981f..cadb2c91

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25880&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25880&range=00-01

  Stats: 9 lines in 5 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25880.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25880/head:pull/25880

PR: https://git.openjdk.org/jdk/pull/25880

From dl at openjdk.org  Thu Jun 19 11:08:52 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 19 Jun 2025 11:08:52 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements [v2]
In-Reply-To: <-Srl4rBMKaePK43P9eti6IIhToplbQI4b8s0RN7vj0w=.f40c37f8-7b16-44e7-b7ab-ceeb7e272fb9@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
 <-Srl4rBMKaePK43P9eti6IIhToplbQI4b8s0RN7vj0w=.f40c37f8-7b16-44e7-b7ab-ceeb7e272fb9@github.com>
Message-ID: <uPC9Gsb8t1jsoZu00LyXyoeTU359t0zaGvlLZlG7F1c=.498ebf75-d269-4ea3-844c-00b5e9251991@github.com>

On Thu, 19 Jun 2025 09:42:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/classes/java/util/concurrent/CompletionStage.java line 155:
> 
>> 153:  * <i>happen-before</I> that computation begins. And actions taken by
>> 154:  * a {@code CompletionStage} <i>happen-before</i> actions of any
>> 155:  * dependent stage subsequent to its completion.
> 
> I found "its" ambiguous in that sentence, does it mean:
> 
> Suggestion:
> 
>  * dependent stage subsequent to that stage's completion.
> 
> 
> ?

Changed to:
 And actions taken by
 * {@code CompletionStage x} <i>happen-before</i> actions of any
 * dependent stage subsequent to {@code x}'s completion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25880#discussion_r2156730502

From duke at openjdk.org  Thu Jun 19 11:18:04 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 19 Jun 2025 11:18:04 GMT
Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines
In-Reply-To: <_aaiFefzPrulZGe08LyyU_iXOlj1nWWzfOs7fMm6jFI=.9737e245-42b2-4b78-bfc0-8cc880163b55@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <EzaE4fjURV7jR4ihkgSJZiemmZw813zLQ3IOWAUmdqA=.29d77e27-5a9d-4931-adca-11064ffd4fe5@github.com>
 <_aaiFefzPrulZGe08LyyU_iXOlj1nWWzfOs7fMm6jFI=.9737e245-42b2-4b78-bfc0-8cc880163b55@github.com>
Message-ID: <03QlPzTvuWFYDfssp2DZXxgzeghJ9lWPdzP8zhARQpk=.2b956fb9-7de6-4b75-9021-0303c3368e37@github.com>

On Wed, 18 Jun 2025 16:57:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 455:
>> 
>>> 453:         List<String> lines = new ArrayList<String>();
>>> 454: 
>>> 455:         StringBuilder sb = new StringBuilder(82);
>> 
>> Is there a reason for this pre-allocation? If the whole content is smaller than 8192 in size, this allocation would be redundant because we are going through the string constructor path.
>
>> Is there a reason for this pre-allocation?
> 
> What would you suggest? Start with a smaller allocation and increase it if needed? There is no possibility of knowing the length of the stream.

As this PR explicitly targets performance and as the aim of this method is to keep **all** content in-memory anyways, I wonder if it would be acceptable and even faster to pre-allocate `new StringBuilder(TRANSFER_BUFFER_SIZE)`? In the end, this allocation is just temporary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2156717996

From duke at openjdk.org  Thu Jun 19 11:18:06 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 19 Jun 2025 11:18:06 GMT
Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines
In-Reply-To: <ygpBWJcYr4SvICJAvwIxcluMvqA6jWUp0BECx_LTBZE=.b16a4826-2458-4c54-a85d-59a5dd09d2f3@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <hHU0EXWuvwHeAI3J_Kaqod4lmlg1PxPRp-bjoQIMxqY=.8d555c08-6aec-4fb2-ab66-6bde86ff91e9@github.com>
 <Xxm7UWmkDuZ_S5kXIfVmmZhko2fH9fqYgHoxqHDd60Q=.4204a85e-74b4-4bab-ad84-8f1156a857e6@github.com>
 <xEDWkYkryzrtiIo0yiaOKgrl8C9kjzr_0JIsuxY4BB8=.f81538a6-f26c-4f82-92d5-fbe4c4884558@github.com>
 <ygpBWJcYr4SvICJAvwIxcluMvqA6jWUp0BECx_LTBZE=.b16a4826-2458-4c54-a85d-59a5dd09d2f3@github.com>
Message-ID: <n5OxnkaNvmhX1WDjSS6zVbgHOLLCwwgCpx5Wvz51USc=.98bf75da-1c2c-4133-9a11-72bcef003794@github.com>

On Wed, 18 Jun 2025 16:45:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I think we should treat "\r\n" as a single line terminator? for example
>> 
>>  "hello\r\nworld".lines().forEach(line -> out.format("[%s]\n", line));
>> =>
>> [hello]
>> [world]
>> 
>> instead of (the current impl)
>> 
>> [hello]
>> []
>> [world]
>> 
>> or I misread the impl?
>
>> I think we should treat "\r\n" as a single line terminator?
> 
> You are correct: that needs to be fixed:
> 
> jshell> Reader r = new StringReader("hello\r\nworld")
> r ==> java.io.StringReader at 480bdb19
> 
> jshell> r.readAllLines()
> $3 ==> [hello, , world]
> 
> Thanks for the catch!

`Scanner` seems to scan for even more characters: https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/java.base/share/classes/java/util/Scanner.java#L490

Would it make sense to resemble this? Would it make sense to simply use `Scanner` directly? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2156724736

From duke at openjdk.org  Thu Jun 19 11:18:07 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 19 Jun 2025 11:18:07 GMT
Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines
In-Reply-To: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
Message-ID: <1ehoDFZZXyZeL4yXlyp9APIUZJrJqrwWftvpEamOS8w=.b75449c1-a506-4719-b24c-9e0fa461326d@github.com>

On Wed, 18 Jun 2025 00:04:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replaces the implementation `readAllCharsAsString().lines().toList()` with reading into a temporary `char` array which is then processed to detect line terminators and copy non-terminating characters into strings which are added to the list.

src/java.base/share/classes/java/io/Reader.java line 480:

> 478:                     pos++;
> 479:                 } else { // term > pos
> 480:                     if (eol && sb.length() == 0) {

Is there a reason for `sb.length() == 0` instead of `sb.isEmpty()`?

src/java.base/share/classes/java/io/Reader.java line 508:

> 506:         }
> 507: 
> 508:         return lines;

Do we really want to return a mutable `ArrayList` here? In earlier discussions about this very API I was told that it deliberately returns `String` instead of `CharSequence` due to *intended* immutability, even if that potentially implied slower performance. Following this logic, it would be just straightforward to `return Collections.unmodifiableList(lines);` here. ?

src/java.base/share/classes/java/io/Reader.java line 551:

> 549:     public String readAllAsString() throws IOException {
> 550:         StringBuilder result = new StringBuilder();
> 551:         char[] cbuf = new char[TRANSFER_BUFFER_SIZE];

As this PR explicitly targets performance and as the aim of this method is to keep **all** content in-memory anyways, I wonder if it would be acceptable and even faster to pre-allocate `new StringBuilder(TRANSFER_BUFFER_SIZE)`? In the end, this allocation is just temporary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2156727346
PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2156742905
PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2156750703

From dl at openjdk.org  Thu Jun 19 11:31:53 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 19 Jun 2025 11:31:53 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements [v3]
In-Reply-To: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
Message-ID: <S9tlbNx3hJEON3vjVL7gyNvI9pA5l5ra1mn-ExmkbyE=.2c3881b8-45ce-40cb-9499-be2fd1aeb659@github.com>

> This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Add JDK-8353155 doc improvement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25880/files
  - new: https://git.openjdk.org/jdk/pull/25880/files/cadb2c91..18ea3e7b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25880&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25880&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25880.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25880/head:pull/25880

PR: https://git.openjdk.org/jdk/pull/25880

From dl at openjdk.org  Thu Jun 19 11:44:06 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 19 Jun 2025 11:44:06 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements [v4]
In-Reply-To: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
Message-ID: <E9vp3GGyZNsbdiIbqEwbIADKGOF3L5oKr6GiFGxClyk=.4624dc48-d55e-40d5-80d3-39a26f2bdad4@github.com>

> This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Add JDK-8186959 docfix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25880/files
  - new: https://git.openjdk.org/jdk/pull/25880/files/18ea3e7b..bd543fc5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25880&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25880&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25880.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25880/head:pull/25880

PR: https://git.openjdk.org/jdk/pull/25880

From dl at openjdk.org  Thu Jun 19 11:58:33 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 19 Jun 2025 11:58:33 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements [v5]
In-Reply-To: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
Message-ID: <ERciNc3tSasAPYrkZM9mb7xiA8sxkinQy958Usqu430=.a4ee43a1-96d6-40c3-9d7b-a5f5be81ce22@github.com>

> This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Add JDK-8190889 docfix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25880/files
  - new: https://git.openjdk.org/jdk/pull/25880/files/bd543fc5..4ef7649a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25880&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25880&range=03-04

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25880.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25880/head:pull/25880

PR: https://git.openjdk.org/jdk/pull/25880

From viktor.klang at oracle.com  Thu Jun 19 12:35:54 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 19 Jun 2025 12:35:54 +0000
Subject: Gatherer JavaDoc
In-Reply-To: <71cad51c-5928-478b-a2dc-5071d6e44b56@gmail.com>
References: <71cad51c-5928-478b-a2dc-5071d6e44b56@gmail.com>
Message-ID: <MW4PR10MB5774C6D97B91B567CC4B5F1DFF7DA@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Cay!

Thanks for the questions, see my responses below:

>1. "Gatherers whose integrator is an instance of Gatherer.Integrator.Greedy can be >assumed not to short-circuit, *and the return value of invoking >Gatherer.Integrator.integrate(Object, Object, Downstream) does not need to be >inspected*."

>The way it is worded, I get the impression that a greedy integrator could simply >return false (or to save a letter, true), because, not inspected. But I am confused. It >was my impression that any integrator, greedy or not, should return false if >downstream.push returns false. Why would the implementation not want to >know? (The current implementation does inspect the return value.)

No, it doesn't say that it won't be inspected, it says that it doesn't need to. So if a user returns false from a greedy integrator's integrate-method, they can't be surprised if that signal isn't acted upon.

The "evaluator" which operates on the Gatherer instance then has more freedom as to how it is implemented when it sees Greedy Integrators.

>2. "Gatherers whose finisher is defaultFinisher() are considered to not have an >end-of-stream hook *and invoking their finisher is optional.*"

>I don't get the significance of the "and" part. Why would anyone care if >defaultFinisher is invoked? It's a no-op.

For developers: If the user has to implement the Gatherer interface and overrides/implements the finisher()-method, it does not need to synthesize a no-op (bi-)consumer, which will end up being invoked needlessly, but instead they can return the `defaultFinisher()` which indeed is how the default implementation of Gatherer::finisher() is implemented: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherer.java#L250

For developers who venture into overriding andThen(), knowing which finishers are no-ops, and thus do not need to be composed, reduces the cost of invoking them.

For implementors of things which evaluate Gatherers: they can now avoid the overhead of invoking no-op finishers (which tend to be fairly common).

>3. What is the use case for

>static <T,R> Gatherer<T,Void,R>
>of(Gatherer.Integrator<Void,T,R> integrator, BiConsumer<Void, >Gatherer.Downstream<? super R>> finisher)

>If there is no state, what can the finisher do?

Inject known data at the end of a stream, for instance:

jshell> Gatherer<String, Void, String> s = Gatherer.of((_, s, d) -> d.push(s), (_, d) -> d.push("EOF"))
s ==> GathererImpl[initializer=DEFAULT, integrator=$Lam ... 0000007e000cf838 at 5f3a4b84]

jshell> Stream.of("foo", "bar", "baz").gather(s).toList()
$2 ==> [foo, bar, baz, EOF]


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Cay Horstmann <cay.horstmann at gmail.com>
Sent: Thursday, 19 June 2025 12:25
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Gatherer JavaDoc

Hi, I have trio of minor questions about the Gatherer JavaDoc at https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/util/stream/Gatherer.html

1. "Gatherers whose integrator is an instance of Gatherer.Integrator.Greedy can be assumed not to short-circuit, *and the return value of invoking Gatherer.Integrator.integrate(Object, Object, Downstream) does not need to be inspected*."

The way it is worded, I get the impression that a greedy integrator could simply return false (or to save a letter, true), because, not inspected. But I am confused. It was my impression that any integrator, greedy or not, should return false if downstream.push returns false. Why would the implementation not want to know? (The current implementation does inspect the return value.)

2. "Gatherers whose finisher is defaultFinisher() are considered to not have an end-of-stream hook *and invoking their finisher is optional.*"

I don't get the significance of the "and" part. Why would anyone care if defaultFinisher is invoked? It's a no-op.

3. What is the use case for

static <T,R> Gatherer<T,Void,R>
of(Gatherer.Integrator<Void,T,R> integrator, BiConsumer<Void, Gatherer.Downstream<? super R>> finisher)

If there is no state, what can the finisher do?

Thanks,

Cay

--

Cay S. Horstmann | https://horstmann.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250619/921d0d21/attachment-0001.htm>

From magnus.ihse.bursie at oracle.com  Thu Jun 19 12:40:52 2025
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 19 Jun 2025 14:40:52 +0200
Subject: Interest in Java based attach provider implementation?
In-Reply-To: <839c95d5-7965-4065-8d8c-75c21eb79f8e@gmx.net>
References: <4b22f750-721f-e178-6618-0f0fb062c921@gmx.net>
 <839c95d5-7965-4065-8d8c-75c21eb79f8e@gmx.net>
Message-ID: <112cc394-b8a9-412a-9ca8-114a73994607@oracle.com>

Hi Philippe,

There is an ongoing effort about "Panamization" (that is, adapting it to 
use FFM instead of JNI) of native code in the JDK in general. This is 
discussed on the core-libs-dev mailing list. I've cc:ed them. I think it 
would be beneficial if you coordinate your efforts with the Panamization 
effort.

/Magnus


On 2025-06-15 17:43, Philippe Marschall wrote:
> Hello
>
> I further pursued the approach
>
> - Rebased the Linux implementation [1], implemented the permission 
> check using JSR 203 and the Unix domain sockets using JEP 380.
> - Applied the same changes to the AIX implementation [2].
> - Switched Linux to an FFM based kill implementation [3], completely 
> getting rid of JNI.
> -? Updated the macOS implementation [4], implemented the permission 
> check using JSR 203 and the Unix domain sockets using JEP 380.
> - Switched macOS to an FFM based kill and sysctl implementation [5], 
> completely getting rid of JNI.
>
> I ran the serviceability test suite on Linux and macOS and it passes. 
> I manually verified that I can attach to JVMs using local builds.
>
> I could not test on AIX.
>
> ?[1] 
> https://github.com/marschall/jdk/commit/3a7796daadad7c9d2d85e9e4623f170baecc0e41
> ?[2] 
> https://github.com/marschall/jdk/commit/962729e0bfb6b7d86af303f25c6670d407d1d2d9
> ?[3] 
> https://github.com/marschall/jdk/commit/7b5f1bf6f55458a7f69f50b8fdf4986e22202559
> ?[4] 
> https://github.com/marschall/jdk/commit/93372a124eca6078fde5597c2498b381a4ef5dfa
> ?[5] 
> https://github.com/marschall/jdk/commit/c5faf9655bbb85cc3ed9b2a7ef15b08ab83d1d8b
>
> Cheers
> Philippe
>
> On 20.04.22 22:13, Philippe Marschall wrote:
>> Hello
>>
>> I hope this is the right mailing list. I recently had a look at the
>> Linux attach provider implementation and could not help but noticing
>> that a large part, if not all of it, could be replaced with Java.
>> Besides getting rid of the C code this should allow us to unify the AIX,
>> Linux and macOS implementations under a single Unix implementation.
>>
>> The permission check can be implemented using JSR 203 [1] to access uid,
>> gid and file mode and using jdk.internal.misc.VM to get the euid and 
>> egid.
>>
>> Reading and writing to Unix domain sockets can be done through JEP 
>> 380 [2].
>>
>> Sending SIGQUIT to a process could in theory done through JEP 102 [3]
>> however sending SIGQUIT to self is currently blocked. This is required
>> for the self attach mechanism. There a very small C function is still
>> needed for now, this is hopefully portable.
>>
>> I did a small prototype [4]. The tier1 suite runs and I can attach to a
>> local JVM.
>>
>> The overhead will likely be a bit higher as we go through more JDK
>> abstractions.
>>
>> ??[1] https://jcp.org/en/jsr/detail?id=203
>> ??[2] https://openjdk.java.net/jeps/380
>> ??[3] https://openjdk.java.net/jeps/102
>> ??[4]
>> https://github.com/marschall/jdk/ 
>> commit/207dac7e4d1bd65450bbd2c9e14d33fc34b7cebc
>>
>> Cheers
>> Philippe
>

From pminborg at openjdk.org  Thu Jun 19 12:52:29 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 19 Jun 2025 12:52:29 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v3]
In-Reply-To: <9rPmkCvviEZbIZr8JtKXOSQrwJu9_zbsu3U078ZUC2c=.910074e7-bb10-4a96-98e9-29ac7ad4df2f@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
 <9rPmkCvviEZbIZr8JtKXOSQrwJu9_zbsu3U078ZUC2c=.910074e7-bb10-4a96-98e9-29ac7ad4df2f@github.com>
Message-ID: <9ZTBTgDTIgmZali7a8PcTUp1cecdTifn6694Z_YTgZA=.5bc13c2b-e30f-4e46-9f50-cf6aa2cbbf72@github.com>

On Thu, 19 Jun 2025 09:59:41 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to release the underlying function if a stable function or collection has invoked its underlying supplier exhaustively so that it can be collected.
>> 
>> This PR passes tier1, tier2, and tier3 testing on multiple platforms.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into sv-release-supplier2
>  - Fix performance regression
>  - Clean up
>  - Fix bug
>  - Simplify
>  - Revert to records
>  - Make code more like the old one
>  - Add removable underlying functions

Performance looks really good on all platforms except Linux AArch64, where there are significant regressions for:
 * StableFunctionBenchmark.map
 * StableFunctionBenchmark.staticIntFunction
 * StableFunctionBenchmark.staticSMap
 * StableIntFunctionBenchmark.intFunction
 * StableIntFunctionBenchmark.staticIntFunction
 
These need to be addressed before integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25878#issuecomment-2987956351

From pminborg at openjdk.org  Thu Jun 19 12:52:30 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 19 Jun 2025 12:52:30 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v3]
In-Reply-To: <FZcnbKswDk3KKXUNQg9ht-J_p1AzKI7BVZ3kcP3U_2E=.6ef90d5b-23b4-4237-9359-1e7c741b3358@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
 <9rPmkCvviEZbIZr8JtKXOSQrwJu9_zbsu3U078ZUC2c=.910074e7-bb10-4a96-98e9-29ac7ad4df2f@github.com>
 <FZcnbKswDk3KKXUNQg9ht-J_p1AzKI7BVZ3kcP3U_2E=.6ef90d5b-23b4-4237-9359-1e7c741b3358@github.com>
Message-ID: <oX6MXSlHuOkdBbukrG8QVNg4yEhhu5lC2u427WfNHU4=.4a12c4fc-5fca-49c3-bab1-40e55a9cd897@github.com>

On Thu, 19 Jun 2025 11:01:28 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The 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 sv-release-supplier2
>>  - Fix performance regression
>>  - Clean up
>>  - Fix bug
>>  - Simplify
>>  - Revert to records
>>  - Make code more like the old one
>>  - Add removable underlying functions
>
> src/java.base/share/classes/jdk/internal/lang/stable/StableSupplier.java line 46:
> 
>> 44:     @Override
>> 45:     public T get() {
>> 46:         return delegate.orElseSet(underlyingHolder.underlying(), underlyingHolder);
> 
> By?avoiding?reading from?`underlyingHolder` when?the?`StableValue` is?already?set, this?can?avoid the?overhead of?a?field?read from?`underlyingHolder`:
> Suggestion:
> 
>         final Object t = delegate.wrappedContentsAcquire();
>         if (t != null) {
>             return unwrap(t);
>         }
>         return delegate.orElseSet(underlyingHolder.underlying(), underlyingHolder);

Before this proposal:


Benchmark                               Mode  Cnt  Score   Error  Units
StableSupplierBenchmark.stable          avgt   10  1.369 ? 0.019  ns/op
StableSupplierBenchmark.staticStable    avgt   10  0.343 ? 0.005  ns/op
StableSupplierBenchmark.staticSupplier  avgt   10  0.389 ? 0.008  ns/op
StableSupplierBenchmark.supplier        avgt   10  1.739 ? 0.047  ns/op


After this proposal:


Benchmark                               Mode  Cnt  Score   Error  Units
StableSupplierBenchmark.stable          avgt   10  1.436 ? 0.120  ns/op
StableSupplierBenchmark.staticStable    avgt   10  0.352 ? 0.044  ns/op
StableSupplierBenchmark.staticSupplier  avgt   10  0.346 ? 0.016  ns/op
StableSupplierBenchmark.supplier        avgt   10  1.588 ? 0.035  ns/op. <-- !


So, it appears to be some gain here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25878#discussion_r2156934164

From alanb at openjdk.org  Thu Jun 19 12:52:42 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 19 Jun 2025 12:52:42 GMT
Subject: RFR: 8359830: Incorrect os.version reported on macOS Tahoe 26
 (Beta)
In-Reply-To: <dIYjIn7ZiNM0p0D0nTJN-B08KdxqZ-pPO__CRNrhgY0=.2f533c49-a9c1-4a03-9d69-eb747ef3e8a9@github.com>
References: <dIYjIn7ZiNM0p0D0nTJN-B08KdxqZ-pPO__CRNrhgY0=.2f533c49-a9c1-4a03-9d69-eb747ef3e8a9@github.com>
Message-ID: <Gt_p6Gr1dMMBlskwnBT-qEdYAJUqiKh8SqVI-ja5gDw=.d5aac4db-1e8e-4989-8c5f-726274bd67d3@github.com>

On Wed, 18 Jun 2025 06:01:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8359830?
> 
> macOS operating system's newer version 26 (currently in Beta) is reported as a 16 by older versions of XCode. JDK internally uses the `NSProcessInfo` and `NSOperatingSystemVersion` APIs to identify the macOS version and set the `os.version` system property to that value. The current recommended version to build the JDK on macOS is XCode 15.4. The `NSOperatingSystemVersion` API on that version of XCode reports macOS version as 16 instead of 26.
> 
> The commit in this PR updates the JDK code to handle this mismatch and set the `os.version` appropriately to 26. This fix is similar to what we did with macOS BigSur when the macOS version 10.16 was meant to mean 11 https://bugs.openjdk.org/browse/JDK-8253702. 
> 
> The existing `OsVersionTest` has been updated for some trivial clean up. Existing tests in tier1, tier2 and tier3 continue to pass with this change. If anyone has access to a macOS 26 Beta, I request them to build this change and run `tier1` tests to help verify that there aren't any failures.

Are there changes for os_bsd.cpp too?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25865#issuecomment-2987999212

From vklang at openjdk.org  Thu Jun 19 14:26:42 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 19 Jun 2025 14:26:42 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements [v5]
In-Reply-To: <ERciNc3tSasAPYrkZM9mb7xiA8sxkinQy958Usqu430=.a4ee43a1-96d6-40c3-9d7b-a5f5be81ce22@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
 <ERciNc3tSasAPYrkZM9mb7xiA8sxkinQy958Usqu430=.a4ee43a1-96d6-40c3-9d7b-a5f5be81ce22@github.com>
Message-ID: <-etfD_znOhF9vLj5ExmcaMukYbBWOPkqbfLCTJg1AHE=.54fa60f0-0843-4421-9964-63bfeb435c6c@github.com>

On Thu, 19 Jun 2025 11:58:33 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add JDK-8190889 docfix

src/java.base/share/classes/java/util/concurrent/CompletionStage.java line 155:

> 153:  * <i>happen-before</i> that computation begins. And actions taken by
> 154:  * {@code CompletionStage x} <i>happen-before</i> actions of any
> 155:  * dependent stage subsequent to {@code x}'s completion.

?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25880#discussion_r2157148191

From dl at openjdk.org  Thu Jun 19 17:30:14 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 19 Jun 2025 17:30:14 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements [v6]
In-Reply-To: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
Message-ID: <-Kufr-aHomqMPg42voqeRSzvdwQu0_sgT0jg9PLzJkQ=.a31a9958-e903-43b4-9cb2-2ebb476328bf@github.com>

> This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Add JDK-6317534 and JDK-6351533 doc improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25880/files
  - new: https://git.openjdk.org/jdk/pull/25880/files/4ef7649a..b10114e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25880&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25880&range=04-05

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25880.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25880/head:pull/25880

PR: https://git.openjdk.org/jdk/pull/25880

From duke at openjdk.org  Thu Jun 19 17:42:30 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 19 Jun 2025 17:42:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <yC5NAA2uzq92MZGyXJQkRYallBsQCJpF8vmemkndk9c=.c7bb4cff-9af0-4d25-9782-dbe35cafcfd8@github.com>

On Wed, 18 Jun 2025 15:25:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 183:
> 
>> 181: size.bit.alg=%1$d-Bit-%2$s
>> 182: Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und selbstsigniertem Zertifikat ({1}) mit einer G?ltigkeit von {2} Tagen\n\tf?r: {3}
>> 183: Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und einem von <{2}> ausgestellten Zertifikat ({1}) mit einer G?ltigkeit von {3} Tagen\n\tf?r: {4}
> 
> It feels as if there's something missing after _?einem?_.

seems ok to me, einem von X ausgestellten Zertifikat ~ einem Zertifikat, das von X ausgestellt wurde

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2157444024

From dl at openjdk.org  Thu Jun 19 18:31:17 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 19 Jun 2025 18:31:17 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements [v7]
In-Reply-To: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
Message-ID: <zGPKnbWSOeDAsjIWYONUrcyBAdlI-7FPGUcFoft19ps=.0cf26f16-b552-4fb4-81f6-191887914432@github.com>

> This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Add JDK-8195628 doc fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25880/files
  - new: https://git.openjdk.org/jdk/pull/25880/files/b10114e5..c85698c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25880&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25880&range=05-06

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25880.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25880/head:pull/25880

PR: https://git.openjdk.org/jdk/pull/25880

From dl at openjdk.org  Thu Jun 19 22:49:17 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 19 Jun 2025 22:49:17 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements [v8]
In-Reply-To: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
Message-ID: <dDyhg7PqXliwANTO-jIK3PNfcb2HawdSb4ZvMLyEiMg=.7ac219c3-9c7c-4185-ba7e-0e338414f669@github.com>

> This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Adding JDK-8333172 to doc improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25880/files
  - new: https://git.openjdk.org/jdk/pull/25880/files/c85698c7..93ece642

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25880&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25880&range=06-07

  Stats: 32 lines in 3 files changed: 19 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/25880.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25880/head:pull/25880

PR: https://git.openjdk.org/jdk/pull/25880

From alanb at openjdk.org  Fri Jun 20 12:13:30 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Jun 2025 12:13:30 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements [v8]
In-Reply-To: <dDyhg7PqXliwANTO-jIK3PNfcb2HawdSb4ZvMLyEiMg=.7ac219c3-9c7c-4185-ba7e-0e338414f669@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
 <dDyhg7PqXliwANTO-jIK3PNfcb2HawdSb4ZvMLyEiMg=.7ac219c3-9c7c-4185-ba7e-0e338414f669@github.com>
Message-ID: <AqmXNwhk_eVthSdnbeloLVcM-Rdq351YXH0_XA5PSTc=.668926cf-3045-4f43-85cf-749bba471774@github.com>

On Thu, 19 Jun 2025 22:49:17 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding JDK-8333172 to doc improvements

src/java.base/share/classes/java/util/concurrent/TimeUnit.java line 402:

> 400:      * or equal to zero, do not wait at all.
> 401:      * @throws  IllegalMonitorStateException  if the current thread is not
> 402:      *               the owner of this object's monitor.

This should probably use "the object's monitor" rather than "the object's monitor" as "this" is the TimeUnit instance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25880#discussion_r2158815125

From alanb at openjdk.org  Fri Jun 20 12:22:30 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Jun 2025 12:22:30 GMT
Subject: RFR: 8359919: Minor java.util.concurrent doc improvements [v8]
In-Reply-To: <dDyhg7PqXliwANTO-jIK3PNfcb2HawdSb4ZvMLyEiMg=.7ac219c3-9c7c-4185-ba7e-0e338414f669@github.com>
References: <T5v75GWzehICmLBko9W0DbCtUGTZXNFHnZfdWlwqab4=.2f7f6168-8e78-4836-8451-292e49083bac@github.com>
 <dDyhg7PqXliwANTO-jIK3PNfcb2HawdSb4ZvMLyEiMg=.7ac219c3-9c7c-4185-ba7e-0e338414f669@github.com>
Message-ID: <ae0hc9ZLVQsm5lvOX52K5V_LbUBV5eebOUjHWfwyai8=.b611aa07-bb5c-46c0-afb1-b3f16098ae00@github.com>

On Thu, 19 Jun 2025 22:49:17 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This collects miscellaneous open issues that can be resolved with documentation updates; each indicated by adding JDK issue numbers
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding JDK-8333172 to doc improvements

src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java line 86:

> 84:  *   }
> 85:  *   // ... and so on
> 86:  * }}</pre>

I wonder if this should be convert to a `{@snippet ..}` and have it handle the checked exceptions thrown by findVarHandle. I'm just thinking of someone seeing VarHandle usage for first time, then reporting a bug that the example doesn't compile.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25880#discussion_r2158832831