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 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 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 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 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 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 shade at openjdk.org  Mon Jun  2 14:58:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 14:58:56 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v5]
In-Reply-To: <Qg0_gMfrt-7sL33BFT2OfTqm9QN3ZtZ-bhia7mKV43o=.9e4e64be-a754-4fd6-814f-2c19fa622cc6@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <Qg0_gMfrt-7sL33BFT2OfTqm9QN3ZtZ-bhia7mKV43o=.9e4e64be-a754-4fd6-814f-2c19fa622cc6@github.com>
Message-ID: <CiwfC3eMjGzYH_Y1CkaAkmxEmxFESLJI0eRUjDZZJjQ=.2d4abd2f-a018-498d-b4ee-30752cf36ecd@github.com>

On Thu, 29 May 2025 14:29:43 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

>> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
>> 
>> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>>  
>> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
>> 
>> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
>> 
>> **before**
>> 
>> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
>> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
>> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
>> [1
>> 
>> **after**
>> 
>> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
>> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
>> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
>> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
>> 
>> 
>> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
>> 
>> **Before**
>> 
>> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
>> B...
>
> Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant comment

Looks good to me, but we need to polish the benchmark.

test/micro/org/openjdk/bench/java/nio/ByteBufferAllocationBenchmark.java line 43:

> 41: @State(Scope.Thread)
> 42: @Measurement(iterations = 5)
> 43: @Warmup(iterations = 5)

Suggestion:

@Warmup(iterations = 3, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 3, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(3)

test/micro/org/openjdk/bench/java/nio/ByteBufferAllocationBenchmark.java line 44:

> 42: @Measurement(iterations = 5)
> 43: @Warmup(iterations = 5)
> 44: public class ByteBufferAllocationBenchmark {

I could have sworn we added some `ByteBuffer` allocation benchmarks before. But I cannot find them. For consistency with other tests, I suggest naming this test `DirectByteBufferAlloc.java`.

test/micro/org/openjdk/bench/java/nio/ByteBufferAllocationBenchmark.java line 50:

> 48:             "1024", // 1KB
> 49:             "1048576", // 1 MB
> 50:             "2147483647" // ~2 GB

Trying to allocate 2GB would likely fail on lots of testing hosts. Since we want to tickle 1MB limit, I suggest testing with 16MB.

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

PR Review: https://git.openjdk.org/jdk/pull/25487#pullrequestreview-2888804487
PR Review Comment: https://git.openjdk.org/jdk/pull/25487#discussion_r2121408158
PR Review Comment: https://git.openjdk.org/jdk/pull/25487#discussion_r2121405948
PR Review Comment: https://git.openjdk.org/jdk/pull/25487#discussion_r2121409454

From bpb at openjdk.org  Mon Jun  2 15:47:52 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 2 Jun 2025 15:47:52 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat
In-Reply-To: <Q0EnWNSmtyOQwl3WeAdm_iABnzf2B2nRogvyWWMEQRA=.3df809f0-c63b-45ca-b64f-3ee783bc9506@github.com>
References: <y6Tbzr-6MDJ6I4S9_cLPIlnMgda81JMRiinpQVdvsMs=.f67074fe-d43a-4d6f-99f9-1c336819b31c@github.com>
 <hI2g5P134ARzGplZDwmVTH2vJnDMFaQHuGgbXoTs9xs=.7ad682d0-cda1-4bd9-9f33-57e1ab036c19@github.com>
 <dgSIZeOfXZzXxnqzr7mGIqu4Z2BFyaUyrk104U6flLM=.d8617155-46c1-4ef9-921f-e1f8c9233142@github.com>
 <nIzMbJ1dZiFJ2tH-FMzTWliB_mAmNuxFJV6xUeR2h5c=.caad9dc7-9266-4b24-bbab-4f80053e3880@github.com>
 <Q0EnWNSmtyOQwl3WeAdm_iABnzf2B2nRogvyWWMEQRA=.3df809f0-c63b-45ca-b64f-3ee783bc9506@github.com>
Message-ID: <0iDUEz2OGuNzR_aqeQFgU-IvGloTiNjt8fyH1D-LX8A=.d466db2c-3e7a-4cbf-af52-85a697bdb1fe@github.com>

On Sat, 31 May 2025 06:36:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Okay, let's go with what you have for now and we can mull over re-visiting this list. It dates from when the support for the "at" functions varied across operating systems and versions.

Agreed. On Linux, the `openat`, `unlinkat`, and `renameat` calls appear all, like `fchmodat`, to have been introduced in Linux version 2.6.16 which was in 2008, so I suspect these will be able to be dropped from the check. It would be helpful to know which of the calls are not available on AIX (@MBaesken).

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

PR Comment: https://git.openjdk.org/jdk/pull/25534#issuecomment-2931326662

From bpb at openjdk.org  Mon Jun  2 16:16:07 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 2 Jun 2025 16:16:07 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat [v4]
In-Reply-To: <y6Tbzr-6MDJ6I4S9_cLPIlnMgda81JMRiinpQVdvsMs=.f67074fe-d43a-4d6f-99f9-1c336819b31c@github.com>
References: <y6Tbzr-6MDJ6I4S9_cLPIlnMgda81JMRiinpQVdvsMs=.f67074fe-d43a-4d6f-99f9-1c336819b31c@github.com>
Message-ID: <_k8E_FsCnmfTWrLrhDzuYZCjV1I28Drae8RmI1E4DjM=.cd9ce709-1108-4d6b-ac16-1a7706c50032@github.com>

> Modify to use the `fchmodat(2)` system call to set permissions where possible to do so. This fixes the problem presented in the issue description.

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

  8357425: Use try-with-resources in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25534/files
  - new: https://git.openjdk.org/jdk/pull/25534/files/bf2316ed..bf2a80f0

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

  Stats: 56 lines in 1 file changed: 15 ins; 15 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/25534.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25534/head:pull/25534

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

From bpb at openjdk.org  Mon Jun  2 16:16:07 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 2 Jun 2025 16:16:07 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat [v3]
In-Reply-To: <OLogRoCZv4VbQ4wReAjaTALI_4RpKU1OO10RipcFsKs=.b652bc35-dc0c-42a4-83c9-991831df0fbb@github.com>
References: <y6Tbzr-6MDJ6I4S9_cLPIlnMgda81JMRiinpQVdvsMs=.f67074fe-d43a-4d6f-99f9-1c336819b31c@github.com>
 <oE2ovEHpVY1Tp77JYLWW6UK5iCFyazIA2d5oFXdZe3o=.60f9e77e-fce0-4e1c-b77f-068e4817e314@github.com>
 <OLogRoCZv4VbQ4wReAjaTALI_4RpKU1OO10RipcFsKs=.b652bc35-dc0c-42a4-83c9-991831df0fbb@github.com>
Message-ID: <i44fnrpEG2BphxrUn4pVvROZYb44invgRCuLRjZEgJo=.5a2f019a-0de9-4e49-9755-1ea52d427fea@github.com>

On Sat, 31 May 2025 06:27:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357425: Change view used to set directory permissions
>
> test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 187:
> 
>> 185:         Set<PosixFilePermission> permsDir = getPosixFilePermissions(aDir);
>> 186: 
>> 187:         SecureDirectoryStream<Path> stream =
> 
> If you are doing any more edits then you can change this to use try-with-resources.

So changed in https://github.com/openjdk/jdk/pull/25534/commits/bf2a80f06d2dbe95d03fd79bbeae65cf4318beea.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25534#discussion_r2121610856

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 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 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 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 duke at openjdk.org  Tue Jun  3 08:12:38 2025
From: duke at openjdk.org (Rohitash Kumar)
Date: Tue, 3 Jun 2025 08:12:38 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v6]
In-Reply-To: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
Message-ID: <a2OO1FMEnCaoAbw6Zj5ObGYICiOND4KPtOvwn3442eA=.6d92a436-60f9-440f-9f46-3fd825590e0f@github.com>

> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
> 
> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>  
> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
> 
> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
> 
> **before**
> 
> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
> [1
> 
> **after**
> 
> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
> 
> 
> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
> 
> **Before**
> 
> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
> ByteBufferAllocationBenchmark.allocateDirectBuffer         1...

Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Update test/micro/org/openjdk/bench/java/nio/ByteBufferAllocationBenchmark.java
  
  Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25487/files
  - new: https://git.openjdk.org/jdk/pull/25487/files/17cce92c..e45dc133

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

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

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

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 duke at openjdk.org  Tue Jun  3 08:35:45 2025
From: duke at openjdk.org (Rohitash Kumar)
Date: Tue, 3 Jun 2025 08:35:45 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v7]
In-Reply-To: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
Message-ID: <P_JMGnVUgEGhkws8Vv8-ZHyAqJ1efNJB3qXy35dAMzg=.5908354b-601a-486b-a1d3-035a5ea3f518@github.com>

> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
> 
> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>  
> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
> 
> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
> 
> **before**
> 
> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
> [1
> 
> **after**
> 
> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
> 
> 
> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
> 
> **Before**
> 
> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
> ByteBufferAllocationBenchmark.allocateDirectBuffer         1...

Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Address PR Comments (rename bench and reduce max alloc size)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25487/files
  - new: https://git.openjdk.org/jdk/pull/25487/files/e45dc133..c4951938

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

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

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

From shade at openjdk.org  Tue Jun  3 09:12:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jun 2025 09:12:54 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v7]
In-Reply-To: <P_JMGnVUgEGhkws8Vv8-ZHyAqJ1efNJB3qXy35dAMzg=.5908354b-601a-486b-a1d3-035a5ea3f518@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <P_JMGnVUgEGhkws8Vv8-ZHyAqJ1efNJB3qXy35dAMzg=.5908354b-601a-486b-a1d3-035a5ea3f518@github.com>
Message-ID: <QjYaJw0nihDXt3RYnJqylYVO11BGC-3DlNpHJQLhspw=.dd910412-cbdf-4fe5-851a-fafe4b4d75f9@github.com>

On Tue, 3 Jun 2025 08:35:45 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

>> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
>> 
>> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>>  
>> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
>> 
>> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
>> 
>> **before**
>> 
>> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
>> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
>> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
>> [1
>> 
>> **after**
>> 
>> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
>> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
>> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
>> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
>> 
>> 
>> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
>> 
>> **Before**
>> 
>> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
>> B...
>
> Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR Comments (rename bench and reduce max alloc size)

Now that clearing code is a bit more complicated, I think we need to extend the test that verifies that DBB is properly initialized. There is already one test, but it is unsatisfactory.

Amend it like this:  [8357959-test.txt](https://github.com/user-attachments/files/20565736/8357959-test.txt) -- then run on your new code (`make test TEST=java/nio/Buffer/AllocateDirectInit.java`).

src/java.base/share/classes/java/nio/Bits.java line 248:

> 246:      *        the starting memory address
> 247:      * @param size
> 248:      *        the number of bytes to set

Bikeshedding: This is probably `count`, not `size`.

src/java.base/share/classes/java/nio/Bits.java line 260:

> 258:             offset += len;
> 259:         }
> 260:     }

So this becomes:

Suggestion:

    static void setMemory(long srcAddr, long count, byte value) {
        long offset = 0;
        while (offset < count) {
            long len = Math.min(UNSAFE_SET_THRESHOLD, count - offset);
            UNSAFE.setMemory(srcAddr + offset, len, value);
            offset += len;
        }
    }

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

PR Review: https://git.openjdk.org/jdk/pull/25487#pullrequestreview-2891346767
PR Review Comment: https://git.openjdk.org/jdk/pull/25487#discussion_r2123164214
PR Review Comment: https://git.openjdk.org/jdk/pull/25487#discussion_r2123168075

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 duke at openjdk.org  Tue Jun  3 09:50:02 2025
From: duke at openjdk.org (Rohitash Kumar)
Date: Tue, 3 Jun 2025 09:50:02 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v7]
In-Reply-To: <QjYaJw0nihDXt3RYnJqylYVO11BGC-3DlNpHJQLhspw=.dd910412-cbdf-4fe5-851a-fafe4b4d75f9@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <P_JMGnVUgEGhkws8Vv8-ZHyAqJ1efNJB3qXy35dAMzg=.5908354b-601a-486b-a1d3-035a5ea3f518@github.com>
 <QjYaJw0nihDXt3RYnJqylYVO11BGC-3DlNpHJQLhspw=.dd910412-cbdf-4fe5-851a-fafe4b4d75f9@github.com>
Message-ID: <aVALs70p2BFntzKsmJngImct1ZyDDoLyXV9__Zqh3hg=.0dbadf49-0d73-4a48-805e-1d61e44239f9@github.com>

On Tue, 3 Jun 2025 08:49:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address PR Comments (rename bench and reduce max alloc size)
>
> src/java.base/share/classes/java/nio/Bits.java line 260:
> 
>> 258:             offset += len;
>> 259:         }
>> 260:     }
> 
> So this becomes:
> 
> Suggestion:
> 
>     static void setMemory(long srcAddr, long count, byte value) {
>         long offset = 0;
>         while (offset < count) {
>             long len = Math.min(UNSAFE_SET_THRESHOLD, count - offset);
>             UNSAFE.setMemory(srcAddr + offset, len, value);
>             offset += len;
>         }
>     }

It might be trival but isn't it better to keep `len` declaration outside of while loop?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25487#discussion_r2123307761

From shade at openjdk.org  Tue Jun  3 10:07:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jun 2025 10:07:53 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v7]
In-Reply-To: <aVALs70p2BFntzKsmJngImct1ZyDDoLyXV9__Zqh3hg=.0dbadf49-0d73-4a48-805e-1d61e44239f9@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <P_JMGnVUgEGhkws8Vv8-ZHyAqJ1efNJB3qXy35dAMzg=.5908354b-601a-486b-a1d3-035a5ea3f518@github.com>
 <QjYaJw0nihDXt3RYnJqylYVO11BGC-3DlNpHJQLhspw=.dd910412-cbdf-4fe5-851a-fafe4b4d75f9@github.com>
 <aVALs70p2BFntzKsmJngImct1ZyDDoLyXV9__Zqh3hg=.0dbadf49-0d73-4a48-805e-1d61e44239f9@github.com>
Message-ID: <-Odwq8p7yXK9SHHellbMtKp7zaOk3YBBzh_81lskCAA=.849e617c-a603-4574-9bec-e7a14189c716@github.com>

On Tue, 3 Jun 2025 09:47:01 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/Bits.java line 260:
>> 
>>> 258:             offset += len;
>>> 259:         }
>>> 260:     }
>> 
>> So this becomes:
>> 
>> Suggestion:
>> 
>>     static void setMemory(long srcAddr, long count, byte value) {
>>         long offset = 0;
>>         while (offset < count) {
>>             long len = Math.min(UNSAFE_SET_THRESHOLD, count - offset);
>>             UNSAFE.setMemory(srcAddr + offset, len, value);
>>             offset += len;
>>         }
>>     }
>
> It might be trival but isn't it better to keep `len` declaration outside of while loop?

I don't think so, reliability argument wins: put the variables in their closest scope. Here, for example, it shows directly that `len` is (re-)defined for every iteration. There are hardly any performance implications of doing this, barring compiler nitpicks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25487#discussion_r2123349452

From shade at openjdk.org  Tue Jun  3 10:12:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jun 2025 10:12:52 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v7]
In-Reply-To: <P_JMGnVUgEGhkws8Vv8-ZHyAqJ1efNJB3qXy35dAMzg=.5908354b-601a-486b-a1d3-035a5ea3f518@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <P_JMGnVUgEGhkws8Vv8-ZHyAqJ1efNJB3qXy35dAMzg=.5908354b-601a-486b-a1d3-035a5ea3f518@github.com>
Message-ID: <x6dmmL8jVL-7jR762fVLL2M5AB4pLSmbBmIsKNEbot8=.7b626fe4-df31-4625-9a48-f70ee299dbc7@github.com>

On Tue, 3 Jun 2025 08:35:45 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

>> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
>> 
>> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>>  
>> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
>> 
>> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
>> 
>> **before**
>> 
>> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
>> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
>> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
>> [1
>> 
>> **after**
>> 
>> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
>> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
>> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
>> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
>> 
>> 
>> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
>> 
>> **Before**
>> 
>> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
>> B...
>
> Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR Comments (rename bench and reduce max alloc size)

Also, I do not see GHA runs. Go to https://github.com/rk-kmr/jdk/actions and enable the workflows before you push the new commits.

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

PR Comment: https://git.openjdk.org/jdk/pull/25487#issuecomment-2934494259

From duke at openjdk.org  Tue Jun  3 10:32:13 2025
From: duke at openjdk.org (Rohitash Kumar)
Date: Tue, 3 Jun 2025 10:32:13 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v8]
In-Reply-To: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
Message-ID: <OCVWFXwttmUkRp-AJmmuFT69Ar2pBBs-Fkc_0EgAqrI=.43530e88-a679-450d-a3be-e4529002483b@github.com>

> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
> 
> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>  
> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
> 
> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
> 
> **before**
> 
> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
> [1
> 
> **after**
> 
> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
> 
> 
> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
> 
> **Before**
> 
> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
> ByteBufferAllocationBenchmark.allocateDirectBuffer         1...

Rohitash Kumar has updated the pull request incrementally with two additional commits since the last revision:

 - rename param from size to count
 - Apply patch for test extension

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25487/files
  - new: https://git.openjdk.org/jdk/pull/25487/files/c4951938..2abf1423

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

  Stats: 49 lines in 2 files changed: 31 ins; 1 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/25487.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25487/head:pull/25487

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

From shade at openjdk.org  Tue Jun  3 10:41:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jun 2025 10:41:53 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v8]
In-Reply-To: <OCVWFXwttmUkRp-AJmmuFT69Ar2pBBs-Fkc_0EgAqrI=.43530e88-a679-450d-a3be-e4529002483b@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <OCVWFXwttmUkRp-AJmmuFT69Ar2pBBs-Fkc_0EgAqrI=.43530e88-a679-450d-a3be-e4529002483b@github.com>
Message-ID: <g0UtzSxE99JwnOOndwacl0RhbGSeSbADe1B6WvZ_Xiw=.fd8d4ffc-739d-48fd-81a9-48f042b5f9fd@github.com>

On Tue, 3 Jun 2025 10:32:13 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

>> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
>> 
>> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>>  
>> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
>> 
>> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
>> 
>> **before**
>> 
>> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
>> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
>> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
>> [1
>> 
>> **after**
>> 
>> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
>> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
>> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
>> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
>> 
>> 
>> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
>> 
>> **Before**
>> 
>> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
>> B...
>
> Rohitash Kumar has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - rename param from size to count
>  - Apply patch for test extension

This looks fine to me. @AlanBateman or other NIO folks should review this version as well.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25487#pullrequestreview-2891747034

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 alanb at openjdk.org  Tue Jun  3 14:02:18 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Jun 2025 14:02:18 GMT
Subject: RFR: 8358496: Concurrent reading from Socket with timeout executes
 sequentially
Message-ID: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>

If several threads attempt to read from a Socket's input stream at the same time then all but the winner will block trying to acquire the read lock.  This is okay for untimed-reads but surprising for timed-reads as the timeout is only effective after acquiring the lock. The SocketImpl is changed so that the timeout applies to the total time waiting to acquire and read.

A new test is added to the existing java/net/Socket/Timeouts test. It is migrated from TestNG to a JUnit test as a drive-by change - it's mostly mechanical and the changes kept as minimal as possible.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/25614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25614&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358496
  Stats: 173 lines in 2 files changed: 67 ins; 11 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/25614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25614/head:pull/25614

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

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 dfuchs at openjdk.org  Tue Jun  3 15:26:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Jun 2025 15:26:53 GMT
Subject: RFR: 8358496: Concurrent reading from Socket with timeout executes
 sequentially
In-Reply-To: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
References: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
Message-ID: <oOVwHGW_Gfwf1WZkttZYuZnzN-rHfnSFexA0vqZtSx0=.75a004cb-5ea1-474c-9707-041fd06a1ac7@github.com>

On Tue, 3 Jun 2025 12:56:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If several threads attempt to read from a Socket's input stream at the same time then all but the winner will block trying to acquire the read lock.  This is okay for untimed-reads but surprising for timed-reads as the timeout is only effective after acquiring the lock. The SocketImpl is changed so that the timeout applies to the total time waiting to acquire and read.
> 
> A new test is added to the existing java/net/Socket/Timeouts test. It is migrated from TestNG to a JUnit test as a drive-by change - it's mostly mechanical and the changes kept as minimal as possible.

Changes LGTM. Minor comment on the test.

test/jdk/java/net/Socket/Timeouts.java line 80:

> 78:         try (Socket s = new Socket()) {
> 79:             SocketAddress remote = Utils.refusingEndpoint();
> 80:             assertThrows(ConnectException.class,  () -> s.connect(remote, 10000));

Ah! Good - you're even fixing a bug here.

test/jdk/java/net/Socket/Timeouts.java line 249:

> 247:                         () -> s.getInputStream().read());
> 248:                 int timeout = s.getSoTimeout();
> 249:                 checkDuration(startMillis, timeout-100, timeout+20_000);

Maybe it would be worth noting here that if the bug isn't fixed, the last thread to call read() would have to wait for 200 seconds, which largely exceeds 22s?

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25614#pullrequestreview-2893023129
PR Review Comment: https://git.openjdk.org/jdk/pull/25614#discussion_r2124221517
PR Review Comment: https://git.openjdk.org/jdk/pull/25614#discussion_r2124218812

From alanb at openjdk.org  Tue Jun  3 15:35:29 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Jun 2025 15:35:29 GMT
Subject: RFR: 8357425: (fs) SecureDirectoryStream setPermissions should use
 fchmodat [v4]
In-Reply-To: <_k8E_FsCnmfTWrLrhDzuYZCjV1I28Drae8RmI1E4DjM=.cd9ce709-1108-4d6b-ac16-1a7706c50032@github.com>
References: <y6Tbzr-6MDJ6I4S9_cLPIlnMgda81JMRiinpQVdvsMs=.f67074fe-d43a-4d6f-99f9-1c336819b31c@github.com>
 <_k8E_FsCnmfTWrLrhDzuYZCjV1I28Drae8RmI1E4DjM=.cd9ce709-1108-4d6b-ac16-1a7706c50032@github.com>
Message-ID: <taP4gxGSZ7mZBx5_CI4WhGo_euMbtVDYllcyEZ2thb4=.0ae13859-b505-4719-aef6-c4d389a94f3e@github.com>

On Mon, 2 Jun 2025 16:16:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify to use the `fchmodat(2)` system call to set permissions where possible to do so. This fixes the problem presented in the issue description.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357425: Use try-with-resources in test

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25534#pullrequestreview-2893085503

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 bpb at openjdk.org  Tue Jun  3 15:46:36 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 3 Jun 2025 15:46:36 GMT
Subject: Integrated: 8357425: (fs) SecureDirectoryStream setPermissions should
 use fchmodat
In-Reply-To: <y6Tbzr-6MDJ6I4S9_cLPIlnMgda81JMRiinpQVdvsMs=.f67074fe-d43a-4d6f-99f9-1c336819b31c@github.com>
References: <y6Tbzr-6MDJ6I4S9_cLPIlnMgda81JMRiinpQVdvsMs=.f67074fe-d43a-4d6f-99f9-1c336819b31c@github.com>
Message-ID: <yNihsV5uiYjfPs2TkbcmTsGh9d6Y-myt7Sz_uIDHnsQ=.ff48855a-21df-458f-9b16-51ad2379158d@github.com>

On Thu, 29 May 2025 23:37:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify to use the `fchmodat(2)` system call to set permissions where possible to do so. This fixes the problem presented in the issue description.

This pull request has now been integrated.

Changeset: 4604c86d
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4604c86d2fced32c186680788ba98f74df071b23
Stats:     125 lines in 4 files changed: 113 ins; 0 del; 12 mod

8357425: (fs) SecureDirectoryStream setPermissions should use fchmodat

Reviewed-by: alanb

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

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

From alanb at openjdk.org  Tue Jun  3 16:10:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Jun 2025 16:10:38 GMT
Subject: RFR: 8358496: Concurrent reading from Socket with timeout executes
 sequentially [v2]
In-Reply-To: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
References: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
Message-ID: <O5nTjJzL7tQyn4q_cfv1yTpGbfgIjUg1k9d1RkO0Qfs=.ec618e60-6d7c-4570-9ee8-1ffda5912f01@github.com>

> If several threads attempt to read from a Socket's input stream at the same time then all but the winner will block trying to acquire the read lock.  This is okay for untimed-reads but surprising for timed-reads as the timeout is only effective after acquiring the lock. The SocketImpl is changed so that the timeout applies to the total time waiting to acquire and read.
> 
> A new test is added to the existing java/net/Socket/Timeouts test. It is migrated from TestNG to a JUnit test as a drive-by change - it's mostly mechanical and the changes kept as minimal as possible.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Make test comment cleaner

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25614/files
  - new: https://git.openjdk.org/jdk/pull/25614/files/80fe13b1..3dc870ed

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

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

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

From alanb at openjdk.org  Tue Jun  3 16:10:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Jun 2025 16:10:38 GMT
Subject: RFR: 8358496: Concurrent reading from Socket with timeout executes
 sequentially [v2]
In-Reply-To: <oOVwHGW_Gfwf1WZkttZYuZnzN-rHfnSFexA0vqZtSx0=.75a004cb-5ea1-474c-9707-041fd06a1ac7@github.com>
References: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
 <oOVwHGW_Gfwf1WZkttZYuZnzN-rHfnSFexA0vqZtSx0=.75a004cb-5ea1-474c-9707-041fd06a1ac7@github.com>
Message-ID: <YdG_G79PYHPkos945VgqkiENqelgzIymYdmV8Oj6EIA=.da1bcdef-630f-4bbe-aceb-8f9ca7a90235@github.com>

On Tue, 3 Jun 2025 15:20:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make test comment cleaner
>
> test/jdk/java/net/Socket/Timeouts.java line 249:
> 
>> 247:                         () -> s.getInputStream().read());
>> 248:                 int timeout = s.getSoTimeout();
>> 249:                 checkDuration(startMillis, timeout-100, timeout+20_000);
> 
> Maybe it would be worth noting here that if the bug isn't fixed, the last thread to call read() would have to wait for 200 seconds, which largely exceeds 22s?

Okay, I can make the test method description a bit clearer on this point.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25614#discussion_r2124337179

From dfuchs at openjdk.org  Tue Jun  3 16:24:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Jun 2025 16:24:56 GMT
Subject: RFR: 8358496: Concurrent reading from Socket with timeout executes
 sequentially [v2]
In-Reply-To: <O5nTjJzL7tQyn4q_cfv1yTpGbfgIjUg1k9d1RkO0Qfs=.ec618e60-6d7c-4570-9ee8-1ffda5912f01@github.com>
References: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
 <O5nTjJzL7tQyn4q_cfv1yTpGbfgIjUg1k9d1RkO0Qfs=.ec618e60-6d7c-4570-9ee8-1ffda5912f01@github.com>
Message-ID: <M0LpoQIix4h2-UdKGpKlzto-oTJlt_yVYqXuJ50QPng=.43294b15-4393-4e8e-8cbb-a9d3847ef88d@github.com>

On Tue, 3 Jun 2025 16:10:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If several threads attempt to read from a Socket's input stream at the same time then all but the winner will block trying to acquire the read lock.  This is okay for untimed-reads but surprising for timed-reads as the timeout is only effective after acquiring the lock. The SocketImpl is changed so that the timeout applies to the total time waiting to acquire and read.
>> 
>> A new test is added to the existing java/net/Socket/Timeouts test. It is migrated from TestNG to a JUnit test as a drive-by change - it's mostly mechanical and the changes kept as minimal as possible.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make test comment cleaner

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25614#pullrequestreview-2893258189

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 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 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 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 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 bpb at openjdk.org  Tue Jun  3 20:51:30 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 3 Jun 2025 20:51:30 GMT
Subject: RFR: 8358537: (bf) JavaNioAccess::getBufferAddress bypasses direct
 buffer MemorySession state check
Message-ID: <xSSwwSM3iKkLS7HuAjbN2xoIJJEvfcqY2HvaAiCro6c=.55924517-36c7-4c10-ba0d-0417fc0353e8@github.com>

Add package-scope `long java.nio.Buffer::address()` to simply return the value of the `address` instance variable; use this method in `JavaNioAccess::getBufferAddress`.

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

Commit messages:
 - 8358537: (bf) JavaNioAccess::getBufferAddress bypasses direct buffer MemorySession state check

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

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

From bpb at openjdk.org  Tue Jun  3 20:51:30 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 3 Jun 2025 20:51:30 GMT
Subject: RFR: 8358537: (bf) JavaNioAccess::getBufferAddress bypasses direct
 buffer MemorySession state check
In-Reply-To: <xSSwwSM3iKkLS7HuAjbN2xoIJJEvfcqY2HvaAiCro6c=.55924517-36c7-4c10-ba0d-0417fc0353e8@github.com>
References: <xSSwwSM3iKkLS7HuAjbN2xoIJJEvfcqY2HvaAiCro6c=.55924517-36c7-4c10-ba0d-0417fc0353e8@github.com>
Message-ID: <b3whYtPznd6GqFuPJEUTbkN9pWYi9dpxnrBhdg3De-4=.2a054439-2e15-4512-858c-9a1f75ca3fb7@github.com>

On Tue, 3 Jun 2025 20:46:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add package-scope `long java.nio.Buffer::address()` to simply return the value of the `address` instance variable; use this method in `JavaNioAccess::getBufferAddress`.

`Buffer::address` is overridden for heap buffers to throw an `UnsupportedOperationException`. The `MemorySegments` test is modified to remove the use of shared `Arena`s which cause `UnsupportedOperationException`s to be thrown. The `jdk_core` tests have no failures attributable to these changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25631#issuecomment-2937144841

From jvernee at openjdk.org  Tue Jun  3 21:42:15 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 3 Jun 2025 21:42:15 GMT
Subject: RFR: 8358537: (bf) JavaNioAccess::getBufferAddress bypasses direct
 buffer MemorySession state check
In-Reply-To: <xSSwwSM3iKkLS7HuAjbN2xoIJJEvfcqY2HvaAiCro6c=.55924517-36c7-4c10-ba0d-0417fc0353e8@github.com>
References: <xSSwwSM3iKkLS7HuAjbN2xoIJJEvfcqY2HvaAiCro6c=.55924517-36c7-4c10-ba0d-0417fc0353e8@github.com>
Message-ID: <3WJKUR0fRSNYhzvp2a-BLgtka1jx_d1ImRU1QaFKLOw=.bfe07d01-4644-4df4-b8c1-e85ee94343c9@github.com>

On Tue, 3 Jun 2025 20:46:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add package-scope `long java.nio.Buffer::address()` to simply return the value of the `address` instance variable; use this method in `JavaNioAccess::getBufferAddress`.

test/jdk/java/nio/channels/etc/MemorySegments.java line 61:

> 59:      */
> 60:     static Stream<Supplier<Arena>> arenaSuppliers() {
> 61:         return Stream.of(Arena::global, Arena::ofAuto, Arena::ofConfined);

Why is using a shared arena causing the UOE to be thrown? I'd think that would be triggered by the use of heap buffers, but shared arena is for off-heap memory.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25631#discussion_r2124976750

From bpb at openjdk.org  Tue Jun  3 22:35:15 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 3 Jun 2025 22:35:15 GMT
Subject: RFR: 8358537: (bf) JavaNioAccess::getBufferAddress bypasses direct
 buffer MemorySession state check
In-Reply-To: <3WJKUR0fRSNYhzvp2a-BLgtka1jx_d1ImRU1QaFKLOw=.bfe07d01-4644-4df4-b8c1-e85ee94343c9@github.com>
References: <xSSwwSM3iKkLS7HuAjbN2xoIJJEvfcqY2HvaAiCro6c=.55924517-36c7-4c10-ba0d-0417fc0353e8@github.com>
 <3WJKUR0fRSNYhzvp2a-BLgtka1jx_d1ImRU1QaFKLOw=.bfe07d01-4644-4df4-b8c1-e85ee94343c9@github.com>
Message-ID: <f3-ABip4uzb2FMzBTCAtd3_ogBSZh8-2YMW6fGbENDw=.0fd22152-a66d-4b89-bf8f-6c7c92312365@github.com>

On Tue, 3 Jun 2025 21:39:54 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Add package-scope `long java.nio.Buffer::address()` to simply return the value of the `address` instance variable; use this method in `JavaNioAccess::getBufferAddress`.
>
> test/jdk/java/nio/channels/etc/MemorySegments.java line 61:
> 
>> 59:      */
>> 60:     static Stream<Supplier<Arena>> arenaSuppliers() {
>> 61:         return Stream.of(Arena::global, Arena::ofAuto, Arena::ofConfined);
> 
> Why is using a shared arena causing the UOE to be thrown? I'd think that would be triggered by the use of heap buffers, but shared arena is for off-heap memory.

I thin it's running into this method in DirectBufferX:

    public long address() {
        MemorySessionImpl session = session();
        if (session != null) {
            if (session.ownerThread() == null && session.isCloseable()) {
                throw new UnsupportedOperationException("ByteBuffer derived from closeable shared sessions not supported");
            }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25631#discussion_r2125050873

From jvernee at openjdk.org  Wed Jun  4 00:00:17 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 4 Jun 2025 00:00:17 GMT
Subject: RFR: 8358537: (bf) JavaNioAccess::getBufferAddress bypasses direct
 buffer MemorySession state check
In-Reply-To: <f3-ABip4uzb2FMzBTCAtd3_ogBSZh8-2YMW6fGbENDw=.0fd22152-a66d-4b89-bf8f-6c7c92312365@github.com>
References: <xSSwwSM3iKkLS7HuAjbN2xoIJJEvfcqY2HvaAiCro6c=.55924517-36c7-4c10-ba0d-0417fc0353e8@github.com>
 <3WJKUR0fRSNYhzvp2a-BLgtka1jx_d1ImRU1QaFKLOw=.bfe07d01-4644-4df4-b8c1-e85ee94343c9@github.com>
 <f3-ABip4uzb2FMzBTCAtd3_ogBSZh8-2YMW6fGbENDw=.0fd22152-a66d-4b89-bf8f-6c7c92312365@github.com>
Message-ID: <8u8uJR2BFSVVTuEpYBfI0gJ7lxn1svRHaKKmcV__YIg=.6c616f49-3017-423d-9fe3-1fa16222fb54@github.com>

On Tue, 3 Jun 2025 22:32:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/nio/channels/etc/MemorySegments.java line 61:
>> 
>>> 59:      */
>>> 60:     static Stream<Supplier<Arena>> arenaSuppliers() {
>>> 61:         return Stream.of(Arena::global, Arena::ofAuto, Arena::ofConfined);
>> 
>> Why is using a shared arena causing the UOE to be thrown? I'd think that would be triggered by the use of heap buffers, but shared arena is for off-heap memory.
>
> I thin it's running into this method in DirectBufferX:
> 
>     public long address() {
>         MemorySessionImpl session = session();
>         if (session != null) {
>             if (session.ownerThread() == null && session.isCloseable()) {
>                 throw new UnsupportedOperationException("ByteBuffer derived from closeable shared sessions not supported");
>             }

Oh, I see. IIRC this is why the shared secrets are bypassing the `address()` method. For shared arenas the caller is supposed to do an acquire/release, and then use shared secrets to get the buffer address, bypassing this check.

@minborg recently did some work to change over uses of `DirectBuffer::address` in https://github.com/openjdk/jdk/pull/25324 and https://github.com/openjdk/jdk/pull/25321

If ByteBuffers derived from segments with shared arenas no longer work with this patch, that seems like a regression to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25631#discussion_r2125140322

From bpb at openjdk.org  Wed Jun  4 00:43:20 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Jun 2025 00:43:20 GMT
Subject: RFR: 8358537: (bf) JavaNioAccess::getBufferAddress bypasses direct
 buffer MemorySession state check
In-Reply-To: <8u8uJR2BFSVVTuEpYBfI0gJ7lxn1svRHaKKmcV__YIg=.6c616f49-3017-423d-9fe3-1fa16222fb54@github.com>
References: <xSSwwSM3iKkLS7HuAjbN2xoIJJEvfcqY2HvaAiCro6c=.55924517-36c7-4c10-ba0d-0417fc0353e8@github.com>
 <3WJKUR0fRSNYhzvp2a-BLgtka1jx_d1ImRU1QaFKLOw=.bfe07d01-4644-4df4-b8c1-e85ee94343c9@github.com>
 <f3-ABip4uzb2FMzBTCAtd3_ogBSZh8-2YMW6fGbENDw=.0fd22152-a66d-4b89-bf8f-6c7c92312365@github.com>
 <8u8uJR2BFSVVTuEpYBfI0gJ7lxn1svRHaKKmcV__YIg=.6c616f49-3017-423d-9fe3-1fa16222fb54@github.com>
Message-ID: <nQyuTm7C24wD98EWR74OUIZ-WP0EuWFQQ9wbsVPb2Ys=.5a7a3cbf-83d6-426a-8179-d71d73f6fb2e@github.com>

On Tue, 3 Jun 2025 23:57:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I thin it's running into this method in DirectBufferX:
>> 
>>     public long address() {
>>         MemorySessionImpl session = session();
>>         if (session != null) {
>>             if (session.ownerThread() == null && session.isCloseable()) {
>>                 throw new UnsupportedOperationException("ByteBuffer derived from closeable shared sessions not supported");
>>             }
>
> Oh, I see. IIRC this is why the shared secrets are bypassing the `address()` method. For shared arenas the caller is supposed to do an acquire/release, and then use shared secrets to get the buffer address, bypassing this check.
> 
> @minborg recently did some work to change over uses of `DirectBuffer::address` in https://github.com/openjdk/jdk/pull/25324 and https://github.com/openjdk/jdk/pull/25321
> 
> If ByteBuffers derived from segments with shared arenas no longer work with this patch, that seems like a regression to me.

It could be. More study is clearly needed. This is related to #25531.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25631#discussion_r2125195256

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 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 alanb at openjdk.org  Wed Jun  4 09:03:18 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 09:03:18 GMT
Subject: RFR: 8358537: (bf) JavaNioAccess::getBufferAddress bypasses direct
 buffer MemorySession state check
In-Reply-To: <nQyuTm7C24wD98EWR74OUIZ-WP0EuWFQQ9wbsVPb2Ys=.5a7a3cbf-83d6-426a-8179-d71d73f6fb2e@github.com>
References: <xSSwwSM3iKkLS7HuAjbN2xoIJJEvfcqY2HvaAiCro6c=.55924517-36c7-4c10-ba0d-0417fc0353e8@github.com>
 <3WJKUR0fRSNYhzvp2a-BLgtka1jx_d1ImRU1QaFKLOw=.bfe07d01-4644-4df4-b8c1-e85ee94343c9@github.com>
 <f3-ABip4uzb2FMzBTCAtd3_ogBSZh8-2YMW6fGbENDw=.0fd22152-a66d-4b89-bf8f-6c7c92312365@github.com>
 <8u8uJR2BFSVVTuEpYBfI0gJ7lxn1svRHaKKmcV__YIg=.6c616f49-3017-423d-9fe3-1fa16222fb54@github.com>
 <nQyuTm7C24wD98EWR74OUIZ-WP0EuWFQQ9wbsVPb2Ys=.5a7a3cbf-83d6-426a-8179-d71d73f6fb2e@github.com>
Message-ID: <mV0Pk8SqzDx8ZtwEE0aWu_5IRaytxRiX_uXI8NMbYs4=.ba3bc847-865b-4fc6-9a68-c7287bf38417@github.com>

On Wed, 4 Jun 2025 00:41:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Oh, I see. IIRC this is why the shared secrets are bypassing the `address()` method. For shared arenas the caller is supposed to do an acquire/release, and then use shared secrets to get the buffer address, bypassing this check.
>> 
>> @minborg recently did some work to change over uses of `DirectBuffer::address` in https://github.com/openjdk/jdk/pull/25324 and https://github.com/openjdk/jdk/pull/25321
>> 
>> If ByteBuffers derived from segments with shared arenas no longer work with this patch, that seems like a regression to me.
>
> It could be. More study is clearly needed. This is related to #25531.

I added this test to ensure that memory segments allocated from any Arena could be used with the synchronous channels. It shouldn't be changed.

It may be that further work is required on the asynchronous channels, I will take a closer look.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25631#discussion_r2126079622

From alanb at openjdk.org  Wed Jun  4 09:55:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 09:55:20 GMT
Subject: Integrated: 8358496: Concurrent reading from Socket with timeout
 executes sequentially
In-Reply-To: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
References: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
Message-ID: <LGLho4LhsxCtg1IMn5zM3Cd9SAadVqAe379f5yresjk=.00fa5169-fca7-4f6d-8c6a-93b2e76a7d04@github.com>

On Tue, 3 Jun 2025 12:56:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If several threads attempt to read from a Socket's input stream at the same time then all but the winner will block trying to acquire the read lock.  This is okay for untimed-reads but surprising for timed-reads as the timeout is only effective after acquiring the lock. The SocketImpl is changed so that the timeout applies to the total time waiting to acquire and read.
> 
> A new test is added to the existing java/net/Socket/Timeouts test. It is migrated from TestNG to a JUnit test as a drive-by change - it's mostly mechanical and the changes kept as minimal as possible.

This pull request has now been integrated.

Changeset: 7838321b
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7838321b74276e45b92c54904ea31ef70ed9e33f
Stats:     174 lines in 2 files changed: 68 ins; 11 del; 95 mod

8358496: Concurrent reading from Socket with timeout executes sequentially

Reviewed-by: dfuchs

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

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

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 bpb at openjdk.org  Wed Jun  4 14:29:13 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Jun 2025 14:29:13 GMT
Subject: RFR: 8358537: (bf) JavaNioAccess::getBufferAddress bypasses direct
 buffer MemorySession state check [v2]
In-Reply-To: <xSSwwSM3iKkLS7HuAjbN2xoIJJEvfcqY2HvaAiCro6c=.55924517-36c7-4c10-ba0d-0417fc0353e8@github.com>
References: <xSSwwSM3iKkLS7HuAjbN2xoIJJEvfcqY2HvaAiCro6c=.55924517-36c7-4c10-ba0d-0417fc0353e8@github.com>
Message-ID: <4V9W09WuhUg4pVOxlpbkHCgrR7VMvZ6sTIwyOXV2R7M=.e1d3c74a-9169-4d09-b40c-cec575a0cbf0@github.com>

> Add package-scope `long java.nio.Buffer::address()` to simply return the value of the `address` instance variable; use this method in `JavaNioAccess::getBufferAddress`.

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

  8358537: Revert MemorySegments test change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25631/files
  - new: https://git.openjdk.org/jdk/pull/25631/files/7c2f0130..7e6c05ad

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

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

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

From bpb at openjdk.org  Wed Jun  4 14:29:14 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Jun 2025 14:29:14 GMT
Subject: RFR: 8358537: (bf) JavaNioAccess::getBufferAddress bypasses direct
 buffer MemorySession state check [v2]
In-Reply-To: <mV0Pk8SqzDx8ZtwEE0aWu_5IRaytxRiX_uXI8NMbYs4=.ba3bc847-865b-4fc6-9a68-c7287bf38417@github.com>
References: <xSSwwSM3iKkLS7HuAjbN2xoIJJEvfcqY2HvaAiCro6c=.55924517-36c7-4c10-ba0d-0417fc0353e8@github.com>
 <3WJKUR0fRSNYhzvp2a-BLgtka1jx_d1ImRU1QaFKLOw=.bfe07d01-4644-4df4-b8c1-e85ee94343c9@github.com>
 <f3-ABip4uzb2FMzBTCAtd3_ogBSZh8-2YMW6fGbENDw=.0fd22152-a66d-4b89-bf8f-6c7c92312365@github.com>
 <8u8uJR2BFSVVTuEpYBfI0gJ7lxn1svRHaKKmcV__YIg=.6c616f49-3017-423d-9fe3-1fa16222fb54@github.com>
 <nQyuTm7C24wD98EWR74OUIZ-WP0EuWFQQ9wbsVPb2Ys=.5a7a3cbf-83d6-426a-8179-d71d73f6fb2e@github.com>
 <mV0Pk8SqzDx8ZtwEE0aWu_5IRaytxRiX_uXI8NMbYs4=.ba3bc847-865b-4fc6-9a68-c7287bf38417@github.com>
Message-ID: <12wH5p-Aw8HXmI9DkAjuhBzhlDZ8POgqeFRwD32SUdg=.27bd3023-c56a-46ac-9d9d-9397eb076fb3@github.com>

On Wed, 4 Jun 2025 09:00:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It could be. More study is clearly needed. This is related to #25531.
>
> I added this test to ensure that memory segments allocated from any Arena could be used with the synchronous channels. It shouldn't be changed.
> 
> It may be that further work is required on the asynchronous channels, I will take a closer look.

Test change reverted in [7e6c05a](https://github.com/openjdk/jdk/pull/25631/commits/7e6c05add2e47bf4ef59af6753d4e85d9aa058f2).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25631#discussion_r2126741663

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 shade at openjdk.org  Wed Jun  4 15:09:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Jun 2025 15:09:53 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v5]
In-Reply-To: <7OGRS3HDffEZa2_AldHLrmo0ujN6PcxYzrjodi3yYVo=.f84f2b01-a7ee-4d0a-84f7-496c7c71e117@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <Qg0_gMfrt-7sL33BFT2OfTqm9QN3ZtZ-bhia7mKV43o=.9e4e64be-a754-4fd6-814f-2c19fa622cc6@github.com>
 <7OGRS3HDffEZa2_AldHLrmo0ujN6PcxYzrjodi3yYVo=.f84f2b01-a7ee-4d0a-84f7-496c7c71e117@github.com>
Message-ID: <_NNIj_VFS6CaPgH0qakYcdbs1Gr-sN72tKOc_JAiPl4=.26d07cd3-62d1-464a-a55a-0c4c5ae07e1a@github.com>

On Fri, 30 May 2025 13:05:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant comment
>
> Moving it to Bits.setMemory looks good.

I think this looks fine. @AlanBateman -- do you think it is worth having in JDK 25? I do. If you agree, we need to integrate this soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/25487#issuecomment-2940388659

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 stuefe at openjdk.org  Wed Jun  4 16:15:51 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 4 Jun 2025 16:15:51 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v8]
In-Reply-To: <OCVWFXwttmUkRp-AJmmuFT69Ar2pBBs-Fkc_0EgAqrI=.43530e88-a679-450d-a3be-e4529002483b@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <OCVWFXwttmUkRp-AJmmuFT69Ar2pBBs-Fkc_0EgAqrI=.43530e88-a679-450d-a3be-e4529002483b@github.com>
Message-ID: <dC1kOFyIEGZ1wTAj-HgC_eHwSQEhcgvNXH3Y-pFmSYk=.2af2c58c-c038-4f0b-92c8-657184a9c82e@github.com>

On Tue, 3 Jun 2025 10:32:13 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

>> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
>> 
>> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>>  
>> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
>> 
>> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
>> 
>> **before**
>> 
>> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
>> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
>> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
>> [1
>> 
>> **after**
>> 
>> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
>> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
>> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
>> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
>> 
>> 
>> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
>> 
>> **Before**
>> 
>> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
>> B...
>
> Rohitash Kumar has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - rename param from size to count
>  - Apply patch for test extension

This may be a stupid question but why do we not just mmap large allocations in Unsafe.allocateMemory (with anonymous mappings)? These sections would then come pre-zero-initialized by the OS, no? 

Edit: could not find this in Posix but at least on Linux it is zero initialized. See Linux man page for mmap on MAP_ANONYMOUS.

Edit edit: and since the glibc uses mmap for large allocations, chances are the memory is initialized unnecessarily by us, unless it was re-used from earlier glibc allocations.

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

PR Comment: https://git.openjdk.org/jdk/pull/25487#issuecomment-2940607873

From shade at openjdk.org  Wed Jun  4 16:39:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Jun 2025 16:39:54 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v8]
In-Reply-To: <dC1kOFyIEGZ1wTAj-HgC_eHwSQEhcgvNXH3Y-pFmSYk=.2af2c58c-c038-4f0b-92c8-657184a9c82e@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <OCVWFXwttmUkRp-AJmmuFT69Ar2pBBs-Fkc_0EgAqrI=.43530e88-a679-450d-a3be-e4529002483b@github.com>
 <dC1kOFyIEGZ1wTAj-HgC_eHwSQEhcgvNXH3Y-pFmSYk=.2af2c58c-c038-4f0b-92c8-657184a9c82e@github.com>
Message-ID: <CIEOOIYJfSHfdafoa6-Z7DQvJIRuwio3UpV3grIGvhA=.2f0f1bd3-1db4-4a8e-884c-8b09e4ee9fe0@github.com>

On Wed, 4 Jun 2025 16:10:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This may be a stupid question but why do we not just mmap large allocations in Unsafe.allocateMemory (with anonymous mappings)? These sections would then come pre-zero-initialized by the OS, no?

This is not a stupid question, but I think there are peculiarities down that path. I think we want native allocator to decide what is the mmap threshold (glibc malloc does it with configurable options). We want to make sure it is cross-platform or at least not very hairy. There might be no guarantee that all these "prezeroed" pages would not be mapped at the single zero page, which causes latency on first COW, and also likely throws off RSS accounting a bit. It might be worth exploring as deep-dive RFE. For now, it is cleaner (pun intended) to keep cleaning stuff ourselves.

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

PR Comment: https://git.openjdk.org/jdk/pull/25487#issuecomment-2940691597

From jvernee at openjdk.org  Wed Jun  4 17:12:51 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 4 Jun 2025 17:12:51 GMT
Subject: RFR: 8358537: (bf) JavaNioAccess::getBufferAddress bypasses direct
 buffer MemorySession state check [v2]
In-Reply-To: <4V9W09WuhUg4pVOxlpbkHCgrR7VMvZ6sTIwyOXV2R7M=.e1d3c74a-9169-4d09-b40c-cec575a0cbf0@github.com>
References: <xSSwwSM3iKkLS7HuAjbN2xoIJJEvfcqY2HvaAiCro6c=.55924517-36c7-4c10-ba0d-0417fc0353e8@github.com>
 <4V9W09WuhUg4pVOxlpbkHCgrR7VMvZ6sTIwyOXV2R7M=.e1d3c74a-9169-4d09-b40c-cec575a0cbf0@github.com>
Message-ID: <12xa6f9yGYRuajaK7MYZJasESK0qFyb4Kwng5Kdw-u0=.e17848b4-e392-4e72-9485-b1c16050cde7@github.com>

On Wed, 4 Jun 2025 14:29:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add package-scope `long java.nio.Buffer::address()` to simply return the value of the `address` instance variable; use this method in `JavaNioAccess::getBufferAddress`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8358537: Revert MemorySegments test change

Discussed this with the rest of the Panama team. The way it works currently (without this PR) is how it's intended to work.

The issue is that JDK code can take the address of a direct byte buffer and pass it to some native method, but if the buffer was backed by a shared arena, the memory can be freed in the middle of that. That's why the 'default' implementation in `DirectBuffer::address` throws an exception. Code that wants to use the address of a direct buffer backed by a shared arena first has to acquire the arena, then get the address, and after it is done using the address, release the arena again. The second step requires a way to bypass the check. i.e. the shared secrets implementation intentionally accesses the field directly.

As for heap buffers: The base object and address form an Unsafe addressing pair. i.e. these are passed to Unsafe accessor methods. For heap buffers this would be the array base offset + any offset into the array (in bytes). The implementation of e.g. `MemorySegment::ofBuffer` uses both to construct a memory segment, so again, the address needs to be accessible. But, since the implementation uses shared secrets to access the address, as long as that method keeps bypassing the `address()` accessor method, I think this will continue to work.

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

PR Comment: https://git.openjdk.org/jdk/pull/25631#issuecomment-2940787082

From mcimadamore at openjdk.org  Wed Jun  4 17:31:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Jun 2025 17:31:51 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v8]
In-Reply-To: <OCVWFXwttmUkRp-AJmmuFT69Ar2pBBs-Fkc_0EgAqrI=.43530e88-a679-450d-a3be-e4529002483b@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <OCVWFXwttmUkRp-AJmmuFT69Ar2pBBs-Fkc_0EgAqrI=.43530e88-a679-450d-a3be-e4529002483b@github.com>
Message-ID: <kPUThhHi4DSnc3HY4Y3XnzvouIFweuKL_RttMk6GvcA=.21b7f903-1547-4c4a-aab0-bd757fe8e489@github.com>

On Tue, 3 Jun 2025 10:32:13 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

>> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
>> 
>> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>>  
>> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
>> 
>> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
>> 
>> **before**
>> 
>> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
>> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
>> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
>> [1
>> 
>> **after**
>> 
>> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
>> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
>> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
>> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
>> 
>> 
>> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
>> 
>> **Before**
>> 
>> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
>> B...
>
> Rohitash Kumar has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - rename param from size to count
>  - Apply patch for test extension

Note: in FFM we actually use a plain `long` loop instead of calling `Unsafe::setMemory`:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java#L239

(to facilitate this, we ensure that all allocations are, internally, at least 8-byte aligned).

A simple loop like this, with only one input region of memory typically auto-vectorizes quite well. In the long run, I'd prefer to see bulk operations in Unsafe being rewritten to use simpler operations and loops. I think we're getting quite close, but we can't get all the way there for stuff like `copyMemory` because, currently, there are some problems in determining that two off-heap memory regions are provably disjoint (but this is not an issue in the case of `setMemory`).

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

PR Comment: https://git.openjdk.org/jdk/pull/25487#issuecomment-2940835094

From mcimadamore at openjdk.org  Wed Jun  4 17:34:50 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Jun 2025 17:34:50 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v8]
In-Reply-To: <OCVWFXwttmUkRp-AJmmuFT69Ar2pBBs-Fkc_0EgAqrI=.43530e88-a679-450d-a3be-e4529002483b@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <OCVWFXwttmUkRp-AJmmuFT69Ar2pBBs-Fkc_0EgAqrI=.43530e88-a679-450d-a3be-e4529002483b@github.com>
Message-ID: <xM_LJNjKsNvmHwlMU9XR39tRYt2Uj0PlDDAMEZxO2zA=.9f5bcce3-9651-4f08-9429-fa5970728df5@github.com>

On Tue, 3 Jun 2025 10:32:13 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

>> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
>> 
>> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>>  
>> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
>> 
>> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
>> 
>> **before**
>> 
>> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
>> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
>> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
>> [1
>> 
>> **after**
>> 
>> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
>> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
>> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
>> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
>> 
>> 
>> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
>> 
>> **Before**
>> 
>> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
>> B...
>
> Rohitash Kumar has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - rename param from size to count
>  - Apply patch for test extension

For the records, while the fix looks fine, I'm a bit on the fence whether it's too late to target 25, as sometimes these things can hit unexpected performance regressions with more real-world/complex code. Having more "bake time" to test would be preferrable IMHO.

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

PR Comment: https://git.openjdk.org/jdk/pull/25487#issuecomment-2940843015

From alanb at openjdk.org  Wed Jun  4 17:59:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 17:59:51 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v5]
In-Reply-To: <7OGRS3HDffEZa2_AldHLrmo0ujN6PcxYzrjodi3yYVo=.f84f2b01-a7ee-4d0a-84f7-496c7c71e117@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <Qg0_gMfrt-7sL33BFT2OfTqm9QN3ZtZ-bhia7mKV43o=.9e4e64be-a754-4fd6-814f-2c19fa622cc6@github.com>
 <7OGRS3HDffEZa2_AldHLrmo0ujN6PcxYzrjodi3yYVo=.f84f2b01-a7ee-4d0a-84f7-496c7c71e117@github.com>
Message-ID: <taCn1FI6nrTOaFaggIo2g22oQWW7XQj2-esVhyWGXgI=.f6496c8c-1eee-43f9-99df-1a91922861f3@github.com>

On Fri, 30 May 2025 13:05:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant comment
>
> Moving it to Bits.setMemory looks good.

> I think this looks fine. @AlanBateman -- do you think it is worth having in JDK 25? I do. If you agree, we need to integrate this soon.

I don't see anything wrong with the current change but it does feel like a change for early in a release rather than the day before forking.  Also this issue has existed for 20+ years so maybe better to hold off to after the fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/25487#issuecomment-2940903717

From bpb at openjdk.org  Wed Jun  4 18:12:50 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Jun 2025 18:12:50 GMT
Subject: RFR: 8358537: (bf) JavaNioAccess::getBufferAddress bypasses direct
 buffer MemorySession state check [v2]
In-Reply-To: <12xa6f9yGYRuajaK7MYZJasESK0qFyb4Kwng5Kdw-u0=.e17848b4-e392-4e72-9485-b1c16050cde7@github.com>
References: <xSSwwSM3iKkLS7HuAjbN2xoIJJEvfcqY2HvaAiCro6c=.55924517-36c7-4c10-ba0d-0417fc0353e8@github.com>
 <4V9W09WuhUg4pVOxlpbkHCgrR7VMvZ6sTIwyOXV2R7M=.e1d3c74a-9169-4d09-b40c-cec575a0cbf0@github.com>
 <12xa6f9yGYRuajaK7MYZJasESK0qFyb4Kwng5Kdw-u0=.e17848b4-e392-4e72-9485-b1c16050cde7@github.com>
Message-ID: <mbvhon8v-7GzXVSPt72Aju8HlpiTUjH28W3SaJS-1AU=.ce6690c0-b7e6-4b03-a64c-fb50bd35188c@github.com>

On Wed, 4 Jun 2025 17:09:07 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Discussed this with the rest of the Panama team. The way it works currently (without this PR) is how it's intended to work.

Thank you for the elucidation: that is very helpful.

Perhaps some comments need to be added in strategic places to clarify the situation to avoid similar confusion in the future? This PR arose out of #25531, in particular when [it was suggested](https://github.com/openjdk/jdk/pull/25531#discussion_r2115194676) to access the address of the direct buffer via `IOUtil.bufferAddress` which calls `JavaNioAccess.getBufferAddress`. A failure was expected for buffers created from shared `Arena`s but none occurred, and it looked like there had been an oversight in the buffer address access protocol.

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

PR Comment: https://git.openjdk.org/jdk/pull/25631#issuecomment-2940936917

From bpb at openjdk.org  Wed Jun  4 22:12:50 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Jun 2025 22:12:50 GMT
Subject: RFR: 8358537: (bf) JavaNioAccess::getBufferAddress bypasses direct
 buffer MemorySession state check [v2]
In-Reply-To: <mbvhon8v-7GzXVSPt72Aju8HlpiTUjH28W3SaJS-1AU=.ce6690c0-b7e6-4b03-a64c-fb50bd35188c@github.com>
References: <xSSwwSM3iKkLS7HuAjbN2xoIJJEvfcqY2HvaAiCro6c=.55924517-36c7-4c10-ba0d-0417fc0353e8@github.com>
 <4V9W09WuhUg4pVOxlpbkHCgrR7VMvZ6sTIwyOXV2R7M=.e1d3c74a-9169-4d09-b40c-cec575a0cbf0@github.com>
 <12xa6f9yGYRuajaK7MYZJasESK0qFyb4Kwng5Kdw-u0=.e17848b4-e392-4e72-9485-b1c16050cde7@github.com>
 <mbvhon8v-7GzXVSPt72Aju8HlpiTUjH28W3SaJS-1AU=.ce6690c0-b7e6-4b03-a64c-fb50bd35188c@github.com>
Message-ID: <3ft2MRJ6baCJ156ZeTOonCurdGujAOQtDaONAJBSBqk=.72317ec9-cb8e-4101-ad81-fbdf68a1b3e7@github.com>

On Wed, 4 Jun 2025 18:10:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Perhaps some comments need to be added in strategic places to clarify the situation to avoid similar confusion in the future?

It would be all right to repurpose this PR and its issue simply to add such comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/25631#issuecomment-2941716999

From bpb at openjdk.org  Wed Jun  4 22:18:03 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Jun 2025 22:18:03 GMT
Subject: RFR: 8357847: (ch) WindowsAsynchronousFileChannelImpl should
 support FFM Buffers [v3]
In-Reply-To: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
References: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
Message-ID: <HDkpFi9xMF7lv_hMCXFTKg2hjuLQChGfZczQXlvPXFo=.0df98027-2eb3-4f84-bb70-134f0f751546@github.com>

> Acquire the scope of a direct buffer before it is used and release it after the task has finished with it, whether the task execution is immediate or pended.

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

  8357912: Add similar changes to SimpleAsynchronousFileChannelImpl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25531/files
  - new: https://git.openjdk.org/jdk/pull/25531/files/82fb9e0b..9d8ed193

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

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

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

From bpb at openjdk.org  Wed Jun  4 22:22:50 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Jun 2025 22:22:50 GMT
Subject: RFR: 8357847: (ch) WindowsAsynchronousFileChannelImpl should
 support FFM Buffers [v3]
In-Reply-To: <HDkpFi9xMF7lv_hMCXFTKg2hjuLQChGfZczQXlvPXFo=.0df98027-2eb3-4f84-bb70-134f0f751546@github.com>
References: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
 <HDkpFi9xMF7lv_hMCXFTKg2hjuLQChGfZczQXlvPXFo=.0df98027-2eb3-4f84-bb70-134f0f751546@github.com>
Message-ID: <-QSA0zeCinMPLzcvSUwQuO_fYURiatFzn0ipRWffPEk=.7737c610-7fb2-41cf-acca-5cdce1bd2287@github.com>

On Wed, 4 Jun 2025 22:18:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Acquire the scope of a direct buffer before it is used and release it after the task has finished with it, whether the task execution is immediate or pended.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357912: Add similar changes to SimpleAsynchronousFileChannelImpl

Before the change in https://github.com/openjdk/jdk/pull/25531/commits/9d8ed1933340ca01455ba41603386da7dbd964f2, the test `java/nio/channels/AsynchronousFileChannel/Basic.java` failed on Unix for both confined and shared `Arena`s.

The `((DirectBuffer)dst).address()` calls added here are to check the session and its state, and the returned value is ignored. It might be better if something like `void DirectBuffer::checkSession` were available, identical to `DirectBuffer::address` but without returning the address.

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

PR Comment: https://git.openjdk.org/jdk/pull/25531#issuecomment-2941748675

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 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 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 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 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 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 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 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 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 alanb at openjdk.org  Thu Jun  5 10:09:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 10:09:52 GMT
Subject: RFR: 8358537: (bf) JavaNioAccess::getBufferAddress bypasses direct
 buffer MemorySession state check [v2]
In-Reply-To: <3ft2MRJ6baCJ156ZeTOonCurdGujAOQtDaONAJBSBqk=.72317ec9-cb8e-4101-ad81-fbdf68a1b3e7@github.com>
References: <xSSwwSM3iKkLS7HuAjbN2xoIJJEvfcqY2HvaAiCro6c=.55924517-36c7-4c10-ba0d-0417fc0353e8@github.com>
 <4V9W09WuhUg4pVOxlpbkHCgrR7VMvZ6sTIwyOXV2R7M=.e1d3c74a-9169-4d09-b40c-cec575a0cbf0@github.com>
 <12xa6f9yGYRuajaK7MYZJasESK0qFyb4Kwng5Kdw-u0=.e17848b4-e392-4e72-9485-b1c16050cde7@github.com>
 <mbvhon8v-7GzXVSPt72Aju8HlpiTUjH28W3SaJS-1AU=.ce6690c0-b7e6-4b03-a64c-fb50bd35188c@github.com>
 <3ft2MRJ6baCJ156ZeTOonCurdGujAOQtDaONAJBSBqk=.72317ec9-cb8e-4101-ad81-fbdf68a1b3e7@github.com>
Message-ID: <_fQI_Qr6x14tNWwgJ67jPK6DM8YgM50Kf08QBEsqu0A=.c301b9d7-7893-4e76-b926-1a8ea25216cf@github.com>

On Wed, 4 Jun 2025 22:10:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Perhaps some comments need to be added in strategic places to clarify the situation to avoid similar confusion in the future? 

I think we should start by reviewing the test coverage. The channels/etc/MemorySegments.java test that we added will exercise all the methods on the synchronous channels that take a ByteBuffer as a parameter. We need to check what tests we have for AsynchronousSocketChannel and AsynchronousFileChannel to ensure that we are testing them with buffers that are views of memory segments allocated from an auto or the global arena. We need good tests before changing anything.

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

PR Comment: https://git.openjdk.org/jdk/pull/25631#issuecomment-2943562745

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 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 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 bpb at openjdk.org  Thu Jun  5 15:18:52 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 5 Jun 2025 15:18:52 GMT
Subject: RFR: 8358537: (bf) JavaNioAccess::getBufferAddress bypasses direct
 buffer MemorySession state check [v2]
In-Reply-To: <4V9W09WuhUg4pVOxlpbkHCgrR7VMvZ6sTIwyOXV2R7M=.e1d3c74a-9169-4d09-b40c-cec575a0cbf0@github.com>
References: <xSSwwSM3iKkLS7HuAjbN2xoIJJEvfcqY2HvaAiCro6c=.55924517-36c7-4c10-ba0d-0417fc0353e8@github.com>
 <4V9W09WuhUg4pVOxlpbkHCgrR7VMvZ6sTIwyOXV2R7M=.e1d3c74a-9169-4d09-b40c-cec575a0cbf0@github.com>
Message-ID: <dlDJf8yWm-Rw63kl4JJeULMe4y0H0u6E7qiglUHP-I0=.84c8f15f-6ab8-44db-b552-f6911bf88682@github.com>

On Wed, 4 Jun 2025 14:29:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add package-scope `long java.nio.Buffer::address()` to simply return the value of the `address` instance variable; use this method in `JavaNioAccess::getBufferAddress`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8358537: Revert MemorySegments test change

The test in #25531 covers `AsynchronousFileChannel`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25631#issuecomment-2944952257

From bpb at openjdk.org  Thu Jun  5 17:48:48 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 5 Jun 2025 17:48:48 GMT
Subject: RFR: 8357847: (ch) WindowsAsynchronousFileChannelImpl should
 support FFM Buffers [v4]
In-Reply-To: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
References: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
Message-ID: <2K2kkBqqk9r1dL8QBt71UR_VakOlGfahV6PZoaBlJzU=.8aa96baf-1ad1-4af4-a8cf-282dd425f403@github.com>

> Acquire the scope of a direct buffer before it is used and release it after the task has finished with it, whether the task execution is immediate or pended.

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

  8357912: Add reading to test of unsupported views

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25531/files
  - new: https://git.openjdk.org/jdk/pull/25531/files/9d8ed193..906057a3

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

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

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

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 shade at openjdk.org  Fri Jun  6 15:13:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 6 Jun 2025 15:13:56 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v8]
In-Reply-To: <OCVWFXwttmUkRp-AJmmuFT69Ar2pBBs-Fkc_0EgAqrI=.43530e88-a679-450d-a3be-e4529002483b@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <OCVWFXwttmUkRp-AJmmuFT69Ar2pBBs-Fkc_0EgAqrI=.43530e88-a679-450d-a3be-e4529002483b@github.com>
Message-ID: <Vxkn-VHZUMAK6H6Z5fWWCoo8-qiTXtQbfwPwLfThPEM=.fc9741d5-82b5-4aef-aebf-031705035496@github.com>

On Tue, 3 Jun 2025 10:32:13 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

>> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
>> 
>> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>>  
>> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
>> 
>> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
>> 
>> **before**
>> 
>> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
>> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
>> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
>> [1
>> 
>> **after**
>> 
>> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
>> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
>> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
>> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
>> 
>> 
>> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
>> 
>> **Before**
>> 
>> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
>> B...
>
> Rohitash Kumar has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - rename param from size to count
>  - Apply patch for test extension

Right, makes sense. I think we are now early in a JDK 26 release.

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

PR Comment: https://git.openjdk.org/jdk/pull/25487#issuecomment-2949565632

From alanb at openjdk.org  Mon Jun  9 12:34:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Jun 2025 12:34:54 GMT
Subject: RFR: 8357847: (ch) AsynchronousFileChannel implementations should
 support FFM Buffers [v4]
In-Reply-To: <2K2kkBqqk9r1dL8QBt71UR_VakOlGfahV6PZoaBlJzU=.8aa96baf-1ad1-4af4-a8cf-282dd425f403@github.com>
References: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
 <2K2kkBqqk9r1dL8QBt71UR_VakOlGfahV6PZoaBlJzU=.8aa96baf-1ad1-4af4-a8cf-282dd425f403@github.com>
Message-ID: <ZnCQnkrxBqYqHEP0YEV0x-pHVCBhRPyc0lEF8u_RoQY=.c7b78f45-43f6-4454-acc1-d5b88fad5434@github.com>

On Thu, 5 Jun 2025 17:48:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Acquire the scope of a direct buffer before it is used and release it after the task has finished with it, whether the task execution is immediate or pended.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357912: Add reading to test of unsupported views

src/java.base/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java line 393:

> 391:         if (src.isDirect()) {
> 392:             IOUtil.acquireScope(src, true);
> 393:             ((DirectBuffer)src).address();

Is the using of address() here for testing purposes?

test/jdk/java/nio/channels/AsynchronousFileChannel/Basic.java line 632:

> 630:         rand.nextBytes(buf);
> 631:         Arena arena = isConfined ? Arena.ofConfined() : Arena.ofShared();
> 632:         return arena.allocate(buf.length).asByteBuffer().put(buf).flip();

For the asynchronous channels then we should only prohibit thread-confined, using a buffer that is a view of a memory segment allocated from a shared arena is okay.  I've included (disabled-for-now) test in draft changes for JDK-8358958 to test attempting to close a shared arena while a write op is outstanding, I think we can use that to test the changes here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25531#discussion_r2135636952
PR Review Comment: https://git.openjdk.org/jdk/pull/25531#discussion_r2135634762

From bpb at openjdk.org  Mon Jun  9 16:04:02 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Jun 2025 16:04:02 GMT
Subject: RFR: 8357847: (ch) AsynchronousFileChannel implementations should
 support FFM Buffers [v4]
In-Reply-To: <ZnCQnkrxBqYqHEP0YEV0x-pHVCBhRPyc0lEF8u_RoQY=.c7b78f45-43f6-4454-acc1-d5b88fad5434@github.com>
References: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
 <2K2kkBqqk9r1dL8QBt71UR_VakOlGfahV6PZoaBlJzU=.8aa96baf-1ad1-4af4-a8cf-282dd425f403@github.com>
 <ZnCQnkrxBqYqHEP0YEV0x-pHVCBhRPyc0lEF8u_RoQY=.c7b78f45-43f6-4454-acc1-d5b88fad5434@github.com>
Message-ID: <MQn6P0SRjs0JrMmzdtWPOuRQ68crmIPogAoQ7bbRlDM=.1f1efba1-e047-41ac-9cc2-18e3451937f9@github.com>

On Mon, 9 Jun 2025 12:32:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Is the using of address() here for testing purposes?

It was to check the state of the session / scope.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25531#discussion_r2135999019

From alanb at openjdk.org  Mon Jun  9 19:12:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Jun 2025 19:12:34 GMT
Subject: RFR: 8357847: (ch) AsynchronousFileChannel implementations should
 support FFM Buffers [v4]
In-Reply-To: <MQn6P0SRjs0JrMmzdtWPOuRQ68crmIPogAoQ7bbRlDM=.1f1efba1-e047-41ac-9cc2-18e3451937f9@github.com>
References: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
 <2K2kkBqqk9r1dL8QBt71UR_VakOlGfahV6PZoaBlJzU=.8aa96baf-1ad1-4af4-a8cf-282dd425f403@github.com>
 <ZnCQnkrxBqYqHEP0YEV0x-pHVCBhRPyc0lEF8u_RoQY=.c7b78f45-43f6-4454-acc1-d5b88fad5434@github.com>
 <MQn6P0SRjs0JrMmzdtWPOuRQ68crmIPogAoQ7bbRlDM=.1f1efba1-e047-41ac-9cc2-18e3451937f9@github.com>
Message-ID: <Cc-ZZ_vlIOM7i2JdsessHJKcElHtVoR3xuUj1QoVafg=.ec6bc5d9-0b91-452c-93ba-641c99741b11@github.com>

On Mon, 9 Jun 2025 16:01:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java line 393:
>> 
>>> 391:         if (src.isDirect()) {
>>> 392:             IOUtil.acquireScope(src, true);
>>> 393:             ((DirectBuffer)src).address();
>> 
>> Is the using of address() here for testing purposes?
>
>> Is the using of address() here for testing purposes?
> 
> It was to check the state of the session / scope.

That will fail when allocated from a shared arena, so not the expected behavior. Maybe we should try to get JDK-8358958 done first as it has tests that we can enable to exercise all the scenarios.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25531#discussion_r2136316146

From bpb at openjdk.org  Mon Jun  9 19:22:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Jun 2025 19:22:38 GMT
Subject: RFR: 8357847: (ch) AsynchronousFileChannel implementations should
 support FFM Buffers [v4]
In-Reply-To: <Cc-ZZ_vlIOM7i2JdsessHJKcElHtVoR3xuUj1QoVafg=.ec6bc5d9-0b91-452c-93ba-641c99741b11@github.com>
References: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
 <2K2kkBqqk9r1dL8QBt71UR_VakOlGfahV6PZoaBlJzU=.8aa96baf-1ad1-4af4-a8cf-282dd425f403@github.com>
 <ZnCQnkrxBqYqHEP0YEV0x-pHVCBhRPyc0lEF8u_RoQY=.c7b78f45-43f6-4454-acc1-d5b88fad5434@github.com>
 <MQn6P0SRjs0JrMmzdtWPOuRQ68crmIPogAoQ7bbRlDM=.1f1efba1-e047-41ac-9cc2-18e3451937f9@github.com>
 <Cc-ZZ_vlIOM7i2JdsessHJKcElHtVoR3xuUj1QoVafg=.ec6bc5d9-0b91-452c-93ba-641c99741b11@github.com>
Message-ID: <4dxKSKnKHJS8bAClX8gZMWK1qP5fR7Y7vmAOUyTg-m0=.581e2446-c5be-4e0c-95a3-2457fdaa75d9@github.com>

On Mon, 9 Jun 2025 19:09:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Maybe we should try to get JDK-8358958 done first

I agree.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25531#discussion_r2136336871

From alanb at openjdk.org  Tue Jun 10 07:06:29 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Jun 2025 07:06:29 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v8]
In-Reply-To: <Vxkn-VHZUMAK6H6Z5fWWCoo8-qiTXtQbfwPwLfThPEM=.fc9741d5-82b5-4aef-aebf-031705035496@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <OCVWFXwttmUkRp-AJmmuFT69Ar2pBBs-Fkc_0EgAqrI=.43530e88-a679-450d-a3be-e4529002483b@github.com>
 <Vxkn-VHZUMAK6H6Z5fWWCoo8-qiTXtQbfwPwLfThPEM=.fc9741d5-82b5-4aef-aebf-031705035496@github.com>
Message-ID: <stp9ArF-F-JXBnh4gdYknCVgt9eH5BGAWWVDQFft9X8=.f6e4ffe7-0c18-4a04-9e04-a77b74f590cc@github.com>

On Fri, 6 Jun 2025 15:10:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Right, makes sense. I think we are now early in a JDK 26 release.

Indeed, I'll do another pass on this today.

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

PR Comment: https://git.openjdk.org/jdk/pull/25487#issuecomment-2957913554

From alanb at openjdk.org  Tue Jun 10 07:48:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Jun 2025 07:48:54 GMT
Subject: RFR: 8358958: (aio) AsynchronousByteChannel.read/write should throw
 IAE if buffer is thread-confined
Message-ID: <oBLENz5Rz7APHyKcvEioLetpi_6kRIC43LyxjcVoCSc=.fb9da1be-e200-4ee5-a94c-f15da0cefb91@github.com>

It's nonsensical to invoke read/write methods defined by the AsynchronousXXX channels with buffers that are views of memory segments allocated from a thread-confined arena.

For AsynchronousSocketChannel, the current behavior is for the read/write methods to initiate an I/O operation that completes with an IOException and an IllegalStateException as cause. For AsynchronousFileChannel, the current behavior is for the read/write methods to initiate an I/O operation that never completes (a thread in the channel groups terminates with a WrongThreadException).

The proposal is that the read/write methods reject, with IllegalArgumentException, any attempt to initiate as async I/O operation with a buffer from a thread-confined arena. IAE is already declared to be thrown for read-only buffers or attempting a positional read/write with a negative file position.

The java/nio/channels/etc/MemorySegments.java test is updated to test AsynchronousSocketChannel and AsynchronousFileChannel with buffers from all arena kinds. The tests include attempts to close a shared arena while an I/O operation is in progress. For now, the testAsyncFileChannelXXX tests are disabled until they meet up with the changes in JDK-8357847 (pr/25531).

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

Commit messages:
 - Merge branch 'master' into JDK-8358958
 - Drop links to problematic operations from asByteBuffer method description
 - Disable testAsyncFileChannelReadWrite on Windows for now
 - Add test for async close of arena
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/25691/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25691&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358958
  Stats: 434 lines in 8 files changed: 409 ins; 3 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/25691.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25691/head:pull/25691

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

From alanb at openjdk.org  Tue Jun 10 11:01:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Jun 2025 11:01:55 GMT
Subject: RFR: 8358958: (aio) AsynchronousByteChannel.read/write should
 throw IAE if buffer is thread-confined [v2]
In-Reply-To: <oBLENz5Rz7APHyKcvEioLetpi_6kRIC43LyxjcVoCSc=.fb9da1be-e200-4ee5-a94c-f15da0cefb91@github.com>
References: <oBLENz5Rz7APHyKcvEioLetpi_6kRIC43LyxjcVoCSc=.fb9da1be-e200-4ee5-a94c-f15da0cefb91@github.com>
Message-ID: <OUnCBV-3SCIsEB4xX19sHPK7N4P7EIRp8Yo6FQy83mY=.b2d89662-87db-4d77-a67b-9d701591765e@github.com>

> It's nonsensical to invoke read/write methods defined by the AsynchronousXXX channels with buffers that are views of memory segments allocated from a thread-confined arena.
> 
> For AsynchronousSocketChannel, the current behavior is for the read/write methods to initiate an I/O operation that completes with an IOException and an IllegalStateException as cause. For AsynchronousFileChannel, the current behavior is for the read/write methods to initiate an I/O operation that never completes (a thread in the channel groups terminates with a WrongThreadException).
> 
> The proposal is that the read/write methods reject, with IllegalArgumentException, any attempt to initiate as async I/O operation with a buffer from a thread-confined arena. IAE is already declared to be thrown for read-only buffers or attempting a positional read/write with a negative file position.
> 
> The java/nio/channels/etc/MemorySegments.java test is updated to test AsynchronousSocketChannel and AsynchronousFileChannel with buffers from all arena kinds. The tests include attempts to close a shared arena while an I/O operation is in progress. For now, the testAsyncFileChannelXXX tests are disabled until they meet up with the changes in JDK-8357847 (pr/25531).

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Missing update to TestAsyncSocketChannels

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25691/files
  - new: https://git.openjdk.org/jdk/pull/25691/files/d7734f91..4a66c604

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

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

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

From alanb at openjdk.org  Tue Jun 10 13:38:41 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Jun 2025 13:38:41 GMT
Subject: RFR: 8358764: (sc) SocketChannel.close when thread blocked in read
 causes connection to be reset (win)
Message-ID: <2JaiaJEJeeH1tfyvK_q8liQeOmuKDUBqNjKSQCoD5ls=.6c078e51-2710-498a-83c6-f0e925e97827@github.com>

On Windows, if a platform thread is blocked in SocketChannel.read, and another thread closes the channel, then Windows abruptly closes the connection (RST).  In releases prior to JDK 11,  the connection was shutdown for writing before closing so the connection was closed gracefully, an unexpected behavior change

implCloseBlockingMode is changed to shutdown the connection for writing on Windows, no change in behavior for other platforms.

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

Commit messages:
 - Improve comments
 - Merge branch 'master' into JDK-8358764
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/25700/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25700&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358764
  Stats: 244 lines in 5 files changed: 227 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25700/head:pull/25700

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

From jpai at openjdk.org  Tue Jun 10 13:56:30 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Jun 2025 13:56:30 GMT
Subject: RFR: 8358764: (sc) SocketChannel.close when thread blocked in read
 causes connection to be reset (win)
In-Reply-To: <2JaiaJEJeeH1tfyvK_q8liQeOmuKDUBqNjKSQCoD5ls=.6c078e51-2710-498a-83c6-f0e925e97827@github.com>
References: <2JaiaJEJeeH1tfyvK_q8liQeOmuKDUBqNjKSQCoD5ls=.6c078e51-2710-498a-83c6-f0e925e97827@github.com>
Message-ID: <BEd3rWFlNOV3jlAfdBEMUJ1UTseLAyGwhKrGNEvQdm8=.bd715b6b-0de3-41cd-a016-619a1c0fa497@github.com>

On Mon, 9 Jun 2025 19:17:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> On Windows, if a platform thread is blocked in SocketChannel.read, and another thread closes the channel, then Windows abruptly closes the connection (RST).  In releases prior to JDK 11,  the connection was shutdown for writing before closing so the connection was closed gracefully, an unexpected behavior change
> 
> implCloseBlockingMode is changed to shutdown the connection for writing on Windows, no change in behavior for other platforms.

src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 1125:

> 1123:             state = ST_CLOSING;
> 1124: 
> 1125:             if (connected && Net.shouldShutdownWriteBeforeClose()) {

Hello Alan, I just had a brief passing look at these changes and based on my limited knowledge of this area, they look reasonable to me. I'll take a more detailed look tomorrow. Is the use of a JNI function, to determine whether or not we should shutdown before close, done for the sake of consistency with the rest of the platform specific logic?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25700#discussion_r2137971071

From alanb at openjdk.org  Tue Jun 10 14:17:32 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Jun 2025 14:17:32 GMT
Subject: RFR: 8358764: (sc) SocketChannel.close when thread blocked in read
 causes connection to be reset (win)
In-Reply-To: <BEd3rWFlNOV3jlAfdBEMUJ1UTseLAyGwhKrGNEvQdm8=.bd715b6b-0de3-41cd-a016-619a1c0fa497@github.com>
References: <2JaiaJEJeeH1tfyvK_q8liQeOmuKDUBqNjKSQCoD5ls=.6c078e51-2710-498a-83c6-f0e925e97827@github.com>
 <BEd3rWFlNOV3jlAfdBEMUJ1UTseLAyGwhKrGNEvQdm8=.bd715b6b-0de3-41cd-a016-619a1c0fa497@github.com>
Message-ID: <0-wOmaTfHexWvpdxECZ90yyLM8j-NNz-ZRLroLU8GyQ=.952377cf-d84c-424c-a8bf-8bbc5bd0079e@github.com>

On Tue, 10 Jun 2025 13:53:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> On Windows, if a platform thread is blocked in SocketChannel.read, and another thread closes the channel, then Windows abruptly closes the connection (RST).  In releases prior to JDK 11,  the connection was shutdown for writing before closing so the connection was closed gracefully, an unexpected behavior change
>> 
>> implCloseBlockingMode is changed to shutdown the connection for writing on Windows, no change in behavior for other platforms.
>
> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 1125:
> 
>> 1123:             state = ST_CLOSING;
>> 1124: 
>> 1125:             if (connected && Net.shouldShutdownWriteBeforeClose()) {
> 
> Hello Alan, I just had a brief passing look at these changes and based on my limited knowledge of this area, they look reasonable to me. I'll take a more detailed look tomorrow. Is the use of a JNI function, to determine whether or not we should shutdown before close, done for the sake of consistency with the rest of the platform specific logic?

The NativeDispatcher and Net APIs are separate, the latter typically has very platform specific code to configure. So it's just keeping to the existing architecture.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25700#discussion_r2138026540

From pminborg at openjdk.org  Tue Jun 10 14:17:59 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Jun 2025 14:17:59 GMT
Subject: RFR: 8359119: There are several opportunities to use Stable Values in
 j.n.c.Charset
Message-ID: <TQ1hWftS-obMd0ocVzaTgkCe7mI6be38FL5OsdZixRI=.82b1b28a-cb1f-4fcc-90cf-0d80bce57b63@github.com>

Fields and methods can better leverage the Stable Value API compared to using DCL and holder classes. There are also some fields that can be marked `@Stable`.

This PR passes tier1, tier2, and tier3 tests on multiple platforms.

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

Commit messages:
 - Add stable value functionality

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

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

From pminborg at openjdk.org  Tue Jun 10 14:17:59 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Jun 2025 14:17:59 GMT
Subject: RFR: 8359119: There are several opportunities to use Stable Values
 in j.n.c.Charset
In-Reply-To: <TQ1hWftS-obMd0ocVzaTgkCe7mI6be38FL5OsdZixRI=.82b1b28a-cb1f-4fcc-90cf-0d80bce57b63@github.com>
References: <TQ1hWftS-obMd0ocVzaTgkCe7mI6be38FL5OsdZixRI=.82b1b28a-cb1f-4fcc-90cf-0d80bce57b63@github.com>
Message-ID: <otqz39luKlf1ndLrxGzq1aKwwXku3gZpfpitCrhjno0=.3cb6dc32-1460-46d7-8ebb-5b9c20d0898d@github.com>

On Tue, 10 Jun 2025 14:09:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Fields and methods can better leverage the Stable Value API compared to using DCL and holder classes. There are also some fields that can be marked `@Stable`.
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms.

src/java.base/share/classes/java/nio/charset/Charset.java line 353:

> 351:     private static Iterator<CharsetProvider> providers() {
> 352:         return new Iterator<>() {
> 353:                 final ClassLoader cl = ClassLoader.getSystemClassLoader();

Drive by fix. We forgot to declare these fields `final`.

src/java.base/share/classes/java/nio/charset/Charset.java line 377:

> 375:                 }
> 376: 
> 377:                 public void remove() {

`remove()` is specified to throw UOE unless overridden. So, removing this redundant code.

src/java.base/share/classes/java/nio/charset/Charset.java line 683:

> 681:         }
> 682:         this.name = canonicalName;
> 683:         this.aliasSet = Set.of(as);

Creating an unmodifiable set is probably more efficient than storing an array and then lazily creating a set. Better to do a set directly up front.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25727#discussion_r2138022133
PR Review Comment: https://git.openjdk.org/jdk/pull/25727#discussion_r2138016240
PR Review Comment: https://git.openjdk.org/jdk/pull/25727#discussion_r2138020354

From jpai at openjdk.org  Tue Jun 10 14:23:30 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Jun 2025 14:23:30 GMT
Subject: RFR: 8358764: (sc) SocketChannel.close when thread blocked in read
 causes connection to be reset (win)
In-Reply-To: <0-wOmaTfHexWvpdxECZ90yyLM8j-NNz-ZRLroLU8GyQ=.952377cf-d84c-424c-a8bf-8bbc5bd0079e@github.com>
References: <2JaiaJEJeeH1tfyvK_q8liQeOmuKDUBqNjKSQCoD5ls=.6c078e51-2710-498a-83c6-f0e925e97827@github.com>
 <BEd3rWFlNOV3jlAfdBEMUJ1UTseLAyGwhKrGNEvQdm8=.bd715b6b-0de3-41cd-a016-619a1c0fa497@github.com>
 <0-wOmaTfHexWvpdxECZ90yyLM8j-NNz-ZRLroLU8GyQ=.952377cf-d84c-424c-a8bf-8bbc5bd0079e@github.com>
Message-ID: <GO5UhMv9gotY2WjCeJO8nXDxJIVuhfwcsEPM3_YGG-w=.b77fb104-cbf2-4028-a5e7-7eb2203c21cd@github.com>

On Tue, 10 Jun 2025 14:14:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The NativeDispatcher and Net APIs are separate, the latter typically has very platform specific code to configure.

I was thinking of the `jdk.internal.util.OperatingSystem.isWindows()` instead of the JNI backed function.

> So it's just keeping to the existing architecture.

That answers my question. Thank you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25700#discussion_r2138040879

From alanb at openjdk.org  Tue Jun 10 14:28:29 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Jun 2025 14:28:29 GMT
Subject: RFR: 8359119: Change Charset to use StableValue
In-Reply-To: <otqz39luKlf1ndLrxGzq1aKwwXku3gZpfpitCrhjno0=.3cb6dc32-1460-46d7-8ebb-5b9c20d0898d@github.com>
References: <TQ1hWftS-obMd0ocVzaTgkCe7mI6be38FL5OsdZixRI=.82b1b28a-cb1f-4fcc-90cf-0d80bce57b63@github.com>
 <otqz39luKlf1ndLrxGzq1aKwwXku3gZpfpitCrhjno0=.3cb6dc32-1460-46d7-8ebb-5b9c20d0898d@github.com>
Message-ID: <UbFOML5JsI3tAH7QelHK6DD1rP48jt9_yqKc8FcpzQQ=.def635b1-d6e9-4d67-bdc9-489f804f4f5c@github.com>

On Tue, 10 Jun 2025 14:12:35 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Fields and methods can better leverage the Stable Value API compared to using DCL and holder classes. There are also some fields that can be marked `@Stable`.
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms.
>
> src/java.base/share/classes/java/nio/charset/Charset.java line 353:
> 
>> 351:     private static Iterator<CharsetProvider> providers() {
>> 352:         return new Iterator<>() {
>> 353:                 final ClassLoader cl = ClassLoader.getSystemClassLoader();
> 
> Drive by fix. We forgot to declare these fields `final`.

final isn't actually needed here, I think better to drop this drive-by change from the PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25727#discussion_r2138051345

From alanb at openjdk.org  Tue Jun 10 14:35:30 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Jun 2025 14:35:30 GMT
Subject: RFR: 8359119: Change Charset to use StableValue
In-Reply-To: <otqz39luKlf1ndLrxGzq1aKwwXku3gZpfpitCrhjno0=.3cb6dc32-1460-46d7-8ebb-5b9c20d0898d@github.com>
References: <TQ1hWftS-obMd0ocVzaTgkCe7mI6be38FL5OsdZixRI=.82b1b28a-cb1f-4fcc-90cf-0d80bce57b63@github.com>
 <otqz39luKlf1ndLrxGzq1aKwwXku3gZpfpitCrhjno0=.3cb6dc32-1460-46d7-8ebb-5b9c20d0898d@github.com>
Message-ID: <Dk7_RWXiiduM9APCzdcATNeg8rAoqdOBsoGj7SNW36M=.093a6d7d-d9c6-482d-9d04-14dfada60af9@github.com>

On Tue, 10 Jun 2025 14:11:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Fields and methods can better leverage the Stable Value API compared to using DCL and holder classes. There are also some fields that can be marked `@Stable`.
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms.
>
> src/java.base/share/classes/java/nio/charset/Charset.java line 683:
> 
>> 681:         }
>> 682:         this.name = canonicalName;
>> 683:         this.aliasSet = Set.of(as);
> 
> Creating an unmodifiable set is probably more efficient than storing an array and then lazily creating a set. Better to do a set directly up front.

I think the drive-by changes to this and to aliases, should be dropped, as they are a separate discussion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25727#discussion_r2138066685

From alanb at openjdk.org  Tue Jun 10 14:42:27 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Jun 2025 14:42:27 GMT
Subject: RFR: 8358764: (sc) SocketChannel.close when thread blocked in read
 causes connection to be reset (win)
In-Reply-To: <GO5UhMv9gotY2WjCeJO8nXDxJIVuhfwcsEPM3_YGG-w=.b77fb104-cbf2-4028-a5e7-7eb2203c21cd@github.com>
References: <2JaiaJEJeeH1tfyvK_q8liQeOmuKDUBqNjKSQCoD5ls=.6c078e51-2710-498a-83c6-f0e925e97827@github.com>
 <BEd3rWFlNOV3jlAfdBEMUJ1UTseLAyGwhKrGNEvQdm8=.bd715b6b-0de3-41cd-a016-619a1c0fa497@github.com>
 <0-wOmaTfHexWvpdxECZ90yyLM8j-NNz-ZRLroLU8GyQ=.952377cf-d84c-424c-a8bf-8bbc5bd0079e@github.com>
 <GO5UhMv9gotY2WjCeJO8nXDxJIVuhfwcsEPM3_YGG-w=.b77fb104-cbf2-4028-a5e7-7eb2203c21cd@github.com>
Message-ID: <wqI4l-yyXh6pXbro1kjf8jkoWprHGfif0IP_2Efbkgg=.2994586b-f0e6-43b0-a3ac-1c9659041969@github.com>

On Tue, 10 Jun 2025 14:21:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The NativeDispatcher and Net APIs are separate, the latter typically has very platform specific code to configure. So it's just keeping to the existing architecture.
>
>> The NativeDispatcher and Net APIs are separate, the latter typically has very platform specific code to configure.
> 
> I was thinking of the `jdk.internal.util.OperatingSystem.isWindows()` instead of the JNI backed function.
> 
>> So it's just keeping to the existing architecture.
> 
> That answers my question. Thank you.

This area uses platform specific classes + code to allow for porting purposes. Maybe some day we may be able to refactor Net and/or combine with NativeDispatcher but not here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25700#discussion_r2138080120

From pminborg at openjdk.org  Tue Jun 10 14:53:29 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Jun 2025 14:53:29 GMT
Subject: RFR: 8359119: Change Charset to use StableValue
In-Reply-To: <TQ1hWftS-obMd0ocVzaTgkCe7mI6be38FL5OsdZixRI=.82b1b28a-cb1f-4fcc-90cf-0d80bce57b63@github.com>
References: <TQ1hWftS-obMd0ocVzaTgkCe7mI6be38FL5OsdZixRI=.82b1b28a-cb1f-4fcc-90cf-0d80bce57b63@github.com>
Message-ID: <n-BXX8U18Ssv4zS5jnzfO48fWAcGG7Qs4TD3qZOiX1s=.970e9070-10bd-4c95-92ab-b68da27e8530@github.com>

On Tue, 10 Jun 2025 14:09:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Fields and methods can better leverage the Stable Value API compared to using DCL and holder classes. There are also some fields that can be marked `@Stable`.
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms.

Current startup performance on an M1 macOS using `brr -b perfstartup-noop`.

Base:

Wall clock:       29.5 ms/op
  :.cycles:       100702748 average cycles elapsed
  :.instructions: 196311919 average instructions retired
  :.maxrss:       39100416 bytes maximum resident set size
  :.taskclock:    23.0 ms/op

  
Patch:

Wall clock:       29.0 ms/op
  :.cycles:       101696210 average cycles elapsed
  :.instructions: 196761541 average instructions retired
  :.maxrss:       39067648 bytes maximum resident set size
  :.taskclock:    22.5 ms/op

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

PR Comment: https://git.openjdk.org/jdk/pull/25727#issuecomment-2959567453

From alanb at openjdk.org  Tue Jun 10 15:07:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Jun 2025 15:07:28 GMT
Subject: RFR: 8359119: Change Charset to use StableValue
In-Reply-To: <TQ1hWftS-obMd0ocVzaTgkCe7mI6be38FL5OsdZixRI=.82b1b28a-cb1f-4fcc-90cf-0d80bce57b63@github.com>
References: <TQ1hWftS-obMd0ocVzaTgkCe7mI6be38FL5OsdZixRI=.82b1b28a-cb1f-4fcc-90cf-0d80bce57b63@github.com>
Message-ID: <UmjHhAmdYONuXYwHGOY74XKHZeDKBjtfXF5ESDuSHGY=.d30ac15d-fa60-4880-a4c8-556505493bbf@github.com>

On Tue, 10 Jun 2025 14:09:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Fields and methods can better leverage the Stable Value API compared to using DCL and holder classes. There are also some fields that can be marked `@Stable`.
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms.

src/java.base/share/classes/java/nio/charset/Charset.java line 384:

> 382: 
> 383:     private static final Supplier<ThreadTracker> TRACKER = StableValue.supplier(
> 384:             new Supplier<>() { public ThreadTracker get() { return new ThreadTracker(); }});

ThreadTracker pre-dates ScopedValue. We could potentially use a  ScopedValue<Boolean> IN_USE here, or StableValue<ScopedValue<Boolean>> if there are issues running the class initializer in early VM startup. Separate discussion but we don't need ThreadTracker now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25727#discussion_r2138150754

From pminborg at openjdk.org  Tue Jun 10 15:15:44 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Jun 2025 15:15:44 GMT
Subject: RFR: 8359119: Change Charset to use StableValue [v2]
In-Reply-To: <TQ1hWftS-obMd0ocVzaTgkCe7mI6be38FL5OsdZixRI=.82b1b28a-cb1f-4fcc-90cf-0d80bce57b63@github.com>
References: <TQ1hWftS-obMd0ocVzaTgkCe7mI6be38FL5OsdZixRI=.82b1b28a-cb1f-4fcc-90cf-0d80bce57b63@github.com>
Message-ID: <l5D_p3SX_spsWDcXRAHC4qEBNNB9bkxY_C6Cfrn_SPY=.70b17a15-0390-4ced-b658-3954490660af@github.com>

> Fields and methods can better leverage the Stable Value API compared to using DCL and holder classes. There are also some fields that can be marked `@Stable`.
> 
> This PR passes tier1, tier2, and tier3 tests on multiple platforms.

Per Minborg has updated the pull request incrementally with three additional commits since the last revision:

 - Revert for loop
 - Revert more
 - Revert changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25727/files
  - new: https://git.openjdk.org/jdk/pull/25727/files/57edd190..21a43faa

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

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

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

From pminborg at openjdk.org  Tue Jun 10 15:19:29 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Jun 2025 15:19:29 GMT
Subject: RFR: 8359119: Change Charset to use StableValue [v2]
In-Reply-To: <UmjHhAmdYONuXYwHGOY74XKHZeDKBjtfXF5ESDuSHGY=.d30ac15d-fa60-4880-a4c8-556505493bbf@github.com>
References: <TQ1hWftS-obMd0ocVzaTgkCe7mI6be38FL5OsdZixRI=.82b1b28a-cb1f-4fcc-90cf-0d80bce57b63@github.com>
 <UmjHhAmdYONuXYwHGOY74XKHZeDKBjtfXF5ESDuSHGY=.d30ac15d-fa60-4880-a4c8-556505493bbf@github.com>
Message-ID: <MCduZE958EiKd2K3UpGiF3Rb-CHlCBUJsbuVXRTmadM=.c234fe3f-f9a3-4848-9d62-2a2ac5c66a51@github.com>

On Tue, 10 Jun 2025 15:04:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Revert for loop
>>  - Revert more
>>  - Revert changes
>
> src/java.base/share/classes/java/nio/charset/Charset.java line 384:
> 
>> 382: 
>> 383:     private static final Supplier<ThreadTracker> TRACKER = StableValue.supplier(
>> 384:             new Supplier<>() { public ThreadTracker get() { return new ThreadTracker(); }});
> 
> ThreadTracker pre-dates ScopedValue. We could potentially use a  ScopedValue<Boolean> IN_USE here, or StableValue<ScopedValue<Boolean>> if there are issues running the class initializer in early VM startup. Separate discussion but we don't need ThreadTracker now.

So, revert the changes here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25727#discussion_r2138177730

From alanb at openjdk.org  Tue Jun 10 15:25:29 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Jun 2025 15:25:29 GMT
Subject: RFR: 8359119: Change Charset to use StableValue [v2]
In-Reply-To: <MCduZE958EiKd2K3UpGiF3Rb-CHlCBUJsbuVXRTmadM=.c234fe3f-f9a3-4848-9d62-2a2ac5c66a51@github.com>
References: <TQ1hWftS-obMd0ocVzaTgkCe7mI6be38FL5OsdZixRI=.82b1b28a-cb1f-4fcc-90cf-0d80bce57b63@github.com>
 <UmjHhAmdYONuXYwHGOY74XKHZeDKBjtfXF5ESDuSHGY=.d30ac15d-fa60-4880-a4c8-556505493bbf@github.com>
 <MCduZE958EiKd2K3UpGiF3Rb-CHlCBUJsbuVXRTmadM=.c234fe3f-f9a3-4848-9d62-2a2ac5c66a51@github.com>
Message-ID: <qllpKbtzUIJ-dJPNiGZSBEvLSypkWga2vh2a8VKhNJI=.41f015a0-0a64-4c00-99cd-d2b2fc0544c5@github.com>

On Tue, 10 Jun 2025 15:16:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/charset/Charset.java line 384:
>> 
>>> 382: 
>>> 383:     private static final Supplier<ThreadTracker> TRACKER = StableValue.supplier(
>>> 384:             new Supplier<>() { public ThreadTracker get() { return new ThreadTracker(); }});
>> 
>> ThreadTracker pre-dates ScopedValue. We could potentially use a  ScopedValue<Boolean> IN_USE here, or StableValue<ScopedValue<Boolean>> if there are issues running the class initializer in early VM startup. Separate discussion but we don't need ThreadTracker now.
>
> So, revert the changes here?

I think it's okay, it's just that the change is a reminder that all ThreadTracker usages can be replaced with a ScopedValue<Boolean> but may require a bit of work to allow using during early VM startup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25727#discussion_r2138196314

From alanb at openjdk.org  Tue Jun 10 15:49:36 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Jun 2025 15:49:36 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v8]
In-Reply-To: <OCVWFXwttmUkRp-AJmmuFT69Ar2pBBs-Fkc_0EgAqrI=.43530e88-a679-450d-a3be-e4529002483b@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <OCVWFXwttmUkRp-AJmmuFT69Ar2pBBs-Fkc_0EgAqrI=.43530e88-a679-450d-a3be-e4529002483b@github.com>
Message-ID: <xzqxEh4ldxhh0sVjqaObsEY1bSg0hU0Z1aRaojqgEKw=.69aeb85e-f971-43d4-b2f5-e5304a5e344d@github.com>

On Tue, 3 Jun 2025 10:32:13 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

>> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
>> 
>> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>>  
>> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
>> 
>> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
>> 
>> **before**
>> 
>> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
>> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
>> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
>> [1
>> 
>> **after**
>> 
>> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
>> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
>> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
>> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
>> 
>> 
>> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
>> 
>> **Before**
>> 
>> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
>> B...
>
> Rohitash Kumar has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - rename param from size to count
>  - Apply patch for test extension

test/jdk/java/nio/Buffer/AllocateDirectInit.java line 70:

> 68: 
> 69:     private static void check(ByteBuffer bb) {
> 70:         for (bb.position(0); bb.position() < bb.limit(); ) {

I think it would be more readable to use `while (bb.hasRemaining()) {` here.

Also can you update the end date in the copyright header.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25487#discussion_r2138252456

From duke at openjdk.org  Tue Jun 10 16:27:52 2025
From: duke at openjdk.org (Rohitash Kumar)
Date: Tue, 10 Jun 2025 16:27:52 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v8]
In-Reply-To: <xzqxEh4ldxhh0sVjqaObsEY1bSg0hU0Z1aRaojqgEKw=.69aeb85e-f971-43d4-b2f5-e5304a5e344d@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <OCVWFXwttmUkRp-AJmmuFT69Ar2pBBs-Fkc_0EgAqrI=.43530e88-a679-450d-a3be-e4529002483b@github.com>
 <xzqxEh4ldxhh0sVjqaObsEY1bSg0hU0Z1aRaojqgEKw=.69aeb85e-f971-43d4-b2f5-e5304a5e344d@github.com>
Message-ID: <JMyZWv3MFIQ_P73f__kyIdsuF7cEfQ0uoyV4Rqp2hLE=.451d096d-5dab-4ceb-9f81-9fb5042007ea@github.com>

On Tue, 10 Jun 2025 15:47:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Rohitash Kumar has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - rename param from size to count
>>  - Apply patch for test extension
>
> test/jdk/java/nio/Buffer/AllocateDirectInit.java line 70:
> 
>> 68: 
>> 69:     private static void check(ByteBuffer bb) {
>> 70:         for (bb.position(0); bb.position() < bb.limit(); ) {
> 
> I think it would be more readable to use `while (bb.hasRemaining()) {` here.
> 
> Also can you update the end date in the copyright header.

Done ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25487#discussion_r2138324258

From duke at openjdk.org  Tue Jun 10 16:27:52 2025
From: duke at openjdk.org (Rohitash Kumar)
Date: Tue, 10 Jun 2025 16:27:52 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v9]
In-Reply-To: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
Message-ID: <46QgTbFuJlEoKvVLhEG4Emh0dWJ2Gj1Fhce8jZ8qon4=.6bd1a283-22a7-43c2-80d6-83fa4d9e90d9@github.com>

> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
> 
> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>  
> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
> 
> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
> 
> **before**
> 
> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
> [1
> 
> **after**
> 
> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
> 
> 
> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
> 
> **Before**
> 
> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
> ByteBufferAllocationBenchmark.allocateDirectBuffer         1...

Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Change for to while loop and update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25487/files
  - new: https://git.openjdk.org/jdk/pull/25487/files/2abf1423..2867d495

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

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

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

From bpb at openjdk.org  Tue Jun 10 19:13:31 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 10 Jun 2025 19:13:31 GMT
Subject: RFR: 8358958: (aio) AsynchronousByteChannel.read/write should
 throw IAE if buffer is thread-confined [v2]
In-Reply-To: <OUnCBV-3SCIsEB4xX19sHPK7N4P7EIRp8Yo6FQy83mY=.b2d89662-87db-4d77-a67b-9d701591765e@github.com>
References: <oBLENz5Rz7APHyKcvEioLetpi_6kRIC43LyxjcVoCSc=.fb9da1be-e200-4ee5-a94c-f15da0cefb91@github.com>
 <OUnCBV-3SCIsEB4xX19sHPK7N4P7EIRp8Yo6FQy83mY=.b2d89662-87db-4d77-a67b-9d701591765e@github.com>
Message-ID: <RFd7F82N3OEVHleNl6GJGjIWagNUBUEgeJuUkybxbHw=.dc350837-aaa8-4bb5-bd61-f521310f41d3@github.com>

On Tue, 10 Jun 2025 11:01:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It's nonsensical to invoke read/write methods defined by the AsynchronousXXX channels with buffers that are views of memory segments allocated from a thread-confined arena.
>> 
>> For AsynchronousSocketChannel, the current behavior is for the read/write methods to initiate an I/O operation that completes with an IOException and an IllegalStateException as cause. For AsynchronousFileChannel, the current behavior is for the read/write methods to initiate an I/O operation that never completes (a thread in the channel groups terminates with a WrongThreadException).
>> 
>> The proposal is that the read/write methods reject, with IllegalArgumentException, any attempt to initiate as async I/O operation with a buffer from a thread-confined arena. IAE is already declared to be thrown for read-only buffers or attempting a positional read/write with a negative file position.
>> 
>> The java/nio/channels/etc/MemorySegments.java test is updated to test AsynchronousSocketChannel and AsynchronousFileChannel with buffers from all arena kinds. The tests include attempts to close a shared arena while an I/O operation is in progress. For now, the testAsyncFileChannelXXX tests are disabled until they meet up with the changes in JDK-8357847 (pr/25531).
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing update to TestAsyncSocketChannels

Implementation changes look fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/25691#issuecomment-2960330658

From alanb at openjdk.org  Tue Jun 10 19:31:29 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Jun 2025 19:31:29 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v9]
In-Reply-To: <46QgTbFuJlEoKvVLhEG4Emh0dWJ2Gj1Fhce8jZ8qon4=.6bd1a283-22a7-43c2-80d6-83fa4d9e90d9@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <46QgTbFuJlEoKvVLhEG4Emh0dWJ2Gj1Fhce8jZ8qon4=.6bd1a283-22a7-43c2-80d6-83fa4d9e90d9@github.com>
Message-ID: <WSqG0rxvbm8ytvRFfD_mUjkJRgP0miZs2nMcVS0fpo4=.206a378d-de33-467c-87c5-231f7bff5ed8@github.com>

On Tue, 10 Jun 2025 16:27:52 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

>> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
>> 
>> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>>  
>> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
>> 
>> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
>> 
>> **before**
>> 
>> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
>> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
>> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
>> [1
>> 
>> **after**
>> 
>> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
>> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
>> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
>> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
>> 
>> 
>> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
>> 
>> **Before**
>> 
>> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
>> B...
>
> Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change for to while loop and update copyright year

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25487#pullrequestreview-2914822314

From bpb at openjdk.org  Tue Jun 10 22:40:27 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 10 Jun 2025 22:40:27 GMT
Subject: RFR: 8358958: (aio) AsynchronousByteChannel.read/write should
 throw IAE if buffer is thread-confined [v2]
In-Reply-To: <OUnCBV-3SCIsEB4xX19sHPK7N4P7EIRp8Yo6FQy83mY=.b2d89662-87db-4d77-a67b-9d701591765e@github.com>
References: <oBLENz5Rz7APHyKcvEioLetpi_6kRIC43LyxjcVoCSc=.fb9da1be-e200-4ee5-a94c-f15da0cefb91@github.com>
 <OUnCBV-3SCIsEB4xX19sHPK7N4P7EIRp8Yo6FQy83mY=.b2d89662-87db-4d77-a67b-9d701591765e@github.com>
Message-ID: <V2rR5RtBgUSfpsZRmgCH9YHfXfiuea2aZXu4cAkVNmc=.38e2070b-4918-44f3-a006-7ea59df61d18@github.com>

On Tue, 10 Jun 2025 11:01:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It's nonsensical to invoke read/write methods defined by the AsynchronousXXX channels with buffers that are views of memory segments allocated from a thread-confined arena.
>> 
>> For AsynchronousSocketChannel, the current behavior is for the read/write methods to initiate an I/O operation that completes with an IOException and an IllegalStateException as cause. For AsynchronousFileChannel, the current behavior is for the read/write methods to initiate an I/O operation that never completes (a thread in the channel groups terminates with a WrongThreadException).
>> 
>> The proposal is that the read/write methods reject, with IllegalArgumentException, any attempt to initiate as async I/O operation with a buffer from a thread-confined arena. IAE is already declared to be thrown for read-only buffers or attempting a positional read/write with a negative file position.
>> 
>> The java/nio/channels/etc/MemorySegments.java test is updated to test AsynchronousSocketChannel and AsynchronousFileChannel with buffers from all arena kinds. The tests include attempts to close a shared arena while an I/O operation is in progress. For now, the testAsyncFileChannelXXX tests are disabled until they meet up with the changes in JDK-8357847 (pr/25531).
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing update to TestAsyncSocketChannels

Looks fine to me.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25691#pullrequestreview-2915190766

From bpb at openjdk.org  Wed Jun 11 00:43:59 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Jun 2025 00:43:59 GMT
Subject: RFR: 8357286: (bf) Remove obsolete instanceof checks in
 CharBuffer.append
Message-ID: <S1_AE1lulvhDJ9RyzSux0jzpERWAIJLuHmWz8O_Z3SU=.f78cdce0-efb9-4b95-8329-7eeb6dfec4e2@github.com>

Remove some instanceof checks which are vestigial now that `CharSequence` itself defines `getChars(int,int,char[],int)`.

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

Commit messages:
 - 8357286: (bf) Remove obsolete instanceof checks in CharBuffer.append

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

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

From jpai at openjdk.org  Wed Jun 11 07:30:29 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 07:30:29 GMT
Subject: RFR: 8358958: (aio) AsynchronousByteChannel.read/write should
 throw IAE if buffer is thread-confined [v2]
In-Reply-To: <OUnCBV-3SCIsEB4xX19sHPK7N4P7EIRp8Yo6FQy83mY=.b2d89662-87db-4d77-a67b-9d701591765e@github.com>
References: <oBLENz5Rz7APHyKcvEioLetpi_6kRIC43LyxjcVoCSc=.fb9da1be-e200-4ee5-a94c-f15da0cefb91@github.com>
 <OUnCBV-3SCIsEB4xX19sHPK7N4P7EIRp8Yo6FQy83mY=.b2d89662-87db-4d77-a67b-9d701591765e@github.com>
Message-ID: <196I9oR6XeEKZMGI5SIoaK_y_FbWM0-lATlUlA8P-AI=.46cad8f7-b72c-4a89-8225-eab3f65f8850@github.com>

On Tue, 10 Jun 2025 11:01:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It's nonsensical to invoke read/write methods defined by the AsynchronousXXX channels with buffers that are views of memory segments allocated from a thread-confined arena.
>> 
>> For AsynchronousSocketChannel, the current behavior is for the read/write methods to initiate an I/O operation that completes with an IOException and an IllegalStateException as cause. For AsynchronousFileChannel, the current behavior is for the read/write methods to initiate an I/O operation that never completes (a thread in the channel groups terminates with a WrongThreadException).
>> 
>> The proposal is that the read/write methods reject, with IllegalArgumentException, any attempt to initiate as async I/O operation with a buffer from a thread-confined arena. IAE is already declared to be thrown for read-only buffers or attempting a positional read/write with a negative file position.
>> 
>> The java/nio/channels/etc/MemorySegments.java test is updated to test AsynchronousSocketChannel and AsynchronousFileChannel with buffers from all arena kinds. The tests include attempts to close a shared arena while an I/O operation is in progress. For now, the testAsyncFileChannelXXX tests are disabled until they meet up with the changes in JDK-8357847 (pr/25531).
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing update to TestAsyncSocketChannels

The changes look OK to me. I glanced through the tests (especially the MemorySegments.java) and they look fine too.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25691#pullrequestreview-2915966730

From jpai at openjdk.org  Wed Jun 11 07:34:30 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 07:34:30 GMT
Subject: RFR: 8358958: (aio) AsynchronousByteChannel.read/write should
 throw IAE if buffer is thread-confined [v2]
In-Reply-To: <OUnCBV-3SCIsEB4xX19sHPK7N4P7EIRp8Yo6FQy83mY=.b2d89662-87db-4d77-a67b-9d701591765e@github.com>
References: <oBLENz5Rz7APHyKcvEioLetpi_6kRIC43LyxjcVoCSc=.fb9da1be-e200-4ee5-a94c-f15da0cefb91@github.com>
 <OUnCBV-3SCIsEB4xX19sHPK7N4P7EIRp8Yo6FQy83mY=.b2d89662-87db-4d77-a67b-9d701591765e@github.com>
Message-ID: <kGyNGKowPlbHZ8gLNYTDHgj3e0atrS5_QBGEKsQqmoE=.9b2cb1eb-7c4e-4dac-939f-fe7723889205@github.com>

On Tue, 10 Jun 2025 11:01:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It's nonsensical to invoke read/write methods defined by the AsynchronousXXX channels with buffers that are views of memory segments allocated from a thread-confined arena.
>> 
>> For AsynchronousSocketChannel, the current behavior is for the read/write methods to initiate an I/O operation that completes with an IOException and an IllegalStateException as cause. For AsynchronousFileChannel, the current behavior is for the read/write methods to initiate an I/O operation that never completes (a thread in the channel groups terminates with a WrongThreadException).
>> 
>> The proposal is that the read/write methods reject, with IllegalArgumentException, any attempt to initiate as async I/O operation with a buffer from a thread-confined arena. IAE is already declared to be thrown for read-only buffers or attempting a positional read/write with a negative file position.
>> 
>> The java/nio/channels/etc/MemorySegments.java test is updated to test AsynchronousSocketChannel and AsynchronousFileChannel with buffers from all arena kinds. The tests include attempts to close a shared arena while an I/O operation is in progress. For now, the testAsyncFileChannelXXX tests are disabled until they meet up with the changes in JDK-8357847 (pr/25531).
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing update to TestAsyncSocketChannels

`AsynchronousFileChannelImpl.java` requires a copyright year update.

test/jdk/java/nio/channels/etc/MemorySegments.java line 663:

> 661:         Arena arena = arenaSupplier.get();
> 662: 
> 663:         Path file = Files.createTempFile(Path.of(""), "foo", ".dat");

Is the use of an empty `Path` instead of `Path.of(".")` intentional here? The documentation of `Path` states:


> Accessing a file using an <i>empty path</i> is equivalent to accessing the default directory of the file system.

Unlike the current working directory, I couldn't find the definition of default directory. Are they the same for the default filesystem?

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

PR Comment: https://git.openjdk.org/jdk/pull/25691#issuecomment-2961556065
PR Review Comment: https://git.openjdk.org/jdk/pull/25691#discussion_r2139417370

From jpai at openjdk.org  Wed Jun 11 07:40:27 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 07:40:27 GMT
Subject: RFR: 8357286: (bf) Remove obsolete instanceof checks in
 CharBuffer.append
In-Reply-To: <S1_AE1lulvhDJ9RyzSux0jzpERWAIJLuHmWz8O_Z3SU=.f78cdce0-efb9-4b95-8329-7eeb6dfec4e2@github.com>
References: <S1_AE1lulvhDJ9RyzSux0jzpERWAIJLuHmWz8O_Z3SU=.f78cdce0-efb9-4b95-8329-7eeb6dfec4e2@github.com>
Message-ID: <nLsLaNl8j_SoiwaDvB__K8p4h3s8MpgscdzUXVxCqdI=.99e668b3-44ae-4ff0-8beb-c6cbda219088@github.com>

On Wed, 11 Jun 2025 00:38:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove some instanceof checks which are vestigial now that `CharSequence` itself defines `getChars(int,int,char[],int)`.

Hello Brian, it looks like the Basic.java test has caught a genuine issue with this change:


java.lang.NullPointerException: Cannot invoke "java.lang.CharSequence.length()" because "csq" is null
	at java.base/java.nio.HeapCharBuffer.append(HeapCharBuffer.java:297)
	at java.base/java.nio.HeapCharBuffer.append(HeapCharBuffer.java:48)
	at Basic.test(Basic.java:340)
	at Basic.main(Basic.java:382)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
	at java.base/java.lang.Thread.run(Thread.java:1474)

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

PR Comment: https://git.openjdk.org/jdk/pull/25739#issuecomment-2961571788

From jpai at openjdk.org  Wed Jun 11 07:53:29 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 07:53:29 GMT
Subject: RFR: 8358764: (sc) SocketChannel.close when thread blocked in read
 causes connection to be reset (win)
In-Reply-To: <2JaiaJEJeeH1tfyvK_q8liQeOmuKDUBqNjKSQCoD5ls=.6c078e51-2710-498a-83c6-f0e925e97827@github.com>
References: <2JaiaJEJeeH1tfyvK_q8liQeOmuKDUBqNjKSQCoD5ls=.6c078e51-2710-498a-83c6-f0e925e97827@github.com>
Message-ID: <PjxipyIt0ZSyeFxLW7TbalsEjUbXpJoiSbOqRWktQIo=.9431a164-0bfc-46f6-9d56-ed177ac0cc14@github.com>

On Mon, 9 Jun 2025 19:17:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> On Windows, if a platform thread is blocked in SocketChannel.read, and another thread closes the channel, then Windows abruptly closes the connection (RST).  In releases prior to JDK 11,  the connection was shutdown for writing before closing so the connection was closed gracefully, an unexpected behavior change
> 
> implCloseBlockingMode is changed to shutdown the connection for writing on Windows, no change in behavior for other platforms.

The changes look good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25700#pullrequestreview-2916038434

From vyazici at openjdk.org  Wed Jun 11 08:12:28 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 08:12:28 GMT
Subject: RFR: 8358764: (sc) SocketChannel.close when thread blocked in read
 causes connection to be reset (win)
In-Reply-To: <2JaiaJEJeeH1tfyvK_q8liQeOmuKDUBqNjKSQCoD5ls=.6c078e51-2710-498a-83c6-f0e925e97827@github.com>
References: <2JaiaJEJeeH1tfyvK_q8liQeOmuKDUBqNjKSQCoD5ls=.6c078e51-2710-498a-83c6-f0e925e97827@github.com>
Message-ID: <MBS_t-yriMZofbVhmLFUqMUzTBdWCmFbEfJ6xju8rS8=.9a7a8936-7ccc-4a94-a456-9cef34632e4e@github.com>

On Mon, 9 Jun 2025 19:17:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> On Windows, if a platform thread is blocked in SocketChannel.read, and another thread closes the channel, then Windows abruptly closes the connection (RST).  In releases prior to JDK 11,  the connection was shutdown for writing before closing so the connection was closed gracefully, an unexpected behavior change
> 
> implCloseBlockingMode is changed to shutdown the connection for writing on Windows, no change in behavior for other platforms.

Verified that

1. Only on Windows, `implCloseNonBlockingMode()` disallows further writes prior to `tryClose()`
2. Tests stress the ill behavior reported

test/jdk/java/nio/channels/SocketChannel/PeerReadsAfterAsyncClose.java line 166:

> 164:      * {@code c} is the fully qualified class name and {@code m} is the method name.
> 165:      */
> 166:     private void onReach(Thread target, String location, Runnable action) {

Very sweet approach! ?

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

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25700#pullrequestreview-2916055853
PR Review Comment: https://git.openjdk.org/jdk/pull/25700#discussion_r2139466425

From shade at openjdk.org  Wed Jun 11 08:37:32 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 11 Jun 2025 08:37:32 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v9]
In-Reply-To: <46QgTbFuJlEoKvVLhEG4Emh0dWJ2Gj1Fhce8jZ8qon4=.6bd1a283-22a7-43c2-80d6-83fa4d9e90d9@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <46QgTbFuJlEoKvVLhEG4Emh0dWJ2Gj1Fhce8jZ8qon4=.6bd1a283-22a7-43c2-80d6-83fa4d9e90d9@github.com>
Message-ID: <mS0_0WbkuKSHqWEPVZU5c1A0GHgwsGHY6YLG_DX1RAQ=.4ae3f6be-e858-4f53-af2a-199434d51f2e@github.com>

On Tue, 10 Jun 2025 16:27:52 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

>> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
>> 
>> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>>  
>> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
>> 
>> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
>> 
>> **before**
>> 
>> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
>> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
>> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
>> [1
>> 
>> **after**
>> 
>> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
>> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
>> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
>> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
>> 
>> 
>> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
>> 
>> **Before**
>> 
>> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
>> B...
>
> Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change for to while loop and update copyright year

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25487#pullrequestreview-2916174265

From alanb at openjdk.org  Wed Jun 11 08:42:30 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Jun 2025 08:42:30 GMT
Subject: RFR: 8357286: (bf) Remove obsolete instanceof checks in
 CharBuffer.append
In-Reply-To: <S1_AE1lulvhDJ9RyzSux0jzpERWAIJLuHmWz8O_Z3SU=.f78cdce0-efb9-4b95-8329-7eeb6dfec4e2@github.com>
References: <S1_AE1lulvhDJ9RyzSux0jzpERWAIJLuHmWz8O_Z3SU=.f78cdce0-efb9-4b95-8329-7eeb6dfec4e2@github.com>
Message-ID: <kc3Pw3fL4w24hU2bhPjhYkSua2rVlyqKBXCxdKspCMU=.2d09195e-f41b-4fe1-989a-6aa39d876e4a@github.com>

On Wed, 11 Jun 2025 00:38:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove some instanceof checks which are vestigial now that `CharSequence` itself defines `getChars(int,int,char[],int)`.

src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template line 297:

> 295:         checkSession();
> 296: 
> 297:         Objects.checkFromToIndex(start, end, csq.length());

The append(CharSequence) methods are specified to append "null" when the CharSequence is null so append(null, 0, 0) will need to be handled here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25739#discussion_r2139553057

From jpai at openjdk.org  Wed Jun 11 10:11:41 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 10:11:41 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte)
Message-ID: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>

Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 

The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:


public void setTTL(byte ttl) throws IOException
public byte getTTL() throws IOException


and this other one on `MulticastSocket`:


public void send(DatagramPacket p, byte ttl) throws IOException 


have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.

The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.

Existing tests in tier1, tier2 and tier3 continue to pass with these changes.

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

Commit messages:
 - 8332623: Remove setTTL()/getTTL() methods from DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket, byte)

Changes: https://git.openjdk.org/jdk/pull/25744/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25744&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332623
  Stats: 442 lines in 19 files changed: 12 ins; 408 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/25744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25744/head:pull/25744

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

From alanb at openjdk.org  Wed Jun 11 10:26:31 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Jun 2025 10:26:31 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte)
In-Reply-To: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
Message-ID: <splwdKURAY698rTNujlB48ksxTaR7BEPjDXuQRBRCGc=.430d0072-8413-4039-afad-2abb2a578b20@github.com>

On Wed, 11 Jun 2025 10:05:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
> 
> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
> 
> 
> public void setTTL(byte ttl) throws IOException
> public byte getTTL() throws IOException
> 
> 
> and this other one on `MulticastSocket`:
> 
> 
> public void send(DatagramPacket p, byte ttl) throws IOException 
> 
> 
> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
> 
> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
> 
> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.

src/java.base/share/classes/sun/nio/ch/DatagramSocketAdaptor.java line 564:

> 562:     @SuppressWarnings("removal")
> 563:     public void send(DatagramPacket p, byte ttl) throws IOException {
> 564:         sendLock.lock();

sendLock can be removed too, it's only need because of this send method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25744#discussion_r2139773421

From alanb at openjdk.org  Wed Jun 11 10:30:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Jun 2025 10:30:34 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte)
In-Reply-To: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
Message-ID: <4HVVzzXtybAGhlzTgO9OO9i0gY6jOXMFifw-4DgVZHg=.66092864-4ba9-4535-a54c-3adea5f4b3c4@github.com>

On Wed, 11 Jun 2025 10:05:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
> 
> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
> 
> 
> public void setTTL(byte ttl) throws IOException
> public byte getTTL() throws IOException
> 
> 
> and this other one on `MulticastSocket`:
> 
> 
> public void send(DatagramPacket p, byte ttl) throws IOException 
> 
> 
> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
> 
> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
> 
> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.

test/jdk/java/net/MulticastSocket/SetTTLTo0.java line 26:

> 24: /* @test
> 25:  * @bug 4148757
> 26:  * @summary Make sure MulticastSocket.setTimeToLive() can be set to 0

I think the original okay as this test just checks that you are set the TTL to 0.

test/jdk/java/nio/channels/DatagramChannel/AdaptorMulticasting.java line 410:

> 408:         DatagramPacket p = new DatagramPacket(message, message.length);
> 409:         p.setSocketAddress(target);
> 410:         final int oldTTL = s.getTimeToLive();

Just replacing it with s.send(p) should be okay here, no need to set/restore TTL.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25744#discussion_r2139782287
PR Review Comment: https://git.openjdk.org/jdk/pull/25744#discussion_r2139778959

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 jpai at openjdk.org  Wed Jun 11 10:42:12 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 10:42:12 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte) [v2]
In-Reply-To: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
Message-ID: <BgNh7VcZDDn_hixD1p8-ABb7ISHL0jbo35AzotAh7aU=.bdcc6f92-5fec-4a03-a0be-cb4feb187cfc@github.com>

> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
> 
> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
> 
> 
> public void setTTL(byte ttl) throws IOException
> public byte getTTL() throws IOException
> 
> 
> and this other one on `MulticastSocket`:
> 
> 
> public void send(DatagramPacket p, byte ttl) throws IOException 
> 
> 
> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
> 
> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
> 
> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.

Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:

 - no need to setTimeToLive() in AdaptorMulticasting test
 - undo change to "@summary" of a test
 - remove sendLock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25744/files
  - new: https://git.openjdk.org/jdk/pull/25744/files/934d3357..c0017d07

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

  Stats: 31 lines in 3 files changed: 0 ins; 26 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25744/head:pull/25744

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

From jpai at openjdk.org  Wed Jun 11 10:42:12 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 10:42:12 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte) [v2]
In-Reply-To: <splwdKURAY698rTNujlB48ksxTaR7BEPjDXuQRBRCGc=.430d0072-8413-4039-afad-2abb2a578b20@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
 <splwdKURAY698rTNujlB48ksxTaR7BEPjDXuQRBRCGc=.430d0072-8413-4039-afad-2abb2a578b20@github.com>
Message-ID: <1_InbStWgQLW4U57SPscWpKF5Zy4QYJyKYulsWNsZwU=.a39fd476-348c-4f1a-89f8-79c8514edd89@github.com>

On Wed, 11 Jun 2025 10:23:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - no need to setTimeToLive() in AdaptorMulticasting test
>>  - undo change to "@summary" of a test
>>  - remove sendLock
>
> src/java.base/share/classes/sun/nio/ch/DatagramSocketAdaptor.java line 564:
> 
>> 562:     @SuppressWarnings("removal")
>> 563:     public void send(DatagramPacket p, byte ttl) throws IOException {
>> 564:         sendLock.lock();
> 
> sendLock can be removed too, it's only need because of this send method.

I hadn't noticed that. I have removed it now and updated the PR.

> test/jdk/java/net/MulticastSocket/SetTTLTo0.java line 26:
> 
>> 24: /* @test
>> 25:  * @bug 4148757
>> 26:  * @summary Make sure MulticastSocket.setTimeToLive() can be set to 0
> 
> I think the original okay as this test just checks that you are set the TTL to 0.

Done - reverted the `@summary` to the original one.

> test/jdk/java/nio/channels/DatagramChannel/AdaptorMulticasting.java line 410:
> 
>> 408:         DatagramPacket p = new DatagramPacket(message, message.length);
>> 409:         p.setSocketAddress(target);
>> 410:         final int oldTTL = s.getTimeToLive();
> 
> Just replacing it with s.send(p) should be okay here, no need to set/restore TTL.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25744#discussion_r2139801248
PR Review Comment: https://git.openjdk.org/jdk/pull/25744#discussion_r2139802233
PR Review Comment: https://git.openjdk.org/jdk/pull/25744#discussion_r2139801483

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 dfuchs at openjdk.org  Wed Jun 11 11:54:33 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 11 Jun 2025 11:54:33 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte) [v2]
In-Reply-To: <BgNh7VcZDDn_hixD1p8-ABb7ISHL0jbo35AzotAh7aU=.bdcc6f92-5fec-4a03-a0be-cb4feb187cfc@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
 <BgNh7VcZDDn_hixD1p8-ABb7ISHL0jbo35AzotAh7aU=.bdcc6f92-5fec-4a03-a0be-cb4feb187cfc@github.com>
Message-ID: <53H1sX7ZGsgiaIt4F_nnUelj-59ZxxIn8XgfuBb8vGA=.8ecc01f6-7cb8-46c1-a001-842e9f9e94c5@github.com>

On Wed, 11 Jun 2025 10:42:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
>> 
>> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
>> 
>> 
>> public void setTTL(byte ttl) throws IOException
>> public byte getTTL() throws IOException
>> 
>> 
>> and this other one on `MulticastSocket`:
>> 
>> 
>> public void send(DatagramPacket p, byte ttl) throws IOException 
>> 
>> 
>> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
>> 
>> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
>> 
>> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - no need to setTimeToLive() in AdaptorMulticasting test
>  - undo change to "@summary" of a test
>  - remove sendLock

Generally look good. One question on one of the tests.

test/jdk/java/net/DatagramSocket/SendCheck.java line 133:

> 131:                 Sender.of(DatagramChannel.open().socket()),
> 132:                 Sender.of((MulticastSocket)
> 133:                         DatagramChannel.open().socket(), (byte) 0)

Should we instead just remove the ttl parameter and test with plain MulticastSocket::send?

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

PR Review: https://git.openjdk.org/jdk/pull/25744#pullrequestreview-2916814072
PR Review Comment: https://git.openjdk.org/jdk/pull/25744#discussion_r2139934428

From duke at openjdk.org  Wed Jun 11 11:58:30 2025
From: duke at openjdk.org (Rohitash Kumar)
Date: Wed, 11 Jun 2025 11:58:30 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v9]
In-Reply-To: <46QgTbFuJlEoKvVLhEG4Emh0dWJ2Gj1Fhce8jZ8qon4=.6bd1a283-22a7-43c2-80d6-83fa4d9e90d9@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <46QgTbFuJlEoKvVLhEG4Emh0dWJ2Gj1Fhce8jZ8qon4=.6bd1a283-22a7-43c2-80d6-83fa4d9e90d9@github.com>
Message-ID: <EECMDwHDOQe-B1dMPKCzP-G89FqKoIsZRYo-6W7W7P8=.a3997e4b-3c97-4a42-9392-aede6f8e308a@github.com>

On Tue, 10 Jun 2025 16:27:52 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

>> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
>> 
>> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>>  
>> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
>> 
>> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
>> 
>> **before**
>> 
>> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
>> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
>> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
>> [1
>> 
>> **after**
>> 
>> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
>> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
>> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
>> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
>> 
>> 
>> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
>> 
>> **Before**
>> 
>> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
>> B...
>
> Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change for to while loop and update copyright year

/Integrate

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

PR Comment: https://git.openjdk.org/jdk/pull/25487#issuecomment-2962394802

From jpai at openjdk.org  Wed Jun 11 12:07:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 12:07:51 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte) [v3]
In-Reply-To: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
Message-ID: <c-WFuFIED56QxSBaFv-HXYgn5LsJy5nQ7u-bWzT-WVA=.b7b03730-1b72-4ab5-aa6d-d224849cc0bd@github.com>

> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
> 
> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
> 
> 
> public void setTTL(byte ttl) throws IOException
> public byte getTTL() throws IOException
> 
> 
> and this other one on `MulticastSocket`:
> 
> 
> public void send(DatagramPacket p, byte ttl) throws IOException 
> 
> 
> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
> 
> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
> 
> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Daniel's review - continue to test MulticastSocket in SendCheck

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25744/files
  - new: https://git.openjdk.org/jdk/pull/25744/files/c0017d07..7a33f351

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

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

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

From jpai at openjdk.org  Wed Jun 11 12:07:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 12:07:51 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte) [v3]
In-Reply-To: <53H1sX7ZGsgiaIt4F_nnUelj-59ZxxIn8XgfuBb8vGA=.8ecc01f6-7cb8-46c1-a001-842e9f9e94c5@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
 <BgNh7VcZDDn_hixD1p8-ABb7ISHL0jbo35AzotAh7aU=.bdcc6f92-5fec-4a03-a0be-cb4feb187cfc@github.com>
 <53H1sX7ZGsgiaIt4F_nnUelj-59ZxxIn8XgfuBb8vGA=.8ecc01f6-7cb8-46c1-a001-842e9f9e94c5@github.com>
Message-ID: <ZPFRxkh98gS2h8zwULd_fjKNHzMb_RjAXbwq-sGzuCg=.23160510-30df-45a7-89d8-33af7286d38a@github.com>

On Wed, 11 Jun 2025 11:49:22 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 review - continue to test MulticastSocket in SendCheck
>
> test/jdk/java/net/DatagramSocket/SendCheck.java line 133:
> 
>> 131: 
>> 132:         List<Object[]> testcases = new ArrayList<>();
>> 133:         for (var packet : Packets) {
> 
> Should we instead just remove the ttl parameter and test with plain MulticastSocket::send?

That's a good catch. The test description of this test states that it's meant to test DatagramSocket, the adaptor, the DatagramChannel and the MulticastSocket. The change I did would have stopped testing MulticastSocket altogether. I have now updated the PR to only remove the use of a setTTL() from this test and it now continues to test the send() methods of these classes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25744#discussion_r2139961400

From duke at openjdk.org  Wed Jun 11 12:27:32 2025
From: duke at openjdk.org (duke)
Date: Wed, 11 Jun 2025 12:27:32 GMT
Subject: RFR: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes [v9]
In-Reply-To: <46QgTbFuJlEoKvVLhEG4Emh0dWJ2Gj1Fhce8jZ8qon4=.6bd1a283-22a7-43c2-80d6-83fa4d9e90d9@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
 <46QgTbFuJlEoKvVLhEG4Emh0dWJ2Gj1Fhce8jZ8qon4=.6bd1a283-22a7-43c2-80d6-83fa4d9e90d9@github.com>
Message-ID: <hD-aqGtpgUoNUfarNaDbmw38fdPUl5Tgp47r8TZoLbQ=.c1af0ea8-b751-4188-b349-0a977f9a5755@github.com>

On Tue, 10 Jun 2025 16:27:52 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

>> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
>> 
>> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>>  
>> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
>> 
>> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
>> 
>> **before**
>> 
>> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
>> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
>> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
>> [1
>> 
>> **after**
>> 
>> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
>> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
>> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
>> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
>> 
>> 
>> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
>> 
>> **Before**
>> 
>> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
>> B...
>
> Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change for to while loop and update copyright year

@rk-kmr 
Your change (at version 2867d495593a71e884fd287e069f6335313560c9) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25487#issuecomment-2962487376

From dfuchs at openjdk.org  Wed Jun 11 13:18:30 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 11 Jun 2025 13:18:30 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte) [v3]
In-Reply-To: <c-WFuFIED56QxSBaFv-HXYgn5LsJy5nQ7u-bWzT-WVA=.b7b03730-1b72-4ab5-aa6d-d224849cc0bd@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
 <c-WFuFIED56QxSBaFv-HXYgn5LsJy5nQ7u-bWzT-WVA=.b7b03730-1b72-4ab5-aa6d-d224849cc0bd@github.com>
Message-ID: <Uc5Y1fDXYcMc4XREU_sxh3PQaFnC6AfIoQlVBOwHSPY=.bb3284ba-16da-412e-9a32-32a59d263702@github.com>

On Wed, 11 Jun 2025 12:07:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
>> 
>> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
>> 
>> 
>> public void setTTL(byte ttl) throws IOException
>> public byte getTTL() throws IOException
>> 
>> 
>> and this other one on `MulticastSocket`:
>> 
>> 
>> public void send(DatagramPacket p, byte ttl) throws IOException 
>> 
>> 
>> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
>> 
>> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
>> 
>> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's review - continue to test MulticastSocket in SendCheck

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25744#pullrequestreview-2917111623

From alanb at openjdk.org  Wed Jun 11 14:12:37 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Jun 2025 14:12:37 GMT
Subject: Integrated: 8358764: (sc) SocketChannel.close when thread blocked in
 read causes connection to be reset (win)
In-Reply-To: <2JaiaJEJeeH1tfyvK_q8liQeOmuKDUBqNjKSQCoD5ls=.6c078e51-2710-498a-83c6-f0e925e97827@github.com>
References: <2JaiaJEJeeH1tfyvK_q8liQeOmuKDUBqNjKSQCoD5ls=.6c078e51-2710-498a-83c6-f0e925e97827@github.com>
Message-ID: <Mr12mv1FxuIhWapAx9WYfnn_Va9ssmUDSXup7BFXN3I=.4699c033-340e-464d-b838-16f128678ce8@github.com>

On Mon, 9 Jun 2025 19:17:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> On Windows, if a platform thread is blocked in SocketChannel.read, and another thread closes the channel, then Windows abruptly closes the connection (RST).  In releases prior to JDK 11,  the connection was shutdown for writing before closing so the connection was closed gracefully, an unexpected behavior change
> 
> implCloseBlockingMode is changed to shutdown the connection for writing on Windows, no change in behavior for other platforms.

This pull request has now been integrated.

Changeset: e5196fc2
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e5196fc24d2ec9e581af7803ac47036111fee029
Stats:     244 lines in 5 files changed: 227 ins; 1 del; 16 mod

8358764: (sc) SocketChannel.close when thread blocked in read causes connection to be reset (win)

Reviewed-by: jpai, vyazici

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

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

From bpb at openjdk.org  Wed Jun 11 15:32:28 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Jun 2025 15:32:28 GMT
Subject: RFR: 8357286: (bf) Remove obsolete instanceof checks in
 CharBuffer.append
In-Reply-To: <nLsLaNl8j_SoiwaDvB__K8p4h3s8MpgscdzUXVxCqdI=.99e668b3-44ae-4ff0-8beb-c6cbda219088@github.com>
References: <S1_AE1lulvhDJ9RyzSux0jzpERWAIJLuHmWz8O_Z3SU=.f78cdce0-efb9-4b95-8329-7eeb6dfec4e2@github.com>
 <nLsLaNl8j_SoiwaDvB__K8p4h3s8MpgscdzUXVxCqdI=.99e668b3-44ae-4ff0-8beb-c6cbda219088@github.com>
Message-ID: <CHX73BSWeLPYSHQFTVxcQ93E_GagzMbpp35_krF876w=.50575e71-54ed-4e58-80f3-e24bfc57bfc2@github.com>

On Wed, 11 Jun 2025 07:37:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Brian, it looks like the Basic.java test has caught a genuine issue with this change:

Which `Basic.java`? The `jdk_nio` tests all passed on Linux.

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

PR Comment: https://git.openjdk.org/jdk/pull/25739#issuecomment-2963278033

From bpb at openjdk.org  Wed Jun 11 15:32:30 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Jun 2025 15:32:30 GMT
Subject: RFR: 8357286: (bf) Remove obsolete instanceof checks in
 CharBuffer.append
In-Reply-To: <kc3Pw3fL4w24hU2bhPjhYkSua2rVlyqKBXCxdKspCMU=.2d09195e-f41b-4fe1-989a-6aa39d876e4a@github.com>
References: <S1_AE1lulvhDJ9RyzSux0jzpERWAIJLuHmWz8O_Z3SU=.f78cdce0-efb9-4b95-8329-7eeb6dfec4e2@github.com>
 <kc3Pw3fL4w24hU2bhPjhYkSua2rVlyqKBXCxdKspCMU=.2d09195e-f41b-4fe1-989a-6aa39d876e4a@github.com>
Message-ID: <mT2A878khReRoyx-83VVOyI6qdF8LIMdsuf-rJcr6ak=.076cd912-77b2-4de9-8fd6-fdf5e957670d@github.com>

On Wed, 11 Jun 2025 08:40:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Remove some instanceof checks which are vestigial now that `CharSequence` itself defines `getChars(int,int,char[],int)`.
>
> src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template line 297:
> 
>> 295:         checkSession();
>> 296: 
>> 297:         Objects.checkFromToIndex(start, end, csq.length());
> 
> The append(CharSequence) methods are specified to append "null" when the CharSequence is null so append(null, 0, 0) will need to be handled here.

Based on code inspection, it looks like that error might have already been possible but did not turn up before.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25739#discussion_r2140494453

From jpai at openjdk.org  Wed Jun 11 15:58:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 15:58:28 GMT
Subject: RFR: 8357286: (bf) Remove obsolete instanceof checks in
 CharBuffer.append
In-Reply-To: <CHX73BSWeLPYSHQFTVxcQ93E_GagzMbpp35_krF876w=.50575e71-54ed-4e58-80f3-e24bfc57bfc2@github.com>
References: <S1_AE1lulvhDJ9RyzSux0jzpERWAIJLuHmWz8O_Z3SU=.f78cdce0-efb9-4b95-8329-7eeb6dfec4e2@github.com>
 <nLsLaNl8j_SoiwaDvB__K8p4h3s8MpgscdzUXVxCqdI=.99e668b3-44ae-4ff0-8beb-c6cbda219088@github.com>
 <CHX73BSWeLPYSHQFTVxcQ93E_GagzMbpp35_krF876w=.50575e71-54ed-4e58-80f3-e24bfc57bfc2@github.com>
Message-ID: <XIWOqjhNoxVkptqfFtxBo9GKl6ihP0WYY82_ZR1BRjs=.aa97c362-a797-48e5-8a55-c7db34ca2bcc@github.com>

On Wed, 11 Jun 2025 15:27:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > Hello Brian, it looks like the Basic.java test has caught a genuine issue with this change:
> 
> Which `Basic.java`? The `jdk_nio` tests all passed on Linux.

The failure was from the GitHub actions jobs that are linked against this PR. For example here https://github.com/bplb/jdk/actions/runs/15573247306#summary-43854237657. The test appears to be `java/lang/Appendable/Basic`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25739#issuecomment-2963365420

From bpb at openjdk.org  Wed Jun 11 16:13:32 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Jun 2025 16:13:32 GMT
Subject: RFR: 8357286: (bf) Remove obsolete instanceof checks in
 CharBuffer.append
In-Reply-To: <XIWOqjhNoxVkptqfFtxBo9GKl6ihP0WYY82_ZR1BRjs=.aa97c362-a797-48e5-8a55-c7db34ca2bcc@github.com>
References: <S1_AE1lulvhDJ9RyzSux0jzpERWAIJLuHmWz8O_Z3SU=.f78cdce0-efb9-4b95-8329-7eeb6dfec4e2@github.com>
 <nLsLaNl8j_SoiwaDvB__K8p4h3s8MpgscdzUXVxCqdI=.99e668b3-44ae-4ff0-8beb-c6cbda219088@github.com>
 <CHX73BSWeLPYSHQFTVxcQ93E_GagzMbpp35_krF876w=.50575e71-54ed-4e58-80f3-e24bfc57bfc2@github.com>
 <XIWOqjhNoxVkptqfFtxBo9GKl6ihP0WYY82_ZR1BRjs=.aa97c362-a797-48e5-8a55-c7db34ca2bcc@github.com>
Message-ID: <7vfw3shTCxIQxPUNgGOTij786oiNhexcv-4YBEV9CjQ=.3b64fc8b-a85b-4e0e-bd5e-579ffb93f27c@github.com>

On Wed, 11 Jun 2025 15:56:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The test appears to be `java/lang/Appendable/Basic`.

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25739#issuecomment-2963412066

From bpb at openjdk.org  Wed Jun 11 22:36:49 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Jun 2025 22:36:49 GMT
Subject: RFR: 8357286: (bf) Remove obsolete instanceof checks in
 CharBuffer.append [v2]
In-Reply-To: <S1_AE1lulvhDJ9RyzSux0jzpERWAIJLuHmWz8O_Z3SU=.f78cdce0-efb9-4b95-8329-7eeb6dfec4e2@github.com>
References: <S1_AE1lulvhDJ9RyzSux0jzpERWAIJLuHmWz8O_Z3SU=.f78cdce0-efb9-4b95-8329-7eeb6dfec4e2@github.com>
Message-ID: <YnLjaKtO8K6v1tAWahAOegilvQHCX8XaqdVyZWaa-ew=.976df254-062c-4edd-8ee7-dde8d5860ec0@github.com>

> Remove some instanceof checks which are vestigial now that `CharSequence` itself defines `getChars(int,int,char[],int)`.

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

  8357286: Correctly handle null CharSequence

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25739/files
  - new: https://git.openjdk.org/jdk/pull/25739/files/6f02b2cd..cda92b2e

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

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

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

From bpb at openjdk.org  Wed Jun 11 22:36:49 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Jun 2025 22:36:49 GMT
Subject: RFR: 8357286: (bf) Remove obsolete instanceof checks in
 CharBuffer.append [v2]
In-Reply-To: <mT2A878khReRoyx-83VVOyI6qdF8LIMdsuf-rJcr6ak=.076cd912-77b2-4de9-8fd6-fdf5e957670d@github.com>
References: <S1_AE1lulvhDJ9RyzSux0jzpERWAIJLuHmWz8O_Z3SU=.f78cdce0-efb9-4b95-8329-7eeb6dfec4e2@github.com>
 <kc3Pw3fL4w24hU2bhPjhYkSua2rVlyqKBXCxdKspCMU=.2d09195e-f41b-4fe1-989a-6aa39d876e4a@github.com>
 <mT2A878khReRoyx-83VVOyI6qdF8LIMdsuf-rJcr6ak=.076cd912-77b2-4de9-8fd6-fdf5e957670d@github.com>
Message-ID: <C8DQKptAqsyQFas8UmNkIdcoKxPxCMVeamQKvREasUg=.7a43922a-4a39-464b-b93d-2ca3e44dcdc4@github.com>

On Wed, 11 Jun 2025 15:29:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template line 297:
>> 
>>> 295:         checkSession();
>>> 296: 
>>> 297:         Objects.checkFromToIndex(start, end, csq.length());
>> 
>> The append(CharSequence) methods are specified to append "null" when the CharSequence is null so append(null, 0, 0) will need to be handled here.
>
> Based on code inspection, it looks like that error might have already been possible but did not turn up before.

Fixed in cda92b2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25739#discussion_r2141216896

From alanb at openjdk.org  Thu Jun 12 06:37:23 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Jun 2025 06:37:23 GMT
Subject: RFR: 8358958: (aio) AsynchronousByteChannel.read/write should
 throw IAE if buffer is thread-confined [v3]
In-Reply-To: <oBLENz5Rz7APHyKcvEioLetpi_6kRIC43LyxjcVoCSc=.fb9da1be-e200-4ee5-a94c-f15da0cefb91@github.com>
References: <oBLENz5Rz7APHyKcvEioLetpi_6kRIC43LyxjcVoCSc=.fb9da1be-e200-4ee5-a94c-f15da0cefb91@github.com>
Message-ID: <LnoIL4Ta1-B6jA8Nh-IaUs9bWKWegIOOHQWGlkd24tA=.b94ca4cf-d2c2-4db5-b0b5-08957823f91c@github.com>

> It's nonsensical to invoke read/write methods defined by the AsynchronousXXX channels with buffers that are views of memory segments allocated from a thread-confined arena.
> 
> For AsynchronousSocketChannel, the current behavior is for the read/write methods to initiate an I/O operation that completes with an IOException and an IllegalStateException as cause. For AsynchronousFileChannel, the current behavior is for the read/write methods to initiate an I/O operation that never completes (a thread in the channel groups terminates with a WrongThreadException).
> 
> The proposal is that the read/write methods reject, with IllegalArgumentException, any attempt to initiate as async I/O operation with a buffer from a thread-confined arena. IAE is already declared to be thrown for read-only buffers or attempting a positional read/write with a negative file position.
> 
> The java/nio/channels/etc/MemorySegments.java test is updated to test AsynchronousSocketChannel and AsynchronousFileChannel with buffers from all arena kinds. The tests include attempts to close a shared arena while an I/O operation is in progress. For now, the testAsyncFileChannelXXX tests are disabled until they meet up with the changes in JDK-8357847 (pr/25531).

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Update copyright header
 - Merge branch 'master' into JDK-8358958
 - Missing update to TestAsyncSocketChannels
 - Merge branch 'master' into JDK-8358958
 - Drop links to problematic operations from asByteBuffer method description
 - Disable testAsyncFileChannelReadWrite on Windows for now
 - Add test for async close of arena
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25691/files
  - new: https://git.openjdk.org/jdk/pull/25691/files/4a66c604..60658f18

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

  Stats: 3440 lines in 76 files changed: 1704 ins; 1418 del; 318 mod
  Patch: https://git.openjdk.org/jdk/pull/25691.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25691/head:pull/25691

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

From alanb at openjdk.org  Thu Jun 12 06:37:25 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Jun 2025 06:37:25 GMT
Subject: RFR: 8358958: (aio) AsynchronousByteChannel.read/write should
 throw IAE if buffer is thread-confined [v2]
In-Reply-To: <kGyNGKowPlbHZ8gLNYTDHgj3e0atrS5_QBGEKsQqmoE=.9b2cb1eb-7c4e-4dac-939f-fe7723889205@github.com>
References: <oBLENz5Rz7APHyKcvEioLetpi_6kRIC43LyxjcVoCSc=.fb9da1be-e200-4ee5-a94c-f15da0cefb91@github.com>
 <OUnCBV-3SCIsEB4xX19sHPK7N4P7EIRp8Yo6FQy83mY=.b2d89662-87db-4d77-a67b-9d701591765e@github.com>
 <kGyNGKowPlbHZ8gLNYTDHgj3e0atrS5_QBGEKsQqmoE=.9b2cb1eb-7c4e-4dac-939f-fe7723889205@github.com>
Message-ID: <LvOuAg7P6qsWYTW09yc4CFr593ydtpOi0EXXJba157g=.f2903542-7f61-4b5b-9fed-8c89806f6cfa@github.com>

On Wed, 11 Jun 2025 07:31:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing update to TestAsyncSocketChannels
>
> test/jdk/java/nio/channels/etc/MemorySegments.java line 663:
> 
>> 661:         Arena arena = arenaSupplier.get();
>> 662: 
>> 663:         Path file = Files.createTempFile(Path.of(""), "foo", ".dat");
> 
> Is the use of an empty `Path` instead of `Path.of(".")` intentional here? The documentation of `Path` states:
> 
> 
>> Accessing a file using an <i>empty path</i> is equivalent to accessing the default directory of the file system.
> 
> Unlike the current working directory, I couldn't find the definition of default directory. Are they the same for the default filesystem?

Path.of("") is intentional here, using Path.of(".") would work the same way. The default directory has always been the current working directory (user.dir). Maybe the docs could be clearer on this but it would be significant work to review changes to long standing API docs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25691#discussion_r2141820293

From alanb at openjdk.org  Thu Jun 12 06:46:31 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Jun 2025 06:46:31 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte) [v3]
In-Reply-To: <c-WFuFIED56QxSBaFv-HXYgn5LsJy5nQ7u-bWzT-WVA=.b7b03730-1b72-4ab5-aa6d-d224849cc0bd@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
 <c-WFuFIED56QxSBaFv-HXYgn5LsJy5nQ7u-bWzT-WVA=.b7b03730-1b72-4ab5-aa6d-d224849cc0bd@github.com>
Message-ID: <g3bH3ZlX4XGGP62pDKP5Nch8H6IA6xiYchVJ3Z97_WU=.dbb32788-8978-4f58-b736-f0c669906c55@github.com>

On Wed, 11 Jun 2025 12:07:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
>> 
>> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
>> 
>> 
>> public void setTTL(byte ttl) throws IOException
>> public byte getTTL() throws IOException
>> 
>> 
>> and this other one on `MulticastSocket`:
>> 
>> 
>> public void send(DatagramPacket p, byte ttl) throws IOException 
>> 
>> 
>> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
>> 
>> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
>> 
>> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's review - continue to test MulticastSocket in SendCheck

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25744#pullrequestreview-2919730619

From alanb at openjdk.org  Thu Jun 12 06:48:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Jun 2025 06:48:34 GMT
Subject: RFR: 8357286: (bf) Remove obsolete instanceof checks in
 CharBuffer.append [v2]
In-Reply-To: <YnLjaKtO8K6v1tAWahAOegilvQHCX8XaqdVyZWaa-ew=.976df254-062c-4edd-8ee7-dde8d5860ec0@github.com>
References: <S1_AE1lulvhDJ9RyzSux0jzpERWAIJLuHmWz8O_Z3SU=.f78cdce0-efb9-4b95-8329-7eeb6dfec4e2@github.com>
 <YnLjaKtO8K6v1tAWahAOegilvQHCX8XaqdVyZWaa-ew=.976df254-062c-4edd-8ee7-dde8d5860ec0@github.com>
Message-ID: <Vrf2-UbNQaUaije9TDwAUZOiNK5gRjEyptbmhgVoask=.93be7887-e8d5-4277-b851-af96cdc3673e@github.com>

On Wed, 11 Jun 2025 22:36:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove some instanceof checks which are vestigial now that `CharSequence` itself defines `getChars(int,int,char[],int)`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357286: Correctly handle null CharSequence

Updated patch looks okay, I assume at least tier1-3 have been run with the changes.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25739#pullrequestreview-2919735334

From alanb at openjdk.org  Thu Jun 12 11:14:32 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Jun 2025 11:14:32 GMT
Subject: RFR: 8359119: Change Charset to use StableValue [v2]
In-Reply-To: <l5D_p3SX_spsWDcXRAHC4qEBNNB9bkxY_C6Cfrn_SPY=.70b17a15-0390-4ced-b658-3954490660af@github.com>
References: <TQ1hWftS-obMd0ocVzaTgkCe7mI6be38FL5OsdZixRI=.82b1b28a-cb1f-4fcc-90cf-0d80bce57b63@github.com>
 <l5D_p3SX_spsWDcXRAHC4qEBNNB9bkxY_C6Cfrn_SPY=.70b17a15-0390-4ced-b658-3954490660af@github.com>
Message-ID: <bPQm2GAZ2ojXhw2_oJGVTqB7fs_90INXb9MHtz_vNCA=.62589ccc-b96a-411e-8af1-4b7e4df3b2a4@github.com>

On Tue, 10 Jun 2025 15:15:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Fields and methods can better leverage the Stable Value API compared to using DCL and holder classes. There are also some fields that can be marked `@Stable`.
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert for loop
>  - Revert more
>  - Revert changes

Overall I think this is okay but will need to run startup benchmarks due to this class being used in early startup.

src/java.base/share/classes/java/nio/charset/Charset.java line 431:

> 429:     /* The extended set of charsets */
> 430:     private static final Supplier<List<CharsetProvider>> EXTENDED_PROVIDERS = StableValue.supplier(
> 431:             new Supplier<>() { public List<CharsetProvider> get() { return extendedProviders0(); }});

This one looks okay.

src/java.base/share/classes/java/nio/charset/Charset.java line 627:

> 625:         return Objects.requireNonNullElse(
> 626:                 standardProvider.charsetForName(StaticProperty.fileEncoding()),
> 627:                 sun.nio.cs.UTF_8.INSTANCE);

I think it would more readable to keep the if-then-else rather than using requireNonNullElse here.

src/java.base/share/classes/java/nio/charset/Charset.java line 657:

> 655:     @Stable
> 656:     private final String name;          // tickles a bug in oldjavac
> 657:     @Stable

If we touching these then we can remove the "tickles a bug in oldjavac" comment as I think that goes back to before JDK 5.

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

PR Comment: https://git.openjdk.org/jdk/pull/25727#issuecomment-2966203126
PR Review Comment: https://git.openjdk.org/jdk/pull/25727#discussion_r2142374192
PR Review Comment: https://git.openjdk.org/jdk/pull/25727#discussion_r2142377094
PR Review Comment: https://git.openjdk.org/jdk/pull/25727#discussion_r2142380225

From jpai at openjdk.org  Thu Jun 12 11:24:34 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Jun 2025 11:24:34 GMT
Subject: RFR: 8358958: (aio) AsynchronousByteChannel.read/write should
 throw IAE if buffer is thread-confined [v2]
In-Reply-To: <LvOuAg7P6qsWYTW09yc4CFr593ydtpOi0EXXJba157g=.f2903542-7f61-4b5b-9fed-8c89806f6cfa@github.com>
References: <oBLENz5Rz7APHyKcvEioLetpi_6kRIC43LyxjcVoCSc=.fb9da1be-e200-4ee5-a94c-f15da0cefb91@github.com>
 <OUnCBV-3SCIsEB4xX19sHPK7N4P7EIRp8Yo6FQy83mY=.b2d89662-87db-4d77-a67b-9d701591765e@github.com>
 <kGyNGKowPlbHZ8gLNYTDHgj3e0atrS5_QBGEKsQqmoE=.9b2cb1eb-7c4e-4dac-939f-fe7723889205@github.com>
 <LvOuAg7P6qsWYTW09yc4CFr593ydtpOi0EXXJba157g=.f2903542-7f61-4b5b-9fed-8c89806f6cfa@github.com>
Message-ID: <mwWCuIqn2znrJRx3Sap71MWbGvqGfn02iaJT2TKc3pg=.09f9fe2e-f0d3-46b1-8c93-1a601906eb0f@github.com>

On Thu, 12 Jun 2025 06:31:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/nio/channels/etc/MemorySegments.java line 663:
>> 
>>> 661:         Arena arena = arenaSupplier.get();
>>> 662: 
>>> 663:         Path file = Files.createTempFile(Path.of(""), "foo", ".dat");
>> 
>> Is the use of an empty `Path` instead of `Path.of(".")` intentional here? The documentation of `Path` states:
>> 
>> 
>>> Accessing a file using an <i>empty path</i> is equivalent to accessing the default directory of the file system.
>> 
>> Unlike the current working directory, I couldn't find the definition of default directory. Are they the same for the default filesystem?
>
> Path.of("") is intentional here, using Path.of(".") would work the same way. The default directory has always been the current working directory (user.dir). Maybe the docs could be clearer on this but it would be significant work to review changes to long standing API docs.

I had a brief look for the "default directory" term within the JDK. It appears even in java.io area. So like you note it would need bigger work to make it clear. In any case, my question was more for understanding what the default directory resolves to and since it's the same as `Path.of(".")`, its usage itself is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25691#discussion_r2142414605

From jpai at openjdk.org  Thu Jun 12 11:24:32 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Jun 2025 11:24:32 GMT
Subject: RFR: 8358958: (aio) AsynchronousByteChannel.read/write should
 throw IAE if buffer is thread-confined [v3]
In-Reply-To: <LnoIL4Ta1-B6jA8Nh-IaUs9bWKWegIOOHQWGlkd24tA=.b94ca4cf-d2c2-4db5-b0b5-08957823f91c@github.com>
References: <oBLENz5Rz7APHyKcvEioLetpi_6kRIC43LyxjcVoCSc=.fb9da1be-e200-4ee5-a94c-f15da0cefb91@github.com>
 <LnoIL4Ta1-B6jA8Nh-IaUs9bWKWegIOOHQWGlkd24tA=.b94ca4cf-d2c2-4db5-b0b5-08957823f91c@github.com>
Message-ID: <bibPlHcZhkWmM7YuvGOFKpumUbNuN4AB1CiDks8WaTE=.698468ea-a6ab-47a7-9707-8b8b93f77287@github.com>

On Thu, 12 Jun 2025 06:37:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It's nonsensical to invoke read/write methods defined by the AsynchronousXXX channels with buffers that are views of memory segments allocated from a thread-confined arena.
>> 
>> For AsynchronousSocketChannel, the current behavior is for the read/write methods to initiate an I/O operation that completes with an IOException and an IllegalStateException as cause. For AsynchronousFileChannel, the current behavior is for the read/write methods to initiate an I/O operation that never completes (a thread in the channel groups terminates with a WrongThreadException).
>> 
>> The proposal is that the read/write methods reject, with IllegalArgumentException, any attempt to initiate as async I/O operation with a buffer from a thread-confined arena. IAE is already declared to be thrown for read-only buffers or attempting a positional read/write with a negative file position.
>> 
>> The java/nio/channels/etc/MemorySegments.java test is updated to test AsynchronousSocketChannel and AsynchronousFileChannel with buffers from all arena kinds. The tests include attempts to close a shared arena while an I/O operation is in progress. For now, the testAsyncFileChannelXXX tests are disabled until they meet up with the changes in JDK-8357847 (pr/25531).
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Update copyright header
>  - Merge branch 'master' into JDK-8358958
>  - Missing update to TestAsyncSocketChannels
>  - Merge branch 'master' into JDK-8358958
>  - Drop links to problematic operations from asByteBuffer method description
>  - Disable testAsyncFileChannelReadWrite on Windows for now
>  - Add test for async close of arena
>  - Initial commit

This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25691#pullrequestreview-2920651837

From duke at openjdk.org  Thu Jun 12 12:26:43 2025
From: duke at openjdk.org (Rohitash Kumar)
Date: Thu, 12 Jun 2025 12:26:43 GMT
Subject: Integrated: 8357959: (bf) ByteBuffer.allocateDirect initialization can
 result in large TTSP spikes
In-Reply-To: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
References: <33SAJo7kIIIwrfqktWGf4OcUVd-qWC7rLAG9MM9NFC4=.ac40cad3-75b0-4e82-9560-03f296b554be@github.com>
Message-ID: <07zVw3XBXG09yMmg9pNF9dmc2LjKxBEgD9EUBw0Lzl0=.95779260-4b07-4363-8f09-60bcb9142403@github.com>

On Wed, 28 May 2025 09:30:56 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

> ByteBuffer.allocateDirect uses UNSAFE.setMemory, causing high time-to-safepoint (100+ ms) for large (100 MB+) allocations.
> 
> This PR applies a simple fix by chunking the zeroing operation within ByteBuffers. A more robust solution would be to add chunking inside UNSAFE.setMemory itself. However Its not that straightforward as mentioned by Aleksey in [JDK-8357959](https://bugs.openjdk.org/browse/JDK-8357959)
>>Looks like all current uses we care about are in Buffers. Taking a safepoint within cleaning would open some questions whether any VM code expect to see semi-initialized area we are busy cleaning up. For Buffers, this question does not arise. Therefore, we can do the fix in Buffers first, without changing the Unsafe itself.
>  
> I can pursue that if its preferred. I chose 1 MB as a chunk size some what arbitrarily I am open to suggestion, if there are better options.
> 
> For verification, I tested the fix against the reproducer - [gist](https://gist.github.com/rk-kmr/be4322b72a14ae04aeefc0260c01acf6) and confirmed that ttsp timing were lower.
> 
> **before**
> 
> 0.444s][info][safepoint,stats] ThreadDump                   [             13               1 ][        194156625      65291  194221916 ]               0
> [0.662s][info][safepoint,stats] ThreadDump                   [             13               1 ][        200013875      87834  200101709 ]               0
> [0.858s][info][safepoint,stats] ThreadDump                   [             13               1 ][        183762583      43417  183806000 ]               0
> [1
> 
> **after**
> 
> 1.705s][info][safepoint,stats] ThreadDump                   [             11               1 ][            92792      24958     117750 ]               0
> [1.724s][info][safepoint,stats] ThreadDump                   [             11               1 ][           497375      94041     591416 ]               0
> [1.736s][info][safepoint,stats] ThreadDump                   [             11               1 ][           156750      47208     203958 ]               0
> [1.747s][info][safepoint,stats] ThreadDump                   [             11               1 ][           121958      28334     150292 ]               0
> 
> 
> I added a benchmark to ensure that chunking doesn't introduce significant overhead across different allocation sizes, and following results confirm that. 
> 
> **Before**
> 
> Benchmark                                              (bytes)  Mode  Cnt          Score         Error  Units
> ByteBufferAllocationBenchmark.allocateDirectBuffer         1...

This pull request has now been integrated.

Changeset: e5ce5c57
Author:    Rohitash Kumar <kurohita at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e5ce5c57c83972ff52758a804c942986cab74ca7
Stats:     132 lines in 4 files changed: 115 ins; 0 del; 17 mod

8357959: (bf) ByteBuffer.allocateDirect initialization can result in large TTSP spikes

Reviewed-by: shade, alanb

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

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

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 20:24:34 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Jun 2025 20:24:34 GMT
Subject: Integrated: 8357286: (bf) Remove obsolete instanceof checks in
 CharBuffer.append
In-Reply-To: <S1_AE1lulvhDJ9RyzSux0jzpERWAIJLuHmWz8O_Z3SU=.f78cdce0-efb9-4b95-8329-7eeb6dfec4e2@github.com>
References: <S1_AE1lulvhDJ9RyzSux0jzpERWAIJLuHmWz8O_Z3SU=.f78cdce0-efb9-4b95-8329-7eeb6dfec4e2@github.com>
Message-ID: <J0h16MzM4TWxKQEFyJL1GCRESAYlyxNUEmq9v0inNVM=.1548162f-d058-4888-a1cd-e7eb8ca8b80e@github.com>

On Wed, 11 Jun 2025 00:38:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove some instanceof checks which are vestigial now that `CharSequence` itself defines `getChars(int,int,char[],int)`.

This pull request has now been integrated.

Changeset: 0dd7c69b
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0dd7c69b9e4307e6e8f290b84828f6de8a79e644
Stats:     54 lines in 2 files changed: 10 ins; 29 del; 15 mod

8357286: (bf) Remove obsolete instanceof checks in CharBuffer.append

Reviewed-by: alanb

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

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

From alanb at openjdk.org  Fri Jun 13 06:36:37 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Jun 2025 06:36:37 GMT
Subject: Integrated: 8358958: (aio) AsynchronousByteChannel.read/write should
 throw IAE if buffer is thread-confined
In-Reply-To: <oBLENz5Rz7APHyKcvEioLetpi_6kRIC43LyxjcVoCSc=.fb9da1be-e200-4ee5-a94c-f15da0cefb91@github.com>
References: <oBLENz5Rz7APHyKcvEioLetpi_6kRIC43LyxjcVoCSc=.fb9da1be-e200-4ee5-a94c-f15da0cefb91@github.com>
Message-ID: <L4450ZH_MtUtcybu1fhjTpF-bhwsMxqZIfas0VmoRPc=.4bdf93e6-b0ef-4034-b6e9-cf0580537044@github.com>

On Mon, 9 Jun 2025 09:34:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It's nonsensical to invoke read/write methods defined by the AsynchronousXXX channels with buffers that are views of memory segments allocated from a thread-confined arena.
> 
> For AsynchronousSocketChannel, the current behavior is for the read/write methods to initiate an I/O operation that completes with an IOException and an IllegalStateException as cause. For AsynchronousFileChannel, the current behavior is for the read/write methods to initiate an I/O operation that never completes (a thread in the channel groups terminates with a WrongThreadException).
> 
> The proposal is that the read/write methods reject, with IllegalArgumentException, any attempt to initiate as async I/O operation with a buffer from a thread-confined arena. IAE is already declared to be thrown for read-only buffers or attempting a positional read/write with a negative file position.
> 
> The java/nio/channels/etc/MemorySegments.java test is updated to test AsynchronousSocketChannel and AsynchronousFileChannel with buffers from all arena kinds. The tests include attempts to close a shared arena while an I/O operation is in progress. For now, the testAsyncFileChannelXXX tests are disabled until they meet up with the changes in JDK-8357847 (pr/25531).

This pull request has now been integrated.

Changeset: 9aeacf2d
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9aeacf2de5bb8758dd614da365262338b0d26d6f
Stats:     443 lines in 9 files changed: 410 ins; 6 del; 27 mod

8358958: (aio) AsynchronousByteChannel.read/write should throw IAE if buffer is thread-confined

Reviewed-by: jpai, bpb

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

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

From syan at openjdk.org  Fri Jun 13 06:41:16 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 13 Jun 2025 06:41:16 GMT
Subject: RFR: 8359402: TesCloseDescriptors.java should throw SkippedException
 when there is no lsof/sctp
Message-ID: <F9DG6HnxKZxPMn6NpRlix-lBvbWZmfE-9jIBD_kggi4=.38c60e50-63a9-4975-a30c-0ce25976de96@github.com>

Hi all,

Test com/sun/nio/sctp/SctpChannel/CloseDescriptors.java should throw jtreg.SkippedException when there is no lsof command or there is no SCTP in test machine.
Before this PR, this test report Execution successful when there is no SCTP.


--------------------------------------------------
TEST: com/sun/nio/sctp/SctpChannel/CloseDescriptors.java
TEST RESULT: Passed. Execution successful
--------------------------------------------------


After this PR, it will report `jtreg.SkippedException` when there is no SCTP


--------------------------------------------------
TEST: com/sun/nio/sctp/SctpChannel/CloseDescriptors.java
TEST RESULT: Passed. Skipped: jtreg.SkippedException: SCTP protocol is not supported
--------------------------------------------------


Change has been verified locally, test-fix only, no risk.

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

Commit messages:
 - 8359402: TesCloseDescriptors.java should throw SkippedException when there is no lsof/sctp

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

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

From alanb at openjdk.org  Fri Jun 13 07:46:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Jun 2025 07:46:28 GMT
Subject: RFR: 8359119: Change Charset to use StableValue [v2]
In-Reply-To: <qllpKbtzUIJ-dJPNiGZSBEvLSypkWga2vh2a8VKhNJI=.41f015a0-0a64-4c00-99cd-d2b2fc0544c5@github.com>
References: <TQ1hWftS-obMd0ocVzaTgkCe7mI6be38FL5OsdZixRI=.82b1b28a-cb1f-4fcc-90cf-0d80bce57b63@github.com>
 <UmjHhAmdYONuXYwHGOY74XKHZeDKBjtfXF5ESDuSHGY=.d30ac15d-fa60-4880-a4c8-556505493bbf@github.com>
 <MCduZE958EiKd2K3UpGiF3Rb-CHlCBUJsbuVXRTmadM=.c234fe3f-f9a3-4848-9d62-2a2ac5c66a51@github.com>
 <qllpKbtzUIJ-dJPNiGZSBEvLSypkWga2vh2a8VKhNJI=.41f015a0-0a64-4c00-99cd-d2b2fc0544c5@github.com>
Message-ID: <K2muH5DUzEhNWWO1gG7PhBFSYfK9g_geD3eM-V-ASMI=.504a280f-0126-4286-b917-1ceb0e3929a8@github.com>

On Tue, 10 Jun 2025 15:22:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> So, revert the changes here?
>
> I think it's okay, it's just that the change is a reminder that all ThreadTracker usages can be replaced with a ScopedValue<Boolean> but may require a bit of work to allow using during early VM startup.

I chatted with Andrew Haley yesterday about allowing ScopedValue be used in early startup. Charset is initialized very early in initPhase1, when initializing the system properties, so easy to get recursive initialization issues that surface or NPE or other exceptions.  There are several ways we can fix this and it means that TRACKER is not needed. I don't mind if we change it to use a StableValue now but I expect we will change it very soon to remove ThreadTracker and just replace with ScopedValue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25727#discussion_r2144408658

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 duke at openjdk.org  Fri Jun 13 11:30:51 2025
From: duke at openjdk.org (Dermot Boyle)
Date: Fri, 13 Jun 2025 11:30:51 GMT
Subject: RFR: 8359127: Amend
 java/nio/channels/DatagramChannel/PromiscuousIPv6.java to use @requires for OS
 platform selection
Message-ID: <AJ_0a1zfRlhvu3sZ6UII_C8EbVH3QQhfKcg4_TEMlRE=.fd0458eb-6480-47b5-9123-58549585a2a4@github.com>

Replaced programmatic check for the OS platform (which threw a Skipped exception) with JTreg @requires.

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

Commit messages:
 - Update coopyright header
 - JDK-8359127: Amend java/nio/channels/DatagramChannel/PromiscuousIPv6.java to use @requires for OS platform selection

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

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

From syan at openjdk.org  Fri Jun 13 11:30:51 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 13 Jun 2025 11:30:51 GMT
Subject: RFR: 8359127: Amend
 java/nio/channels/DatagramChannel/PromiscuousIPv6.java to use @requires for OS
 platform selection
In-Reply-To: <AJ_0a1zfRlhvu3sZ6UII_C8EbVH3QQhfKcg4_TEMlRE=.fd0458eb-6480-47b5-9123-58549585a2a4@github.com>
References: <AJ_0a1zfRlhvu3sZ6UII_C8EbVH3QQhfKcg4_TEMlRE=.fd0458eb-6480-47b5-9123-58549585a2a4@github.com>
Message-ID: <OM0h_TR0wVF73_ToIjRTgW5D48Fooe1eHFGCUDycI54=.51525457-553b-4314-8411-8dd6e413d777@github.com>

On Thu, 12 Jun 2025 11:55:35 GMT, Dermot Boyle <duke at openjdk.org> wrote:

> Replaced programmatic check for the OS platform (which threw a Skipped exception) with JTreg @requires.

The copyright year should be updated from 2023 to 2025.

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

PR Comment: https://git.openjdk.org/jdk/pull/25781#issuecomment-2968771195

From duke at openjdk.org  Fri Jun 13 11:45:30 2025
From: duke at openjdk.org (serhiysachkov)
Date: Fri, 13 Jun 2025 11:45:30 GMT
Subject: RFR: 8359127: Amend
 java/nio/channels/DatagramChannel/PromiscuousIPv6.java to use @requires for OS
 platform selection
In-Reply-To: <AJ_0a1zfRlhvu3sZ6UII_C8EbVH3QQhfKcg4_TEMlRE=.fd0458eb-6480-47b5-9123-58549585a2a4@github.com>
References: <AJ_0a1zfRlhvu3sZ6UII_C8EbVH3QQhfKcg4_TEMlRE=.fd0458eb-6480-47b5-9123-58549585a2a4@github.com>
Message-ID: <iouYxQgdbi541O3IJASE2DGRoMas1IBcUZovyH3vP7g=.1ae8293d-794f-495c-8e80-326cb0e17fc4@github.com>

On Thu, 12 Jun 2025 11:55:35 GMT, Dermot Boyle <duke at openjdk.org> wrote:

> Replaced programmatic check for the OS platform (which threw a Skipped exception) with JTreg @requires.

LGTM

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

PR Comment: https://git.openjdk.org/jdk/pull/25781#issuecomment-2970134715

From mchhipa at openjdk.org  Fri Jun 13 12:51:40 2025
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Fri, 13 Jun 2025 12:51:40 GMT
Subject: RFR: 8359127: Amend
 java/nio/channels/DatagramChannel/PromiscuousIPv6.java to use @requires for OS
 platform selection
In-Reply-To: <AJ_0a1zfRlhvu3sZ6UII_C8EbVH3QQhfKcg4_TEMlRE=.fd0458eb-6480-47b5-9123-58549585a2a4@github.com>
References: <AJ_0a1zfRlhvu3sZ6UII_C8EbVH3QQhfKcg4_TEMlRE=.fd0458eb-6480-47b5-9123-58549585a2a4@github.com>
Message-ID: <NZ795iJnEa2u8GXcN3e5hQD39TtXz-SbSl4uayetBfo=.b3236e48-0f55-4bc9-9c3b-4bb4a0b1fa45@github.com>

On Thu, 12 Jun 2025 11:55:35 GMT, Dermot Boyle <duke at openjdk.org> wrote:

> Replaced programmatic check for the OS platform (which threw a Skipped exception) with JTreg @requires.

test/jdk/java/nio/channels/DatagramChannel/PromiscuousIPv6.java line 215:

> 213:         boolean hasIPV6MulticastAll;
> 214: 
> 215:         if (!supportedByPlatform()) {

supportedByPlatform() method definition can be deleted from line number 207, as not it is not being called anywhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25781#discussion_r2145024909

From dfuchs at openjdk.org  Fri Jun 13 13:10:33 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Jun 2025 13:10:33 GMT
Subject: RFR: 8359127: Amend
 java/nio/channels/DatagramChannel/PromiscuousIPv6.java to use @requires for OS
 platform selection
In-Reply-To: <AJ_0a1zfRlhvu3sZ6UII_C8EbVH3QQhfKcg4_TEMlRE=.fd0458eb-6480-47b5-9123-58549585a2a4@github.com>
References: <AJ_0a1zfRlhvu3sZ6UII_C8EbVH3QQhfKcg4_TEMlRE=.fd0458eb-6480-47b5-9123-58549585a2a4@github.com>
Message-ID: <U_eElm9gM5ZOdmHzRnfnbABUi-KXsMZPBZQtyBh86B4=.34cfc837-705e-4b87-83a6-7fc9465ce9e4@github.com>

On Thu, 12 Jun 2025 11:55:35 GMT, Dermot Boyle <duke at openjdk.org> wrote:

> Replaced programmatic check for the OS platform (which threw a Skipped exception) with JTreg @requires.

I have the same remark than @mahendrachhipa, otherwise LGTM.

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

PR Comment: https://git.openjdk.org/jdk/pull/25781#issuecomment-2970338575

From duke at openjdk.org  Fri Jun 13 13:25:38 2025
From: duke at openjdk.org (Dermot Boyle)
Date: Fri, 13 Jun 2025 13:25:38 GMT
Subject: RFR: 8359127: Amend
 java/nio/channels/DatagramChannel/PromiscuousIPv6.java to use @requires for OS
 platform selection [v2]
In-Reply-To: <AJ_0a1zfRlhvu3sZ6UII_C8EbVH3QQhfKcg4_TEMlRE=.fd0458eb-6480-47b5-9123-58549585a2a4@github.com>
References: <AJ_0a1zfRlhvu3sZ6UII_C8EbVH3QQhfKcg4_TEMlRE=.fd0458eb-6480-47b5-9123-58549585a2a4@github.com>
Message-ID: <S9aJoT-2NAMXda6SGYP0-h13c3KS5ysdDNNPIzzDywo=.81c90f3a-cddd-4e03-a372-d8a4ffdf3f0f@github.com>

> Replaced programmatic check for the OS platform (which threw a Skipped exception) with JTreg @requires.

Dermot Boyle has updated the pull request incrementally with one additional commit since the last revision:

  Removed unused supportedByPlatform() method definition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25781/files
  - new: https://git.openjdk.org/jdk/pull/25781/files/e21548b0..6831ea37

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

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

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

From djelinski at openjdk.org  Fri Jun 13 14:44:59 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 13 Jun 2025 14:44:59 GMT
Subject: RFR: 8359127: Amend
 java/nio/channels/DatagramChannel/PromiscuousIPv6.java to use @requires for OS
 platform selection [v2]
In-Reply-To: <S9aJoT-2NAMXda6SGYP0-h13c3KS5ysdDNNPIzzDywo=.81c90f3a-cddd-4e03-a372-d8a4ffdf3f0f@github.com>
References: <AJ_0a1zfRlhvu3sZ6UII_C8EbVH3QQhfKcg4_TEMlRE=.fd0458eb-6480-47b5-9123-58549585a2a4@github.com>
 <S9aJoT-2NAMXda6SGYP0-h13c3KS5ysdDNNPIzzDywo=.81c90f3a-cddd-4e03-a372-d8a4ffdf3f0f@github.com>
Message-ID: <6_rq3XjnXNVkRQTHXbk_-5Of2XluvIlrA2sLutczjiM=.dd8fb989-58ac-45fe-904d-ce0067d05ef6@github.com>

On Fri, 13 Jun 2025 13:25:38 GMT, Dermot Boyle <duke at openjdk.org> wrote:

>> Replaced programmatic check for the OS platform (which threw a Skipped exception) with JTreg @requires.
>
> Dermot Boyle has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused supportedByPlatform() method definition

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25781#pullrequestreview-2925082343

From duke at openjdk.org  Fri Jun 13 14:58:41 2025
From: duke at openjdk.org (Dermot Boyle)
Date: Fri, 13 Jun 2025 14:58:41 GMT
Subject: RFR: 8359127: Amend
 java/nio/channels/DatagramChannel/PromiscuousIPv6.java to use @requires for OS
 platform selection [v2]
In-Reply-To: <NZ795iJnEa2u8GXcN3e5hQD39TtXz-SbSl4uayetBfo=.b3236e48-0f55-4bc9-9c3b-4bb4a0b1fa45@github.com>
References: <AJ_0a1zfRlhvu3sZ6UII_C8EbVH3QQhfKcg4_TEMlRE=.fd0458eb-6480-47b5-9123-58549585a2a4@github.com>
 <NZ795iJnEa2u8GXcN3e5hQD39TtXz-SbSl4uayetBfo=.b3236e48-0f55-4bc9-9c3b-4bb4a0b1fa45@github.com>
Message-ID: <MfHrvpiGYUNPceqtsvT60saHAFCDM-2cY3wFVJ02YRk=.eccd4e5f-d800-4529-848a-2933e1813c9b@github.com>

On Fri, 13 Jun 2025 12:49:00 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Dermot Boyle has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unused supportedByPlatform() method definition
>
> test/jdk/java/nio/channels/DatagramChannel/PromiscuousIPv6.java line 215:
> 
>> 213:         boolean hasIPV6MulticastAll;
>> 214: 
>> 215:         if (!supportedByPlatform()) {
> 
> supportedByPlatform() method definition can be deleted from line number 207, as not it is not being called anywhere.

Thanks Mahendra, have removed it

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25781#discussion_r2145278791

From dfuchs at openjdk.org  Fri Jun 13 15:03:30 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Jun 2025 15:03:30 GMT
Subject: RFR: 8359127: Amend
 java/nio/channels/DatagramChannel/PromiscuousIPv6.java to use @requires for OS
 platform selection [v2]
In-Reply-To: <S9aJoT-2NAMXda6SGYP0-h13c3KS5ysdDNNPIzzDywo=.81c90f3a-cddd-4e03-a372-d8a4ffdf3f0f@github.com>
References: <AJ_0a1zfRlhvu3sZ6UII_C8EbVH3QQhfKcg4_TEMlRE=.fd0458eb-6480-47b5-9123-58549585a2a4@github.com>
 <S9aJoT-2NAMXda6SGYP0-h13c3KS5ysdDNNPIzzDywo=.81c90f3a-cddd-4e03-a372-d8a4ffdf3f0f@github.com>
Message-ID: <GSdMuNqkT03x23NE1VBfHVedkk1gj0OObCxIuNbFdOY=.3ec8d5e5-aff7-4ba3-b223-b2007a372250@github.com>

On Fri, 13 Jun 2025 13:25:38 GMT, Dermot Boyle <duke at openjdk.org> wrote:

>> Replaced programmatic check for the OS platform (which threw a Skipped exception) with JTreg @requires.
>
> Dermot Boyle has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused supportedByPlatform() method definition

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25781#pullrequestreview-2925141994

From duke at openjdk.org  Fri Jun 13 15:21:38 2025
From: duke at openjdk.org (duke)
Date: Fri, 13 Jun 2025 15:21:38 GMT
Subject: RFR: 8359127: Amend
 java/nio/channels/DatagramChannel/PromiscuousIPv6.java to use @requires for OS
 platform selection [v2]
In-Reply-To: <S9aJoT-2NAMXda6SGYP0-h13c3KS5ysdDNNPIzzDywo=.81c90f3a-cddd-4e03-a372-d8a4ffdf3f0f@github.com>
References: <AJ_0a1zfRlhvu3sZ6UII_C8EbVH3QQhfKcg4_TEMlRE=.fd0458eb-6480-47b5-9123-58549585a2a4@github.com>
 <S9aJoT-2NAMXda6SGYP0-h13c3KS5ysdDNNPIzzDywo=.81c90f3a-cddd-4e03-a372-d8a4ffdf3f0f@github.com>
Message-ID: <hrhtGfsHuGHyUzQ3Vl4y4gOgcz4qzjpALGdd4DvWtiY=.924bc5e8-b37d-49ec-bcee-5ef5d0145f55@github.com>

On Fri, 13 Jun 2025 13:25:38 GMT, Dermot Boyle <duke at openjdk.org> wrote:

>> Replaced programmatic check for the OS platform (which threw a Skipped exception) with JTreg @requires.
>
> Dermot Boyle has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused supportedByPlatform() method definition

@dermotb 
Your change (at version 6831ea37cce33c68cd3279208cc9db7a928555c3) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25781#issuecomment-2970725362

From bpb at openjdk.org  Fri Jun 13 15:30:19 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Jun 2025 15:30:19 GMT
Subject: RFR: 8357847: (ch) AsynchronousFileChannel implementations should
 support FFM Buffers [v5]
In-Reply-To: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
References: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
Message-ID: <skcEpBdOIQIkpxfKLvhjTs7anUCB6m9Y53mk5HpRMWY=.4c62d1d0-b8dc-4703-897d-af68ef355dd3@github.com>

> Acquire the scope of a direct buffer before it is used and release it after the task has finished with it, whether the task execution is immediate or pended.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - 8357912: Changes pursuant to JDK-8358958
 - Merge
 - 8357912: Add reading to test of unsupported views
 - 8357912: Add similar changes to SimpleAsynchronousFileChannelImpl
 - 8357847: Use IOUtil.bufferAddress; broaden testing of Arena types
 - 8357847: WindowsAsynchronousFileChannelImpl should support FFM Buffers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25531/files
  - new: https://git.openjdk.org/jdk/pull/25531/files/906057a3..2914bebb

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

  Stats: 67139 lines in 1197 files changed: 37833 ins; 18475 del; 10831 mod
  Patch: https://git.openjdk.org/jdk/pull/25531.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25531/head:pull/25531

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

From duke at openjdk.org  Fri Jun 13 15:59:59 2025
From: duke at openjdk.org (Dermot Boyle)
Date: Fri, 13 Jun 2025 15:59:59 GMT
Subject: Integrated: 8359127: Amend
 java/nio/channels/DatagramChannel/PromiscuousIPv6.java to use @requires for OS
 platform selection
In-Reply-To: <AJ_0a1zfRlhvu3sZ6UII_C8EbVH3QQhfKcg4_TEMlRE=.fd0458eb-6480-47b5-9123-58549585a2a4@github.com>
References: <AJ_0a1zfRlhvu3sZ6UII_C8EbVH3QQhfKcg4_TEMlRE=.fd0458eb-6480-47b5-9123-58549585a2a4@github.com>
Message-ID: <SCo5nrsMDVlzi49LG3_ulPj4HxgVecUraKePvsSBekk=.e477b9da-6fce-4e0c-9450-99b7746a7533@github.com>

On Thu, 12 Jun 2025 11:55:35 GMT, Dermot Boyle <duke at openjdk.org> wrote:

> Replaced programmatic check for the OS platform (which threw a Skipped exception) with JTreg @requires.

This pull request has now been integrated.

Changeset: 78b1360e
Author:    dermster <dermot.boyle at oracle.com>
Committer: Mark Sheppard <msheppar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78b1360e7de84585d6e387ac6e0789a4d02187d5
Stats:     18 lines in 1 file changed: 1 ins; 11 del; 6 mod

8359127: Amend java/nio/channels/DatagramChannel/PromiscuousIPv6.java to use @requires for OS platform selection

Reviewed-by: djelinski, dfuchs

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

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

From alanb at openjdk.org  Fri Jun 13 17:33:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Jun 2025 17:33:38 GMT
Subject: RFR: 8357847: (ch) AsynchronousFileChannel implementations should
 support FFM Buffers [v5]
In-Reply-To: <skcEpBdOIQIkpxfKLvhjTs7anUCB6m9Y53mk5HpRMWY=.4c62d1d0-b8dc-4703-897d-af68ef355dd3@github.com>
References: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
 <skcEpBdOIQIkpxfKLvhjTs7anUCB6m9Y53mk5HpRMWY=.4c62d1d0-b8dc-4703-897d-af68ef355dd3@github.com>
Message-ID: <geHZi04g25HAKwAqQg0qRWvs1XYmiZxcTdWB7ds1e-w=.e95f90a5-d127-4b73-9c03-9904a312e86a@github.com>

On Fri, 13 Jun 2025 15:30:19 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Acquire the scope of a direct buffer before it is used and release it after the task has finished with it, whether the task execution is immediate or pended.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - 8357912: Changes pursuant to JDK-8358958
>  - Merge
>  - 8357912: Add reading to test of unsupported views
>  - 8357912: Add similar changes to SimpleAsynchronousFileChannelImpl
>  - 8357847: Use IOUtil.bufferAddress; broaden testing of Arena types
>  - 8357847: WindowsAsynchronousFileChannelImpl should support FFM Buffers

I checked the latest update and the src changes look okay. I'll do a second pass on Monday.

For the test, can you remove the `@Disabled` from the etc/MemorySegments.java as that should give us good coverage.

test/jdk/java/nio/channels/AsynchronousFileChannel/Basic.java line 566:

> 564: 
> 565:     // tests unsupported MemorySegment view buffers
> 566:     static void testViewsOfConfinedArenas(Path file) throws IOException {

MemorySegments.testAsyncFileChannelReadWrite will test this too.

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

PR Comment: https://git.openjdk.org/jdk/pull/25531#issuecomment-2971049932
PR Review Comment: https://git.openjdk.org/jdk/pull/25531#discussion_r2145599250

From bpb at openjdk.org  Fri Jun 13 17:38:28 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Jun 2025 17:38:28 GMT
Subject: RFR: 8357847: (ch) AsynchronousFileChannel implementations should
 support FFM Buffers [v5]
In-Reply-To: <geHZi04g25HAKwAqQg0qRWvs1XYmiZxcTdWB7ds1e-w=.e95f90a5-d127-4b73-9c03-9904a312e86a@github.com>
References: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
 <skcEpBdOIQIkpxfKLvhjTs7anUCB6m9Y53mk5HpRMWY=.4c62d1d0-b8dc-4703-897d-af68ef355dd3@github.com>
 <geHZi04g25HAKwAqQg0qRWvs1XYmiZxcTdWB7ds1e-w=.e95f90a5-d127-4b73-9c03-9904a312e86a@github.com>
Message-ID: <TOVo9JwbHYro4onp0n8tSmJeRZ4g42MhrcfPW6XB0FU=.bbbf5d3d-b759-4f63-99a8-08f782255559@github.com>

On Fri, 13 Jun 2025 17:28:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> For the test, can you remove the `@Disabled` from the etc/MemorySegments.java as that should give us good coverage.

And `@DisabledOnOs(OS.WINDOWS)`?

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

PR Comment: https://git.openjdk.org/jdk/pull/25531#issuecomment-2971074283

From alanb at openjdk.org  Fri Jun 13 17:41:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Jun 2025 17:41:33 GMT
Subject: RFR: 8357847: (ch) AsynchronousFileChannel implementations should
 support FFM Buffers [v5]
In-Reply-To: <TOVo9JwbHYro4onp0n8tSmJeRZ4g42MhrcfPW6XB0FU=.bbbf5d3d-b759-4f63-99a8-08f782255559@github.com>
References: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
 <skcEpBdOIQIkpxfKLvhjTs7anUCB6m9Y53mk5HpRMWY=.4c62d1d0-b8dc-4703-897d-af68ef355dd3@github.com>
 <geHZi04g25HAKwAqQg0qRWvs1XYmiZxcTdWB7ds1e-w=.e95f90a5-d127-4b73-9c03-9904a312e86a@github.com>
 <TOVo9JwbHYro4onp0n8tSmJeRZ4g42MhrcfPW6XB0FU=.bbbf5d3d-b759-4f63-99a8-08f782255559@github.com>
Message-ID: <nZ5oVHymrCzG3nXYcuLtkH684wHsKZ2Cfvkg87zA1LA=.d132d53a-8726-4034-a7fb-8a72f25b5bf1@github.com>

On Fri, 13 Jun 2025 17:34:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > For the test, can you remove the `@Disabled` from the etc/MemorySegments.java as that should give us good coverage.
> 
> And `@DisabledOnOs(OS.WINDOWS)`?

Yes, testAsyncFileChannelReadWrite and testAsyncFileChannelWriteRacingArenaClose should now run on all platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/25531#issuecomment-2971086861

From bpb at openjdk.org  Fri Jun 13 17:45:16 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Jun 2025 17:45:16 GMT
Subject: RFR: 8357847: (ch) AsynchronousFileChannel implementations should
 support FFM Buffers [v6]
In-Reply-To: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
References: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
Message-ID: <Bt54kCcUFNBb0M1Cssww_YGeBSKdu0DU9GnnspBhb_s=.f0120486-ff00-4805-bf1c-8609d176533a@github.com>

> Acquire the scope of a direct buffer before it is used and release it after the task has finished with it, whether the task execution is immediate or pended.

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

  8357912: Remove @Disabled[OnOs] from MemorySegments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25531/files
  - new: https://git.openjdk.org/jdk/pull/25531/files/2914bebb..abec5885

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

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

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

From bpb at openjdk.org  Fri Jun 13 17:58:16 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Jun 2025 17:58:16 GMT
Subject: RFR: 8357847: (ch) AsynchronousFileChannel implementations should
 support FFM Buffers [v7]
In-Reply-To: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
References: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
Message-ID: <XrHL_2VLP_16rt22S_4W4D_aA5pOx3qr73S7shOM5rg=.262319ae-5b17-45fa-86fe-5c0834efe960@github.com>

> Acquire the scope of a direct buffer before it is used and release it after the task has finished with it, whether the task execution is immediate or pended.

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

  8357912: Remove testViewsOfConfinedArenas sub-test of AsynchronousFileChannel/Basic.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25531/files
  - new: https://git.openjdk.org/jdk/pull/25531/files/abec5885..2cbb0283

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

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

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

From alanb at openjdk.org  Sat Jun 14 11:10:37 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 14 Jun 2025 11:10:37 GMT
Subject: RFR: 8357847: (ch) AsynchronousFileChannel implementations should
 support FFM Buffers [v7]
In-Reply-To: <XrHL_2VLP_16rt22S_4W4D_aA5pOx3qr73S7shOM5rg=.262319ae-5b17-45fa-86fe-5c0834efe960@github.com>
References: <YTeYj3tpTYe-lNbwQenLXmtG7gsYA4MHq31YQZ8H_Zw=.a1b524e4-9990-4f6a-895b-2fcfe26d76ef@github.com>
 <XrHL_2VLP_16rt22S_4W4D_aA5pOx3qr73S7shOM5rg=.262319ae-5b17-45fa-86fe-5c0834efe960@github.com>
Message-ID: <8-x30vhOIsFqMOyQOY7NKsbatGl8RZxWpfUBuyx5TCI=.63c7e9d5-c998-4a21-8f3a-633940d1ab9d@github.com>

On Fri, 13 Jun 2025 17:58:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Acquire the scope of a direct buffer before it is used and release it after the task has finished with it, whether the task execution is immediate or pended.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357912: Remove testViewsOfConfinedArenas sub-test of AsynchronousFileChannel/Basic.java

Marked as reviewed by alanb (Reviewer).

I did another pass over this and I think it's okay.

For SimpleAsynchronousFileChannelImpl + shared then it does 2 acquire/releases. The first acquire in the initiating thread and the second acquire in the pooled thread. Removing the acquire/release from the nested usage in IOUtil would be disruptive so I think what you have is okay because this isn't a widely used API and the implementation is begging to be replaced if more usage/interest were to happen in the future. Note that the isDirect checks in the change to this code aren't needed as acquireScope/releaseScope don't do anything when there isn't a session.

WindowsAsynchronousFileChannelImpl looks okay. The acquire is in the initiating thread and it releases if there isn't an I/O op pending. If pending then it gets released in the pooled-thread when the I/O op completes or fails.

The update to test is okay. Note that genBuffer doesn't release memory so maybe we should change this test to run othervm. Same thing for etc/MemorySegments.java as it leaks when testing allocations from the global arena. The imports of the DisabledXX annotations can be removed.

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

PR Review: https://git.openjdk.org/jdk/pull/25531#pullrequestreview-2927826466
PR Comment: https://git.openjdk.org/jdk/pull/25531#issuecomment-2972481448

From jpai at openjdk.org  Sun Jun 15 04:29:40 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 15 Jun 2025 04:29:40 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte) [v3]
In-Reply-To: <c-WFuFIED56QxSBaFv-HXYgn5LsJy5nQ7u-bWzT-WVA=.b7b03730-1b72-4ab5-aa6d-d224849cc0bd@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
 <c-WFuFIED56QxSBaFv-HXYgn5LsJy5nQ7u-bWzT-WVA=.b7b03730-1b72-4ab5-aa6d-d224849cc0bd@github.com>
Message-ID: <-19lLxuydf8B_cCj9F7p0g_iFTx5tGagkJxdihC02WE=.1ebbbe5e-e7cf-48c1-81bd-e402d2ab0f84@github.com>

On Wed, 11 Jun 2025 12:07:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
>> 
>> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
>> 
>> 
>> public void setTTL(byte ttl) throws IOException
>> public byte getTTL() throws IOException
>> 
>> 
>> and this other one on `MulticastSocket`:
>> 
>> 
>> public void send(DatagramPacket p, byte ttl) throws IOException 
>> 
>> 
>> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
>> 
>> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
>> 
>> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's review - continue to test MulticastSocket in SendCheck

The CSR is now ready for review https://bugs.openjdk.org/browse/JDK-8359594

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

PR Comment: https://git.openjdk.org/jdk/pull/25744#issuecomment-2973486415